From rem-conf Thu Jun 01 00:00:08 2000 From rem-conf-request@es.net Thu Jun 01 00:00:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xOuM-0005U8-00; Wed, 31 May 2000 23:56:46 -0700 Received: from lint.cisco.com [171.68.224.209] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xOuK-0005Tc-00; Wed, 31 May 2000 23:56:44 -0700 Received: from omega.cisco.com (omega.cisco.com [171.69.63.141]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id XAA16544; Wed, 31 May 2000 23:55:13 -0700 (PDT) Date: Wed, 31 May 2000 23:55:13 -0700 (PDT) From: Dan Wing To: Rex Coldren cc: "Bratakos, Maroula" , rem-conf@es.net Subject: Re: RFC 2833 on Tones In-Reply-To: <39355668.6B6E05F8@agcs.com> Message-ID: <0005312352530.25129-100000@omega.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 31 May 2000 11:14 -0700, Rex Coldren wrote: > RFC 2833 does not address the possibility of replacing normal RTP > payloads with RFC 2833 payloads. This would be a useful concept in > bandwidth limited networks. What do you think? That is how AAL2 (ITU I.366.2) does it. But it only works if you know, a priori, that the peer understands RFC2833 events. In fact, I suspect the inability to know that is why RFC2833 recommends sending both the tones and RFC2833 events -- to allow for peers that don't understand or don't prefer RFC2833 events. -Dan Wing From rem-conf Thu Jun 01 01:48:26 2000 From rem-conf-request@es.net Thu Jun 01 01:48:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xQXs-0007NE-00; Thu, 1 Jun 2000 01:41:40 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12xQXp-0007MR-00; Thu, 1 Jun 2000 01:41:38 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-111.dialup.cs.tu-berlin.de [130.149.145.111]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id KAA03122; Thu, 1 Jun 2000 10:38:51 +0200 (MET DST) Message-Id: <4.3.2.20000601095434.00dc5920@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 01 Jun 2000 10:44:50 +0200 To: Jonathan Rosenberg From: Stephan Wenger Subject: Re: Question on RFC2733, packet-based FEC Cc: rem-conf@es.net In-Reply-To: <3935F9DB.85DE1FEF@dynamicsoft.com> References: <4.3.2.20000531092714.00dc2210@mail.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan, This has actually been discussed within IETF. In fact, I think one of >the MPEG-4 over RTP drafts may actually be doing this. We rejected this >from the rfc2733 mechanism, as I recall, because you needed a whole >bunch of additional stuff to indicate what is covered by the FEC, if its >not the whole packet. In the worst case, you'd actually need a bitmap >which is the size of the largest packet, where the bitmap indicates >which bits are protected by FEC. As a result, any general purpose >mechanism for unequal protection would likely require as many bits to >signal as the savings obtained from the unequal protection. Note that >the advantages of this unequal proection is solely reducing packet >sizes. Well, I believe that, in the future, all video coding schemes will include data partitioning (DP). DP allows you to separate the different data types of video (e.g. motion vectors and coefficients) from each other. Similarly, a few audio coding schemes such as G.723.1 already identify bits that are more important for the perceptual quality of reconstructed audio, and allow to separate those from the other bits. To arrange the more important bits at the begin, and the less important bits at the end of a packet is (or will be in the future) a functionality of the media coding. STandards that already allow for this include H.263++ (to be ratified in fall), MPEG-4 visual, and G.723.1. There might be more. If we assume such input data, then there is no need for any additional signalling of the importance of bits. The size of the FEC packet would be the indication of the number of protected bits. I agree that this is not a 'general purpose' mechanism. But it is powerful enough for all practical forms of use I'm currently thinking about. And the change would be rather minor -- a mere change of a requirement, no change in the packet format. The change would be completely upward compatible. I wish I would have thought about this earlier, and payd more attention to IETF discussions on that. Now, it's a bit late. But I feel that we should consider introducing such a change at the time when RFC2733 is moving forward from proposed to draft standard status. Regarding your remark that one of the MPEG-4 drafts is currently addressing this issue: you're right. But one reason why this draft does not have that much support is precisely that it mixes QoS/transport functionality with simple packetization issues (where architectural cleanness would suggest separating the problem). Stephan From rem-conf Thu Jun 01 03:33:46 2000 From rem-conf-request@es.net Thu Jun 01 03:33:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xSC1-0001j9-00; Thu, 1 Jun 2000 03:27:13 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12xSBy-0001iz-00; Thu, 1 Jun 2000 03:27:11 -0700 Received: from csperkins.demon.co.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Thu, 1 Jun 2000 11:26:26 +0100 Received: from csperkins.demon.co.uk (localhost [127.0.0.1]) by csperkins.demon.co.uk (8.9.3/8.8.7) with ESMTP id KAA01698; Thu, 1 Jun 2000 10:38:04 +0100 Message-Id: <200006010938.KAA01698@csperkins.demon.co.uk> To: Dan Wing cc: Rex Coldren , "Bratakos, Maroula" , rem-conf@es.net Subject: Re: RFC 2833 on Tones In-Reply-To: Message from Dan Wing of "Wed, 31 May 2000 10:57:49 PDT." <0005311046400.19593-100000@omega.cisco.com> Date: Thu, 01 Jun 2000 10:38:04 +0100 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Dan Wing writes: >On Wed, 31 May 2000 10:43 -0700, Rex Coldren wrote: >> When used with RFC 2198, the number of redundant encodings also has an >> impact on the total bandwidth used. > >I think the duplication has merit, but appropriate text is required >explaining when such RFC2198 duplication of DTMF tones isn't appropriate. > >Perhaps a simple MAY is good enough, but only if we assume implementors >will understand why it's a MAY instead of SHOULD or MUST. I haven't read >RFC2198 in awhile, but it may have text which explains some of the >drawbacks of arbitrary duplication of packets in a bandwidth-constrained >or policed network. My quick skim of RFC2198 didn't turn up such text, >however. It's briefly mentioned in the security considerations section, but could probably do with expanding. I'm maintaining an errata list for this, for when we revise the RFC, if you have any appropriate words I can add them. Colin From rem-conf Thu Jun 01 03:36:19 2000 From rem-conf-request@es.net Thu Jun 01 03:36:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xSG2-0001oB-00; Thu, 1 Jun 2000 03:31:22 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xSFz-0001o1-00; Thu, 1 Jun 2000 03:31:19 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18392; Thu, 1 Jun 2000 06:31:16 -0400 (EDT) Message-Id: <200006011031.GAA18392@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mpeg4-es-01.txt Date: Thu, 01 Jun 2000 06:31:16 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for MPEG-4 Audio/Visual streams Author(s) : Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata Filename : draft-ietf-avt-rtp-mpeg4-es-01.txt Pages : 20 Date : 31-May-00 This document describes RTP payload formats for the carriage of MPEG-4 Audio and Visual streams[2][3], and an RTCP format for MPEG-4 upstream messages functionalities[4]. In this specification, MPEG-4 Audio/Visual bitstreams are directly mapped into RTP packets. The RTP header fields usage and the fragmentation rule for MPEG-4 Visual and Audio bitstreams are specified. It also specifies an RTCP packet usage to carry the MPEG-4 upstream messages. In addition, MIME type registrations and SDP usages for the MPEG-4 Audio and Visual streams are defined in this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mpeg4-es-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000531085219.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-es-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000531085219.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jun 01 05:58:43 2000 From rem-conf-request@es.net Thu Jun 01 05:58:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xUR9-0004t8-00; Thu, 1 Jun 2000 05:50:59 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 12xUR6-0004sy-00; Thu, 1 Jun 2000 05:50:57 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-65.dialup.cs.tu-berlin.de [130.149.145.65]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id OAA22234; Thu, 1 Jun 2000 14:41:39 +0200 (MET DST) Message-Id: <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 01 Jun 2000 14:47:37 +0200 To: "Shigeru Fukunaga" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" From: Stephan Wenger Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <006301bfcb16$81489580$e750fea9@kangaroo> References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Shigeru, group, Thanks for your reply. >At first, we would like to describe only MPEG-4 specific things in this >draft. >As FIR is a common technique for all video coding, other common document >seems to be appropriate. Ok, so you propose to leave "common" feedback mechanism like FIR to some other place, and put only "MPEG-4" specific feedback stuff into your payload spec. I'm not sure that this is the right thing to do, for three reasons: 1) unavailability of a 'general' feedback spec, 2) previous payload specs contents and 3) the difficulty to define "common feedback mechanisms". Regarding 1) When we discussed RFC2429, covering H.263+, we had already adopted reference picture selection (NEWPRED), due to work of your company (OKI). Early Internet drafts of RFC2429 suggested at least two different ways to handle NEWPRED feedback, but were deleted from the drafts because of scaling problems. Several people though of coming up with a 'unified feedback solution', but, until now, nothing happened. This might be partly lack of interest, and partly the difficulty of the problem. Consequently, when adopting your draft unchanged, there would not be a standardized way to perform FIR and similar in IETF environments such as SIP. The only way to respond to packet losses, beyond responding on RTCP receiver reports, would be to use NEWPRED. Correct me if I'm wrong here. Regarding 2) There are currently two categories of RTP payload specs with respect to the feedback problem. Category one defines RTCP feedback, and category two does not. There are, to the best of my knowledge, no payload specs proposed or accepted that follow your idea to include only a few feedback mechanisms specific to a media coding and not in include other known ones for the same media coding. Certainly, not so important ones like FIR. Regarding 3) FIR is common to all video coding? Well, people not using compression (BT565) will disagree. Audio folk will disagree. Motion JPEG proponents will also disagree. On the other hand, NEWPRED is unique to MPEG-4? You know that H.263+, available as a standard since 1998, includes NEWPRED as well, so NEWPRED is NOT unique to MPEG-4. A strong argument to include NEWPRED into a unified RTCP feedback RFC? Furthermore, there are mechanisms like Slices out there, which are available in many, but not all, predictive video coding standards. Are they candidates for a 'common' feedback doc, or should they go into a RTCP section of a specific payload? >Second, new proposal just before the last call is not good. We largely >discussed >the issues of RTCP for NEWPRED since Adelade meeting, and revised text. >It also takes much time to discuss FIR, however, we have enough time. With this I disagree strongly. First let me say, that I'm not on a mission to prevent MPEG-4 ES packetization to move forward. It's not my plan to artificially delay the process, and if it would be, then I'm sure that the our chairs would be able to move forward with the draft regardless of my concerns. If people in the ITU-T want to prevent MPEG-4 >from happen in H.323, then there are other fori more appropriate to achieve that goal. Having said this, however, I have to emphasize that a) we are talking about a Internet Draft, b) that you asked for comments, and c) that I see an architectural flaw here. I'm aware that additional delay may cause some delay in ITU-T Q.13/16 and Q.14/16 work (on H.245 for example) as well (meaning that possible the adoption of MPEG-4 visual/audio to H.323 would be delayed somewhat). That could be a reason for us (me and you guys) to work harder, but not to let a draft pass that contains known architectural problems. Can you please inform this group about your timing constraints? Why the rush? The way to move forward: I see three ways to move forward from now 1) Someone convinces me that I should shut up and let things go. Probably I'm stickling to principles that are not the general principles of AVT. Anyone besides the proponents of the draft (outside the MPEG core)? 2) Delete section 5 (the rest seems to be, apart from language/editorial problems, ok, at least to me). Work together with interested parties, including myself, on a unified feedback solution, in a separate RFC or a set of separate RFCs. 3) Leave section 5 and bring it into such a shape that it can incorporate other feedback schemes, including FIR and SLice Re-transmission at least. I'm still working on my changes for that. Stephan From rem-conf Thu Jun 01 09:46:31 2000 From rem-conf-request@es.net Thu Jun 01 09:46:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xXxQ-0000Sb-00; Thu, 1 Jun 2000 09:36:32 -0700 Received: from adsl-63-193-136-149.dsl.lsan03.pacbell.net (okwhatever.com) [63.193.136.149] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xXxO-0000SL-00; Thu, 1 Jun 2000 09:36:30 -0700 Received: from okwhatever.com [207.175.229.62] by okwhatever.com with ESMTP (SMTPD32-5.01) id A18B1A5E01BA; Thu, 01 Jun 2000 09:38:35 PST Message-ID: <3936909F.2542FB2@okwhatever.com> Date: Thu, 01 Jun 2000 09:34:39 -0700 From: Frank Basso X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Re: SIGCOMM 2000 Call for Participation References: <200006010024.RAA22782@rum.isi.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe Joe Touch wrote: > Call for Participation > ACM SIGCOMM 2000 Conference > > August 28 - September 1, 2000 > Grand Hotel, Stockholm, Sweden > http://www.acm.org/sigcomm/sigcomm2000 > sigcomm2000-info@acm.org > > Deadlines: > > Proposals for student travel grant: June 22, 2000 > Proposals for poster session: July 12, 2000 > Advance registration ends: July 28, 2000 > Outrageous opinions desired: starting August 25, 2000 > > SIGCOMM 2000 is the annual conference of the Special Interest Group on > Data Communication (SIGCOMM), a single-track, highly selective > conference with a technical program of 26 papers, tutorials by noted > instructors on the two days prior, and sessions on speculative results. > > Early registration for Sigcomm 2000 is now open. Registration details, > as well as information on student travel grants and requests for > proposals for a work-in-progress poster session are available at the > Sigcomm website above. > > Registration > > Conference and hotel registration is handled by the Stockholm Convention > Bureau (see address below, or website above). Note that the number of > delegates is limited to 500 and that registration requests will be > handled on a "first-come-first-served" basis. Please refer to the web > form or paper form for various rates and options. ACM has selected Delta > Air Lines as the Official airline for its conferences in Europe for > 2000. Delta has special fares in place for ACM and your traveling > companions. See the website for further details. > > Sigcomm registration is by secure web form, or fax or ordinary mail. > On-line registration is available at the Sigcomm website; fax and > ordinary mail registrations must be completed well in advance of the > deadlines, using this PDF form sent or faxed to the address below: > https://www.it.uu.se/conf/sigcomm2000/register.pdf > http://www.acm.org/sigcomm/sigcomm2000/register.pdf > > Stockholm Convention Bureau > ACM SIGCOMM 2000 > P O Box 6911 > SE-102 39 Stockholm, SWEDEN > Phone: +46 8 546 515 00 / Fax: +46 8 546 515 99 > > Opening Reception and Dinner events > > The reception is generously hosted by Stockholm City, and includes a > sightseeing cruise on the water ways of Stockholm, through the Old Town > to the City Hall, site of the famous for the Nobel Prize festivities. > The banquet dinner is hosted at the Vasa Museum, site of the Sweden's > largest and most prestigious warship; dinner is included in the cost of > registration, and guest tickets are available. Advance reservations > necessary for all events. > > Stockholm - the Royal capital of Sweden - is one of the most beautiful > cities in the world. It is built on fourteen islands and surrounded by > waters so clean that you can fish and swim right in the middle of the > city. Stockholm became the capital of Sweden 750 years ago. In the > winding alleyways of the city's medieval Old Town, the air is redolent > with history. And yet, only a few minutes walking distance away lies > the throbbing pulse of a modern city. > > SIGCOMM Award > > The SIGCOMM Award is given annually to a person whose career and > technical achievements demonstrate a long-term commitment to the field > of data communications. ACM SIGCOMM is pleased to announce that the 2000 > SIGCOMM Award is being given to Prof. André Danthine, University of > Liege, Belgium, who will also provide the keynote address. > > Tutorials > > SIGCOMM 2000 begins with two days of full-day tutorials covering single > topics in detail at both the introductory and advanced level. Tutorials > offered this year are: > - Voice over IP > Prof. Henning Schulzrinne, Columbia Univ. > - Analysis of Network and Protocol Behavior with Common Tools > Prof. Shawn Ostermann, Ohio Univ. > - Network Security Protocols > Dr. Radia Perlman, Sun Microsystems > - Distributed control and resource pricing > Dr. Richard Gibbens, Univ. of Cambridge > Dr. Peter Key, Microsoft Research > > Outrageous Opinions Session > > The Outrageous Opinions Session provides an opportunity for sharing > entertaining, provocative, and otherwise enriching ideas and suggestions > in their early stages. Submissions are actively solicited by the OO > Chair Gary Delp (gdelp@acm.org) beginning August 25, 2000. > > Poster Session - Work in Progress > > The Poster Session is an opportunity for students (as primary poster > authors) to present work in progress. Poster proposals should be sent > to the PC chairs by July 12. Posters will be reviewed by the TPC, and > decisions made by early August; see the website for further details. > > Student Travel Awards > > The student travel program provides support for SIGCOMM conference > participation to students, primarily not paper authors, who would > otherwise find it difficult to attend. Students at degree granting > institutions throughout the world are eligible. See the website for > further criteria and application procedures. > > General Co-Chairs > Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se) > Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se) > Program Co-Chairs > Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com) > Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu) > Publicity Chair > Joe Touch, USC/ISI, USA (touch@isi.edu) > Tutorials Chair > Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se) > Local Arrangements Co-Chairs > Bengt Ahlgren, SICS, Sweden (bengta@sics.se) > Christian Tschudin, Uppsala U., Sweden (tschudin@docs.uu.se) > > Support from Ericsson, Telia, and Sprint is gratefully acknowledged. > The student travel grant program is supported by Nokia and the US > National Science Foundation. From rem-conf Thu Jun 01 13:05:23 2000 From rem-conf-request@es.net Thu Jun 01 13:05:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xb6i-0003Mq-00; Thu, 1 Jun 2000 12:58:20 -0700 Received: from icsl.icsl.ucla.edu [128.97.90.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xb6h-0003Mg-00; Thu, 1 Jun 2000 12:58:19 -0700 Received: from pc130 (ts48-24.wla.ts.ucla.edu [164.67.27.225]) by icsl.icsl.ucla.edu (8.8.8+Sun/8.8.8(ICSL0003)) with SMTP id MAA05732; Thu, 1 Jun 2000 12:57:27 -0700 (PDT) From: "Adam Li" To: "Jonathan Rosenberg" , Cc: "D.-S. Park" , "John D. Villasenor" , , Subject: RE: Question on RFC2733, packet-based FEC Date: Thu, 1 Jun 2000 12:57:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3935F9DB.85DE1FEF@dynamicsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, there, Thanks for the discussion on this issue. I should have come to ask for suggestions from you all earlier. But I just came back from a long trip oversea, and am quite occupied by my other works recently. The scheme I proposed is actually very generic and quite simple to implement. It doesn't make much assumption on the payload it protects, and probably won't take much overhead to communicate the protection range and levels. The only thing I am not sure is that if it can be easily fit in the structure of draft-ietf-avt-fec and draft-ietf-avt-reedsolomon. Also, it might make sense to have seperate mechanics for complete and partial recovery of lost packet, since not all codecs have the capability of benefiting from partial recovered data packets. Later today, I will post a document that discribe the proposed scheme, so you can take a look at the details. I really would appreciate your suggestions and feedback on if we should incooperate it into draft-ietf-avt-fec or to start a seperate internet draft on this. Regards, Adam Li ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax) > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, May 31, 2000 10:51 PM > To: Stephan Wenger > Cc: rem-conf@es.net > Subject: Re: Question on RFC2733, packet-based FEC > > > > > Stephan Wenger wrote: > > > > Hi all, > > > > I don't understand the reason for an (artificial?) limitation of > > RFC2733. RFC2733 says that, when calculating FEC over > > several packets of different sizes, the FEC packet has to > > protect all bytes of the biggest packet (and padding is to be > > used for the other packets to bring them up to the size of > > the biggest packet). Is there some hidden secret about this > > requirement? > > > The aim is to provide complete recovery of a missing packet, which > results in this requirement. > > > > > The rest of the EMail describes scenarios where this limitation > > is counter-productive. > > > > In a recent ITU meeting, Adam Li of UCLA brought to our > > attention an idea to implement unequal error protection using > > packet based FEC. What they want to do is to use data > > partitioning to put important video data (such as headers and > > motion vectors) to the front of a packet, and put the less > > important coefficients to the end. Then apply packet based > > FEC only on the first (more important) part of the packets. > > Resulting FEC packets are smaller -- lower bandwidth requirements. > > This has actually been discussed within IETF. In fact, I > think one of > the MPEG-4 over RTP drafts may actually be doing this. We > rejected this > from the rfc2733 mechanism, as I recall, because you needed a whole > bunch of additional stuff to indicate what is covered by > the FEC, if its > not the whole packet. In the worst case, you'd actually > need a bitmap > which is the size of the largest packet, where the bitmap indicates > which bits are protected by FEC. As a result, any general purpose > mechanism for unequal protection would likely require as > many bits to > signal as the savings obtained from the unequal protection. > Note that > the advantages of this unequal proection is solely reducing packet > sizes. > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > From rem-conf Thu Jun 01 15:26:02 2000 From rem-conf-request@es.net Thu Jun 01 15:26:00 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 12xdH7-00000W-00; Thu, 1 Jun 2000 15:17:13 -0700 Received: from asn16-218.mcmail.com ([195.44.16.218] helo=Mailer003) by mail2.es.net with smtp (Exim 1.92 #1) id 12xdGc-0007nr-00; Thu, 1 Jun 2000 15:16:46 -0700 From: Subject: Earn $100,000 Per Year sending E-mail !! Date: Thu, 1 Jun 2000 19:39:16 Message-Id: <805.718022.322111@Mailer003> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To be removed from our mailing list click reply,and type remove in the subject box. Thankyou. Tens of thousands of new people are going online every week, within the next three to four years there will be over 250 million people surfing the net, and within the next eight years there will be over a billion. That is a lot of people, and they are all within your reach. EARN $100,000 PER YEAR SENDING E-MAIL!!! DON'T DELETE THIS.....PRINT IT......READ IT!!! YOU'LL BE GLAD YOU DID!!!! Dear Friend, You can earn $50,000 or more in the next 90 days sending e-mail, seem impossible? ------------------------------------------------------------ "AS SEEN ON NATIONAL T.V." Thank you for your time and Interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an Entire show to the investigation of the program described below to see, if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for All that there are, absolutely no laws prohibiting the participation in the program. This has helped to Show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing, much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. "HERE IT IS BELOW" ============================================================ *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a Look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days! Please read the enclosed program.. THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEYMAKING OPPORTUNITY. It does not require you to come into contact with people, do any hard work, and best of all, you Never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you've been waiting for, THIS IS IT! Simply follow the instructions, and your dreams will come true. This multi-level e-mail order marketing program works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialised method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over >From scratch. Without hesitating, Trump said he would find a good network marketing company and Get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned His response "That's why I'm sitting up here and you are all sitting out there!" With network marketing you have two sources of income. Direct commissions from sales you make yourself and commissions from sales made by people you introduce to the business. Residual income is the secret of the wealthy. It means investing time or money once and getting paid Again and again and again. In network marketing, it also means getting paid for the work of others. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years Down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, They just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON.I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at Least gets my money back. But like most of you I was still a little sceptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is Indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, the only expense is my time. I am telling you like it is, I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it cost me. In less than one week, I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back And relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!! Remember that it won't work if you don't try it. This program does work, but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work, you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT#1, and100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are if financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke P.S. Do you have any idea what 11,700 $5 bills ($58,000) look like piled upon a kitchen table? IT'S AWESOME! ------------------------------------------------------------ A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that an amateur could, not have created such a program, and one that is legal. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a Testimonial for this program. I have already made over 4 MILLION DOLLARS! I have retired from the program after sending out over 16,000 programs. Now I have several offices that make this and several other programs here and over seas. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent, IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA ------------------------------------------------------------ HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ ------------------------------------------------------------ INSTRUCTIONS: Before you say "BULL... ", Please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere: This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if You don't order them). * For each report, send $5.00 CASH, the NAME & NUMBEROF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember that this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you copy every name and address ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE! To assist you with marketing your business on the internet, the 4 reports you purchase will provide you with invaluable marketing information which includes how to send bulk e-mails, where to find thousands of free classified ads and much, much more. In addition you will be provided with information on Internet Marketing Clubs such as INTERNET MARKETING RESOURCES (IMR): This is one the premiere Internet marketing clubs on the INTERNET. This club provides a forum where Internet marketers from all over the world can exchange ideas and secrets on Internet Marketing. In addition, this club specialises in providing free Internet marketing tools and services for the Do-Yourself-Internet-Marketer. They will provide you with free bulk e-mail software and up to 1,000,000 fresh e-mail addresses each week. This club Will provide you with hundreds of free resources which include: How to obtain free web sites, how to obtain top rankings in search engines for your web-site, how to send bulk e-mail into AOL and CompuServe, how to market your products on newsgroups, free classified ads, electronic malls, bulletin boards, banner ads and much more. http://homepage1-2.virtualave.net/index3.htm There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mails out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! REPORT #2 will show you the best methods for bulk e mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET 1. Advertising on the 'Net is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5 .........................$50 2nd level--10 members from those 10 ($5 x 100)..............$500 3rd level--10 members from those 100 ($5 x 1,000)...........$5,000 4th level--10 members from those 1,000 ($5 x 10,000)........$50,000 ----------- THIS TOTALS ------------------------------------$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------------------------ AVAILABLE REPORTS ------------------------------------------------------------ *** Order Each REPORT by NUMBER and NAME *** Notes: - ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT (CHEQUES NOT ACCEPTED) - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure wrapping it in at least two sheets of paper conceals the cash - On one of those sheets of paper, include: (a) The number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: ____________________________________________________________ REPORT #1 "The Insiders Guide To Advertising For Free on the Internet" ORDER REPORT #1 FROM: Casper Godber 2 NEWFIELD AVENUE, CASTLEFORD, WEST YORKSHIRE. WF10 4BH U.K. ____________________________________________________________ REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: R Tweed 51 VICTORIA ROAD SYDENHAM BELFAST BT4 1QU U.K.____________________________________________________________ REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: Reports Connaught House Old Rectory Close Mersham Kent TN25 6LZ UK ____________________________________________________________ REPORT #4 "How to become a Millionaire utilising the Power Of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: Susie Norman 801 N.W. Blvd. Ardmore, OKLAHOMA 73401 USA. ____________________________________________________________ ******* TIPS FOR SUCCESS ******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO PRODUCE! 2. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST ANYTHING TO SHIP! 3. YOU ARE SELLING A PRODUCT WHICH DOES NOT COST YOU ANYTHING TO ADVERTISE! 4. YOU ARE UTILIZING THE POWER OF THE INTERNET AND THE POWER OF MULTI-LEVEL MARKETING TO DISTRIBUTE YOUR PRODUCT ALL OVER THE WORLD! 5. YOUR ONLY EXPENSES OTHER THAN YOUR INITIAL $20 INVESTMENT IS YOUR TIME! 6. VIRTUALLY ALL OF THE INCOME YOU GENERATE FROM THIS PROGRAM IS PURE PROFIT! 7. THIS PROGRAM WILL CHANGE YOUR LIFE FOREVER. ******* T E S T I M O N I A L S ******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Steven Bardfield, Portland, OR My name is Mitchell. My wife, Jody, and I live in Chicago, IL. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Jody about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Jody totally Ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Jody in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Mitchell Wolf MD., Chicago, IL The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Charles Morris, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this Year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where people live. There simply isn't a better investment with a faster return Paige Willis, Des Moines, IA I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program, ...11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! Violet Wilson, Johnstown, PA This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Kerry Ford, Centerport, NY ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM! NOW IS THE TIME FOR YOUR TURN DECISIVE ACTION YIELDS POWERFUL RESULTS PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) 1-(800)827-5722 for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings and results are highly dependent on your activities and advertising. This letter Constitute no guarantees stated or implied. In the event that it is determined that this letter constitutes a guarantee of any kind, that guarantee is now void. Any testimonials or amounts of earnings listed in this letter may be factual or fictitious. If you have any question of the legality of this letter contact the Office of Associate Director for Marketing Practices Federal Trade Commission Bureau of Consumer Protection in Washington DC. ============================================================ This ad is being sent in compliance with Senate bill 1618, Title 3, section 301. http://www.senate.gov/~murkowski/commercialemail/S771index.html This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, paragraph (a)(2)(C) of S. 1618, http://www.senate.gov/~murkowski/commercialemail/S771index.html Further transmissions to you by the sender of this email may be stopped at no cost to you by sending a reply to this email address with the word "remove" in the subject line. From rem-conf Thu Jun 01 16:47:56 2000 From rem-conf-request@es.net Thu Jun 01 16:47:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xeas-0006d3-00; Thu, 1 Jun 2000 16:41:42 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xeaq-0006co-00; Thu, 1 Jun 2000 16:41:40 -0700 Received: from kangaroo (kansai.kansai.oki.co.jp [10.173.5.1]) by titanic.kansai.oki.co.jp (8.9.3/3.7W) with SMTP id IAA01643; Fri, 2 Jun 2000 08:41:26 +0900 (JST) Message-ID: <004001bfcc23$3fb659a0$8d4efea9@kangaroo> From: "Shigeru Fukunaga" To: "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Stephan Wenger" References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Fri, 2 Jun 2000 08:43:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Stephan and all, Thank you for your comments. I would like to try to answer your questions. > Regarding 1) > When we discussed RFC2429, covering H.263+, we had already adopted > reference picture selection (NEWPRED), due to work of your company (OKI). > Early Internet drafts of RFC2429 suggested at least two different ways > to handle NEWPRED feedback, but were deleted from the drafts because > of scaling problems. Sure. I was one of the proponents of NEWPRED to H.263+/AnnexN. > Several people though of coming up with a 'unified feedback solution', but, > until now, nothing happened. This might be partly lack of interest, and partly > the difficulty of the problem. Consequently, when adopting your draft > unchanged, there would not be a standardized way to perform FIR and > similar in IETF environments such as SIP. The only way to respond to > packet losses, beyond responding on RTCP receiver reports, would be > to use NEWPRED. Correct me if I'm wrong here. I don't understand the correct reason why the backchannel of RTP was dropped two years ago. So we could not propose another solution for H.263+ RTP. At least I understand that backchannel over RTP got storongly objection, and many persons preferred to RTCP. Threrefore I proposed upstream RTCP for MPEG-4 case. > Regarding 3) > FIR is common to all video coding? Well, people not using compression > (BT565) will disagree. Audio folk will disagree. Motion JPEG proponents will > also disagree. I mean the video codings using inter frame coding, such as H.261/3 and MPEG-1/2/4. > On the other hand, NEWPRED is unique to MPEG-4? You > know that H.263+, available as a standard since 1998, includes NEWPRED > as well, so NEWPRED is NOT unique to MPEG-4. That' right. Only H.263 and MPEG-4 have a NEWPRED technique. > A strong argument to > include NEWPRED into a unified RTCP feedback RFC? Furthermore, there > are mechanisms like Slices out there, which are available in many, but not all, > predictive video coding standards. Are they candidates for a 'common' feedback > doc, or should they go into a RTCP section of a specific payload? This issue was discussed at Adelaid. The conclusion was that the RTCP of NEWPRED was accepted to be included in MPEG-4 RTP/RTCP doc. And if the common feedback draft will be made in the future, the specification of RTCP of NEWPRED in MPEG-4 will be considered as a base idea. > Can you please inform this group about your timing constraints? Why the rush? We would like to formally use MPEG-4 on H.323 in our products as soon as possible. As the next version of H.323 will be decided in Nov. meeting of ITU-T/SG16, we would like our proposed RTP format to be RFC before the meeting. > 2) Delete section 5 (the rest seems to be, apart from language/editorial > problems, > ok, at least to me). Work together with interested parties, including > myself, on > a unified feedback solution, in a separate RFC or a set of separate RFCs. In this case, we cannot formally use NEWPRED of MPEG-4 on H.323 for at least 2 years, until the next H.323 will be decided in 2002 or later. We would like to disagree with this case. > 3) Leave section 5 and bring it into such a shape that it can incorporate other > feedback schemes, including FIR and SLice Re-transmission at least. I'm > still working on my changes for that. FIR and re-transmission can cause new congestions, because the amount of bits is much increased during congestion. This is much against to the IETF policy of congestion control. We have to solve this issue, if you want to include FIR and re-transmission into our draft. Best Regards, Shigeru -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 From rem-conf Thu Jun 01 20:12:29 2000 From rem-conf-request@es.net Thu Jun 01 20:12:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xhc3-0000so-00; Thu, 1 Jun 2000 19:55:07 -0700 Received: from maynard.mail.mindspring.net [207.69.200.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xhc1-0000se-00; Thu, 1 Jun 2000 19:55:05 -0700 Received: from wilson (vmlabs37.vmlabs.com [204.31.130.37]) by maynard.mail.mindspring.net (8.9.3/8.8.5) with SMTP id WAA10902 for ; Thu, 1 Jun 2000 22:55:00 -0400 (EDT) Reply-To: From: "Wilson C. Chung" To: Subject: RTP MPEG1/2 Date: Thu, 1 Jun 2000 19:54:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <200006010938.KAA01698@csperkins.demon.co.uk> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is there any implementation of RTP encapsulation of MPEG1/2 streams? Tx, Wilson C. Chung, VMLabs From rem-conf Thu Jun 01 22:07:35 2000 From rem-conf-request@es.net Thu Jun 01 22:07:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xjZB-0002aw-00; Thu, 1 Jun 2000 22:00:17 -0700 Received: from (redball.dynamicsoft.com) [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xjZ9-0002aQ-00; Thu, 1 Jun 2000 22:00:15 -0700 Received: from dynamicsoft.com (1Cust178.tnt1.freehold.nj.da.uu.net [63.17.113.178]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA11178; Fri, 2 Jun 2000 00:57:06 -0400 (EDT) Message-ID: <39373E57.9EFFFB88@dynamicsoft.com> Date: Fri, 02 Jun 2000 00:55:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Adam Li CC: schulzrinne@cs.columbia.edu, "D.-S. Park" , "John D. Villasenor" , rem-conf@es.net, fanliu@icsl.ucla.edu Subject: Re: Question on RFC2733, packet-based FEC References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Adam Li wrote: > > Hi, there, > > Thanks for the discussion on this issue. I should have come to ask for > suggestions from you all earlier. But I just came back from a long > trip oversea, and am quite occupied by my other works recently. > > The scheme I proposed is actually very generic and quite simple to > implement. It doesn't make much assumption on the payload it protects, > and probably won't take much overhead to communicate the protection > range and levels. The only thing I am not sure is that if it can be > easily fit in the structure of draft-ietf-avt-fec and > draft-ietf-avt-reedsolomon. Also, it might make sense to have seperate > mechanics for complete and partial recovery of lost packet, since not > all codecs have the capability of benefiting from partial recovered > data packets. Well, there is the practical problem that draft-ietv-avt-fec has already issued as rfc2733, and cannot be changed. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Thu Jun 01 22:12:03 2000 From rem-conf-request@es.net Thu Jun 01 22:12:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xjfX-0002dJ-00; Thu, 1 Jun 2000 22:06:51 -0700 Received: from (mail.maxair.com) [63.65.250.27] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xjfS-0002d9-00; Thu, 1 Jun 2000 22:06:47 -0700 Received: from localhost (WEB498 [207.153.227.18]) by mail.maxair.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id L4ZZ6N1S; Fri, 2 Jun 2000 06:50:44 +0200 X-Mailer: Internet Mail Service [15.3.1583.81] (Solaris; Sparc10) Date: Thu, 01 Jun 2000 22:06:07 X-Accept-Language: en From: To: Subject: (ADV) - The Stocktech Express- X-References: 061903BB4, 0CC427E88 X-See-Also: 08ADBA0B1 Message-ID: Sensitivity: Restricted Content-Type: text/html X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list { ADV: The Stocktech Express}

The Stocktech Express is an independent service that sends you timely advice and solid recommendations on companies with tremendous capital gains potential. We search North America and around the globe for emerging stocks that have the potential and the e

If you would like to receive regular updates
about this company simply Click This and Send

Independence Day for Investors Coming Through Launch of Alternative Trading System (ATS) on July 4th.

Over the last 10 years, we have seen investor’s money being inefficiently stripped by traders, brokers, and other intermediaries who haven’t had the individual’s best interests at heart. As a result, this Internet technology company embarked on a mission

The Current System is Flawed from having too many intermediaries, a limited number of designated market makers, a traditional Wall Street that is inefficient and unappealing, and unfair access is given to institutional clients. As a result, one in four e

If you would like to receive regular updates
about this company simply Click This and Send

The ATS System provides alternative pools of liquidity through members trading directly with each other. It is an easy to use order entry, matching, and record-keeping system that eliminates brokers and traders, enabling transactions to be executed far m

The Many Benefits offered under the ATS system include: 1) ease of use and 24 hour/7 day real time access and execution; 2) Trading any registered security in the world without a broker; 3) Direct interaction between individual investors and institutions;

NIPHIX Alternative Listing Facility (ALF) Planned. Currently in the conceptual stage, the company is planning an Internet-based Alternative Listing Facility (ALF) in June of 2001. It will establish a new avenue of opportunity for companies in need of ca

Financing, Management, & Partners. Recently, $6.9 million in capital was raised from a private Investment Group and Management has proven experience to move quickly. This team has expertise in investment banking, conventional and online trading environm

If you would like to receive regular updates
about this company simply Click This and Send

***********************************************************************************

At Stocktech Express we appreciate your interest in reading this free newsletter and hope that you will take the opportunity to subscribe with us now. We send out well- researched, regular and timely advice on companies from here and afar, proving that it

Disclaimer:

Stocktech Express is not a Registered Investment Advisor or a Broker / Dealer. This newsletter was compiled from information provided by reliable sources. Readers are advised that this information is issued solely for information purposes and is not to be

NOTE from Delivery service:

This message is being distributed as an advertisement. The Company/Person/s sending this message are acting merely as a delivery service. NONE of the INFORMATION contained in the above message has been verified for its validity or accuracy. PLEASE ALWAYS 002 From rem-conf Thu Jun 01 23:21:28 2000 From rem-conf-request@es.net Thu Jun 01 23:21:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12xklr-0004n7-00; Thu, 1 Jun 2000 23:17:27 -0700 Received: from icsl.icsl.ucla.edu [128.97.90.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12xklo-0004mx-00; Thu, 1 Jun 2000 23:17:25 -0700 Received: from pc130 (ts47-8.wla.ts.ucla.edu [164.67.26.209]) by icsl.icsl.ucla.edu (8.8.8+Sun/8.8.8(ICSL0003)) with SMTP id XAA02953; Thu, 1 Jun 2000 23:16:43 -0700 (PDT) From: "Adam Li" To: "Adam Li" , "Jonathan Rosenberg" , Cc: "D.-S. Park" , "John D. Villasenor" , , Subject: RE: Question on RFC2733, packet-based FEC Date: Thu, 1 Jun 2000 23:17:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_01BFCC1F.83D21920" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BFCC1F.83D21920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, there, The enclosed is a file which described a proposed scheme for doing Uneven Level Protection. Please take a look if you have time, and give me your suggestions and thoughts, and also your advices on whether we should incooperate it in to the draft-ietf-avt-fec or start a seperate internet draft with it. Your help is really appreciated. Adam Li ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax) ------=_NextPart_000_0006_01BFCC1F.83D21920 Content-Type: application/msword; name="ULP.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ULP.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAJQAAAAAAAAAA EAAAJwAAAAEAAAD+////AAAAACQAAAB+AAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA+BK/AAAAAAAAEAAAAAAABAAAZSUAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIjYAADd8AAA3fAAATiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAN4BAAAAAAAA3gEAAN4B AAAAAAAA3gEAAAAAAADeAQAAAAAAAN4BAAAAAAAA3gEAABQAAAAAAAAAAAAAAPIBAAAAAAAA8gYA AAAAAADyBgAAAAAAAPIGAAAAAAAA8gYAABQAAAAGBwAAHAAAAPIBAAAAAAAAiBQAAP4AAAAuBwAA OgAAAGgHAAAAAAAAaAcAAAAAAABoBwAAAAAAAGgHAAAAAAAAaAcAAFYBAAC+CAAAdAAAADIJAAA8 AAAA7xMAAAIAAADxEwAAAAAAAPETAAAAAAAA8RMAAAAAAADxEwAAAAAAAPETAAAAAAAA8RMAACQA AACGFQAAIAIAAKYXAADaAAAAFRQAAC0AAAAAAAAAAAAAAAAAAAAAAAAA3gEAAAAAAABuCQAAAAAA AAAAAAAAAAAAAAAAAAAAAABoBwAAAAAAAGgHAAAAAAAAbgkAAAAAAABuCQAAAAAAABUUAAAAAAAA KgoAAAAAAADeAQAAAAAAAN4BAAAAAAAAaAcAAAAAAAAAAAAAAAAAAGgHAAAAAAAAQhQAABYAAAAq CgAAAAAAACoKAAAAAAAAKgoAAAAAAABuCQAAUgAAAN4BAAAAAAAAaAcAAAAAAADeAQAAAAAAAGgH AAAAAAAA7xMAAAAAAAAAAAAAAAAAACoKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAbgkAAAAAAADvEwAAAAAAACoKAACYBAAAKgoAAAAAAADCDgAA VgAAAGcTAABAAAAA3gEAAAAAAADeAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4xMAAAAAAABoBwAAAAAAACIHAAAMAAAAALlh2FbM vwHyAQAAAAUAAPIGAAAAAAAAwAkAAGoAAACnEwAADAAAAAAAAAAAAAAA4xMAAAwAAABYFAAAMAAA AIgUAAAAAAAAsxMAADAAAACAGAAAAAAAACoKAAAAAAAAgBgAAAAAAADjEwAAAAAAACoKAAAAAAAA 8gEAAAAAAADyAQAAAAAAAN4BAAAAAAAA3gEAAAAAAADeAQAAAAAAAN4BAAAAAAAAAgDZAAAADUEg Z2VuZXJpYyBVbmV2ZW4gTGV2ZWwgUHJvdGVjdGlvbiAoVUxQKSBwcm9wb3NhbA1BZGFtIEguIExp DUltYWdlIENvbW11bmljYXRpb24gTGFiDUVsZWN0cmljYWwgRW5naW5lZXJpbmcgRGVwYXJ0bWVu dA1Vbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEsIExvcyBBbmdlbGVzDUxvcyBBbmdlbGVzLCBDQSA5 MDA5NSwgVVNBDQ1CYWNrZ3JvdW5kDQ1JbiBwYWNrZXQtc3dpdGNoZWQgbmV0d29ya3MsIHRoZSBk b21pbmFudCBlcnJvciBwYXR0ZXJuIGlzIHBhY2tldCBsb3NzLiBHZW5lcmFsbHksIHRoZSBkYXRh IGxpbmsgbGF5ZXIgd2lsbCBkaXNjYXJkIHRoZSBwYWNrZXRzIHRoYXQgZGlkIG5vdCBwYXNzIHRo ZSBpbnRlZ3JpdHkgY2hlY2suIEluIGdlbmVyYWwsIHRoZXJlIGFyZSB0d28gd2F5cyB0byByZWNv dmVyIGxvc3QgcGFja2V0OiByZXRyYW5zbWlzc2lvbiBvciBmb3J3YXJkIGVycm9yIGNvcnJlY3Rp b24gKEZFQykuIEJlY2F1c2Ugb2YgcmVhbCB0aW1lIG5hdHVyZSBvZiBtYW55IGFwcGxpY2F0aW9u cywgaXQgaGFzIHN0cmljdCBkZWxheSByZXF1aXJlbWVudCB0aGFuIGEgcHVyZSBkYXRhIHRyYW5z bWlzc2lvbi4gQXMgYSByZXN1bHQsIHJldHJhbnNtaXNzaW9uIG9mIHRoZSBsb3N0IHBhY2tldHMg aXMgZ2VuZXJhbGx5IG5vdCBhIHZhbGlkIG9wdGlvbi4gU28gdGhlIGJldHRlciB3YXkgdG8gYXR0 ZW1wdCB0byByZWNvdmVyIGluZm9ybWF0aW9uIGFib3V0IGEgbG9zdCBwYWNrZXQgaW4gdGhpcyBj YXNlIGlzIEZFQy4gSGVyZSwgdGhlIGVycm9yIGNvcnJlY3Rpb24gaGFzIHRvIGJlIG9uIHRoZSBw YWNrZXQgbGV2ZWwsIGJlY2F1c2UgYW55IGNvcnJlY3Rpb24gd2l0aGluIHRoZSBwYWNrZXQgd2ls bCBiZSB1c2VsZXNzIGlmIHRoZSB3aG9sZSBwYWNrZXQgaXMgbG9zdC4gDQ1UaGUgYmFzaWMgd2F5 IHRvIGRvIGVycm9yIGNvcnJlY3Rpb24gaXMgdG8gc2VuZCByZWR1bmRhbnQgaW5mb3JtYXRpb24g YWxvbmcgd2l0aCB0aGUgZGF0YSB0aGF0IG5lZWRzIHRvIGJlIHRyYW5zbWl0dGVkIChpbiBzZXBh cmF0ZWQgcGFja2V0cyBvciBldmVuIGluIHNlcGFyYXRlIGNoYW5uZWwpLCBhbmQgdG8gcmVwYWly IHRoZSBkYXRhIGZyb20gdGhlIHJlZHVuZGFuY2llcyBpbiBjYXNlIHNvbWUgcGFja2V0IGlzIGxv c3QgaW4gdHJhbnNtaXNzaW9uLiBDdXJyZW50bHkgUlRQIEZFQyBpcyBiZWluZyBkaXNjdXNzZWQg aW4gSUVURiBjb21tdW5pdHkuIFRoZXJlIGFyZSB0d28gSW50ZXJuZXQgRHJhZnRzIGluIElFVEYg QVZUIGdyb3VwIG5vdy4gVGhlIG1ldGhvZCBpcyB0byBzZW5kIHJlZHVuZGFudCBwYWNrZXRzIGZv ciBhIGdyb3VwIG9mIGRhdGEsIGFzIHNob3duIGJlbG93IChmb3IgdmlkZW8gZGF0YSkuIEZvciB0 aGUgc2ltcGxpY2l0eSwgWE9SIChFeGNsdXNpdmUgT1IpIGlzIHVzZWQgaGVyZSB0byBpbGx1c3Ry YXRlIHRoZSBzdHJ1Y3R1cmUgWzFdLiBIb3dldmVyLCBnZW5lcmFsaXppbmcgaXQgaW50byBvdGhl ciBhbGdvcml0aG1zIChzdWNoIGFzIFJlZWQtU29sb21vbikgaXMgc3RyYWlnaHRmb3J3YXJkIFsy XS4NEyBFTUJFRCBQb3dlclBvaW50LlNsaWRlLjggIBQBFQ1JbiB0aGUgKE4gPSA1KSBjYXNlIGls bHVzdHJhdGVkIGluIEZpZy4gMSwgYSBGRUMgcGFja2V0LCB3aGljaCBpcyB0aGUgWE9SIG9mIHBy ZXZpb3VzIGZpdmUgcGFja2V0cyAoemVyby1wYWRkZWQgdG8gdGhlIGxhcmdlc3QgYW1vbmcgdGhl IGZpdmUgaW4gWE9SIG9wZXJhdGlvbiksIGlzIHNlbnQgYWZ0ZXIgdGhlIGZpdmUgZGF0YSBwYWNr ZXRzLiBJZiBhbnkgb25lIG9mIHRoZSA1IHBhY2tldHMgaXMgbG9zdCwgd2UgY2FuIHN0aWxsIHJl Y292ZXIgaXQgZnJvbSB0aGUgRkVDIHBhY2tldCBhbmQgdGhlIG90aGVyIDQuICBUaGUgc21hbGxl ciB0aGUgTiBpcywgdGhlIGdyZWF0ZXIgcHJvdGVjdGlvbiBpdCBicmluZ3MuDQ1Ib3dldmVyLCBm b3IgbWFueSBhcHBsaWNhdGlvbnMsIGVzcGVjaWFsbHkgaW4gbW9iaWxlIGVudmlyb25tZW50LCB0 aGUgYmFuZHdpZHRoIGlzIHVzdWFsbHkgc2NhcmNlLiBWaWRlbyBwYWNrZXRzIHVzdWFsbHkgdmFy eSBncmVhdGx5IGluIGxlbmd0aCBiZXR3ZWVuIElOVFJBIGFuZCBJTlRFUiBmcmFtZXMsIGFuZCBi ZXR3ZWVuIHNjZW5lcyBvZiBkaWZmZXJlbnQgY29udGVudCBhbmQgbW92ZW1lbnQuIFplcm8tcGFk ZGluZyB0byB0aGUgbGVuZ3RoIG9mIHRoZSBsb25nZXN0IHBhY2tldCBjYW4gYmUgYSBncmVhdCB3 YXN0ZSBvZiBiYW5kd2lkdGggcmVzb3VyY2UgYW5kIGlzIHZlcnkgaW5lZmZpY2llbnQuDVByaW5j aXBsZSBvZiB0aGUgcHJvcG9zYWwNDUluIG1hbnkgY2FzZXMgZm9yIG11bHRpbWVkaWEgc3RyZWFt cywgd2UgaGF2ZSBzb21lIHZlcnkgaW1wb3J0YW50IGtub3dsZWRnZSBhYm91dCB0aGUgc3RyZWFt LiBJbiBnZW5lcmFsLCB0aGUgbW9yZSBpbXBvcnRhbnQgcGFydHMgb2YgdGhlIGRhdGEgYXJlIGFs d2F5cyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBkYXRhIHBhY2tldC4gVGhpcyBpcyB0aGUgY29t bW9uIHByYWN0aWNlIGZvciBtb3N0IGNvZGVjcywgc2luY2UgdGhlIGJlZ2lubmluZyBvZiB0aGUg cGFja2V0IGlzIGNsb3NlciB0byB0aGUgcmUtc3luY2hyb25pemF0aW9uIG1hcmtlciBhdCB0aGUg aGVhZGVyIGFuZCB0aHVzIGlzIG1vcmUgbGlrZWx5IHRvIGJlIGNvcnJlY3RpdmVseSBkZWNvZGVk IGlmIHRoZSBkYXRhIGlzIHZhcmlhYmxlIGxlbmd0aCBjb2RlZC4NDUluIElUVS1UIEguMjYzKysg YW5kIE1QRUctNCBWaXN1YWwgU2ltcGxlIFByb2ZpbGUsIGJvdGggYXJlIHRoZSBtb3N0IGNvbW1v biB2aWRlbyBwYXlsb2FkIHR5cGVzIGZvciBILjMyMywgd2Uga25vdyB3aGVyZSB0aGUgbW9yZSBp bXBvcnRhbnQgZGF0YSBpcyBhdCB3aGVuIHRoZSBkYXRhIHBhcnRpdGlvbmluZyBzY2hlbWUgaXMg aW52b2tlZC4gSW4gYm90aCBzdGFuZGFyZHMsIHZpZGVvIG1hY3JvYmxvY2sgKE1CKSBoZWFkZXJz IGFuZCBtb3Rpb24gdmVjdG9ycyBhcmUgdHJhbnNtaXR0ZWQgaW4gdGhlIHBhcnRpdGlvbiBhdCB0 aGUgYmVnaW5uaW5nIG9mIHRoZSB2aWRlbyBwYWNrZXQgd2hpbGUgRENUIGNvZWZmaWNpZW50cyBh cmUgdHJhbnNtaXR0ZWQgaW4gdGhlIHBhcnRpdGlvbiBjbG9zZSB0byB0aGUgZW5kIG9mIHRoZSBw YWNrZXQuIEJlY2F1c2UgdGhlIGRhdGEgaXMgYXJyYW5nZWQgaW4gdGhlIG9yZGVyIG9mIG1vcmUg aW1wb3J0YW50IGRhdGEgdG8gbGVzcyBpbXBvcnRhbnQgZGF0YSwgaXQgaXMgcG9zc2libGUgdG8g cHJvdmlkZSBtb3JlIHByb3RlY3Rpb24gdG8gdGhlIGJlZ2lubmluZyBwYXJ0IG9mIHRoZSBwYWNr ZXQuDQ1JbiBjYXNlIG9mIGF1ZGlvIHN0cmVhbSwgdGhlcmUgYXJlIGFsc28gbWFueSBhcHBsaWNh dGlvbnMuIE1hbnkgbm93IGF1ZGlvIGNvZGVjcyBkbyBlbmNvZGUgaW50byBiaXRzdHJlYW0gZGF0 YSBvZiBkaWZmZXJlbnQgaW1wb3J0YW5jZSwgd2hpY2ggaXMgc2ltaWxhciB0byB0aGUgdmlkZW8g c2NoZW1lIG1lbnRpb25lZCBhYm92ZS4gRXZlbiBmb3IgdW5pZm9ybSBzaWduaWZpY2FuY2UgYXVk aW8gc3RyZWFtLCBzcGVjaWFsIHRlY2huaXF1ZXMgY2FuIGJlIHVzZWQgdG8gc3RyZXRjaCB0aGUg cmVjb3ZlcmVkIHBhcnRpYWwgYXVkaW8gZGF0YS4gQWxzbywgaWYgdGhlcmUgaXMgYXVkaW8gcmVk dW5kYW5jeSBjb2RpbmcsIGl0IG1ha2VzIHNlbnNlIHRvIGhhdmUgbW9yZSBwcm90ZWN0aW9uIGFw cGxpZWQgdG8gdGhlIG9yaWdpbmFsIGRhdGEsIHdoaWxlIHdpdGggbm8gcHJvdGVjdGlvbnMgZm9y IHRoZSByZWR1bmRhbnQgY29waWVzLg0NU28gdGhlIGFwcGxpY2F0aW9uIHNob3VsZCBiZW5lZml0 IGZyb20gdW5lcXVhbCBlcnJvciBwcm90ZWN0aW9ucyBzY2hlbWUgd2l0aCBtb3JlIGVtcGhhc2lz IG9uIHRoZSBiZWdpbm5pbmcgcGFydCBvZiB0aGUgcGFja2V0cy4gRmlndXJlIDIgc2hvd3MgYW4g ZXhhbXBsZSB0byBpbGx1c3RyYXRlIHRoZSBzY2hlbWUuIFRoZSBkYXRhIG9mIGxlbmd0aCBMIGlu IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHBhY2tldHMgYXJlIHByb3RlY3RlZCB3aXRoIHRoZSBleHRy YSBGRUMgcGFja2V0LCB3aGljaCBpcyB0aGUgWE9SIHJlc3VsdCBvZiBhbGwgdGhlIHByb3RlY3Rl ZCBwYXJ0IG9mIHRoZSBwYWNrZXRzLiANEyBFTUJFRCBQb3dlclBvaW50LlNsaWRlLjggIBQBFQ1C eSBhZGp1c3RpbmcgdmFsdWUgb2YgTiBhbmQgTCwgdGhlIHByb3RlY3Rpb24gbGV2ZWwgZm9yIHRo ZSBkYXRhIG9mIGxlbmd0aCBMIGNhbiBiZSBhZGp1c3RlZC4gV2l0aCBhIGNhcmVmdWxseSBzZWxl Y3RlZCBOIGFuZCBMIHZhbHVlLCB0aGUgYmFuZHdpZHRoIGlzIG1vcmUgZWZmZWN0aXZlbHkgdXRp bGl6ZWQgdG8gcHJvdGVjdCB0aGUgbW9yZSBpbXBvcnRhbnQgcGFydHMgb2YgdGhlIGRhdGEsIGFu ZCB6ZXJvLXBhZGRpbmcgd2lsbCBiZSByYXJlbHkgbmVlZGVkLiBUaGUgZGV0ZXJtaW5hdGlvbiBv ZiBwcm9wZXIgTiBhbmQgTCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRoaXMgcHJvcG9zYWwuIFRo ZXNlIHBhcmFtZXRlcnMgaW4gdGhlIHNjaGVtZSBzaG91bGQgYmUgbGVmdCB0byBiZSBkZXRlcm1p bmVkIGJ5IHVzZXJzIGZvciBzcGVjaWZpYyB0cmFuc21pc3Npb24gY2hhbm5lbCBhbmQgc3BlY2lm aWMgdmlkZW8gY29udGVudC4gRm9yIGNoYW5uZWxzIHdpdGggaGlnaGVyIGVycm9yIHJhdGUsIHRo ZSBOIHZhbHVlIHNob3VsZCBiZSBjaG9zZW4gc21hbGxlciB0byBnaXZlIGhpZ2hlciBsZXZlbCBw cm90ZWN0aW9ucy4gQWxzbywgdGhlIEwgc2hvdWxkIGJlIGNob3NlbiBzbyB0aGF0IHRoZSBpbXBv cnRhbnQgcG9ydGlvbiBvZiBkYXRhIGlzIGNvdmVyZWQgaW4gbW9zdCBvZiB0aGUgY2FzZXMgKGFu ZCB0aHVzIHdpbGwgYmUgZGlmZmVyZW50IGZyb20gc3RyZWFtIHRvIHN0cmVhbSkuIFRoZSBpbnRl bGxpZ2VudCBjaG9pY2UgZm9yIHRoZXNlIHZhbHVlcyBmb3IgdGhlIG1vc3QgZWZmaWNpZW50IHV0 aWxpemF0aW9uIG9mIHRoZSBiYW5kd2lkdGggZm9yIHRoZSBwcm90ZWN0aW9uIHNob3VsZCBiZSBs ZWZ0IGZvciBlYWNoIGluZGl2aWR1YWwgYXBwbGljYXRpb24uIA1UaGUgYWR2YW50YWdlIG9mIFVM UCBGRUM/DQ1CZXNpZGVzIHRoZSBhZHZhbnRhZ2Ugb2YgYWNoaWV2aW5nIG1vcmUgZWZmaWNpZW50 IHVzYWdlIG9mIGJhbmR3aWR0aCBieSBwcm92aWRpbmcgdW5lcXVhbCBlcnJvciBwcm90ZWN0aW9u IHRvIG1vcmUgaW1wb3J0YW50IGRhdGEgb2YgdGhlIHN0cmVhbSwgdGhlIFVMUCBGRUMgYWxzbyBo YXZlIHRoZSBmb2xsb3dpbmcgbWFqb3IgYWR2YW50YWdlczoNDU9uZSBvZiB0aGUgbWFqb3IgYWR2 YW50YWdlcyBvZiB0aGUgVUxQIEZFQyBzY2hlbWUgaXMgdGhhdCBpdCBpcyBjb21wbGV0ZWx5IGdl bmVyaWMuIEl0IGlzIHRvdGFsbHkgdHJhbnNwYXJlbnQgdG8gdGhlIGNvZGVjcywgYW5kIGl0IGRv ZXMgbm90IHJlcXVpcmUgbG9va2luZyBpbnRvIHRoZSBwYWNrZXRzIHJlY2VpdmVkIGZyb20gdGhl IGNvZGVjcyAod2hpY2ggd2lsbCByZXF1aXJlIEguMzIzIHVuZGVyc3RhbmQgdGhlIGZvcm1hdCBv ZiBkYXRhIHN0cmVhbSwgYW5kIGl0IG5vdCBnZW5lcmljKS4gVGhlcmUgaXMgYWxzbyBubyBuZWVk IHRvIGJyZWFrIGFwYXJ0IGFuZCByZWFzc2VtYmxlIHRoZSBkYXRhIHBhY2tldHMuIEV2ZXJ5IHBh Y2tldCBpcyB0cmVhdGVkIGFzIGEgd2hvbGUgdW5pdC4gDQ1Bbm90aGVyIG1ham9yIGFkdmFudGFn ZSBpcyB0aGF0IGl0IGhhcyBubyBpbXBhY3QgYXQgYWxsIG9uIHRoZSBsb3dlciBsYXllcnMgKGUu Zy4sIGRhdGEgbGluayBsYXllciwgcGh5c2ljYWwgbGF5ZXIpLiBUaGUgRkVDIHBhY2tldHMgYXJl IGp1c3QgdHJhbnNtaXR0ZWQgYW5kIGhhbmRsZWQgdGhlIHNhbWUgd2F5IGFzIHRoZSBvdGhlciBk YXRhIHBhY2tldHMuIFRoZSBsb3dlciBsYXllcnMgbmVlZCBub3QgdG8ga25vdyB0aGUgZGlmZmVy ZW5jZSBiZXR3ZWVuIHRoZW0uDQ1UaGUgdGhpcmQgbWFqb3IgYWR2YW50YWdlIGlzIHRoZSBncmVh dCBjb21wYXRpYmlsaXR5IHdpdGggdGhlIHRlcm1pbmFscyB0aGF0IGRvIG5vdCBzdXBwb3J0IFVM UCBGRUMgc2NoZW1lLiBTdWNoIHRlcm1pbmFscyBjYW4gc2ltcGx5IGlnbm9yZSB0aGUgRkVDIHBh Y2tldHMgYW5kIHBsYXkgYmFjayB0aGUgZGF0YSBwYWNrZXRzIHRoZSBzYW1lIHdheSBhcyBubyBl eHRyYSBwcm90ZWN0aW9uLiBBbHNvLCBhdCB0aGUgd2lyZWxlc3MgbmV0d29yayB0byBmaXhlZC1s aW5lIG5ldHdvcmsgYm91bmRhcnksIHRoZSBnYXRld2F5IGNhbiBlYXNpbHkgYW5kIHZlcnkgZWZm aWNpZW50bHkgdHJhbnNsYXRlIGluIGJldHdlZW4sIGFzICgxKSB0aGUgZml4ZWQtbGluZSBuZXR3 b3JrIGRvZXMgbm90IHRoZSBleHRyYSBwcm90ZWN0aW9uIHRvIHNhdmUgdGhlIGJhbmR3aWR0aCwg YW5kICgyKSBtb3N0IGZpeGVkLWxpbmUgdGVybWluYWxzIHByb2JhYmx5IGRvIG5vdCBzdXBwb3J0 IFVMUCBGRUMgc2NoZW1lLiANDUFsc28sIHRoZSBwcm9wb3NlZCBzY2hlbWUgaXMgZWFzeSBhbmQg ZmFzdCB0byBpbXBsZW1lbnQuIEZvciBleGFtcGxlIGluIHRoZSBtdWx0aWNhc3Qgc2NlbmFyaW8s IHRoZSBNQ1UgY2FuIGVhc2lseSBhcHBseSB0aGlzIHRvIHRoZSBsaW5rcyB0aGF0IGdvIHRocm91 Z2ggd2lyZWxlc3MgY29ubmVjdGlvbiB3aXRob3V0IGluY3VyIG11Y2ggY29tcGxleGl0eSBvdmVy aGVhZCBhbmQgcHJvY2Vzc2luZyBkZWxheS4gDVByb3Bvc2FsDQ1XZSBwcm9wb3NlIHRoZSBmb2xs b3dpbmcgc2NoZW1lOg0NVGhlIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBzaWRlcyBzaG91bGQgdXNl IGRhdGEgcGFydGl0aW9uaW5nIG9wdGlvbiBmb3IgdGhlIHZpZGVvIGNvZGVjLiBBbHNvLCB0aGUg c2VuZGluZyBhbmQgcmVjZWl2aW5nIHNpZGVzIHdvdWxkIG5lZ290aWF0ZSBhIHNldCBvZiBwcm90 ZWN0aW9uIGxldmVscyBOaSAoSSA9IDEsIDIsIIUpIGFuZCBjb3JyZXNwb25kaW5nIHByb3RlY3Rp b24gbGVuZ3RoIExpICh0aGUgdXNhZ2UgaXMgaWxsdXN0cmF0ZWQgYmVsb3cpLiBBbnkgTmkgc2hv dWxkIGJlIGludGVncmFsIG11bHRpcGxlIG9mIE5pLTEuIA0NRHVyaW5nIHRyYW5zbWlzc2lvbiwg YWZ0ZXIgZWFjaCBOaSBwYWNrZXRzLCB0aGUgRkVDIHBhY2tldCBjb3JyZXNwb25kaW5nIHRvIHRo ZSBYT1IgcmVzdWx0IG9mIHRoZSBwcm90ZWN0ZWQgTGkgbGVuZ3RoIGRhdGEgaW4gdGhlIHByZXZp b3VzIE5pIHBhY2tldHMgd2lsbCBiZSBzZW50IGFmdGVyLiAoTm90ZTogU2luY2UgTmkgaXMgaW50 ZWdyYWwgbXVsdGlwbGUgb2YgTmktMSwgZm9yIGVhY2ggbGV2ZWwtaSBGRUMgZGF0YSBzZW50LCB0 aGVyZSBpcyBsZXZlbC1pLTEgRkVDIGRhdGEgc2VudCByaWdodCBpbiBmcm9udCBvZiBpdC4gU28g ZWFjaCBGRUMgcGFja2V0IHdpbGwgYWx3YXlzIHN0YXJ0IHdpdGggbGV2ZWwtMSBkYXRhLikNEyBF TUJFRCBQb3dlclBvaW50LlNsaWRlLjggIBQBFQ1BcyBtZW50aW9uZWQgYmVmb3JlLCBYT1IgaXMg anVzdCB1c2VkIHRvIGlsbHVzdHJhdGUgdGhlIHNjaGVtZS4gV2UgY2FuIGVhc2lseSBleHRlbmQg dGhlIGFsZ29yaXRobSBpbiBSZWVkLVNvbG9tb24gY29kZSB0byBzZW5kIE1pIEZFQyBibG9ja3Mg Zm9yIHRoZSBOaSBwcm90ZWN0ZWQgY29kZS4gSW4gdGhpcyBjYXNlLCB3ZSBhbHNvIG5lZWQgdG8g cmVxdWlyZSB0aGF0IE1pIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAs/Ag8E0AaQAtADEAIAAoAGkA bgAgAGEAZABkAGkAdABpAG8AbgBhAGwAIAB0AG8AIAB0AGgAZQAgAHIAZQBxAHUAaQByAGUAbQBl AG4AdAAgAHQAaABhAHQAIABOAGkAIABzAGgAbwB1AGwAZAAgAGIAZQAgAGkAbgB0AGUAZwByAGEA bAAgAG0AdQBsAHQAaQBwAGwAZQAgAG8AZgAgAE4AaQAtADEAIABpAG4AIAB0AGgAZQAgAFgATwBS ACAAYwBhAHMAZQApAC4AIAANAA0AQwBvAG4AYwBsAHUAcwBpAG8AbgANAA0AVABoAGUAIABwAHIA bwBwAG8AcwBlAGQAIABVAG4AZQB2AGUAbgAtAEwAZQB2AGUAbAAgAFAAcgBvAHQAZQBjAHQAaQBv AG4AIABwAHIAbwB2AGkAZABlAHMAIABhACAAdwBhAHkAIAB0AG8AIABtAG8AcgBlACAAZQBmAGYA aQBjAGkAZQBuAHQAbAB5ACAAdQB0AGkAbABpAHoAZQAgAHQAaABlACAAYwBoAGEAbgBuAGUAbAAg AGMAYQBwAGEAYwBpAHQAeQAgAGYAbwByACAAYgBlAHQAdABlAHIAIABwAHIAbwB0AGUAYwB0AGkA bwBuACAAbwBmACAAdABoAGUAIABtAHUAbAB0AGkAbQBlAGQAaQBhIHRyYW5zbWlzc2lvbi4gVGhp cyBzY2hlbWUgc2hvdWxkIGdyZWF0bHkgaW1wcm92ZSB0aGUgdHJhbnNtaXNzaW9uIG9mIG11bHRp bWVkaWEgY29udGVudCBvdmVyIGVycm9yLXByb25lIGNoYW5uZWxzLiANDVJlZmVyZW5jZQ0NWzFd IElFVEYgSW50ZXJuZXQgRHJhZnQgLSBBbiBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIEdlbmVyaWMg Rm9yd2FyZCBFcnJvciBDb3JyZWN0aW9uLCBKLiBSb3NlbmJlcmcsIGFuZCBILiBTY2h1bHpyaW5u ZS4NWzJdIElFVEYgSW50ZXJuZXQgRHJhZnQgLSBBbiBSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIFJl ZWQgU29sb21vbiBDb2RlcywgSi4gUm9zZW5iZXJnLCBhbmQgSC4gU2NodWx6cmlubmUuDQ0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAQQAADIEAAA9BAAAuQQAAOYE AADvBAAArAYAALcGAAC/BgAA0wYAAIYHAACHBwAACQoAAAoKAAAlCgAAJgoAACgKAAD2CgAA+goA AMsSAADMEgAAIxQAACQUAAA/FAAAQBQAAEEUAABCFAAA7BgAAO4YAAADHwAABB8AADgfAAA5HwAA YR8AAGIfAACDHwAAhh8AAKsfAACsHwAA9x8AAPgfAAAWIAAAFyAAAEIgAABDIAAAXSAAAGAgAADy IAAA8yAAAA4hAAAPIQAAECEAABEhAADlIQAA5iEAAOchAADoIQAAACIAAAQiAAD79enfANkA2QDZ ANkA1ADG1ADZANkA1AC4s9QA2QCxALEAsQCxALEAsQCxALEAsQDUAKOe1ACcALEAlgALT0oBAFFK AQBoCAADaAgACQNq2B4AAFUIARoDano4ETwKCAFVCAFWCAFtSAAEbkgABHUIAQADSCoCCQNqhAUA AFUIARoDarM6ETwKCAFVCAFWCAFtSAAEbkgABHUIAQAaA2pY8BA8CggBVQgBVggBbUgABG5IAAR1 CAEACQNqAAAAAFUIAQtuSBEEbygBdEgRBBI1CIE2CIFPSgAAUUoAAGFKGAAAFjUIgTYIgUNKIABP SgAAUUoAAGFKGAAACjUIgUNKJABcCIEACG1ICQRzSAkEOwAEAAABBAAAMgQAAD0EAABVBAAAdwQA AJ0EAAC4BAAAuQQAAMQEAADFBAAAhQcAAIYHAAAJCgAAKQoAAIoLAACLCwAA5gwAAAANAAABDQAA 9AAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAAM8AAAAA AAAAAAAAAADPAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAAM8AAAAAAAAAAAAAAADGAAAAAAAAAAAA AAAAxAAAAAAAAAAAAAAAAMQAAAAAAAAAAAAAAADEAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAALAA AAAAAAAAAAAAAACwAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAK4AAAAAAAAAAAAAAACpAAAAAAAA AAAAAAAAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQIACiYAC0YDAAABEQAACwAADcYRAAWm/wAA aAF2AjgEAAAAAAAIEQANxgoEpv9oAXYCOAQAAAEAAAkCAAomAAtGAwATpAAAFKQAAAAIAgADJAET pAAAFKQAAGEkAQAGAgADJAEUpPAAYSQBABQPAAMkAQ3GBQABoAUAD4SgBRGEYPoTpHgAFKTgAV6E oAVghGD6YSQBAAoPAA3GBwEHGgGKBUATpHgAFKR4AAATAAQAAGUlAAD+AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQEBDQAAoQ4AAKIOAADxEAAA8hAAAMwSAADN EgAAIxQAAEMUAADBFwAA2xcAANwXAACjGAAApBgAADAaAAAxGgAAPhsAAD8bAAA+HQAAPx0AACwe AAA1HgAANh4AAFceAABYHgAAiR8AAIofAADyIAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA AAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA AAAAAADsAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA 8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAAAAAAAAAAAAAABQIACiYAC0YD AAALAAANxhEABab/AABoAXYCOAQAAAAAAAABEQAAG/IgAAASIQAA0CIAANIiAADoIgAA6iIAAHYk AAB3JAAAgSQAAIIkAAD6JAAAZCUAAGUlAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADuAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADsAAAAAAAAAAAA AAAA5wAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAANwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAgAAA3GCwAD0ALgELgaAAAAAAESAAUAAAomAAtGAwAAAQAABQIACiYA C0YDAAALAAANxhEABab/AABoAXYCOAQAAAAAAAAMBCIAAAYiAAAMIgAAXiIAAGAiAACiIgAAqCIA AHckAACCJAAAhSQAAPokAAD9JAAAZSUAAAD9AP0A/QD18QDxAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG NQiBXAiBAA41CIE2CIFPSgIAUUoCAAADSCoCAAwgADGQaAEfsNAvILDgPSGwCAcisAgHI5CgBSSQ oAUlsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQFAABEAGQAAAAAAAAAAgAAAAAAAAAAAAAAAADZ F98R6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8EIAAACyBArwCAAAAAEE AAAACgAAUwAL8B4AAAAEQQEAAAA/AQAABgCBAREAABC/AQwAHwD/AQAACAAAABDwBAAAAAAAAIAy AAfw7gQAAAMEGEtrVbX5SqDxv7rxThWPpP8AygQAAAEAAABEAAAAAADXAGAhG/DCBAAAGEtrVbX5 SqDxv7rxThWPpPgNAAAAAAAAAAAAAIoJAAAmBwAA6Cc7AHBULACQBAAAAP54nLVXYUidVRh+33PO 992rOVzMuTELdBNj5Zy7c1EMq7Um0ZZKW39CiBXX0DJDzVo/FgnBUGz7ERFGtPajpMVgjjbN63az TInI1YW1DUTY4ib+CJF+TdGec77v3vt9pkvz+sHD+c5z3vOc57zn3HO+y5RBJGdtogBdJ/3cCxTZ 2bSZ5vEQrafE047QogDpHiYiaCIEaptcZpthFOXRkcrq6hwamaJS3TMH+GNTq6uT6UZnmigiQX9L v6ZELdtlckyUoixiMOxqWMA9IvGWJYoC7RkKb4rXYSZEs2gz9kmzO9hxfUdYprdu2eq2sC/ifruA pqg4cEpXki1+jWRCkhrCZEm7zXWzdgn1E8jqJUQrGAq67bZpZ1qH+oxHKTU1R1GaeWXoCOM5RyTa xCKj7ZfOaM/ai492N61UtmqTo6vkTKVjSiRmapn4PDXI9YEK7lDeDE2hXyIfTt36n+ph8ac1uWbq QXnZ6hRrpX5W3giWyrVSr1IzVmwF6vTz/ArUp9WNYKv6b/WF++83bLhixI+jLLAS43HKhWdnO2o2 1LJQFkpFY8EQxwxe4DEgxb8NTuM0+NMe/jI4jTj4uIdXImZQLMaAFP8MOI0m8E0e/hQ4jV7wvR7+ GjiNOfBzHv4+GTN4So4BKf4lcBrt4Ns9fDc4javgr3r4v8Bp5KoxIMWXqZhBDfgaD/8OOI0z4M94 +Cg4jQnwEx7etmIGW6wxwMk3+1ZRr+7CU8JZLfatluVbyzzVy8dlOW8T/pNRLHrCbCR9xp2bd/Qi yX1wpK4h3JxfGX4r/7nGhqOvE912VGx3fy199pXwZvfcYtqAMpT5Me8Veh7VR19+NdySvytE26mQ dgB5GH+724uTp523/PfswqJNTvIDy5rd8j0eEI97PYZW5zEo22SnSLfHCb/H3avzeBYeS2W6PXZI n8ey1XmsUm0ylnaPJcrncc/qPE6rWdmq0ucx13j8FR4zUx4rDuz3uwzRw7R3hU4L7Y1Wt3VFpjeb 0v5d6mxW1L3yZlNY/7pz4bQEPgvxXbh0NhfeT3Vw9ARgY6x9KnU/LbyR9BdwoaynOT7Ic7yPp/hJ vsUVPM5Pc4wreYSf5yi/yH1cx73cwBf4GPfw+8B74jx/IL7mLpRd4hx/JL7kz8Vn/JX4kHvECe4V HdwPXBTH+VvRiHeN13hA1HMU5feoD6HtR8T8BAyhzwj6/gKNa9Aah+YktOMYI45yWvTwPHBHXuAA TuUNqo9zVZQL1Ag/qGIcUuP8iLrFj6opLldz/BhQhvfd4HYCZSrOu9RNfkiN8jY1zFvQN1sNQGcQ GIBmBNoRjNGPsS5izG/4NjxcF1/wqPiEh8VJ/g4+o/AcceczJJoxjxZwzZhXI0pnTj+YuJN8Bf36 0P88dLqh9yl0uwz6kbsIchhBLgeQ00HkdgCI8hs8zLU8yjV8E7mPcxXW4yBQjbU5xMu92ZY6SQ9z p6ildO3ZbPckfddEV+aX5+/B7yiHdt51r/r3ovNtNSPWG4+JW5OF2Hr4WHNLuCH1/8C5K+1F/id5 H///Kn23O99+/wB5AMrNVBkAAEQAZAAAAAAAAAACAAAAAAAAAAAAAAAAANkX3xHoA+gDAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwQgAAALIECvAIAAAAAgQAAAAKAABTAAvwHgAA AARBAgAAAD8BAAAGAIEBEQAAEL8BDAAfAP8BAAAIAAAAEPAEAAAAAQAAgDIAB/C+GAAAAwSccbLX q7KTHvXtvi4rc1Si/wCaGAAAAQAAAMgFAAAAANcAYCEb8JIYAACccbLXq7KTHvXtvi4rc1Sivm8A AAAAAAAAAAAAigkAACYHAADoJzsAcFQsAGAYAAAA/nictZ0PlFZVucbP2d/+ZgTjGl0oSioSDlkX /yAq1pE0KCnMych/eKOgBr1oXFFJ0VDxSIpNOigGR1S6cBWTKyQRKMpgY7IculSUJCTeMykpSwlF MiwwvO/zzOyZdzin3SmItX5rmHd/v/3s75sR5jycccKgWxBUWocGQW2wOcCvnsLAmsOCPsHb8isI 3hm4X9+Whw6sDWDwEYfwEUbee0/7pD8nNjg8OKvuzDN7BS07g2Nh9hJ+954r2vfp3v7o7nxUEJjg jUrXPSvy3mHtk158lA3eEYQyCdv3qAqHGve7d5iBtd/uZuV3NuwhzyQI3pI1Hj/A9Kiw7dR7TJU2 Vo5oXwm7POL9NR8KdgaDamfhnY6Vrnt0vCAdexi+Sjjtu9tftYfl/Zk18lYebeVAh7Sv13A9DHrI +3vVTp1PrW3HCp9XNzyCZ+5l3JopSBtRaUs7o6Y47e/Z6zpZeJec5Ruyz73h/nsFHa9a26vsPh5t U8u3tfLWfQz27ZvQsVqVj2EQDKjYoMF+IJxN0rBBcHPM5pGUa26O2UKScs3NMVtMUq651L/8pTO1 hm93qnQYy0hK080xW0VSrrk5Zs0k5ZpLeest/dzaUmo6UmC0kJRmp1XvORuMDSSl6ay9e+s9WTA2 kZSmm2PWSlKuud327PGdAcY2ktJ0c8xeJSnX3G5//vPXPGeDsZukNJ31pz99zXMGGPtIStPNMatW Qco1t9ubb/rOAKMHSWk6a/fur3rOAKM3SWk6649//KonC0ZfktJ0c8wGkJRrbrc33hjvOQOMQSSl 6axdu8Z7zgBjCElpdlrjPFkwYpLSdNbrr4/zZMEYTlKaznrtta94smCMIilNZ7366lc8WTBGk5Sm s3bs+LInC8YYktJ01u9//2VPFozxJKXprFdeGevJgjGRpDSd9fLLYz1ZMCaTlKaztm37kicLxlSS 0nTWSy99yZMFYzpJaTrrxRf/3ZMF4yaS0nTW1q3ne7JgNJKUprOef/58TxaMuSSl6azf/naMJwvG fJLSdFaWnefJgrGIpDSd9dxz53qyYCwlKU1nPfvsuZ4sGCtIStNZmzef48mC0URSms7atOlsTxaM J0lK01kbN57tyYKxnqQ0nfWrX53lyYKxkaQ0nbVhwxc9WTC2kJSms37+89GeLBhbSUrTWevXf8GT BWM7SWk666c/PdOTBWMXSWk666mnPu/JgrGHpDSdtXZtnScLhqkBKU1nPfHEGZ4sGN1IStNZzc1n eLJg9CQpTWetWfM5TxaM95KUprMee+x0TxaMfiSl6axHHx3lyYJxJElpOuvhhz/ryYJxLElpOutH P/qMJwvGUJLSdNby5SM9WTBOISlNZz300GmeLBinkZSms5Yu/bQnC0YdSWk668EHP+XJgnEOSWk6 64EHRniyYIwlKU1n3X//CE8WjAkkpems++4b7smCMYmkNJ21cOGpniwYU0hK01kLFpzqyYIxjaQ0 nTV//imeLBgzSErTWXff/QlPFowGktJ01rx5wzxZMGaTlKaz0vRkTxaMu0hK01lz5sSeLBgLSUrT WXfcEXuyYCwmKU1n3X77xz1ZMJaRlKazZs36mCcLxiqS0nTWrbee5MmC0UxSms665ZaTPFkwWkhK 01kNDUM9WTA2kJSms26++URPFozNJKXprJkzT/RkwWglKU1n3XjjCZ4sGNtIStNZM2Yc78mC8RpJ aTrrhhuO92TB2E1Sms5KkiGeLBj7SErTWdOnD/FkwaipBSlNN8esB0m55na79trjPGeA0ZukNJ11 zTXHec4A4/0kpemsadMGe7JgDCApTWd985uDPVkwBpGUZsdVnsyGkJRrbrerrz7WcwYYMUlpOuuq q471nAHGCJLSdNbUqb4sGKNIStNZV155jCcLxmiS0uy4jpPZ+STlmtvtiiuO8ZwBxniS0uy4UpPZ RJJyrc23Hadpe9+0v23bvzYMc92a6wTRWeLXEV1OclR7F3a4vTO8SNIarN63Myff2RX1civkcbuq QTDS/PVeTj+PMk1cc9hIYtMgdFyDyex2EptGNcdsDonN7WqO2Z0kNlgr18TBuIfE5k61G2YLSGzu UXPM7iWxWaBS/E0cjO+T2Nzbxar3nA3GgyQ231eWv4mD8QMSmwfVyTFbTmLzA7Wbv4mDsZLEZrna DbNHSWxWqt38TRyMNSQ2jyrL38TBaCaxWaPOgNlaEptmtZu/iYPRQmKzVln+Jg7GehKbFmX5mzgY G0hs1ivL37jBeJrEZoN6vphtIrF5Wu3mb+JgbCGx2aQs3akVXOWKkZHYbFFnwOwFEptM7aa7tvwZ YLxIYvOCsnTXlj8DjJdJbF5Ulu7a8lkwdpDYvKws3bXls2DsJLHZoazt231ZMN4gsdmpLN215bNg vEli84aydNeWz4Kxl8TmTWXpri2fBeNtEpu9ytJdWz4LhqmC2LytLN215bNg1JDYwCzq2vJZMLqT 2NQoS3dt+SwYPUhsuitLd20FX2mJ0ZPEpoeynnvO19DB6EVi01NZumvLZ8HoQ2LTS1m6a8tnwehL YtNHWc8842vNYHyQxKavsnTXls+C0Z/E5oPK0l1bPgvGQBKb/srSXVs+C8ZHSWwGKkt3bfksGEeT 2HxUWbpry2fBGExic7SydNeWz4JxAonNYGXpri2fBeMkEpsTlKW7tnwWjJNJbE5Slu7a8lkwTiWx OVlZumvLZ8EYQWJzqrJ015bPgjGSxGaEsnTXls+CcTqJzUhl6a4tnwWjjsTmdGXprq2gXRJjNIlN nbJWrPiMJwvG2SQ2o5Wlu7Z8FowxJDZnK0t3bfksGGNJbMYoa8mST3uyYIwjsRmrLN215bNg1JPY jFOW7tryWTAuJLGpV5bu2vJZMC4msblQWbpry2fBuITE5mJl6a4tnwXjMhKbS5Slu7Z8FowrSGwu U5bu2vJZMK4msblCWbpry2fBuIbE5mpl3XnnME8WjOtJbK5Rlu7a8lkwZpDYXK8s3bUVtIFizCSx maGs2bN9DR2M75DYzFSW7tryWTAaSWy+oyzdteWzYMwmcq2nrMZGX0MHYw6JzWxl6a4tnwVjHpHr RGXpri2fBWM+ic08Zd18s6+hg7GAxGa+snTXls+CcR+Ra0xl6a4tnwXjARKb+5Slu7Z8FowHSWwe UJbu2gquMcV4iMg1prJ015bPgrGcxOYhZV1/va+hg/EwkStQZfkbOhiPkdg8rCx/EwdjDYkNzI4r UJk9QeQKVO2mu7b8GWCsJbF5QlkBAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAD+////HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAAI8AAAD9////JgAA ACkAAAD+////KgAAAD0AAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAPgAAADMAAAA0AAAA NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAD+////PwAAAGAAAABTAAAAQQAAAEIAAABD AAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEA AABSAAAA/v///2EAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAA AP7///9iAAAAYwAAAI4AAAClAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAA bgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8 AAAAfQAAAP7////9////gAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8gAAAABgkCAAAAAADAAAAAAAAA RgAAAAAAAAAAAAAAAAC5YdhWzL8BKAAAAAAdAAAAAAAARABhAHQAYQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAAA9jsAAAAAAABXAG8AcgBkAEQA bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC AR8AAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiNgAA AAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAWAAEBIgAAAP////8WAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgXi/YVsy/AQC5 YdhWzL8BAAAAAAAAAAAAAAAAXwAxADAAMAA3ADcANAAzADAANgA0AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAQD//////////wgAAAARjYFkm0/PEYbqAKoAuSno AAAAAGBeL9hWzL8BYF4v2FbMvwEAAAAAAAAAAAAAAAABAE8AbABlAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUAAAAAAAAAAEAQwBvAG0AcABP AGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA BQAAAAcAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAHUAAAAA AAAAAwBPAGIAagBJAG4AZgBvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAADAAAABAAAAAAAAAD+////AgAAAP7////+/////v///wYAAAAHAAAACAAAAAkAAAAKAAAA CwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZ AAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcA AAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAA ADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAP7///9DAAAA RAAAAEUAAABGAAAARwAAAEgAAABJAAAA/v////7///9MAAAA/v////7////+////UAAAAFEAAABS AAAAUwAAAFQAAABVAAAAVgAAAP7////+////WQAAAP7////+/////v///10AAABeAAAAXwAAAGAA AABhAAAAYgAAAGMAAAD+////ZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAP7///9tAAAAbgAA AG8AAABwAAAAcQAAAP7///9zAAAA/v////////////////////////////////////////////// /////////////////////wEAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8RjYFkm0/PEYbqAKoAuSnoGwAAAE1p Y3Jvc29mdCBQb3dlclBvaW50IFNsaWRlAA8AAABNU1ByZXNlbnRhdGlvbgATAAAAUG93ZXJQb2lu dC5TbGlkZS44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPHAAAABQAAABf wJHjyRQAAAQA9AMDAGIAQWRhbQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQK AgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA2A4AAAsAAAABAAAAYAAA AAIAAABoAAAABAAAAIAAAAAIAAAAkAAAAAkAAACgAAAAEgAAAKwAAAAKAAAAzAAAAAwAAADYAAAA DQAAAOQAAAAPAAAA8AAAABEAAAD4AAAAAgAAAOQEAAAeAAAADwAAAE5vIFNsaWRlIFRpdGxlAAAe AAAABQAAAEFkYW0AaWRlUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEGAAAACgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD+////AAAAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf///////////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAkAAAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIACQAA AAsAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQAAAAgPAAAAAAAA UABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACgAAgH/////DAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAyAAAA7RQAAAAAAAAeAAAABQAAAEFkYW0AaWRlHgAAAAIAAAA3AGFtHgAAABUAAABNaWNyb3Nv ZnQgUG93ZXJQb2ludAAAUABAAAAAIBsnIwIAAABAAAAAQBIl1StOvwFAAAAAgAZx2R1QvwEDAAAA EAAAAEcAAADYDQAA/////wMAAAAIAG8QTQwAAAEACQAAA+QGAAAHAMwAAAAAABEAAAAmBg8AGAD/ ////AAAQAAAAAAAAAAAAugMAAMoCAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQA GwBUTlBQFADI8AAwAAAAABQAAADkF3YAAAAAAAAACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYP AAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwC ygK6AwQAAAAEAQ0ABwAAAPwCAAD///8AAAAEAAAALQEAAAkAAAD6AgUAAAAAAP///wAiAAQAAAAt AQEABAAAAC0BAAAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEAAAQAAAAtAQAACQAAAPoCAAAAAAAA AAAAACIABAAAAC0BAgAQAAAAJgYPABYA/////wAARwAAAI8CAAARAQAAwQIAAAgAAAAmBg8ABgD/ ////AQANAAAA+wIAAAAAAAAAAAAAAAAAAQAAAAAAAAQAAAAtAQMABQAAAAkCAAAAAgUAAAAUAgAA AAAEAAAAAgECABAAAAAmBg8AFgD/////AABHAQAAjwIAAHkCAADBAgAACAAAACYGDwAGAP////8B AAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAAIBAgAHAAAA/AIAAP//ZgAAAAQAAAAtAQQACQAAAPoC AAABAAAAAAAAAiIABAAAAC0BBQAHAAAAGwSxAOkCgADIAQQAAAAtAQAABAAAAPABBAAEAAAALQEC AAQAAADwAQUABwAAAPwCAAD//2YAAAAEAAAALQEEAAkAAAD6AgAAAQAAAAAAAAIiAAQAAAAtAQUA BwAAABsE8QBRAsAAyAEEAAAALQEAAAQAAADwAQQABAAAAC0BAgAEAAAA8AEFAAcAAAD8AgAA//9m AAAABAAAAC0BBAAJAAAA+gIAAAEAAAAAAAACIgAEAAAALQEFAAcAAAAbBDEBQQIAAcgBBAAAAC0B AAAEAAAA8AEEAAQAAAAtAQIABAAAAPABBQAHAAAA/AIAAP//ZgAAAAQAAAAtAQQACQAAAPoCAAAB AAAAAAAAAiIABAAAAC0BBQAHAAAAGwRxAXkDQAHIAQQAAAAtAQAABAAAAPABBAAEAAAALQECAAQA AADwAQUABwAAAPwCAAD//2YAAAAEAAAALQEEAAkAAAD6AgAAAQAAAAAAAAIiAAQAAAAtAQUABwAA ABsEsQFZAoAByAEEAAAALQEAAAQAAADwAQQABAAAAC0BAgAEAAAA8AEFAAcAAAD8AgAAAMz/AAAA BAAAAC0BBAAJAAAA+gIAAAEAAAAAAAACIgAEAAAALQEFAAcAAAAbBPEBeQPAAcgBBAAAAC0BAAAE AAAA8AEEAAQAAAAtAQIABAAAAPABBQAQAAAAJgYPABYA/////wAAdQMAAHUAAAB8AwAABAIAAAQA AAAtAQEABwAAAPwCAAAAAAAAAAAEAAAALQEEAAQAAAAGAQIADAAAACQDBAB6A3gAdgN4AHYDiAB6 A4gADAAAACQDBAB6A5QAdgOUAHYDpAB6A6QADAAAACQDBAB6A7AAdgOwAHYDwAB6A8AADAAAACQD BAB6A8wAdgPMAHYD3AB6A9wADAAAACQDBAB6A+gAdgPoAHYD+AB6A/gADAAAACQDBAB6AwQBdgME AXYDFAF6AxQBDAAAACQDBAB6AyABdgMgAXYDMAF6AzABDAAAACQDBAB6AzwBdgM8AXYDTAF6A0wB DAAAACQDBAB6A1gBdgNYAXYDaAF6A2gBDAAAACQDBAB6A3QBdgN0AXYDhAF6A4QBDAAAACQDBAB6 A5ABdgOQAXYDoAF6A6ABDAAAACQDBAB6A6wBdgOsAXYDvAF6A7wBDAAAACQDBAB6A8gBdgPIAXYD 2AF6A9gBDAAAACQDBAB6A+QBdgPkAXYD9AF6A/QBBAAAAAYBAQAEAAAALQECAAQAAAAtAQAACAAA ACYGDwAGAP////8BAAcAAAD8AgEAAAAAAAAABAAAAC0BBQAEAAAALQEBAAcAAAAbBK0AXwF8ANYA BAAAAC0BAAAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAAFQAAAPsC4P8AAAAAAAC8AgAAAAAA AAAAVGltZXMgTmV3IFJvbWFuAAC7BAAAAC0BBgAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAA BAAAAC4BGAAEAAAAAgEBABMAAAAyCqAA4AAIAAAAUGFja2V0IDEUABAADgASAA4ACgAIABAABAAA AC4BAQAEAAAAAgECAAQAAAACAQIABAAAAC0BBQAEAAAALQEBAAcAAAAbBPEAYQHAANgABAAAAC0B AAAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEY AAQAAAACAQEAEwAAADIK5ADiAAgAAABQYWNrZXQgMhQAEAAOABIADgAKAAgAEAAEAAAALgEBAAQA AAACAQIABAAAAAIBAgAEAAAALQEFAAQAAAAtAQEABwAAABsEMQFhAQAB2AAEAAAALQEAAAQAAAAt AQIABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIB AQATAAAAMgokAeIACAAAAFBhY2tldCAzFAAQAA4AEgAOAAoACAAQAAQAAAAuAQEABAAAAAIBAgAE AAAAAgECAAQAAAAtAQUABAAAAC0BAQAHAAAAGwRxAWEBQAHYAAQAAAAtAQAABAAAAC0BAgAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABMAAAAy CmQB4gAIAAAAUGFja2V0IDQUABAADgASAA4ACgAIABAABAAAAC4BAQAEAAAAAgECAAQAAAACAQIA BAAAAC0BBQAEAAAALQEBAAcAAAAbBLEBYQGAAdgABAAAAC0BAAAEAAAALQECAAUAAAAJAgAAAAIF AAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAEwAAADIKpAHiAAgA AABQYWNrZXQgNRQAEAAOABIADgAKAAgAEAAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEF AAQAAAAtAQEABwAAABsE8QGRAcAB2AAEAAAALQEAAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAWAAAAMgrkAeIACgAAAFBhY2tl dCBGRUMUABAADgASAA4ACgAIABQAFQAXAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQAAAAtAQUA BAAAAC0BAQAHAAAAGwRpAv8BOAJ4AQQAAAAtAQAABAAAAC0BAgAFAAAACQIAAAACBQAAABQCAAAA AAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABMAAAAyClwCggEIAAAARmlndXJl IDEUAAgAEAASAA4ADwAIABAABAAAAC4BAQAEAAAAAgECAAQAAAACAQIAEAAAACYGDwAWAP////8A AI0AAAB9AAAAzQAAAK0BAAAEAAAALQEBAAQAAAAtAQQABAAAAAYBAgDMAAAAJANkAMgAggDIAH4A wgB/AL0AgAC8AIAAswCGAK0AjgCsAI8AqwCTAKoAmQCqAPsAqQAAAagABAGqAAUBqAADAaIACwGZ ABEBmwASAZoAEAGVABIBkAASAZAAEgGPABMBjgAUAY4AFAGPABUBkAAWAZAAFgGVABcBmgAYAZsA FgGZABcBogAdAagAJQGqACMBqAAkAakAKAGrACgBqQAnAaoALQGqAI8BqwCUAasAlQGsAJkBrQCa AbMAogG8AKgBvQCoAcIAqgHIAKoByACmAcMApgG+AKQBvQCmAb8ApQG2AJ8BsACXAa4AmQGwAJgB rwCUAa0AlAGvAJUBrgCPAa4ALQGtACgBrQAnAa0AJwGsACMBqwAiAaUAGgGcABQBmwAUAZYAEwGQ ABIBkAAWAZEAFQGSABQBkgAUAZEAEwGQABIBkAAUAZAAFgGWABYBmwAUAZwAFAGlAA4BqwAGAawA BQGtAAEBrgD7AK4AmQCvAJQAsACQAK4AjwCwAJEAtgCJAL8AgwC9AIIAvgCEAMMAgwAEAAAABgEB AAQAAAAtAQIABAAAAC0BAAAIAAAAJgYPAAYA/////wEABAAAAC0BBQAEAAAALQEBAAcAAAAbBDEB hgAAASgABAAAAC0BAAAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAU AgAAAAAEAAAALgEYAAQAAAACAQEADwAAADIKJAEyAAUAAABOID0gNQAXAAgAEgAIABAABAAAAC4B AQAEAAAAAgECAAQAAAACAQIABAAAAC0BAQAEAAAALQEFABAAAAD7AhAABwAAAAAAvAIAAAAAAQIC IlN5c3RlbQAABAAAAC0BAwAEAAAA8AEGAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkA AAAmBg8ACAD/////AQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQ k5cIACss+a4wAAAAsAEAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAtAAAAAYAAAC8 AAAABwAAAMQAAAAIAAAAzAAAAAkAAADUAAAACgAAANwAAAAXAAAA5AAAAAsAAADsAAAAEAAAAPQA AAATAAAA/AAAABYAAAAEAQAADQAAAAwBAAAMAAAATgEAAAIAAADkBAAAHgAAAA8AAABPbi1zY3Jl ZW4gU2hvdwAAHgAAAAIAAAAgAC1zAwAAAO0UAAADAAAACAAAAAMAAAABAAAAAwAAAAAAAAADAAAA AAAAAAMAAAAAAAAAAwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAD AAAAEAAAAFRpbWVzIE5ldyBSb21hbgAPAAAARGVmYXVsdCBEZXNpZ24ADwAAAE5vIFNsaWRlIFRp dGxlAAwQDwDoA+cCAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAARAAAAKAAAAAAAAAAAAAAAAQAA AAAAAAEPAPID8AAAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB0wAAAAAALcPRAAAAFQAaQBtAGUA cwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA/NJiAPzSYgAIz2IA+NMDMCzPYgAIAAAALM9iAH7UAzAA AAQAAACpDwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAA AABAAgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSEAAAADwAA8HwAAAAAAAbwIAAAAAIMAAADAAAA FwAAAAIAAAABAAAABwAAAAIAAAAUAAAAYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/ AQgACAABAgIAAAggABrxCAAAAADM/wD//2YAQAAe8RAAAAD//2YAAQAACAIAAAj3AAAQHwDwDxwA AAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQB4sAAAAfAP8DFAAAAAIAAAQMAAAAAAAA AAAAAAACAAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAKgAAAGQAAAAqAAAAZAAAADjPYgB+ 1AMwMM9iAAgAAACQCQAALAcAAPT////0////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEA AABACwAAPwDZDwwAAAAAANoPBAAAAAAAJQAPAPAPWAAAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEA AAAAAAAAAJ8PBAAAAAYAAAAAAKoPCgAAAAEAAAABAAAAAAAQAJ8PBAAAAAUAAAAAAKoPCgAAAAEA AAABAAAAAAAAAOoDAAAAAA8A+AN1CAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAABTBg APAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAYADwByAAAAAAAP8A////AAAA AAD//wAA/5kAAAD//wD/AAAAlpaWAGAA8AcgAAAA///MAAAAAABmZjMAgIAAADOZMwCAAAAAADPM AP/MZgBgAPAHIAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICAAE1NTQDq6uoAYADwByAAAAD///8A AAAAAICAgAAAAAAA/8xmAAAA/wDMAMwAwMDAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAMDAwAAA Zv8A/wAAAACZAABgAPAHIAAAAP///wAAAAAAgICAAAAAAAAzmf8Amf/MAMwAzACysrIAAACjDz4A AAABAP/9PwAAACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAD///////8s AAAAAAMAABAAow98AAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAAAgAAAP// 7wAAAAAA////////IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAAT IPADYAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4A AAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJA AgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEA AQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCA BAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIA GAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAAC ABgAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBNME AAAPAALwywQAABAACPAIAAAABgAAAAYEAAAPAAPwYwQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAA AAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAA fwABAAEAgAB0LnYAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ 8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQDNAA8ADfBUAAAAAACfDwQAAAAAAAAA AACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACq DwoAAAAhAAAAAQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEAAQCAANQo dgCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAOAEsAHQFAAPDwAR 8BAAAAAAAMMLCAAAAAEAAAACAM0ADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRv IGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGgg bGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAA qg8KAAAAUwAAAAEAAAAAAA8ABPC1AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAEAgAB0 KHYAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaAEA8A EfAQAAAAAADDCwgAAAACAAAABwHNAA8ADfA9AAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxQA AAACAAAAAAAAAAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPC3AAAAEgAK8AgAAAAFBAAAAAoA AIMAC/AwAAAAfwABAAEAgAAUKHYAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAI AAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQLNAA8ADfA/AAAAAACfDwQAAAAE AAAAAACoDwEAAAAqAAChDxYAAAACAAAAAAAACAAAAQACAAAAAAACAA4AAAD6DwQAAAAAAAAADwAE 8LcAAAASAArwCAAAAAYEAAAACgAAgwAL8DAAAAB/AAEAAQCAALQndgCBAQQAAAiDAQAAAAi/AQEA EQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPIBDQFIAQDwAR8BAAAAAAAMMLCAAAAAQAAAAI As0ADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAA AAIADgAAANgPBAAAAAAAAAAPAATwSAAAABIACvAIAAAAAQQAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACA gIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4DPQkAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAA AAAHAAUwDwAMBO0IAAAPAALw5QgAACAACPAIAAAAEQAAABMIAAAPAAPwfQgAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPBSAAAAEgAK8AgAAAAECAAA AAoAAHMAC/AqAAAAhQACAAAAhwABAAAAgQH//2YAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ 8AgAAAAAA7AKcBEgBA8ABPBSAAAAEgAK8AgAAAAFCAAAAAoAAHMAC/AqAAAAhQACAAAAhwABAAAA gQH//2YAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACABLAK4A2gBQ8ABPBSAAAAEgAK 8AgAAAAGCAAAAAoAAHMAC/AqAAAAhQACAAAAhwABAAAAgQH//2YAvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIAAAQ8AgAAAAABrAKgA0gBw8ABPBSAAAAEgAK8AgAAAAHCAAAAAoAAHMAC/AqAAAAhQAC AAAAhwABAAAAgQH//2YAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACAB7AK0BSgCA8A BPBSAAAAEgAK8AgAAAAICAAAAAoAAHMAC/AqAAAAhQACAAAAhwABAAAAgQH//2YAvwEQABAAwAEB AAAI/wEIAAgAAQICAAAIAAAQ8AgAAAAACbAKEA4gCg8ABPBSAAAAEgAK8AgAAAAJCAAAAAoAAHMA C/AqAAAAhQACAAAAhwABAAAAgQEAzP8AvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACA CrAK0BSgCw8ABPBkAAAAQgEK8AgAAAAKCAAAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAARAEEAAAA fwEAAAEAvwEAABAAwAEBAAAIywHUlAAAzgEGAAAA/wEYABgAAQICAAAIAAAQ8AgAAADQAtAU0BQA DA8ABPCkAAAAogwK8AgAAAALCAAAAAoAAKMAC/A8AAAAgAD0JnYAhQACAAAAhwAGAAAAvwACAAIA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADqAgYFNAgKBA8ADfA4 AAAAAACfDwQAAAAEAAAAAACoDwgAAABQYWNrZXQgMQAAoQ8UAAAACQAAAAAAAAAAAAkAAAABAAAA AQAPAATwpAAAAKIMCvAIAAAADAgAAAAKAACjAAvwPAAAAIAAFCV2AIUAAgAAAIcABgAAAL8AAgAC AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAgAQQBT4IoAUPAA3w OAAAAAAAnw8EAAAABAAAAAAAqA8IAAAAUGFja2V0IDIAAKEPFAAAAAkAAAAAAAAAAAAJAAAAAQAA AAEADwAE8KQAAACiDArwCAAAAA0IAAAACgAAowAL8DwAAACAABQudgCFAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAAAGEAU+CCAHDwAN 8DgAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAFBhY2tldCAzAAChDxQAAAAJAAAAAAAAAAAACQAAAAEA AAABAA8ABPCkAAAAogwK8AgAAAAOCAAAAAoAAKMAC/A8AAAAgABULXYAhQACAAAAhwAGAAAAvwAC AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACABxAFPgigCA8A DfA4AAAAAACfDwQAAAAEAAAAAACoDwgAAABQYWNrZXQgNAAAoQ8UAAAACQAAAAAAAAAAAAkAAAAB AAAAAQAPAATwpAAAAKIMCvAIAAAADwgAAAAKAACjAAvwPAAAAIAAlCx2AIUAAgAAAIcABgAAAL8A AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAAAkQBT4IIAoP AA3wOAAAAAAAnw8EAAAABAAAAAAAqA8IAAAAUGFja2V0IDUAAKEPFAAAAAkAAAAAAAAAAAAJAAAA AQAAAAEADwAE8KYAAACiDArwCAAAABAIAAAACgAAowAL8DwAAACAANQrdgCFAAIAAACHAAYAAAC/ AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAIAKEAVeCaAL DwAN8DoAAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAFBhY2tldCBGRUMAAKEPFAAAAAsAAAAAAAAAAAAL AAAAAQAAAAEADwAE8KQAAACiDArwCAAAABEIAAAACgAAowAL8DwAAACAABQrdgCFAAIAAACHAAYA AAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAFAN0Ajz C3AODwAN8DgAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAEZpZ3VyZSAxAAChDxQAAAAJAAAAAAAAAAAA CQAAAAEAAAABAA8ABPBeAAAAcgUK8AgAAAASCAAAAAoAAJMAC/A2AAAAhQACAAAAhwABAAAAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAIywHUlAAA/wEIAAgAAQICAAAIAAAQ8AgAAAAAA2ADsATwCQ8A BPChAAAAogwK8AgAAAATCAAAAAoAAKMAC/A8AAAAgAC0KnYAhQACAAAAhwAGAAAAvwACAAIAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAABvAAHAMgBw8ADfA1AAAA AACfDwQAAAAEAAAAAACoDwUAAABOID0gNQAAoQ8UAAAABgAAAAAAAAAAAAYAAAABAAAAAQAPAATw SAAAABIACvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKy sgAAAHIXEAAAAAEAMAAAAAAA7wIAAGwLAAAAAPUPHAAAAAAAAACDFQADAAAAALEUAAABAAAAAwAA AAAACTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUARABv AGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAA4AAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQgAA AOABAAAAAAAAXwAxADAAMAA3ADcANgAyADAAOQA5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABgAAQD//////////xEAAAARjYFkm0/PEYbqAKoAuSnoAAAAAGBeL9hW zL8BYF4v2FbMvwEAAAAAAAAAAAAAAAABAE8AbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEoAAAAUAAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIADgAAABAAAAD/ ////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASwAAAHUAAAAAAAAAAAAGAAAA HgAAAAsAAABGb250cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEA AAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////EY2BZJtPzxGG6gCqALkp6BsAAABNaWNyb3NvZnQg UG93ZXJQb2ludCBTbGlkZQAPAAAATVNQcmVzZW50YXRpb24AEwAAAFBvd2VyUG9pbnQuU2xpZGUu OAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DxwAAAAUAAAAX8CR4+IWAAAE APQDAwBiAEFkYW0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAA AAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAALABAAAQAAAAAQAAAIgAAAADAE8AYgBq AEkAbgBmAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE0AAAAE AAAAAAAAAFAAaQBjAHQAdQByAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAASAAIBDwAAABMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/v///wAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgH///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABOAAAAJAAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACABIAAAAUAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAABEJAAAAAAAAP7/AAAECgIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAABQkAAALAAAAAQAAAGAAAAAC AAAAaAAAAAQAAACAAAAACAAAAJAAAAAJAAAAoAAAABIAAACsAAAACgAAAMwAAAAMAAAA2AAAAA0A AADkAAAADwAAAPAAAAARAAAA+AAAAAIAAADkBAAAHgAAAA8AAABObyBTbGlkZSBUaXRsZQAAHgAA AAUAAABBZGFtAGlkZR4AAAAFAAAAQWRhbQBpZGUeAAAAAwAAADEwAG0eAAAAFQAAAE1pY3Jvc29m dCBQb3dlclBvaW50AABQAEAAAADA4SyIJgAAAEAAAABAEiXVK06/AUAAAADg+ikxSlC/AQMAAAAR AAAARwAAABIjAAD/////AwAAAAgAbxBNDAAAAQAJAAADgREAAAcAzAAAAAAAEQAAACYGDwAYAP// //8AABAAAAAAAAAAAAC6AwAAygIAAAkAAAAmBg8ACAD/////AgAAABcAAAAmBg8AIwD/////BAAb AFROUFAUAMjwADAAAAAAFAAAAOQXdgAAAAAAAAAKAAAAJgYPAAoAVE5QUAAAAgD0AwkAAAAmBg8A CAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAMAAEAAAABAAAAAAAAAAUAAAALAgAAAAAFAAAADALK AroDBAAAAAQBDQAHAAAA/AIAAP///wAAAAQAAAAtAQAACQAAAPoCBQAAAAAA////ACIABAAAAC0B AQAEAAAALQEAAAkAAAAdBiEA8ADQAsADAAAAAAQAAAAtAQAABAAAAC0BAAAJAAAA+gIAAAAAAAAA AAAAIgAEAAAALQECABAAAAAmBg8AFgD/////AABHAAAAjwIAABEBAADBAgAACAAAACYGDwAGAP// //8BAA0AAAD7AgAAAAAAAAAAAAAAAAABAAAAAAAABAAAAC0BAwAFAAAACQIAAAACBQAAABQCAAAA AAQAAAACAQIAEAAAACYGDwAWAP////8AAEcBAACPAgAAeQIAAMECAAAIAAAAJgYPAAYA/////wEA BQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAAAgECABAAAAAmBg8AFgD/////AADEAQAAbAAAAOwCAACk AAAACAAAACYGDwAGAP////8AAAQAAAAtAQEABwAAAPwCAQAAAAAAAAAEAAAALQEEAAQAAAAHAQQA BwAAAPwCAAD+/mUAAAAEAAAALQEFAAwAAAAkAwQAyAFwANoBcADaAaAAyAGgAAcAAAD8AgAA+/tk AAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQA2gFwAOwBcADsAaAA2gGgAAcAAAD8AgAA+PhjAAAA BAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQA7AFwAP4BcAD+AaAA7AGgAAcAAAD8AgAA8/NhAAAABAAA AC0BBgAEAAAA8AEFAAwAAAAkAwQA/gFwABACcAAQAqAA/gGgAAcAAAD8AgAA7OxeAAAABAAAAC0B BQAEAAAA8AEGAAwAAAAkAwQAEAJwACICcAAiAqAAEAKgAAcAAAD8AgAA4+NbAAAABAAAAC0BBgAE AAAA8AEFAAwAAAAkAwQAIgJwADQCcAA0AqAAIgKgAAcAAAD8AgAA2dlWAAAABAAAAC0BBQAEAAAA 8AEGAAwAAAAkAwQANAJwAEYCcABGAqAANAKgAAcAAAD8AgAAzMxRAAAABAAAAC0BBgAEAAAA8AEF AAwAAAAkAwQARgJwAFgCcABYAqAARgKgAAcAAAD8AgAAv79MAAAABAAAAC0BBQAEAAAA8AEGAAwA AAAkAwQAWAJwAGoCcABqAqAAWAKgAAcAAAD8AgAAsbFGAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAk AwQAagJwAHwCcAB8AqAAagKgAAcAAAD8AgAAo6NBAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQA fAJwAI4CcACOAqAAfAKgAAcAAAD8AgAAlpY8AAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAjgJw AKACcACgAqAAjgKgAAcAAAD8AgAAi4s3AAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAoAJwALIC cACyAqAAoAKgAAcAAAD8AgAAgoI0AAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAsgJwAMQCcADE AqAAsgKgAAcAAAD8AgAAfHwxAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAxAJwANYCcADWAqAA xAKgAAcAAAD8AgAAd3cvAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQA1gJwAOgCcADoAqAA1gKg AAQAAAAtAQQABAAAAPABBgAEAAAALQECAAQAAAAtAQAABAAAAAcBAQAIAAAAJgYPAAYA/////wEA CQAAAPoCAAABAAAAAAAAACIABAAAAC0BBQAEAAAALQEEAAcAAAAbBKEA6QJwAMgBBAAAAC0BAgAE AAAA8AEFAAQAAAAtAQAACAAAACYGDwAGAP////8BABAAAAAmBg8AFgD/////AADEAQAArAAAAFQC AADkAAAACAAAACYGDwAGAP////8AAAQAAAAtAQEABAAAAC0BBAAEAAAABwEEAAcAAAD8AgAA/v5l AAAABAAAAC0BBQAMAAAAJAMEAMgBsADQAbAA0AHgAMgB4AAHAAAA/AIAAPz8ZAAAAAQAAAAtAQYA BAAAAPABBQAMAAAAJAMEANABsADZAbAA2QHgANAB4AAHAAAA/AIAAPj4YwAAAAQAAAAtAQUABAAA APABBgAMAAAAJAMEANkBsADhAbAA4QHgANkB4AAHAAAA/AIAAPPzYQAAAAQAAAAtAQYABAAAAPAB BQAMAAAAJAMEAOEBsADqAbAA6gHgAOEB4AAHAAAA/AIAAO3tXgAAAAQAAAAtAQUABAAAAPABBgAM AAAAJAMEAOoBsADyAbAA8gHgAOoB4AAHAAAA/AIAAOTkWwAAAAQAAAAtAQYABAAAAPABBQAMAAAA JAMEAPIBsAD7AbAA+wHgAPIB4AAHAAAA/AIAANnZVwAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAME APsBsAADArAAAwLgAPsB4AAHAAAA/AIAAM3NUgAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAAMC sAAMArAADALgAAMC4AAHAAAA/AIAAMDATAAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAAwCsAAU ArAAFALgAAwC4AAHAAAA/AIAALKyRwAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEABQCsAAdArAA HQLgABQC4AAHAAAA/AIAAKSkQQAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAB0CsAAlArAAJQLg AB0C4AAHAAAA/AIAAJeXPAAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEACUCsAAuArAALgLgACUC 4AAHAAAA/AIAAIyMOAAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAC4CsAA2ArAANgLgAC4C4AAH AAAA/AIAAIODNAAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEADYCsAA/ArAAPwLgADYC4AAHAAAA /AIAAHx8MQAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAD8CsABHArAARwLgAD8C4AAHAAAA/AIA AHd3LwAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAEcCsABQArAAUALgAEcC4AAEAAAALQEEAAQA AADwAQYABAAAAC0BAgAEAAAALQEAAAQAAAAHAQEACAAAACYGDwAGAP////8BAAkAAAD6AgAAAQAA AAAAAAAiAAQAAAAtAQUABAAAAC0BBAAHAAAAGwThAFECsADIAQQAAAAtAQIABAAAAPABBQAEAAAA LQEAAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA/////wAAxAEAAOwAAABEAgAAJAEAAAgAAAAm Bg8ABgD/////AAAEAAAALQEBAAQAAAAtAQQABAAAAAcBBAAHAAAA/AIAAP7+ZQAAAAQAAAAtAQUA DAAAACQDBADIAfAAzwHwAM8BIAHIASABBwAAAPwCAAD8/GQAAAAEAAAALQEGAAQAAADwAQUADAAA ACQDBADPAfAA1wHwANcBIAHPASABBwAAAPwCAAD4+GMAAAAEAAAALQEFAAQAAADwAQYADAAAACQD BADXAfAA3gHwAN4BIAHXASABBwAAAPwCAADz82EAAAAEAAAALQEGAAQAAADwAQUADAAAACQDBADe AfAA5gHwAOYBIAHeASABBwAAAPwCAADt7V4AAAAEAAAALQEFAAQAAADwAQYADAAAACQDBADmAfAA 7QHwAO0BIAHmASABBwAAAPwCAADk5FsAAAAEAAAALQEGAAQAAADwAQUADAAAACQDBADtAfAA9QHw APUBIAHtASABBwAAAPwCAADZ2VcAAAAEAAAALQEFAAQAAADwAQYADAAAACQDBAD1AfAA/AHwAPwB IAH1ASABBwAAAPwCAADNzVIAAAAEAAAALQEGAAQAAADwAQUADAAAACQDBAD8AfAABALwAAQCIAH8 ASABBwAAAPwCAADAwEwAAAAEAAAALQEFAAQAAADwAQYADAAAACQDBAAEAvAACwLwAAsCIAEEAiAB BwAAAPwCAACyskcAAAAEAAAALQEGAAQAAADwAQUADAAAACQDBAALAvAAEwLwABMCIAELAiABBwAA APwCAACkpEEAAAAEAAAALQEFAAQAAADwAQYADAAAACQDBAATAvAAGgLwABoCIAETAiABBwAAAPwC AACXlzwAAAAEAAAALQEGAAQAAADwAQUADAAAACQDBAAaAvAAIgLwACICIAEaAiABBwAAAPwCAACM jDgAAAAEAAAALQEFAAQAAADwAQYADAAAACQDBAAiAvAAKQLwACkCIAEiAiABBwAAAPwCAACDgzQA AAAEAAAALQEGAAQAAADwAQUADAAAACQDBAApAvAAMQLwADECIAEpAiABBwAAAPwCAAB8fDEAAAAE AAAALQEFAAQAAADwAQYADAAAACQDBAAxAvAAOALwADgCIAExAiABBwAAAPwCAAB3dy8AAAAEAAAA LQEGAAQAAADwAQUADAAAACQDBAA4AvAAQALwAEACIAE4AiABBAAAAC0BBAAEAAAA8AEGAAQAAAAt AQIABAAAAC0BAAAEAAAABwEBAAgAAAAmBg8ABgD/////AQAJAAAA+gIAAAEAAAAAAAAAIgAEAAAA LQEFAAQAAAAtAQQABwAAABsEIQFBAvAAyAEEAAAALQECAAQAAADwAQUABAAAAC0BAAAIAAAAJgYP AAYA/////wEAEAAAACYGDwAWAP////8AAMQBAAAsAQAAfAMAAGQBAAAIAAAAJgYPAAYA/////wAA BAAAAC0BAQAEAAAALQEEAAQAAAAHAQQABwAAAPwCAAD+/mUAAAAEAAAALQEFAAwAAAAkAwQAyAEw AeMBMAHjAWAByAFgAQcAAAD8AgAA+/tkAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQA4wEwAf4B MAH+AWAB4wFgAQcAAAD8AgAA+PhjAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQA/gEwARkCMAEZ AmAB/gFgAQcAAAD8AgAA8/NhAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAGQIwATQCMAE0AmAB GQJgAQcAAAD8AgAA7OxeAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQANAIwAU8CMAFPAmABNAJg AQcAAAD8AgAA4+NbAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQATwIwAWoCMAFqAmABTwJgAQcA AAD8AgAA2dlWAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAagIwAYUCMAGFAmABagJgAQcAAAD8 AgAAzMxRAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAhQIwAaACMAGgAmABhQJgAQcAAAD8AgAA v79MAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAoAIwAbsCMAG7AmABoAJgAQcAAAD8AgAAsbFG AAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAuwIwAdYCMAHWAmABuwJgAQcAAAD8AgAAo6NBAAAA BAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQA1gIwAfECMAHxAmAB1gJgAQcAAAD8AgAAlpY8AAAABAAA AC0BBgAEAAAA8AEFAAwAAAAkAwQA8QIwAQwDMAEMA2AB8QJgAQcAAAD8AgAAi4s3AAAABAAAAC0B BQAEAAAA8AEGAAwAAAAkAwQADAMwAScDMAEnA2ABDANgAQcAAAD8AgAAgoI0AAAABAAAAC0BBgAE AAAA8AEFAAwAAAAkAwQAJwMwAUIDMAFCA2ABJwNgAQcAAAD8AgAAfHwxAAAABAAAAC0BBQAEAAAA 8AEGAAwAAAAkAwQAQgMwAV0DMAFdA2ABQgNgAQcAAAD8AgAAd3cvAAAABAAAAC0BBgAEAAAA8AEF AAwAAAAkAwQAXQMwAXgDMAF4A2ABXQNgAQQAAAAtAQQABAAAAPABBgAEAAAALQECAAQAAAAtAQAA BAAAAAcBAQAIAAAAJgYPAAYA/////wEACQAAAPoCAAABAAAAAAAAACIABAAAAC0BBQAEAAAALQEE AAcAAAAbBGEBeQMwAcgBBAAAAC0BAgAEAAAA8AEFAAQAAAAtAQAACAAAACYGDwAGAP////8BABAA AAAmBg8AFgD/////AADEAQAAbAEAAFwCAACkAQAACAAAACYGDwAGAP////8AAAQAAAAtAQEABAAA AC0BBAAEAAAABwEEAAcAAAD8AgAA/v5lAAAABAAAAC0BBQAMAAAAJAMEAMgBcAHRAXAB0QGgAcgB oAEHAAAA/AIAAPv7ZAAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEANEBcAHaAXAB2gGgAdEBoAEH AAAA/AIAAPj4YwAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEANoBcAHjAXAB4wGgAdoBoAEHAAAA /AIAAPPzYQAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAOMBcAHsAXAB7AGgAeMBoAEHAAAA/AIA AOzsXgAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAOwBcAH1AXAB9QGgAewBoAEHAAAA/AIAAOPj WwAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAPUBcAH+AXAB/gGgAfUBoAEHAAAA/AIAANnZVgAA AAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAP4BcAEHAnABBwKgAf4BoAEHAAAA/AIAAMzMUQAAAAQA AAAtAQYABAAAAPABBQAMAAAAJAMEAAcCcAEQAnABEAKgAQcCoAEHAAAA/AIAAL+/TAAAAAQAAAAt AQUABAAAAPABBgAMAAAAJAMEABACcAEZAnABGQKgARACoAEHAAAA/AIAALGxRgAAAAQAAAAtAQYA BAAAAPABBQAMAAAAJAMEABkCcAEiAnABIgKgARkCoAEHAAAA/AIAAKOjQQAAAAQAAAAtAQUABAAA APABBgAMAAAAJAMEACICcAErAnABKwKgASICoAEHAAAA/AIAAJaWPAAAAAQAAAAtAQYABAAAAPAB BQAMAAAAJAMEACsCcAE0AnABNAKgASsCoAEHAAAA/AIAAIuLNwAAAAQAAAAtAQUABAAAAPABBgAM AAAAJAMEADQCcAE9AnABPQKgATQCoAEHAAAA/AIAAIKCNAAAAAQAAAAtAQYABAAAAPABBQAMAAAA JAMEAD0CcAFGAnABRgKgAT0CoAEHAAAA/AIAAHx8MQAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAME AEYCcAFPAnABTwKgAUYCoAEHAAAA/AIAAHd3LwAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAE8C cAFYAnABWAKgAU8CoAEEAAAALQEEAAQAAADwAQYABAAAAC0BAgAEAAAALQEAAAQAAAAHAQEACAAA ACYGDwAGAP////8BAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQUABAAAAC0BBAAHAAAAGwShAVkC cAHIAQQAAAAtAQIABAAAAPABBQAEAAAALQEAAAgAAAAmBg8ABgD/////AQAHAAAA/AIAAADM/wAA AAQAAAAtAQUACQAAAPoCAAABAAAAAAAAAiIABAAAAC0BBgAHAAAAGwThASECsAHIAQQAAAAtAQAA BAAAAPABBQAEAAAALQECAAQAAADwAQYAEAAAACYGDwAWAP////8AAB0CAABlAAAAJAIAADQCAAAE AAAALQEBAAcAAAD8AgAAAAAAAAAABAAAAC0BBQAEAAAABgECAAwAAAAkAwQAIgJoAB4CaAAeAngA IgJ4AAwAAAAkAwQAIgKEAB4ChAAeApQAIgKUAAwAAAAkAwQAIgKgAB4CoAAeArAAIgKwAAwAAAAk AwQAIgK8AB4CvAAeAswAIgLMAAwAAAAkAwQAIgLYAB4C2AAeAugAIgLoAAwAAAAkAwQAIgL0AB4C 9AAeAgQBIgIEAQwAAAAkAwQAIgIQAR4CEAEeAiABIgIgAQwAAAAkAwQAIgIsAR4CLAEeAjwBIgI8 AQwAAAAkAwQAIgJIAR4CSAEeAlgBIgJYAQwAAAAkAwQAIgJkAR4CZAEeAnQBIgJ0AQwAAAAkAwQA IgKAAR4CgAEeApABIgKQAQwAAAAkAwQAIgKcAR4CnAEeAqwBIgKsAQwAAAAkAwQAIgK4AR4CuAEe AsgBIgLIAQwAAAAkAwQAIgLUAR4C1AEeAuQBIgLkAQwAAAAkAwQAIgLwAR4C8AEeAgACIgIAAgwA AAAkAwQAIgIMAh4CDAIeAhwCIgIcAgwAAAAkAwQAIgIoAh4CKAIeAjACIgIwAgQAAAAGAQEABAAA AC0BAgAEAAAALQEAAAgAAAAmBg8ABgD/////AQAEAAAALQEEAAQAAAAtAQEABwAAABsEnQBfAWwA 1gAEAAAALQEAAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAVAAAA+wLg/wAAAAAAALwCAAAA AAAAABJUaW1lcyBOZXcgUm9tYW4AALsEAAAALQEGAAQAAADwAQMABQAAAAkCAAAAAgUAAAAUAgAA AAAEAAAALgEYAAQAAAACAQEAEwAAADIKkADgAAgAAABQYWNrZXQgMRQAEAAOABIADgAKAAgAEAAE AAAALgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEEAAQAAAAtAQEABwAAABsE4QBhAbAA2AAEAAAA LQEAAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAu ARgABAAAAAIBAQATAAAAMgrUAOIACAAAAFBhY2tldCAyFAAQAA4AEgAOAAoACAAQAAQAAAAuAQEA BAAAAAIBAgAEAAAAAgECAAQAAAAtAQQABAAAAC0BAQAHAAAAGwQhAWEB8ADYAAQAAAAtAQAABAAA AC0BAgAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAA AgEBABMAAAAyChQB4gAIAAAAUGFja2V0IDMUABAADgASAA4ACgAIABAABAAAAC4BAQAEAAAAAgEC AAQAAAACAQIABAAAAC0BBAAEAAAALQEBAAcAAAAbBGEBYQEwAdgABAAAAC0BAAAEAAAALQECAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAEwAA ADIKVAHiAAgAAABQYWNrZXQgNBQAEAAOABIADgAKAAgAEAAEAAAALgEBAAQAAAACAQIABAAAAAIB AgAEAAAALQEEAAQAAAAtAQEABwAAABsEoQFhAXAB2AAEAAAALQEAAAQAAAAtAQIABQAAAAkCAAAA AgUAAAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQATAAAAMgqUAeIA CAAAAFBhY2tldCA1FAAQAA4AEgAOAAoACAAQAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQAAAAt AQQABAAAAC0BAQAHAAAAGwThAZEBsAHYAAQAAAAtAQAABAAAAC0BAgAFAAAACQIAAAACBQAAABQC AAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABYAAAAyCtQB4gAKAAAAUGFj a2V0IEZFQxQAEAAOABIADgAKAAgAFAAVABcABAAAAC4BAQAEAAAAAgECAAQAAAACAQIABAAAAC0B BAAEAAAALQEBAAcAAAAbBIkC/wFYAngBBAAAAC0BAAAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAEwAAADIKfAKCAQgAAABGaWd1 cmUgMhQACAAQABIADgAPAAgAEAAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAQAAAAJgYPABYA//// /wAAjQAAAG0AAADNAAAAnQEAAAQAAAAtAQEABAAAAC0BBQAEAAAABgECAMwAAAAkA2QAyAByAMgA bgDCAG8AvQBwALwAcACzAHYArQB+AKwAfwCrAIMAqgCJAKoA6wCpAPAAqAD0AKoA9QCoAPMAogD7 AJkAAQGbAAIBmgAAAZUAAgGQAAIBkAACAY8AAwGOAAQBjgAEAY8ABQGQAAYBkAAGAZUABwGaAAgB mwAGAZkABwGiAA0BqAAVAaoAEwGoABQBqQAYAasAGAGpABcBqgAdAaoAfwGrAIQBqwCFAawAiQGt AIoBswCSAbwAmAG9AJgBwgCaAcgAmgHIAJYBwwCWAb4AlAG9AJYBvwCVAbYAjwGwAIcBrgCJAbAA iAGvAIQBrQCEAa8AhQGuAH8BrgAdAa0AGAGtABcBrQAXAawAEwGrABIBpQAKAZwABAGbAAQBlgAD AZAAAgGQAAYBkQAFAZIABAGSAAQBkQADAZAAAgGQAAQBkAAGAZYABgGbAAQBnAAEAaUA/gCrAPYA rAD1AK0A8QCuAOsArgCJAK8AhACwAIAArgB/ALAAgQC2AHkAvwBzAL0AcgC+AHQAwwBzAAQAAAAG AQEABAAAAC0BAgAEAAAALQEAAAgAAAAmBg8ABgD/////AQAEAAAALQEEAAQAAAAtAQEABwAAABsE IQGGAPAAKAAEAAAALQEAAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAACBQAA ABQCAAAAAAQAAAAuARgABAAAAAIBAQAPAAAAMgoUATIABQAAAE4gPSA1ABcACAASAAgAEAAEAAAA LgEBAAQAAAACAQIABAAAAAIBAgAQAAAAJgYPABYA/////wAAxQEAAOUBAADMAQAANAIAAAQAAAAt AQEABAAAAC0BBQAEAAAABgECAAwAAAAkAwQAygHoAcYB6AHGAfgBygH4AQwAAAAkAwQAygEEAsYB BALGARQCygEUAgwAAAAkAwQAygEgAsYBIALGATACygEwAgQAAAAGAQEABAAAAC0BAgAEAAAALQEA AAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA/////wAAxQEAAAQCAAAkAgAAHQIAAAQAAAAtAQEA BAAAAC0BBQAEAAAABgECAAwAAAAkAwQA1wEOAtcBEgIRAhICEQIOAgQAAAAGAQEACgAAACQDAwDZ AQcCyAEQAtkBGAIKAAAAJAMDAA8CGQIgAhACDwIIAgQAAAAtAQIABAAAAC0BAAAIAAAAJgYPAAYA /////wEABAAAAC0BBAAEAAAALQEBAAcAAAAbBEkCCgIYAuABBAAAAC0BAAAEAAAALQECAAUAAAAJ AgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEACQAAADIK PALqAQEAAABMABUABAAAAC4BAQAEAAAAAgECAAQAAAACAQIABAAAAC0BAQAEAAAALQEEABAAAAD7 AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAABAAAAC0BAwAEAAAA8AEGAA8AAAAmBg8AFABUTlBQ BAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBj AHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH/////FQAAAP////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABUAAAABhcAAAAAAAAFAEQAbwBjAHUAbQBl AG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAP// /////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE8AAADgAQAAAAAA AF8AMQAwADAANwA3ADYAMQA1ADMAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAYAAEBBAAAAA0AAAAaAAAAEY2BZJtPzxGG6gCqALkp6AAAAABgXi/YVsy/AQBPSdhW zL8BAAAAAAAAAAAAAAAAAQBPAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABXAAAAFAAAAAAAAAAPAOgD5wIAAAEA6QMoAAAAgBYAAOAQAADgEAAA gBYAABEAAAAoAAAAAAAAAAAAAAABAAAAAAAAAQ8A8gPwAAAALwDIDwwAAAAwANIPBAAAAAAAAAAP ANUHTAAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAD80mIA/NJiAAjP YgD40wMwLM9iAAgAAAAsz2IAftQDMAAABhIAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/ AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgAAAAAAQAA AAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBIQAAAAP AADwfAAAAAAABvAgAAAAAgwAAAMAAAAaAAAAAgAAAAEAAAAHAAAAAgAAABgAAABjAAvwJAAAAIEB BAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACCAAGvEIAAAAAMz/AP//ZgBAAB7xEAAA AADM/wABAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAH iwAAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQA AAAqAAAAZAAAACoAAABkAAAAOM9iAH7UAzAwz2IACAAAAJAJAAAsBwAA9P////T///8BAAAAcAD7 AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAA/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A9YAAAA AADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqg8KAAAAAQAAAAEAAAAA ABAAnw8EAAAABQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA6gMAAAAADwD4A3UIAAACAO8DGAAAAAEA AAABAgcJCAAAAAAAAAAAAAAAAAAFMGAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ ALKysgBgAPAHIAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD//8wA AAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d3QCA gIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADwByAA AAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAAAAAA ADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAAAEAC AAAAAAIAAAD//+8AAAAAAP///////ywAAAAAAwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAAAA AGQAFAAAANgAAABAAgAAAAACAAAA///vAAAAAAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIA HACABQAAIiDQAkACAAACABgAgAUAABMg8ANgAwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAF AP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAAAAAAD///////8MAAAA AAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9S AAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAAAAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJ AAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAF AAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAA AgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAA AAIAEAAEAAAAAAAAAAIAEAAPAAwE0wQAAA8AAvDLBAAAEAAI8AgAAAAGAAAABgQAAA8AA/BjBAAA DwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAAS AArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEAAQCAABQudgCHAAEAAACBAQQAAAiDAQAAAAi/AQEA EQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAAB AM4ADwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxl IHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQA AAAKAACDAAvwMAAAAH8AAQABAIAAdC52AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAEC AgAACAAAEPAIAAAA4ASwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAAIAzgAPAA3wngAAAAAAnw8E AAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxl dmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAA AAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LUAAAASAArwCAAAAAQE AAAACgAAgwAL8DAAAAB/AAEAAQCAAFQtdgCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQAB AgIAAAgAABDwCAAAAGAPsAFgBoAQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAc4ADwAN8D0AAAAAAJ8P BAAAAAQAAAAAAKgPAQAAACoAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAA4AAAD4DwQAAAAAAAAA DwAE8LcAAAASAArwCAAAAAUEAAAACgAAgwAL8DAAAAB/AAEAAQCAANQudgCBAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAfQDoAQDwAR8BAAAAAAAMMLCAAAAAMA AAAJAs4ADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFgAAAAIAAAAAAAAIAAABAAIA AAAAAAIADgAAAPoPBAAAAAAAAAAPAATwtwAAABIACvAIAAAABgQAAAAKAACDAAvwMAAAAH8AAQAB AIAAFCV2AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA8gENAU gBAPABHwEAAAAAAAwwsIAAAABAAAAAgCzgAPAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAA oQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAAB BAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gNWCwAAAgDv AxgAAAAAAAAADxAAAAAAAAAAAACAAAAAAAcABTAPAAwEBgsAAA8AAvD+CgAAIAAI8AgAAAAUAAAA FwgAAA8AA/CWCgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAF AAAADwAE8HAAAAASAArwCAAAAAQIAAAACgAAwwAL8EgAAACFAAIAAACHAAEAAACAAQcAAACBAf// ZgCDAfABdhCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAA AKACsApwEcADDwAE8HAAAAASAArwCAAAAAUIAAAACgAAwwAL8EgAAACFAAIAAACHAAEAAACAAQcA AACBAf//ZgCDAfABdhCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgA ABDwCAAAACAEsArgDUAFDwAE8HAAAAASAArwCAAAAAYIAAAACgAAwwAL8EgAAACFAAIAAACHAAEA AACAAQcAAACBAf//ZgCDAfABdhCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAj/AQgACAAB AgIAAAgAABDwCAAAAKAFsAqADcAGDwAE8HAAAAASAArwCAAAAAcIAAAACgAAwwAL8EgAAACFAAIA AACHAAEAAACAAQcAAACBAf//ZgCDAfABdhCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAj/ AQgACAABAgIAAAgAABDwCAAAACAHsArQFEAIDwAE8HAAAAASAArwCAAAAAgIAAAACgAAwwAL8EgA AACFAAIAAACHAAEAAACAAQcAAACBAf//ZgCDAfABdhCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADA AQEAAAj/AQgACAABAgIAAAgAABDwCAAAAKAIsAoQDsAJDwAE8FIAAAASAArwCAAAAAkIAAAACgAA cwAL8CoAAACFAAIAAACHAAEAAACBAQDM/wC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAA ACAKsArADEALDwAE8GQAAABCAQrwCAAAAAoIAAAACgAAowAL8DwAAACFAAIAAACHAAEAAABEAQQA AAB/AQAAAQC/AQAAEADAAQEAAAjLAdSUAADOAQYAAAD/ARgAGAABAgIAAAgAABDwCAAAAHACwAzA DCANDwAE8KQAAACiDArwCAAAAAsIAAAACgAAowAL8DwAAACAADQsdgCFAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAIoCBgU0CKoDDwAN 8DgAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAFBhY2tldCAxAAChDxQAAAAJAAAAAAAAAAAACQAAAAEA AAABAA8ABPCkAAAAogwK8AgAAAAMCAAAAAoAAKMAC/A8AAAAgADUKHYAhQACAAAAhwAGAAAAvwAC AAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAgBBAFPghABQ8A DfA4AAAAAACfDwQAAAAEAAAAAACoDwgAAABQYWNrZXQgMgAAoQ8UAAAACQAAAAAAAAAAAAkAAAAB AAAAAQAPAATwpAAAAKIMCvAIAAAADQgAAAAKAACjAAvwPAAAAIAA1CV2AIUAAgAAAIcABgAAAL8A AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAoAUQBT4IwAYP AA3wOAAAAAAAnw8EAAAABAAAAAAAqA8IAAAAUGFja2V0IDMAAKEPFAAAAAkAAAAAAAAAAAAJAAAA AQAAAAEADwAE8KQAAACiDArwCAAAAA4IAAAACgAAowAL8DwAAACAAPQ/4wCFAAIAAACHAAYAAAC/ AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAACAHEAU+CEAI DwAN8DgAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAFBhY2tldCA0AAChDxQAAAAJAAAAAAAAAAAACQAA AAEAAAABAA8ABPCkAAAAogwK8AgAAAAPCAAAAAoAAKMAC/A8AAAAgAC0QOMAhQACAAAAhwAGAAAA vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACgCBAFPgjA CQ8ADfA4AAAAAACfDwQAAAAEAAAAAACoDwgAAABQYWNrZXQgNQAAoQ8UAAAACQAAAAAAAAAAAAkA AAABAAAAAQAPAATwpgAAAKIMCvAIAAAAEAgAAAAKAACjAAvwPAAAAIAAdEHjAIUAAgAAAIcABgAA AL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAIAoQBV4J QAsPAA3wOgAAAAAAnw8EAAAABAAAAAAAqA8KAAAAUGFja2V0IEZFQwAAoQ8UAAAACwAAAAAAAAAA AAsAAAABAAAAAQAPAATwpAAAAKIMCvAIAAAAEQgAAAAKAACjAAvwPAAAAIAANELjAIUAAgAAAIcA BgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAEA7Q CPMLMA8PAA3wOAAAAAAAnw8EAAAABAAAAAAAqA8IAAAARmlndXJlIDIAAKEPFAAAAAkAAAAAAAAA AAAJAAAAAQAAAAEADwAE8F4AAAByBQrwCAAAABIIAAAACgAAkwAL8DYAAACFAAIAAACHAAEAAACB AQQAAAiDAQAAAAi/AQAAEADAAQEAAAjLAdSUAAD/AQgACAABAgIAAAgAABDwCAAAAKACYAOwBJAJ DwAE8KEAAACiDArwCAAAABMIAAAACgAAowAL8DwAAACAAJRC4wCFAAIAAACHAAYAAAC/AAIAAgCB AQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAKAF8AAcA8AGDwAN8DUA AAAAAJ8PBAAAAAQAAAAAAKgPBQAAAE4gPSA1AAChDxQAAAAGAAAAAAAAAAAABgAAAAEAAAABAA8A BPBkAAAAQgEK8AgAAAAUCAAAAAoAAKMAC/A8AAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEAvwEA ABAAwAEBAAAIywHUlAAAzgEGAAAA/wEYABgAAQICAAAIAAAQ8AgAAABwC7AKsAogDQ8ABPBqAAAA QgEK8AgAAAAWCAAAAAoAALMAC/BCAAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEAvwEAABAAwAEB AAAIywHUlAAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABgDLAKwAxgDA8ABPCdAAAA ogwK8AgAAAAXCAAAAAoAAKMAC/A8AAAAgAD0QuMAhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACQDEALNAywDQ8ADfAxAAAAAACfDwQA AAAEAAAAAACoDwEAAABMAAChDxQAAAACAAAAAAAAAAAAAgAAAAEAAAABAA8ABPBIAAAAEgAK8AgA AAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJ AAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAAAAchcQAAAA AQAwAAAAAADvAgAAbAsAAAAA9Q8cAAAAAAAAAIMVAAMAAAAAyhYAAAEAAAADAAAAAAAJMAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAADAAAAkAAAAA8AAACoAAAABAAAALQAAAAGAAAAvAAAAAcAAADEAAAA CAAAAMwAAAAJAAAA1AAAAAoAAADcAAAAFwAAAOQAAAALAAAA7AAAABAAAAD0AAAAEwAAAPwAAAAW AAAABAEAAA0AAAAMAQAADAAAAE4BAAACAAAA5AQAAB4AAAAPAAAAT24tc2NyZWVuIFNob3cAAB4A AAACAAAAIAAtcwMAAAAGFwAAAwAAAAkAAAADAAAAAQAAAAMAAAAAAAAAAwAAAAAAAAADAAAAAAAA AAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAwAAABAAAABUaW1l cyBOZXcgUm9tYW4ADwAAAERlZmF1bHQgRGVzaWduAA8AAABObyBTbGlkZSBUaXRsZQAMEAAABgAA AB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAARGVzaWduIFRlbXBsYXRlAAMAAAAB AAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAQAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIAFwAAABkAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWAAAAHUAAAAAAAAAAwBPAGIAagBJAG4AZgBvAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaAAAABAAAAAAAAABQAGkAYwB0AHUAcgBl AHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACARgA AAAcAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAA AEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAaAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAWwAAACQAAAAAAAAAAQD+/wMKAAD/////EY2BZJtPzxGG6gCqALkp6BsAAABNaWNyb3NvZnQg UG93ZXJQb2ludCBTbGlkZQAPAAAATVNQcmVzZW50YXRpb24AEwAAAFBvd2VyUG9pbnQuU2xpZGUu OAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DxwAAAAUAAAAX8CR41YcAAAE APQDAwBiAEFkYW0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAA AAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAALABAAAQAAAAAQAAAIgAAAADAAAAkAAA AA8AAACoAAAABAAAALQAAAAGAAAAvAAAAAcAAADEAAAACAAAAMwAAAAJAAAA1AAAAAoAAADcAAAA FwAAAOQAAAALAAAA7AAAABAAAAD0AAAAEwAAAPwAAAAWAAAABAEAAA0AAAAMAQAADAAAAE4BAAAC AAAA5AQAAB4AAAAPAAAAT24tc2NyZWVuIFNob3cAAB4AAAACAAAAIAAtcwMAAAB6HAAAAwAAAA0A AAADAAAAAQAAAAMAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACABsAAAAdAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGQAAADAMgAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1 AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB/////x4AAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfwAAAHocAAAAAAAABQBEAG8AYwB1AG0AZQBu AHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABcAAAA4AEAAAAAAAAx AFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADgACAAEAAAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKgAAACAGAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAAJAyAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAACAAAAACAAAAJAAAAAJAAAAoAAAABIAAACs AAAACgAAAMwAAAAMAAAA2AAAAA0AAADkAAAADwAAAPAAAAARAAAA+AAAAAIAAADkBAAAHgAAAA8A AABObyBTbGlkZSBUaXRsZQAAHgAAAAUAAABBZGFtAGlkZR4AAAAFAAAAQWRhbQBpZGUeAAAAAwAA ADEwAG0eAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AABQAEAAAABgSIWlJwAAAEAAAABAEiXV K06/AUAAAAAgGnIlSlC/AQMAAAAYAAAARwAAAI4xAAD/////AwAAAAgAbxBNDAAAAQAJAAADvxgA AAgAzAAAAAAAEQAAACYGDwAYAP////8AABAAAAAAAAAAAAC6AwAAygIAAAkAAAAmBg8ACAD///// AgAAABcAAAAmBg8AIwD/////BAAbAFROUFAUAMjwADAAAAAAFAAAAOQXdgAAAAAAdgAKAAAAJgYP AAoAVE5QUAAAAgD0AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAMAAEAAAABAAAA AAAAAAUAAAALAgAAAAAFAAAADALKAroDBAAAAAQBDQAHAAAA/AIAAP///wAAAAQAAAAtAQAACQAA APoCBQAAAAAA////ACIABAAAAC0BAQAEAAAALQEAAAkAAAAdBiEA8ADQAsADAAAAAAQAAAAtAQAA BAAAAC0BAAAJAAAA+gIAAAAAAAAAAAAAIgAEAAAALQECABAAAAAmBg8AFgD/////AABHAAAAjwIA ABEBAADBAgAACAAAACYGDwAGAP////8BAA0AAAD7AgAAAAAAAAAAAAAAAAABAAAAAAAABAAAAC0B AwAFAAAACQIAAAACBQAAABQCAAAAAAQAAAACAQIAEAAAACYGDwAWAP////8AAEcBAACPAgAAeQIA AMECAAAIAAAAJgYPAAYA/////wEABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAAAgECABAAAAAmBg8A FgD/////AADsAQAAPAAAABQDAAB0AAAACAAAACYGDwAGAP////8AAAQAAAAtAQEABwAAAPwCAQAA AAAAAAAEAAAALQEEAAQAAAAHAQQABwAAAPwCAAD+/mUAAAAEAAAALQEFAAwAAAAkAwQA8AFAAAIC QAACAnAA8AFwAAcAAAD8AgAA+/tkAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAAgJAABQCQAAU AnAAAgJwAAcAAAD8AgAA+PhjAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAFAJAACYCQAAmAnAA FAJwAAcAAAD8AgAA8/NhAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAJgJAADgCQAA4AnAAJgJw AAcAAAD8AgAA7OxeAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAOAJAAEoCQABKAnAAOAJwAAcA AAD8AgAA4+NbAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQASgJAAFwCQABcAnAASgJwAAcAAAD8 AgAA2dlWAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAXAJAAG4CQABuAnAAXAJwAAcAAAD8AgAA zMxRAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAbgJAAIACQACAAnAAbgJwAAcAAAD8AgAAv79M AAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAgAJAAJICQACSAnAAgAJwAAcAAAD8AgAAsbFGAAAA BAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAkgJAAKQCQACkAnAAkgJwAAcAAAD8AgAAo6NBAAAABAAA AC0BBQAEAAAA8AEGAAwAAAAkAwQApAJAALYCQAC2AnAApAJwAAcAAAD8AgAAlpY8AAAABAAAAC0B BgAEAAAA8AEFAAwAAAAkAwQAtgJAAMgCQADIAnAAtgJwAAcAAAD8AgAAi4s3AAAABAAAAC0BBQAE AAAA8AEGAAwAAAAkAwQAyAJAANoCQADaAnAAyAJwAAcAAAD8AgAAgoI0AAAABAAAAC0BBgAEAAAA 8AEFAAwAAAAkAwQA2gJAAOwCQADsAnAA2gJwAAcAAAD8AgAAfHwxAAAABAAAAC0BBQAEAAAA8AEG AAwAAAAkAwQA7AJAAP4CQAD+AnAA7AJwAAcAAAD8AgAAd3cvAAAABAAAAC0BBgAEAAAA8AEFAAwA AAAkAwQA/gJAABADQAAQA3AA/gJwAAQAAAAtAQQABAAAAPABBgAEAAAALQECAAQAAAAtAQAABAAA AAcBAQAIAAAAJgYPAAYA/////wEACQAAAPoCAAABAAAAAAAAACIABAAAAC0BBQAEAAAALQEEAAcA AAAbBHEAEQNAAPABBAAAAC0BAgAEAAAA8AEFAAQAAAAtAQAACAAAACYGDwAGAP////8BABAAAAAm Bg8AFgD/////AADsAQAAfAAAAHwCAAC0AAAACAAAACYGDwAGAP////8AAAQAAAAtAQEABAAAAC0B BAAEAAAABwEEAAcAAAD8AgAA/v5lAAAABAAAAC0BBQAMAAAAJAMEAPABgAD4AYAA+AGwAPABsAAH AAAA/AIAAPz8ZAAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAPgBgAABAoAAAQKwAPgBsAAHAAAA /AIAAPj4YwAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAAECgAAJAoAACQKwAAECsAAHAAAA/AIA APPzYQAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAAkCgAASAoAAEgKwAAkCsAAHAAAA/AIAAO3t XgAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEABICgAAaAoAAGgKwABICsAAHAAAA/AIAAOTkWwAA AAQAAAAtAQYABAAAAPABBQAMAAAAJAMEABoCgAAjAoAAIwKwABoCsAAHAAAA/AIAANnZVwAAAAQA AAAtAQUABAAAAPABBgAMAAAAJAMEACMCgAArAoAAKwKwACMCsAAHAAAA/AIAAM3NUgAAAAQAAAAt AQYABAAAAPABBQAMAAAAJAMEACsCgAA0AoAANAKwACsCsAAHAAAA/AIAAMDATAAAAAQAAAAtAQUA BAAAAPABBgAMAAAAJAMEADQCgAA8AoAAPAKwADQCsAAHAAAA/AIAALKyRwAAAAQAAAAtAQYABAAA APABBQAMAAAAJAMEADwCgABFAoAARQKwADwCsAAHAAAA/AIAAKSkQQAAAAQAAAAtAQUABAAAAPAB BgAMAAAAJAMEAEUCgABNAoAATQKwAEUCsAAHAAAA/AIAAJeXPAAAAAQAAAAtAQYABAAAAPABBQAM AAAAJAMEAE0CgABWAoAAVgKwAE0CsAAHAAAA/AIAAIyMOAAAAAQAAAAtAQUABAAAAPABBgAMAAAA JAMEAFYCgABeAoAAXgKwAFYCsAAHAAAA/AIAAIODNAAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAME AF4CgABnAoAAZwKwAF4CsAAHAAAA/AIAAHx8MQAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAGcC gABvAoAAbwKwAGcCsAAHAAAA/AIAAHd3LwAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAG8CgAB4 AoAAeAKwAG8CsAAEAAAALQEEAAQAAADwAQYABAAAAC0BAgAEAAAALQEAAAQAAAAHAQEACAAAACYG DwAGAP////8BAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAtAQUABAAAAC0BBAAHAAAAGwSxAHkCgADw AQQAAAAtAQIABAAAAPABBQAEAAAALQEAAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA/////wAA 7AEAAPwAAABsAgAANAEAAAgAAAAmBg8ABgD/////AAAEAAAALQEBAAQAAAAtAQQABAAAAAcBBAAH AAAA/AIAAP7+ZQAAAAQAAAAtAQUADAAAACQDBADwAQAB9wEAAfcBMAHwATABBwAAAPwCAAD8/GQA AAAEAAAALQEGAAQAAADwAQUADAAAACQDBAD3AQAB/wEAAf8BMAH3ATABBwAAAPwCAAD4+GMAAAAE AAAALQEFAAQAAADwAQYADAAAACQDBAD/AQABBgIAAQYCMAH/ATABBwAAAPwCAADz82EAAAAEAAAA LQEGAAQAAADwAQUADAAAACQDBAAGAgABDgIAAQ4CMAEGAjABBwAAAPwCAADt7V4AAAAEAAAALQEF AAQAAADwAQYADAAAACQDBAAOAgABFQIAARUCMAEOAjABBwAAAPwCAADk5FsAAAAEAAAALQEGAAQA AADwAQUADAAAACQDBAAVAgABHQIAAR0CMAEVAjABBwAAAPwCAADZ2VcAAAAEAAAALQEFAAQAAADw AQYADAAAACQDBAAdAgABJAIAASQCMAEdAjABBwAAAPwCAADNzVIAAAAEAAAALQEGAAQAAADwAQUA DAAAACQDBAAkAgABLAIAASwCMAEkAjABBwAAAPwCAADAwEwAAAAEAAAALQEFAAQAAADwAQYADAAA ACQDBAAsAgABMwIAATMCMAEsAjABBwAAAPwCAACyskcAAAAEAAAALQEGAAQAAADwAQUADAAAACQD BAAzAgABOwIAATsCMAEzAjABBwAAAPwCAACkpEEAAAAEAAAALQEFAAQAAADwAQYADAAAACQDBAA7 AgABQgIAAUICMAE7AjABBwAAAPwCAACXlzwAAAAEAAAALQEGAAQAAADwAQUADAAAACQDBABCAgAB SgIAAUoCMAFCAjABBwAAAPwCAACMjDgAAAAEAAAALQEFAAQAAADwAQYADAAAACQDBABKAgABUQIA AVECMAFKAjABBwAAAPwCAACDgzQAAAAEAAAALQEGAAQAAADwAQUADAAAACQDBABRAgABWQIAAVkC MAFRAjABBwAAAPwCAAB8fDEAAAAEAAAALQEFAAQAAADwAQYADAAAACQDBABZAgABYAIAAWACMAFZ AjABBwAAAPwCAAB3dy8AAAAEAAAALQEGAAQAAADwAQUADAAAACQDBABgAgABaAIAAWgCMAFgAjAB BAAAAC0BBAAEAAAA8AEGAAQAAAAtAQIABAAAAC0BAAAEAAAABwEBAAgAAAAmBg8ABgD/////AQAJ AAAA+gIAAAEAAAAAAAAAIgAEAAAALQEFAAQAAAAtAQQABwAAABsEMQFpAgAB8AEEAAAALQECAAQA AADwAQUABAAAAC0BAAAIAAAAJgYPAAYA/////wEAEAAAACYGDwAWAP////8AAOwBAAA8AQAApAMA AHQBAAAIAAAAJgYPAAYA/////wAABAAAAC0BAQAEAAAALQEEAAQAAAAHAQQABwAAAPwCAAD+/mUA AAAEAAAALQEFAAwAAAAkAwQA8AFAAQsCQAELAnAB8AFwAQcAAAD8AgAA+/tkAAAABAAAAC0BBgAE AAAA8AEFAAwAAAAkAwQACwJAASYCQAEmAnABCwJwAQcAAAD8AgAA+PhjAAAABAAAAC0BBQAEAAAA 8AEGAAwAAAAkAwQAJgJAAUECQAFBAnABJgJwAQcAAAD8AgAA8/NhAAAABAAAAC0BBgAEAAAA8AEF AAwAAAAkAwQAQQJAAVwCQAFcAnABQQJwAQcAAAD8AgAA7OxeAAAABAAAAC0BBQAEAAAA8AEGAAwA AAAkAwQAXAJAAXcCQAF3AnABXAJwAQcAAAD8AgAA4+NbAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAk AwQAdwJAAZICQAGSAnABdwJwAQcAAAD8AgAA2dlWAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQA kgJAAa0CQAGtAnABkgJwAQcAAAD8AgAAzMxRAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQArQJA AcgCQAHIAnABrQJwAQcAAAD8AgAAv79MAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAyAJAAeMC QAHjAnAByAJwAQcAAAD8AgAAsbFGAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQA4wJAAf4CQAH+ AnAB4wJwAQcAAAD8AgAAo6NBAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQA/gJAARkDQAEZA3AB /gJwAQcAAAD8AgAAlpY8AAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAGQNAATQDQAE0A3ABGQNw AQcAAAD8AgAAi4s3AAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQANANAAU8DQAFPA3ABNANwAQcA AAD8AgAAgoI0AAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQATwNAAWoDQAFqA3ABTwNwAQcAAAD8 AgAAfHwxAAAABAAAAC0BBQAEAAAA8AEGAAwAAAAkAwQAagNAAYUDQAGFA3ABagNwAQcAAAD8AgAA d3cvAAAABAAAAC0BBgAEAAAA8AEFAAwAAAAkAwQAhQNAAaADQAGgA3ABhQNwAQQAAAAtAQQABAAA APABBgAEAAAALQECAAQAAAAtAQAABAAAAAcBAQAIAAAAJgYPAAYA/////wEACQAAAPoCAAABAAAA AAAAACIABAAAAC0BBQAEAAAALQEEAAcAAAAbBHEBoQNAAfABBAAAAC0BAgAEAAAA8AEFAAQAAAAt AQAACAAAACYGDwAGAP////8BABAAAAAmBg8AFgD/////AADsAQAAvAEAAIQCAAD0AQAACAAAACYG DwAGAP////8AAAQAAAAtAQEABAAAAC0BBAAEAAAABwEEAAcAAAD8AgAA/v5lAAAABAAAAC0BBQAM AAAAJAMEAPABwAH5AcAB+QHwAfAB8AEHAAAA/AIAAPv7ZAAAAAQAAAAtAQYABAAAAPABBQAMAAAA JAMEAPkBwAECAsABAgLwAfkB8AEHAAAA/AIAAPj4YwAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAME AAICwAELAsABCwLwAQIC8AEHAAAA/AIAAPPzYQAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAAsC wAEUAsABFALwAQsC8AEHAAAA/AIAAOzsXgAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEABQCwAEd AsABHQLwARQC8AEHAAAA/AIAAOPjWwAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAB0CwAEmAsAB JgLwAR0C8AEHAAAA/AIAANnZVgAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEACYCwAEvAsABLwLw ASYC8AEHAAAA/AIAAMzMUQAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAC8CwAE4AsABOALwAS8C 8AEHAAAA/AIAAL+/TAAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEADgCwAFBAsABQQLwATgC8AEH AAAA/AIAALGxRgAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAEECwAFKAsABSgLwAUEC8AEHAAAA /AIAAKOjQQAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAEoCwAFTAsABUwLwAUoC8AEHAAAA/AIA AJaWPAAAAAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAFMCwAFcAsABXALwAVMC8AEHAAAA/AIAAIuL NwAAAAQAAAAtAQUABAAAAPABBgAMAAAAJAMEAFwCwAFlAsABZQLwAVwC8AEHAAAA/AIAAIKCNAAA AAQAAAAtAQYABAAAAPABBQAMAAAAJAMEAGUCwAFuAsABbgLwAWUC8AEHAAAA/AIAAHx8MQAAAAQA AAAtAQUABAAAAPABBgAMAAAAJAMEAG4CwAF3AsABdwLwAW4C8AEHAAAA/AIAAHd3LwAAAAQAAAAt AQYABAAAAPABBQAMAAAAJAMEAHcCwAGAAsABgALwAXcC8AEEAAAALQEEAAQAAADwAQYABAAAAC0B AgAEAAAALQEAAAQAAAAHAQEACAAAACYGDwAGAP////8BAAkAAAD6AgAAAQAAAAAAAAAiAAQAAAAt AQUABAAAAC0BBAAHAAAAGwTxAYECwAHwAQQAAAAtAQIABAAAAPABBQAEAAAALQEAAAgAAAAmBg8A BgD/////AQAHAAAA/AIAAGb//wAAAAQAAAAtAQUACQAAAPoCAAABAAAAAAAAAiIABAAAAC0BBgAH AAAAGwSxASkCgAHwAQQAAAAtAQAABAAAAPABBQAEAAAALQECAAQAAADwAQYABAAAAC0BBAAEAAAA LQEBAAcAAAAbBG0AhwE8AP4ABAAAAC0BAAAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAAFQAA APsC4P8AAAAAAAC8AgAAAAAAAAASVGltZXMgTmV3IFJvbWFuAAC7BAAAAC0BBQAEAAAA8AEDAAUA AAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABMAAAAyCmAACAEIAAAAUGFja2V0IDEU ABAADgASAA4ACgAIABAABAAAAC4BAQAEAAAAAgECAAQAAAACAQIABAAAAC0BBAAEAAAALQEBAAcA AAAbBLEAiQGAAAABBAAAAC0BAAAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAA AgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAEwAAADIKpAAKAQgAAABQYWNrZXQgMhQAEAAOABIA DgAKAAgAEAAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEEAAQAAAAtAQEABwAAABsEMQGJ AQABAAEEAAAALQEAAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAACBQAAABQC AAAAAAQAAAAuARgABAAAAAIBAQATAAAAMgokAQoBCAAAAFBhY2tldCAzFAAQAA4AEgAOAAoACAAQ AAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQAAAAtAQQABAAAAC0BAQAHAAAAGwRxAYkBQAEAAQQA AAAtAQAABAAAAC0BAgAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAA AC4BGAAEAAAAAgEBABMAAAAyCmQBCgEIAAAAUGFja2V0IDQUABAADgASAA4ACgAIABAABAAAAC4B AQAEAAAAAgECAAQAAAACAQIABAAAAC0BBAAEAAAALQEBAAcAAAAbBPEBiQHAAQABBAAAAC0BAAAE AAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQA AAACAQEAEwAAADIK5AEKAQgAAABQYWNrZXQgNRQAEAAOABIADgAKAAgAEAAEAAAALgEBAAQAAAAC AQIABAAAAAIBAgAEAAAALQEEAAQAAAAtAQEABwAAABsEsQG5AYABAAEEAAAALQEAAAQAAAAtAQIA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAW AAAAMgqkAQoBCgAAAFBhY2tldCBGRUMUABAADgASAA4ACgAIABQAFQAXAAQAAAAuAQEABAAAAAIB AgAEAAAAAgECAAQAAAAtAQQABAAAAC0BAQAHAAAAGwSZAv8BaAJ4AQQAAAAtAQAABAAAAC0BAgAF AAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABMA AAAyCowCggEIAAAARmlndXJlIDMUAAgAEAASAA4ADwAIABAABAAAAC4BAQAEAAAAAgECAAQAAAAC AQIAEAAAACYGDwAWAP////8AAN0AAAA1AAAA/QAAALUAAAAEAAAALQEBAAcAAAD8AgAAAAAAAAAA BAAAAC0BAwAEAAAABgECAKYAAAAkA1EA+AA6APgANgDzADcA8gA3AO4AOQDrADwA6wA9AOoAQgDq AGoA6QBuAOsAbgDqAG0A5wBwAOMAcgDlAHMA5ABxAOAAcgDgAHIA3wBzAN4AdADeAHQA3wB1AOAA dgDgAHYA5AB3AOUAdQDjAHYA5wB4AOoAewDrAHoA6QB6AOkAeQDqAH4A6gCmAOsAqgDrAKsA6wCs AO4ArwDyALEA8wCxAPgAsgD4AK4A9ACtAPMArwD1AK4A8QCsAO4AqQDvAKoA7QCqAO8AqwDuAKYA 7gB+AO0AegDtAHkA7QB4AOoAdQDmAHMA5QBzAOAAcgDgAHYA4QB1AOIAdADiAHQA4QBzAOAAcgDg AHQA4AB2AOUAdQDmAHUA6gBzAO0AcADtAG8A7gBqAO4AQgDvAD4A7QA+AO4APwDxADwA9QA6APMA OQD0ADsABAAAAAYBAQAEAAAALQECAAQAAAAtAQAACAAAACYGDwAGAP////8BAAcAAAD8AgAAZv// AAAABAAAAC0BBgAEAAAALQEBAAQAAAAtAQYACQAAAB0GIQDwADAAZwBgAHgABAAAAC0BBgAEAAAA LQEAAAQAAADwAQYABAAAAC0BAgAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIA AAAABAAAAC4BGAAEAAAAAgEBAAkAAAAyCoQAggABAAAATgAXAAQAAAAuAQEABAAAAAIBAgAVAAAA +wLr/wAAAAAAALwCAAAAAAAAABJUaW1lcyBOZXcgUm9tYW4AALsEAAAALQEGAAQAAADwAQUABQAA AAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEACQAAADIKjACZAAEAAAAxAAsABAAAAC4B AQAEAAAAAgECABUAAAD7AuD/AAAAAAAAvAIAAAAAAAAAElRpbWVzIE5ldyBSb21hbgAAuwQAAAAt AQUABAAAAPABBgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQANAAAAMgqEAKQA BAAAACA9IDIIABIACAAQAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECABAAAAAmBg8AFgD/////AADt AQAA7QEAAPQBAABMAgAABAAAAC0BAQAEAAAALQEDAAQAAAAGAQIADAAAACQDBADyAfAB7gHwAe4B AALyAQACDAAAACQDBADyAQwC7gEMAu4BHALyARwCDAAAACQDBADyASgC7gEoAu4BOALyATgCDAAA ACQDBADyAUQC7gFEAu4BSALyAUgCBAAAAAYBAQAEAAAALQECAAQAAAAtAQAACAAAACYGDwAGAP// //8BABAAAAAmBg8AFgD/////AADtAQAAFAIAACwCAAAtAgAABAAAAC0BAQAEAAAALQEDAAQAAAAG AQIADAAAACQDBAD/AR4C/wEiAhkCIgIZAh4CBAAAAAYBAQAKAAAAJAMDAAECFwLwASACAQIoAgoA AAAkAwMAFwIpAigCIAIXAhgCBAAAAC0BAgAEAAAALQEAAAgAAAAmBg8ABgD/////AQAEAAAALQEE AAQAAAAtAQEABwAAABsEWQIkAigC8AEEAAAALQEAAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAJAAAAMgpMAvoBAQAAAEwAFQAE AAAALgEBAAQAAAACAQIAFQAAAPsC6/8AAAAAAAC8AgAAAAAAAAASVGltZXMgTmV3IFJvbWFuAAC7 BAAAAC0BBgAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAAkAAAAy ClQCDwIBAAAAMQALAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAcAAAD8AgAAZv//AAAABAAAAC0B BQAJAAAA+gIAAAEAAAAAAAACIgAEAAAALQEHAAcAAAAbBPEAKQLAAPABBAAAAC0BAAAEAAAA8AEF AAQAAAAtAQIABAAAAPABBwAEAAAALQEEAAQAAAAtAQEABwAAABsE8QC5AcAAAAEEAAAALQEAAAQA AAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAVAAAA+wLg/wAAAAAAALwCAAAAAAAAABJUaW1lcyBO ZXcgUm9tYW4AALsEAAAALQEFAAQAAADwAQYABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQA AAACAQEAFgAAADIK5AAKAQoAAABQYWNrZXQgRkVDFAAQAA4AEgAOAAoACAAUABUAFwAEAAAALgEB AAQAAAACAQIABAAAAAIBAgAHAAAA/AIAAACZ/wAAAAQAAAAtAQYACQAAAPoCAAABAAAAAAAAAiIA BAAAAC0BBwAHAAAAGwSxAWECgAEoAgQAAAAtAQAABAAAAPABBgAEAAAALQECAAQAAADwAQcAEAAA ACYGDwAWAP////8AACUCAAA1AAAALAIAAEwCAAAEAAAALQEBAAQAAAAtAQMABAAAAAYBAgAMAAAA JAMEACoCOAAmAjgAJgJIACoCSAAMAAAAJAMEACoCVAAmAlQAJgJkACoCZAAMAAAAJAMEACoCcAAm AnAAJgKAACoCgAAMAAAAJAMEACoCjAAmAowAJgKcACoCnAAMAAAAJAMEACoCqAAmAqgAJgK4ACoC uAAMAAAAJAMEACoCxAAmAsQAJgLUACoC1AAMAAAAJAMEACoC4AAmAuAAJgLwACoC8AAMAAAAJAME ACoC/AAmAvwAJgIMASoCDAEMAAAAJAMEACoCGAEmAhgBJgIoASoCKAEMAAAAJAMEACoCNAEmAjQB JgJEASoCRAEMAAAAJAMEACoCUAEmAlABJgJgASoCYAEMAAAAJAMEACoCbAEmAmwBJgJ8ASoCfAEM AAAAJAMEACoCiAEmAogBJgKYASoCmAEMAAAAJAMEACoCpAEmAqQBJgK0ASoCtAEMAAAAJAMEACoC wAEmAsABJgLQASoC0AEMAAAAJAMEACoC3AEmAtwBJgLsASoC7AEMAAAAJAMEACoC+AEmAvgBJgII AioCCAIMAAAAJAMEACoCFAImAhQCJgIkAioCJAIMAAAAJAMEACoCMAImAjACJgJAAioCQAIEAAAA BgEBAAQAAAAtAQIABAAAAC0BAAAIAAAAJgYPAAYA/////wEAEAAAACYGDwAWAP////8AAF0CAAA1 AAAAZAIAAEwCAAAEAAAALQEBAAQAAAAtAQMABAAAAAYBAgAMAAAAJAMEAGICOABeAjgAXgJIAGIC SAAMAAAAJAMEAGICVABeAlQAXgJkAGICZAAMAAAAJAMEAGICcABeAnAAXgKAAGICgAAMAAAAJAME AGICjABeAowAXgKcAGICnAAMAAAAJAMEAGICqABeAqgAXgK4AGICuAAMAAAAJAMEAGICxABeAsQA XgLUAGIC1AAMAAAAJAMEAGIC4ABeAuAAXgLwAGIC8AAMAAAAJAMEAGIC/ABeAvwAXgIMAWICDAEM AAAAJAMEAGICGAFeAhgBXgIoAWICKAEMAAAAJAMEAGICNAFeAjQBXgJEAWICRAEMAAAAJAMEAGIC UAFeAlABXgJgAWICYAEMAAAAJAMEAGICbAFeAmwBXgJ8AWICfAEMAAAAJAMEAGICiAFeAogBXgKY AWICmAEMAAAAJAMEAGICpAFeAqQBXgK0AWICtAEMAAAAJAMEAGICwAFeAsABXgLQAWIC0AEMAAAA JAMEAGIC3AFeAtwBXgLsAWIC7AEMAAAAJAMEAGIC+AFeAvgBXgIIAmICCAIMAAAAJAMEAGICFAJe AhQCXgIkAmICJAIMAAAAJAMEAGICMAJeAjACXgJAAmICQAIEAAAABgEBAAQAAAAtAQIABAAAAC0B AAAIAAAAJgYPAAYA/////wEAEAAAACYGDwAWAP////8AACUCAAAUAgAAZAIAAC0CAAAEAAAALQEB AAQAAAAtAQMABAAAAAYBAgAMAAAAJAMEADcCHgI3AiICUQIiAlECHgIEAAAABgEBAAoAAAAkAwMA OQIXAigCIAI5AigCCgAAACQDAwBPAikCYAIgAk8CGAIEAAAALQECAAQAAAAtAQAACAAAACYGDwAG AP////8BAAQAAAAtAQQABAAAAC0BAQAHAAAAGwRZAlwCKAIoAgQAAAAtAQAABAAAAC0BAgAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAAkAAAAy CkwCMgIBAAAATAAVAAQAAAAuAQEABAAAAAIBAgAVAAAA+wLr/wAAAAAAALwCAAAAAAAAABJUaW1l cyBOZXcgUm9tYW4AALsEAAAALQEGAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEY AAQAAAACAQEACQAAADIKVAJHAgEAAAAyAAsABAAAAC4BAQAEAAAAAgECAAQAAAACAQIAEAAAACYG DwAWAP////8AAN0AAAD9AAAA/QAAAH0BAAAEAAAALQEBAAQAAAAtAQMABAAAAAYBAgCmAAAAJANR APgAAgH4AP4A8wD/APIA/wDuAAEB6wAEAesABQHqAAoB6gAyAekANgHrADYB6gA1AecAOAHjADoB 5QA7AeQAOQHgADoB4AA6Ad8AOwHeADwB3gA8Ad8APQHgAD4B4AA+AeQAPwHlAD0B4wA+AecAQAHq AEMB6wBCAekAQgHpAEEB6gBGAeoAbgHrAHIB6wBzAesAdAHuAHcB8gB5AfMAeQH4AHoB+AB2AfQA dQHzAHcB9QB2AfEAdAHuAHEB7wByAe0AcgHvAHMB7gBuAe4ARgHtAEIB7QBBAe0AQAHqAD0B5gA7 AeUAOwHgADoB4AA+AeEAPQHiADwB4gA8AeEAOwHgADoB4AA8AeAAPgHlAD0B5gA9AeoAOwHtADgB 7QA3Ae4AMgHuAAoB7wAGAe0ABgHuAAcB8QAEAfUAAgHzAAEB9AADAQQAAAAGAQEABAAAAC0BAgAE AAAALQEAAAgAAAAmBg8ABgD/////AQAHAAAA/AIAAGb//wAAAAQAAAAtAQUABAAAAC0BAQAEAAAA LQEFAAkAAAAdBiEA8AAwAGcAKAF4AAQAAAAtAQUABAAAAC0BAAAEAAAA8AEFAAQAAAAtAQIABQAA AAkCAAAAAgUAAAAUAgAAAAAVAAAA+wLg/wAAAAAAALwCAAAAAAAAABJUaW1lcyBOZXcgUm9tYW4A ALsEAAAALQEFAAQAAADwAQYABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEACQAA ADIKTAGCAAEAAABOABcABAAAAC4BAQAEAAAAAgECABUAAAD7Auv/AAAAAAAAvAIAAAAAAAAAElRp bWVzIE5ldyBSb21hbgAAuwQAAAAtAQYABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAu ARgABAAAAAIBAQAJAAAAMgpUAZkAAQAAADEACwAEAAAALgEBAAQAAAACAQIAFQAAAPsC4P8AAAAA AAC8AgAAAAAAAAASVGltZXMgTmV3IFJvbWFuAAC7BAAAAC0BBQAEAAAA8AEGAAUAAAAJAgAAAAIF AAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAA0AAAAyCkwBpAAEAAAAID0gMggAEgAIABAABAAAAC4B AQAEAAAAAgECAAQAAAACAQIAEAAAACYGDwAWAP////8AAF0AAAA1AAAAlQAAAH0BAAAEAAAALQEB AAQAAAAtAQMABAAAAAYBAgDMAAAAJANkAJAAOgCQADYAiwA3AIYAOACFADkAfgA+AHgARwB4AEgA dwBNAHYAUwB2AL0AdgDCAHQAxwB2AMgAdQDGAG8AzwBoANQAaQDWAGkA1ABkANUAYADWAGAA1gBf ANcAXgDYAF4A2ABfANkAYADaAGAA2gBkANsAaQDcAGkA2gBoANwAbwDhAHUA6gB2AOgAdADpAHYA 7gB4AO4AdgDtAHYA8wB2AF0BdwBiAXcAYwF4AGgBeABpAX4AcgGFAHcBhgB4AYsAeQGQAHoBkAB2 AYwAdQGHAHQBhwB2AYgAdAGBAG8BewBmAXoAaAF8AGcBewBiAXkAYgF7AGMBegBdAXoA8wB6AO4A egDtAHoA7QB4AOgAeADnAHIA3gBrANkAagDYAGUA1wBgANYAYADaAGEA2QBiANgAYgDYAGEA1wBg ANYAYADYAGAA2gBlANkAagDYAGsA1wByANIAeADJAHgAyAB6AMMAegC9AHoAUwB7AE4AfABJAHoA SAB7AEoAgQBBAIgAPACHADoAhwA8AIwAOwAEAAAABgEBAAQAAAAtAQIABAAAAC0BAAAIAAAAJgYP AAYA/////wEABwAAAPwCAAAAmf8AAAAEAAAALQEGAAQAAAAtAQEABAAAAC0BBgAJAAAAHQYhAPAA MABnAMgAAAAEAAAALQEGAAQAAAAtAQAABAAAAPABBgAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEACQAAADIK7AAKAAEAAABOABcA BAAAAC4BAQAEAAAAAgECABUAAAD7Auv/AAAAAAAAvAIAAAAAAAAAElRpbWVzIE5ldyBSb21hbgAA uwQAAAAtAQYABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAJAAAA Mgr0ACEAAQAAADIACwAEAAAALgEBAAQAAAACAQIAFQAAAPsC4P8AAAAAAAC8AgAAAAAAAAASVGlt ZXMgTmV3IFJvbWFuAAC7BAAAAC0BBQAEAAAA8AEGAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4B GAAEAAAAAgEBAA0AAAAyCuwALAAEAAAAID0gNAgAEgAIABAABAAAAC4BAQAEAAAAAgECAAQAAAAC AQIABAAAAC0BAQAEAAAALQEEABAAAAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQAABAAAAC0B BgAEAAAA8AEFAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAA AAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACBAAAAggAAAIMAAACE AAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAA/v///6YAAACQAAAAkQAAAJIA AACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAA AKEAAACiAAAAowAAAKQAAAD+/////v///6cAAAD+////qQAAAKoAAACrAAAArAAAAK0AAACuAAAA rwAAALAAAACxAAAAsgAAALMAAAC0AAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////w8A6AP3AgAAAQDpAygA AACAFgAA4BAAAOAQAACAFgAAKQAAAGAAAAAAAAAAAAAAAAEAAAAAAAABDwDyA/AAAAAvAMgPDAAA ADAA0g8EAAAAAAAAAA8A1QdMAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEA bgAAAPzSYgD80mIACM9iAPjTAzAsz2IACAAAACzPYgB+1AMwAAAGEgAAqQ8KAAAABwAAAAIACQQA AEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA ////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAAAPAAsElAAAAA8AAPCMAAAAAAAG8CAAAAACDAAAAwAAACQAAAACAAAAAQAAAAcAAAACAAAA IgAAAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIYAAa8RgAAAAA zP8A//9mAGb//wAzzP8AM5n/AACZ/wBAAB7xEAAAAACZ/wABAAAIAgAACPcAABAfAPAPHAAAAAAA 8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHiwAAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAA AAIAAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAAqAAAAZAAAACoAAABkAAAAOM9iAH7UAzAw z2IACAAAAJAJAAAsBwAA9P////T///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEAL AAA/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A9YAAAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAA AAAAnw8EAAAABgAAAAAAqg8KAAAAAQAAAAEAAAAAABAAnw8EAAAABQAAAAAAqg8KAAAAAQAAAAEA AAAAAAAA6gMAAAAADwD4A3UIAAACAO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAAFMGAA8Acg AAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAAAA/wD///8AAAAAAP// AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA/8xm AGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAAAAAA gICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADwByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm/wD/ AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAAAAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAAAAEA //0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////ywAAAAA AwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAAAAAGQAFAAAANgAAABAAgAAAAACAAAA///vAAAA AAD///////8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANg AwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAHgAAAAAA AABAAgAAAAACAAAA///vAAAAAAD///////8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAA AAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAA AGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIA AAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAAB AAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwE0wQAAA8A AvDLBAAAEAAI8AgAAAAGAAAABgQAAA8AA/BjBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAAAEAAAFAAAADwAE8NIAAAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEA AQCAAASYdgCHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAA AIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAABAM4ADwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgP IAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAA ACEAAAABAAAAAAAPAATwFgEAABIACvAIAAAAAwQAAAAKAACDAAvwMAAAAH8AAQABAIAAZJh2AIEB BAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAA4ASwAdAUAA8PABHwEAAA AAAAwwsIAAAAAQAAAAIAzgAPAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRp dCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZl bA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoA AABTAAAAAQAAAAAADwAE8LUAAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/AAEAAQCAAMSYdgCB AQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAPsAFgBoAQDwAR8BAA AAAAAMMLCAAAAAIAAAAHAc4ADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFAAAAAIA AAAAAAAAAAACAAAAAAACAA4AAAD4DwQAAAAAAAAADwAE8LcAAAASAArwCAAAAAUEAAAACgAAgwAL 8DAAAAB/AAEAAQCAACSZdgCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDw CAAAAGAPsAfQDoAQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAs4ADwAN8D8AAAAAAJ8PBAAAAAQAAAAA AKgPAQAAACoAAKEPFgAAAAIAAAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAPAATwtwAA ABIACvAIAAAABgQAAAAKAACDAAvwMAAAAH8AAQABAIAAhJl2AIEBBAAACIMBAAAACL8BAQARAMAB AQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA8gENAUgBAPABHwEAAAAAAAwwsIAAAABAAAAAgCzgAP AA3wPwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAO AAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAA AAAAAMyZADMzzADMzP8AsrKyAA8A7gO6EAAAAgDvAxgAAAAAAAAADxAAAAAAAAAAAACAAAAAAAcA BTAPAAwEahAAAA8AAvBiEAAAIAAI8AgAAAAeAAAAIQgAAA8AA/D6DwAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAADwAE8HAAAAASAArwCAAAAAQIAAAACgAA wwAL8EgAAACFAAIAAACHAAEAAACAAQcAAACBAf//ZgCDAfABdhCLAQAApv+MAWQAAACcAQsAAEC/ ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAIABoAtgEqACDwAE8HAAAAASAArwCAAAAAUI AAAACgAAwwAL8EgAAACFAAIAAACHAAEAAACAAQcAAACBAf//ZgCDAfABdhCLAQAApv+MAWQAAACc AQsAAEC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAAADoAvQDiAEDwAE8HAAAAASAArw CAAAAAYIAAAACgAAwwAL8EgAAACFAAIAAACHAAEAAACAAQcAAACBAf//ZgCDAfABdhCLAQAApv+M AWQAAACcAQsAAEC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAAAGoAtwDiAHDwAE8HAA AAASAArwCAAAAAcIAAAACgAAwwAL8EgAAACFAAIAAACHAAEAAACAAQcAAACBAf//ZgCDAfABdhCL AQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAIAHoAvAFaAI DwAE8HAAAAASAArwCAAAAAgIAAAACgAAwwAL8EgAAACFAAIAAACHAAEAAACAAQcAAACBAf//ZgCD AfABdhCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAIAK oAsAD6ALDwAE8FIAAAASAArwCAAAAAkIAAAACgAAcwAL8CoAAACFAAIAAACHAAEAAACBAWb//wC/ ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAAAJoAvwDCAKDwAE8KQAAACiDArwCAAAAAsI AAAACgAAowAL8DwAAACAAESadgCFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADA AQEAAAj/AQAACAABAgIAAAgAABDwCAAAAGoB9gUkCYoCDwAN8DgAAAAAAJ8PBAAAAAQAAAAAAKgP CAAAAFBhY2tldCAxAAChDxQAAAAJAAAAAAAAAAAACQAAAAEAAAABAA8ABPCkAAAAogwK8AgAAAAM CAAAAAoAAKMAC/A8AAAAgAAEm3YAhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAAAwAGLgkgBA8ADfA4AAAAAACfDwQAAAAEAAAAAACo DwgAAABQYWNrZXQgMgAAoQ8UAAAACQAAAAAAAAAAAAkAAAABAAAAAQAPAATwpAAAAKIMCvAIAAAA DQgAAAAKAACjAAvwPAAAAIAAxJt2AIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQ AMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAAAYABi4JIAcPAA3wOAAAAAAAnw8EAAAABAAAAAAA qA8IAAAAUGFja2V0IDMAAKEPFAAAAAkAAAAAAAAAAAAJAAAAAQAAAAEADwAE8KQAAACiDArwCAAA AA4IAAAACgAAowAL8DwAAACAAIScdgCFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAIAHAAYuCaAIDwAN8DgAAAAAAJ8PBAAAAAQAAAAA AKgPCAAAAFBhY2tldCA0AAChDxQAAAAJAAAAAAAAAAAACQAAAAEAAAABAA8ABPCkAAAAogwK8AgA AAAPCAAAAAoAAKMAC/A8AAAAgABEnXYAhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEA ABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACACgAGLgmgCw8ADfA4AAAAAACfDwQAAAAEAAAA AACoDwgAAABQYWNrZXQgNQAAoQ8UAAAACQAAAAAAAAAAAAkAAAABAAAAAQAPAATwpgAAAKIMCvAI AAAAEAgAAAAKAACjAAvwPAAAAIAABJ52AIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8B AAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAAAkABk4KIAoPAA3wOgAAAAAAnw8EAAAABAAA AAAAqA8KAAAAUGFja2V0IEZFQwAAoQ8UAAAACwAAAAAAAAAAAAsAAAABAAAAAQAPAATwpAAAAKIM CvAIAAAAEQgAAAAKAACjAAvwPAAAAIAAxJ52AIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAA CL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAcA7QCPMLkA8PAA3wOAAAAAAAnw8EAAAA BAAAAAAAqA8IAAAARmlndXJlIDMAAKEPFAAAAAkAAAAAAAAAAAAJAAAAAQAAAAEADwAE8F4AAABy BQrwCAAAABIIAAAACgAAkwAL8DYAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEA AAjLAdSUAAD/AQgACAABAgIAAAgAABDwCAAAAFABQAXQBSAEDwAE8LIAAACiDArwCAAAABMIAAAA CgAAkwAL8DYAAACAACSfdgCFAAIAAACHAAYAAAC/AAIAAgCBAWb//wC/ARAAEADAAQEAAAj/AQAA CAABAgIAAAgAABDwCAAAAEAC0AI8BWADDwAN8EwAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAE4xID0g MgAAoQ8qAAAABwAAAAAAAAAAAAEAAAABAAAAAQABAAAAAQAIAAEA5/8FAAAAAQAAAAEADwAE8GQA AABCAQrwCAAAABQIAAAACgAAowAL8DwAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAjLAdSUAADOAQYAAAD/ARgAGAABAgIAAAgAABDwCAAAAKALoAugC7ANDwAE8GoAAABCAQrw CAAAABYIAAAACgAAswAL8EIAAACFAAIAAACHAAEAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjL AdSUAADQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAMAMoAvwDMAMDwAE8LQAAACiDArw CAAAABcIAAAACgAAowAL8DwAAACAAISfdgCFAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/ AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAPAMoAvUDBAODwAN8EgAAAAAAJ8PBAAAAAQA AAAAAKgPAgAAAEwxAAChDyoAAAADAAAAAAAAAAAAAQAAAAEAAAABAAEAAAABAAgAAQDn/wEAAAAB AAAAAQAPAATwUgAAABIACvAIAAAAGAgAAAAKAABzAAvwKgAAAIUAAgAAAIcAAQAAAIEBZv//AL8B EAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAgASgC/AMoAUPAATwpgAAAKIMCvAIAAAAGQgA AAAKAACjAAvwPAAAAIAAxKF2AIUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAEPAIAAAAgAQABk4KoAUPAA3wOgAAAAAAnw8EAAAABAAAAAAAqA8K AAAAUGFja2V0IEZFQwAAoQ8UAAAACwAAAAAAAAAAAAsAAAABAAAAAQAPAATwUgAAABIACvAIAAAA GggAAAAKAABzAAvwKgAAAIUAAgAAAIcAAQAAAIEBAJn/AL8BEAAQAMABAQAACP8BCAAIAAECAgAA CAAAEPAIAAAAAAnwDEAOIAoPAATwZAAAAEIBCvAIAAAACggAAAAKAACjAAvwPAAAAIUAAgAAAIcA AQAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAAM4BBgAAAP8BGAAYAAECAgAACAAAEPAI AAAAUAHwDPAMsA0PAATwZAAAAEIBCvAIAAAAGwgAAAAKAACjAAvwPAAAAIUAAgAAAIcAAQAAAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACMsB1JQAAM4BBgAAAP8BGAAYAAECAgAACAAAEPAIAAAAUAFA DkAOsA0PAATwagAAAEIBCvAIAAAAHAgAAAAKAACzAAvwQgAAAIUAAgAAAIcAAQAAAEQBBAAAAH8B AAABAL8BAAAQAMABAQAACMsB1JQAANABAQAAANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAwAzw DEAOwAwPAATwtAAAAKIMCvAIAAAAHQgAAAAKAACjAAvwPAAAAIAAFCt2AIUAAgAAAIcABgAAAL8A AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA8AzwDCQOEA4P AA3wSAAAAAAAnw8EAAAABAAAAAAAqA8CAAAATDIAAKEPKgAAAAMAAAAAAAAAAAABAAAAAQAAAAEA AQAAAAEACAABAOf/AQAAAAEAAAABAA8ABPBeAAAAcgUK8AgAAAAeCAAAAAoAAJMAC/A2AAAAhQAC AAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywHUlAAA/wEIAAgAAQICAAAIAAAQ8AgA AAAABkAF0AXQCA8ABPCyAAAAogwK8AgAAAAfCAAAAAoAAJMAC/A2AAAAgACUKXYAhQACAAAAhwAG AAAAvwACAAIAgQFm//8AvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADwBtACPAUQCA8A DfBMAAAAAACfDwQAAAAEAAAAAACoDwYAAABOMSA9IDIAAKEPKgAAAAcAAAAAAAAAAAABAAAAAQAA AAEAAQAAAAEACAABAOf/BQAAAAEAAAABAA8ABPBeAAAAcgUK8AgAAAAgCAAAAAoAAJMAC/A2AAAA hQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAIywHUlAAA/wEIAAgAAQICAAAIAAAQ 8AgAAABQAUACYAPQCA8ABPCyAAAAogwK8AgAAAAhCAAAAAoAAJMAC/A2AAAAgAB0K3YAhQACAAAA hwAGAAAAvwACAAIAgQEAmf8AvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACwBAAAbALQ BQ8ADfBMAAAAAACfDwQAAAAEAAAAAACoDwYAAABOMiA9IDQAAKEPKgAAAAcAAAAAAAAAAAABAAAA AQAAAAEAAQAAAAEACAABAOf/BQAAAAEAAAABAA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA AAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAAAAchcQAAAAAQAwAAAAAAD/AgAAfAsA AAAA9Q8cAAAAAAAAAIMVAAMAAAAAPhwAAAEAAAADAAAAAAAJMAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAADEVCAAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAADAAAAEAAAAFRpbWVzIE5ldyBSb21h bgAPAAAARGVmYXVsdCBEZXNpZ24ADwAAAE5vIFNsaWRlIFRpdGxlAAwQAAAGAAAAHgAAAAsAAABG b250cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAA AFNsaWRlIFRpdGxlcwADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+ /wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAAC0AQAAEQAAAAEA AACQAAAAAgAAAJgAAAADAAAA4AAAAAQAAAD0AAAABQAAAAgBAAAGAAAAFAEAAAcAAAAgAQAACAAA ADQBAAAJAAAASAEAABIAAABUAQAACgAAAHABAAAMAAAAfAEAAA0AAACIAQAADgAAAJQBAAAPAAAA nAEAABAAAACkAQAAEwAAAKwBAAACAAAA5AQAAB4AAAA9AAAAQSBnZW5lcmljIFVuZXZlbiBMZXZl bCBQcm90ZWN0aW9uIChVTFApIHByb3Bvc2FsumsruD4VYx2R61Nl6U4tnwXjZyQ269TJMdtAYvMz tZvu2gru5hFjI5ErUGXpri1/BhibSWw2Kkt3bQXNshhbSGw2q5Nj1krkClTtpru2gsZZjBdIbFrV bpi9ROQKVGjzbcdp2t4/eF3byWabpB1Y13ae5KyrBsErB7Frqze3ksw0CG6O2W0k45qbY/ZdknHN zTFLSca1cl0bjLtIRtPNMZtPMq51/OkpswUk41q5rg3GvSSjWa5rg/F9ktEs17XB+B+S0XRzzJaS jGvlujYYy0hG080x+xHJuFaua4PxCMloluvaYDxGMpodfzLKbA3JuFaua4PRTDKa5bo2GE+SjGa5 rg1GC8loluvaYPwvyWi6OWY/JxnXynVtMH5JMpqd1jjPGWBsJBnNooau4O4VMTaRjGZRE5fPgrGF ZDSLmrh8FoyMZDSLmrh8FoznSUazqInLZ8H4HcloFjVx+SwY20hGs6iJK/iXRjG2k4xmURNXcFeO GK+SjGZRE1d0F2q9eZ1kNIuauHwWjDdIRrOoictnwXiTZDSLmrh8Foy9JKNZ1MTls2DsIxnNoiau 4F9QxQirIKNZ1MTls2BYktEsauLyWTBqSUbTWb/5je+uNxjdSUbTWf673mD8C8nazCDfxOWzYPQk Gc2iJq6ol6w3vUhGs6iJK+ol6817SEazqInLZ8F4H8loFjVx+SwYHyAZTWetW+e76w3Gh0hGs6iJ y2fBGEAymkVNXNHdzfXmwySj6ayf/MTX38H4KMloFjVx+SwYR5OMZlETl8+CMZhkNIuauHwWjONJ RrOoictnwRhKMppFTVzBnWhifJxkNIuauHwWjGEko1nUxOWzYHySZDSLmrh8FoxPkYxmUROXz4Ix kmQ0i5q4og603owiGc2iJq7gjgMxziAZzaImLp8F4wsko1nUxOWzYJxFMppFTVw+C8a5JKNZ1MTl s2CcTzKaRU1cwR0TYowlGc2iJi6fBWM8yWgWNXH5LBj1JKNZ1MTls2BcSDKaRU1cPgvGRSSj6Sz/ XW8wJpGMZlETV3CXohiTSUazqIkruqO/3kwhGU1n+e96g3ElyWgWNXH5LBhXk4xmURNX1LfWm2tI RrOoiSvqW+vNdJLRLGri8lkwZpCMZlETV9S31pubSEazqIkr+k6FevNtktEsauLyWTBuIRnNoiYu nwVjFsloluvUYNxBMppujtlcknGtXNcGYx7JaHY2rfXmHpJxrVzXBuO/SEbTzTH7b5JxrVwHB+N+ ktEs18HBWEwymuW6NhhLSEazXNcG4yGS0SzXtcFYTjKanR1rvXmYZFwr17XBeJRkNN0csyaSca3N /+d1ba1mjaQdWNeG74T9nTzw1srB69pqK3NIUmkQOv79QWYLScI1N8dsCUm41vGRltkqknCtXNcG 40mS0OxsSWorG0jCtY7GV2ZbSMK1cl0bjG0koVmua4OxiyQ0y3VtMPaRhGbnlWRtpVsVJFwr17XB 6E0Smm6OWT+ScK1c1wZjEEloluvaYAwlCc3Or6drK8NJwrVyXRuMOpLQLNe1wRhDEprlujYYE0hC 080xm0wSrpXr4GBMIwnNcl0bjJtIQrNc1wZjNkloluvaYMwnCc1yXRuMxSShWa5rg7GCJDTLdW0w mklCs1zXBmM9SWg6y/8dpjA2k4Rmua4NxlaS0CzXtcF4jSQ0y3VtMPaQhGa5rg1GtQYkNMt1bTB6 koRmua4NRl+S0CzXtcE4kiQ0y3VtMIaQhGa5rg3GKSShWa5rgzGKJDSd5f8OUxjnkISms/Rdb0Xf KVZbGU8SmuW6NhiTSEKzXNcGYypJaJbr2mDMIAnNcl0bjEaS0CzXtcG4iyQ0y3VtMBaRhGa5rg3G MpLQLNe1wWgiCc1yXRuMFpLQLNe1wdhIEprlujYYrSSh6azVq31dG4ztJKFZrmuDsZskNMt1bTBM LUholuvaYPQgCc1yXRuM95KEZrmuDcYAktAs17XBOJYkNMt1bTBiktAs17XBGEkSms5atGi4JwvG aJLQLNe1wfgySWiW69pgTCQJzXJdG4wpJKFZrmuDMZ0kNMt1bTAaSELTWX/jO0zFmEsSmuW6NhgL SUKzXNcGYylJaJbr2mCsIgnNcl0bjLUkoVmua4OxgSQ0y3VtMJ4jCc1yXRuMbSShWa5rg/EHktDs 7Np896/B2EcSmuW6NhjdDwEJzXJdG4zeJKHprG99y3evHIx+JKFZrmuDMYgkNMt1bTCGkoSms/Rd bwX/piLGCJLQLGroCr7bUYw6ktAsauIKrgHFOJ8kNDtaeJlNIAnXipq4/BlgXEoSmkWNW/4MMKaR hGZR41ZwDSjGTJLQdHPMZpOEa0VNXMH9pGJ8jyQ0i5q4/BlgLCYJzaImLp8FYyVJaLo5Zs0k4VpR E1dwHSfGz0hC080x20wSrrX5/7zvML2h8htJO7Ambr6E1NQEwWB78Jq4xZVGEtkGoeMrZpnNJpFt VHPM5pDIzlZzzOaRyGKtXBMHYz6J7Dy1G2YLSWTnqzlmi0hkF6oUfxMHYzGJ7KIuVr3vs1CMJSSy i5Xlb+JgLCORXaJOjtkKEtllajd/EwdjFYnsCrUbZk0ksqvUbv4mDkYziWyTsvxNHIwnSWSb1Rkw ayGRfVLt5m/iYKwnkW1Rlr+Jg7GBRHa9svxNHIyNJLIb1Mkx20Qiu1Ht5m/iYGwhkd2kLH8TB6OV RHZLF2ucJwvGVhLZVmX5mzgY20hktyrL38TB2E4iu01Z/iYOxqskstuV5W/iYOwikX1VWf4mDsZu EtldyvI3cTD2kMjuVpa/iYOxj0R2j7L8TRwMUwWR3acsfxMHo0oiC7NcEwejG4lsVVn+Jg5GDxLZ bsryN3EwepLI9lCWv4mD0ZtEtqey/E0cjD4ksr2V5W/iYPQlke2jLH8TB6MfiWxfZfmbOBgDSGT7 KcvfxME4kkR2gLL8TRyMQSSyRyrL38TBOIZEdpCy/E0cjCEksscoy9/EwRhKIjtEWf4mDkZMIjtU Wf4mDsYpJLKxsvxNHIzhJLKnKMvfxME4jUR2uLL8TRyMUSSypynL38TBqCORHaUsfxMHYzSJbJ2y /He9wTiHRHa0svxNHIwxJLLnKMvfxMEYSyI7Rln+Jg7GeBLZscryN3EwJpDIjleWv4mDMZFEdoKy /E0cjEkkshOV5W/iYEwmkZ2kLH8TB2MKiexkZfnveoMxlUR2irL8TRyMaSSyU5Xlb+JgTCeRnaYs fxMH4wYS2enK8jdxMG4ikb1BWf4mDkYDiexNyvobTZwYjUSuiZTlb+JgzCZyxaQsfxMHYy6R6yll +Zs4GPNIZOcqy9/EwZhP5GpLWf4mDsZCItdiyvI3cTAWEblSU5a/iYOxmMiVmrL8TRyMpUSu1JTl b+JgLCORXaosfxMHYwWR6zhl+Zs4GKuIXMcpy3/XG4wmIld5yvI3cTCaiVzlKcvfxMF4kshVnrL8 TRyMFiLXgMryN3Ew1hO5BlSWv4mDsYHINaCy9P8Jrui7NeX6j8g1oLL8d8zB2EzkClFZ/jvjYGwh kYXZcQ0os1Yi14BqN/8dczC2ErkGVJb/jjkY24hcAyrLf8ccjO1ErgGV5b9jDsZrRK4B1fPFbBeJ 7GtqN/8dczB2E7nKU7thtofIdZzQ5v/z7pgbaPfib4zSPZ17dsH6t9VrtV+aOaLjebelrLNfr9ZZ lxLsl2I6nt3+LeCEquwpj79M3t5V7Wz9Ok7BX/qZ1chunV9TdAsvIIPDyULn/PMyA1fK/Eo1/67M QJPMm9R8i8xAxUwWOucfMheQz8r8s2p+ocxAo8wb1XyJzMCvZf5rNf+DzMDh8lXT4ZXO+ccqF5Dx Mh+v5tfJDNwv8/vVfK3MwA6Z71DzQ+0FZIh8bTXEds6/IDNwlcyvUvO5MgOPy/xxNf8/mYFqdbLQ Oe9fvYCcLvPT1XyizMBtMr+t2vbxCXOfw/t/junPeffRPtzOCq+t9Ar7G/05hF2Kfp5I7wD3cS59 u+3zY7X7THnXWRMnTbi8X92EK/uNvmTS+P8Mgq1d//v86z/p5OiwD98aOc+/ytvjul8SxgYnP3P8 1y6eMKXf4OOCjwQDgqOEwyX/I+1W2G6ZLm/zz+5kk1Saww+Xenblz9jXnKLPeNyBnbFVzlhvDvYZ H+96xiEHdsYbKkmltnKwz/jVSpczHn9gZxxok8rig37Gqu1yxhMO7Izr7FuVOnvwzvhunvEBOWP3 zjOe9ukRXU95XHBiEP+dJ/1GTe/qnurjlYP7ap5ds6mCV/O0iRd+47IJ+C/n3XLSo+WcA4Jenldz /7/BJsqJ+gg1ktXH7v/vVp1/Z+HnXQ2oXBTsC/uH+8L3hjvD94UvhB8IW8MPhk+HUdgSHhX+ODwx XBV+Mnwk/FS4PDwz/GH4JeE8syycYB4ML5W3l5ql4SRzfzjVfC+83twR3mxmho2mIbxduMVcG95m LpHfg6+Hd5iLwrnydp68f7es3SOPWSDcLc73xL1P9lgie62UPZtl7ybJaJK368wPw2eEX1aWh1nl kfCVyqpwR+XH4Z8qLWFonw672dbwMPtC+E67M+xl94W9hUPl991lViMcal8KD7HPhsb+ItxTeSp8 XdyXKk2yzxNCk+y5WvZeLRmPSdZKyVwRPipn+IFZFC4yd4XzTWOYyjnnyplntz+fu83l8jymyOxy eV6XyNu253QXH9cYzhFvlvgzZZ/rZL8psu+l5DF57VbLa7haXssmeU2fkNe2Sfhx+JnwqXBY+Ivw +PDZcFD4UjhQPh79hSPlYzMgPLC/y1rNF8N6c0FwsD5nD2v/k/Q6Prqu37B+J8h/R72CY/6uz9Vv ycIzwu2261dbf+3rq1n2OXsjsdVZQuf8iOqNZJTMR6n5f8gMzJL5rNJfDxSdM6q2fVU4rsQ5V9ph 1ZV2ZPXUKhjWkdud65XgEftv1QY7vPqIPa/qZp+ojqleXB1e/UR1UPUf+xj/qjq4em61xR6sj3E3 fox/WH3e4uecfU7+pPT/Odl5Lrx+e807eS731VBozBFfvOryKRMmuZNVOr4Kz/+0O/2r60/Hw1na vur/fyuUfjEeHQAARABkAAAAAAAAAAIAAAAAAAAAAAAAAAAA9xf1EegD6AMAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBCAAAAsgQK8AgAAAADBAAAAAoAAFMAC/AeAAAABEEDAAAA PwEAAAYAgQERAAAQvwEMAB8A/wEAAAgAAAAQ8AQAAAACAACAMgAH8IgcAAADBGom2u5vef1AZgKv kQkSNsX/AGQcAAABAAAAHB8AAAAAogBgIRvwXBwAAGom2u5vef1AZgKvkQkSNsXyfgAAAAAAAAAA AACWCQAALwcAAAhxOwBIiywAKhwAAAD+eJzFnQuYFMW5hru6ZgahxYCiRDbYyEUUXBBYFFAwAgZU RBBUrgJykZCQeCcIxqBGRUAhIuIdRULw1pyA4QiK0SZBjfeHCNHEmBhCvBDRqK0Icv7vm52dWrot y4DH9Xmfmf1r3vpreme3p78tXOXV9Tw99XjP28fb5OGjoXBY4Vvet71d8uF5DbzSxwJ5aPs6Hgw+ Yh8+wpfPGldXWrCS8yq8wf0HDGjkPbXNOwpmI+EfjS+pnqde9aPr8VGe53sf6tpzavnsW9WVRnxU ztvXU1JR1XPkhcAv3dvXb19nQd2c3Mup+p4s0dshY1y+h2qlKq56u5+njZHm1SOq1iOaFg71tnmd 69yOT2pGas9Rc0Bq5vB5lLDag6qP2ir5fG7B81bLo+vXwdEtjhc4rrz68vlnxkzlp1acUfN51cUj uOZGfmnMz+jWRxe7DS5kd/sqc70jAwultlnmaat2n8urOWrFo1z6ehSrOd7WkdvS1+Dzz8fXjObl a+h5LXXOS3L3ertIqBKhVEetkAeh2mXUUduPhApjpTpqB5FQYazUdefOctcCb7cZ3WE0JaE6yJgN tVYkVE2NOmqVJFStjC47dpjPrdilUNMFRhUJVWUta5xlbTCOI6GqMqzPPhtn6QWjNwnVccbKUetH QtXbmG37dtsaYAwioepnzIbacBKqQcZsn3461rI2GGNJqIYb1iefjLWsAcYkEqqxxhpQu4CEapIx W5KcY1kDjEtJqC4wrI8/PseyBhgzSKguNayPPrL1gjGThGqGYX344RhLLxjzSKhmGs8XtYUkVPOM 2T74YIxlDTAWkVAtNKz33x9tWQOMX5FQLTLWgFpEQvUrY7b33htlWQOMVSRUkWH9+9+jLGuA8TgJ 1SrD2rr1bEsvGOtJqB43rHffPdvSC8bzJFTrDeudd2y9YLxCQvW8Yb311khLLxivk1C9Ylhbtoyw 9IKxmYTqdcP65z9HWHrB2EpCtdmwNm8ebukF4yMSqq2G9eabwyy9YOwgofrIsP72t2GWXjByBRCq HYb1xhtDLb1g7EtCBbNkvf76EEsvGAcQeUUb1p//PMTSC0YFCdUBhvXqq2dZesFoQUJVYVibNp1p 6QWjDQlVC8PauPEMSy8YHUmo2hjWhg1nWHrB6EZC1dGwXn55sKUXjJ4kVN0M68UXB1l6wTiJhKqn YT3//OmWXjAGklCdZFjPPjvQ0gvGUBKqgYb19NMDLL1gjCahGmpY69efZukFYyIJ1WjD+t3v+lt6 wTiPhGqiYcVxf0svGFNIqM4zrCeeONXSC8blJFRTDGvt2n6WXjCuIaG63LAeffQUSy8Y15NQXWNY q1efbOkFYwEJ1fWGtWrVSZZeMO4koVpgWA8/3NfSC8YSEqo7DWvFij6WXjAeJKFaYljLl3/P0gvG wyRUDxrWgw+eaOkF4zESqocN64EHelt6wVhHQvWYYS1b1svSC8azJFTrDOuXv+xp6QVjAwnVs4a1 ZElPSy8Yr5FQbTCse+75rqUXjDdJqF4zrEWLvmvpBeMdEqo3DevOO4+39ILxAQnVO4Z1++09LL1g bCeh+sCwbrmlu6UXDL8OCNV2w1q48DhLLxh1SahglqwFC4619ILRkISqrmHdeOOxll4wDiahamhY v/hFN0svGM1IqA42rLlzu1p6wTichKqZYd1wQ1dLLxhHkVAdblhz5nSx9ILRhYTqKMOaNesYSy8Y x5NQdTGsmTOPsfSC0YeE6njDuvbaoy29YJxGQtXHsK6+urOlF4wzSahOM6yf/7yzpReMs0mozjSs K6+ssvSCMYGE6mzDuuKKTpZeMCaTUE0wrBkzOll6wbiYhGqyYf3sZ7ZeMC4jobrYsH76046WXjCu IqGCWaqjNpuE6ipjtunTO1jWAGM+CdVsw5o2rYNlDTBuI6Gab6wBtcUkVLcZs1166VGWNcC4n4Rq sWFNnXqUZQ0wVpBQ3W9YP/mJrReM1SRUKwxrypT2ll4wniShWm08X9SeIaF60pjtkkvaW9YA4yUS qmeM2VD7EwkVxop+rmY1xc/96tvi/HWUSqVnpdQPqSQ+mtd6XpXVaVdFrpl6VbolOXPebTWPSqdy WcnbcfK4UQXPe8GSvJnPwyVr66s+I7FKhFIdtc9JzLFSHTU/D2KO1ZyHpJYnMcfcsjYYdUlMs+b8 JLX6JOZYqY5aAxJzzC1rg9GIxDTdsjYY3yYxTbesDUYFiWnWXPtJLSQxx9yyNhjNSUyzVEftMBJz zC1rg9GGxDTdsjYYlSSmWU4w+6oOJOaYW9YGozOJabplbTC6kJimW9YG4zgS0yznoX3V8STmmFsG B6MXiWm6ZW0w+pCYZtkabekF42QS08xK6NK9YPQnMc2sJC7dC8bpJKaZlcSle8E4g8Q0s5K4dC8Y Q0lMMyuJy7gOF2MEiWlmJXHpXjBGk5hmVhKX7gVjHIlpZiVx6V4wziUxzawkLt0Lxg9ITDMriUv3 gvFjEtPMSuLSvWBcQGKaWUlcuheMS0hMMyuJS/eCMZXENLOSuHQvGJeRmGY5ibNlajBmkJhmVhKX 7gXjKhLTzEri0r1gXEtimiXrlVdsmRqM2SSmmZXEpXvBuIHENLOSuHQvGDeSmGZWEpfuBWMBiWlm JXHpXjBuJTHNrCQu3QvGnSSmWbKeeWaApReMu0lMMyuJS/eCsYTENLOSuHQvGMtITLNkPfmkLVOD 8QCJaWYlceleMJaTmGZWEpfuBWMFiWlmJXEZ78XFWEVimllJXLoXjDUkppmVxKV7wVhLYppZSVy6 F4wnSUwzK4lL94LxexLTzEri0r1gPE1imiXroYdOtPSC8RyJaWYlceleMF4kMc2sJC7dC8YGEtPM SuIyMjUxNpGYZlYSl+4F4zUS08xK4tK9YPyVxDSzkrh0LxhvkphmVhKXkd+J8U8S08xK4tK9YLxN Ypol69Zbu1t6wdhKYppZSVy6F4z3SUwzK4lL94LxEYlplqz58235HYxPSEwzK4lL94Kxg8Q0s5K4 dC8YXgHENEvW9dfbMjUYmsQ0s5K4dC8YdUhMMyuJS/eCUY/ENLOSuHQvGPuRuGh66SQu3QvG/iSm mZXEpXvBOJDENLOSuHQvGAeTmGZWEpeRt4rRlMQ0s5K4dC8YzUhMMyuJS/eC0ZLENLOSuHQvGK1J TDMriUv3gtGWxDRL1mWX2fI7GO1JTNMtp4PRkcQ03XI6GEeTmKZbHgejG4lpluqodScxx9xyOhgn kJimW04HozeJabrldDD6kphmqY5aPxJzzC2ng3EaiWnWpNhSG0RijhX9ry+nW6cGS7c9y+mukj5H Fzyvsd57Od1cfzsJdCLU/NZIajtJoLcbddRUHgR6p1FHLUcCjTG3nA5GHRJomDU/eaVWj8hMRh21 +iTQ9Ywu9pwORkMS6Pq1rHGWtcFoRALd0LDsOR2MxiTQjYyVo9aEBLqxMZs9p4PRlAS6iTEbaoeS QDc1ZrPndDBakkAfalj2nA5GaxLolsYaUGtDAt3amC1JbGuAUUkC3caw7DkdjA4k0JWGZc/pYFSR QHcwLHseB+MYEugq4/mi1o0E+hhjNntOB6M7CXQ3w7LviYNxAgl0d2MNqPUmgT7BmM2+Jw5GHxLo 3oZl3xMH42QS6D6GZd8TB+NUEuiTDcu+Jw7GQBLoUw3r7bdtmRqMwSTQAw3LvicOxlkk0IMNy74n DsYwEuizDMu+Jw7GSBLoYYZl3xMHYwwJ9EjDsu+JgzGOBHqMYdn3xME4lwR6nGHZ98TBmEQCfa5h 2ffEwZhMAj3JsMwkLt0Lxvkk0JMNy74nDsZFJNDnG5Z9TxyMKSTQFxmWfU8cjEtJoKcYln1PHIzL SKAvNSz7njgYM0igLzMs+544GFeRQM8wLPueOBjXkEBfZVj2PXEwriOBvsawzCQu3QvGHBLo6wzL vicOxlwS6DmGZd8TB2M+CfRcwzKTuHQvGDeTQM83LPueOBi3kkDfbFj2PXEw7iCBvtWw7HviYCwi gb7DsOx74mDcSwK9yLDse+JgLCWBvtewVq607YmDcR8J9FLDsu+Jg/EgCfR9hvUle+LEWE4C/aBh mUlcVgY6119JAr3csOx74mCsIoFeaVj2PXEwVpNArzKspUtt+R2Mx0igVxuWfU8cjN+SQD9mWGYS l+4FYx0J9G8Ny74nDsZ6Euh1hmXfEwfjGRLo9YZl3xMH4zkS6GcMy0zi0r1gvEgC/Zxh2ffEwdhA Av2iYdn3xMHYSAK9wbDse+JgvEoCvdGw7HviYPyFBPpVw7LviYPxBgn0XwzLvicOxj9IoN8wLPue OBhbSKD/YVj2PXEw3iaB3mJY9j1xMLaSQL9tWPY9cTC2kUBvNSz7njgYH5JAbzOsq66yZWowEhLo Dw3LvicOxnYi1+yGZd8TB2MnkSt6w7LviYPhFYBc7xuWfU8cjBwJNMysJC7dC0YdEuicYZlJXLoX jHpEDMMyk7h0Lxj1SaDrGZaZxKV7wWhAAg2zVEetEQl0A2M2M6HLyArEaEwC3ciwzCQuvQYYTUig GxuWmcSle8FoSgLdxLDMJC7dC0YzEuimxvNFrSUJdDNjNjOJy8pn5/qtSaBbGrOh1oYEGmNFP1ez muLney+J21e3lW57lsQdLk3OlIZr9mISV6V1HkQ6yUU1Rwe1/UjEsZrfGEitCYk4Vs6MqnQrEnHM LYmD0YFENMsZSpU+jkQcK9VR60sijrklcTAGkYimWxIHYxSJaLolcTAmkYhm+Sq0Sl9CIo65JXEw ZpCIZvnKqkquPEDEMbckDsZCEtF0S+Jg3EsimuX34lU6IhHH3JI4GGtIRNMtiYOxnkQ03ZI4GC+T iKZbEgfjdRLRLNVRe4tEHHNL4mB8RCKabkkcDK8AIprlM1yV3pdEHHNL4mA0JhFNtyQORgsS0XRL 4mC0IxFNtyQORjcS0SxZ9n+dCuNEEtF0S+JgDCQRTbckDsYIEtF0S+JgTCQRTbckDsZFJKLplsTB uJxENN2SOBizSETTLYmDsYBENN2SOBj3kIimWxIH40ES0XRL4mA8QiKabkkcjHUkoumWxMF4kUQ0 3ZI4GK+RiKZbEgdjC4louiVxMD4gEU23JA7G5ySi6ZbEwahbB0Q03ZI4GAeSiKZbEgejGYlouiVx MI4kEU23JA5GFxLRdEviYPQiEU23JA7GaSSiWbLWrLElcTCGkYimWxIHYwKJaLolcTDOJxFNtyQO xmUkoumWxMG4lkQ03ZI4GPNJRNMtiYNxF4louiVxMO4nEU23JA7Gb0hE0y2Jg/EkiWi6JXEwniMR TbckDsafSETTLYmDsZlENN2SOBjbSETTLYmDsYNENEuW/V+nwqizD4houiVxMA4gEU23JA7GISQq mp5LEgejDYlouiVxMDqTiKZbEgfjBBLRdEviYPQjEU23JA7GEBLRdEviYIwlEU23JA7Gj0lE0y2J g3EpiWi6JXEwriYRzZJl/9epMOaRiKZbEgfjDhLRdEviYCwjEc2sTC1jJ7gYK0lEs+Z3D1L7LYk4 lpW1ZST7YvyBRDSzsrb0GmBsJBHNrKwt3QvG30lEMytrS/eC8W8S0SzVUfuURBzLytrSa4CRrwsi mllZW3oNMBqQiGZW1pbuBeM7JKKZlbWle8FoTSKaNemY1DqRiGNZWVt6DTB6kIhmqY7aySTiWNH/ +na9LdenSLc9y9rOEy4qSK/83svapuc+Iwn/K9VR20USjpXqqOk8SDhWzuam5wok4Zhb1gajHklo 1mTSUtuPJBwrJ33Tc/uThGNuWRuMg0hC0y1rg9GEJDTdsjYYTUlCsyY/ltqhJOGYW9YGoxVJaJYz yum5I0jCMbesDUYlSWi6ZW0wOpCEZjkPnZ6rIgnH3LI2GF1IQtMta4NxHEloumVtML5LEppuWRuM 3iShWaqj1pckHHPL2mD0IwlNt6wNxmkkoVlzNSW1QSThmFvWBuMsktB0y9pgDCcJTbesDcYoktB0 y9pgjCUJTbesDcYEktB0y9pgTCIJTbesDcaPSELTLWuDcQFJaLplbTAuIQlNt6wNxqUkoemWtcH4 KUloumVtMGaQhKZb1gbj5yShWc7abP9qFcZMktB0y9pgzCEJTbesDcY8ktAsWea/P8147yvGTSSh 6Za1wVhIEppuWRuM20lC0y1rg7GIJDTdsjYY95KEplvWBuNXJKFZsuz/JzgYD5CEplvWBiMiCU23 rA3GCpLQLFn2/xMcjFUkoemWtcFYQxKablkbjMdJQtMta4MRk4SmW9YGYz1JaLplbTCeIQnNkmX/ P8HBeJ4kNN2yNhgvk4SmW9YG4xWS0CxZ9v8THIxXSULTLWuD8TpJaLplbTD+RhKablkbjM0koemW tcF4iyQ03bI2GFtJQtMta4PxPkloumVtMD4iCU23rA3GpySh6Za1wdhBEppuWRsMrwASmm5ZG4wc SWi6ZW0w9iEJTbesDca+JKHplrXBaEASmm5ZG4wDSELTLWuD0ZgkNN2yNhgVJKHplrXBCElC0y1r g9GCJDTdsjYYrUlC0y1rg9GGJDTdsjYY7UhC0y1rg9GRJDRLln3XG4yjSUIzK6HL+heX03PdSEIz K4nL+t359FwPktDMSuLSvWD0JAnNrCQu3QvGiSShmZXEZf2efnruJJLQLNVRO5UkHMtK4tJrgDGQ JDSzkrj0GmCcQRKaWUlcuheMoSShmZXEpXvBGEESmqU6aqNJwrGsJC69BhjjSEKzVEdtIkk4VvS/ vl1vn+S+L93ck7jSs5tg/D2L/O7d/OY1R7HYZXDu2vymmrzPy3w25ZwxV32rqu3G6l/6Nm+2b9qw sv6SxIEe/pbFQ7uKC3nUr376+w/+/uTxFzbrP35Ks9N/PHnMj+QCsvZX5ov/xkU79W3e+rKeA+S2 Y72PvSU+jsuAMWN/MP6iZh06ekd4Lb12wne8RnK/aKlqy691m35269RW3VfNdXp27mtcrJaZa+y4 Z2vcV2/Vc/29vcZ3/Fpr7LRna1wua6zSe3uNN+haa6zaszV+ktuqp+f29ho35mqtsfOerXFwbmJu 0148jgdxjZ1kjfXKa/zeib1qr7Kjd4x37Fdc6dJCRb5tYZ3eu0fz6sKfNY7m975/7sUXjMersrGs tNJrJSu1Hc3df0fRBe/JpHal3P6hZnXln6DFj2JV87Ygszzl4TxwjjfNny9c513sz/LO82d7P/Sv 98b6N3qj/Ju9Ef7t3jD/Lm+of683xF8mNFBn+QeqM/0marhwln+QGuxXqAH+IaqP31Kd7LcWmqve cr9HNcf6h6mu/hFye6R83k7G2stjjhLaitNe3CqZo4vM1V3m7Cpzd5X7PdQQv5ewTA31H1LD/BVq hL9KjfLXqLH+4+qH/u/Uef7v1cX+U2oaWSv310rtUeEJdaHcn+T/r5rgr5THLxdvhRonjJW5zpE5 z5G5x0iP0dLrbP9o6dtBelaq/v7hsq7DZI2tqtffTvWUdfeS9feUeg+5LT6HdvK4I+XxbcVrJX5z maepzNeEjJFjdI4cK+klx/Jeb5wcw1HCWH+xN8G/05vk3+pd6N8kx3uesECO/U3VXxdV89r6KufF Qs3XvPR5+a86TfP2UR97Var2I0tnxsIev5br8rU8UPVT+KtI/TO+t4pnyqedz5Tld0Tu/Seoa9i/ g3yPZ/f/6mfqglP/+tXPfzGPcLPuzTo28tp/pe/f93NFPhf+mt/9d4rl79iaK2J5F/UBCfM7hHK9 e/4DMl7q4436lVID90v9fqP+tNTAJqlvyru+ArPWP1jWPUeY57D+FvnJ+Rb5KflhZHJN33oc114r qSKDb5WfmS/VhuSvy1+dvyA/JD88/2Xry/4ZrgvT89fka78z3PPX/d/zDfJ43fWTs8o38bpP8n3y xdd9xRe+3r7aO+k61cdron9t/l31Ze+k63zB0Z7oT8y96/he8+v9/iy+K+jj78m7gpoz6S3mz9wv O4KDc40Lm/Q1+S/6iVs6grt/P/0sXzyfX593+3kwK3+DN4OskvurjPofpQZ2yv2dRr1CzSC91Cyh XB8jNTBT6jON+lKpgRek/oJR3yo1cKA/SyjXO/kzyHCpDzfqU6UG7pb63Ub9camBLVLfYtTzegap 1LOEUn12/hR9BblQzxbK9XlSA49I/RGjvlFqYJfUdxn1prkryIm52UK5PlZqYJbUZxn1ZVIDL0n9 JaP+ntRA4/xsoVzvnL+CjJT6SKM+TWpgsdQXG/UnpAY2Sf2//3ncoFB8/TQtuL1+Kgo3eA3JKrm/ yqj/UWpgp9zfadQrVEPSS1UUyq+fisIYqYGZUp9p1JdKDbwg9ReM+lapgQP9ikL59VNR6OQ3JMOl PtyoT5UauFvqdxv1x6UGtkh9i1HP64akUlcUyq+fisIpUgMXSv1Coz5PauARqT9i1DdKDeyS+i6j 3jTXkJyYqyiUXz8VhbFSA7OkPsuoL5MaeEnqLxn196QGGucrCuXXT0Whc74hGSn1kUZ9mtTAYqkv NupPSA1skvp///rBzx+cz/H6cTmf/1rO4b+Wc/nbJH0+Xynnc5y7Vxrn83/J+fygwgX5f+3B+Two XJOv/dN1b5zP7/qGz+evsH9Hy/k86/rvOr/6+k9/8derfMV3kz/Nn+Vf7M/2z/Pn+HLF54/15/uj /IW+XPH5w/xF/lB/iT/Ev09ooOWKT8sVn5YrPrnfWMsVnx7gh1qu+PTJ/uFCCy1XfLqH34oc67fW Xf02clspn7eXsaPkMR2EI8VpL25nmaOLzNVd5uwqc3eV+z20XPEJ9+mhfqSH+Su1XPHpUf6jWq74 tFzxabni03LFp6eRtXJ/rdQeFZ7QcsWn5YpPT/AflscvF2+lHieMlbnOkTnlik/LFZ+WKz4tV3zS t4P0bKf7c/2tZY2HVa+/ve4p6+4l6+8p9R5yW3wO7eRxlfL4tuIdJn5zmecQma8JkSs+6dEAveRY LvHHyTEcJcgVnz/Bv8uf5N/myxWfHO9fCDfLsV/g78kVX363r3J+tyu+xC9d8ZUT1t3fwf3/vxcr vsZP19/steK5+pu9Vjxd//fXitu84rl9qrJ/r2/i9/ok73w1X7jOG69meUPVDd6Zap53irrZ66kW ed3UfV6V+o3XST3itVe/l/4bhM2qUv1HHaE8v53QVu1QrdQ+/iFqf/9A1cSvp5r5+6mWQuj7qoX/ sdeS/Mc7zH/fO0Juj5TP28lYe3lMJ6GdOB3F7SJznOC3UqcwM2mnBvlHCJVqtNz/kXC5bq/m6E7q Vl2l7tDd1DLdU63Qp6g1+kz1hB6qYj1erdfnq6eEtXL/Mak9IqzVI9VqfbpaqU9SD+gT1D36WLVA d5F5ugtdZc4uMncX6XGM9OokPTuqAf6RzHi6+d9RHfyGqq2s8whZc6vq59PO3y7P4zN5PtvleX0s t8XnVMnHNVStxTtU/INlnm/JfFrm9cgxcuy6yDHsIseyqxzT7nJsuwjHqse8E9T/eCeppd7p6k5v pFooX4/5wi3ytfnq6U/tK5Har4La6U9dJdPt9si9nf6M8A/2vsnv6PP9wV7xrPnNfEeP8M/zqr+j q77sO7r21yrH7/DP/Ab8ypbWp3y/+aCpF140fnL6t4TpvxBvftT+i/I4JsWr0/8DJ4AHcwAAAAAA AAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACAQIAAAAhAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAGQAAADkAQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAbAAAAFgBAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAByAAAAagAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAACBmb3IgQW5uZXggSQAAVQAeAAAACQAAAFByb3Bvc2FsACBVbh4AAAALAAAAQWRhbSBILiBM aQBuHgAAAAEAAAAAZGFtHgAAAAEAAAAAZGFtHgAAAAsAAABOb3JtYWwuZG90AG4eAAAACwAAAEFk YW0gSC4gTGkAbh4AAAACAAAAOABhbR4AAAATAAAATWljcm9zb2Z0IFdvcmQgOS4wAHZAAAAAAJ6t /R8AAABAAAAAAOLDv0nLvwFAAAAAAIbkzlbMvwEDAAAAAQAAAAMAAACsBAAAAwAAAKMaAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAAB AAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAAoAQAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAAgAAAAAYA AACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAAsAAAABYAAAC4AAAADQAA AMAAAAAMAAAACQEAAAIAAADkBAAAHgAAAAUAAABVQ0xBAABpAAMAAAA4AAAAAwAAAA0AAAADAAAA tiAAAAMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAD0AAABB IGdlbmVyaWMgVW5ldmVuIExldmVsIFByb3RlY3Rpb24gKFVMUCkgcHJvcG9zYWwgZm9yIEFubmV4 IEkADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29m dCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAUABMACgABAGkADwADAAAAAwAAAAAAOAAAQPH/AgA4AAwABgBOAG8AcgBtAGEAbAAAAAIAAAAY AENKGABfSAEEYUoYAG1ICQRzSAkEdEgJBAAARgACQAEAAgBGAAwACQBIAGUAYQBkAGkAbgBnACAA MgAAABAAAgAGJAETpPAAFKQ8AEAmARIANQiBNgiBT0oCAFFKAgBhShQAAAAAAAAAAAAAAAAAAAA8 AEFA8v+hADwADAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQA AAAAAAAAAAAAAAAAOgD+TwEA8gA6AAwABABIAGUAYQBkAAAAEAAPAAMkAw3GBQABBxrAYSQDDwBh ShQAbUgJCHNICQh1CAAAKABVQKIAAQEoAAwACQBIAHkAcABlAHIAbABpAG4AawAAAAYAPioBQioC PgBCQAEAEgE+AAwACQBCAG8AZAB5ACAAVABlAHgAdAAAABYAEQANxhEABab/AABoAXYCOAQAAAAA AAQAYUoUAEgAQ0ABACIBSAAMABAAQgBvAGQAeQAgAFQAZQB4AHQAIABJAG4AZABlAG4AdAAAABYA EgAPhGgBEYSY/hOkeABehGgBYISY/gAAAAAAAE4gAAAHAAA2AAAGAP////8AAAAAAQAAADIAAAA9 AAAAVQAAAHcAAACdAAAAuAAAALkAAADEAAAAxQAAAIUDAACGAwAACQYAACkGAACKBwAAiwcAAOYI AAAACQAAAQkAAKEKAACiCgAA8QwAAPIMAADMDgAAzQ4AACMQAABDEAAAwRMAANsTAADcEwAAoxQA AKQUAAAwFgAAMRYAAD4XAAA/FwAAPhkAAD8ZAAAsGgAANRoAADYaAABXGgAAWBoAAIkbAACKGwAA 8hwAABIdAABRHgAAUh4AAF0eAABeHgAAXx8AAGAfAABqHwAAax8AAOMfAABNIAAAUCAAAJgAAAAP MAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgBgAAAACMAAAAAAAAACAAAAAgBgAAAACMAAA AAAAAACAAAAAgBgAAAACMAAAAAAAAACAAAAAgBgAAAACMAAAAAAAAACAAAAAgBgAAAACMAAAAAAA AACAAAAAgBgAAAACMAAAAAAAAACAAAAAgBgAAyACMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA uQAAAJgAAAAAMAAAAAAAAACAuQAAAJgAAAAAMAAAAAAAAACAuQAAAJgAAAARMAAAAAAAAACAuQAA AJgAAAAAMAAAAAAAAACAuQAAAJgAAAAAMAAAAAAAAACAuQAAAJgAAAAAMAAAAAAAAACAuQAAAJgA AAARMAAAAAAAAACAuQAAABgAAyACMAEAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA5ggAAJgAAAAR MAAAAAAAAACAAAAAgJgAAAARMAAAAAAAAACA5ggAAJgAAAARMAAAAAAAAACA5ggAAJgAAAARMAAA AAAAAACA5ggAAJgAAAARMAAAAAAAAACA5ggAAJgAAAAAMAAAAAAAAACA5ggAAJgAAAAAMAAAAAAA AACA5ggAAJgAAAAAMAAAAAAAAACA5ggAAJgAAAAAMAAAAAAAAACA5ggAABgAAyACMAIAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAfhIAAJgAAAAAMAAAAAAAAACAfhIAAJgAAAAAMAAAAAAAAACAfhIA AJgAAAAAMAAAAAAAAACAfhIAAJgAAAAAMAAAAAAAAACAfhIAAJgAAAAAMAAAAAAAAACAfhIAAJgA AAAAMAAAAAAAAACAfhIAAJgAAAAAMAAAAAAAAACAfhIAAJgAAAAAMAAAAAAAAACAfhIAAJgAAAAA MAAAAAAAAACAfhIAABgAAyACMAMAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA6RgAAJgAAAAAMAAA AAAAAACA6RgAAJgAAAAAMAAAAAAAAACA6RgAAJgAAAAAMAAAAAAAAACA6RgAAJgAAAAAMAAAAAAA AACA6RgAAJgAAAAAMAAAAAAAAACA6RgAAJgAAAAAMAAAAAAAAACA6RgAAJgAAAAAMAAAAAAAAACA 6RgAAJgAAAAAMAAAAAAAAACA6RgAABgAAyACMAQAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACADx0A AJgAAAAAMAAAAAAAAACADx0AAJgAAAAAMAAAAAAAAACADx0AAJgAAyAAMAUAAAAAAACADx0AAJgA AAAAMAAAAAAAAACAfR8AAJgAAAASMAAAAAAAAACAfR8AAJgAAAASMAAAAAAAAACAfR8AAJoAAAAA MAAAAAAAAACAAAAAgAAEAAAEIgAAZSUAABUAAAAaAAAAAAQAAAENAADyIAAAZSUAABYAAAAYAAAA GQAAAAAEAABlJQAAFwAAAAkGAAAlBgAAJwYAACMQAAA/EAAAQRAAAPIcAAAOHQAAEB0AAE4gAAAT OpT/lYATOpT/lYATOpT/lYD//w4AAAALAF8AMQAwADAANwA1ADIAOQAyADMANAALAF8AMQAwADAA NwA1ADIAOQA1ADMANwALAF8AMQAwADAANwA1ADIAOQA1ADYANgALAF8AMQAwADAANwA1ADIAOQA4 ADkANgALAF8AMQAwADAANwA3ADIANwAwADgANwALAF8AMQAwADAANwA3ADQAMgA5ADkAMwALAF8A MQAwADAANwA3ADQAMwAwADYANAALAF8AMQAwADAANwA3ADIANwAzADUAOQALAF8AMQAwADAANwA3 ADQAMgA5ADQANgALAF8AMQAwADAANwA3ADQAMgA5ADYANwALAF8AMQAwADAANwA3ADQAMwAwADgA MAALAF8AMQAwADAANwA3ADYAMQA1ADAAMwALAF8AMQAwADAANwA3ADYAMgAwADkAOQALAF8AMQAw ADAANwA3ADYAMQA1ADMAMAAlBgAAJQYAACUGAAAlBgAAJQYAACUGAAAlBgAAPxAAAD8QAAA/EAAA PxAAAD8QAAA/EAAADh0AAFAgAAAAAABAAQAAQAIAAEADAABABAAAQAUAAEAGAABABwAAQAgAAEAJ AABACgAAQAsAAEAMAABADQAAQCUGAAAlBgAAJQYAACUGAAAlBgAAJQYAACUGAAA/EAAAPxAAAD8Q AAA/EAAAPxAAAD8QAAAOHQAAUCAAAAAAAABZCgAAXwoAAIALAACKCwAAUg0AAFsNAABxHAAAchwA ANYfAADhHwAAQCAAAEsgAABQIAAABwAEAAcAHAAHABwABwAcAAcAHAAHABwABwAAAAAAcQgAAH0I AAAqEQAANhEAALcRAADWEQAAcBIAAHwSAADBEwAA2hMAAA4bAAASGwAAax8AAOIfAADjHwAATCAA AFAgAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA//8UAAAACgBBAGQAYQBtACAA SAAuACAATABpABUARAA6AFwAVwBvAHIAawBcAEgAMwAyADMAXABJAGQAZQBhAC4AZABvAGMACgBB AGQAYQBtACAASAAuACAATABpAEgAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBjAGEA dABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABv AFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABJAGQAZQBhAC4AYQBzAGQACgBBAGQA YQBtACAASAAuACAATABpAEgAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBjAGEAdABp AG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIA ZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABJAGQAZQBhAC4AYQBzAGQACgBBAGQAYQBt ACAASAAuACAATABpABUARAA6AFwAVwBvAHIAawBcAEgAMwAyADMAXABJAGQAZQBhAC4AZABvAGMA CgBBAGQAYQBtACAASAAuACAATABpAEgAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBj AGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUA dABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABJAGQAZQBhAC4AYQBzAGQACgBB AGQAYQBtACAASAAuACAATABpABUARAA6AFwAVwBvAHIAawBcAEgAMwAyADMAXABJAGQAZQBhAC4A ZABvAGMACgBBAGQAYQBtACAASAAuACAATABpAEgAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABw AGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQA XABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYAIABJAGQAZQBhAC4AYQBz AGQACgBBAGQAYQBtACAASAAuACAATABpABUARAA6AFwAVwBvAHIAawBcAEgAMwAyADMAXABJAGQA ZQBhAC4AZABvAGMACgBBAGQAYQBtACAASAAuACAATABpABUARAA6AFwAVwBvAHIAawBcAEgAMwAy ADMAXABJAGQAZQBhAC4AZABvAGMACgBBAGQAYQBtACAASAAuACAATABpAEgAQwA6AFwAVwBJAE4A RABPAFcAUwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkAYwByAG8AcwBv AGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABvAGYA IABJAGQAZQBhAC4AYQBzAGQAAwAuWBAQELHkuP8P/w//D/8P/w//D/8P/w//DxAAxioLLUyBBDj/ D/8P/w//D/8P/w//D/8P/w8QAN1MA3UPAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQACAAAAAAABAAAA AAAAAAAAAAAAAAAAAAADGAAAD4QIBxGEmP4VxgUAAQgHBl6ECAdghJj+bygAAQAAAAEAAAAEgAEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhNgJEYSY/hXGBQAB2AkGXoTYCWCEmP4CAAEALgABAAAAAoIB AAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SoDBGETP8VxgUAAagMBl6EqAxghEz/AgACAC4AAQAAAACA AQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EeA8RhJj+FcYFAAF4DwZehHgPYISY/gIAAwAuAAEAAAAE gAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEgSEYSY/hXGBQABSBIGXoRIEmCEmP4CAAQALgABAAAA AoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QYFRGETP8VxgUAARgVBl6EGBVghEz/AgAFAC4AAQAA AACAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E6BcRhJj+FcYFAAHoFwZehOgXYISY/gIABgAuAAEA AAAEgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhLgaEYSY/hXGBQABuBoGXoS4GmCEmP4CAAcALgAB AAAAAoIBAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SIHRGETP8VxgUAAYgdBl6EiB1ghEz/AgAIAC4A AQAAAAAQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAAu AAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEA LgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgAC AC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIA AwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4C AAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/ AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY /gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCE mP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlg hEz/AgAIAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNAC YISY/gIAAAAuAAMAAAAuWBAQAAAAAAAAAAAAAAAA3UwDdQAAAAAAAAAAAAAAAMYqCy0AAAAAAAAA AAAAAAD//////////////////wMAAAAAAAAAAAD//wMAAAAAABIADwAJBBkACQQbAAkEDwAJBBkA CQQbAAkEDwAJBBkACQQbAAkEAAAAAAAAUCAAAAEAAAD/QAGAAABeCgAAXgoAANzXZAADAgMCXgoA AAAAAABZCgAAAAAAAAIoAAAAAAAAAOkdAADpHgAATiAAAHAAAAgAQAAAcAAAIgAAAABwAABIAEAA AP//AQAAAAcAVQBuAGsAbgBvAHcAbgD//wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAA AAD//wAAAgD//wAAAAAEAAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAA AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQ AAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIc6AAAAAAAAAAAA AAAAAAD/AAAAAAAAAEEAcgBpAGEAbAAAAEcRkAGACgAAAAAAAAAAAAABAAAAAAAHCBAAAAAAAAAA AAACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAAAC3/M/8gAA5mHWcAACIABABxCIgYAPDQAgAAaAEA AAAAr/tFZrUNRoYAAAAACADlAAAArAQAAKMaAAABAA0AAAAEAAMQOAAAAAAAAAAAAAAAAQABAAAA AQAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBMjAAABAA GQBkAAAAGQAAALYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB CQAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAQyg1EA8BAA3wMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAPABBACAAZwBlAG4AZQByAGkAYwAgAFUAbgBlAHYAZQBu ACAATABlAHYAZQBsACAAUAByAG8AdABlAGMAdABpAG8AbgAgACgAVQBMAFAAKQAgAHAAcgBvAHAA bwBzAGEAbAAgAGYAbwByACAAQQBuAG4AZQB4ACAASQAIAFAAcgBvAHAAbwBzAGEAbAAAAAAACgBB AGQAYQBtACAASAAuACAATABpAAoAQQBkAGEAbQAgAEgALgAgAEwAaQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0006_01BFCC1F.83D21920-- From rem-conf Sat Jun 03 08:00:53 2000 From rem-conf-request@es.net Sat Jun 03 08:00:50 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 12yF8V-0004db-00; Sat, 3 Jun 2000 07:42:51 -0700 Received: from ip146.houston2.tx.pub-ip.psi.net ([38.11.201.146] helo=machine) by mail2.es.net with smtp (Exim 1.92 #1) for rem-conf@es.net id 12yF8P-0004dR-00; Sat, 3 Jun 2000 07:42:46 -0700 From: To: Date: Sat, 3 Jun 2000 06:09:14 Message-Id: <532.808971.156292@machine> Subject: Tired Of Earning What Someone Else Thinks You Are Worth? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Have You Dreamed Of: -Owning Your Own Time? -Controlling your Financial Future? -Feeling Good About What You Do And Helping Others? Are you? -Tired Of Working For Someone Else   For What "They" Feel You Are Worth? --Tired Of The MLM Scene? -Looking For A Legitimate Home-Based Enterprise That Can Generate You $10k-20k+ Monthly? THEN CHECK THIS OUT -Make $1,000 to $15,000 Profit On Every Sale And our System Does The Selling For you. -Free Enterprise......Not MLM Or Franchise. -Full Training And Support In An Environment Of Utmost Integrity. -Lead Generation System That Brings Qualified Prospects to You. -A Multiple 6-Figure Income is Realistically Attainable in 1st Year. -2 to3 year Retirement Program...Period! -This Program Is All About Money...How To   Make It, How To Keep It, And How to Make   It Work For you. CALL: 1-800-320-9895  Ext. 5433 Free Recorded Message From rem-conf Sat Jun 03 22:47:32 2000 From rem-conf-request@es.net Sat Jun 03 22:47:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12yT3V-0002pk-00; Sat, 3 Jun 2000 22:34:37 -0700 Received: from mail.sktelecom.com (sktelecom.com) [203.236.1.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 12yT3U-0002nX-00; Sat, 3 Jun 2000 22:34:36 -0700 Received: from server (8-118.sktelecom.com [203.236.8.118] (may be forged)) by sktelecom.com (8.10.1/8.10.1) with SMTP id e545cD202564 for ; Sun, 4 Jun 2000 14:38:13 +0900 (KST) Message-ID: <002401bfcde7$519c4b00$bb0d0296@sktelecom.com> From: =?ks_c_5601-1987?B?wMy1v7Hi?= To: Subject: Date: Sun, 4 Jun 2000 14:39:52 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01BFCE32.BE4765A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0021_01BFCE32.BE4765A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUNCg== ------=_NextPart_000_0021_01BFCE32.BE4765A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MTkuNjMwNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj48Rk9OVCBmYWNlPUNvdXJpZXIgc2l6ZT0yPnVu c3Vic2NyaWJlPC9GT05UPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0021_01BFCE32.BE4765A0-- From rem-conf Sun Jun 04 21:39:36 2000 From rem-conf-request@es.net Sun Jun 04 21:39:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12yoW5-0005De-00; Sun, 4 Jun 2000 21:29:33 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 12yoW3-0005DT-00; Sun, 4 Jun 2000 21:29:31 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id NAA07151; Mon, 5 Jun 2000 13:28:56 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id NAA05396; Mon, 5 Jun 2000 13:28:55 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id NAA24235; Mon, 5 Jun 2000 13:28:55 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id NAA46300; Mon, 5 Jun 2000 13:28:54 +0900 (JST) Message-ID: <01fa01bfcea6$81e49f00$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Shigeru Fukunaga" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Stephan Wenger" Cc: "Yoshihiro Kikuchi" References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 5 Jun 2000 13:28:32 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Stephan, Fukunaga-san, all, Thank you very much for your reply. I'm one of the authors of the I/D, but I myself is not a NEWPRED proponent. I'm writing here just as an editor. There are two things discussed in the thread: (1) Stephan's proposal to add the FIR description to the I/D, and (2) How to treat NEWPRED RTCP part (section 5) of the I/D. These two issues are related, but I'm afraid these are too much mixed up throughout the discussion. (1) FIR (Stephan's proposal) I also think that it may have some value to have a feedback mechanism that covers all MPEG-4 Visual Profiles but not only ARTS Profile. However, we need to know exactly what the proposal is to add any technical change on the I/D. We heard only a rough idea on Stephan's proposal. We also need to discuss whether Stephan's proposal matches best to the I/D, or some others. These requires precise description on the proposal, and probably requires further discussions. I think it is hard to take the third way proposed in Stephan's latest mail to add the FIR description to the I/D at this very late stage. It would be nice to have a discussion in the future. (2) NEWPRED RTCP (section 5) It is true that NEWPRED RTCP covers only ARTS Profile. It would be desired to have feedback mechanism that covers all MPEG-4 Visual Profiles. This does need further discussions and thus impossible to add it to the I/D, but could be nice to have such scheme in a separate I/D. I don't want to prevent the future discussions for such feedback mechanism, Stephan's or whatever, that can be used combined with the RTP part of the I/D. To clarify this, I would like to propose adding some descriptions to the I/D that show the followings. - The RTCP described in section 5 is OPTIONAL. The use of this RTCP is limited to NEWPRED in ARTS Profile. - For profiles other than ARTS, some feedback mechanisms other than NEWPRED may be defined in separate documents and may be used combined with the MPEG-4 Visual RTP part of the I/D. Comments are welcome. Best regards, Yoshihiro ----- Original Message ----- From: Stephan Wenger To: Shigeru Fukunaga ; Yoshihiro Kikuchi ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT Sent: Thursday, June 01, 2000 9:47 PM Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > Dear Shigeru, group, > > Thanks for your reply. > > >At first, we would like to describe only MPEG-4 specific things in this > >draft. > >As FIR is a common technique for all video coding, other common document > >seems to be appropriate. > > Ok, so you propose to leave "common" feedback mechanism like FIR to > some other place, and put only "MPEG-4" specific feedback stuff into > your payload spec. I'm not sure that this is the right thing to do, for three > reasons: 1) unavailability of a 'general' feedback spec, 2) previous > payload specs contents and 3) the difficulty to define "common feedback > mechanisms". > > Regarding 1) > When we discussed RFC2429, covering H.263+, we had already adopted > reference picture selection (NEWPRED), due to work of your company (OKI). > Early Internet drafts of RFC2429 suggested at least two different ways > to handle NEWPRED feedback, but were deleted from the drafts because > of scaling problems. > Several people though of coming up with a 'unified feedback solution', but, > until now, nothing happened. This might be partly lack of interest, and partly > the difficulty of the problem. Consequently, when adopting your draft > unchanged, there would not be a standardized way to perform FIR and > similar in IETF environments such as SIP. The only way to respond to > packet losses, beyond responding on RTCP receiver reports, would be > to use NEWPRED. Correct me if I'm wrong here. > > Regarding 2) > There are currently two categories of RTP payload specs with respect to the > feedback problem. Category one defines RTCP feedback, and category > two does not. There are, to the best of my knowledge, no payload specs > proposed or accepted that follow your idea to include only a few feedback > mechanisms specific to a media coding and not in include other known > ones for the same media coding. Certainly, not so important ones like FIR. > > Regarding 3) > FIR is common to all video coding? Well, people not using compression > (BT565) will disagree. Audio folk will disagree. Motion JPEG proponents will > also disagree. On the other hand, NEWPRED is unique to MPEG-4? You > know that H.263+, available as a standard since 1998, includes NEWPRED > as well, so NEWPRED is NOT unique to MPEG-4. A strong argument to > include NEWPRED into a unified RTCP feedback RFC? Furthermore, there > are mechanisms like Slices out there, which are available in many, but not all, > predictive video coding standards. Are they candidates for a 'common' feedback > doc, or should they go into a RTCP section of a specific payload? > > >Second, new proposal just before the last call is not good. We largely > >discussed > >the issues of RTCP for NEWPRED since Adelade meeting, and revised text. > >It also takes much time to discuss FIR, however, we have enough time. > > With this I disagree strongly. > > First let me say, that I'm not on a mission to prevent MPEG-4 ES packetization > to move forward. It's not my plan to artificially delay the process, and > if it would be, > then I'm sure that the our chairs would be able to move forward with the draft > regardless of my concerns. If people in the ITU-T want to prevent MPEG-4 > from happen in H.323, then there are other fori more appropriate to achieve > that > goal. > Having said this, however, I have to emphasize that a) we are talking about a > Internet Draft, b) that you asked for comments, and c) that I see an > architectural > flaw here. I'm aware that additional delay may cause some delay in ITU-T > Q.13/16 and Q.14/16 work (on H.245 for example) as well (meaning that > possible the adoption of MPEG-4 visual/audio to H.323 would be delayed > somewhat). That could be a reason for us (me and you guys) to work harder, > but not to let a draft pass that contains known architectural problems. > > Can you please inform this group about your timing constraints? Why the rush? > > The way to move forward: > > I see three ways to move forward from now > 1) Someone convinces me that I should shut up and let things go. Probably I'm > stickling to principles that are not the general principles of AVT. Anyone > besides the proponents of the draft (outside the MPEG core)? > 2) Delete section 5 (the rest seems to be, apart from language/editorial > problems, > ok, at least to me). Work together with interested parties, including > myself, on > a unified feedback solution, in a separate RFC or a set of separate RFCs. > 3) Leave section 5 and bring it into such a shape that it can incorporate other > feedback schemes, including FIR and SLice Re-transmission at least. I'm > still working on my changes for that. > > Stephan > > > From rem-conf Mon Jun 05 01:04:13 2000 From rem-conf-request@es.net Mon Jun 05 01:04:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12yrmv-0000Ht-00; Mon, 5 Jun 2000 00:59:09 -0700 Received: from mailrelay2.lrz-muenchen.de [129.187.254.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 12yrmt-0000Hj-00; Mon, 5 Jun 2000 00:59:07 -0700 Received: from [129.187.12.34] by mailout.lrz-muenchen.de with ESMTP; Mon, 5 Jun 2000 09:59:04 +0200 Sender: a2824av@lrz.de Message-Id: <393B5DC8.3EC0AE4D@lrz.de> Date: Mon, 05 Jun 2000 09:59:04 +0200 From: Karim Tripodoro Organization: Leibniz Rechenzentrum X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.13 i586) X-Accept-Language: de-DE, en MIME-Version: 1.0 To: majordomo@mbone.de, rem-conf@es.net, rem-conf-de@mbone.de Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe mbone-de From rem-conf Mon Jun 05 01:45:16 2000 From rem-conf-request@es.net Mon Jun 05 01:45:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ysRZ-0001Gf-00; Mon, 5 Jun 2000 01:41:09 -0700 Received: from adsl-63-193-136-149.dsl.lsan03.pacbell.net (okwhatever.com) [63.193.136.149] by mail1.es.net with esmtp (Exim 1.81 #2) id 12ysRX-0001GV-00; Mon, 5 Jun 2000 01:41:07 -0700 Date: Mon, 5 Jun 2000 01:42:49 PST Message-Id: <200006050142.AA899350922@okwhatever.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Frank Basso" Reply-To: To: fukunaga444@oki.co.jp , 4on2andIP-sys@advent.ee.columbia.edu , rem-conf@es.net , stewe@cs.tu-berlin.de , kiku@eel. CC: kiku@eel.rdc.toshiba.co.jp Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format X-Mailer: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe ---------- Original Message ---------------------------------- From: "Yoshihiro Kikuchi" Date: Mon, 5 Jun 2000 13:28:32 +0900 >Dear Stephan, Fukunaga-san, all, > >Thank you very much for your reply. > >I'm one of the authors of the I/D, but I myself is not a NEWPRED proponent. >I'm writing here just as an editor. > >There are two things discussed in the thread: (1) Stephan's proposal to add >the FIR description to the I/D, and (2) How to treat NEWPRED RTCP part >(section 5) of the I/D. These two issues are related, but I'm afraid these >are too much mixed up throughout the discussion. > >(1) FIR (Stephan's proposal) >I also think that it may have some value to have a feedback mechanism that >covers all MPEG-4 Visual Profiles but not only ARTS Profile. However, we >need to know exactly what the proposal is to add any technical change on the >I/D. We heard only a rough idea on Stephan's proposal. We also need to >discuss whether Stephan's proposal matches best to the I/D, or some others. >These requires precise description on the proposal, and probably requires >further discussions. > >I think it is hard to take the third way proposed in Stephan's latest mail >to add the FIR description to the I/D at this very late stage. It would be >nice to have a discussion in the future. > >(2) NEWPRED RTCP (section 5) >It is true that NEWPRED RTCP covers only ARTS Profile. It would be desired >to have feedback mechanism that covers all MPEG-4 Visual Profiles. This does >need further discussions and thus impossible to add it to the I/D, but could >be nice to have such scheme in a separate I/D. > >I don't want to prevent the future discussions for such feedback mechanism, >Stephan's or whatever, that can be used combined with the RTP part of the >I/D. To clarify this, I would like to propose adding some descriptions to >the I/D that show the followings. > >- The RTCP described in section 5 is OPTIONAL. The use of this RTCP is >limited to NEWPRED in ARTS Profile. >- For profiles other than ARTS, some feedback mechanisms other than NEWPRED >may be defined in separate documents and may be used combined with the >MPEG-4 Visual RTP part of the I/D. > > >Comments are welcome. > >Best regards, >Yoshihiro > >----- Original Message ----- >From: Stephan Wenger >To: Shigeru Fukunaga ; Yoshihiro Kikuchi >; 4on2andIP-sys ><4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT >Sent: Thursday, June 01, 2000 9:47 PM >Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > > >> Dear Shigeru, group, >> >> Thanks for your reply. >> >> >At first, we would like to describe only MPEG-4 specific things in this >> >draft. >> >As FIR is a common technique for all video coding, other common document >> >seems to be appropriate. >> >> Ok, so you propose to leave "common" feedback mechanism like FIR to >> some other place, and put only "MPEG-4" specific feedback stuff into >> your payload spec. I'm not sure that this is the right thing to do, for >three >> reasons: 1) unavailability of a 'general' feedback spec, 2) previous >> payload specs contents and 3) the difficulty to define "common feedback >> mechanisms". >> >> Regarding 1) >> When we discussed RFC2429, covering H.263+, we had already adopted >> reference picture selection (NEWPRED), due to work of your company (OKI). >> Early Internet drafts of RFC2429 suggested at least two different ways >> to handle NEWPRED feedback, but were deleted from the drafts because >> of scaling problems. >> Several people though of coming up with a 'unified feedback solution', >but, >> until now, nothing happened. This might be partly lack of interest, and >partly >> the difficulty of the problem. Consequently, when adopting your draft >> unchanged, there would not be a standardized way to perform FIR and >> similar in IETF environments such as SIP. The only way to respond to >> packet losses, beyond responding on RTCP receiver reports, would be >> to use NEWPRED. Correct me if I'm wrong here. >> >> Regarding 2) >> There are currently two categories of RTP payload specs with respect to >the >> feedback problem. Category one defines RTCP feedback, and category >> two does not. There are, to the best of my knowledge, no payload specs >> proposed or accepted that follow your idea to include only a few feedback >> mechanisms specific to a media coding and not in include other known >> ones for the same media coding. Certainly, not so important ones like >FIR. >> >> Regarding 3) >> FIR is common to all video coding? Well, people not using compression >> (BT565) will disagree. Audio folk will disagree. Motion JPEG proponents >will >> also disagree. On the other hand, NEWPRED is unique to MPEG-4? You >> know that H.263+, available as a standard since 1998, includes NEWPRED >> as well, so NEWPRED is NOT unique to MPEG-4. A strong argument to >> include NEWPRED into a unified RTCP feedback RFC? Furthermore, there >> are mechanisms like Slices out there, which are available in many, but not >all, >> predictive video coding standards. Are they candidates for a 'common' >feedback >> doc, or should they go into a RTCP section of a specific payload? >> >> >Second, new proposal just before the last call is not good. We largely >> >discussed >> >the issues of RTCP for NEWPRED since Adelade meeting, and revised text. >> >It also takes much time to discuss FIR, however, we have enough time. >> >> With this I disagree strongly. >> >> First let me say, that I'm not on a mission to prevent MPEG-4 ES >packetization >> to move forward. It's not my plan to artificially delay the process, and >> if it would be, >> then I'm sure that the our chairs would be able to move forward with the >draft >> regardless of my concerns. If people in the ITU-T want to prevent MPEG-4 >> from happen in H.323, then there are other fori more appropriate to >achieve >> that >> goal. >> Having said this, however, I have to emphasize that a) we are talking >about a >> Internet Draft, b) that you asked for comments, and c) that I see an >> architectural >> flaw here. I'm aware that additional delay may cause some delay in ITU-T >> Q.13/16 and Q.14/16 work (on H.245 for example) as well (meaning that >> possible the adoption of MPEG-4 visual/audio to H.323 would be delayed >> somewhat). That could be a reason for us (me and you guys) to work >harder, >> but not to let a draft pass that contains known architectural problems. >> >> Can you please inform this group about your timing constraints? Why the >rush? >> >> The way to move forward: >> >> I see three ways to move forward from now >> 1) Someone convinces me that I should shut up and let things go. Probably >I'm >> stickling to principles that are not the general principles of AVT. >Anyone >> besides the proponents of the draft (outside the MPEG core)? >> 2) Delete section 5 (the rest seems to be, apart from language/editorial >> problems, >> ok, at least to me). Work together with interested parties, including >> myself, on >> a unified feedback solution, in a separate RFC or a set of separate >RFCs. >> 3) Leave section 5 and bring it into such a shape that it can incorporate >other >> feedback schemes, including FIR and SLice Re-transmission at least. >I'm >> still working on my changes for that. >> >> Stephan >> >> >> > > > From rem-conf Mon Jun 05 02:50:58 2000 From rem-conf-request@es.net Mon Jun 05 02:50:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12ytSb-0002Y8-00; Mon, 5 Jun 2000 02:46:17 -0700 Received: from wodc7-1.corprelay.mail.uu.net [192.48.96.68] by mail1.es.net with esmtp (Exim 1.81 #2) id 12ytSa-0002Xx-00; Mon, 5 Jun 2000 02:46:16 -0700 Received: from neserve0.corp.us.uu.net by wodc7mr1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: neserve0.corp.us.uu.net [153.39.201.88]) id QQisgd16016; Mon, 5 Jun 2000 09:46:15 GMT Received: by neserve0.corp.us.uu.net id QQisgd19162; Mon, 5 Jun 2000 05:46:14 -0400 (EDT) From: jhall@UU.NET (Jeremy Hall) Message-Id: Subject: Re: RTP MPEG1/2 In-Reply-To: from "Wilson C. Chung" at "Jun 1, 2000 07:54:05 pm" To: wchung@ix.netcom.com Date: Mon, 5 Jun 2000 05:46:14 -0400 (EDT) CC: rem-conf@es.net X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Lame has an mp3rtp program that encodes it. There are various decoders out there that are supposed to work with other programs. Unfortunately, the only one I am aware of for UNIX is a propriatory version that does not coe in source form. _J In the new year, Wilson C. Chung wrote: > Is there any implementation of RTP encapsulation of MPEG1/2 streams? > > Tx, Wilson C. Chung, VMLabs > From rem-conf Mon Jun 05 04:46:19 2000 From rem-conf-request@es.net Mon Jun 05 04:46:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12yvF3-00046f-00; Mon, 5 Jun 2000 04:40:25 -0700 Received: from mrs-1-fix.smartworld.net (mrs-1.smartworld.net) [216.70.64.24] by mail1.es.net with esmtp (Exim 1.81 #2) id 12yvF1-00046V-00; Mon, 5 Jun 2000 04:40:23 -0700 Received: from localhost.localdomain (IDENT:root@1Cust233.tnt4.daytona-beach.fl.da.uu.net [63.22.0.233]) by mrs-1.smartworld.net (8.9.1a/8.9.1) with SMTP id HAA07251 for ; Mon, 5 Jun 2000 07:40:35 -0400 (EDT) From: Scott Johnson Reply-To: shogunx@operamail.com To: rem-conf@es.net Subject: Re: subscribe Date: Mon, 5 Jun 2000 07:05:07 -0400 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: MIME-Version: 1.0 Message-Id: <00060507052500.00764@localhost.localdomain> Content-Transfer-Encoding: 8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe From rem-conf Mon Jun 05 05:55:56 2000 From rem-conf-request@es.net Mon Jun 05 05:55:54 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 12ywMg-0002Sr-00; Mon, 5 Jun 2000 05:52:22 -0700 Received: from iisc.ernet.in ([144.16.64.3]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 12ywMU-0002Sb-00; Mon, 5 Jun 2000 05:52:19 -0700 Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id SAA15748 for ; Mon, 5 Jun 2000 18:17:25 +0530 (IST) Received: by ece.iisc.ernet.in (SMI-8.6/SMI-4.1) id SAA21212; Mon, 5 Jun 2000 18:16:42 +0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <200006051246.SAA21212@ece.iisc.ernet.in> Subject: RTP and CTI To: rem-conf@es.net Date: Mon, 5 Jun 2000 18:16:42 +0530 (GMT+05:30) X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am at the cross roads to decide on where to locate the RTP implementation in the context of VoIP. I hope I am sending my mail to the appropriate mailing list. Hoping that I can discuss the design issues here... I am using a Pentium desktop running Unix OS. I am supposed to build a CTI card with a DSP on it running voice processing software. There are two options for me to choose when it comes to the implementation of RTP. 1) To implement RTP, jitter algorithm on the CTI card itself 2) To implement RTP, jitter algorithm on the host, and pass on the voice samples to the CTI card for further processing Given the two options, what is the most suitable location for RTP ? I would be thankful if you can give me a clear perspective on this. Regards Anand From rem-conf Mon Jun 05 07:54:46 2000 From rem-conf-request@es.net Mon Jun 05 07:54:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12yyBd-0006hy-00; Mon, 5 Jun 2000 07:49:05 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 12yyBb-0006ho-00; Mon, 5 Jun 2000 07:49:04 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 5 Jun 2000 15:48:20 +0100 To: anand@ece.iisc.ernet.in (SVR Anand) cc: rem-conf@es.net Subject: Re: RTP and CTI In-reply-to: Your message of "Mon, 05 Jun 2000 18:16:42 +0530." <200006051246.SAA21212@ece.iisc.ernet.in> Date: Mon, 05 Jun 2000 15:48:19 +0100 Message-ID: <1913.960216499@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> SVR Anand writes: >Hi, > >I am at the cross roads to decide on where to locate the RTP implementation >in the context of VoIP. I hope I am sending my mail to the appropriate >mailing list. Hoping that I can discuss the design issues here... > >I am using a Pentium desktop running Unix OS. I am supposed to build a CTI >card with a DSP on it running voice processing software. There are two >options for me to choose when it comes to the implementation of RTP. > >1) To implement RTP, jitter algorithm on the CTI card itself >2) To implement RTP, jitter algorithm on the host, and pass on the > voice samples to the CTI card for further processing > >Given the two options, what is the most suitable location for RTP ? The implementations I'm aware of use the second approach. I'd be interested in hearing of other solutions. Colin From rem-conf Mon Jun 05 09:02:03 2000 From rem-conf-request@es.net Mon Jun 05 09:02:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12yzFt-0000P6-00; Mon, 5 Jun 2000 08:57:33 -0700 Received: from iisc.ernet.in [144.16.64.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 12yzFn-0000Ow-00; Mon, 5 Jun 2000 08:57:28 -0700 Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id VAA25172; Mon, 5 Jun 2000 21:28:01 +0530 (IST) Received: by ece.iisc.ernet.in (SMI-8.6/SMI-4.1) id VAA27073; Mon, 5 Jun 2000 21:27:18 +0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <200006051557.VAA27073@ece.iisc.ernet.in> Subject: Re: RTP and CTI To: C.Perkins@cs.ucl.ac.uk (Colin Perkins) Date: Mon, 5 Jun 2000 21:27:18 +0530 (GMT+05:30) Cc: rem-conf@es.net In-Reply-To: <1913.960216499@cs.ucl.ac.uk> from "Colin Perkins" at Jun 05, 2000 03:48:19 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin, Can you let me know why the second approach might have been preferred, and may I know the implementations you are refering to ? I am asking this because there is one argument in favour of approach 1. Please correct me if it is valid at all. The argument is, If the machine has two or more high speed network interfaces serving good amount of network traffic, to avoid the per-packet overheads associated with RTP, and the related processing every 20msec of audio, it is better to make the DSP handle this functionality. How far is this correct ? I should admit that though approach 2) gives a "nice" feeling, I am very much interested in knowing whether approach 1) can potentially result in a bad design. Thanks Regards Anand > > --> SVR Anand writes: > >Hi, > > > >I am at the cross roads to decide on where to locate the RTP implementation > >in the context of VoIP. I hope I am sending my mail to the appropriate > >mailing list. Hoping that I can discuss the design issues here... > > > >I am using a Pentium desktop running Unix OS. I am supposed to build a CTI > >card with a DSP on it running voice processing software. There are two > >options for me to choose when it comes to the implementation of RTP. > > > >1) To implement RTP, jitter algorithm on the CTI card itself > >2) To implement RTP, jitter algorithm on the host, and pass on the > > voice samples to the CTI card for further processing > > > >Given the two options, what is the most suitable location for RTP ? > > The implementations I'm aware of use the second approach. I'd be interested > in hearing of other solutions. > > Colin > From rem-conf Mon Jun 05 09:39:51 2000 From rem-conf-request@es.net Mon Jun 05 09:39:50 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12yzrE-0001VK-00; Mon, 5 Jun 2000 09:36:08 -0700 Received: from gnatplanet.bitscout.com (nuplanet.bitscout.com) [198.137.170.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 12yzrC-0001VA-00; Mon, 5 Jun 2000 09:36:06 -0700 Received: from wrkplanet ([10.173.17.30]) by nuplanet.bitscout.com (2.0 Build 2119 (Berkeley 8.8.4)/8.8.4) with ESMTP id MAA00511; Mon, 05 Jun 2000 12:29:44 -0400 Message-Id: <4.2.0.58.20000605123343.03ee68e0@10.173.17.1> X-Sender: jsteer@10.173.17.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 05 Jun 2000 12:34:50 -0400 To: Colin Perkins , anand@ece.iisc.ernet.in (SVR Anand) From: Jon Steer Subject: Re: RTP and CTI Cc: rem-conf@es.net In-Reply-To: <1913.960216499@cs.ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_19995296==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_19995296==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:48 PM 6/5/00 +0100, Colin Perkins wrote: >--> SVR Anand writes: > >Hi, > > > >I am at the cross roads to decide on where to locate the RTP implementation > >in the context of VoIP. I hope I am sending my mail to the appropriate > >mailing list. Hoping that I can discuss the design issues here... > > > >I am using a Pentium desktop running Unix OS. I am supposed to build a CTI > >card with a DSP on it running voice processing software. There are two > >options for me to choose when it comes to the implementation of RTP. > > > >1) To implement RTP, jitter algorithm on the CTI card itself > >2) To implement RTP, jitter algorithm on the host, and pass on the > > voice samples to the CTI card for further processing > > > >Given the two options, what is the most suitable location for RTP ? > >The implementations I'm aware of use the second approach. I'd be interested >in hearing of other solutions. Actually, a number of chips, (AudioCodes comes to mind) implement #1. regards, jon Jon Steer -- CTO http://www.tsemantics.com/ T!Semantics ,Inc 40 Berkeley St, Nashua N.H. 03064 phone:(603)889-1185 x203 video: (603)889-1125 fax: (603)-883-9365 --=====================_19995296==_.ALT Content-Type: text/html; charset="us-ascii" At 03:48 PM 6/5/00 +0100, Colin Perkins wrote:

--> SVR Anand writes:
>Hi,
>
>I am at the cross roads to decide on where to locate the RTP implementation
>in the context of VoIP. I hope I am sending my mail to the appropriate
>mailing list. Hoping that I can discuss the design issues here...
>
>I am using a Pentium desktop running Unix OS. I am supposed to build a CTI
>card with a DSP on it running voice processing software. There are two
>options for me to choose when it comes to the implementation of RTP.
>
>1) To implement RTP, jitter algorithm on the CTI card itself
>2) To implement RTP, jitter algorithm on the host, and pass on the
>   voice samples to the CTI card for further processing
>
>Given the two options, what is the most suitable location for RTP ?

The implementations I'm aware of use the second approach. I'd be interested
in hearing of other solutions.

Actually, a number of chips, (AudioCodes comes to mind) implement
#1.

regards,
jon




Jon Steer -- CTO
T!Semantics ,Inc 40 Berkeley St, Nashua N.H. 03064
phone:(603)889-1185 x203  video: (603)889-1125  fax: (603)-883-9365
--=====================_19995296==_.ALT-- From rem-conf Mon Jun 05 13:34:06 2000 From rem-conf-request@es.net Mon Jun 05 13:34:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12z3Sj-0003xI-00; Mon, 5 Jun 2000 13:27:05 -0700 Received: from sdn-ar-001ohcincp305.dialsprint.net (opera) [168.191.25.43] by mail1.es.net with smtp (Exim 1.81 #2) id 12z3Sc-0003vn-00; Mon, 5 Jun 2000 13:26:59 -0700 From: Opera5@veriomail.com To: Subject: Best New Trade Show Display by Opera Portables, Inc. adv Date: Mon, 05 Jun 2000 16:20:13 -0500 X-Sender: Opera5@veriomail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Opera Portables, Inc. is offering "by invitation" visits to our web site. Packed full of exciting projects and news, Opera is leading the industry with displays that are as much eye-popping as they are eye catching. Winner of numerous industry awards, including Ernst & Young's Crescendo Award, Exhibitor Magazine's Best New Product, Forty Under 40 and Emerging 30, Opera Portables is a progressive young company with imagination and vision. If you use displays, you really owe it to yourself to check out our stuff! Go to http://2704962006/ Opera Portables, Inc. All removes honored at http://2704962006/removes.htm From rem-conf Tue Jun 06 05:02:11 2000 From rem-conf-request@es.net Tue Jun 06 05:02:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12zHkp-00038z-00; Tue, 6 Jun 2000 04:42:43 -0700 Received: from moutvdom00.kundenserver.de [195.20.224.149] by mail1.es.net with esmtp (Exim 1.81 #2) id 12zHkn-00038p-00; Tue, 6 Jun 2000 04:42:41 -0700 Received: from [195.20.224.208] (helo=mrvdom01.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 12zHkf-0001HR-00 for rem-conf@es.net; Tue, 6 Jun 2000 13:42:33 +0200 Received: from p3e9e6fc6.dip0.t-ipconnect.de ([62.158.111.198] helo=pt6587352) by mrvdom01.kundenserver.de with smtp (Exim 2.12 #2) id 12zHkT-0007NB-00 for rem-conf@es.net; Tue, 6 Jun 2000 13:42:22 +0200 From: WIMMEX AG To: rem-conf@es.net Subject: WIMMEX welcomes you X-Mailer: CK PERSONAL MAILER Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: Date: Tue, 6 Jun 2000 13:42:22 +0200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear colleagues and friends, we are glad to present you today our new worldwide service for companies of the internet, multimedia and telecommunication sectors. It would be great if you would join our network and support this project. WIMMEX investigates, monitors and analyses market developments in the multimedia, internet and telecommunication sectors. In a rapidly changing market, WIMMEX can recognize market trends and issue recommendations. WIMMEX partners have access to numerous free services for their day-to-day business: - WIMMEX quarterly: a benchmark analysis to compare your company with your competition; - one quarterly search in the highly specialized WIMMEX search engine; - a permanently updated collection of macro and microeconomic market data; - WIMMEX knowledge management analysis for your company; - our WIMMEX tested worldwide job databases for the internet, multimedia and - telecommunication sectors for rapid and reliable recruitment of qualified staff. Take a moment to acquaint yourself with our free services for companies in the internet, multimedia and telecommunication sectors and visit our homepage: http://www.wimmex.com Those companies which take part in our quarterly surveys (which will take no more than 5 minutes of their time) will get access to numerous additional free services their your day-to-day business. All company data collected in our surveys are subject to the strict German data protection laws and are not passed on to third parties. WIMMEX analyses data solely for macroeconomic investigations and sector reports. Sincerely Dr. Jochen Reuter Chief Executive Officer WIMMEX AG Adelheidstr. 6 D- 80798 Munich phone: +49-(0)89- 27349-343 fax: +49-(0)89- 27349-348 mailto:jochen.reuter@wimmex.com From rem-conf Tue Jun 06 16:51:01 2000 From rem-conf-request@es.net Tue Jun 06 16:51:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12zSwv-0001fi-00; Tue, 6 Jun 2000 16:39:57 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 12zSwu-0001fY-00; Tue, 6 Jun 2000 16:39:56 -0700 Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id TAA07309; Tue, 6 Jun 2000 19:41:06 -0400 (EDT) Message-ID: <393D8BD8.DDEC1A04@dynamicsoft.com> Date: Tue, 06 Jun 2000 19:40:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net, sip , "iptel, list" , megaco@standards.nortelnetworks.com Subject: Availability of RTP library source code in C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I am pleased to finally announce the availability of source code for RTPlib, and RTP library in C developed jointly by myself, Daniel Rubenstein from U.Mass Amherst, and Henning Schulzrinne and Jonathan Lennox from Columbia University. The library is fairly complete, implementing some of the harder things, such as SSRC collision, mixers, and RTCP timer reconsideration, in a transparent manner. It comes with HTML documentation and example applications. The library is free for non-commercial and research usage. It has been run and tested primarily on Solaris, but has also been used on NT. You can obtain the software at: http://www.bell-labs.com/topic/swdist/ Thanks! -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Tue Jun 06 17:00:37 2000 From rem-conf-request@es.net Tue Jun 06 17:00:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12zT9X-0001v4-00; Tue, 6 Jun 2000 16:52:59 -0700 Received: from adsl-61-114-163.mia.bellsouth.net (eresearchonline.tzo.com) [208.61.114.163] by mail1.es.net with smtp (Exim 1.81 #2) id 12zT9U-0001uJ-00; Tue, 6 Jun 2000 16:52:56 -0700 To: From: Subject: Diabetes Research Study Date: Tue, 6 Jun 2000 16:33:13 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list eResearchOnline.tzo.com is conducting a scientific study about stress and diabetes, in conjunction with adherence to your diabetes treatment regimen. This study does not involve testing of any medication, nor does it require you to change your existing diabetes treatment plan. If you qualify for this study you will be asked to fill out several psychological questionnaires, as well as visit a local laboratory for some routine blood analysis. In addition to receiving the free blood test results, you will also be compensated for your time, when you complete the study (any compensation will be paid in U.S. dollars). If you are interested in participating, the first step is to visit our web site and complete the initial interview survey. http://www.eResearchOnline.tzo.com Due to heavy traffic at our site, the survey may sometimes be unavailable please retry at a later time. This survey will give us information to determine if you qualify to be in our study. If you are eligible you will be contacted with further instructions and complete details about this research study. If this email was incorrectly sent to you, we apologize for the inconvenience, if you know of someone with diabetes and you think they may be interested in participating, we would appreciate if you could forward this message to them. All information given to eResearchOnline.tzo.com through its questionnaires or subsequent phone interviews, will not be used for any commercial purpose and will be kept completely confidential. This information will not be shared or sold to any other organization. This in a non commercial email, if you never wish to be contacted again, please forward this message to remove@eResearchOnline.tzo.com and your email address will be removed from our mailing list.. The purpose of eResearchOnline.tzo.com is to use the internet to increase the scope of research to a global level. Recruitment Dept. From rem-conf Thu Jun 08 03:59:10 2000 From rem-conf-request@es.net Thu Jun 08 03:59:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 12zzoW-0002pR-00; Thu, 8 Jun 2000 03:45:28 -0700 Received: from ferao.jungle.bt.co.uk [132.146.107.45] by mail1.es.net with esmtp (Exim 1.81 #2) id 12zzoV-0002p4-00; Thu, 8 Jun 2000 03:45:27 -0700 Received: from sherekhan.jungle.bt.co.uk (sherekhan [132.146.107.25]) by ferao.jungle.bt.co.uk (8.9.1b+Sun/Jungle-8.9.1-03) with SMTP id LAA12962 for ; Thu, 8 Jun 2000 11:32:56 +0100 (BST) Received: from jungle.bt.co.uk ([132.146.107.59]) by sherekhan.jungle.bt.co.uk; Thu, 8 Jun 00 11:32:54 BST Message-Id: <393F79F8.1EE545D0@jungle.bt.co.uk> Date: Thu, 08 Jun 2000 11:48:24 +0100 From: Sylvie Brunelle X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: rem Subject: same multicast address for different RTP sessions??? Content-Type: multipart/alternative; boundary="------------5FF9931F232E87D13E6A9E9C" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --------------5FF9931F232E87D13E6A9E9C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody, I was wondering whether it was possible to have two different RTP sessions with the same multicast address but different UDP ports. If I understand well the passage below (paragraph 2.2 from draft-ietf-avt-rtp-new-07.txt), it seems to be possible. " If both audio and video media are used in a conference, they are transmitted as separate RTP sessions RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated." But in that case that would mean that, if RTP session 1 and RTP session 2 do use the same multicast address, one participant from RTP session 1 will take from the network the traffic from RTP session 1 and RTP session2 and will only differentiate the packets coming from these two different sessions when he will process the UDP header! Furthermore, in case there is congestion and the participant of session 1 and 2 (which are using the same multicast address) decides to unsubscribe from the RTP session 2 (in order to reduce congestion), he will not solve congestion at all, as the router will continue forwarding him all the packets corresponding to the multicast address of RTP session 1 (and thus RTP session2). Cheers, Sylvie --------------5FF9931F232E87D13E6A9E9C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody,

I was wondering whether it was possible to have two different RTP sessions with the same multicast address but different UDP ports. If I understand well the passage below (paragraph 2.2 from draft-ietf-avt-rtp-new-07.txt), it seems to be possible.

" If both audio and video media are used in a conference, they are
   transmitted as separate RTP sessions RTCP packets are transmitted for
   each medium using two different UDP port pairs and/or multicast
   addresses. There is no direct coupling at the RTP level between the
   audio and video sessions, except that a user participating in both
   sessions should use the same distinguished (canonical) name in the
   RTCP packets for both so that the sessions can be associated."

But in that case that would mean that, if RTP session 1 and RTP session 2 do use the same multicast address, one participant from RTP session 1 will take from the network the traffic from RTP session 1 and RTP session2 and will only differentiate the packets coming from these two different sessions when he will process the UDP header!

Furthermore,  in case there is congestion and the participant of session 1 and 2 (which are using the same multicast address) decides to unsubscribe from the RTP session 2 (in order to reduce congestion), he will not solve congestion at all, as the router will continue forwarding him all the packets corresponding to the multicast address of RTP session 1 (and thus RTP session2).

Cheers,
Sylvie --------------5FF9931F232E87D13E6A9E9C-- From rem-conf Thu Jun 08 04:00:49 2000 From rem-conf-request@es.net Thu Jun 08 04:00:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 130006-0002td-00; Thu, 8 Jun 2000 03:57:26 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 130003-0002tT-00; Thu, 8 Jun 2000 03:57:23 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10714; Thu, 8 Jun 2000 06:57:22 -0400 (EDT) Message-Id: <200006081057.GAA10714@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-10.txt Date: Thu, 08 Jun 2000 06:57:22 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, I. Suconick, B. Strahm Filename : draft-ietf-avt-rtp-mib-10.txt Pages : 37 Date : 07-Jun-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol(RTP) systems [RFC1889]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000607121425.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000607121425.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jun 08 04:30:25 2000 From rem-conf-request@es.net Thu Jun 08 04:30:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1300Te-0004kh-00; Thu, 8 Jun 2000 04:27:58 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1300Tb-0004kX-00; Thu, 8 Jun 2000 04:27:56 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jun 2000 12:27:44 +0100 To: Sylvie Brunelle cc: rem Subject: Re: same multicast address for different RTP sessions??? In-reply-to: Your message of "Thu, 08 Jun 2000 11:48:24 BST." <393F79F8.1EE545D0@jungle.bt.co.uk> Date: Thu, 08 Jun 2000 12:27:42 +0100 Message-ID: <10441.960463662@cs.ucl.ac.uk> From: Jon Crowcroft X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <393F79F8.1EE545D0@jungle.bt.co.uk>, Sylvie Brunelle typed: >>I was wondering whether it was possible to have two different RTP >>sessions with the same multicast address but different UDP ports. If I >>understand well the passage below (paragraph 2.2 from >>draft-ietf-avt-rtp-new-07.txt), it seems to be possible. well, under most circumstances, one would expect traffic sources from the same place with receviers at the same locations to go over the same tree roughly (ok, so there are equal cost multipath OSPFs out there, but ....) so whether you use the same multicast address or different ones, they are sharing the same bottlenecks unless there's very explicit multicast policies setup (could use different GLOP addresses etc etc) - but yes, yo uare right, receiver based congestion control, leaving one group and not the other, wouldnt work if both flows are distinguished only by UDP ports - nor would (i think) source specific (IGMP v3) if they are sources from same IP address...... of course if you want explicit differentiation, its done either by intserv (which includes ports) or in diffserv by edge marking of DSCP fields in IP Header, which can be different for things with same src+dst IP addresses and ports >> >>" If both audio and video media are used in a conference, they are >> transmitted as separate RTP sessions RTCP packets are transmitted for >> >> each medium using two different UDP port pairs and/or multicast >> addresses. There is no direct coupling at the RTP level between the >> audio and video sessions, except that a user participating in both >> sessions should use the same distinguished (canonical) name in the >> RTCP packets for both so that the sessions can be associated." >> >>But in that case that would mean that, if RTP session 1 and RTP session >>2 do use the same multicast address, one participant from RTP session 1 >>will take from the network the traffic from RTP session 1 and RTP >>session2 and will only differentiate the packets coming from these two >>different sessions when he will process the UDP header! >> >>Furthermore, in case there is congestion and the participant of session >>1 and 2 (which are using the same multicast address) decides to >>unsubscribe from the RTP session 2 (in order to reduce congestion), he >>will not solve congestion at all, as the router will continue forwarding >>him all the packets corresponding to the multicast address of RTP >>session 1 (and thus RTP session2). >> >>Cheers, >>Sylvie From rem-conf Thu Jun 08 05:14:03 2000 From rem-conf-request@es.net Thu Jun 08 05:14:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 130136-0005sG-00; Thu, 8 Jun 2000 05:04:36 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 130135-0005s6-00; Thu, 8 Jun 2000 05:04:35 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jun 2000 13:04:24 +0100 To: Sylvie Brunelle cc: rem Subject: Re: same multicast address for different RTP sessions??? In-reply-to: Your message of "Thu, 08 Jun 2000 11:48:24 BST." <393F79F8.1EE545D0@jungle.bt.co.uk> Date: Thu, 08 Jun 2000 13:04:22 +0100 Message-ID: <1090.960465862@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Sylvie, --> Sylvie Brunelle writes: >I was wondering whether it was possible to have two different RTP >sessions with the same multicast address but different UDP ports. If I >understand well the passage below (paragraph 2.2 from >draft-ietf-avt-rtp-new-07.txt), it seems to be possible. Yes, it is possible. >But in that case that would mean that, if RTP session 1 and RTP session >2 do use the same multicast address, one participant from RTP session 1 >will take from the network the traffic from RTP session 1 and RTP >session2 and will only differentiate the packets coming from these two >different sessions when he will process the UDP header! Correct. >Furthermore, in case there is congestion and the participant of session >1 and 2 (which are using the same multicast address) decides to >unsubscribe from the RTP session 2 (in order to reduce congestion), he >will not solve congestion at all, as the router will continue forwarding >him all the packets corresponding to the multicast address of RTP >session 1 (and thus RTP session2). Correct. These are the reasons why it is best to use different multicast groups for different sessions. Colin From rem-conf Thu Jun 08 05:36:19 2000 From rem-conf-request@es.net Thu Jun 08 05:36:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1301Uo-0006xF-00; Thu, 8 Jun 2000 05:33:14 -0700 Received: from ns.webdirt.net [12.26.137.73] by mail1.es.net with esmtp (Exim 1.81 #2) id 1301Un-0006x5-00; Thu, 8 Jun 2000 05:33:13 -0700 Received: from win98celeron (216-118-5-171.pdq.net [216.118.5.171]) by ns.webdirt.net (8.9.3/8.9.3) with SMTP id JAA18208; Thu, 8 Jun 2000 09:40:08 -0400 Message-ID: <002901bfd145$92e08700$ab0576d8@pdq.net> From: "kjposter2" To: "Sylvie Brunelle" , "Colin Perkins" Cc: "rem" References: <1090.960465862@cs.ucl.ac.uk> Subject: Re: same multicast address for different RTP sessions??? Date: Thu, 8 Jun 2000 07:32:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would really really like to unsubscribe from this the email address I would like to unsubscribe joekratz@netropolis.net any help would be appreciated I requested this but still receive emails ----- Original Message ----- From: Colin Perkins To: Sylvie Brunelle Cc: rem Sent: Thursday, June 08, 2000 7:04 AM Subject: Re: same multicast address for different RTP sessions??? > Sylvie, > > --> Sylvie Brunelle writes: > >I was wondering whether it was possible to have two different RTP > >sessions with the same multicast address but different UDP ports. If I > >understand well the passage below (paragraph 2.2 from > >draft-ietf-avt-rtp-new-07.txt), it seems to be possible. > > Yes, it is possible. > > >But in that case that would mean that, if RTP session 1 and RTP session > >2 do use the same multicast address, one participant from RTP session 1 > >will take from the network the traffic from RTP session 1 and RTP > >session2 and will only differentiate the packets coming from these two > >different sessions when he will process the UDP header! > > Correct. > > >Furthermore, in case there is congestion and the participant of session > >1 and 2 (which are using the same multicast address) decides to > >unsubscribe from the RTP session 2 (in order to reduce congestion), he > >will not solve congestion at all, as the router will continue forwarding > >him all the packets corresponding to the multicast address of RTP > >session 1 (and thus RTP session2). > > Correct. > > These are the reasons why it is best to use different multicast groups for > different sessions. > > Colin > > From rem-conf Thu Jun 08 07:36:30 2000 From rem-conf-request@es.net Thu Jun 08 07:36:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1303Ew-0000zc-00; Thu, 8 Jun 2000 07:24:58 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1303Ev-0000zS-00; Thu, 8 Jun 2000 07:24:57 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jun 2000 15:24:15 +0100 To: anand@ece.iisc.ernet.in (SVR Anand) cc: rem-conf@es.net Subject: Re: RTP and CTI In-reply-to: Your message of "Mon, 05 Jun 2000 21:27:18 +0530." <200006051557.VAA27073@ece.iisc.ernet.in> Date: Thu, 08 Jun 2000 15:24:13 +0100 Message-ID: <1771.960474253@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> SVR Anand writes: >Can you let me know why the second approach might have been preferred, and >may I know the implementations you are refering to ? I would choose to implement RTP packetisation/de-packetization, RTCP and the de-jitter operation in software, since these are not processor bound operations but are somewhat subtle in their operation (especially writing a good de-jitter algorithm). Those aspects I would choose to implement in the card are audio coding and loss concealment, since these would benefit >from the presence of a DSP. >I am asking this because there is one argument in favour of approach 1. >Please correct me if it is valid at all. The argument is, > >If the machine has two or more high speed network interfaces serving >good amount of network traffic, to avoid the per-packet overheads >associated with RTP, and the related processing every 20msec of audio, it is >better to make the DSP handle this functionality. How far is this correct ? Certainly if you have a high speed network with QoS this is a valid approach. If you want something which runs over a non-guaranteed QoS network, then I would suspect that it is easier to implement the dejitter operation in software. >I should admit that though approach 2) gives a "nice" feeling, I am very much >interested in knowing whether approach 1) can potentially result in a bad >design. It depends on your application to a large degree. The implementations I know are PC-based, handling a small number of streams. If your system has to process a very large number of streams, the trade-off is somewhat different. Colin From rem-conf Thu Jun 08 07:41:14 2000 From rem-conf-request@es.net Thu Jun 08 07:41:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1303ML-00013Z-00; Thu, 8 Jun 2000 07:32:37 -0700 Received: from marjan.fesb.hr [161.53.166.3] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 1303M9-00011G-00; Thu, 8 Jun 2000 07:32:30 -0700 Received: from jurica (jurica.fesb.hr [161.53.166.43]) by marjan.fesb.hr (8.9.3/8.9.3) with SMTP id NAA01970; Thu, 8 Jun 2000 13:16:13 +0200 (MET DST) Message-ID: <042801bfd13f$4c7f4fe0$2ba635a1@fesb.hr> From: "SoftCOM Secretary" To: "SoftCOM Mailing List" Subject: SoftCOM 2000 Deadline Extension and Feature Topic CFP Date: Thu, 8 Jun 2000 13:17:28 +0200 Organization: FESB, University of Split MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear All, Due to the number of requests for deadline extension the SoftCOM 2000 Organizing Committee has extended the paper submission deadline to June 19, 2000. We use this opportunity to remind the potential contributors that the deadline for special session "The New Millennium Telecommunications in the Alps-Adria Countries" is approaching. >From the papers presented at SoftCOM 2000, a set of the most representative papers (or their integrals) will be selected for publication in the August 2001 issue of the IEEE Communications Magazine. Deadline for the Feature Topic: Complete manuscript to be received by July 15, 2000 Notification of acceptance: July 31, 2000 The Feature Topic includes, but it is not limited to: -historical background, developments, -operation statistics and experiencies, user (universities, institutes, schools) opinions, -the newest technologies and services, -development of telelearning and videoconferencing, -Web applications and information systems, -security aspects, -plans for future,toward the new millennium, -the role of universities and institutes, -the role of the national and regional operators and companies, industry and institutions, -joint projects, joint institutes and laboratories between academic and operators and companies, industry and institutions, -participation of academic institutions in education of professionals from industry and vice versa, Participation in this FT is expected from institutions which cover academic networking (such as CARNet in Croatia, Arnes in Slovenia), as well as from universities, institutes and schools as users, particularly in the Alps-Adria region. In addition, contributions from national and regional institutions, companies, operators and industry who participate in development of academic networking, promotion of education and R&D investigations are particularly welcome. More details can be found at http://www.fesb.hr/SoftCOM Thank you for your interest in SoftCOM 2000. SoftCOM 2000 Organizing Committee From rem-conf Thu Jun 08 08:31:08 2000 From rem-conf-request@es.net Thu Jun 08 08:31:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1304E5-0003AT-00; Thu, 8 Jun 2000 08:28:09 -0700 Received: from (mail.krri.re.kr) [203.227.203.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 1304E3-00039i-00; Thu, 8 Jun 2000 08:28:07 -0700 Received: from kiaCoul41 (firewall.krri.re.kr [10.10.10.10]) by mail.krri.re.kr (8.9.1a/8.9.3) with SMTP id JAA25104; Fri, 9 Jun 2000 09:24:33 +0900 From: u4p1cYW5t@platin.pes.cz DATE: 08 Jun 00 11:45:40 AM Message-ID: <6g509stj73E7> SUBJECT: great web hosting deals Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list GET YOUR OWN 5 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY! STOP PAYING $19.95 or more PER MONTH TODAY for your web site, WHEN YOU CAN GET ONE FOR ONLY $11.95 PER MONTH! DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A SIMPLE PHONE CALL TO OUR OFFICE. YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with no extra charge! UNLIMITED TRAFFIC -- no extra charge! WE HAVE BOTH UNIX AND NT MACHINES WITH FRONT PAGE EXTENSIONS FULLY SUPPORTED. A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS. ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP CHARGE. FOR DETAILS CALL 1 888 248 0765 or fax 240 337 8325 PES WEB HOSTING -- _______________________________________________________________ Want to do bulk email? Ask us how today! GET YOUR MESSAGE DELIVERED TO 500,000 PEOPLE FOR ONLY $550.00. OR HAVE YOUR MESSAGE DELIVERED TO OVER 1 MILLION PEOPLE FOR ONLY $1200.00. Call 1888 248 0765 for FURTHER INFORMATION today! or fax 240 337 8325 _________________________________________________________________ Get your own offshore trust! PROTECT YOUR PERSONAL ASSETS FROM LAWSUITS or Do SOME ESTATE PLANNING TO MINIMIZE THOSE INHERITANCE TAXES! GET THAT OFFSHORE BANK ACCOUNT YOU ALWAYS WANTED! For further information please fax 240 337 8325 THANK YOU From rem-conf Thu Jun 08 08:32:12 2000 From rem-conf-request@es.net Thu Jun 08 08:32:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1304GF-0003Qu-00; Thu, 8 Jun 2000 08:30:23 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 1304GE-0003QV-00; Thu, 8 Jun 2000 08:30:22 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA27139 for ; Thu, 8 Jun 2000 11:30:21 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <393FBC0D.6409C243@cs.columbia.edu> Date: Thu, 08 Jun 2000 11:30:21 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: MPEG2 streaming hardware Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is there hardware that can reliably compress & stream live DVD-quality MPEG-encoded video (and audio) over RTP, in standard formats? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Thu Jun 08 10:00:31 2000 From rem-conf-request@es.net Thu Jun 08 10:00:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1305cf-0006Db-00; Thu, 8 Jun 2000 09:57:37 -0700 Received: from mta5.rcsntx.swbell.net [151.164.30.29] by mail1.es.net with esmtp (Exim 1.81 #2) id 1305cd-0006DE-00; Thu, 8 Jun 2000 09:57:35 -0700 Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D37FA42U@mta5.rcsntx.swbell.net> for rem-conf@es.net; Thu, 8 Jun 2000 11:05:09 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:09 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net From: zainprov@swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: rem-conf@es.net Message-id: <0FVU00DEWFCJ2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From rem-conf Thu Jun 08 11:02:56 2000 From rem-conf-request@es.net Thu Jun 08 11:02:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1306a5-0000BR-00; Thu, 8 Jun 2000 10:59:01 -0700 Received: from iisc.ernet.in [144.16.64.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 1306a2-0000BH-00; Thu, 8 Jun 2000 10:58:59 -0700 Received: from ece.iisc.ernet.in (ece.iisc.ernet.in [144.16.64.2]) by iisc.ernet.in (8.9.2/8.9.0) with SMTP id XAA43783; Thu, 8 Jun 2000 23:29:23 +0530 (IST) Received: by ece.iisc.ernet.in (SMI-8.6/SMI-4.1) id XAA23444; Thu, 8 Jun 2000 23:28:42 +0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <200006081758.XAA23444@ece.iisc.ernet.in> Subject: Re: RTP and CTI To: C.Perkins@cs.ucl.ac.uk (Colin Perkins) Date: Thu, 8 Jun 2000 23:28:42 +0530 (GMT+05:30) Cc: rem-conf@es.net In-Reply-To: <1771.960474253@cs.ucl.ac.uk> from "Colin Perkins" at Jun 08, 2000 03:24:13 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin, Thanks a lot for your response. The machine I am using is a Pentium III PC. I also feel that it is better to implement RTP packetization/de-packetization, RTCP, as well as de-jitter algorithm on the host. Some more thoughts. It is difficult to imagine that the delay due to RTP packet processing + jitter algorithm can really result in a additional packet worth of delay (20millisec) in the playout times. If we note that the new playout delay calculation is going to occur only at the beginning of a new talk spurt, host need not unduly worry since the only per-packet overhead is going to be measurement of jitter which is not computationally intensive at all. Arriving at the correct de-jitter algorithm, as you have very rightly pointed out, can be very tricky, and lot of fine tuning may be required. At times there is a bit of subjectivity involved. Burying it in the DSP is a bit scary ! Regards Anand > > --> SVR Anand writes: > >Can you let me know why the second approach might have been preferred, and > >may I know the implementations you are refering to ? > > I would choose to implement RTP packetisation/de-packetization, RTCP and > the de-jitter operation in software, since these are not processor bound > operations but are somewhat subtle in their operation (especially writing > a good de-jitter algorithm). Those aspects I would choose to implement in > the card are audio coding and loss concealment, since these would benefit > from the presence of a DSP. > > >I am asking this because there is one argument in favour of approach 1. > >Please correct me if it is valid at all. The argument is, > > > >If the machine has two or more high speed network interfaces serving > >good amount of network traffic, to avoid the per-packet overheads > >associated with RTP, and the related processing every 20msec of audio, it is > >better to make the DSP handle this functionality. How far is this correct ? > > Certainly if you have a high speed network with QoS this is a valid > approach. If you want something which runs over a non-guaranteed QoS > network, then I would suspect that it is easier to implement the dejitter > operation in software. > > >I should admit that though approach 2) gives a "nice" feeling, I am very much > >interested in knowing whether approach 1) can potentially result in a bad > >design. > > It depends on your application to a large degree. The implementations I > know are PC-based, handling a small number of streams. If your system has > to process a very large number of streams, the trade-off is somewhat > different. > > Colin > From rem-conf Thu Jun 08 12:01:59 2000 From rem-conf-request@es.net Thu Jun 08 12:01:58 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1307Vh-0001PQ-00; Thu, 8 Jun 2000 11:58:33 -0700 Received: from adsl-63-193-136-149.dsl.lsan03.pacbell.net (okwhatever.com) [63.193.136.149] by mail1.es.net with esmtp (Exim 1.81 #2) id 1307Vf-0001PF-00; Thu, 8 Jun 2000 11:58:31 -0700 Date: Thu, 8 Jun 2000 12:00:58 PST Message-Id: <200006081200.AA1286865366@okwhatever.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Frank Basso" Reply-To: To: sylvie@jungle.bt.co.uk , C.Perkins@cs.ucl.ac.uk , kjposter2@webdirt.net CC: rem-conf@es.net Subject: Re: same multicast address for different RTP sessions??? X-Mailer: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscribe rem-conf Someone help me here... ---------- Original Message ---------------------------------- From: "kjposter2" Date: Thu, 8 Jun 2000 07:32:11 -0500 >I would really really like to unsubscribe from this > >the email address I would like to unsubscribe > >joekratz@netropolis.net > >any help would be appreciated > >I requested this but still receive emails > >----- Original Message ----- >From: Colin Perkins >To: Sylvie Brunelle >Cc: rem >Sent: Thursday, June 08, 2000 7:04 AM >Subject: Re: same multicast address for different RTP sessions??? > > >> Sylvie, >> >> --> Sylvie Brunelle writes: >> >I was wondering whether it was possible to have two different RTP >> >sessions with the same multicast address but different UDP ports. If I >> >understand well the passage below (paragraph 2.2 from >> >draft-ietf-avt-rtp-new-07.txt), it seems to be possible. >> >> Yes, it is possible. >> >> >But in that case that would mean that, if RTP session 1 and RTP session >> >2 do use the same multicast address, one participant from RTP session 1 >> >will take from the network the traffic from RTP session 1 and RTP >> >session2 and will only differentiate the packets coming from these two >> >different sessions when he will process the UDP header! >> >> Correct. >> >> >Furthermore, in case there is congestion and the participant of session >> >1 and 2 (which are using the same multicast address) decides to >> >unsubscribe from the RTP session 2 (in order to reduce congestion), he >> >will not solve congestion at all, as the router will continue forwarding >> >him all the packets corresponding to the multicast address of RTP >> >session 1 (and thus RTP session2). >> >> Correct. >> >> These are the reasons why it is best to use different multicast groups for >> different sessions. >> >> Colin >> >> > > > From rem-conf Fri Jun 09 04:16:39 2000 From rem-conf-request@es.net Fri Jun 09 04:16:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 130Maf-0002Wb-00; Fri, 9 Jun 2000 04:04:41 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 130Mad-0002WR-00; Fri, 9 Jun 2000 04:04:40 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Jun 2000 12:04:05 +0100 To: anand@ece.iisc.ernet.in (SVR Anand) cc: rem-conf@es.net Subject: Re: RTP and CTI In-reply-to: Your message of "Thu, 08 Jun 2000 23:28:42 +0530." <200006081758.XAA23444@ece.iisc.ernet.in> Date: Fri, 09 Jun 2000 12:04:05 +0100 Message-ID: <1421.960548645@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> SVR Anand writes: >It is difficult to imagine that the delay due to RTP packet processing + >jitter algorithm can really result in a additional packet worth of delay >(20millisec) in the playout times. Depends on the network - if you're running over the public Internet, the jitter can indeed be that bad. If you control the network, you probably don't need to worry about it. >If we note that the new playout delay calculation is going to occur only at >the beginning of a new talk spurt, host need not unduly worry since the >only per-packet overhead is going to be measurement of jitter which is not >computationally intensive at all. Right... >Arriving at the correct de-jitter algorithm, as you have very rightly pointed >out, can be very tricky, and lot of fine tuning may be required. At times >there is a bit of subjectivity involved. Burying it in the DSP is a bit >scary ! Colin From rem-conf Fri Jun 09 14:43:19 2000 From rem-conf-request@es.net Fri Jun 09 14:43:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 130WNn-0003sW-00; Fri, 9 Jun 2000 14:32:03 -0700 Received: from uoscc.uos.ac.kr [203.249.96.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 130WNl-0003sM-00; Fri, 9 Jun 2000 14:32:01 -0700 Received: from odyssey.uos.ac.kr (odyssey.uos.ac.kr [203.249.97.225]) by uoscc.uos.ac.kr (8.10.1/8.10.1) with SMTP id e59LUSB14731; Sat, 10 Jun 2000 06:30:28 +0900 Received: from p0Fr3lBf1 by odyssey.uos.ac.kr (SMI-8.6/SMI-SVR4) id FAA17220; Sat, 10 Jun 2000 05:51:54 +0900 From: V3tXQ94o3@star.co.kr DATE: 09 Jun 00 5:43:46 PM Reply-to: QWr412@tank.dwe.co.kr Message-ID: TO: zxUTD40@skyworth.com.hk SUBJECT: A Million Dollars? 2 Ways To Get It.... X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Opt In Mailing List ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You are recieving this message because you were referred or requested additional information. If you would like to have your address removed from our Opt-In listserver, see the end of this message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ THE SIMPLE FACT IS YOU CAN WIN IT OR WORK FOR IT...THIS E-MAIL CAN PROVIDE INFORMATION ON BOTH METHODS, PLUS WE WILL PROVIDE YOU WITH FREE PERSONAL WEB SITE AND FREE MONEY MAKING REPORTS! SEE BELOW CHECK BOXES & FAX BACK TO (770) 234-5340 [ ] SHOW ME WHERE TO REGISTER (FOR FREE), SEVERAL PLACES I CAN WIN A MILLION DOLLARS [ ] TELL ME HOW I CAN MAKE MONEY PART TIME IN A HOME BASED BUSINESS WITH LITTLE OR NO RISK [ ] SEND ME INFORMATION ON HOW I CAN RECEIVE A FREE WEBSITE FOR TAKING 60 SECONDS TO FILL THIS OUT [ ] SEND ME YOUR LIST OF FREE SPECIAL MONEY MAKING REPORTS ON HOW TO MAKE MONEY ON A PART TIME BASIS (NO COST OR OBLIGATION-JUST SEND THE LIST) [ ] I AM A SERIOUS BUS OPP SEEKER, IF YOU HAVE A LEGITIMATE OPPORTUNITY FOR IMMEDIATE INCOME, CALL ME AS SOON AS POSSIBLE [ ] NAME_____________________________ PHONE____________________________ FAX_______________________________ E-MAIL_____________________________ FAX BACK TO (770) 234-5340 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To be taken off of this listserver, Please include the word R in the subject header to: novel@myrealbox.com From rem-conf Fri Jun 09 16:59:00 2000 From rem-conf-request@es.net Fri Jun 09 16:58:59 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 130YVW-0001T3-00; Fri, 9 Jun 2000 16:48:10 -0700 Received: from nw201-2.indigo.ie ([194.125.201.2] helo=cfb_gpo.indigo.ie) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 130YVU-0001Sn-00; Fri, 9 Jun 2000 16:48:08 -0700 Received: from V96XIlXdc (unverified) by cfb_gpo.indigo.ie (Content Technologies SMTPRS 4.0.1) with SMTP id ; Fri, 9 Jun 2000 21:35:03 +0100 DATE: 09 Jun 00 3:28:36 PM FROM: Zyt035BFv@public.tjuc.com.cn Message-ID: SUBJECT: Re: your decision Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Look, we don't want to waste your time...or ours You must be determined to earn a bare minimum of $10,000 in the next 30 - 45 days and to develop a net worth of over 1 Million Dollars Cash in the next 24-36 months. My mission is to help other people develop their life long dreams. Part of what I'm looking for are those people who are committed to that BIG of a picture and are not afraid to work for it. We can help you: REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! NOT MLM or FRANCHISE Don't bother to call unless you are serious. Learn the Facts CALL 1-877-407-3047 (24 hrs) $10,000 IN 30 - 45 DAYS RETIREMENT IN 3-5 YEARS Please accept our deepest apologizes, if you received this email unsolicited, and you can be removed automatically below. *************************************************************************************** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:lori1969@altavistausa.com?subject=REMOVE PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. **************************************************************************************** From rem-conf Sun Jun 11 13:21:49 2000 From rem-conf-request@es.net Sun Jun 11 13:21:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 131E0A-0003Jz-00; Sun, 11 Jun 2000 13:06:34 -0700 Received: from mail9.wlv.netzero.net [209.247.163.66] by mail1.es.net with smtp (Exim 1.81 #2) id 131E09-0003Jp-00; Sun, 11 Jun 2000 13:06:33 -0700 Received: (qmail 9936 invoked by uid 0); 11 Jun 2000 20:06:26 -0000 Received: from dialup-63.210.126.47.losangeles1.level3.net (HELO j) (63.210.126.47) by mail9.wlv.netzero.net with SMTP; 11 Jun 2000 20:06:26 -0000 From: "John Chang" To: Subject: VC Information Date: Sun, 11 Jun 2000 13:07:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Sir or Madam: I have found this e-mail address through a website called www.bitscout.com which has a section on videoconferencing. I believe that this address adds me to a mailing list where I can receive more information on VC, DTVC, and other aspects of VC. Thank you, John Chang _____________________________________________ NetZero - Defenders of the Free World Click here for FREE Internet Access and Email http://www.netzero.net/download/index.html From rem-conf Mon Jun 12 02:25:05 2000 From rem-conf-request@es.net Mon Jun 12 02:25:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 131QMP-0001zr-00; Mon, 12 Jun 2000 02:18:21 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 131QMJ-0001ze-00; Mon, 12 Jun 2000 02:18:18 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id SAA11881; Mon, 12 Jun 2000 18:17:50 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id SAA23873; Mon, 12 Jun 2000 18:17:49 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id SAA14559; Mon, 12 Jun 2000 18:17:46 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id SAA42006; Mon, 12 Jun 2000 18:17:47 +0900 (JST) Message-ID: <03c901bfd44f$07b26560$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" Cc: "Yoshihiro Kikuchi" Subject: MPEG-4 A/V RTP I/D update: summary of discussion Date: Mon, 12 Jun 2000 18:17:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all MPEG-4 over IP experts, Please find bellow a summary of discussions about the updated I/D of MPEG-4 Audio/Visual RTP/RTCP. We will prepare the final version of the Internet-Draft by the end of this week. The conclusions bellow are what the authors are thinking about now. But we should finally follow the consensus of the group. If someone is not satisfied the summary and conclusions bellow, especially on (2), please let us know your comment through the reflector ASAP. What I would like to have a consensus now is that the final I/D will contain ONLY items that will reach to a consensus among the group before preparing the final text. In other words, a part of the I/D which cannot reach to a consensus may be removed or revised. If there is no further comment, the authors will prepare the final version of I/D following the conclusions bellow. (1) FIR (Stephan's proposal) There was a proposal by Stephan Wenger about a new feedback scheme using FIR. It tries to cover all MPEG-4 Visual profiles, including profiles which are not covered by NEWPRED. However, there is no specific description so far. It lacks of discussions about the idea. Concerns were raised to add a new technical item without having enough discussions. It needs further discussions and may needs comparisons with other proposals to adopt the idea. [Conclusion] Not to include FIR proposal into the I/D. The proposal may be discussed in future. (2) NEWPRED RTCP (section 5) There was a concern raised by Stephan Wenger to keep the RTCP part in the I/D. The reason was that this RTCP concerns only NEWPRED, which covers only ARTS Profile. He proposed that the addition of FIR based feedback scheme may resolve the problem. He proposed three ways to proceed: 1) someone convince him to keep the NEWPRED RTCP as is, 2) move NEWPRED RTCP part (section 5) to a separate I/D and work together with FIR proposal, and 3) put FIR together with NEWPRED into the I/D. (But FIR proposal definitely needs further discussions. See (1) above.) The discussion at the Adelaide meeting was explained by Sigeru Fukunaga, a proponent of the NEWPRED. (Note: Conclusion from the draft minutes is: "Steve Casner concluded with the chairs' view that we should proceed with the definition of this backchannel scheme as is, and consider a more general solution in future.") There is a strong desire by Sigeru Fukunaga to use MPEG-4 NEWPRED on H.323 systems soon in their company's products. It requires RFC for the NEWPRED RTCP be ready before the Nov. SG16 meeting. (Note: It is a common desire among authors to have an RFC for the RTP part soon. However, it should be remarked that all products may not use NEWPRED.) It was proposed by Yoshihiro Kikuchi, an editor of the I/D to add the description to clarify that the NEWPRED RTCP is optional, and nothing to prevent the future discussions about new feedback schemes. [Conclusion] If the conclusion at the Adelaide meeting is agreeable, the authors will follow this. The final conclusion should be made depend on the discussions and the consensus among the whole group. In any case, it should be clarified that the NEWPRED RTCP is nothing to prevent the future discussions on new feedback schemes. (3) Other items There was a suggestion by Stephan Wenger that the English quality may need improvement. There is no technical comment on the parts other than RTCP. [Conclusion] The authors are now working on the improvement of the English quality. The text should be ready by the end of this week. Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 From rem-conf Mon Jun 12 03:46:54 2000 From rem-conf-request@es.net Mon Jun 12 03:46:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 131Rgm-0003Qt-00; Mon, 12 Jun 2000 03:43:28 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 131Rgk-0003Qj-00; Mon, 12 Jun 2000 03:43:26 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27734; Mon, 12 Jun 2000 06:43:24 -0400 (EDT) Message-Id: <200006121043.GAA27734@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mpls@uu.net, rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-theimer-tcrtp-mpls-00.txt Date: Mon, 12 Jun 2000 06:43:23 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Tunneling Multiplexed Compressed RTP in MPLS Author(s) : T. Theimer Filename : draft-theimer-tcrtp-mpls-00.txt Pages : 10 Date : 09-Jun-00 This document describes a method to improve the bandwidth efficiency of voice transmission over an IP/MPLS network by combining RTP compression, PPP multiplexing and MPLS tunneling. This proposal does not require any additions or modifications to existing protocols, and therefore should be fully interoperable with existing implementations of RTP compression and PPP multiplexing. It only requires specific use of some attributes of MPLS signalling protocols to setup a pair of unidirectional MPLS tunnels providing a bidirectional link for compressed RTP over PPP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-theimer-tcrtp-mpls-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-theimer-tcrtp-mpls-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-theimer-tcrtp-mpls-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000609131405.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-theimer-tcrtp-mpls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-theimer-tcrtp-mpls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000609131405.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jun 13 11:03:47 2000 From rem-conf-request@es.net Tue Jun 13 11:03:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 131ucq-0003Ey-00; Tue, 13 Jun 2000 10:37:20 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 131ucn-0003Eo-00; Tue, 13 Jun 2000 10:37:17 -0700 Received: from ksat10 (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by artemis.rus.uni-stuttgart.de with SMTP id TAA19816; Tue, 13 Jun 2000 19:37:01 +0200 (MET DST) env-from (christ@rus.uni-stuttgart.de) From: "Paul Christ" To: "Dave Singer" , <4on2andIP-sys@advent.ee.columbia.edu> Cc: "'Colin Perkins'" , "CURET Dominique FTRD/DMI/REN" , , , "Yan Xiang Chen" , "Stefan Wesner" Subject: RE: MPEG-4 (including Flexmux), over RTP/RTSP Date: Tue, 13 Jun 2000 19:52:15 +0200 Message-ID: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0055_01BFD570.DFDB06F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0055_01BFD570.DFDB06F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Dave, dear all, please find attached our first comment to your/Dave's mail - now evolved into ISO/IEC JTC1/SC29/WG11 N3381. We welcome such a paper and will try to help further to improve it. If you don't mind: We should avoid "memoryless" discussions :-) AS agreed in the IETF C.Guillemot et al., "RTP Payload Format for MPEG-4 with Flexible Error Resiliency", IETF Draft, draft-ietf-avt-mpeg4streams-00, March 1 2000, expires Sept 1 2000 R. Civanlar et al., " RTP Payload Format for MPEG-4 Streams", IETF Draft, draft-ietf-avt-rtp-mpeg4-02, ? ? 2000, expires ?? 20000 are to become experimental RFCs - for technical reasons. which state should not simply be overwritten by declarative statements. All the best P. Christ p.s.: Discussed in the context of Project SoNG with Christine Guillemot > -----Original Message----- > From: owner-4on2andIP-sys@advent.ee.columbia.edu > [mailto:owner-4on2andIP-sys@advent.ee.columbia.edu]On Behalf Of Dave > Singer > Sent: Freitag, 19. Mai 2000 20:13 > To: '4on2andIP-sys@advent.ee.columbia.edu' > Cc: 'Colin Perkins'; CURET Dominique FTRD/DMI/REN; peterw@us.ibm.com; > rem-conf@es.net > Subject: MPEG-4 (including Flexmux), over RTP/RTSP > > > This is a portmanteau message, trying to cover the whole space of > carriage of MPEG-4 in IETF protocols. I'm trying to pull everything > together. > > It started by the resurgence of comment on FlexMux in RTP, so I'll > start with packing formats. > > > PACKING FORMATS > > I have been thinking about packing formats for MPEG-4 data, and I > feel that we need to be a little more flexible. I'd suggest that at > least the following have value: > > a) a simple packing of a single, arbitrary, elementary stream into > RTP packets. The packing would not be stream-format-aware, and so > could carry any one ES. [MPEG4-GENERIC] > > b) a packing of MPEG-4 video, with care to place RTP packet > boundaries at sub-frame boundaries, such that partial frame display > is possible at the reciever. I suspect that the video group's "video > packet" meets the need, and may not require any RTP-specific header. > However, it should be a distinct payload name so that receivers can > know that video-aware packetization has happened. [MPEG4-VIDEO] > > c) a packing of MPEG-4 audio which interleaves the audio frames. See > the existing specifications for QCELP and the draft from Ross > Finlayson for MP3 for examples. Many audio decoders can do some > sensible fill-in for single missing frames, but this fill-in error > concealment rapdily gets worse if multiple consecitive frames are > lost. By intrerleaving, the decoder gets a sporting chance to > conceal errors. A small RTP header is needed to indicate that this > has happened. (With a suitable choice of header, it's possible that > packing (a) could be a special case of this.) [MPEG4-AUDIO] > > d) a packing of flexmux into RTP. This enables the carriage of large > numbers of streams, where the use of separate RTP streams becomes > prohibitive. [MPEG4-FLEXMUX] > > It may be that some formats become common enough, and have such > characteristics, that a unique payload format for it becomes > warranted (e.g. AAC). That should be possible down the road. > > For those streams requiring reliable delivery, I'd like to see us > leverage existing work in the IETF in this area (including, but not > limited to FEC, re-transmission, or repetition), rather than making > it a characteristic of the packing scheme itself. > > I'd like to think that all these, though separate payload schemes > with separate names (in the RTPMAP) can be otherwise treated > uniformly, in terms of timescale and timestamp, ES-ID to RTP mapping, > and so on. > > > TIME-STAMP HANDLING > > I think we are all agreed on this: that the MPEG-4 timescale for an > ES becomes the RTP timescale, that the composition time maps to the > RTP time, and the decode time maps to transmission order. > > > SDP INFORMATION > > I think we can assume, for the moment, that any session described by > SDP (e.g. in SAP, as a file download, as a DESCRIBE over RTSP) has at > most one MPEG-4 session, though I'd like to see how we could lift > this restriction. > > We need > i) RTP stream to elementary stream mapping. This needs to cover the > Flexmux case as well as the single stream. > a=x-mpeg4-esid a.b.c > or > a=x-mpeg4-esids m.i:a.b.c,n.k:p.q > > The first attribute is used for single streams; the second for > flexmux. In this, a is the ESID of the top-level OD stream, b is the > ESID within that scope of another OD stream, and c is the ESID within > that scope of the stream; similarly for p and q. m and n are > muxcodes (identifying the table used), and i and k are flexmux > channel numbers within the indicated muxcode. > > The entire muxcode table(s) also need to be transferred. For the > moment, I propose another attribute for them. Since these tables > have a length indicator, multiple tables can be concatenated > together, if required. > a=x-mpeg4-muxcodetable > > where is a URL that will supply the table(s). If they are > small, a DATA: URL will probably suffice to carry them in-line. If > not, the URL should use a file-retrieval scheme (e.g. HTTP, FTP). > The data at the indicated URL consists of some number of muxcode > tables, complete, in binary format (but note that DATA URLs allow for > base64 encoding of binary data, which would be needed here). The > mime type of a muxcode table needs deciding > (application/x-mpeg4-muxcodetable?). > > > ii) Some indication that an MPEG-4 session is carried, and the means > to get the IOD, if the terminal doesn't already have it by some other > means. > In SDP, as a session-level attribute: > a=x-mpeg4-iod [] > In an RTSP session, the location is optional. If not supplied, > the IOD is retrieved over the RTSP session by using either DESCRIBE > with an accept of type application/x-mpeg4-iod, or a GET-PARAMETER > (we need to decide which). Where the SDP information is supplied by > some other means (e.g. as a file, in SAP), the location is obligatory > and should be a URL which will supply the IOD (e.g. small ones may be > encoded using DATA:, or otherwise HTTP: or other suitable file-access > URL). > -- > David Singer > Apple Computer/QuickTime > ------=_NextPart_000_0055_01BFD570.DFDB06F0 Content-Type: application/msword; name="w3381_comments-ChG_PC_SoNG.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="w3381_comments-ChG_PC_SoNG.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAVAAAAAAAAAAA EAAAVgAAAAEAAAD+////AAAAAFMAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcQAHBAAAABK/AAAAAAAAEAAAAAAABAAAEjkAAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAA AAAHBBYAK2wAABZBAQAWQQEAbzQAAAAAAACiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAHADAAAAAAAAcAMAAHAD AAAAAAAAcAMAAAAAAABwAwAAAAAAAHADAAAAAAAAcAMAABQAAAAAAAAAAAAAAIQDAAAAAAAAhAMA AAAAAACEAwAAAAAAAIQDAAA4AAAAvAMAACQAAADgAwAAXAAAAIQDAAAAAAAA1BIAAJgBAACmBAAA AAAAAKYEAAAAAAAApgQAAAAAAACmBAAAAAAAAKYEAAAAAAAApgQAACIAAADIBAAADAAAANQEAAAI AAAAmRIAAAIAAACbEgAAAAAAAJsSAAAAAAAAmxIAAAAAAACbEgAAAAAAAJsSAAAAAAAAmxIAACQA AABsFAAA9AEAAGAWAACuAAAAvxIAABUAAAAAAAAAAAAAAAAAAAAAAAAAcAMAAAAAAADcBAAAAAAA AAAAAAAAAAAAAAAAAAAAAACmBAAAAAAAAKYEAAAAAAAA3AQAAAAAAADcBAAAAAAAAL8SAAAAAAAA 9goAAAAAAABwAwAAAAAAAHADAAAAAAAApgQAAAAAAAAAAAAAAAAAAKYEAAAAAAAAeAQAAC4AAAD2 CgAAAAAAAPYKAAAAAAAA9goAAAAAAADcBAAAMgUAAHADAAAAAAAApgQAAAAAAABwAwAAAAAAAKYE AAAAAAAAmRIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAMAAAAAAACEAwAAAAAAAHADAAAAAAAAcAMA AAAAAABwAwAAAAAAAHADAAAAAAAA3AQAAAAAAACZEgAAAAAAAPYKAAAqBwAA9goAAAAAAAAgEgAA HgAAAHkSAAAYAAAAcAMAAAAAAABwAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmRIAAAAAAACmBAAAAAAAADwEAAA8AAAAIHy7CV3V vwGEAwAAAAAAAIQDAAAAAAAADgoAAOgAAACREgAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAT1JH QU5JU0FUSU9OIElOVEVSTkFUSU9OQUxFIERFIE5PUk1BTElTQVRJT04NSVNPL0lFQyBKVEMxL1ND MjkvV0cxMQ1DT0RJTkcgT0YgTU9WSU5HIFBJQ1RVUkVTIEFORCBBVURJTw0NSVNPL0lFQyBKVEMx L1NDMjkvV0cxMSBOMzM4MQ0NU291cmNlOgdNUEVHLTQgU3lzdGVtcwcHVGl0bGU6B0EgRnJhbWV3 b3JrIGZvciB0aGUgZGVsaXZlcnkgb2YgTVBFRy00IG92ZXIgSVAtYmFzZWQgUHJvdG9jb2xzBwdB dXRob3I6B0QuIFNpbmdlciAoQXBwbGUpBwdTdGF0dXM6B0FwcHJvdmVkBwcNDQ1cIiBDaGFuZ2Ug aGlzdG9yeQ1cIiANXCIgMC41CQk1LzMxLzAwCQlmaXJzdCBkcmFmdA1cIiANXCIgTm90ZXMNXCIg DVwiIA1cIiAxLiBzYXZlIGFzIHRleHQgd2l0aG91dCBsaW5lIGJyZWFrcyAoZHJhZnQtcGVyLWdl bmVyaWMtcnRwLTAwLm5yb2ZmKQ1cIiANXCIgMi4gbW92ZSB0byBhIHVuaXggYm94IGFuZCBkbywg bnJvZmYgLW1zIGRyYWZ0LXBlci1nZW5lcmljLXJ0cC0wMC5ucm9mZiA+IGRyYWZ0LXBlci1nZW5l cmljLXJ0cC0wMC50eHRucGINXCIgDVwiIDMuIG9wZW4gdGhlICx0eHRucGIgZmlsZSB3aXRoIHZp LiBkbyAxLCRzL1xdJC9cXV5MLy4gVGhpcyBhZGRzIHRoZSBwYWdlIGJyZWFrcyAoaS5lLiBmb3Jt IGZlZWRzKS4gVGhlbiBmaXggc29tZSBvZiB0aGUgcGxhY2VzIHdoZXJlIGEgZm9ybWZlZWQgc2hv dWxkIG5vdCBoYXZlIGhhcHBlbmVkIChsaWtlIGluIHRoZSByZWZlcmVuY2UgbWFya2VycykuIFNh dmUgdGhlIG5ldyBmaWxlIGFzIGRyYWZ0LXBlci1nZW5lcmljLXJ0cC0wMC50eHR0bXAuDVwiIA1c IiA0LiBkbyBjYXQgZHJhZnQtcGVyLWdlbmVyaWMtcnRwLTAwLnR4dHRtcCB8IGZpeC5zaCA+IGRy YWZ0LXNpbmdlci1tcGVnNC1pcC0wMC50eHQgKGxvb2sgYXQgUkZDMTU0MyBmb3IgZml4LnNoKQ1c IiANLnBsIDEwLjBpDS5wbyAwDS5sbCA3LjJpDS5sdCA3LjJpDS5uciBMTCA3LjJpDS5uciBMVCA3 LjJpDS5kcyBMRiBELiBTaW5nZXINLmRzIFJGIFtQYWdlICVdDS5kcyBDRg0uZHMgTEggSW50ZXJu ZXQgRHJhZnQNLmRzIFJIIEp1bmUgMzEgMjAwMA0uZHMgQ0ggZHJhZnQtc2luZ2VyLW1wZWc0LWlw LTAwDS5oeSAwDS5hZCBsDS5pbiAwDS5uZg0udGEgNy4yaVINSW50ZXJuZXQgRW5naW5lZXJpbmcg VGFzayBGb3JjZQlBdWRpby1WaWRlbyBUcmFuc3BvcnQgV0cgJiBPdGhlcnMhDUlOVEVSTkVULURS QUZUCUQuIFNpbmdlcg1kcmFmdC1zaW5nZXItbXBlZzQtaXAtMDAJQXBwbGUgQ29tcHV0ZXINCUp1 bmUgMzEgMjAwMA0JRXhwaXJlczogRGVjZW1iZXIgMzEsIDIwMDANDS5maQ0uY2UNQSBGcmFtZXdv cmsgZm9yIHRoZSBkZWxpdmVyeSBvZiBNUEVHLTQgb3ZlciBJUC1iYXNlZCBQcm90b2NvbHMNDS50 aSAwDVN0YXR1cyBvZiBUaGlzIE1lbW8NLmZpDS5pbiAzDQ1UaGlzIGRvY3VtZW50IGlzIGFuIElu dGVybmV0LURyYWZ0LiAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0 aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5k IGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQ1JbnRlcm5ldC1E cmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250 aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRv Y3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0 LSBEcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFu IGFzIGBgd29yayBpbiBwcm9ncmVzcy4nJw0NVG8gbGVhcm4gdGhlIGN1cnJlbnQgc3RhdHVzIG9m IGFueSBJbnRlcm5ldC1EcmFmdCwgcGxlYXNlIGNoZWNrIHRoZSBgYDFpZC1hYnN0cmFjdHMudHh0 JycgbGlzdGluZyBjb250YWluZWQgaW4gdGhlIEludGVybmV0LURyYWZ0cyBTaGFkb3cgRGlyZWN0 b3JpZXMgb24gZnRwLmlzLmNvLnphIChBZnJpY2EpLCBuaWMubm9yZHUubmV0IChFdXJvcGUpLCBt dW5uYXJpLm96LmF1IChQYWNpZmljIFJpbSksIGRzLmludGVybmljLm5ldCAoVVMgRWFzdCBDb2Fz dCksIG9yIGZ0cC5pc2kuZWR1IChVUyBXZXN0IENvYXN0KS4NDQ0udGkgMA1EaXN0cmlidXRpb24g b2YgdGhpcyBkb2N1bWVudCBpcyB1bmxpbWl0ZWQuDQ0NLnRpIDANQWJzdHJhY3QgDQ1UaGlzIGRv Y3VtZW50IGZvcm1zIGFuIHVtYnJlbGxhIHNwZWNpZmljYXRpb24gZm9yIHRoZSBjYXJyaWFnZSBh bmQgb3BlcmF0aW9uIG9mIE1QRUctNCBtdWx0aW1lZGlhIHNlc3Npb25zIG92ZXIgSVAtYmFzZWQg cHJvdG9jb2xzLCBpbmNsdWRpbmcgUlRQLCBSVFNQLCBhbmQgSFRUUCwgYW1vbmcgb3RoZXJzLg0N LnRpIDANMSBJbnRyb2R1Y3Rpb24NDU1QRUctNCBpcyBhIGNvbXBsZXggbXVsdGltZWRpYSBzeXN0 ZW0gZGVzaWduZWQgZm9yIGRlbGl2ZXJ5IG92ZXIgYSB2YXJpZXR5IG9mIHRyYW5zcG9ydCBwcm90 b2NvbHMuICBJdCBpbmNsdWRlcyBzY2VuZSBtYW5hZ2VtZW50LCBpbnRlcmFjdGl2aXR5LCB2aWRl bywgYXVkaW8sIGFuZCBvdGhlciBzdHJlYW1zLg0NVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIG51 bWJlciBvZiBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIGRldGFpbGVkIG1hcHBpbmcgb2YgTVBFRy00 IGludG8gc2V2ZXJhbCBJUC1iYXNlZCBwcm90b2NvbHMuIGhtIA0NT3BlbiBpc3N1ZXM6ICBpdCBt aWdodCBiZSBkZXNpcmFibGUgdG8gc2lnbmFsIHRvIHRoZSB0ZXJtaW5hbCB0aGUgYW1vdW50IG9m IGJ1ZmZlcmluZyBhc3N1bWVkIGJ5IHRoZSBlbmNvZGluZy90cmFuc21pc3Npb24gcHJvY2VzcyAo aW4gYWRkaXRpb24gdG8gYW55IG5ldHdvcmsgaml0dGVyKS4gbm8gY29tbWVudA0NLnRpIDANMiBV c2Ugb2YgUlRQDQ1UaGVyZSBhcmUgYSBudW1iZXIgb2YgSW50ZXJuZXQgRHJhZnRzIGRlc2NyaWJp bmcgUlRQIHBhY2tldGl6YXRpb24gc2NoZW1lcyBmb3IgTVBFRy00IGRhdGEgWzVdIFs2XSBbN10g WzhdIFs5XS4gIFRoaXMgZHJhZnQgZG9lcyBub3Qgc3BlY2lmeSBhbnkgbmV3IG9uZS4gIE1lZGlh LWF3YXJlIHBhY2tldGl6YXRpb24gKGUuZy4gdmlkZW8gZnJhbWVzIHNwbGl0IGF0IHJlY292ZXJh YmxlIHN1Yi1mcmFtZSBib3VuZGFyaWVzKSBpcyBhIHByaW5jaXBsZSBpbiBSVFAsIGFuZCB0aHVz IGl0IGlzIGxpa2VseSB0aGF0IHNldmVyYWwgUlRQIHNjaGVtZXMgd2lsbCBiZSBuZWVkZWQuICBv LmsuDQ1ObyBtYXR0ZXIgd2hhdCBwYWNrZXRpemF0aW9uIHNjaGVtZSBpcyB1c2VkLCB0aGVyZSBh cmUgYSBudW1iZXIgb2YgY29tbW9uIGNoYXJhY3RlcmlzdGljcyB0aGF0IGFsbCBNVVNUIGhhdmUu DQ0yLjFdICBUaGUgUlRQIHRpbWVzdGFtcCBjb3JyZXNwb25kcyB0byB0aGUgQ1RTIG9mIHRoZSBl YXJsaWVzdCBBVSB3aXRoaW4gdGhlIHBhY2tldC4gby5rLg0NMi4yXSAgUlRQIHBhY2tldHMgU0hP VUxEIGhhdmUgc2VxdWVuY2UgbnVtYmVycywgYW5kIGJlIHNlbnQsIGluIGRlY29kaW5nIG9yZGVy LiAgTm90ZSB0aGF0IGluIHRoZSBjYXNlIHdoZXJlIG11bHRpcGxlLCBpbnRlcmxlYXZlZCBhY2Nl c3MgdW5pdHMgYXJlIHNlbnQgaW4gb25lIHBhY2tldCwgdGhpcyB3aWxsIG5vdCBiZSBhZGhlcmVk IHRvIGNvbXBsZXRlbHkuICBIb3dldmVyLCBhbnkgdHJhbnNtaXNzaW9uIHNjaGVtZSBTSE9VTEQg cmVzcGVjdCBkZWNvZGluZyBkZXBlbmRlbmNpZXMgaW4gYW55IHJlLW9yZGVyaW5nIGl0IGRvZXMs IHNvIHRoYXQgZGVwZW5kZW50IGFjY2VzcyB1bml0cyBkbyBub3QgYXJyaXZlIGJlZm9yZSB0aGUg YWNjZXNzIHVuaXRzIHRoZXkgZGVwZW5kIG9uLiBvLmsuDQ0yLjNdICBUaGUgTVBFRy00IHRpbWVz Y2FsZSAoY2xvY2sgdGlja3MgcGVyIHNlY29uZCkgU0hPVUxEIGJlIHVzZWQgYXMgdGhlIFJUUCB0 aW1lc2NhbGUsIGUuZy4gYXMgZGVjbGFyZWQgaW4gUlRQLiBvLmsuDQ0yLjRdICBBbGwgc2VuZGVy cyBhbmQgcmVjZWl2ZXJzIFNIT1VMRCBpbXBsZW1lbnQgdGhlIHNpbXBsZSBzY2hlbWUgZm9yIHRo ZSBjYXJyaWFnZSBvZiAxIGVsZW1lbnRhcnkgc3RyZWFtIG92ZXIgUlRQIFs4XS4gIDEuIFNob3Vs ZCBub3QgYmUgbWFuZGF0b3J5DQ0odGhpcyBpcyAoYWxzbykgcmVsYXRlZCBhbnlob3cgdG8gdGhl IHF1ZXN0aW9uIG9mIGNhcnJ5aW5nIFNMIFBEVXMgaW4gYSBub3JtYXRpdmUgd2F5LiAgSGVyZSB3 ZSByZWVmZXIgdG8gDTEuIG91ciBhcmd1bWVudGF0aW9uIGNvbmNlcm5pbmcgdGhlIHVzYWdlIG9m ICB0aGUgU0xDb25maWdEZXNjcmlwdG9yICB0byBhY2hpZXZlICJub3JtYXRpdml0eSIgliB5b3Ug bWF5IHdhbnQgdG8gbG9vayBoZXJlIGF0IHRoZSBtYWlsIGV4Y2hhbmdlIGJldHdlZW4gQ2Fyc3Rl biBhbmQgWnZpICAiV2hhdCBkYXRhIGlzIGhhbmRlZCB0aHJvdWdoIHRoZSBEQUkgLSBhbmQgdGhl IHJlbGF0aW9uIHRvIGEgbm9ybWF0aXZlIEVTIiAodGhlIGxhdHRlciBhbHNvIGFuIG9sZCBuaWNl IHRvcGljKToNRGVhciBadmksDT5JIGNhbiByZXBlYXQgd2hhdCBJIHNhaWQgd2hlbiB3ZSBkaXNj dXNzZWQgdGhhdC4gVGhlIFNMIGluZm8gY29tZXMgb24gPnRoZSANPndpcmUgaW4gbm9uIFNMUCBm b3JtYXQsIGFuZCBoYW5kbGVkIGJ5IHRoZSBwbGF5ZXIgYWZ0ZXIgcGFyc2luZy4gSSBzZWUgdmVy eQ0+bGl0dGxlIHBvaW50IGluIGVuY29kaW5nIHRoZSBoZWFkZXIgaW50byBTTFAgYW5kIHRoZW4g ZGVjb2RlIGl0IGJhY2sganVzdCANPmZvciB0aGUgcHVycG9zZSBvZiBwYXNzaW5nIGl0IHRocm91 Z2ggdGhlIERBSS4gWW91IHdvdWxkbid0IHJlYWxseSBleHBlY3QgDT5hbnkgcmVhbCBpbXBsZW1l bnRhdGlvbiB0byBkbyB0aGlzIHNpbGx5IHRoaW5nLg1BZ3JlZWQuDSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMi4gd2hhdCBhYm91dCB0aGUgSk5CIHBy b3Bvc2FsIGZvciBILjMyMyB1c2FnZT8gIA0NDQ0yLjVdICBUaGVyZSBpcyBhIHNpbmdsZSBwYXls b2FkIGZvcm1hdCBmb3IgdGhlIGNhcnJpYWdlIG9mIEZsZXhtdXggb3ZlciBSVFAgWzVdLiAgU2Vu ZGVycyBhbmQgcmVjZWl2ZXJzIE1BWSBpbXBsZW1lbnQgdGhpcyBzY2hlbWUuIA0NMi42XSAgU3Ry ZWFtcyBTSE9VTEQgYmUgc3luY2hyb25pemVkIHVzaW5nIFJUUCB0ZWNobmlxdWVzIChub3RhYmxl IFJUQ1Agc2VuZGVyIHJlcG9ydHMpOyAgdGhlIE1QRUctNCBPQ1IgaXMgbG9naWNhbGx5IG1hcHBl ZCB0byB0aGUgTlRQIHRpbWUgYXhpcyB1c2VkIGluIFJUQ1Auby5rLg0NT3RoZXIgcGF5bG9hZCBm b3JtYXRzIE1BWSBiZSB1c2VkLiAgVGhleSBhcmUgc2lnbmFsbGVkIGFzIHNlcGFyYXRlIFJUUCBw YXlsb2FkIG5hbWVzLXR5cGVzLiAgSW4gcGFydGljdWxhciwgdGhlIGRldmVsb3BtZW50IG9mIHNw ZWNpYWxpemVkIFJUUCBwYXlsb2FkcyBmb3IgdmlkZW8gKGUuZy4gcmVzcGVjdGluZyB2aWRlbyBw YWNrZXRzKSBhbmQgYXVkaW8gKGUuZy4gcHJvdmlkaW5nIGludGVybGVhdmUgWzEwXSkgaXMgZXhw ZWN0ZWQuICBJdCBpcyBwb3NzaWJsZSB0aGF0IHRoZXNlIHNjaGVtZXMgY2FuIGJlIGNvbXBhdGli bGUgd2l0aCB0aGUgc2ltcGxlIHNjaGVtZSB1c2VkIGhlcmUgWzhdLiBubyBjb21tZW50DQ1Gb3Ig dGhvc2Ugc3RyZWFtcyByZXF1aXJpbmcgcmVsaWFibGUgZGVsaXZlcnksIHRoZSByZWNvbW1lbmRh dGlvbiBpcyB0byBsZXZlcmFnZSBleGlzdGluZyB3b3JrIGluIHRoZSBJRVRGIGluIHRoaXMgYXJl YSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8gRkVDLCByZS10cmFuc21pc3Npb24sIG9y IHJlcGV0aXRpb24pLCByYXRoZXIgdGhhbiBtYWtpbmcgaXQgYSBjaGFyYWN0ZXJpc3RpYyBvZiB0 aGUgcGFja2luZyBzY2hlbWUgaXRzZWxmLiAgd2UgIChhZnRlciAyIHllYXJzIG9mIGRpc2N1c3Np b24pIC0gIGRpc2FncmVlOiAgIHdoYXQgYWJvdXQgYWxsIHRoZSBudW1lcm91cyBub24tbXBlZzQg cGF5bG9hZHMgaW4gYWRkaXRpb24gdG8gb3VycyAgLSB3aGljaCAtIGZvciBnb29kIHJlYXNvbnMg IC0gZGlkIG5vdCBmb2xsb3cgdGhpcyByZWNvbW1lbmRhdGlvbi4/IGUuZy4gUlRQIFBheWxvYWQg Zm9yIFJlZHVuZGFudCBBdWRpbyBEYXRhIChSRkMyMTk4KSwgIG9yIGV2ZW4sIGlmICB3ZSBhcmUg bm90IHRvdGFsbHkgbWlzZ3VpZGVkLCB0aGUgcmVmLiAxMCBiZWxvdy4NSW4gYWRkaXRpb24gLCBp biBvcmRlciB0byBzdXBwb3J0IFVFUCB5b3UgaGF2ZSB0byBhcHBseSB0aGUgRkVDIHRvIHRoZSBk YXRhIGFuZCB0aGVuIGVuY2Fwc3VsYXRlIJYgdGhlIG90aGVyIHdheSByb3VuZCBkb2VzIG5vdCBt YWtlIHNlbnNlLg0LIA0NDS50aSAwDTMgTUlNRSBUeXBlcw0NMy4xXSBXaGVuIGFuIE1QNCBmaWxl IGlzIHNlcnZlZCAoZS5nLiBvdmVyIEhUVFApIG9yIG90aGVyd2lzZSBtdXN0IGJlIGlkZW50aWZp ZWQgYnkgYSBNSU1FIHR5cGUsIHRoZSB0eXBlICJ2aWRlby9tcGVnNCIgIFNIT1VMRCBiZSB1c2Vk LiAgVGhlIHR5cGUgImF1ZGlvL21wZWc0IiBNQVkgYmUgdXNlZCB3aGVuIHRoZSBNUEVHLTQgcHJl c2VudGF0aW9uIGNvbnRhaW5lZCB3aXRoaW4gdGhlIE1QNCBmaWxlIGhhcyBubyB2aXN1YWwgYXNw ZWN0cyBhbmQgaXMgZW50aXJlbHkgYXVkaXRvcnkuDQ0zLjJdICBJbiBzb21lIGNhc2VzLCB0aGUg aW5pdGlhbCBvYmplY3QgZGVzY3JpcHRvciBuZWVkcyB0byBiZSBpZGVudGlmaWVkIHdpdGggYSBN SU1FIHR5cGUuIEluIHRoaXMgY2FzZSwgdGhlIHR5cGUgImFwcGxpY2F0aW9uL3gtbXBlZzQtaW9k IiBTSE9VTEQgYmUgdXNlZC4NDTMuM10gSW4gc29tZSBjYXNlcywgdGhlIG11eGNvZGUgdGFibGUg bmVlZGVkIGJ5IGEgZmxleG11eCBkZWNvZGVyIG5lZWRzIHRvIGJlIGlkZW50aWZpZWQgd2l0aCBh IE1JTUUgdHlwZS4gSW4gdGhpcyBjYXNlLCB0aGUgdHlwZSAiYXBwbGljYXRpb24veC1tcGVnNC1t dXhjb2RldGFibGUiIFNIT1VMRCBiZSB1c2VkLg0NMy40XSBUaGUgcGF5bG9hZCBuYW1lcyB1c2Vk IGluIGFuIFJUUE1BUCBhdHRyaWJ1dGUgd2l0aGluIFNEUCwgdG8gc3BlY2lmeSB0aGUgbWFwcGlu ZyBvZiBwYXlsb2FkIG51bWJlciB0byBpdHMgZGVmaW5pdGlvbiwgYWxzbyBjb21lIGZyb20gdGhl IE1JTUUgbmFtZXNwYWNlLiAgRWFjaCBvZiB0aGUgUlRQIHBheWxvYWQgbWFwcGluZ3MgZGVmaW5l ZCBhYm92ZSBoYXMgYSBkaXN0aW5jdCBuYW1lLiAgRm9yIHRob3NlIHBheWxvYWRzIGNhcnJ5aW5n IGEgdmFyaWV0eSBvZiBNUEVHIHN0cmVhbSB0eXBlcywgdGhlIG5hbWUgU0hPVUxEIGJlIGRyYXdu IGZyb20gdGhlICJ2aWRlbyIgbmFtZXNwYWNlLiAgRm9yIHRob3NlIHBheWxvYWRzIHNwZWNpZmlj IHRvIGF1ZGlvIG9ubHksIHRoZSBuYW1lIFNIT1VMRCBiZSBkcmF3biBmcm9tIHRoZSAiYXVkaW8i IG5hbWVzcGFjZS4NDS50aSAwDTQgU0RQIEluZm9ybWF0aW9uDQ1DdXJyZW50bHkgaXQgaXMgYXNz dW1lZCB0aGF0IGFueSBzZXNzaW9uIGRlc2NyaWJlZCBieSBTRFAgKGUuZy4gaW4gU0FQLCBhcyBh IGZpbGUgZG93bmxvYWQsIGFzIGEgREVTQ1JJQkUgb3ZlciBSVFNQKSBoYXMgYXQgbW9zdCBvbmUg TVBFRy00IHNlc3Npb24uICBJdCBpcyBkZXNpcmFibGUgdGhhdCB0aGlzIHJlc3RyaWN0aW9uIGJl IGxpZnRlZC4NDTMuMV0gU2VuZGVycyBTSE9VTEQgYWxlcnQgcmVjZWl2ZXJzIHRoYXQgYW4gTVBF Ry00IHNlc3Npb24gaXMgaW5jbHVkZWQsIGJ5IG1lYW5zIG9mIGFuIFNEUCBhdHRyaWJ1dGUgdGhh dCBpcyBnZW5lcmFsIChpLmUuIGJlZm9yZSBhbnkgIm1lZGlhIiBsaW5lcykuICBUaGlzIHRha2Vz IHRoZSBmb3JtIG9mIGFuIGF0dHJpYnV0ZSBsaW5lOg0NYT14LW1wZWc0LWlvZCBbPGxvY2F0aW9u Pl0NDUluIGFuIFJUU1Agc2Vzc2lvbiwgdGhlIGxvY2F0aW9uIGlzIG9wdGlvbmFsLiAgSWYgbm90 IHN1cHBsaWVkLCB0aGUgSU9EIGlzIHJldHJpZXZlZCBvdmVyIHRoZSBSVFNQIHNlc3Npb24gYnkg dXNpbmcgREVTQ1JJQkUgd2l0aCBhbiBhY2NlcHQgb2YgdHlwZSBhcHBsaWNhdGlvbi94LW1wZWc0 LWlvZC4gV2hlcmUgdGhlIFNEUCBpbmZvcm1hdGlvbiBpcyBzdXBwbGllZCBieSBzb21lIG90aGVy IG1lYW5zIChlLmcuIGFzIGEgZmlsZSwgaW4gU0FQKSwgdGhlIGxvY2F0aW9uIGlzIG9ibGlnYXRv cnkgYW5kIHNob3VsZCBiZSBhIFVSTCBlbmNsb3NlZCBpbiBkb3VibGUtcXVvdGVzLCB3aGljaCB3 aWxsIHN1cHBseSB0aGUgSU9EIChlLmcuIHNtYWxsIG9uZXMgbWF5IGJlIGVuY29kZWQgdXNpbmcg REFUQTosIG9yIG90aGVyd2lzZSBIVFRQOiBvciBvdGhlciBzdWl0YWJsZSBmaWxlLWFjY2VzcyBV UkwpLg0NMy4yXSBUaGUgbWFwcGluZyBvZiBSVFAgc3RyZWFtcyB0byBlbGVtZW50YXJ5IHN0cmVh bXMuIFRoaXMgbmVlZHMgdG8gY292ZXIgdGhlIEZsZXhtdXggY2FzZSBhcyB3ZWxsIGFzIHRoZSBz aW5nbGUgc3RyZWFtLiAgV2l0aGluIHRoZSBTRFAgaW5mb3JtYXRpb24sIGEgc3RyZWFtLXNwZWNp ZmljIGF0dHJpYnV0ZSBTSE9VTEQgYmUgcHJlc2VudCBmb3IgZWFjaCBNUEVHLTQgc3RyZWFtLiAg SXQgdGFrZXMgb25lIG9mIHR3byBmb3JtcywgZGVwZW5kaW5nIG9uIHdoZXRoZXIgYSBzaW5nbGUg ZWxlbWVudGFyeSBzdHJlYW0sIG9yIGEgZmxleG11eCwgaXMgY2FycmllZC4NDWE9eC1tcGVnNC1l c2lkIGEuYi5jDW9yDWE9eC1tcGVnNC1lc2lkcyBtLmk6YS5iLmMsbi5rOnAucQ0NVGhlIGZpcnN0 IGF0dHJpYnV0ZSBpcyB1c2VkIGZvciBzaW5nbGUgc3RyZWFtczsgdGhlIHNlY29uZCBmb3IgZmxl eG11eC4gIEluIHRoaXMsIGEgaXMgdGhlIEVTSUQgb2YgdGhlIHRvcC1sZXZlbCBPRCBzdHJlYW0g KGRlY2xhcmVkIHdpdGhpbiB0aGUgSU9EKSwgYiBpcyB0aGUgRVNJRCB3aXRoaW4gdGhhdCBzY29w ZSBvZiBhbm90aGVyIE9EIHN0cmVhbSwgYW5kIGMgaXMgdGhlIEVTSUQgd2l0aGluIHRoYXQgc2Nv cGUgb2YgdGhlIHN0cmVhbTsgIHNpbWlsYXJseSBmb3IgcCBhbmQgcS4gIG0gYW5kIG4gYXJlIG11 eGNvZGVzIChpZGVudGlmeWluZyB0aGUgdGFibGUgdXNlZCksIGFuZCBpIGFuZCBrIGFyZSBmbGV4 bXV4IGNoYW5uZWwgbnVtYmVycyB3aXRoaW4gdGhlIGluZGljYXRlZCBtdXhjb2RlLg0NMy4zXSBU aGUgZmxleG11eCBzdHJlYW0gYWxzbyBuZWVkcyBhIG11eGNvZGUgdGFibGUgc3VwcGxpZWQgdG8g dGhlIHJlY2VpdmVyLiAgVGhlc2UgYXJlIGluZGljYXRlZCB2aWEgYSBzdHJlYW0tbGV2ZWwgYXR0 cmlidXRlLiANDWE9eC1tcGVnNC1tdXhjb2RldGFibGUgPGxvY2F0aW9uPg0Nd2hlcmUgPGxvY2F0 aW9uPiBpcyBhIFVSTCBlbmNsb3NlZCBpbiBkb3VibGUgcXVvdGVzLCB0aGF0IHdpbGwgc3VwcGx5 IHRoZSB0YWJsZShzKS4gIElmIHRoZXkgYXJlIHNtYWxsLCBhIERBVEE6IFVSTCB3aWxsIHByb2Jh Ymx5IHN1ZmZpY2UgdG8gY2FycnkgdGhlbSBpbi1saW5lLiBJZiBub3QsIHRoZSBVUkwgc2hvdWxk IHVzZSBhIGZpbGUtcmV0cmlldmFsIHNjaGVtZSAoZS5nLiBIVFRQLCBGVFApLiBUaGUgZGF0YSBh dCB0aGUgaW5kaWNhdGVkIFVSTCBjb25zaXN0cyBvZiBzb21lIG51bWJlciBvZiBjb25jYXRlbmF0 ZWQgbXV4Y29kZSB0YWJsZXMsIGNvbXBsZXRlLCBpbiBiaW5hcnkgZm9ybWF0IChidXQgbm90ZSB0 aGF0IERBVEEgVVJMcyBhbGxvdyBmb3IgYmFzZTY0IGVuY29kaW5nIG9mIGJpbmFyeSBkYXRhLCB3 aGljaCB3b3VsZCBiZSBuZWVkZWQgaGVyZSkuICBUaGUgbWltZSB0eXBlIG9mIGEgbXV4Y29kZSB0 YWJsZSBuZWVkcyBkZWNpZGluZyAoYXBwbGljYXRpb24veC1tcGVnNC1tdXhjb2RldGFibGUpLiBU aGVzZSB0YWJsZXMgaGF2ZSBhbiBpbnRyaW5zaWMgbGVuZ3RoLCBzbyBzaW1wbGUgY29uY2F0ZW5h dGlvbiBzdWZmaWNlcy4NDQ0udGkgMA01ICBSVFNQIHVzYWdlDQ1SVFNQIG1heSBiZSB1c2VkIGFz IGEgc2Vzc2lvbiBjb250cm9sIHByb3RvY29sIGZvciBzZXNzaW9ucyB3aGljaCBjYXJyeSBNUEVH LTQgaW5mb3JtYXRpb24uICBXaGVuIFJUU1AgaXMgdXNlZCBhcyBhIHNlc3Npb24tY29udHJvbCBw cm90b2NvbDoNDTUuMV0gIFJUUCBTSE9VTEQgYmUgdXNlZCBhcyB0aGUgdHJhbnNwb3J0IHByb3Rv Y29sLg0NNS4yXSBUaGUgaW5pdGlhbCBERVNDUklCRSBmb3JtYXQgU0hPVUxEIGJlIFNEUC4gIElm IHRoZSBTRFAgaW5mb3JtYXRpb24gcmV2ZWFscyB0aGF0IGFuIElPRCBpcyBuZWVkZWQsIGFuZCB0 aGUgdGVybWluYWwgZG9lcyBub3QgYWxyZWFkeSBoYXZlIGl0LCB0aGVuIGEgc2Vjb25kIERFU0NS SUJFIGFjY2VwdGluZyBhbiBJT0QgU0hPVUxEIGJlIHBlcmZvcm1lZCAoc2VlIGFib3ZlKS4NDTUu M10gTm90ZSB0aGF0IGlmIGFsbCBNUEVHLTQgc3RyZWFtcyBhcmUgY2xvc2VkIChURUFSRE9XTikg dGhlbiB0aGUgUlRTUCBzZXNzaW9uIElEIHdpbGwgYmUgbG9zdC4gIFRoZSBuZXh0IChyZS0pb3Bl bmVkIHN0cmVhbSB3aWxsIHN1cHBseSBhIG5ldyBzZXNzaW9uIElELiAgQ2FyZSBzaG91bGQgYmUg dGFrZW4gdGhhdCB0aGUgdGFyZ2V0IG9mIHRoZSBVUkwgaGFzIG5vdCBjaGFuZ2VkIGluIHRoZSBp bnRlcnZhbDsgIG5ldyBERVNDUklCRXMgbWF5IGJlIG5lZWRlZC4NDS50aSAwDTMgU0RQIFVzYWdl DQ1TRFAgaXMgdXNlZCBhcyBhIG1lY2hhbmlzbSB0byBjb252ZXkgdG8gUlRQIHJlY2VpdmVycyB0 aGUgaW5mb3JtYXRpb24gcmVxdWlyZWQgdG8gZGVjb2RlIGFuZCBwcmVzZW50IGEgc2V0IG9mIFJU UCBzZXNzaW9ucy4gU0RQIGNhbiBiZSB1c2VkIGFzIGFuIGFubm91bmNlbWVudCBtZWNoYW5pc20g YXMgZGVzY3JpYmVkIGluIFs5XSBvciBjYW4gYmUgdXNlZCBhcyBhIGRlc2NyaXB0aW9uIGZvcm1h dCB3aXRoIHRoZSBSZWFsIFRpbWUgU3RyZWFtaW5nIFByb3RvY29sIFs2XS4gSW4gYm90aCBjYXNl cywgU0RQIGlzIHVzZWQgdG8gc3BlY2lmeSB0aGUgc2V0IG9mIFJUUCBzZXNzaW9ucyBiZWluZyB0 cmFuc21pdHRlZCwgdGhlIG1lZGlhIHR5cGUgaW4gZWFjaCBzZXNzaW9uLCB0aGUgcGF5bG9hZCBm b3JtYXQgYW5kIGVuY29kaW5nIGZvcm1hdCBvZiBlYWNoIHNlc3Npb24gYW5kIG90aGVyIHBhcmFt ZXRlcnMgYXNzb2NpYXRlZCB3aXRoIGVhY2ggc2Vzc2lvbi4NDVRoaXMgcHJvcG9zYWwgZGVmaW5l cyBhIHNldCBvZiBleHRlbnNpb25zIHRvIHRoZSBtZWNoYW5pc21zIGFscmVhZHkgZGVmaW5lZCBi eSBTRFAuIFRoZXNlIGV4dGVuc2lvbnMgYXJlIHVzZWQgdG8gY29udmV5IHRoZSBmb2xsb3dpbmcg aW5mb3JtYXRpb246DQ0tIFJUUCBwYWNrZXRpemF0aW9uIHNjaGVtZQ0NLSBNZWRpYSBzYW1wbGUg ZW5jb2RpbmcgZm9ybWF0DQ0tIFBhcmFtZXRlcnMgZm9yIHRoZSBtZWRpYSBlbmNvZGluZyBmb3Jt YXQNDVRoZSBTRFAgcnRwbWFwIGFuZCBmbXRwIGF0dHJpYnV0ZXMgYXJlIHVzZWQgdG8gY29udmV5 IHRoZSBhYm92ZSBpbmZvcm1hdGlvbi4NDQ0udGkgMA1BY2tub3dsZWRnbWVudHMNDVRoaXMgZHJh ZnQgaGFzIGJlbmVmaXRlZCBncmVhdGx5IGJ5IGNvbnRyaWJ1dGlvbnMgZnJvbSBtYW55IHBlb3Bs ZSwgaW5jbHVkaW5nIE1pa2UgQ29sZW1hbiwgSmVhbi1DbGF1ZGUgRHVmb3JkLCBQZXRlciBXZXN0 ZXJpbmssIENhcnN0ZW4gSGVycGVsLCBPbGl2aWVyIEF2YXJvLCBhbmQgbWFueSBvdGhlcnMuICBU aGVpciBpbnNpZ2h0LCBmb3Jlc2lnaHQsIGFuZCBjb250cmlidXRpb24gaXMgZ3JhdGVmdWxseSBh Y2tub3dsZWRnZWQuDQ0uYnANLnRpIDANDFJlZmVyZW5jZXMNDVsxXSBILiBTY2h1bHpyaW5uZSwg ZXQuIGFsLiwgIlJUUCA6IEEgVHJhbnNwb3J0IFByb3RvY29sIGZvciBSZWFsLVRpbWUgQXBwbGlj YXRpb25zIiwgSUVURiBSRkMgMTg4OSwgSmFudWFyeSAxOTk2LiANDVsyXSBILiBTY2h1bHpyaW5u ZSwgZXQuIGFsLiwgIlJUUCBQcm9maWxlIGZvciBBdWRpbyBhbmQgVmlkZW8gQ29uZmVyZW5jZSB3 aXRoIE1pbmltYWwgQ29udHJvbCIsIElFVEYgUkZDIDE4OTAsIEphbnVhcnkgMTk5Ni4NDVszXSBI LiBTY2h1bHpyaW5uZSwgZXQuIGFsLiwgIlJlYWwgVGltZSBTdHJlYW1pbmcgUHJvdG9jb2wiLCBJ RVRGIERyYWZ0LCBkcmFmdC1pZXRmLW1tdXNpYy1ydHNwLTA5LnR4dCwgRmVicnVhcnkgMiAxOTk4 LCBFeHBpcmVzOiBBdWd1c3QgMiAxOTk4Lg0NWzRdIE0uIEhhbmRsZXksICJTRFA6IFNlc3Npb24g RGVzY3JpcHRpb24gUHJvdG9jb2wiLCBJRVRGIERyYWZ0LCBkcmFmdC1pZXRmLW1tdXNpYy1zZHAt MDUudHh0LCBOb3ZlbWJlciAyMSAxOTk3LCBFeHBpcmVzOiBOb3ZlbWJlciAyMSAxOTk4Lg0NWzVd IEMuUm91eCAgZXQgYWwuLCAiUlRQIFBheWxvYWQgRm9ybWF0IGZvciBGbGV4bXVsdGlwbGV4ZWQg TVBFRy00IFN0cmVhbXMiLCBJRVRGIERyYWZ0LCBkcmFmdC1yZ2NjLWF2dC1tcGVnNGZsZXhtdXgt MDAsIE1hcmNoLCAwOSAyMDAwIGV4cGlyZXMgU2VwdCA5IDIwMDANDVs2XSBZb3NoaWhpcm8gS2lr dWNoaSBldCBhbC4sICJSVFAgcGF5bG9hZCBmb3JtYXQgZm9yIE1QRUctNCBBdWRpby9WaXN1YWwg c3RyZWFtcyIsIElFVEYgRHJhZnQsIGRyYWZ0LWlldGYtYXZ0LXJ0cC1tcGVnNC1lcy0wMSwgRmVi IDEgMjAwMCwgZXhwaXJlcyBBdWcgMSAyMDAwDQ1bN10gQy5HdWlsbGVtb3QgZXQgYWwuLCAiUlRQ IFBheWxvYWQgRm9ybWF0IGZvciBNUEVHLTQgd2l0aCBGbGV4aWJsZSBFcnJvciBSZXNpbGllbmN5 IiwgSUVURiBEcmFmdCwgZHJhZnQtaWV0Zi1hdnQtbXBlZzRzdHJlYW1zLTAwLCBNYXJjaCAxIDIw MDAsIGV4cGlyZXMgU2VwdCAxIDIwMDANDVs4XSBSIENpdmFubGFyIGV0IGFsLiwgIiBSVFAgUGF5 bG9hZCBGb3JtYXQgZm9yIE1QRUctNCBTdHJlYW1zIiwgSUVURiBEcmFmdCwgZHJhZnQtaWV0Zi1h dnQtcnRwLW1wZWc0LTAyLCA/PyAyMDAwLCBleHBpcmVzID8/IDIwMDAwDQ1bOV0gQy5HdWlsbGVt b3QgZXQgYWwuLCAiUlRQIHBheWxvYWQgZm9ybWF0IGZvciBNUEVHLTQgVmlzdWFsIEFkdmFuY2Vk IFByb2ZpbGVzIiwgSUVURiBEcmFmdCwgZHJhZnQtZ2MtYXZ0LW1wZWc0dmlzdWFsLTAwLnR4dCwg TWFyY2ggMSAyMDAwLCBleHBpcmVzIFNlcHQgMSAyMDAwDQ1bMTBdIFIuIEZpbmxheXNvbiwgIkEg TW9yZSBMb3NzLVRvbGVyYW50IFJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgTVAzIEF1ZGlvIiwgSUVU RiBEcmFmdCwgZHJhZnQtaWV0Zi1hdnQtcnRwLW1wMy0wMS50eHQsIE1hciAxMCAyMDAwLCBleHBp cmVzIFNlcCAxMCAyMDAwDQ0udGkgMA1BdXRob3JzJyBDb250YWN0IEluZm9ybWF0aW9uDS5uZg1E YXZpZCBTaW5nZXINRW1haWw6IHNpbmdlckBhcHBsZS5jb20NVGVsOiArMSA0MDggOTc0IDMxNjIN DUFwcGxlIENvbXB1dGVyLCBJbmMuDU9uZSBJbmZpbml0ZSBMb29wLCBNUzozMDItM01UDUN1cGVy dGlubyAgQ0EgOTUwMTQNVVNBDQ0uZmkNDVwiSW50ZXJuZXQgRHJhZnQJZHJhZnQtcGVyaXlhbm5h bi1nZW5lcmljLXJ0cC0wMAlNYXJjaCAxMywgMTk5Nw0NXCJBLiBQZXJpeWFubmFuLCBELiBTaW5n ZXIsIE0uIFNwZWVyCQlbUGFnZSAAXQ0NXCJBLiBQZXJpeWFubmFuLCBELiBTaW5nZXIsIE0uIFNw ZWVyCQlbUGFnZSAAXQ0NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGcEAAB/BAAAgAQAAIUEAACGBAAAhwQAAKYEAADk BAAA5QQAAO4EAAAABQAAAQUAAAkFAAASBQAAEwUAABYFAABiCAAAvggAANYIAAARCQAAGAkAAFkJ AABeCQAAcwkAAH0JAACfDAAApAwAANMMAADYDAAAlg0AAJsNAACcDQAAqg0AANQOAADVDgAA1w4A ANgOAACBDwAAjA8AAI4PAACTDwAAlA8AAKEPAADqEAAA6xAAAPAQAAC1EQAAuhEAAEMTAABEEwAA SBMAALsTAADAEwAAOhQAADsUAAD7+fXx9QD5AO757gD57vkA7ADsAOYA7ADsAOwA7ADsAOQA29LJ AMAA7ADkALeuAK4ApZwAkwCTAAAAAAAAAAAAAAAAAAAAEQEIgQRIAQAFaEtsRkYHSAAAEQEIgQRI AQAFaEpsRkYHSAAAEQEIgQRIAQAFaElsRkYHSAAAEQEIgQRIAQAFaEhsRkYHSAAAEQEIgQRIAQAF aEZsRkYHSAAAEQEIgQRIAQAFaEVsRkYHSAAAEQEIgQRIAQAFaERsRkYHSAAAEQEIgQRIAQAFaIRs RkYHSAAAEQEIgQRIAQAFaENsRkYHSAAAAz4qAQs8CIFDShIARUgGAAM8CIEEbUgJBAAHNQiBQ0os AAc1CIFDSiQAAzUIgQc1CIFDShwAADcABAAALQQAAEQEAABoBAAAaQQAAIYEAACHBAAAjwQAAJ4E AACfBAAApgQAAOUEAADmBAAA7gQAAAAFAAABBQAACQUAABIFAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPYAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOUAAAAAAAAAAAAA AADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAL4cAQAAAAAAAAAAAADiAAAAAAAAAAAAAAAAuwAA AAAAAAAAAAAAAJlsAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAAuwAAAAAAAAAAAAAAAJlIAAAAAAAA AAAAAADiAAAAAAAAAAAAAAAAuwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIQAAFiQBFyQBApZs AAM0AQjWMAACAABABY4kAAZABQAAAAAAAAAAAAAAAAAAAAAABk4fAAAAAAAAAAAAAAAAAAAAAAMX ABYkAQAjAAAWJAEXJAEClmwAB5QkAQM0AQjWMAACAABABY4kAAZABQAAAAAAAAAAAAAAAAAAAAAA Bk4fAAAAAAAAAAAAAAAAAAAAAAMAABYkAQABAAAABAAAAyQCQCYACgAAAyQBEmQQ/wAADcYFAAEL FQAACAAAAyQBDoQ5/w+E5P5AJgAAEQAEAAAtBAAARAQAAGgEAABpBAAAhgQAAIcEAACPBAAAngQA AJ8EAACmBAAA5QQAAOYEAADuBAAAAAUAAAEFAAAJBQAAEgUAABMFAAAUBQAAFQUAABYFAAAoBQAA LAUAAEkFAABNBQAAVgUAAFoFAABeBQAApgUAAKoFAAAWBgAAGgYAABwHAAAgBwAAkgcAAJYHAACg BwAApgcAAK8HAAC4BwAAxAcAANAHAAD+/v77/vjz7url3trVzsrFvrq1sq+sqaajoJ2al5SRjouI hYJ/fHl2c3AAAAAAAAAAAAAABQal/P//BQax/P//BQa6/P//BQbD/P//BQbJ/P//BQbT/P//BQbX /P//BQZJ/f//BQZN/f//BQZP/v//BQZT/v//BQa//v//BQbD/v//BQYL////BQYP////BQYT//// BQYc////BQYg////BQY9////BQZB////BQZT////BQZU////BQZV////CAIWAAZW////AAcDAQZX ////DAIXAAMBBQoGYP///wAJAwEFCgZo////BwMBBmn///8MAhcAAwEFCgZ7////AAkDAQUKBoP/ //8HAwEGhP///wwCFwADAQUKBsP///8ACQMBBQoGyv///wcDAQbL////CQMBBQoG2v///wkDAQUK BuL///8FBuP///8FBtz///8CBQAqEgUAABMFAAAUBQAAFQUAABYFAAAoBQAALAUAAEkFAABNBQAA VgUAAFoFAABeBQAApgUAAKoFAAAWBgAAGgYAABwHAAAgBwAAkgcAAJYHAACgBwAApgcAAK8HAAC4 BwAAxAcAANAHAADdAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAAAAAA AAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAA ANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAA AAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAA AAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZ AAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAAAAAAAAAA AQAAAAEWAAAhAAAWJAEXJAEClmwAAzQBCNYwAAIAAEAFjiQABkAFAAAAAAAAAAAAAAAAAAAAAAAG Th8AAAAAAAAAAAAAAAAAAAAAABnQBwAA4QcAAPEHAAD4BwAADggAACIIAABCCAAASAgAAE4IAABU CAAAWAgAAGIIAAClCAAAvggAAOYIAAD0CAAAEAkAABEJAAAVCQAAGQkAAFgJAABZCQAAXwkAAHMJ AAB3CQAAfQkAAH4JAABtCgAAbgoAAHYLAAB3CwAAnQwAAJ4MAACfDAAApQwAANEMAADSDAAA0wwA ANkMAADjDAAA5AwAAJUNAACWDQAAnA0AAPz59vPw7ern5OHe29jV0s/MycbDwL26t7SxrKeinZiV ko+MiYaDgH14dXIAAAAAAAAAAAAFBtP2//8FBtT2//8IAg8ABoX3//8ABQaG9///BQaQ9///BQaW 9///BQaX9///BQaY9///BQbE9///BQbK9///BQbL9///BQbM9///CAIPAAby+P//AAgCDwAG8/j/ /wAIAg8ABvv5//8ACAIPAAb8+f//AAgCDwAG6/r//wAFBuz6//8FBvL6//8FBvb6//8FBgr7//8F BhD7//8FBhH7//8FBlD7//8FBlT7//8FBlj7//8FBln7//8FBnX7//8FBoP7//8FBqv7//8FBsT7 //8FBgf8//8FBhH8//8FBhX8//8FBhv8//8FBiH8//8FBif8//8FBkf8//8FBlv8//8FBnH8//8F Bnj8//8FBoj8//8FBpn8//8AK9AHAADhBwAA8QcAAPgHAAAOCAAAIggAAEIIAABICAAATggAAFQI AABYCAAAYggAAKUIAAC+CAAA5ggAAPQIAAAQCQAAEQkAABUJAAAZCQAAWAkAAFkJAABfCQAAcwkA AHcJAAB9CQAAfgkAAG0KAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAA AADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAAAAAEPAAMAAAMkAQAFAAANxgUAAcAhAgcAAAMkAw3G BQABwCECAwAAAyQDAAEAAAAbbQoAAG4KAAB2CwAAdwsAAJ0MAACeDAAAnwwAAKUMAADRDAAA0gwA ANMMAADZDAAA4wwAAOQMAACVDQAAlg0AAJwNAACrDQAArA0AAF4OAABfDgAA2Q4AANoOAACNDwAA jg8AAJQPAAChDwAAog8AAPEQAADyEAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAA APsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAA AAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAA AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAA AAAAAAEQAAABAAAAAQ8AAB2cDQAAqw0AAKwNAABeDgAAXw4AANkOAADaDgAAjQ8AAI4PAACUDwAA oQ8AAKIPAADxEAAA8hAAAGARAABhEQAAuxEAALwRAABJEwAAShMAAMETAADCEwAAVxQAAFgUAADD FAAA3BUAAOYVAAAzFgAAgBYAAMwWAAAYFwAASRcAAFEXAAC1FwAAthcAALcXAAC4FwAA/Pn07+rl 4N3a19TPysXAu7axrKeinZiTjImGgX57eHVwa2ZhAAAAAAAAAAAAAAgCEAAGsuz//wAIAhAABrPs //8ACAIQAAa07P//AAgCEAAGGO3//wAFBiDt//8FBlHt//8FBp3t//8FBunt//8IAhoABjbu//8A BQaD7v//BQaN7v//DQIQAAam7///CAEACQEIAhAABhHw//8ACAIQAAYS8P//AAgCEAAGp/D//wAI AhAABqjw//8ACAIQAAYf8f//AAgCEAAGIPH//wAIAhAABq3y//8ACAIQAAau8v//AAgCEAAGCPP/ /wAIAhAABgnz//8ACAIQAAZ38///AAgCEAAGePP//wAIAhAABsf0//8ABQbI9P//BQbV9P//BQbb 9P//BQbc9P//CAIQAAaP9f//AAgCEAAGkPX//wAIAhAABgr2//8ACAIQAAYL9v//AAgCEAAGvfb/ /wAFBr72//8FBs32//8AJPIQAABgEQAAYREAALsRAAC8EQAASRMAAEoTAADBEwAAwhMAAFcUAABY FAAAwxQAANwVAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAASBAACiYAC0YBAEMkAUXGgAAAAQCWbEZGAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQQAEMkAUXGgAAAAQDT bEZGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEQAAAMOxQAAFgUAABZFAAAYRQAAGgUAACHFAAAiRQAAJMUAAC4FAAAvhQAAMMU AADGFAAAyhQAANcUAADjFAAA9RQAAP0UAAA5FQAAPhUAAFMVAABrFQAAtRUAANoVAADcFQAAMxYA AIAWAABJFwAAUBcAAFEXAAB/FwAAgxcAAIUXAACGFwAAiRcAAPbt5O3k2+Tb0tvJwLfAt8C3rreu pZyTfpN+b7ftZslmXQAAAAAAAAAAAAAAAAAAAAAAEQEIgQRIAQAFaEtsRkYHSAAAEQEIgQRIAQAF aJxsRkYHSAAAHAEIgQRIAQAFaJpsRkYHSAAAaAgAbUgHBG5IBwQAKAEIgQRIAQAFaJpsRkYHSAAA Q0oUAE9KAwBRSgMAaAgAbUgHBG5IBwQAEQEIgQRIAQAFaJpsRkYHSAAAEQEIgQRIAQAFaNVsRkYH SAAAEQEIgQRIAQAFaJhsRkYHSAAAEQEIgQRIAQAFaJdsRkYHSAAAEQEIgQRIAQAFaJZsRkYHSAAA EQEIgQRIAQAFaJVsRkYHSAAAEQEIgQRIAQAFaJtsRkYHSAAAEQEIgQRIAQAFaJlsRkYHSAAAEQEI gQRIAQAFaJRsRkYHSAAAEQEIgQRIAQAFaJNsRkYHSAAAEQEIgQRIAQAFaNRsRkYHSAAAEQEIgQRI AQAFaNNsRkYHSAAAACHcFQAA5hUAADMWAACAFgAAzBYAABgXAABJFwAAURcAALUXAAC2FwAAtxcA ALgXAAA8GAAAPRgAAOEYAADiGAAAQhoAAEMaAAByHAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAALMAAAAAAAAAAAAAAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAALEAAAAAAAAA AAAAAACxAAAAAAAAAAAAAAAAsQAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAACxAAAAAAAAAAAAAAAA sQAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAEQQAEMkAUXGgAAAAQCGbEZGAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAA QyQBAAEaAAABAAAAEokXAAC0FwAAOhgAADsYAADcGAAA4BgAADEZAAA2GQAAPBkAADYaAABBGgAA RBsAAEUbAABJGwAAahsAAHMbAAB0GwAAdRsAAI8bAACYGwAAmxsAALobAADWGwAAAxwAADscAAA8 HAAARxwAAEgcAABxHAAAdRwAANMcAADUHAAA1RwAAP0cAAD+HAAA/xwAAPYA7QDkANvSAMkAycC3 wK7ApZyunK6Tg3iDeINteGJ4YoOTAAAAAAAAAAAAAAAAAAAAAAAVAQiBBEgBAAVo3WxGRgdIAABD ShQAFQEIgQRIAQAFaNtsRkYHSAAAQ0oUABUBCIEESAEABWjcbEZGB0gAAENKFAAfAQiBBEgBAAVo 0GxGRgdIAABDShQAV8oHAQEA0WxGRhEBCIEESAEABWjQbEZGB0gAABEBCIEESAEABWhhbEZGB0gA ABEBCIEESAEABWhgbEZGB0gAABEBCIEESAEABWjPbEZGB0gAABEBCIEESAEABWjObEZGB0gAABEB CIEESAEABWhfbEZGB0gAABEBCIEESAEABWhebEZGB0gAABEBCIEESAEABWhdbEZGB0gAABEACIFj SAEAZGhdbEZGZ0gAABEBCIEESAEABWhcbEZGB0gAABEBCIEESAEABWhQbEZGB0gAABEBCIEESAEA BWhMbEZGB0gAAAAjuBcAADwYAAA9GAAA4RgAAOIYAABCGgAAQxoAAHIcAAD+HAAAAR0AAAIdAAAD HQAACR0AABYdAAAXHQAALx4AADAeAADNHgAAzh4AAIMfAACEHwAAOiEAADshAABBIQAAUyEAAFQh AAAbIgAAHCIAAN0iAADeIgAA+SIAAPoiAADDJAAAxCQAAAgmAAAJJgAAHiYAAPv28ezn4t/c19LN ysfEv7q1sKumoZyZlpOOiYR/enVwa2ZhXAgCEAAGYN7//wAIAhAABmHe//8ACAIQAAal3///AAgC EAAGpt///wAIAhAABm/h//8ACAIQAAZw4f//AAgCEAAGi+H//wAIAhAABozh//8ACAIQAAZN4v// AAgCEAAGTuL//wAIAhAABhXj//8ABQYW4///BQYo4///BQYu4///CAIQAAYv4///AAgCEAAG5eT/ /wAIAhAABubk//8ACAIQAAab5f//AAgCEAAGnOX//wAIAhAABjnm//8ACAIQAAY65v//AAgCEAAG Uuf//wAFBlPn//8FBmDn//8FBmbn//8IAhAABmfn//8ACAIQAAZo5///AAgCEAAGa+f//wAFBvfn //8FBibq//8IAhAABifq//8ACAIQAAaH6///AAgCEAAGiOv//wAIAhAABizs//8ACAIQAAYt7P// AAgCEAAGsez//yRyHAAA/hwAAAEdAAACHQAAAx0AAAkdAAAWHQAAFx0AAC8eAAAwHgAAzR4AAM4e AACDHwAAhB8AADohAAA7IQAAQSEAAFMhAABUIQAAGyIAABwiAADdIgAAugAAAAAAAAAAAAAAALgA AAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAC2AAAAAAAA AAAAAAAAtgAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAA ALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAC4AAAA AAAAAAAAAAAAtgAAAAAAAAAAAAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAuAAAAAAAAAAA AAAAALgAAAAAAAAAAAAAAAC4AAAAAAAAAAAAAAAAAAAAAAEAAAABEAAARAAAQyQBRcaAAAABANts RkYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAFf8cAAAAHQAAAR0AAAMdAAAIHQAACR0AABYdAAA7IQAAQCEAAEEhAABTIQAA0ioA ANcqAADYKgAA5ioAAJUtAACaLQAAmy0AAKYtAADeMAAA4zAAAOQwAAD0MAAA7zEAAPgxAAD5MQAA BTIAALw3AADBNwAAwjcAAN83AADiNwAAajgAAG44AABvOAAAcTgAALA4AACyOAAA3DgAAN04AADg OAAA4jgAAAw5AAANOQAAEjkAAPbtAOsA6QDrAOkA6wDpAOsA6QDrAOkA6wDpAOsA6esA6wDrAOsA 5ADrAOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAkDagAAGABVCAEDPioBAzwIgREACIFjSAEAZGjRbEZGZ0gAABEBCIEESAEABWjR bEZGB0gAAAAs3SIAAN4iAAD5IgAA+iIAAMMkAADEJAAACCYAAAkmAAAeJgAAISYAAEMmAABEJgAA 1ScAANYnAABXKAAAWCgAAHooAAB7KAAA0CoAANEqAADSKgAA2CoAAOYqAADnKgAAdSsAAHYrAACq KwAAqysAAIYsAACHLAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAB AAAAARAAAB0eJgAAISYAAEMmAABEJgAA1ScAANYnAABXKAAAWCgAAHooAAB7KAAA0CoAANEqAADS KgAA2CoAAOYqAADnKgAAdSsAAHYrAACqKwAAqysAAIYsAACHLAAAlC0AAJUtAACbLQAApy0AAKgt AACSLwAAky8AACYwAAAnMAAAQjAAAEMwAABiMAAAYzAAAI4wAAD79vHs5+Ld2NPOycTBvru2sayn op2YlZKPjIeCfXhzbmlkXwAAAAAAAAAAAAAACAIRAAYG1P//AAgCEQAGB9T//wAIAhEABibU//8A CAIRAAYn1P//AAgCEQAGQtT//wAIAhAABkPU//8ACAIQAAbW1P//AAgCEAAG19T//wAIAhAABsHW //8ABQbC1v//BQbO1v//BQbU1v//BQbV1v//CAIQAAbi1///AAgCEAAG49f//wAIAhAABr7Y//8A CAIQAAa/2P//AAgCEAAG89j//wAIAhAABvTY//8ACAIQAAaC2f//AAUGg9n//wUGkdn//wUGl9n/ /wgCEAAGmNn//wAIAhAABpnZ//8ACAIQAAbu2///AAgCEAAG79v//wAIAhAABhHc//8ACAIQAAYS 3P//AAgCEAAGk9z//wAIAhAABpTc//8ACAIQAAYl3v//AAgCEAAGJt7//wAIAhAABkje//8ACAIQ AAZL3v//I4csAACULQAAlS0AAJstAACnLQAAqC0AAJIvAACTLwAAJjAAACcwAABCMAAAQzAAAGIw AABjMAAAjjAAAI8wAADcMAAA3TAAAN4wAADkMAAA9DAAAPUwAADuMQAA7zEAAPMxAAD5MQAABTIA AAYyAAB6MgAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAA AAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAA AAAAAAD7AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAETAAABEQAAAQAA AAEQAAAcjjAAAI8wAADcMAAA3TAAAN4wAADkMAAA9DAAAPUwAADuMQAA7zEAAPMxAAD5MQAABTIA AAYyAAB6MgAAezIAAPgyAAD5MgAAijMAAIszAAAXNAAAGDQAALQ0AAC1NAAAVDUAAFU1AAD7NQAA /DUAAIA2AACBNgAAIjcAACM3AAC7NwAAvDcAAMI3AADfNwAA4zcAAPA3AAAIOAAAHTgAAPv28+7r 6OXg3drX1NHMx8K9uLWwraijnpuWk46LhoF8eXZzcG1qZwAAAAAAAAAFBmHM//8FBnnM//8FBobM //8FBorM//8FBqfM//8FBq3M//8FBq7M//8IAhMABkbN//8ACAITAAZHzf//AAgCEwAG6M3//wAF BunN//8IAhMABm3O//8ABQZuzv//CAITAAYUz///AAUGFc///wgCEwAGtM///wAIAhMABrXP//8A CAITAAZR0P//AAUGUtD//wgCEwAG3tD//wAFBt/Q//8IAhMABnDR//8ACAITAAZx0f//AAgCEwAG 7tH//wAIAhMABu/R//8ACAITAAZj0v//AAUGZNL//wUGcNL//wUGdtL//wUGetL//wUGe9L//wgC EAAGdNP//wAFBnXT//8FBoXT//8FBovT//8IAhEABozT//8ABQaN0///CAIQAAba0///AAgCEQAG 29P//yd6MgAAezIAAPgyAAD5MgAAijMAAIszAAAXNAAAGDQAALQ0AAC1NAAAVDUAAFU1AAD7NQAA /DUAAIA2AACBNgAAIjcAACM3AAC7NwAAvDcAAMI3AADfNwAA4zcAAPA3AAAIOAAAHTgAAB44AAAz OAAAUTgAAGU4AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7 AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAA AAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAAAAAAAAAAEAAAAB EwAAHR04AAAeOAAAMzgAAFE4AABlOAAAaTgAAGo4AABuOAAAbzgAAK84AACwOAAA3zgAABA5AAAR OQAAEjkAAPz59vPw7ern5eXi5eXnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BQIVAA0BAgEBAAUG+8v//wUG/8v//wUGAMz//wUGBMz//wUGGMz//wUGNsz//wUGS8z//wUGTMz/ /wAOZTgAAGk4AABqOAAAbjgAAG84AACvOAAAsDgAAN84AADgOAAADzkAABA5AAAROQAAEjkAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADFQAxJAADAAAxJAADFAAxJAAAAQAA AAwpAAkwAAowARQwKhxQAQAfsNAvILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABIAGwAKAAEAWwAPAAIABAAAAAQALAAAQPH/AgAsAAAACABTAHQAYQBuAGQAYQByAGQAAAACAAAA CABDShgAbUgJBAAAAAAAAAAAAAAAAAAAAAAAAEIAQUDy/6EAQgAAABkAQQBiAHMAYQB0AHoALQBT AHQAYQBuAGQAYQByAGQAcwBjAGgAcgBpAGYAdABhAHIAdAAAAAAAAAAAAAAAAAAwAP5PAQDyADAA AAAIAGEAYgBzAHQAcgBhAGMAdAAAAAoADwAOhNACD4TQAgQAQ0oUACgA/k8BAAIBKAAAAAQAYgBv AGQAeQAAAAoAEAAOhGgBD4RoAQQAQ0oUACgA/k8BARIBKAAAAAYAYgB1AGwAbABlAHQAAAAKABEA D4QcAhGETP8AADgA/k8BASIBOAAAAA4AcABhAGMAawBlAHQAIABmAG8AcgBtAGEAdABzAAAAAgAS AAgAT0oFAFFKBQAyAP5PAQAyATIAAAAJAHIAZQBmAGUAcgBlAG4AYwBlAAAACgATAA+EaAERhJj+ BABDShQANgAfQAEAQgE2AAAACQBLAG8AcABmAHoAZQBpAGwAZQAAAA0AFAANxggAAuAQwCEBAgAE AENKFAA0ACBAAQBSATQAAAAIAEYAdQDfAHoAZQBpAGwAZQAAAA0AFQANxggAAuAQwCEBAgAEAENK FABCAP5PAQBiAUIADAAKAFcARwAxADEALQBUAGkAdABsAGUAAAAMABYAAyQBBiQBEYQ3Ag8ANQiB Q0ocAE9KAgBRSgIAAEwA/k8BAHIBTAAMAAwAVABpAHQAcgBlACAAQQB1AHQAaABvAHIAAAANABcA AyQDDcYFAAGmBgAAEwA1CIFDShQAT0oAAFFKAABtSAkIAFYA/k8BAIIBVgAMAAsAYQBuAG4AZQB4 ACAAdABpAHQAbABlAAAAGgAYAAMkAQUkAQYkATEkABSkeAANxgUAATgEABMANQiBQ0ocAE9KAABR SgAAbUgHBABAAFlAAQCSAUAAAAAQAEQAbwBrAHUAbQBlAG4AdABzAHQAcgB1AGsAdAB1AHIAAAAG ABkALUQgAQgAT0oGAFFKBgBAAEJgAQCiAUAAAAAKAFQAZQB4AHQAawD2AHIAcABlAHIAAAACABoA FwBDShQAT0oDAFFKAwBoCABtSAcEbkgHBAAAAAAAEjUAAAsAAGwAAAYA/////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAQQAAAEEAAABxAAAAcQAAAKEAAACkAAAAAAQAADsUAACJFwAA /xwAABI5AAAgAAAAKQAAACsAAAAuAAAAAAQAABIFAADQBwAAbQoAAPIQAADcFQAAchwAAN0iAACH LAAAejIAAGU4AAASOQAAIQAAACMAAAAlAAAAJgAAACgAAAAqAAAALQAAAC8AAAAxAAAAMwAAADUA AAAABAAA0AcAAJwNAAC4FwAAHiYAAI4wAAAdOAAAEjkAACIAAAAkAAAAJwAAACwAAAAwAAAAMgAA ADQAAAD//wIAAAAHAFUAbgBrAG4AbwB3AG4ACwBQAGEAdQBsACAAQwBoAHIAaQBzAHQA//8BAAAA DQBfAEgAbAB0ADQANQA0ADYAMAA3ADUANwA5ABMBAAATNQAAAAAAABMBAAATNQAAAAAAANUGAADe BgAAPwgAAEwIAADVCgAA1woAAEkMAABWDAAAWw8AAGQPAACYDwAAoQ8AAJYQAACaEAAA9RAAAAcR AAAVEQAAIBEAAFsRAABiEQAAZxEAAGoRAADcEQAA4BEAAOERAADkEQAA6REAAOwRAADtEQAA8xEA APQRAAD4EQAA+xEAAP8RAAAAEgAABBIAAAUSAAAHEgAACBIAABESAAASEgAAFhIAABgSAAAbEgAA HxIAACMSAAAkEgAAKRIAACoSAAAsEgAALhIAADESAAA0EgAAOBIAADwSAAA/EgAARBIAAEoSAABM EgAATxIAAFASAABXEgAAWBIAAFoSAABbEgAAXhIAAF8SAABlEgAAZhIAAGsSAABsEgAAcxIAAHcS AAB6EgAAexIAAH8SAACBEgAAhxIAAIgSAACNEgAAkRIAAJkSAACaEgAAnRIAAJ4SAACkEgAApRIA AKkSAACuEgAAsRIAALISAAC2EgAAtxIAAL0SAAC+EgAAwBIAAMESAADFEgAAzRIAANASAADREgAA 1BIAANUSAADcEgAA3RIAAN8SAADgEgAA5xIAAOgSAADqEgAA6xIAAPISAADzEgAA9hIAAPwSAAD/ EgAAABMAAAgTAAAJEwAADxMAABATAAAWEwAAGRMAABwTAAAiEwAAMBMAADQTAAA2EwAANxMAADsT AAA8EwAAQRMAAEITAABHEwAASRMAAE8TAADzEwAA+hMAANcUAADfFAAADxUAABgVAAD3GAAA/BgA AOYaAADtGgAAABsAAAcbAAATIQAAGiEAAPMhAAD6IQAAGCIAAB0iAAAxIgAAQiIAAIMiAACKIgAA aCMAAHAjAACTIwAAlCMAAJ8jAACmIwAAzCMAANMjAADfIwAA5iMAAPsjAAACJAAApyUAAK4lAABG JgAATSYAAHspAACEKQAAlywAAJ0sAACiLAAApiwAAF0tAABjLQAAay0AAHQtAAB2LQAAfS0AAH4t AACELQAADS4AABguAABDLgAATC4AAIIuAACNLgAAAC8AAAsvAACSLwAAmS8AABwwAAAiMAAARDAA AFMwAABZMQAAZDEAAAIyAAAKMgAAhTIAAJAyAAArMwAANDMAAG80AAC1NAAAvzQAAM80AADUNAAA 5TQAAO80AAD/NAAABDUAABA1AAATNQAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAHABwABwAcAAcA HAAHABwABwACAAAAAAA7EAAAWRAAAGEQAABoEAAAuBAAAL4QAADDEAAAxhAAAMoQAADKEAAARREA AEURAABpEQAAaREAAGwRAABtEQAAtREAAFATAABREwAAhhMAALQTAAC0EwAAOxQAADsUAABJFwAA ahcAAHMXAAB0FwAAdhcAAHYXAACYFwAAmxcAALoXAAAAGQAAbjQAAG80AAAQNQAAEzUAAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAHAAcAAgD//xQAAAALAFAAYQB1AGwAIABDAGgAcgBpAHMAdABDAEMAOgBcAFQARQBN AFAAXABBAHUAdABvAFcAaQBlAGQAZQByAGgAZQByAHMAdABlAGwAbABlAG4ALQBTAHAAZQBpAGMA aABlAHIAdQBuAGcAIAB2AG8AbgAgAHcAMwAzADgAMQBfAFIAVQBTAF8AYwBvAG0AbQBlAG4AdABz AC4AYQBzAGQACwBQAGEAdQBsACAAQwBoAHIAaQBzAHQAQwBDADoAXABUAEUATQBQAFwAQQB1AHQA bwBXAGkAZQBkAGUAcgBoAGUAcgBzAHQAZQBsAGwAZQBuAC0AUwBwAGUAaQBjAGgAZQByAHUAbgBn ACAAdgBvAG4AIAB3ADMAMwA4ADEAXwBSAFUAUwBfAGMAbwBtAG0AZQBuAHQAcwAuAGEAcwBkAAsA UABhAHUAbAAgAEMAaAByAGkAcwB0AEMAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8AVwBpAGUAZABl AHIAaABlAHIAcwB0AGUAbABsAGUAbgAtAFMAcABlAGkAYwBoAGUAcgB1AG4AZwAgAHYAbwBuACAA dwAzADMAOAAxAF8AUgBVAFMAXwBjAG8AbQBtAGUAbgB0AHMALgBhAHMAZAALAFAAYQB1AGwAIABD AGgAcgBpAHMAdABDAEMAOgBcAFQARQBNAFAAXABBAHUAdABvAFcAaQBlAGQAZQByAGgAZQByAHMA dABlAGwAbABlAG4ALQBTAHAAZQBpAGMAaABlAHIAdQBuAGcAIAB2AG8AbgAgAHcAMwAzADgAMQBf AFIAVQBTAF8AYwBvAG0AbQBlAG4AdABzAC4AYQBzAGQACwBQAGEAdQBsACAAQwBoAHIAaQBzAHQA QwBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBXAGkAZQBkAGUAcgBoAGUAcgBzAHQAZQBsAGwAZQBu AC0AUwBwAGUAaQBjAGgAZQByAHUAbgBnACAAdgBvAG4AIAB3ADMAMwA4ADEAXwBSAFUAUwBfAGMA bwBtAG0AZQBuAHQAcwAuAGEAcwBkAAsAUABhAHUAbAAgAEMAaAByAGkAcwB0AEMAQwA6AFwAVABF AE0AUABcAEEAdQB0AG8AVwBpAGUAZABlAHIAaABlAHIAcwB0AGUAbABsAGUAbgAtAFMAcABlAGkA YwBoAGUAcgB1AG4AZwAgAHYAbwBuACAAdwAzADMAOAAxAF8AUgBVAFMAXwBjAG8AbQBtAGUAbgB0 AHMALgBhAHMAZAALAFAAYQB1AGwAIABDAGgAcgBpAHMAdABDAEMAOgBcAFQARQBNAFAAXABBAHUA dABvAFcAaQBlAGQAZQByAGgAZQByAHMAdABlAGwAbABlAG4ALQBTAHAAZQBpAGMAaABlAHIAdQBu AGcAIAB2AG8AbgAgAHcAMwAzADgAMQBfAFIAVQBTAF8AYwBvAG0AbQBlAG4AdABzAC4AYQBzAGQA CwBQAGEAdQBsACAAQwBoAHIAaQBzAHQAaQBcAFwASwBTAEEAVAAyADkAXAB3AHIAaQB0AGEAYgBs AGUAXABQAHIAbwBqAGUAawB0AGUAXABTAG8ATgBHAFwARABvAGsAcwBcAFcAbwByAGsAcABhAGMA awBhAGcAZQBzAFwAVwBQADUAXABSAFQAUABfAGQAaQBzAGMAdQBzAHMAaQBvAG4AXAB3ADMAMwA4 ADEAXAB3ADMAMwA4ADEAXwBjAG8AbQBtAGUAbgB0AHMALQBDAGgARwBfAFAAQwBfAFMAbwBOAEcA LgBkAG8AYwALAFAAYQB1AGwAIABDAGgAcgBpAHMAdABpAFwAXABLAFMAQQBUADIAOQBcAHcAcgBp AHQAYQBiAGwAZQBcAFAAcgBvAGoAZQBrAHQAZQBcAFMAbwBOAEcAXABEAG8AawBzAFwAVwBvAHIA awBwAGEAYwBrAGEAZwBlAHMAXABXAFAANQBcAFIAVABQAF8AZABpAHMAYwB1AHMAcwBpAG8AbgBc AHcAMwAzADgAMQBcAHcAMwAzADgAMQBfAGMAbwBtAG0AZQBuAHQAcwAtAEMAaABHAF8AUABDAF8A UwBvAE4ARwAuAGQAbwBjAAsAUABhAHUAbAAgAEMAaAByAGkAcwB0AGkAXABcAEsAUwBBAFQAMgA5 AFwAdwByAGkAdABhAGIAbABlAFwAUAByAG8AagBlAGsAdABlAFwAUwBvAE4ARwBcAEQAbwBrAHMA XABXAG8AcgBrAHAAYQBjAGsAYQBnAGUAcwBcAFcAUAA1AFwAUgBUAFAAXwBkAGkAcwBjAHUAcwBz AGkAbwBuAFwAdwAzADMAOAAxAFwAdwAzADMAOAAxAF8AYwBvAG0AbQBlAG4AdABzAC0AQwBoAEcA XwBQAEMAXwBTAG8ATgBHAC4AZABvAGMAAQDvH095KtKonf8P/w//D/8P/w//D/8P/w//DwEAAgAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+E0AIRhJj+FcYFAAHQAgZPSgAAUUoAAG8oAAEALQAB AAAA7x9PeQAAAAAAAAAAAAAAAP///////wEAAAAAAP9AA4ABAP0YAAD9GAAALB89Aa0ArQD9GAAA AAAAAH4YAAAAAAAAAhAAAAAAAAAAEjUAALAAAAgAQAAABwAAAEcWkAEAAAICBgMFBAUCAwSHAgAA AAAAAAAAAAAAAAAAnwAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAEC AAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAIL BgQCAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAAAABBAHIAaQBhAGwAAAA/NZABAAACBwMJAgIF AgQEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAMxaQAQAA AgIGAwUEBQIDBIcCAAAAAAAAAAAAAAAAAACfAAAAAAAAAFQASQBNAEUAUwAAADcxkAEAAAAAAAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAG8AdQByAGkAZQByAAAANSaQAQAAAgsGBAMF BAQCBId6AAAAAACACAAAAAAAAAD/AAAAAAAAAFQAYQBoAG8AbQBhAAAAIgAEAHGIiBgAANACAABo AQAAAADTbEZG3mxGRgAAAAAEAAAAAACVBwAAPCsAAAEAFgAAAAQAgxBcAAAAAAAAAAAAAAABAAEA AAABAAAAAAAAACQDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAASMAAA EAAZAGQAAAAZAAAAGDUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANkYAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAALABPAFIARwBBAE4ASQBTAEEA VABJAE8ATgAgAEkATgBUAEUAUgBOAEEAVABJAE8ATgBBAEwARQAgAEQARQAgAE4ATwBSAE0AQQBM AEkAUwBBAFQASQBPAE4AAAAAAAAACwBEAGEAdgBlACAAUwBpAG4AZwBlAHIACwBQAGEAdQBsACAA QwBoAHIAaQBzAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAHQBAAAPAAAAAQAAAIAAAAACAAAA iAAAAAMAAADAAAAABAAAAMwAAAAFAAAA4AAAAAcAAADsAAAACAAAAAABAAAJAAAAFAEAABIAAAAg AQAADAAAADwBAAANAAAASAEAAA4AAABUAQAADwAAAFwBAAAQAAAAZAEAABMAAABsAQAAAgAAAOQE AAAeAAAALQAAAE9SR0FOSVNBVElPTiBJTlRFUk5BVElPTkFMRSBERSBOT1JNQUxJU0FUSU9OADgu MB4AAAABAAAAAFJHQR4AAAAMAAAARGF2ZSBTaW5nZXIAHgAAAAEAAAAAYXZlHgAAAAsAAABOb3Jt YWwuZG90AAAeAAAADAAAAFBhdWwgQ2hyaXN0AB4AAAACAAAANAB1bB4AAAATAAAATWljcm9zb2Z0 IFdvcmQgOC4wAEFAAAAAAFq1dlvVvwFAAAAAAFwZAF3VvwEDAAAAAQAAAAMAAACVBwAAAwAAADwr AAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAA AAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuXAEAABgBAAAMAAAA AQAAAGgAAAAPAAAAcAAAAAUAAACAAAAABgAAAIgAAAARAAAAkAAAABcAAACYAAAACwAAAKAAAAAQ AAAAqAAAABMAAACwAAAAFgAAALgAAAANAAAAwAAAAAwAAAD5AAAAAgAAAOQEAAAeAAAABgAAAEFw cGxlAEEAAwAAAFwAAAADAAAAFgAAAAMAAAAYNQAAAwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAA AAAAAAALAAAAAAAAAB4QAAABAAAALQAAAE9SR0FOSVNBVElPTiBJTlRFUk5BVElPTkFMRSBERSBO T1JNQUxJU0FUSU9OAAwQAAACAAAAHgAAAAYAAABUaXRlbAADAAAAAQAAAACYAAAAAwAAAAAAAAAg AAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAA ewBDADcAQQBEADQARgBFADAALQAzADgANgBBAC0AMQAxAEQANAAtAEEANQBCADkALQAwADAAMQAw AEEANAAwADkAQQBGAEQAQwB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAk AAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIA AAAzAAAANAAAADUAAAA2AAAA/v///zgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAA AEEAAABCAAAA/v///0QAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAAD+////TAAAAE0AAABOAAAA TwAAAFAAAABRAAAAUgAAAP7////9////VQAAAP7////+/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAADgN5OE PNW/AcAxNYU81b8BADjGKkDVvwEAAAAAAJgAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAA AAAAwAAAAAAAAEYAAAAAULCS2lfVvwGgANoJXdW/AVcAAACAAAAAAAAAADEAVABhAGIAbABlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwAAAA4XAAAAAAAA VwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAK2wAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEMAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQBy AHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////MQBfAH4A MQAuAEQATwBDAAAAAAAAAAAAACgBAAAAAADwNxYASwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBq AAAAkwAAAGVzCPAeAOhHHQBcc2Jhc2Vkb24xXHNhMTAwXHNiMTAwXGxpMzYwXHJpMxIAAgEBAAAA BgAAAP////9cKlxjczEzXGkxXGFkZGl0aXZlIAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAGRkaXRP AGIAagBlAGMAdABQAG8AbwBsAAAAdWxub25lXGFkZGl0aXZlIEVtcGhhc2lzO317XCpcY3MxNlxj ZjFcdWxcFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAoADaCV3VvwGgANoJXdW/ AWVkSHlwZXJsaW5rO317XCpcY3MxOFxmM1xiMVxmczIwXGFkZGl0aXZlIEtleWJvYXJkO317XHMx OVxzYmFzZWRvbjFcZjNcc2EwXHMAAAAA////////////////OVx0eDE5MThcdHgyODc3XHR4Mzgz Nlx0eDQ3OTVcdHg1NzU0XHR4NjcxM1x0eDc2AQAAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGGAAA AE1pY3Jvc29mdCBXb3JkLURva3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQu OAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_0055_01BFD570.DFDB06F0-- From rem-conf Tue Jun 13 12:52:39 2000 From rem-conf-request@es.net Tue Jun 13 12:52:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 131wfy-0004uD-00; Tue, 13 Jun 2000 12:48:42 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 131wfw-0004u3-00; Tue, 13 Jun 2000 12:48:41 -0700 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id MAA12071 for ; Tue, 13 Jun 2000 12:48:39 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 13 Jun 2000 12:48:28 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id MAA25191; Tue, 13 Jun 2000 12:48:28 -0700 (PDT) MIME-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> Date: Tue, 13 Jun 2000 12:48:22 -0700 To: Paul Christ From: Dave Singer Subject: RE: MPEG-4 (including Flexmux), over RTP/RTSP Cc: 4on2andIP-sys@advent.ee.columbia.edu, "'Colin Perkins'" , CURET Dominique FTRD/DMI/REN , peterw@us.ibm.com, rem-conf@es.net, Yan Xiang Chen , Stefan Wesner Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 19:52 +0200 6/13/00, Paul Christ wrote: >Dear Dave, dear all, > >please find attached our first comment to your/Dave's mail - now evolved >into >ISO/IEC JTC1/SC29/WG11 N3381. Thanks for your comments. I appreciate them. We really need to get this area nailed down... > >We welcome such a paper and will try to help further to improve it. >If you don't mind: We should avoid "memoryless" discussions :-) >AS agreed in the IETF > > C.Guillemot et al., > "RTP Payload Format for MPEG-4 with Flexible Error Resiliency", > IETF Draft, draft-ietf-avt-mpeg4streams-00, > March 1 2000, expires Sept 1 2000 > > R. Civanlar et al., > " RTP Payload Format for MPEG-4 Streams", > IETF Draft, draft-ietf-avt-rtp-mpeg4-02, ? > ? 2000, expires ?? 20000 > >are to become experimental RFCs - for technical reasons. >which state should not simply be overwritten >by declarative statements. Right. The purpose of my draft was mostly to focus on the areas on which there was probably agreement, but no actual specification, and to admit that we were likely to have a plurality of RTP packings going ahead. I certainly have no desire to discard existing work in the area; rather to build on it and flesh out all the other areas. It seems, from reading your comments, that your disagreements are only in the area of packing formats. 1) You don't want to require support for the simple packing done by Carsten et al., whereas I feel that it would be good if there is one, simple, general packing that everyone implements and that can carry any MPEG-4 stream, perhaps in a non-optimal fashion. I think it would be disappointing if there was no such spec., and Carsten's draft seems like the best contender. Do you disagree with the principle (that there should be a simple interoperable draft), or the specification itself? 2) My recommendation that we look at existing techniques in the IETF for reliability -- FEC, re-transmission. I didn't mention redundant audio, though as you say that is another existing technique which is orthogonal to the encoding schemes used. I only phrased this as a recommendation, and I guess it could be weakened from there. I certainly have no quibble in principle with combined source/channel coding, which is, I think, the essence of your draft. My draft was explicitly written to get us out of the deadlock of trying to decide, now, a single packing scheme, and permit (maybe even encourage) research, development, interoperation, and promotion of schemes. It's clear from the multiplicity of drafts that we are not yet in consensus. >All the best > >P. Christ > >p.s.: Discussed in the context of Project SoNG > with Christine Guillemot > My regards to all of you, and thanks for the good insights and work you are doing. -- David Singer Apple Computer/QuickTime From rem-conf Wed Jun 14 02:28:30 2000 From rem-conf-request@es.net Wed Jun 14 02:28:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1329J5-0003rA-00; Wed, 14 Jun 2000 02:17:55 -0700 Received: from out5.prserv.net (prserv.net) [32.97.166.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 1329J4-0003r0-00; Wed, 14 Jun 2000 02:17:54 -0700 Received: from rpcaragonite ([139.92.151.53]) by prserv.net (out5) with SMTP id <2000061409170824302p6omde>; Wed, 14 Jun 2000 09:17:12 +0000 Message-ID: <094601bfd5e1$6e2d8ca0$dd975c8b@rennes.cnet.fr> Reply-To: "Olivier Avaro" From: "Olivier Avaro" To: "Paul Christ" , "Dave Singer" Cc: <4on2andIP-sys@advent.ee.columbia.edu>, "'Colin Perkins'" , "CURET Dominique FTRD/DMI" , , , "Yan Xiang Chen" , "Stefan Wesner" References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP Date: Wed, 14 Jun 2000 10:38:40 +0200 Organization: France Telecom - CNET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, I would second Dave on the following aspect : let's get the framework first, we have many matters of consensus there, let's have all the brains on this reflector geting it right. cu, O. From rem-conf Wed Jun 14 03:35:37 2000 From rem-conf-request@es.net Wed Jun 14 03:35:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132ATF-00057E-00; Wed, 14 Jun 2000 03:32:29 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 132ATB-000570-00; Wed, 14 Jun 2000 03:32:26 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id TAA12632; Wed, 14 Jun 2000 19:29:57 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id TAA00740; Wed, 14 Jun 2000 19:29:56 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id TAA21907; Wed, 14 Jun 2000 19:29:55 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id TAA72342; Wed, 14 Jun 2000 19:29:55 +0900 (JST) Message-ID: <05f701bfd5eb$70f1f840$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Olivier Avaro" , "Paul Christ" , "Dave Singer" Cc: <4on2andIP-sys@advent.ee.columbia.edu>, "'Colin Perkins'" , "CURET Dominique FTRD/DMI" , , , "Yan Xiang Chen" , "Stefan Wesner" , "Yoshihiro Kikuchi" References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> <094601bfd5e1$6e2d8ca0$dd975c8b@rennes.cnet.fr> Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP Date: Wed, 14 Jun 2000 19:29:37 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_05F4_01BFD636.E06BC340" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_05F4_01BFD636.E06BC340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Dave, Olivier, all, I'm resending the attached mail which may be related to this discussion because I haven't see this mail through the reflector. I agree with the basic concept of Dave's proposal if it tries to propose a framework covering all MPEG-4 RTP formats. Actually, I misunderstood that it might be proposing like (c) in the attached mail. But, we need to be care that we should never have a solution like (a). By this meaning, I think that N3381 needs further revisions. The selection of RTP payload proposals and MUST/SHOULD/MAY wording should be decided with much care. If it is acceptable, I would like to make a contribution from one side of the MPEG-4 RTP world. Best regards, Yoshihiro ----- Original Message ----- From: Olivier Avaro To: Paul Christ ; Dave Singer Cc: <4on2andIP-sys@advent.ee.columbia.edu>; 'Colin Perkins' ; CURET Dominique FTRD/DMI ; ; ; Yan Xiang Chen ; Stefan Wesner Sent: Wednesday, June 14, 2000 5:38 PM Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP > Hi all, > > I would second Dave on the following aspect : let's get the framework first, > we have many matters of consensus there, let's have all the brains on this > reflector geting it right. > > cu, > > O. > > ------=_NextPart_000_05F4_01BFD636.E06BC340 Content-Type: message/rfc822; name="Resolution 3.2.3 and N3381.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Resolution 3.2.3 and N3381.eml" Return-Path: kiku@eel.rdc.toshiba.co.jp Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id KAA04613; Mon, 12 Jun 2000 10:45:44 +0900 (JST) Message-ID: <013501bfd40f$e1d517a0$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "'Dave Singer'" Cc: "Yoshihiro Kikuchi" , "Herpel Carsten" , "Colin Perkins" , <4on2anIPsys@advent.ee.columbia.edu> Subject: Resolution 3.2.3 and N3381 Date: Mon, 12 Jun 2000 10:45:26 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-UIDL: 3c4974167611871f3a68c8363a8b55d6 Dear Dave and MPEG-4 on IP experts, I read through the output documents from the MPEG Geneva meeting and found some document and descriptions that seem to be related to MPEG-4 on IP. These are 'resolution 3.2.3' and 'N3381'. Because I could not attend the Geneva meeting, I would like to ask some questions to know what do these mean. As stated in N3381, there are some (not one) RTP payload formats for the carriage of MPEG-4 streams. Among them, two payload formats, draft-ietf-avt-rtp-mpeg4-02[8] and draft-ietf-avt-rtp-mpeg4-es-01[6] are both proposed firstly in the MPEG committee, sent to the IETF as liaison statements, and demonstrated in the MPEG meetings. What I would like to ask is which one of the followings is the correct purpose of the framework proposed in N3381. (a) It forces to use only one RTP payload format (draft-ietf-avt-rtp-mpeg4-02[8]), or plus one (draft-rgcc-avt-mpeg4flexmux-00[5]), in all cases when the proposed framework is used. (b) It proposes a framework to treat all MPEG-4 RTP payload formats. It leaves the selection of RTP payload format depending on the media types (e.g. MPEG-4 Audio/Visual), applications, network environments, users needs, etc, while keeping a framework commonly to all RTP payload formats. We can use MPEG-4 Audio/Visual media aware packetization scheme, e.g. draft-ietf-avt-rtp-mpeg4-es-01[6], if it satisfies the conditions [2.1] to [2.6] in section 2 of N3381. (c) It tries to propose new payload formats other than the existing ones. If the answer is: (a) It is really disappointing. I cannot understand why only RTP payload formats where some Systems groups members are favor on are proposed as an MPEG common framework. I must disagree such framework be proposed as "on behalf of ISO/IEC JTC1/SC29/WG11(MPEG)". (b) It is interesting. This may enable MPEG-4 Audio/Visual aware packetization scheme stored in the MP4 file format. This may also enable the combination of OD/BIFS streams and Audio/Visual streams transferred over the RTP payload formats suited for each audio/visual media type. (c) Although anyone is free to propose any new payload formats, it needs *very* good reasons to adopt them considering that there have been several (not one) MPEG-4 RTP payload formats proposed. I may be missing something because I was not at the Geneva meeting. I want to know what was discussed in Geneva. Would you please give us a clarify for the correct understanding of the proposal? Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 ------=_NextPart_000_05F4_01BFD636.E06BC340-- From rem-conf Wed Jun 14 06:25:23 2000 From rem-conf-request@es.net Wed Jun 14 06:25:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132D3L-0007H5-00; Wed, 14 Jun 2000 06:17:55 -0700 Received: from out5.prserv.net (prserv.net) [32.97.166.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 132D3J-0007Gj-00; Wed, 14 Jun 2000 06:17:53 -0700 Received: from rpcaragonite ([139.92.151.98]) by prserv.net (out5) with SMTP id <2000061413170824300vro9pe>; Wed, 14 Jun 2000 13:17:11 +0000 Message-ID: <0aa101bfd602$e9aef820$dd975c8b@rennes.cnet.fr> Reply-To: "Olivier Avaro" From: "Olivier Avaro" To: "Yoshihiro Kikuchi" , "Paul Christ" , "Dave Singer" Cc: <4on2andIP-sys@advent.ee.columbia.edu>, "'Colin Perkins'" , "CURET Dominique FTRD/DMI" , , , "Yan Xiang Chen" , "Stefan Wesner" , "Yoshihiro Kikuchi" References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> <094601bfd5e1$6e2d8ca0$dd975c8b@rennes.cnet.fr> <05f701bfd5eb$70f1f840$4f51c485@eel.rdc.toshiba.co.jp> Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP Date: Wed, 14 Jun 2000 15:16:12 +0200 Organization: France Telecom - CNET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Yoshihiro, all, Indeed, your previous mail did not reach the reflector. The goal of the proposed framework is to achieve end-to-end interoperability when transporting and operating MPEG-4 content over IP-based protocols. This includes the packing of MPEG-4 data, but also session set up and control mechanism, mime types, ... This document is not going to develop new specifications (like new packing), unless needed, but will rather refer to existing ones and improve them, if needed as well. Such framework is expected by the industry for a while, and so far, we have not been able to deliver something consistent and covering all the aspects of the delivery and operation of MPEG-4 content on IP. There are several reasons for this, at least : 1- The complexity of the process. Such framework implies the participation of several communities with different process (not only MPEG and IETF/AVT, but also other IETF groups like MMUSIC); 2- The complexity and multiple usage of the MPEG-4 standard. Different industries have different needs and have so far focused to provide solutions for their own business. Some industry in MPEG felt the need of an integrated framework providing end-to-end interoperability, therefore this initiative. It comes originally >from MPEG since this is were most of the customers are so far. But of course it respects the process of the IETF groups since this is where the standardization should occur, and encourages collaboration, as it already happened in the past. Still, interoperability is about making choices, and this framework is not supposed to be a catalog of options. The framework will point to well identified IETF spec. and will have normative statements. Concerning its status : 1- From an MPEG point of view : this is a regular output document. It's construction has been based on a consensus basis and a well defined timeline has been proposed to finalise it. If divergences of opinions appear, they should be solved by core experiment process in due time. This has not happened so far. 2- From the IETF point of view : this is a regular internet draft that is proposed by one or more specific company who can also mention the status of this document in MPEG. I am not sure though to which group this draft belongs to. Any idea ? It will follow the regular process in IETF. There may be competing documents, but only one will have the MPEG stamp. Kind regards, Olivier From rem-conf Wed Jun 14 08:13:18 2000 From rem-conf-request@es.net Wed Jun 14 08:13:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132End-0001BC-00; Wed, 14 Jun 2000 08:09:49 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 132Enc-0001Aq-00; Wed, 14 Jun 2000 08:09:48 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA12355 for ; Wed, 14 Jun 2000 11:09:47 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3947A03B.925554C1@cs.columbia.edu> Date: Wed, 14 Jun 2000 11:09:47 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: rec.video.desktop CC: rem-conf@es.net Subject: Firewire/1394 for live streaming Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is it possible to use a Firewire/1394 card as a Video-for-Windows device, so that a DV camcorder can directly stream into NetShow, NetMeeting, vic, etc.? Any mechanism to directly convert this to streaming MPEG2? Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Jun 14 09:40:08 2000 From rem-conf-request@es.net Wed Jun 14 09:40:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132G8a-0002wQ-00; Wed, 14 Jun 2000 09:35:32 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 132G8X-0002wG-00; Wed, 14 Jun 2000 09:35:30 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id JAA18558 for ; Wed, 14 Jun 2000 09:35:27 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 14 Jun 2000 09:35:27 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id JAA13590; Wed, 14 Jun 2000 09:35:26 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <05f701bfd5eb$70f1f840$4f51c485@eel.rdc.toshiba.co.jp> References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> <094601bfd5e1$6e2d8ca0$dd975c8b@rennes.cnet.fr> <05f701bfd5eb$70f1f840$4f51c485@eel.rdc.toshiba.co.jp> Date: Wed, 14 Jun 2000 09:35:17 -0700 To: 4on2andIP-sys@advent.ee.columbia.edu From: Dave Singer Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP Cc: rem-conf@es.net, Yoshihiro Kikuchi Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list My intention was your (b). Enable to the support of multiple RTP payloads for MPEG-4 data; require the support of one (so as to have a chance at interoperability). Make sure all schemes share some common characteristics, and share other behavior with respect to IP-based protocols (SDP, RTSP in particular). I didn't actually propose any new payload formats, merely observed that there was probably good reason to make some. (By the way, I have reduced the recipient list here to just the relevant email groups, with a cc to the person I am replying to, to be sure it gets to him, as I assume that everyone is one or both lists.) At 19:29 +0900 6/14/00, Yoshihiro Kikuchi wrote: >Dear Dave, Olivier, all, > >I'm resending the attached mail which may be related to this discussion >because I haven't see this mail through the reflector. > >I agree with the basic concept of Dave's proposal if it tries to propose a >framework covering all MPEG-4 RTP formats. Actually, I misunderstood that it >might be proposing like (c) in the attached mail. But, we need to be care >that we should never have a solution like (a). By this meaning, I think that >N3381 needs further revisions. The selection of RTP payload proposals and >MUST/SHOULD/MAY wording should be decided with much care. > >If it is acceptable, I would like to make a contribution from one side of >the MPEG-4 RTP world. > >Best regards, >Yoshihiro > >What I would like to ask is which one of the followings is the correct >purpose of the framework proposed in N3381. > >(a) It forces to use only one RTP payload format >(draft-ietf-avt-rtp-mpeg4-02[8]), or plus one >(draft-rgcc-avt-mpeg4flexmux-00[5]), in all cases when the proposed >framework is used. > >(b) It proposes a framework to treat all MPEG-4 RTP payload formats. It >leaves the selection of RTP payload format depending on the media types >(e.g. MPEG-4 Audio/Visual), applications, network environments, users needs, >etc, while keeping a framework commonly to all RTP payload formats. We can >use MPEG-4 Audio/Visual media aware packetization scheme, e.g. >draft-ietf-avt-rtp-mpeg4-es-01[6], if it satisfies the conditions [2.1] to >[2.6] in section 2 of N3381. > >(c) It tries to propose new payload formats other than the existing ones. > -- David Singer Apple Computer/QuickTime From rem-conf Wed Jun 14 10:08:27 2000 From rem-conf-request@es.net Wed Jun 14 10:08:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132GbM-0003uG-00; Wed, 14 Jun 2000 10:05:16 -0700 Received: from (zrtps06s.us.nortel.com) [47.140.48.50] by mail1.es.net with esmtp (Exim 1.81 #2) id 132GbK-0003tr-00; Wed, 14 Jun 2000 10:05:14 -0700 Received: from ertpg15e1.nortelnetworks.com (actually zrtph06n.us.nortel.com) by zrtps06s.us.nortel.com; Wed, 14 Jun 2000 13:01:45 -0400 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg15e1.nortelnetworks.com; Wed, 14 Jun 2000 13:01:28 -0400 Received: from zrtpd00x.us.nortel.com ([47.140.224.108]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id MPQCZF69; Wed, 14 Jun 2000 13:01:27 -0400 Received: from americasm01.nt.com (prtpd1gd.us.nortel.com [47.202.36.60]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LLW4M29W; Wed, 14 Jun 2000 13:01:25 -0400 Message-ID: <3947B994.ABAC1709@americasm01.nt.com> Date: Wed, 14 Jun 2000 12:57:56 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Chris Fulmer" Organization: Nortel Networks X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: rem-conf@es.net Subject: Re: Firewire/1394 for live streaming References: <3947A03B.925554C1@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Pinnacle systems (pinnaclesys.com) has some solutions for that. Don't have a bunch of details. somebody at wwug.com may be able to point you in the right direction. -- C Henning Schulzrinne wrote: > Is it possible to use a Firewire/1394 card as a Video-for-Windows > device, so that a DV camcorder can directly stream into NetShow, > NetMeeting, vic, etc.? Any mechanism to directly convert this to > streaming MPEG2? > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Jun 14 10:08:29 2000 From rem-conf-request@es.net Wed Jun 14 10:08:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132Gbf-0003ul-00; Wed, 14 Jun 2000 10:05:35 -0700 Received: from mailout2.hananet.net [210.220.163.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 132Gbd-0003uJ-00; Wed, 14 Jun 2000 10:05:33 -0700 Received: from thrunet.thrunet.com ([211.117.12.76]) by mailout2.hananet.net (Netscape Messaging Server 4.15) with SMTP id FW5LXX03.J1L for ; Thu, 15 Jun 2000 02:01:09 +0900 From: ŔĚÇöżě To: rem-conf@es.net Cc: Subject: żµľî,ŔĎľî »ýȰȸȭ ą«·á mailing service ľČł»!! Date: Thu, 15 Jun 00 02:04:14 ŸŔĚşŁŔĚ ÇĄÁؽà MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=AD_2000_PART_BOUNDARY_19990606 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --AD_2000_PART_BOUNDARY_19990606 Content-Type: text/plain Content-Transfer-Encoding: 7Bit ˘Î ¸ĹŔĎ ąŢľĆş¸˝Ç żµľî,ŔĎľî »ýȰȸȭ żąą®.˘ş˘ş ą«·á Ľ­şń˝ş ¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬¦¬ A school teacher was taking a shower in her apartment when the earthquake hit. Terrified, she rushed out into the hall and went down the stairs pausing not even for bathrobe. One of the calmer tenants stopped her and hinted, "Haven't you forgotten something?" She looked at him for a moment, then dashed back towards her room. "Good God, my purse!" * terrified : °Ěżˇ Áú·ÁĽ­ * pause : Ŕá˝Ă ¸ŘĂß´Ů, ¸Óąµ°Ĺ¸®´Ů. * Good God! : ľß´Üłµł×! * purse : (ąĚ±ą) ÇÚµĺąé ż©Ľ±»ýŔĚ ľĆĆÄĆ®żˇĽ­ »ţżö¸¦ ÇĎ°í ŔִµĄ ÁöÁřŔĚ ŔĎľîłµ´Ů. ČĄşńąé»ęÇŃ Ľ±»ýŔş ąĚĂł °ˇżîŔ» °Éġ´Â °ÍÁ¶Â÷ ŔŘŔş ä şąµµ·Î ¶ŮĂÄłŞżÍ °č´ÜŔ» ł»·Á°¬´Ů. ±×¶§ °°Ŕş ľĆĆÄĆ®żˇ »ě°íŔÖ´Â Á» ħÂřÇŃ »ç¶÷ŔĚ Ľ±»ýŔ» Á¦ÁöÇĎ ¸éĽ­ łÍÁö˝Ă ÇѸ¶µđÇß´Ů. "ąş°ˇ¸¦ ŔŘŔ¸ĽĚłŞ şÁżä?" ż©Ľ±»ýŔş ±× ł˛ŔÚ¸¦ Ŕá˝Ă ąŮ¶óş¸´ő´Ď ˝đ»ě°°ŔĚ ąćŔ¸·Î µÇµąľĆ °ˇ¸ç ĽŇ¸®ĂĆ´Ů. "ľĆÂ÷, ł» ÇÚµĺąé!" ˘Ä żŔ´ĂŔÇ żµľî ÇѸ¶µđ ˘Ĺ ˘Â There's a call for you. A : Mr. Jinwoo, there's a call for you. B : Who's on the line? A : Mr.Lee from Online Korea Co. B : All right. Put him through. ˘Á ŔüČ­¸¦ ąŮ˛ăÁŮ ¶§ 'ŔüČ­ żÔľîżä' ¶ó´Â ÇĄÇöŔş There's a call for you. ¶ó°í ÇŇ Ľö ŔÖľîżä. Ŕ̶§ '´©±¸ÇŃĹ׼­ żÔľîżä?' ÇĎ°í ąŻ´Â ÇĄÇöŔş Who is it? ¶Ç´Â Who's on the line? µîŔ¸·Î ¸»ÇŇ Ľö ŔÖ´ä´Ď´Ů. ˘Â ŔüČ­ żÔ˝Ŕ´Ď´Ů. A : Ářżěľľ, ŔüČ­ żÔ˝Ŕ´Ď´Ů. B : ´©±¸˝Ĺ°ˇżä? A : żÂ¶óŔÎÄÚ¸®ľĆŔÇ Mr.¸®ŔÔ´Ď´Ů. B : ÁÁľĆżä. ż¬°á˝ĂÄŃ ÁÖĽĽżä. ˘Ď ŔÚÁÖ »çżëµÇ´Â ÇĄÇö ¨ç You have a phone call on line three. ¨č You are wanted on the phone. ¨é Will you answer the phone? ¨ę Who wants to speak with me? ¨ç 3ąřŔ¸·Î ŔüČ­ żÔ˝Ŕ´Ď´Ů. ¨č ŔüČ­ żÔ˝Ŕ´Ď´Ů. ¨é ŔüČ­ ąŢľĆ ş¸˝Ă°Úľîżä? ¨ę ´©±¸ÇŃĹ׼­ żÔłŞżä? ˘Ä żŔ´ĂŔÇ ŔĎľî ÇѸ¶µđ ˘Ĺ ˇŘŔĎľîµµ żµľîżÍ °°Ŕş ÇüĹ·Π±¸Ľş µÇľî ŔÖ˝Ŕ´Ď´Ů. ------------------------------------------------------------------------------------------ ===================================================== ľČłçÇĎĽĽżä? ŔúČń´Â ŔüČ­¸¦ ŔĚżëÇŘĽ­ °­»çżÍ 1:1·Î żÜ±ąľî ÇĐ˝ŔŔ» ÇŇ Ľö ŔÖ´Â ˘Ä Online Korea[ http://www.d-day.co.kr ] ˘Ĺ¶ó°í ÇŐ´Ď´Ů. Çă¶ô ľřŔĚ ĆíÁö µĺ·Á ÁËĽŰÇŐ´Ď´Ů. ľŐŔ¸·Î´Â Çă¶ô ľř´Â ĆíÁö´Â µĺ¸®Áö ľĘ°Ú˝Ŕ´Ď´Ů. ÇĎżŔ´Ď, şÎµđ łĘ±×·Żżî żëĽ­¸¦...... ŔúČń ȸ»çżˇĽ­´Â »ýČ° ȸȭżˇ °ü˝É ŔÖ´Â ł×ĆĽÁđ ż©·ŻşĐżˇ°Ô ¸ĹŔĎ(żů-±Ý), ˝Ç »ýČ°żˇ ÇĘżäÇŃ »ýȰȸȭ ÇŃ ą®ŔĺľżŔ» ą«·á·Î ş¸ł» µĺ¸®°í ŔÖľîżä. Ľ­şń˝ş ł»żëŔş Ŕ§żÍ °°ŔĚ ±¸Ľş µÇżŔ´Ď ąŢľĆş¸±ć żřÇϽô şĐŔş ˇě olk@olk.co.kr ˇí·Î "yes"¶ó´Â mailŔ» ÁÖ˝Ă¸é µČ´ä´Ď´Ů. ±×¸®°í, ŔúČń ŔüČ­ żÜ±ąľî °­ŔÇ°ˇ ±Ă±ÝÇϽŠşĐµéŔ» Ŕ§ÇŘ ˘Â˝Ăąü°­ŔǢ¸¦ 1ȸżˇ ÇŃÇŘĽ­ ą«·á·Î ˝Ç˝ĂÇĎ°í ŔÖŔ¸´Ď ¸ąŔĚ ˝ĹĂ»ÇŘ ÁÖĽĽżä. ą«·á ˝Ăąü°­ŔÇ ˝ĹĂ» ąćąýŔş ˘ş www.d-day.co.kr ˘¸ żˇ Á˘ĽÓÇϽŠČÄ "°­ŔÇĽŇ°ł"¶őŔ» Ŭ¸ŻÇϽŴŮŔ˝ "°­ŔÇ˝ĹĂ»"¶őŔ» ş¸˝Ă¸é ˝Ăąü°­ŔǸ¦ ˝ĹĂ»ÇĎ˝Ç Ľö ŔÖľîżä. ŔüČ­ 02-588-0510 Ŕ¸·Îµµ ˝ĹĂ»ÇŇ Ľö ŔÖ´ä´Ď´Ů. ľĆą«ÂÉ·Ď ŔĚ ÇĐ˝Ŕ ąýŔ¸·Î ȸȭ ˝Ç·Â Çâ»óżˇ ŔŰŔş ş¸ĹĆŔĚ µÇľúŔ¸¸é ÇŐ´Ď´Ů. °¨»çÇŐ´Ď´Ů. şŇÇĘżäÇŃ Á¤ş¸ż´´Ů¸é ´ë´ÜČ÷ ÁËĽŰÇŐ´Ď´Ů. --AD_2000_PART_BOUNDARY_19990606-- From rem-conf Wed Jun 14 13:16:18 2000 From rem-conf-request@es.net Wed Jun 14 13:16:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132JPh-0007Kg-00; Wed, 14 Jun 2000 13:05:25 -0700 Received: from athm-216-216-xxx-85.home.net (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 132JPg-0007KO-00; Wed, 14 Jun 2000 13:05:24 -0700 Received: by HAPPY with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 13:07:28 -0700 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B1015971@HAPPY> From: Bill Nowicki To: 'Henning Schulzrinne' Cc: rem-conf@es.net Subject: RE: Firewire/1394 for live streaming Date: Wed, 14 Jun 2000 13:07:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Alas, the $50 FireWire PCI cards (or motherboard interfaces on Sony PCs etc.) do not have a decoder for the DV, so you get the DV encoded stream. The Windows 98 and 2000 support is a Windows Driver Model driver, not Video for Windows. So DirectShow applications can work (like most DV editing tools), but Windows Media Encoder does NOT. My DV over RTP implementations use DirectShow and the Windows driver for simple cards. A few more expensive cards have DV decoder chips on them. They generally have private drivers that work only with the applications from the vendor who sells them, mostly editing tools. We are trying to get an Osprey-500DV which might be able to be used in this way. We (and others) make boxes that can decode DV and encode MPEG-2, which you could just connect back to back, but are "Professional Quality" (i.e. expensive!). Bill Nowicki, Omneon Video From rem-conf Wed Jun 14 13:23:24 2000 From rem-conf-request@es.net Wed Jun 14 13:23:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132Jbv-0007Xj-00; Wed, 14 Jun 2000 13:18:03 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 132Jbu-0007XX-00; Wed, 14 Jun 2000 13:18:02 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA04523; Wed, 14 Jun 2000 16:18:00 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3947E878.E0B38CC9@cs.columbia.edu> Date: Wed, 14 Jun 2000 16:18:00 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bill Nowicki CC: rem-conf@es.net Subject: Re: Firewire/1394 for live streaming References: <03AB3CB11CBED3118A4F009027B0C2B1015971@HAPPY> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill Nowicki wrote: > > Alas, the $50 FireWire PCI cards (or motherboard interfaces on Sony PCs > etc.) do not have a decoder for the DV, so you get the DV encoded stream. > The Windows 98 and 2000 support is a Windows Driver Model driver, not Video > for Windows. So DirectShow applications can work (like most DV editing > tools), but Windows Media Encoder does NOT. My DV over RTP implementations > use DirectShow and the Windows driver for simple cards. Is this an application that is available free/otherwise (and thus should be added to the RTP implementation list)? > > A few more expensive cards have DV decoder chips on them. They generally > have private drivers that work only with the applications from the vendor > who sells them, mostly editing tools. We are trying to get an Osprey-500DV > which might be able to be used in this way. We (and others) make boxes that > can decode DV and encode MPEG-2, which you could just connect back to back, > but are "Professional Quality" (i.e. expensive!). Given that DV is apparently DCT-coded, would it be possible to generate MPEG-1 I frames without hardware support or is the DV format (besides the packing into 80? byte units) so different that one has to go back to "raw bits"? > > Bill Nowicki, Omneon Video -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Jun 14 14:20:40 2000 From rem-conf-request@es.net Wed Jun 14 14:20:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132KWt-0001jg-00; Wed, 14 Jun 2000 14:16:55 -0700 Received: from athm-216-216-xxx-85.home.net (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 132KWt-0001gp-00; Wed, 14 Jun 2000 14:16:55 -0700 Received: by HAPPY with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 14:18:59 -0700 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B1015972@HAPPY> From: Bill Nowicki To: 'Henning Schulzrinne' Cc: rem-conf@es.net Subject: RE: Firewire/1394 for live streaming Date: Wed, 14 Jun 2000 14:18:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Our DV RTP was a technology demonstration at NAB 2000. No announced release. You will have to ask a video expert about trans-coding in the Cosine domain without decoding fully to pixels. My guess is that you could do it, but not sure what it would buy? You still would get about 25 Mbits/second. Or I suppose you could do the re-quantize trick, but that would probably introduce ugly artifacts. You might be able to do something like temporal thinning or vic-like avoiding sending macroblocks that have not changed from the previous frame. From rem-conf Wed Jun 14 14:45:30 2000 From rem-conf-request@es.net Wed Jun 14 14:45:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132KtL-0002fO-00; Wed, 14 Jun 2000 14:40:07 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 132KtJ-0002fE-00; Wed, 14 Jun 2000 14:40:05 -0700 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA10597; Wed, 14 Jun 2000 17:40:03 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3947FBB3.5BA77E9E@cs.columbia.edu> Date: Wed, 14 Jun 2000 17:40:03 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net, mbone@isi.edu Subject: Osprey 150 on Solaris (solution) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list For the archives (assuming that anybody still uses Solaris for video conferencing...): With help from Viewcast and some local fiddling, we got the Osprey 150 to work on Solaris. A compiled version of vic can be found at ftp://ftp.cs.columbia.edu/pub/schulzrinne/ The RTP page for vic (http://www.cs.columbia.edu/~hgs/rtp/vic.html) contains some things to check if the program can't find the capture device. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Wed Jun 14 14:47:02 2000 From rem-conf-request@es.net Wed Jun 14 14:47:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132Kva-0002gC-00; Wed, 14 Jun 2000 14:42:26 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (lazzaro) by mail1.es.net with esmtp (Exim 1.81 #2) id 132KvZ-0002g2-00; Wed, 14 Jun 2000 14:42:25 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id OAA07962; Wed, 14 Jun 2000 14:42:24 -0700 Date: Wed, 14 Jun 2000 14:42:24 -0700 From: John Lazzaro Message-Id: <200006142142.OAA07962@snap.CS.Berkeley.EDU> To: BNowicki@Omneon.com Subject: RE: Firewire/1394 for live streaming Cc: rem-conf@es.net, schulzrinne@cs.columbia.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > You will have to ask a video expert about trans-coding in the Cosine domain > without decoding fully to pixels. I'm not at all a video expert, but we did an app a few years ago that used neural nets to transcode JPEG quantized DCT's to restore image quality, and it worked relatively well -- training up nets to do DV to MPEG-1 on the DCT's to minimize artifacts might actually be doable, but I really doubt you want to go down this path ... See: http://www.cs.berkeley.edu/~lazzaro/jqt/index.html for details of the JPEG work. --jl ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Wed Jun 14 16:08:32 2000 From rem-conf-request@es.net Wed Jun 14 16:08:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132MCY-00056H-00; Wed, 14 Jun 2000 16:04:02 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 132MCW-000566-00; Wed, 14 Jun 2000 16:04:00 -0700 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id QAA03380 for ; Wed, 14 Jun 2000 16:03:59 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 14 Jun 2000 16:03:52 -0700 Received: from [17.202.37.250] (il0203a-dhcp122.apple.com [17.202.37.250]) by scv3.apple.com (8.9.3/8.9.3) with ESMTP id QAA27415; Wed, 14 Jun 2000 16:03:52 -0700 (PDT) MIME-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <3947A03B.925554C1@cs.columbia.edu> References: <3947A03B.925554C1@cs.columbia.edu> Newsgroups: rec.video.desktop Date: Wed, 14 Jun 2000 13:59:16 -0700 To: Henning Schulzrinne , rem-conf@es.net From: Kevin Marks Subject: Re: Firewire/1394 for live streaming Cc: rem-conf@es.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:09 AM -0400 6/14/00, Henning Schulzrinne wrote: >Is it possible to use a Firewire/1394 card as a Video-for-Windows >device, so that a DV camcorder can directly stream into NetShow, >NetMeeting, vic, etc.? Any mechanism to directly convert this to >streaming MPEG2? With a G4 Mac you could use FireWire DV as an input to encode to H263, H261 or JPEG with Sorenson Broadcaster & QT 4.1.2. You can get 30fps at 320x240 frame sizes. If you use uLaw or aLaw for the audio you will have an interoperable RTP multicast stream. DV in to MPEG2 encoding in software is not available in QT; Cisco have some servers that will live-encode MPEG from video in. From rem-conf Wed Jun 14 18:13:39 2000 From rem-conf-request@es.net Wed Jun 14 18:13:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132O8X-0007cN-00; Wed, 14 Jun 2000 18:08:01 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 132O8W-0007cC-00; Wed, 14 Jun 2000 18:08:00 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id SAA20699 for ; Wed, 14 Jun 2000 18:07:58 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 14 Jun 2000 18:07:58 -0700 Received: from [17.202.37.250] (il0203a-dhcp122.apple.com [17.202.37.250]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id SAA04998; Wed, 14 Jun 2000 18:07:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <03AB3CB11CBED3118A4F009027B0C2B1015971@HAPPY> References: <03AB3CB11CBED3118A4F009027B0C2B1015971@HAPPY> Date: Wed, 14 Jun 2000 17:00:04 -0700 To: Bill Nowicki , "'Henning Schulzrinne'" From: Kevin Marks Subject: RE: Firewire/1394 for live streaming Cc: rem-conf@es.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 1:07 PM -0700 6/14/00, Bill Nowicki wrote: >Alas, the $50 FireWire PCI cards (or motherboard interfaces on Sony PCs >etc.) do not have a decoder for the DV, so you get the DV encoded stream. >The Windows 98 and 2000 support is a Windows Driver Model driver, not Video >for Windows. So DirectShow applications can work (like most DV editing >tools), but Windows Media Encoder does NOT. My DV over RTP implementations >use DirectShow and the Windows driver for simple cards. QuickTime has a DV decoder, so you could wrap your capture code in a QT VDIG, and use QT to capture and recompress from the API level. From rem-conf Wed Jun 14 18:13:39 2000 From rem-conf-request@es.net Wed Jun 14 18:13:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132O8Y-0007cY-00; Wed, 14 Jun 2000 18:08:02 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 132O8X-0007cH-00; Wed, 14 Jun 2000 18:08:01 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id SAA20711 for ; Wed, 14 Jun 2000 18:08:00 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 14 Jun 2000 18:07:59 -0700 Received: from [17.202.37.250] (il0203a-dhcp122.apple.com [17.202.37.250]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id SAA05001; Wed, 14 Jun 2000 18:07:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <3947E878.E0B38CC9@cs.columbia.edu> References: <03AB3CB11CBED3118A4F009027B0C2B1015971@HAPPY> <3947E878.E0B38CC9@cs.columbia.edu> Date: Wed, 14 Jun 2000 17:03:42 -0700 To: Henning Schulzrinne , Bill Nowicki From: Kevin Marks Subject: Re: Firewire/1394 for live streaming Cc: rem-conf@es.net Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 4:18 PM -0400 6/14/00, Henning Schulzrinne wrote: >Given that DV is apparently DCT-coded, would it be possible to generate >MPEG-1 I frames without hardware support or is the DV format (besides >the packing into 80? byte units) so different that one has to go back to >"raw bits"? The way DV encodes fields is different from MPEG, as I understand it. DV is a fixed size format which does not map well to MPEG1 (which is a different size, and doesn't do fields). You could optimise the decode-recode path by going to a common YUV format and only decoding the coefficients you need. From rem-conf Wed Jun 14 18:56:23 2000 From rem-conf-request@es.net Wed Jun 14 18:56:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132OsC-0001o0-00; Wed, 14 Jun 2000 18:55:12 -0700 Received: from koganei.wide.ad.jp (happy.koganei.wide.ad.jp) [202.249.37.254] by mail1.es.net with esmtp (Exim 1.81 #2) id 132OsB-0001nq-00; Wed, 14 Jun 2000 18:55:11 -0700 Received: from koganei.wide.ad.jp (tweedledee.koganei.wide.ad.jp [202.249.37.72]) by happy.koganei.wide.ad.jp (8.9.3/8.9.3) with ESMTP id KAA04092; Thu, 15 Jun 2000 10:55:10 +0900 (JST) (envelope-from ikob@koganei.wide.ad.jp) Message-ID: <3948376D.DF3B44E5@koganei.wide.ad.jp> Date: Thu, 15 Jun 2000 10:57:04 +0900 From: Katsushi Kobayashi X-Mailer: Mozilla 4.72 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne CC: Bill Nowicki , rem-conf@es.net Subject: Re: Firewire/1394 for live streaming References: <03AB3CB11CBED3118A4F009027B0C2B1015971@HAPPY> <3947E878.E0B38CC9@cs.columbia.edu> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Henning Schulzrinne wrote: > > Bill Nowicki wrote: > > > > Alas, the $50 FireWire PCI cards (or motherboard interfaces on Sony PCs > > etc.) do not have a decoder for the DV, so you get the DV encoded stream. > > The Windows 98 and 2000 support is a Windows Driver Model driver, not Video > > for Windows. So DirectShow applications can work (like most DV editing > > tools), but Windows Media Encoder does NOT. My DV over RTP implementations > > use DirectShow and the Windows driver for simple cards. > > Is this an application that is available free/otherwise (and thus should > be added to the RTP implementation list)? > You can found a DV over RTP implementation on FreeBSD >from http://www.sfc.wide.ad.jp/DVTS (also including FreeBSD driver information). -- ikob@koganei.wide.ad.jp From rem-conf Thu Jun 15 01:37:27 2000 From rem-conf-request@es.net Thu Jun 15 01:37:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132Uyh-0006Em-00; Thu, 15 Jun 2000 01:26:19 -0700 Received: from (sfpexchange02.iscorvdb.co.za) [156.8.60.181] by mail1.es.net with esmtp (Exim 1.81 #2) id 132Uyd-0006DU-00; Thu, 15 Jun 2000 01:26:17 -0700 Received: by sfpexchange02.iscorvdb.co.za with Internet Mail Service (5.5.2650.21) id ; Wed, 14 Jun 2000 20:59:23 +0200 Message-ID: From: 1F255D948@public1.bta.net.cn To: Subject: Re: your decision Date: Wed, 14 Jun 2000 05:59:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Look, we don't want to waste your time...or ours You must be determined to earn a bare minimum of $10,000 in the next 30 - 45 days and to develop a net worth of over 1 Million Dollars Cash in the next 24-36 months. My mission is to help other people develop their life long dreams. Part of what I'm looking for are those people who are committed to that BIG of a picture and are not afraid to work for it. We can help you: REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! NOT MLM or FRANCHISE Don't bother to call unless you are serious. Learn the Facts CALL 1800-914-7027 (24 hrs) $10,000 IN 30 - 45 DAYS RETIREMENT IN 3-5 YEARS Please accept our deepest apologizes, if you received this email unsolicited, and you can be removed automatically below. **************************************************************************** *********** All REMOVE requests AUTOMATICALLY honored upon receipt. mailto:lori1969@altavistausa.com?subject=Remove PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. **************************************************************************** ************ From rem-conf Thu Jun 15 06:44:56 2000 From rem-conf-request@es.net Thu Jun 15 06:44:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132Zqv-0002L4-00; Thu, 15 Jun 2000 06:38:37 -0700 Received: from joplin.ee.pucrs.br (ee.pucrs.br) [200.132.7.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 132Zqs-0002Ku-00; Thu, 15 Jun 2000 06:38:35 -0700 Received: from localhost (ricardob@localhost) by ee.pucrs.br (8.9.3/8.9.3) with ESMTP id KAA08022 for ; Thu, 15 Jun 2000 10:35:43 -0300 (EST) Date: Thu, 15 Jun 2000 10:35:42 -0300 (EST) From: Ricardo Balbinot To: rem-conf@es.net Subject: RE: Firewire/1394 for live streaming In-Reply-To: <03AB3CB11CBED3118A4F009027B0C2B1015971@HAPPY> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 14 Jun 2000, Bill Nowicki wrote: > Alas, the $50 FireWire PCI cards (or motherboard interfaces on Sony PCs > etc.) do not have a decoder for the DV, so you get the DV encoded stream. > The Windows 98 and 2000 support is a Windows Driver Model driver, not Video > for Windows. So DirectShow applications can work (like most DV editing > tools), but Windows Media Encoder does NOT. My DV over RTP implementations > use DirectShow and the Windows driver for simple cards. Yeah, that is true... And de WDM drivers are suposed to be better than the old video for windows ones. But you see, most of the available drivers are still developed for Video for Windows, so, in Win98 and, perhaps, in Win2000, the drivers are implemented following the WDM, but behaves like a normal Video for Windows driver. Truly, most directshow or directvideo applications use those drivers just like a normal video for windows applications (the driver maps a video for windows driver in the WDM architecture). So, I can't see why Windows Media Encoder does not work at all. In fact, if you see that the windows media is heavilly based on the directx technology, that's a strange sentence. Anyway, at the site of the windows media technologies you can download the new Media Player (and tools) specific for Win98 and 2000(that's the beta release, I believe), that may solve this "problem". Bets regards, Ricardo Balbinot. From rem-conf Thu Jun 15 09:07:52 2000 From rem-conf-request@es.net Thu Jun 15 09:07:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132c6N-0004uv-00; Thu, 15 Jun 2000 09:02:43 -0700 Received: from athm-216-216-xxx-85.home.net (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 132c6M-0004uK-00; Thu, 15 Jun 2000 09:02:42 -0700 Received: by HAPPY with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 09:04:48 -0700 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B1015977@HAPPY> From: Bill Nowicki To: 'Ricardo Balbinot' Cc: rem-conf@es.net Subject: RE: Firewire/1394 for live streaming Date: Thu, 15 Jun 2000 09:04:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > In fact, if you see that the windows media is heavilly based > on the directx technology, that's a strange sentence. You are talking about the *PLAYER*. Yes, the Windows Media Player can play DV files (wrapped in AVI) just fine (if you have the 6.4.x version that includes the DV decoder). As far as I can tell the 7.x version of the Windows Media Player has new "skins" and some "jukebox" features but is the same architecture (DirectShow, previously known as ActiveMovie) underneath. I was talking about the *ENCODER*, which is the application that captures the video and compresses it to MPEG-4 or whatever to send over the network. At least the currently released Windows Media Encoder cannot take DV as input, only YUV and RGB type of formats. It does not help that Microsoft keeps changing the names of their technologies and confuses the two sides sometimes themsleves. :-) Glad to see there is some interest in this! Bill Nowicki, Omneon Video From rem-conf Thu Jun 15 09:33:09 2000 From rem-conf-request@es.net Thu Jun 15 09:33:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132cXD-00061t-00; Thu, 15 Jun 2000 09:30:27 -0700 Received: from joplin.ee.pucrs.br (ee.pucrs.br) [200.132.7.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 132cXB-00061W-00; Thu, 15 Jun 2000 09:30:25 -0700 Received: from localhost (ricardob@localhost) by ee.pucrs.br (8.9.3/8.9.3) with ESMTP id NAA10551; Thu, 15 Jun 2000 13:27:07 -0300 (EST) Date: Thu, 15 Jun 2000 13:27:07 -0300 (EST) From: Ricardo Balbinot To: Bill Nowicki cc: rem-conf@es.net Subject: RE: Firewire/1394 for live streaming In-Reply-To: <03AB3CB11CBED3118A4F009027B0C2B1015977@HAPPY> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Ok. I did not noticed that. Regards, Ricardo Balbinot. From rem-conf Thu Jun 15 13:51:01 2000 From rem-conf-request@es.net Thu Jun 15 13:51:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132gR6-0001ym-00; Thu, 15 Jun 2000 13:40:24 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 132gR0-0001yZ-00; Thu, 15 Jun 2000 13:40:18 -0700 Received: from dynamicsoft.com (1Cust213.tnt2.freehold.nj.da.uu.net [63.17.114.213]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA22917; Thu, 15 Jun 2000 16:41:18 -0400 (EDT) Message-ID: <39493F3E.B7753B1F@dynamicsoft.com> Date: Thu, 15 Jun 2000 16:40:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IMPP WG CC: sip , rem-conf@es.net, "iptel, list" Subject: proposal for IMPP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Some colleagues and I have put together a suite of protocols for IMPP, based partly on SIP. Its actually seven separate drafts, althouth the core is just two. They have been submitted to the I-D editor, but you can grab them right now from: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-presence-00.txt Core presence protocol. We've written it to be understandable by non SIP experts, and to also indicate what parts of SIP you do and don't need for presence. Don't be scared by the size (70 pages), nearly half are example message flows. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-im-00.txt Core IM protocol. Also written to be both a tutorial on SIP and explain how to do IM. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-qauth-00.txt A mini-protocol for authorizing subscriptions, to support, among other things, the ability for subscriptions to happen when the presentity is offline. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-pidf-00.txt An XML PIDF format, optional in our architecture. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-lpidf-00.txt A really thin pidf, good for wireless devices, since it uses the same parser SIP uses. This is mandatory to support in our architecture. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-watcherinfo-00.txt A format for watcher info. http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-impp-buddylist-00.txt Something we never discussed on the list before; a buddylist document, much akin to bookmarks, which you can store on a server. This way, when you go to a different machine, you can fetch your buddylist, and get your presence services there. Comments and questions are welcome, of course. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Thu Jun 15 15:31:38 2000 From rem-conf-request@es.net Thu Jun 15 15:31:37 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 132i04-0003Va-00; Thu, 15 Jun 2000 15:20:36 -0700 Received: from igate.nuera.com ([204.216.240.98] helo=sd_exchange.nuera.com) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 132i02-0003VQ-00; Thu, 15 Jun 2000 15:20:34 -0700 Received: by sd_exchange.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Jun 2000 15:19:03 -0700 Message-ID: <613A6A6A3F09D3118F5C00508B2C24FE7F35E6@sd_exchange.nuera.com> From: "Fox, Mike" To: Jonathan Rosenberg , IMPP WG Cc: sip , rem-conf@es.net, "iptel, list" Subject: RE: proposal for IMPP Date: Thu, 15 Jun 2000 15:18:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol may be the right way. Call it SIP Control by Unified Methods. SOAP SCUM Best regards, Mike Fox From rem-conf Thu Jun 15 19:24:16 2000 From rem-conf-request@es.net Thu Jun 15 19:24:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132ll4-0006nw-00; Thu, 15 Jun 2000 19:21:22 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 132lkx-0006nH-00; Thu, 15 Jun 2000 19:21:18 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id LAA29385; Fri, 16 Jun 2000 11:20:52 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id LAA08884; Fri, 16 Jun 2000 11:20:51 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id LAA09245; Fri, 16 Jun 2000 11:20:50 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id LAA62922; Fri, 16 Jun 2000 11:20:49 +0900 (JST) Message-ID: <018d01bfd739$73bdf5c0$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" Cc: "Yoshihiro Kikuchi" References: <03c901bfd44f$07b26560$4f51c485@eel.rdc.toshiba.co.jp> Subject: Re: MPEG-4 A/V RTP I/D update: summary of discussion Date: Fri, 16 Jun 2000 11:20:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear MPEG-4 over IP experts, The authors of the MPEG-4 Audio/Visual RTP are about to prepare the final version of the Internet-Draft. We have not get any comment since I sent the summary and conclusion of the discussion. Can we understand that the conclusion is now satisfied by the whole group? If there is any comment, please let us know ASAP. If there is no further comment, the author will understand that the conclusion is approved and will prepare the final I/D following this. Best regards, Yoshihiro ----- Original Message ----- From: Yoshihiro Kikuchi To: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT Cc: Yoshihiro Kikuchi Sent: Monday, June 12, 2000 6:17 PM Subject: MPEG-4 A/V RTP I/D update: summary of discussion > Dear all MPEG-4 over IP experts, > > Please find bellow a summary of discussions about the updated I/D of MPEG-4 > Audio/Visual RTP/RTCP. We will prepare the final version of the > Internet-Draft by the end of this week. The conclusions bellow are what the > authors are thinking about now. But we should finally follow the consensus > of the group. If someone is not satisfied the summary and conclusions > bellow, especially on (2), please let us know your comment through the > reflector ASAP. > > What I would like to have a consensus now is that the final I/D will contain > ONLY items that will reach to a consensus among the group before preparing > the final text. In other words, a part of the I/D which cannot reach to a > consensus may be removed or revised. > > If there is no further comment, the authors will prepare the final version > of I/D following the conclusions bellow. > > > (1) FIR (Stephan's proposal) > There was a proposal by Stephan Wenger about a new feedback scheme using > FIR. It tries to cover all MPEG-4 Visual profiles, including profiles which > are not covered by NEWPRED. However, there is no specific description so > far. It lacks of discussions about the idea. Concerns were raised to add a > new technical item without having enough discussions. It needs further > discussions and may needs comparisons with other proposals to adopt the > idea. > > [Conclusion] > Not to include FIR proposal into the I/D. The proposal may be discussed in > future. > > (2) NEWPRED RTCP (section 5) > There was a concern raised by Stephan Wenger to keep the RTCP part in the > I/D. The reason was that this RTCP concerns only NEWPRED, which covers only > ARTS Profile. He proposed that the addition of FIR based feedback scheme may > resolve the problem. He proposed three ways to proceed: 1) someone convince > him to keep the NEWPRED RTCP as is, 2) move NEWPRED RTCP part (section 5) to > a separate I/D and work together with FIR proposal, and 3) put FIR together > with NEWPRED into the I/D. (But FIR proposal definitely needs further > discussions. See (1) above.) > The discussion at the Adelaide meeting was explained by Sigeru Fukunaga, a > proponent of the NEWPRED. > (Note: Conclusion from the draft minutes is: "Steve Casner concluded with > the chairs' view that we should proceed with the definition of this > backchannel scheme as is, and consider a more general solution in future.") > There is a strong desire by Sigeru Fukunaga to use MPEG-4 NEWPRED on H.323 > systems soon in their company's products. It requires RFC for the NEWPRED > RTCP be ready before the > Nov. SG16 meeting. > (Note: It is a common desire among authors to have an RFC for the RTP part > soon. However, it should be remarked that all products may not use NEWPRED.) > It was proposed by Yoshihiro Kikuchi, an editor of the I/D to add the > description to clarify that the NEWPRED RTCP is optional, and nothing to > prevent the future discussions about new feedback schemes. > > [Conclusion] > If the conclusion at the Adelaide meeting is agreeable, the authors will > follow this. The final conclusion should be made depend on the discussions > and the consensus among the whole group. In any case, it should be clarified > that the NEWPRED RTCP is nothing to prevent the future discussions on new > feedback schemes. > > > (3) Other items > There was a suggestion by Stephan Wenger that the English quality may need > improvement. There is no technical comment on the parts other than RTCP. > > [Conclusion] > The authors are now working on the improvement of the English quality. The > text should be ready by the end of this week. > > > Best regards, > Yoshihiro > > ---- > Yoshihiro Kikuchi > > E-mail: kiku@eel.rdc.toshiba.co.jp > Corporate Research and Development Center > TOSHIBA Corporation > TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 > > > > > > From rem-conf Fri Jun 16 03:55:13 2000 From rem-conf-request@es.net Fri Jun 16 03:55:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132tap-00042M-00; Fri, 16 Jun 2000 03:43:19 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 132tan-00042C-00; Fri, 16 Jun 2000 03:43:17 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08305; Fri, 16 Jun 2000 06:43:15 -0400 (EDT) Message-Id: <200006161043.GAA08305@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-g7221-00.txt Date: Fri, 16 Jun 2000 06:43:15 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for ITU-T Recommendation G.722.1 Author(s) : P. Luthi Filename : draft-ietf-avt-rtp-g7221-00.txt Pages : 7 Date : 15-Jun-00 ITU-T Recommendation G.722.1 [2] is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet [3]. Also included here are the necessary details for the use of G.722.1 with MIME [4] and SDP [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g7221-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-g7221-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-g7221-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000615103232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-g7221-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-g7221-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000615103232.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jun 16 06:22:30 2000 From rem-conf-request@es.net Fri Jun 16 06:22:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 132vyl-0006Cm-00; Fri, 16 Jun 2000 06:16:11 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 132vyi-0006CV-00; Fri, 16 Jun 2000 06:16:09 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id WAA29859; Fri, 16 Jun 2000 22:16:06 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id WAA16104; Fri, 16 Jun 2000 22:16:06 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id WAA03962; Fri, 16 Jun 2000 22:16:05 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id WAA07065; Fri, 16 Jun 2000 22:16:05 +0900 (JST) Message-ID: <03f601bfd794$fd938b60$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Dave Singer" Cc: "IETF AVT" , "Yoshihiro Kikuchi" References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de><094601bfd5e1$6e2d8ca0$dd975c8b@rennes.cnet.fr><05f701bfd5eb$70f1f840$4f51c485@eel.rdc.toshiba.co.jp> Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP Date: Fri, 16 Jun 2000 22:15:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Dave, Olivier, all, Thank you very much for your answer. I'm now happy that my misunderstandings of (a) and (c) have been cancelled. I'm sorry to have the misunderstanding. I support the trial to have a framework covering multiple MPEG-4 RTP payload formats. However, I still have my opinion that it still needs careful discussions before deciding recommended payload formats. (Is it really single format?) This is nothing to prevent the work, but just to have a solution that all related party are agreeable. We should NOT have a solution like (a). I think that N3381 is a good starting point, but may still need further revisions before stamping MPEG mark. Fortunately, there is one more MPEG meeting in Beijing before the next IETF meeting in August. Is it too late to have a discussion before/at the meeting? Best regards, Yoshihiro ----- Original Message ----- From: Dave Singer To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: ; Yoshihiro Kikuchi Sent: Thursday, June 15, 2000 1:35 AM Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP > My intention was your (b). Enable to the support of multiple RTP > payloads for MPEG-4 data; require the support of one (so as to have > a chance at interoperability). Make sure all schemes share some > common characteristics, and share other behavior with respect to > IP-based protocols (SDP, RTSP in particular). > > I didn't actually propose any new payload formats, merely observed > that there was probably good reason to make some. > > (By the way, I have reduced the recipient list here to just the > relevant email groups, with a cc to the person I am replying to, to > be sure it gets to him, as I assume that everyone is one or both > lists.) > > At 19:29 +0900 6/14/00, Yoshihiro Kikuchi wrote: > >Dear Dave, Olivier, all, > > > >I'm resending the attached mail which may be related to this discussion > >because I haven't see this mail through the reflector. > > > >I agree with the basic concept of Dave's proposal if it tries to propose a > >framework covering all MPEG-4 RTP formats. Actually, I misunderstood that it > >might be proposing like (c) in the attached mail. But, we need to be care > >that we should never have a solution like (a). By this meaning, I think that > >N3381 needs further revisions. The selection of RTP payload proposals and > >MUST/SHOULD/MAY wording should be decided with much care. > > > >If it is acceptable, I would like to make a contribution from one side of > >the MPEG-4 RTP world. > > > >Best regards, > >Yoshihiro > > > >What I would like to ask is which one of the followings is the correct > >purpose of the framework proposed in N3381. > > > >(a) It forces to use only one RTP payload format > >(draft-ietf-avt-rtp-mpeg4-02[8]), or plus one > >(draft-rgcc-avt-mpeg4flexmux-00[5]), in all cases when the proposed > >framework is used. > > > >(b) It proposes a framework to treat all MPEG-4 RTP payload formats. It > >leaves the selection of RTP payload format depending on the media types > >(e.g. MPEG-4 Audio/Visual), applications, network environments, users needs, > >etc, while keeping a framework commonly to all RTP payload formats. We can > >use MPEG-4 Audio/Visual media aware packetization scheme, e.g. > >draft-ietf-avt-rtp-mpeg4-es-01[6], if it satisfies the conditions [2.1] to > >[2.6] in section 2 of N3381. > > > >(c) It tries to propose new payload formats other than the existing ones. > > > -- > David Singer > Apple Computer/QuickTime > From rem-conf Fri Jun 16 13:13:58 2000 From rem-conf-request@es.net Fri Jun 16 13:13:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1332JK-00030l-00; Fri, 16 Jun 2000 13:01:50 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 1332JI-00030a-00; Fri, 16 Jun 2000 13:01:48 -0700 Received: from SMTPMail.PicTel.com (hqsmtpmail.pictel.com [140.242.100.76]) by gateway-gw.pictel.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA22354 for ; Fri, 16 Jun 2000 16:05:17 -0400 (EDT) Received: by SMTPMail.PicTel.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 85256900.006E0393 ; Fri, 16 Jun 2000 16:01:38 -0400 X-Lotus-FromDomain: PICTEL From: "Patrick Luthi" To: rem-conf@es.net Message-ID: <85256900.006E026E.00@SMTPMail.PicTel.com> Date: Fri, 16 Jun 2000 16:01:22 -0400 Subject: I-D ACTION:draft-ietf-avt-rtp-g7221-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The difference from the previous version of draft-ietf-avt-rtp-g7221-00.txt (01/11/2000) authored by Tony Crossman are mainly comments received from different reviewers and the AVT chairs, along with some editorial corrections. The comments were incorporated in: 1) section 4 - the paragraph after figure 1 was rewritten to make it clearer 2) section 4 - the last paragraph was modified to clarify the use of non-standard rates 3) section 4.1 - in the paragraph on additional restrictions, MUST was changed to SHOULD in the first bullet item, and the second bullet item was added 4) section 5 - added missing fields in MIME registration Feedback is welcomed ! Patrick Luthi PictureTel Corp. >To: IETF-Announce:;@es.net >Cc: rem-conf@es.net >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-avt-rtp-g7221-00.txt >Date: Fri, 16 Jun 2000 06:43:15 -0400 >Sender: nsyracus@cnri.reston.va.us >X-Mailing-List: >X-Loop: rem-conf@es.net > >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Audio/Video Transport Working Group of the IETF. > > Title : RTP Payload Format for ITU-T Recommendation G.722.1 > Author(s) : P. Luthi > Filename : draft-ietf-avt-rtp-g7221-00.txt > Pages : 7 > Date : 15-Jun-00 > >ITU-T Recommendation G.722.1 [2] is a wide-band audio codec, which >operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. >This document describes the payload format for including G.722.1 >generated bit streams within an RTP packet [3]. Also included here >are the necessary details for the use of G.722.1 with MIME [4] and >SDP [5]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g7221-00.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-avt-rtp-g7221-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-avt-rtp-g7221-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20000615103232.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-avt-rtp-g7221-00.txt > > > From rem-conf Fri Jun 16 13:40:52 2000 From rem-conf-request@es.net Fri Jun 16 13:40:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1332pi-00044E-00; Fri, 16 Jun 2000 13:35:18 -0700 Received: from out5.prserv.net (prserv.net) [32.97.166.35] by mail1.es.net with esmtp (Exim 1.81 #2) id 1332ph-000444-00; Fri, 16 Jun 2000 13:35:17 -0700 Received: from rpcaragonite ([139.92.8.50]) by prserv.net (out5) with SMTP id <2000061620343324301hdut8e>; Fri, 16 Jun 2000 20:34:34 +0000 Message-ID: <009501bfd7d2$6a4e8ce0$226e69a1@rpcaragonite> Reply-To: "Olivier Avaro" From: "Olivier Avaro" To: "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Dave Singer" Cc: "IETF AVT" , "Yoshihiro Kikuchi" References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de><094601bfd5e1$6e2d8ca0$dd975c8b@rennes.cnet.fr><05f701bfd5eb$70f1f840$4f51c485@eel.rdc.toshiba.co.jp> <03f601bfd794$fd938b60$4f51c485@eel.rdc.toshiba.co.jp> Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP Date: Fri, 16 Jun 2000 22:35:28 +0200 Organization: France Telecom - CNET MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Yoshihiro, > I think that N3381 is a good starting point, but may still need > further revisions before stamping MPEG mark. N3381, as it's name indicate, already have an MPEG mark. > Fortunately, there is one more MPEG meeting in Beijing before the next IETF > meeting in August. Is it too late to have a discussion before/at the > meeting? No, this is not too late, this is just the beginning of the discussion, and your comments are mostly wellcomed. Please send them on the list for discussion. A new version of the document will be proposed to the next meeting based on consensus on this list. Controversial issues should be proposed to the Beijing meeting as separate document. They will be proceeded during the meeting. In Beijing, we will output a new version of the document. Kind regards, Olivier From rem-conf Fri Jun 16 13:57:19 2000 From rem-conf-request@es.net Fri Jun 16 13:57:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13332E-0004sw-00; Fri, 16 Jun 2000 13:48:14 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13332D-0004sm-00; Fri, 16 Jun 2000 13:48:13 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id NAA10324 for ; Fri, 16 Jun 2000 13:48:11 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 16 Jun 2000 13:48:09 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id NAA01681; Fri, 16 Jun 2000 13:48:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <03f601bfd794$fd938b60$4f51c485@eel.rdc.toshiba.co.jp> References: <005401bfd560$1c5236f0$aa1e4581@ksat10.rus.uni-stuttgart.de> <094601bfd5e1$6e2d8ca0$dd975c8b@rennes.cnet.fr> <05f701bfd5eb$70f1f840$4f51c485@eel.rdc.toshiba.co.jp> <03f601bfd794$fd938b60$4f51c485@eel.rdc.toshiba.co.jp> Date: Fri, 16 Jun 2000 13:46:11 -0700 To: Yoshihiro Kikuchi From: Dave Singer Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, IETF AVT , Yoshihiro Kikuchi Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >I support the trial to have a framework covering multiple MPEG-4 RTP payload >formats. However, I still have my opinion that it still needs careful >discussions before deciding recommended payload formats. (Is it really >single format?) This is nothing to prevent the work, but just to have a >solution that all related party are agreeable. We should NOT have a solution >like (a). I think that N3381 is a good starting point, but may still need >further revisions before stamping MPEG mark. OK. I agree, I put out 3381 for comment, not as a final solution. I also agree, that though I feel strongly we need a GP packing format which is required (otherwise we cannot achieve interoperability), it is possible that I have picked the wrong one, though I don't think so. >Fortunately, there is one more MPEG meeting in Beijing before the next IETF >meeting in August. Is it too late to have a discussion before/at the >meeting? Let's discuss away. I will not be in Beijing, but will be on email... -- David Singer Apple Computer/QuickTime From rem-conf Fri Jun 16 15:54:21 2000 From rem-conf-request@es.net Fri Jun 16 15:54:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1334vm-0006ew-00; Fri, 16 Jun 2000 15:49:42 -0700 Received: from rolex.csc.ncsu.edu [152.1.213.197] by mail1.es.net with esmtp (Exim 1.81 #2) id 1334vl-0006em-00; Fri, 16 Jun 2000 15:49:41 -0700 Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id SAA12781; Fri, 16 Jun 2000 18:48:50 -0400 (EDT) From: "Dr. Injong Rhee" Message-Id: <10006161848.ZM12779@unity.ncsu.edu> Date: Fri, 16 Jun 2000 18:48:49 -0400 In-Reply-To: Stephan Wenger "Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format" (Jun 1, 2:47pm) References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> X-Mailer: Z-Mail (3.2.1 10oct95) To: Stephan Wenger , "Shigeru Fukunaga" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, I would to add some comments and express some concerns over the current draft. First, as Stephan pointed out, we need to clean up the language. Many parts are written in a very confusing manner. I will list a subset of things that I found confusing below. Read on.... Second, this draft is only specific to newpred, but it is still called profile for mpeg-4 audio/visiual streams. With this title, I suggest adding other ways of accomplishing the same affair, in particular, other feedback mechanisms such as retransmission and even for forward error correction. Third, it seems to me that feedback mechanisms, especially the types of feedback that this draft specifies (NACK or ACK), are very generic and can be used in many places. They may not be specific for newpred only. Wouldn't it be a good idea to delete section 5, and discuss a more general unified feedback mechansim. I believe there was some drafts on retransmission and feedbacks some time ago. Can we try to extend on that? I am willing to work together on this issue. Fourth, discussion on congestion control in Section 5.3 is not convincing. It seems that the authors are confused about the issues of loss recovery with those of flow control. They are orthogonal issues. For instance, it seems that the authors believe retx causes more congestion. This is not the case. retx is a recovery technique, but not a flow control technique. Instead, you should argue one technique gives lower or higher bit overhead or not -- which is a totally different ball game. Fifth, Does retransmission have more bit overhead than NEWPRED? It seems that the authors believe that. I don't believe that this is a commonly accepted statement because I don't see any evidence or proof for it in any other literature they publish...need more extensive testing to say retx is worse than newpred. On the contrary, my experiments suggest that retx and newpred use similar amount of bit overhead -- of course this depends on the amount of motion present in the video input. Inaddition, why does retx cause lower coding efficiency???? Sixth, the authors need to say that in order for newpred to work, newpred needs real-time encoder. Thus, it MAY not be suitable for streaming. For instance, in section 6.1, in the applications which use this type of media type, the authors need to clarify this point. How can you design internet email applications in a scalable manner with real-time encoders which need to adapt reference frames on the fly depending on the ack from the player???? I believe that this document needs more work. I will be glad to help if requested. Regards, Injong -- Injong Rhee, Department of Computer Science North Carolina State University, Raleigh, NC 27695 Home page: http://www.csc.ncsu.edu/faculty/rhee Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 From rem-conf Fri Jun 16 17:01:46 2000 From rem-conf-request@es.net Fri Jun 16 17:01:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1335y2-00006d-00; Fri, 16 Jun 2000 16:56:06 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 1335y0-00006T-00; Fri, 16 Jun 2000 16:56:05 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-118.dialup.cs.tu-berlin.de [130.149.145.118]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id BAA06024; Sat, 17 Jun 2000 01:50:01 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000617010835.029cbb60@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 Jun 2000 01:19:06 +0200 To: "Dr. Injong Rhee" , "Shigeru Fukunaga" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" From: Stephan Wenger Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <10006161848.ZM12779@unity.ncsu.edu> References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, Sorry for my long silence. Fifth, Does retransmission have more bit overhead than NEWPRED? >It seems that the authors believe that. I don't believe that >this is a commonly accepted statement because I don't see >any evidence or proof for it in any other literature they >publish...need more extensive testing to say retx is worse >than newpred. On the contrary, my experiments suggest that >retx and newpred use similar amount of bit overhead -- of >course this depends on the amount of motion present in >the video input. Inaddition, why does retx cause lower >coding efficiency???? Newpred typically uses MORE bits than a well designed re-transmission algorithm. Re-transmission actually restores the signal completely in the most efficient way, because only those bits are conveyed which were lost before. But, and that is the critical point, re-transmission induces substantial delay, whereas Newpred does not. Newpred's advantage is the low number bits that are added in case compared to other source coding mechanisms such as Intra macroblock refresh, which is, similar to Newpred, also neutral to the delay. This just for clarification. Stephan From rem-conf Fri Jun 16 17:01:53 2000 From rem-conf-request@es.net Fri Jun 16 17:01:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1335y9-00006o-00; Fri, 16 Jun 2000 16:56:13 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 1335y8-00006T-00; Fri, 16 Jun 2000 16:56:12 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-118.dialup.cs.tu-berlin.de [130.149.145.118]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id BAA06030; Sat, 17 Jun 2000 01:50:09 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000617011918.029d7ea0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 Jun 2000 01:44:36 +0200 To: "Dr. Injong Rhee" , "Shigeru Fukunaga" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" From: Stephan Wenger Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <10006161848.ZM12779@unity.ncsu.edu> References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, some comments on the procedural issues, especially on ITU-T vs. IETF timing issues (and how we can cope with then and still get a reasonable feedback mechanism for MPEG-4). The main reason for the rush with the MPEG-4 ES packetization draft is to meet the decision deadline of two new versions of ITU-T recommendations that take advantage of MPEG-4 and Newpred. In order to keep the packetization scheme in those standards, a RFC number has to be issued by that time. It's a hard deadline -- if the draft, even after passing any last calls, is still in the RFC editor's queue, SG.16 will take the mechanism out. The next SG16 meeting is some time this fall (October? I'll look it up ad soon as I'm back in my office). That means that there is an additional delay for having MPEG-4 in H.323 systems when IETF/AVT cannot meet the deadline, which, in turn, is the reason for the rush with the draft. References to MPEG-4 packetization occur in the drafts of H.225.0v.3 and H.245 v.7 (was it 7? Something fairly high). ITU-Recommendations of the H.323 series continue to evolve. New versions of H.245 are decided almost every study group meeting. The update schedule on H.225.0 is much slower. The interesting thing now is, that adding the MPEG-4 ES packetization without Newpred concerns both H.225.0 and H.245, whereas, based on the language the drafts, the added Newpred features would concern only H.245. Maybe the proponents of Newpred want to comment on that. If I'm right with this assessment, then we can delete the controversial section 5 out of the I-D and move forward quickly, in the hope to get over with it in time for the H.225.0 decision in fall. Simultaneously, we can work on a feedback solution in an additional I-D (either MPEG-4 specific or not). This would be added later, but, due to the quick update schedule of H.245, it would probably less time then two years. Stephan At 06:48 PM 6/16/00 -0400, Dr. Injong Rhee wrote: >Hi All, > >I would to add some comments and express some concerns over the current draft. > >First, >as Stephan pointed out, we need to clean up the language. Many parts are > written in a very confusing manner. I will list a subset >of things that I found confusing below. Read on.... > >Second, this draft is only specific to newpred, but it is still called >profile for mpeg-4 audio/visiual streams. With this title, I suggest >adding other ways of accomplishing the same affair, in particular, other >feedback mechanisms such as retransmission and even for forward error >correction. > >Third, it seems to me that feedback mechanisms, especially the >types of feedback that this draft specifies (NACK or ACK), are >very generic and can be used in many places. They may not >be specific for newpred only. Wouldn't it be a good idea to >delete section 5, and discuss a more general unified >feedback mechansim. I believe there was some drafts on >retransmission and feedbacks some time ago. Can we try to >extend on that? I am willing to work together on this issue. > >Fourth, discussion on congestion control in Section 5.3 is not >convincing. It seems that the authors are confused about the >issues of loss recovery with those of flow control. They are >orthogonal issues. For instance, it seems that the authors >believe retx causes more congestion. This is not the case. >retx is a recovery technique, but not a flow control technique. >Instead, you should argue one technique gives lower or higher >bit overhead or not -- which is a totally different ball >game. > >Fifth, Does retransmission have more bit overhead than NEWPRED? >It seems that the authors believe that. I don't believe that >this is a commonly accepted statement because I don't see >any evidence or proof for it in any other literature they >publish...need more extensive testing to say retx is worse >than newpred. On the contrary, my experiments suggest that >retx and newpred use similar amount of bit overhead -- of >course this depends on the amount of motion present in >the video input. Inaddition, why does retx cause lower >coding efficiency???? > >Sixth, the authors need to say that in order for newpred to work, >newpred needs real-time encoder. Thus, it MAY not be suitable for >streaming. For instance, in section 6.1, in the applications which use this >type of media type, the authors need to clarify this point. >How can you design internet email applications in a scalable manner >with real-time encoders which need to adapt reference frames >on the fly depending on the ack from the player???? > >I believe that this document needs more work. I will be glad to help if >requested. > >Regards, >Injong > > >-- >Injong Rhee, Department of Computer Science >North Carolina State University, Raleigh, NC 27695 >Home page: http://www.csc.ncsu.edu/faculty/rhee >Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 From rem-conf Sat Jun 17 06:21:23 2000 From rem-conf-request@es.net Sat Jun 17 06:21:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133IQN-0007hD-00; Sat, 17 Jun 2000 06:14:11 -0700 Received: from rolex.csc.ncsu.edu [152.1.213.197] by mail1.es.net with esmtp (Exim 1.81 #2) id 133IQL-0007gt-00; Sat, 17 Jun 2000 06:14:09 -0700 Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id JAA17233; Sat, 17 Jun 2000 09:13:55 -0400 (EDT) From: "Dr. Injong Rhee" Message-Id: <10006170913.ZM17231@unity.ncsu.edu> Date: Sat, 17 Jun 2000 09:13:55 -0400 In-Reply-To: Stephan Wenger "Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format" (Jun 17, 1:19am) References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> <4.3.2.7.2.20000617010835.029cbb60@mail.cs.tu-berlin.de> X-Mailer: Z-Mail (3.2.1 10oct95) To: Stephan Wenger , "Shigeru Fukunaga" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Jun 17, 1:19am, Stephan Wenger wrote: > Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > Hi all, > > Sorry for my long silence. > > Fifth, Does retransmission have more bit overhead than NEWPRED? > >It seems that the authors believe that. I don't believe that > >this is a commonly accepted statement because I don't see > >any evidence or proof for it in any other literature they > >publish...need more extensive testing to say retx is worse > >than newpred. On the contrary, my experiments suggest that > >retx and newpred use similar amount of bit overhead -- of > >course this depends on the amount of motion present in > >the video input. Inaddition, why does retx cause lower > >coding efficiency???? > > Newpred typically uses MORE bits than a well designed re-transmission > algorithm. Re-transmission actually restores the signal completely > in the most efficient way, because only those bits are conveyed which > were lost before. But, and that is the critical point, re-transmission > induces substantial delay, whereas Newpred does not. > > Newpred's advantage is the low number bits that are added in case > compared to other source coding mechanisms such as Intra macroblock > refresh, which is, similar to Newpred, also neutral to the delay. > Stephan, I am afraid I have to disagree on this. :-) Retx can help even with delays. Retransmitted packets can be used to restore displayed reference frames and these restore reference frames can be used by later frames as reference to stop error propagation. The same effect as NEWPRED can be achieved. Retx will take the same delay as NEWPRED and gives the similar benefit (sometimes with much lower bit overhead) Additional advantages of retx are that it can be used for *multicast* and also for *streaming* without requiring re-encoding to change reference frames.... you can find more details about it >from an upcoming jsac paper by me and my student on this: Error recovery for Interactive video transmission over the internet. JSAC, Vol 18. No. 6 June 2000. If there is an interest, I can send you the draft electronically. Regards, Injong -- Injong Rhee, Department of Computer Science North Carolina State University, Raleigh, NC 27695 Home page: http://www.csc.ncsu.edu/faculty/rhee Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 From rem-conf Sat Jun 17 11:06:58 2000 From rem-conf-request@es.net Sat Jun 17 11:06:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133Ms5-0002f0-00; Sat, 17 Jun 2000 10:59:05 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (lazzaro) by mail1.es.net with esmtp (Exim 1.81 #2) id 133Ms3-0002eq-00; Sat, 17 Jun 2000 10:59:03 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id KAA06748 for rem-conf@es.net; Sat, 17 Jun 2000 10:59:03 -0700 Date: Sat, 17 Jun 2000 10:59:03 -0700 From: John Lazzaro Message-Id: <200006171759.KAA06748@snap.CS.Berkeley.EDU> To: rem-conf@es.net Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everyone, I had a few quick comments about draft-ietf-avt-rtp-mpeg4-es-01.txt, with respect to using it for MPEG 4 Structured Audio (ISO/IEC 14496-3 sec 5) content. For those unfamiliar with SA content, its a combination a tokenized C-like program, contained in a StructuredAudioSpecificConfig, and SA_access_units that launch processes (called instrs) or change local and global variables (either in a direct way, like "change a to 12", or an indirect way, like "fill this table with one cycle of a harmonic series with these weightings"). The StructuredAudioConfig can also contain an arbitrary amount of SA_access_unit-like data packed within it. For a gentle introduction to SA see: http://www.cs.berkeley.edu/~lazzaro/sa/ While I've read over draft-ietf-avt-rtp-new-07.txt as well as a recent draft of the Systems FCD for ISO/IEC 14496-1, I'm not at all a transport guy (but I do see Larry Rowe in the hallway sometimes :-) -- these are just a few things that caught my eye as I read through draft-ietf-avt-rtp-mpeg4-es-01.txt: [from page 19, 6.4 of draft-ietf-avt-rtp-mpeg4-es-01.txt] > The followings are some examples of the media representation in SDP: > > For 6 kb/s CELP bitstream (the audio sampling rate of 8 kHz), > m=audio 49230 RTP/AVP 96 > a=rtpmap:96 MP4A/8000 > a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070 > a=ptime:20 For SA, the string after "config=" (i.e. the StructuredAudioSpecificConfig) can be quite large (two example streams on SA primary author's Eric Scheirer's website are 27 kbytes and 1.7 Mbytes respectively). Rare will they be under a kbyte. Is SDP happy handling data chunks this large? Also, a large part of many config blocks will be quite predictable -- uncompressed tokenized representations of a program in a C-like programming language. Does this have any cryptographic consequences? [from Page 1, 1.3 of draft-ietf-avt-rtp-mpeg4-es-01.txt] > Furthermore, if the payload of a packet is a single audio frame, a packet > loss does not impair the decodability of adjacent packets. Therefore, a > payload specific header for MPEG-4 Audio is not required as same as one > for the other audio coders. If I understand this paragraph correctly, for SA_access_units this isn't true in general. For example, an SA_access_unit may set a global variable to a new value, which is then references throughout the audio content to make a macro change in the performance (for example, set the amplitude level of the audio output of an instrument). So in this sense, an uncorrected error in an SA_access_unit can essentially destroy all audio produced after the error, for the rest of the performance. --john lazzaro ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Sat Jun 17 11:07:10 2000 From rem-conf-request@es.net Sat Jun 17 11:07:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133Mue-0002fW-00; Sat, 17 Jun 2000 11:01:44 -0700 Received: from mail.pi.se [195.7.64.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 133Mud-0002fM-00; Sat, 17 Jun 2000 11:01:43 -0700 Received: from pigpen (ap01-073.mp.pi.se [195.7.86.73]) by mail.pi.se (8.8.8/8.8.8) with SMTP id UAA01292; Sat, 17 Jun 2000 20:01:31 +0200 (MET DST) From: "Gunnar Hellstrom" To: "Stephan Wenger" Cc: "Gary Sullivan" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" , "Shigeru Fukunaga" , "Dr. Injong Rhee" Subject: RE: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Sat, 17 Jun 2000 20:03:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <4.3.2.7.2.20000617011918.029d7ea0@mail.cs.tu-berlin.de> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.pi.se id UAA01292 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephan, I was in the same situation in February, in an SG16 meeting with a docume= nt for decision, and still no RFC for my RTP text packetization. A scaring experience, but with a happy end that time. The IETF approval came the s= ame day as the final plenary of SG16, and the decision could go forward. There is another mechanism published in the RTP profile (RFC 1890). It is= to just register the payload with IANA and register that ITU is the managing body of the payload description. Then include it in your ITU Recommendati= on. I do not know your situation exactly. For me, I am glad that I selected t= o go the IETF way, because the resulting RFC 2793 is then usable both for H.323 and SIP text conversation purposes. We can have Total Conversation with no transcoding between text in any multimedia protocol. But it was frightening.. Regards Gunnar Hellstr=F6m ______________________________________ Gunnar Hellstr=F6m Omnitor AB Alsn=F6gatan 7, 4tr S-116 41 Stockholm Sweden Mob +46 708 204 288 Tel +46 8 556 002 03 Fax +46 8 556 002 06 Video +46 8 556 002 05 Txt (All kinds) +46 8 556 002 05 E-mail gunnar.hellstrom@omnitor.se WWW: http://www.omnitor.se > -----Original Message----- > From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] > Sent: Saturday, June 17, 2000 1:45 AM > To: Dr. Injong Rhee; Shigeru Fukunaga; Yoshihiro Kikuchi; 4on2andIP-sys= ; > IETF AVT > Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > > > Hi All, > > some comments on the procedural issues, especially on > ITU-T vs. IETF timing issues (and how we can cope with > then and still get a reasonable feedback mechanism for > MPEG-4). > > The main reason for the rush with the MPEG-4 ES packetization > draft is to meet the decision deadline of two new versions of > ITU-T recommendations that take advantage of MPEG-4 and Newpred. > In order to keep the packetization scheme in those standards, a > RFC number has to be issued by that time. It's a hard deadline -- > if the draft, even after passing any last calls, is still in the > RFC editor's > queue, SG.16 will take the mechanism out. The next SG16 meeting > is some time this fall (October? I'll look it up ad soon as I'm back i= n > my office). That means that there is an additional delay for having > MPEG-4 in H.323 systems when IETF/AVT cannot meet the deadline, > which, in turn, is the reason for the rush with the draft. > > References to MPEG-4 packetization occur in the drafts of H.225.0v.3 > and H.245 v.7 (was it 7? Something fairly high). > > ITU-Recommendations of the H.323 series continue to evolve. New > versions of H.245 are decided almost every study group meeting. The > update schedule on H.225.0 is much slower. > > The interesting thing now is, that adding the MPEG-4 ES packetization > without Newpred concerns both H.225.0 and H.245, whereas, based > on the language the drafts, the added Newpred features would concern > only H.245. Maybe the proponents of Newpred want to comment on that. > > If I'm right with this assessment, then we can delete the controversial > section 5 out of the I-D and move forward quickly, in the hope to get > over with it in time for the H.225.0 decision in fall. Simultaneously,= we > can work on a feedback solution in an additional I-D (either MPEG-4 > specific or not). This would be added later, but, due to the quick upd= ate > schedule of H.245, it would probably less time then two years. > > Stephan > > > > > > > At 06:48 PM 6/16/00 -0400, Dr. Injong Rhee wrote: > > > >Hi All, > > > >I would to add some comments and express some concerns over the > current draft. > > > >First, > >as Stephan pointed out, we need to clean up the language. Many parts a= re > > written in a very confusing manner. I will list a subset > >of things that I found confusing below. Read on.... > > > >Second, this draft is only specific to newpred, but it is still called > >profile for mpeg-4 audio/visiual streams. With this title, I suggest > >adding other ways of accomplishing the same affair, in particular, oth= er > >feedback mechanisms such as retransmission and even for forward error > >correction. > > > >Third, it seems to me that feedback mechanisms, especially the > >types of feedback that this draft specifies (NACK or ACK), are > >very generic and can be used in many places. They may not > >be specific for newpred only. Wouldn't it be a good idea to > >delete section 5, and discuss a more general unified > >feedback mechansim. I believe there was some drafts on > >retransmission and feedbacks some time ago. Can we try to > >extend on that? I am willing to work together on this issue. > > > >Fourth, discussion on congestion control in Section 5.3 is not > >convincing. It seems that the authors are confused about the > >issues of loss recovery with those of flow control. They are > >orthogonal issues. For instance, it seems that the authors > >believe retx causes more congestion. This is not the case. > >retx is a recovery technique, but not a flow control technique. > >Instead, you should argue one technique gives lower or higher > >bit overhead or not -- which is a totally different ball > >game. > > > >Fifth, Does retransmission have more bit overhead than NEWPRED? > >It seems that the authors believe that. I don't believe that > >this is a commonly accepted statement because I don't see > >any evidence or proof for it in any other literature they > >publish...need more extensive testing to say retx is worse > >than newpred. On the contrary, my experiments suggest that > >retx and newpred use similar amount of bit overhead -- of > >course this depends on the amount of motion present in > >the video input. Inaddition, why does retx cause lower > >coding efficiency???? > > > >Sixth, the authors need to say that in order for newpred to work, > >newpred needs real-time encoder. Thus, it MAY not be suitable for > >streaming. For instance, in section 6.1, in the applications > which use this > >type of media type, the authors need to clarify this point. > >How can you design internet email applications in a scalable manner > >with real-time encoders which need to adapt reference frames > >on the fly depending on the ack from the player???? > > > >I believe that this document needs more work. I will be glad to help i= f > >requested. > > > >Regards, > >Injong > > > > > >-- > >Injong Rhee, Department of Computer Science > >North Carolina State University, Raleigh, NC 27695 > >Home page: http://www.csc.ncsu.edu/faculty/rhee > >Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 > > > > From rem-conf Sun Jun 18 12:46:23 2000 From rem-conf-request@es.net Sun Jun 18 12:46:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133klG-00002Z-00; Sun, 18 Jun 2000 12:29:38 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 133klF-00002O-00; Sun, 18 Jun 2000 12:29:37 -0700 Received: from dumbo.fokus.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id VAA16606; Sun, 18 Jun 2000 21:26:58 +0200 (MET DST) Received: (from mis@localhost) by dumbo.fokus.gmd.de (8.8.8/8.8.8) id VAA12822; Sun, 18 Jun 2000 21:29:11 +0200 (MET DST) Date: Sun, 18 Jun 2000 21:29:11 +0200 (MET DST) From: Mikhail Smirnov Message-Id: <200006181929.VAA12822@dumbo.fokus.gmd.de> To: end2end-interest@ISI.EDU, int-serv@ISI.EDU, conf@colmar.colmar.uha.fr, rem-conf@es.net, qbone@internet2.edu, diffserv-interest@external.cisco.com Subject: QofIS'2000 - Call for Participation X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear colleagues, please take a minute to look at the programme of the 1-st International workshop on Quality of future Internet Services: http://www.fokus.gmd.de/events/qofis2000/html/programme.html The workshop is organised by European non-profit Action COST263 (http://www.fokus.gmd.de/cost263/). I'll be very thankful if you could help us to disseminate this Call for participation as appropriate. Many thanks in advance! We offer 28 carefully selected presentations on Queueing & Scheduling, TCP, flow & congestion control, End to end, Traffic Engineering & QoS Routing, QoS Measurements & Measurement based QoS Mechanisms, Fairness, Adaptation, Traffic Classes & Charging, Resource Utilisation & Performance, and the whole day devoted to Internet Charging (Architecture, Economics, Network dynamics) and Keynote presentation by IETF Chair Fred Baker, and 2 social events. And all this in the heart of Berlin 25-27.Sept.2000 If you consider attending the workshop please register early at http://www.fokus.gmd.de/events/qofis2000/html/registration.html Please note that we accept on-line registrations only UNTIL 04.Sept.00 - thanks! M. Smirnov COST263 Chairperson PS. Sorry for any duplication of this message From rem-conf Sun Jun 18 16:15:41 2000 From rem-conf-request@es.net Sun Jun 18 16:15:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133oDH-0002r1-00; Sun, 18 Jun 2000 16:10:47 -0700 Received: from 24.67.38.150.sk.wave.home.com (dns) [24.67.38.150] by mail1.es.net with smtp (Exim 1.81 #2) id 133oDA-0002qp-00; Sun, 18 Jun 2000 16:10:45 -0700 From: "DomainPromoters.com" To: Message-Id: <419.436695.75573345info@domainpromoters.com> Subject: DomainPromoters.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Sun, 18 Jun 2000 16:10:45 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Domain Promoters.com "A Great Campaign is our Domain!" _________________________________________________________________________________ This week DomainPromoters.com is proud to announce the sale of CashLend.com for $4,800.00 Remember, big money is being paid for good domain names. If you want to sell your name, you must promote, promote, promote! Don't just list your names on brokerage sites, get out there and sell them! DomainPromoters.com provides you with the exposure your name needs. Visit us today for free consultation at www.DomainPromoters.com Yours Truly, Charles Prongua www.DomainPromoters.com You are currently suscribed to our weekly mailling list. If you would like to be removed. Please reply to this email by typing "remove" in the subject line and we will take you off our list. Thanks. From rem-conf Sun Jun 18 18:53:06 2000 From rem-conf-request@es.net Sun Jun 18 18:53:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133qhn-0004wk-00; Sun, 18 Jun 2000 18:50:27 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 133qhl-0004wa-00; Sun, 18 Jun 2000 18:50:25 -0700 Received: from kangaroo (dh304.kansai.oki.co.jp [10.173.3.204]) by titanic.kansai.oki.co.jp (8.9.3/8.9.3) with SMTP id KAA94636; Mon, 19 Jun 2000 10:49:29 +0900 (JST) (envelope-from fukunaga444@oki.co.jp) Message-ID: <00e201bfd990$fa880740$cc03ad0a@kansai.oki.co.jp> From: "Shigeru Fukunaga" To: "Dr. Injong Rhee" , "Stephan Wenger" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> <10006161848.ZM12779@unity.ncsu.edu> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 19 Jun 2000 10:52:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Rhee and all, Thank you for your comment. > First, > as Stephan pointed out, we need to clean up the language. Many parts are > written in a very confusing manner. I will list a subset > of things that I found confusing below. Read on.... We cleaned up the text and will release the next version. > Second, this draft is only specific to newpred, but it is still called > profile for mpeg-4 audio/visiual streams. With this title, I suggest > adding other ways of accomplishing the same affair, in particular, other > feedback mechanisms such as retransmission and even for forward error > correction. This draft concerned with MPEG-4 audio and visual. Not only for feedback channel. The description of feedback channel is a subsection of this draft. > Third, it seems to me that feedback mechanisms, especially the > types of feedback that this draft specifies (NACK or ACK), are > very generic and can be used in many places. They may not > be specific for newpred only. Wouldn't it be a good idea to > delete section 5, and discuss a more general unified > feedback mechansim. I believe there was some drafts on > retransmission and feedbacks some time ago. Can we try to > extend on that? I am willing to work together on this issue. The target of this draft is only MPEG-4 tools, which syntax and semantics have been defined in ISO/IEC 14496. In MPEG-4 audio, vidual, and systems, there are some tools using feedback channel. We would like to define the RTCP only for these MPEG-4 feedback tools. For the moment, only NEWPRED is the candidate to use this new RTCP, because we got no request from other feedback tools. Again, we would like to discuss about only tools defined in MPEG-4 standard. I understand that re-transmission and intra refresh is good techniques for packet loss. These tools are workable not only for MPEG-4 but also H.26x and MPEG-x. I think it is better that these tools will be discuss in the generic RTCP. The RTCP definition of our draft will not prevent the feture discussion of the generic feedback tools. > Fourth, discussion on congestion control in Section 5.3 is not > convincing. It seems that the authors are confused about the > issues of loss recovery with those of flow control. They are > orthogonal issues. For instance, it seems that the authors > believe retx causes more congestion. This is not the case. > retx is a recovery technique, but not a flow control technique. > Instead, you should argue one technique gives lower or higher > bit overhead or not -- which is a totally different ball > game. I'm sorry our text in Section 5.3 made confusion. If you think some text is not appropriate, we can remove them or revise them ASAP. We made our text according to the results in Adelaid meeting. In Adelaid meeting, the chairman of AVT WG clearly indicated that re-transmission may cause another congestion. So all proposals of re-transimission were required to include the good congestion control. This is the problem of re-transmission. Not of our draft. If you want, we can remove the text to indicate the features of re-transmission from our draft. > Fifth, Does retransmission have more bit overhead than NEWPRED? > It seems that the authors believe that. I don't believe that > this is a commonly accepted statement because I don't see > any evidence or proof for it in any other literature they > publish...need more extensive testing to say retx is worse > than newpred. On the contrary, my experiments suggest that > retx and newpred use similar amount of bit overhead -- of > course this depends on the amount of motion present in > the video input. Inaddition, why does retx cause lower > coding efficiency???? We don't want to compare the NEWPRED with other refresh tools now. These technical comparisons have been done in ISO/MPEG meeting for many years. ISO selected NEWPRED into MPEG-4 visual, and we would like to use the NEWPRED over IP. That' all reason we propose RTCP in this draft. We don't want to discuss about the details of re-transmissoin. We will revise our text not to refer about re-transmission in the next version. > Sixth, the authors need to say that in order for newpred to work, > newpred needs real-time encoder. Thus, it MAY not be suitable for > streaming. For instance, in section 6.1, in the applications which use this > type of media type, the authors need to clarify this point. > How can you design internet email applications in a scalable manner > with real-time encoders which need to adapt reference frames > on the fly depending on the ack from the player???? Yes, you are right. NEWPRED needs the real-time encoder. The definition of mpeg4-newpred-upstream-message is defined for real-time communications using SDP. Not for e-mail apprications. So, we will add some explanation in the next version. Best Regards, Shigeru -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 From rem-conf Sun Jun 18 18:57:49 2000 From rem-conf-request@es.net Sun Jun 18 18:57:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133qoA-0005Pz-00; Sun, 18 Jun 2000 18:57:02 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 133qo9-0005PT-00; Sun, 18 Jun 2000 18:57:01 -0700 Received: from kangaroo (dh304.kansai.oki.co.jp [10.173.3.204]) by titanic.kansai.oki.co.jp (8.9.3/8.9.3) with SMTP id KAA94816; Mon, 19 Jun 2000 10:56:32 +0900 (JST) (envelope-from fukunaga444@oki.co.jp) Message-ID: <00f701bfd991$f495b340$cc03ad0a@kansai.oki.co.jp> From: "Shigeru Fukunaga" To: "Dr. Injong Rhee" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Stephan Wenger" References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de><4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> <4.3.2.7.2.20000617010835.029cbb60@mail.cs.tu-berlin.de> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 19 Jun 2000 10:59:08 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Stephan and all, Thank you for your clarification. > Newpred typically uses MORE bits than a well designed re-transmission > algorithm. Re-transmission actually restores the signal completely > in the most efficient way, because only those bits are conveyed which > were lost before. But, and that is the critical point, re-transmission > induces substantial delay, whereas Newpred does not. I didn't know that a well designed re-transmission does not use large bits. So we will remove text about re-transimssion from our draft. Best Regards, Shigeru -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 From rem-conf Sun Jun 18 19:12:05 2000 From rem-conf-request@es.net Sun Jun 18 19:12:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133r1q-0006ZB-00; Sun, 18 Jun 2000 19:11:10 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 133r1l-0006Wz-00; Sun, 18 Jun 2000 19:11:07 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id LAA06081; Mon, 19 Jun 2000 11:10:34 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id LAA27405; Mon, 19 Jun 2000 11:10:34 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id LAA08859; Mon, 19 Jun 2000 11:10:33 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id LAA77119; Mon, 19 Jun 2000 11:10:33 +0900 (JST) Message-ID: <022801bfd993$85b03200$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Dr. Injong Rhee" , "Stephan Wenger" , "Shigeru Fukunaga" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" Cc: "Yoshihiro Kikuchi" References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> <10006161848.ZM12779@unity.ncsu.edu> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 19 Jun 2000 11:10:21 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Rhee, Stepha all, Thank you very much for all who sent us comments. Although we need a little more time to make a complete answer to all comments, here is a quick reply. - The authors are now working on the upgrade of the English quality. The text will be ready in a few days. - The RTP part of the I/D is NOT specific to NEWPRED. ONLY RTCP (section 5) is specific to NEWPRED. Several companies have done cross-verification tests (4 companies for Visual RTP and 2 companies for Audio RTP) WITHOUT NEWPRED. - A new retransmission scheme other than NEWPRED may be valuable, but it needs further discussions. I feel very hard to add new retransmission scheme, or any other new technical items, now without having enough discussions. - I agree that we need to discuss now how to treat NEWPRED RTCP part (section 5) of the I/D. Not only the proponent's voice, but also others from the reflector should be considered to make a decision. - Stephan's proposal on the procedure to defer only NEWPED RTCP will be taken into account for the discussion, although the procedure needs a confirmation. Any ITU-T experts? Best regards, Yoshihiro ----- Original Message ----- From: Dr. Injong Rhee To: Stephan Wenger ; Shigeru Fukunaga ; Yoshihiro Kikuchi ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT Sent: Saturday, June 17, 2000 7:48 AM Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > > > Hi All, > > I would to add some comments and express some concerns over the current draft. > > First, > as Stephan pointed out, we need to clean up the language. Many parts are > written in a very confusing manner. I will list a subset > of things that I found confusing below. Read on.... > > Second, this draft is only specific to newpred, but it is still called > profile for mpeg-4 audio/visiual streams. With this title, I suggest > adding other ways of accomplishing the same affair, in particular, other > feedback mechanisms such as retransmission and even for forward error > correction. > > Third, it seems to me that feedback mechanisms, especially the > types of feedback that this draft specifies (NACK or ACK), are > very generic and can be used in many places. They may not > be specific for newpred only. Wouldn't it be a good idea to > delete section 5, and discuss a more general unified > feedback mechansim. I believe there was some drafts on > retransmission and feedbacks some time ago. Can we try to > extend on that? I am willing to work together on this issue. > > Fourth, discussion on congestion control in Section 5.3 is not > convincing. It seems that the authors are confused about the > issues of loss recovery with those of flow control. They are > orthogonal issues. For instance, it seems that the authors > believe retx causes more congestion. This is not the case. > retx is a recovery technique, but not a flow control technique. > Instead, you should argue one technique gives lower or higher > bit overhead or not -- which is a totally different ball > game. > > Fifth, Does retransmission have more bit overhead than NEWPRED? > It seems that the authors believe that. I don't believe that > this is a commonly accepted statement because I don't see > any evidence or proof for it in any other literature they > publish...need more extensive testing to say retx is worse > than newpred. On the contrary, my experiments suggest that > retx and newpred use similar amount of bit overhead -- of > course this depends on the amount of motion present in > the video input. Inaddition, why does retx cause lower > coding efficiency???? > > Sixth, the authors need to say that in order for newpred to work, > newpred needs real-time encoder. Thus, it MAY not be suitable for > streaming. For instance, in section 6.1, in the applications which use this > type of media type, the authors need to clarify this point. > How can you design internet email applications in a scalable manner > with real-time encoders which need to adapt reference frames > on the fly depending on the ack from the player???? > > I believe that this document needs more work. I will be glad to help if > requested. > > Regards, > Injong > > > -- > Injong Rhee, Department of Computer Science > North Carolina State University, Raleigh, NC 27695 > Home page: http://www.csc.ncsu.edu/faculty/rhee > Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 > > > From rem-conf Sun Jun 18 19:41:57 2000 From rem-conf-request@es.net Sun Jun 18 19:41:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133rRo-0007YB-00; Sun, 18 Jun 2000 19:38:00 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 133rRn-0007Y1-00; Sun, 18 Jun 2000 19:37:59 -0700 Received: from kangaroo (dh304.kansai.oki.co.jp [10.173.3.204]) by titanic.kansai.oki.co.jp (8.9.3/8.9.3) with SMTP id LAA95634; Mon, 19 Jun 2000 11:37:31 +0900 (JST) (envelope-from fukunaga444@oki.co.jp) Message-ID: <004801bfd997$ae341080$cc03ad0a@kansai.oki.co.jp> From: "Shigeru Fukunaga" To: "Dr. Injong Rhee" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Stephan Wenger" References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de><4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> <4.3.2.7.2.20000617011918.029d7ea0@mail.cs.tu-berlin.de> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 19 Jun 2000 11:39:29 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Stephan and all, Thank you for your comments. > The interesting thing now is, that adding the MPEG-4 ES packetization > without Newpred concerns both H.225.0 and H.245, whereas, based > on the language the drafts, the added Newpred features would concern > only H.245. Maybe the proponents of Newpred want to comment on that. As Kikuchi-san said, this procedure needs a confirmation from ITU-T. There seems no space to indicate the RFC number in H.245. We have already propose to add the backchannel information for H.323 into H.245 at May. In this proposal, we could not indicate the RFC number in H.245. Therefore I think we will also have to add the text to indicate the RFC number of the RTCP in H.225.0. So we have to rush the last call WITH RTCP. If we decide to remove the RTCP section, we will have to wait the next decision of H.225.0 in 2002. This schedule does not match to our company's products. Would you please point out, if there is misunderstanding? > If I'm right with this assessment, then we can delete the controversial > section 5 out of the I-D and move forward quickly, in the hope to get > over with it in time for the H.225.0 decision in fall. Simultaneously, we > can work on a feedback solution in an additional I-D (either MPEG-4 > specific or not). This would be added later, but, due to the quick update > schedule of H.245, it would probably less time then two years. I think the RTCP definition in our draft will not prevent to discuss the other feedback tools in the future at all. Would you please tell us what is the problem you will get, if our draft includes RTCP definition? Best Regards, Shigeru -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 From rem-conf Sun Jun 18 20:42:20 2000 From rem-conf-request@es.net Sun Jun 18 20:42:19 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133sQP-00011w-00; Sun, 18 Jun 2000 20:40:37 -0700 Received: from tama3.tas.ntt.co.jp [192.68.248.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 133sQN-00011m-00; Sun, 18 Jun 2000 20:40:35 -0700 Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id MAA24596; Mon, 19 Jun 2000 12:40:27 +0900 (JST) (envelope-from kimata@nttvdt.hil.ntt.co.jp) Received: from nttvdt.hil.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/06/05/00) with ESMTP id MAA14678; Mon, 19 Jun 2000 12:40:24 +0900 (JST) (envelope-from kimata@nttvdt.hil.ntt.co.jp) Received: by nttvdt.hil.ntt.co.jp (8.9.3/hil-1.4b); Mon, 19 Jun 2000 12:40:20 +0900 (JST) Message-Id: <200006190340.MAA10404@nttvdt.hil.ntt.co.jp> Received: from Mary by cartier.hil.ntt.co.jp (8.9.3/3.7W/hil-2.2) with SMTP id MAA08667; Mon, 19 Jun 2000 12:40:22 +0900 (JST) Date: Mon, 19 Jun 2000 12:37:59 +0900 From: Hideaki Kimata To: rhee@unity.ncsu.edu, stewe@cs.tu-berlin.de, fukunaga444@oki.co.jp, kiku@eel.rdc.toshiba.co.jp, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <10006161848.ZM12779@unity.ncsu.edu> References: <10006161848.ZM12779@unity.ncsu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.09 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Dr.Injong, and all, I believe section 5 should remain in this ID. Because NEWPRED backward channel messages are definitly different from other feedback messages from following reasons. (1) These messages can not be used for generic use, because they include MPEG-4 specific syntaxs and semantics. And their names are "NP_NACK" and "NP_ACK", for distinguishing from other generic messages. (2) These messages are only transmitted between Advanced Real-Time Simple (ARTS) profile terminals. This profile and level indication can be transmitted in this ID "MPEG-4 Audio/Visual RTP payload format", at least in IETF way. >From these reasons, NEWPRED backward channels messages are meaningful only ARTS profile in MPEG-4. That is why the format for these messages should exist in text for MPEG-4 payload format. Best regards, Hideaki Kimata On Fri, 16 Jun 2000 18:48:49 -0400 "Dr. Injong Rhee" wrote: >Third, it seems to me that feedback mechanisms, especially the >types of feedback that this draft specifies (NACK or ACK), are >very generic and can be used in many places. They may not >be specific for newpred only. Wouldn't it be a good idea to >delete section 5, and discuss a more general unified >feedback mechansim. I believe there was some drafts on >retransmission and feedbacks some time ago. Can we try to >extend on that? I am willing to work together on this issue. ----------------------------------------- HIDEAKI KIMATA NTT Cyber Space Laboratories Email: kimata@nttvdt.hil.ntt.co.jp Phone: +81 468 59 3124 Fax : +81 468 59 2829 ----------------------------------------- From rem-conf Mon Jun 19 01:33:15 2000 From rem-conf-request@es.net Mon Jun 19 01:33:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133wuM-0004M9-00; Mon, 19 Jun 2000 01:27:50 -0700 Received: from research.gate.nec.co.jp [202.247.6.217] by mail1.es.net with esmtp (Exim 1.81 #2) id 133wuK-0004Li-00; Mon, 19 Jun 2000 01:27:48 -0700 Received: from luke.dsp.cl.nec.co.jp (root@luke.dsp.cl.nec.co.jp [10.56.47.3]) by research.gate.nec.co.jp (8.9.3+3.2W/000323) with ESMTP id RAA27710; Mon, 19 Jun 2000 17:27:35 +0900 (JST) Received: from kero (dhcp021.dsp.cl.nec.co.jp [10.56.44.21]) by luke.dsp.cl.nec.co.jp (8.9.1b+Sun/CL-000424) with SMTP id RAA18040; Mon, 19 Jun 2000 17:27:34 +0900 (JST) Message-ID: <00c901bfd9c8$35be1700$152c380a@dsp.cl.nec.co.jp> From: "Toshiyuki Nomura" To: "John Lazzaro" , References: <200006171759.KAA06748@snap.CS.Berkeley.EDU> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 19 Jun 2000 17:27:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear John and all, Thanks for your comments. > [from page 19, 6.4 of draft-ietf-avt-rtp-mpeg4-es-01.txt] > > For SA, the string after "config=" (i.e. the > StructuredAudioSpecificConfig) can be quite large (two example streams > on SA primary author's Eric Scheirer's website are 27 kbytes and 1.7 > Mbytes respectively). Rare will they be under a kbyte. Is SDP happy > handling data chunks this large? I think it is not happy for SDP to handle such large data. Such large data should be transmitted by the other out-band means. Otherwise, the config data for SA should be transmitted by in-band mode, where the config data is multiplexed with the audio data into the RTP payload, due to the large size of the SA config data. As described in draft-ietf-avt-rtp-mpeg4-es-01.txt, this can be done by setting the cpresent flag to 1. If my understanding is correct, I would like to propose that the config for SA is restricted to be transmitted by the above in-band mode. > [from Page 1, 1.3 of draft-ietf-avt-rtp-mpeg4-es-01.txt] > > If I understand this paragraph correctly, for SA_access_units this isn't > true in general. For example, an SA_access_unit may set a global variable > to a new value, which is then references throughout the audio content > to make a macro change in the performance (for example, set the > amplitude level of the audio output of an instrument). So in this sense, > an uncorrected error in an SA_access_unit can essentially destroy all > audio produced after the error, for the rest of the performance. I think re-transmission can be applied. If an SA_access_unit makes a change which influences the following SA audio data, the SA_access_unit indicating such changes should be transmitted repeatedly. The number of repetition will be dependent on the network condition. I would like to add some sentences to the current I/D in order to clarify error sensivity for SA. Best Regards, Toshiyuki Nomura, NEC ----- Original Message ----- From: John Lazzaro To: Sent: Sunday, June 18, 2000 2:59 AM Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > > Hi everyone, > > I had a few quick comments about > draft-ietf-avt-rtp-mpeg4-es-01.txt, with respect to using it for MPEG > 4 Structured Audio (ISO/IEC 14496-3 sec 5) content. For those > unfamiliar with SA content, its a combination a tokenized C-like > program, contained in a StructuredAudioSpecificConfig, and > SA_access_units that launch processes (called instrs) or change local > and global variables (either in a direct way, like "change a to 12", > or an indirect way, like "fill this table with one cycle of a harmonic > series with these weightings"). The StructuredAudioConfig can also > contain an arbitrary amount of SA_access_unit-like data packed within > it. For a gentle introduction to SA see: > > http://www.cs.berkeley.edu/~lazzaro/sa/ > > While I've read over draft-ietf-avt-rtp-new-07.txt as well as > a recent draft of the Systems FCD for ISO/IEC 14496-1, I'm not at all > a transport guy (but I do see Larry Rowe in the hallway sometimes :-) -- > these are just a few things that caught my eye as I read through > draft-ietf-avt-rtp-mpeg4-es-01.txt: > > [from page 19, 6.4 of draft-ietf-avt-rtp-mpeg4-es-01.txt] > > > The followings are some examples of the media representation in SDP: > > > > For 6 kb/s CELP bitstream (the audio sampling rate of 8 kHz), > > m=audio 49230 RTP/AVP 96 > > a=rtpmap:96 MP4A/8000 > > a=fmtp:96 profile-level-id=9;object=8;cpresent=0;config=9128B1071070 > > a=ptime:20 > > For SA, the string after "config=" (i.e. the > StructuredAudioSpecificConfig) can be quite large (two example streams > on SA primary author's Eric Scheirer's website are 27 kbytes and 1.7 > Mbytes respectively). Rare will they be under a kbyte. Is SDP happy > handling data chunks this large? > > Also, a large part of many config blocks will be quite predictable -- > uncompressed tokenized representations of a program in a C-like > programming language. Does this have any cryptographic consequences? > > [from Page 1, 1.3 of draft-ietf-avt-rtp-mpeg4-es-01.txt] > > > Furthermore, if the payload of a packet is a single audio frame, a packet > > loss does not impair the decodability of adjacent packets. Therefore, a > > payload specific header for MPEG-4 Audio is not required as same as one > > for the other audio coders. > > If I understand this paragraph correctly, for SA_access_units this isn't > true in general. For example, an SA_access_unit may set a global variable > to a new value, which is then references throughout the audio content > to make a macro change in the performance (for example, set the > amplitude level of the audio output of an instrument). So in this sense, > an uncorrected error in an SA_access_unit can essentially destroy all > audio produced after the error, for the rest of the performance. > > > --john lazzaro > > ------------------------------------------------------------------------- > John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley > lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro > ------------------------------------------------------------------------- > > From rem-conf Mon Jun 19 03:35:12 2000 From rem-conf-request@es.net Mon Jun 19 03:35:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 133yrc-0006LM-00; Mon, 19 Jun 2000 03:33:08 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 133yrZ-0006LA-00; Mon, 19 Jun 2000 03:33:05 -0700 Received: from kangaroo (dh304.kansai.oki.co.jp [10.173.3.204]) by titanic.kansai.oki.co.jp (8.9.3/8.9.3) with SMTP id TAA05150; Mon, 19 Jun 2000 19:29:56 +0900 (JST) (envelope-from fukunaga444@oki.co.jp) Message-ID: <029e01bfd9d9$abbd3e20$cc03ad0a@kansai.oki.co.jp> From: "Shigeru Fukunaga" To: "Dr. Injong Rhee" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Stephan Wenger" Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 19 Jun 2000 19:32:28 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_029B_01BFDA25.1A56BB40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_029B_01BFDA25.1A56BB40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Dear Stephan, Dr. Rhee, and all, We would like to revise the RTCP part of the ID according to your comments. Would you please check the new RTCP text? The revised points are following. - We removed all text about re-transmission. - We added the supplementary text about the upstream message of MIME registration. - We updated the English quality. If any problems are remained in this RTCP text, would you please indicate them as soon as possible? Best Regards, Shigeru -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 ------=_NextPart_000_029B_01BFDA25.1A56BB40 Content-Type: application/x-zip-compressed; name="draft-ietf-avt-rtp-mpeg4-es-02-RTCP-r1.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mpeg4-es-02-RTCP-r1.zip" UEsDBBQAAAAIAAOb0yhDLQgSeJcAAACUAgAqAAAAZHJhZnQtaWV0Zi1hdnQtcnRwLW1wZWc0LWVz LTAyLVJUQ1AtcjEuZG9j7FxbjCTXWW7bSdYJ7mBjGxCXcFgQdNvdPdM9s+vdjRIY5uIdvLMzmeld O4qtobr7dHd5q6s6dZmZdvaBB3hDCAQSPIAgUt5ASFzeiAQPeQQRCYKIxEOQ8oR4QpFQJLD5/v8/ p259mV3bIgLRu71VXVXnnP/81+//z6n9+t89960v/+mP/Eul9Pls5anKu+99vPKx3LWn8H3pCfPj 2Urlx3FOP99977336NJP4kcD35fxfe//P/8rPu9Cch/5xJNl8bNcv/Wrf/Dv3z0cP/tHv/l05eWf /fNvruPa13DjOXP/N/Cllr9rdOMf8P0ItcP3o6QieOgKjj+G49M4ruP4cRzv4PgDOL6B4ydwjHH8 Phx/GcdncPw1HKvUL46fxPErOH4/jn/8BKtd5S9wfB7Hrz4h438Fg38Kxw18j7tHaurMvMAZqGEQ TpyYDurgaPfV5qbaSgZusHbfjRLHU1EcamcSSVtWa7Sl85/B9zX3QdIfu2t3g0kSOmt7yYPEd0bO 2oETR4m79pqLnp1KlKRt8Tyd0zzu0rheaxDEFb5G/DoZuyMdJsp2VMGB7hH91yvuiM5pTgduPwyi YBir14NwoG601iv+z1P/v/6vX6dx+PyH//6n/+wf/+oJPv/2d/7yr79pzn/py1/6J5w/ZWii4099 TI7/dVWO9Hl5ff33zWllmfzpypPf+Ntv/F7rR5/9rd+B/Bvf/ZMdXPto6dofYqA3jbxozKlpe1ER mf12RXThq/iSL/laRfjxN/j+UEV0hnj2zxWR7bcrwod/w/cH8f1ORfr+z4roxqdLMn8B3/3d7p7a 92Md+jpWO6EzjPneT+DbDaKx23PW7u5urx0+cEV+uBTjUrcrPPnFihyfM8f/eEmOv/LJp5m2iqFx 0fFTz8q836fuPfOsTIfIJfZ03djTFSvASmZb9FHm8vWKNPqs+U3nZEenR/s7p6/e299JObSF4118 v1TZrNzA91plB/9u4dvkX3uVlG27/sj1tQ5df6S6TvRA7QVhX1/5PPFv7IaBMhahmsrwVCl15UqR 7Vf41ix54CoxHDwNzl+5shP0k4n241tqQM81XR0Pm85Z3AzjaXMy1aPNpo6a6+1WfBFfKdsKOoHo rlwRYvwgdJWYIW5k8sT92+5AOxhbrJPG7nZx+cCZqY12Q3XW19dBcrX6+IKqVqsnsRMnkQqGKh67 kTrQk6Ba7dLpwExO4dzxU01sMktwZUA3XF8NE89T/cDnIf2+VuduPFYOLk7D4MyN3MDn/k90P8a5 aq/Tr+O97c5657r6wpNvtVS1WuwdA4boJwgfkNwsIYZKrS6RrqqR6dQbypWOnKgh5OKn7XMUBsk0 akGesUafYFWAnkNzXU3AW8eLAjVwwSq3l8SLyHGiElfQ4aKJsHLk2p05nssiUg5GunAnyYSmFrkX ahL48ThicomGnlbJdODEetBQoZ56Tp/O0DDoRYGncV31Zob0HF0knpmK3YkGQbHIyZlCHNPQdWjC gUqijI9NZYmNMMpQh5rECP0BZ6EsGA4N+i5zSk/McGCaTw2uEl9ID9D9KNRR1LqqoEBaeWAdTauf hCGpUZkzfbTH/Jx+H40wEVA9juPprbW18/PzFplSKwhHa3Sy1nYHTacHUTh9MBnWVByipJsnY2cQ nKsdN4TKwa70Iw8WccvWOJ54rap8tsywZasY6KgPzUDf83YXsXBJVftOCB6ONB1npD2gNm+QLGlj lD0oqNgljAJ/RWtB+HF3+2iBRUNR+XE1wZwwBkZNfLYx6FeMWbNtPblnSJkm4TSA1EHBgDnjzSDj 6RRU7fti/dFU992h23eok8ZCz5ERKaqd7wl8df04gAoHhin9BzpmMsgYxR+Ab8VxMmYlTB0JllqP tTOAng1d7Q0i3MMMhSFkl6YH9EUNh6EzIqFwfypMPA1LzHHK0E6theulWdjeBmwupQGsAGQ2hhAy CBIpD79MHi21B7vzvNmls4cAnMHANWzfP9hV8WyqYYwj8j/mQSI/Y5M62TkSYjIGLtOsgsT0ED6T JCUytwpNXhifZ9rsw8JgkLAqVavtVlu9Pp4t1AaSk1FM+OGBHvxctWrlVzYJazDZ0CWzFb7A8apz uD7McAwjfpQpQRi9TAnIutl9skKmClrWSprv7dZGZ0OBiAnJCV4iSDx4VE2dQuz6wplMPXh++Dso CXDCwonR0xN3NI7ZXUekRauCLj/vBzEoBAwQD37YextUqh1m0RQ+K8o5ipNZFGu0W/DQF55Xdw+7 u8e7e+r0WA83r19bv3GzfaOj3hyrJ164/uJbCqGLBrjd6mxeaymSzSrzLTOJY3mQkNaT8yIdi2Z+ fxwGvvuOWFve58wWUH0piSQIpkuDIbHb56lnDoAxBvO+70TQddIzI/G+B0mBeKPSsDK/74HjhlIn ioK+K1QyJimbiBXMgGCV9jRHTwivYI2w3HOjFvjrY6g+BUVQIMMuc0B2FpaTBXc00EEqBzgbhFH0 p/0x4ycdhngWodT1XETiGckvifHjHTuz0hNkAQHU13gYMrAIx/x880NihreDc32mw4aKwXm4E5dF 5UZRogGWxvbu2DnTaganJ/wGU0IOn1aD+wEey2OQBRCUUEcQwbqKbo/Ca7vVKXno+fbVavEJAqPq TM77Acs6imHvDtJKFvKEoI+vz8vBcKgBdEH+LQUcPrZt9ZDkSVxuqE/LnTL76cYk8WIXrgAhOUTs CB14fmAFNhmxSjk0ew6hC+mcGuq431pkAjfXN27cEBPokAnsG2bS7M5JdqHjj9jN83AxqVgwgY3g Gcz8td6UVYYnay8e9AjR2gBW7O7MAQwS+4TDJcgGOdMYxATuGnYORRglTkhWmNqY400CgCxmSnMY ava2k6Dnwi/anoTxeeaBYDj8hB8m2D2nsCXhkA94nTrBI1NiJ9pBobYWGhYDZ99qzlkJlzAEKVge BbklQa/RUicu0RPxv3OqRt7cAPXlbHRjGSJyQ6fniWWABHhU+CZYJrSnzzNDJiEpkMyOnGd+erDL LYP5FswbYPeBCUKEuh0ieYTLZ2zZBpxAJ5F3OR4CaETSS926Sp/POHPVphiF5KClDn32HGLRcElw rA6hHXjICNOd6IHrKKSw5+QGioRSh32HAMpAj0JnIFclbQPv5zybhTQ9nIDBUIDMICVaLWDEPJAo pKpElKcvXBIFRT8JsyWHjYDPaZdoFJExSsBID/dFwaYhrAqGYDzuRDs+8y+KSiTxFAJuc4mTXhYp RYPZBMZkVhy7TPyBGgq/rffMQ2PWThsdRQ+MW5N4AD1B3L/eVjb0tNc6xCLwmHLxM5I8+vKm0gS0 stNQU6gpXGUagPtBGCZTk2waTfMCBAJSfr9kNTGDJUZQHuxxMLvU+Jl3ZmyixAxnh29YLYm0TeN4 4gHh8qO1/aOcKWLG55osIKLbosH2bkvVwI3Oxpp4L5PedNa6Jw1203Xom8MqdA606yMeX8DzLkhF 5lB02XEsjYJoQNxpUUpWkJeRsTHuOaE1Hl0nxCGnEoYHKnK3pXRrhHQM6ueUBL1Czq0cYkjle6lc DQwp6UemZyVBs8FH892Q0PvBZBL43my59Auyf2zBY07gE+59uHLnpKrd2lDbAfMiNA6x0FpymxXQ Rx5g5EPA5oELeyD58eUU/XAVC8GPHC+FX8YGA3fI9ZyYE8ooa5Z3FLmsN5lOg5ByGqhYH77fjSZG geAQI+MQkQKQObrvgBFRkPgD9HAnOG+SUIllxYl1ASgi6lUdGBR1oWp3troHdeOaJYeP9BcT0qK0 ygeRTwVuKpPepkRQisd9M3LvFXNT4/zOBU54jjGDaEKh0ZLYYpBPjzdZrShYW2jKOu7Px3WbZRPt BugVxs1VFYyZiEqJ3theBFYtqptI9hWP8zG6nIEVkyuA6L0kpKEmMhKDnThMhFgxg1Te7EtdYa7V NHEDYuqsYAYlSCNEugl1m3cGCLaaqAIzCei4k6njCl8GMOuBAxMz4c0ZvO30SfXSjDtnZwJzLBmp J7MWFxTr1uyV7ZA90oQvJuAgxIgpRyBSPH4mo/mpS8KxuTABLFVuuE5XqPpEsOOTYEJ8C5GiJp4T GjUr1fPSXF8MaVHPc9BXvF5axGPXCheEdBT6UezVsKlh8KrMLFMmAl5xobeYCrbElH5ARR3PkwDL to+5gHMxqwU9cj52EX9MmbCl9iQrwJwDaCdN9MyF96GKbq6vfCfFoQFGOW/OJewxuYKJG5MBW70G 6HKA9aRK6VIB2oko7yZVyelLPM+khcWLiKRkPaQXnEv/BVkC8yPQdrNKGo/LBTfO2XNSp2Fwz3NB NBUY0szYVNDZyfR1GDsmIFCNgupFBQefKsF8gBR6c1oFoDB0PTNDjnQ1CtilSLM1OKNSwUAda/zq uujjxOVa1ZG0b6i7u68fHe/usJrWTXGv06JAxLiWCooWPxYwtBRjHugZQQlEvasH9066VxtypDyW zo93P3dvH73T+cntrTt30hP7xMntw3t3drKzrOX24cHB7t0dboxetz5/VbzB1cOj7v7h3a07V+dx fVblowAXIgxwDCgVFY/3tpuddvsmLyrxhDda7EuPWJy2YpWZbLmmbWr8kVmpKhaZM6dsO8rS0WJ/ ZB9cUd0qg+NclhotrlBmI4lntGZCwdwCQJqBgJQiQOG8eAYLmgRntG4z5J/WdyBoOxe5MheJeTuY 9BjPQC2G7igRfLK2Kw9xlcNUqSZwNWlGHAWCNiRM51pCCoJd+Nz47J5ZBjHKJnNkp80TJTfpCIt1 eVxAt0hrdb3VabWhSbgTs9OLrvKyz8nh2v7utmpvbt683uysrrOoN19SB7vHr+7uHR4fbHUV1V3K DV7ZeKW9sdExhZmb8w9wj5s3r8kDmy++VaekzVg7/B3IE1xvBJPnWmNOtiY3YJbCDthDElvT5QjW LcoGNnLXjKehdBxOICatZ9G7NuFJ71hoGNnepThNVf51Nf9pL7jWWXBto7qOZztqQ22qa+q6ekXd UDfVY1yrvtz8gH+qD+9/pvPw6OEbD5Xa3gZNDw8eMm1HXaHxoaHVokrlJ5MeeGM/D0kQHwYdavmH 1l8hgsl0xTMP1W3WlA+ZlHKRHiidF8ZPTo636woaiggAZcr4QaRUX/7MB/xTZAfDBFo755zBULBd oiDKtwANqxiqVAuflQ98+LN4Hx9RLttLMQIY91/rzWKqkLgjeN/6kl6OxE98cHou7eHxtGvR5xYk YwO4cXIDRpnmA7lcrsOX0FDlnvYo2mj1vDrZ/Zz9Ad++dbz1C/vb6oX2i6pJgTcL1wsitA33DBHa 6l6ki4tOxVXnufbVqhGN6hJqrB1167estARIupHBK+mqh0dZZhSxwG28u7x8sG/QqbS0NU6z/GWC KqPome9MZBROXE2hbKpD6kkqOlxewsPNYNjs8RKpdnxbJdy81qAVZamIqB03gtX245QenpQB9D2d TSS2K+WzR52MtrQW+y5OUOKlJOBZ5KM5EFyen4Ng5PI06hlKKRJXCsD5Qr9AmpDWIQKfFThTJA6d uxfAdrSpSdXeqBOgu6V2TFFoR8tSspCaRntB5FnwPbEx6S7HpFtq3++H2ixd01KayWO1Yxacucph K/y0akGRPYx5iYkeBF5NQkq6JXdCJsYVHX7IFEIcWuwZBLQ6AggJFgAgJrq1sDkTeeCED2AHtQMz R0KLE7nWM3KRdUGillZ5wKy+I1uElOdEcd4Aa1SMoDJLdq0upYf7h0c8XNfGShkpC52238hIZoLk VEAwPUMzNUIzpSEnvadcKvEoP2jaVniSaxSUwBkb4aoXL5QMitOY786INA/CjYtzKNQR2KIseQi+ NEwuTemssF2uL2E35b6OAY5mOXHqOb7OSlBDq1Qw1rNgekoEnbpWbVQN2C/xXdkh116bf+IUswm8 RLAAWOAPojrGSAxXk0kidTILk9DN+TjwtH24aIRAtch8ZAiqgyleI3KHlmkNZtgpcZp6epX21J0G w1NehJZdDEc0v1rd+NlWrjFX5tJUGs054+Odb8KihqiN5BbEePgqnrhZvOGyxXlguk5XD3I6xS1X K5YtQg7dEKrMXaX+K6fYBHGQ+kei3ctTIdCwBiFfzonGSmqipCeAlrbbXMTMBlt4kJoOUnaIzzi0 yymWpadTUbpTC5ZPtT8Q6eXmsJoyd8JLEjGVrCBICIuouYw+qTXkdNP0ljP/1M+4vIVo6CReLM6L Hr65/trtdxrqns8Lc4kcCroKG18WLmgDVVq+4uUW2niVXXEK68a2KHC93lINk4E9Lt01pleqMQTF G5S8EFmEivPLDByOFpQ3VPvGjbS8sdHqqL3CWuSqyka2lq4H/yerEma9OPC84JxUzSzt8iq8jeyl 9fZqtdbm1R/V315lu49guEqqX4S5xFcZ4NHTI9f3Xdn5WWZj7e0E3sUZxjpM7wnz6sS20l3DVusL iHNQSUGWCYQWIu7OiO+mysjz69TJCVCQDqgckVvV1Re0e9aYZ46q+TqFnRpmkm2kWkUNbQXR5Dcz SmijtcT2S30O1YBHTjjIcDIkWugO89qoqy1LQ1p4FMDtubGspzgU4sJ0uT23qsKs2YToEScsX+Cs clLMGQv3lS2k5RdnbCGM+Ft0smlUIvrNMhUFG7spTZvtSg5HbvBgAeKomSU9CVQDWzrLvAyrXlGE PL7RIeLTNeLToq0iWVn2MbhG8qN1PwFvi/rjbWKkuFQmpIQjheCYHq3/FRA1CZuWdDwnHGmzp5ye nTrxuHnQvdcC8YVRTCHrkcjN6vCW5HhcYgLV9mlo9si3NS002ModBYpb1eVuoWY8mNmVmYJ6qec0 VPG2XDUbWIkAc/0OW6zcrVcvMQ2OlkW7g8LAHcoKjTUPu0Fqrpqqaqv8WFD2MvPPNIR7p4xOT0l/ T7noeSqN6IEDHY2ljXS5B2dof9er3bIAzGg10y9fTHuDi7L7OQnuEIid+f1TSUNsdxm9o6B3yh6w VkeO9ahV4+9B0TgNRwwv0uBJV1ZCyKUSl5Rtjrn5BJCaEhyz7ArnjWFsNFdCqIX61P8p73U8jSGE JGQ9IGo0JQbc+SLp0BB8nalg/RXgs9HaULuys5odpF1TWQ5LqlW7fUL2VsGhFJ+0CTyxaelGvRU7 KGnnZEPumw2QtGaZbW/kZE62NL3P3ZDvf5dgGbMcrtqdt3JzniRMS3bnffC9eQCq/MJQEbQSSJ3b krdqLx7umb13yzfdkR5R0vw92kPV+HD2ULn8bskl2wTfxx4qNyr18T+6gSqdm8/7zQNC4lzoyEm9 VIy1Iliy8Yq9xvOq8AZBZ71zU/ypqQB3XqTy5HlkX9qY238/0j5tvyLBOGb+7HCXai3Ak1O3QjJv ghSqAjkYY9ypKfbIW2bZvonlm5WNuBbl5yujAXBRH5I3W7jyEyFk0q6Lsq9EKLX7J2muARIePWvJ KipLIY7cXAJzavcP01Bz//BOSoSEHfhJuyd7zvnZ7b9pTk5iSh12pC5fk84qp+KllwCuLGQ1WAFk P/XjsIh+UBnE5U34ZIADHfPG9iVqAm/RH+s+v2Hq5rVso9OkgqtA/QU5JOi7dBac7vSMMottlzR6 XgNds415hQ5SDLB5UV/b1wh02rexHyOWop6bdxSMspdyCZPREF7J8vlLiMl0xtP+CLK9FFFxopnt D+TV+1o8m5ok1iKFGEkE524Me5Zwil3r6uFobzwXZB3ZpZXbi1h0n48AAvPltoxDrx7et5XGGi0Y hOR96sxGux6UYS2TPM29FSDvGbC4jBxZe/plV1jSGhZyKs/leQZorFPFuyDVeddFU3ksr2RfdKaX B5F8Gu9P4c0iXrs5FdO2sUA5q8TpMBXn/F6M0SkM8IooQ0FoeW6z5abTy/Ne5mJ0O9v/YuyB98ud k7gVmM08HywJP3aTGcIeFR7KGW1ZyMXiREulG1bkQpN3dTI7TP+JD4Z5M8m7BBugW0K0DVEMu7/O jpSzJ8IZSAx0KhDBAN4sf4+XDUFsIWU4HbiR3SG7nrkAGyDosvb5ASkw8MrHoqSesv2W2gWEzCoA y/1bLikifO5GfSk9Ue04D+BEL/OvuQmuMNKVhSVulr0reXt3u2bCYrZsuE2ZUNER+fOTEJLoPyhY AosYYmmKIEjwWV305erChS6uspQVR+rOl6lOd6X0s/dKSL707mDezc2ZZGQDHeJb83L9g0XlIDS9 lkn5DPieedSCQufen9SS9di3+P6bvfMAjKLYH/8EkGKISrOXE3kSJAkkhC5KBymKFEWRciSBHCQ5 TAFRUVFRURGkidKLqIgUO4pKBxUUuzwFwfKk2Gk25P+Zmd3Z3bu9kAc8ff/3cy+f3Oze7OzslO98 57szsz43HpHvPlKRMHWLR9SvL5KxdZ6VecML5Xnlii203aFpcZKZNSTL+jGqLpru1xETx18/bpTu 0Y/rHUk/HpIfzg71D1k9F5dYDkqfaFqq0xX5uMEY+1VxMQnsCjhJNyjoAknOEG4lX30bQ59SInuM ejEOd15H9lc9All3tmPekmxp6tXSM66yZN8oTxpY84JKMSyujuhG060EJEVYVfwNWXpenjV43dsQ 5IYyMyP1MKtF657t1Eid4joptSYnQws6lpqI20urZdXWUIEp/zF6+nJQcC7tl5ZaTruvVeQjd7xo rpLUE9foauUemS19uAsc998/XGhN6/btHLuVy/6U9Sy/dst1G85ITPXU2l3hlPwoILfUJb0RTVV1 TZsppCc7Z+wH0EeuWjJHlIANmueqLlGeZl/9iAH7Ja0spS1iqZ3esiqfYNjVTeaJt5DogZ9yBFXt ZLX5f6lerxrBpkZR0ktUX1fIL9kaB25Ww7Bu1mXb/yvhyFc5spdk11ZbdV+KjZXub3ZRSVSCKLrH rpUgvt7IRPv3eLC9SaXZxFnqkjd7OsVKIfZGVUcnELX5xND3irFvxNop/lelcpoYS8EWka4Bdx5E /eqX6vKQfMhq3Zjfr2m1Yt3jvxf5I55f0mNKlSruRkt6LFaC2CnimwzuY/VKmjQlPZaQUOEI4yfT 5PjJNr5KQvE2ep842lf1Px6Z6C6501aZPmg0BxADV6nrFHQdjp3UKi+sNtld6tzHjygB7IiVKPLF Z5BfGDFKXv+oCuikhV9ClLzckZVXdZEFz50g9sGjqJAlv6kjld4j/uKVpG655BGlsX+JWREDjnTy Vj1XOhw5KUxEY/+C7lx8vasXWe9c2qu7CmpFcEA4ckizuybSzqcXP/MpYhmsmBOfoq8cNekpckUt Ww9T0yNdxlrv1FWzClJR1Dxa9wJFoQJrkK6lxMu5t4HEf2uycS0VFR1Kr1J+D2/R6LTeVb9a1M8N 0hrXS7MWK6rW27F9uyYBe5aikrceazElz4Aupaea8XxyrzBbPlC08kBq7bLHm5CQnpLqyko5WFTN De/uH4nIoSdBZwpM2Jr73bnoBmsolWWb1csmZXlGCbkmABfIURhy4J9ccDAyCPvRh7GARV9DBmvG 1cQcXmZ6VdEjzCKGjkXGIGIMmZ4y5ranRerZafUbefTs9Gq1rAeaStSqqRlcS42/jryYuZGcsB6U Y9km9al27NWPVo2T5gC3/i6H7v2l068CCcc+FeOY51/J9Dge8QjE3ko0/6q9EvnHOSZ/T786bndx FJssWwlNog5H1uTip2A1+XvylTcOngseQZdJL3YOlm6p5Zq/1nBwNTBAjf1UDYE3n7Td3Xmiklt0 gx6U10WPl4x8pOcMl4wx+jtFP5ewl5Awg7Eiy0dhxKSWEkYh1lUTEiJPa2Jmd7nP12PbQ2b8eGqS b+x0O2S33ME8O64qCqHCQHX0qm403t2UXsCJ1ZXqIsdP2icpU1TMR41qEKG1foZeiEUerW7C07dS XTeckRfTc4TMDIth2VnSqqeuGBGA3WzbtjE59icULirQqocyA8qlWRx7qb2csPpdqUdp7vl7Wp5T JtWg7B5y/l5k0TvOs/d0cXbrLgP+v528d4R7+Uvn7um4HcPUvSNNaTPFNbKu9ZdrHMkBhfbwKrxf 5jMHTgbmlhlW/KNNtwVqyljxCrWaQ2cPf9Gqb6TXlGOYNxeOOWsu5qQ5bt4OXnd2Ip/oqoG2cvFx e4SLlmUyb6ImvSUk9CjhbJ2jnWxjJgklNq4bGGxNu/m3515aGXes0y6Lm255bHOBfJbXTUuv11B3 cBpV661EZL2YE4WiDAGXRYxTleMxi/QMh8iSOkQ994tMK90iWPLCTBaIKry2lBucNaTQWpwrKy9c NNA1Y8A9bN//+UeoUC9HJQ0JWTdkZNn9autEKW3zXWuZHr+JCdZACHt9kzw5aDVMcuUqSallOOcX Wk/gZFDUpgI5Ata/PbcmNkQsYl1A/UTYBeXbUwrMiCTzmNUyLCQFvGMavWOmrOXQtT2hiTXnqbol R6ViYM9WdZsObDFrd6qTfCKoH4Z6o+YydySZ2TGqgKh8VOvPe8YUeCwW9pROtZyS2xoRGR1pkbgM CTc0lOmez21MANx3bkFWztCsgoh5Lk70kQYBe3qUX4ZYWlJBpMKSFKXBGJOAdYqVMhGl1jNAKmIM itd4kGWkO1t9acdrFduQF7XofLFrGOn1DFT+mhWnPAteFbrXtY9+wYBrEK3RGazWQZ0bzBwaKohs hS1/iF099doZH+OWQcWsxeazYpp8uh9xCyE5Ficnh7hNkPvJnbuk95hoa42mSjjTiy09MuKdB/ay WdZ5XhurtexW9KpbiS26du9Wy158q1d6byV6srOccYHSBmnVs6IClRuhgoCJp8l7T2y0JPW7Wfsk VbJ0+bvi8k5mjR897kmrYJ7+kK2CySLgUsFcA2d9Ms6sakVOq1SWmktIznY3M0vk7ZuFDmS4kde2 lfeY3Q1LzMcYJ+3E0L2smRpzpIaEZQYS87KGISwz+1pjxFwdKD3tpH5KKlLDepmHvFxETrtvQVtX vZfyLQ/u2w75D+eX7x/J07P3CMYp+z5v77DHz1o1yh7ZbVUcuTy0LlRqRnyy7iBZkx9sPdg3mvY6 ULrlCeVKGeCeAdJ/uKsNVLHwrvhot3JyEdvgQPdURD051Rb+2lqs3/yTRc5Lj/pYRJOUGcxVbz7Q fTi14L6xBNiTPzyL8qkalIVCKi+jk9iOjKq1ljqtRkVZyaXG2xZQQjN0EXVebGNFyQo2OjH1ip36 VNkOR4609wzIHRoM5egCl2ddRg36zvTJX8uHXaxMPXYyVlU/ZRa3hxNacQ0VuDVBn9vRWRuVMtrQ MYDczVbT7VvIMYNU2ix7QdVka0lG3bvPs3oFpEl+0D7Rfg5jP6yxxyhHrJ/v0ecy1ICioDW0Wo8c DeZIi/7AbKsOhHNkJkXlSqE9hkdNtJKpmaeVT6XnBTMzlVCw15ZXPQg7DoV2sVMDoFSvsjA7X10y J5wn1Tg9my0wNCtDvT3DCiRo/2z1fygP8mnDAJWUdoC1ZC5Zz37sHFQLiGRkh7KskY4D6LLJofWW CFATdKT0t3THiFTVs230GgjygYt8ejQs7KzTG1WAmnKxwXnhYYg7WXmsw4HEy7v0bdGqYy0ld/PC eckxfV0uvXEfUrhZD02Ukul+8YYaH2VXu+gyHLEGspYztHeEqqNhD0C3Luc9073+Z9hWqGM2bJE1 xo45+lGGHqmXRYnKVNGOKkc6onJ4pS5AKiB75KqqSHbMUmTbkJaChlVMTCgMg7OyhjgritrvubE9 GiVQJpi1OKXTyc9xr8Rsx0JpLSTJALWiq6xeLikZypVf1hoGEXPG86T4ybG0nsgJGVw+J1mVZI9a 5annlmUpaD0VtFoL/cRW187onE+0Z9ZZuaHGICrlvEAObLaH/SrxrpZcteRrZEiqyJlOm2WF1dVH vkguPwvVwllD2C8EykFbSpjn9tzrN3ePHAeqYukdnGwPu42hRZt8l48Rw2H1ojOn/xZKyUpx/+Jt LVXvWc71kaLSPMa0VgqSTzO1RUAlkprbVj+lHrfUSsqgAiWf1JObcI6ykCtZq158Y6VGpqytmaaK eoVK2FeuWz3O3HARpc8ZtWwJ0ny7Vc5wYhAqsHu+A1VxNj3goDHUaimn58Bm5efKLo2eWqmrqc4B 6XO4UmCdN0MoHdSahqRyxrkup+pXIHgrfpLd6KmbjVJ8vA2TPao4075h+07NcGMZG1mW5ahI9405 CsERUzQgdRSj1FrDOV2FwJMGTnOhNH/VZjnzUEPWEWkkCfQvQg3Kc1kzTcpoeePckiU3nCkAqusm F/cdHq1h+NUiq6DaElK7CmxJWaBeOjPQ1MGSCF3bk9IoTXk13T49csKks/zNLsSyOvpLHfV4pf9w U/atsPT19MRq1exZ0wRMISyI0CqDQ8OhzIg09VQLn9bOCAHHdK7sVKYLaYqnK27WZFtVgSPC98sF +xqFcp3u/sNVWbZTQ1UUHy1ACj9riHaSpww6nSS/xjc3GMrTa4Rb829yzHzEyMbTruJ21rnvT1Zk O5b2xTzX0lVDGcEsZVgu5Dwsz7oPuRZKyiy/aeyxbqXYO/l3o+pJF2tCR7E5pOoJkVH6aP1/0NFU ra98HtRfSvbUf9SyT7V6rZE3i4hvo/r16ixvmYi8PVUnbQFWQvkSnUwkqJp/7Zrt7pIsYdMXd8Su T3ZEFSKvccBq69W4dtNaqk5KkTV9Ms+9eJG72tnzEdx5pZtMLebdrakOwV2WpA+1+pkrna0z8qWl McuTOi0G2kuzR9yPSiMledE1CtWsshIlVpLUk2RXSpap7nIifmaRNfHUaVqL02qTHPttdFmzOlEZ ZkaKUwxsE1FYL+dUzCW07FMdaFl2oteecGlABREXcypatOZjNUK+V/a0jqYPJauOq/sc0cgYb27x bmsjsSpToGW40O7RyxKhlICIgIa61yBVJcMetudcQmrI5kmP5Uut06Reeqdk7yDZU8kP2M2xZVGO 1MblL1H18d9Io2yV0s7l5NVoCVBZsnIGyKxUmeeor9HKgd3emNGJdofdvHtB9pt9dE9tW4ywAdoP T6xmyJFVVvyU0U0/qLHbVXtSuStK1gwvjwCT7qI81PSCQtXpSk8JdNJvVrAESg/9oy5mLWx7gUqc AdxJf3IpEPHaDXdf3H4TsapfMqDoWMi7NJNCnfpqbNjSbCile5LzkkR5vo8e4RIXkSqFHSe1QAeF sE5kN9F6GGE3YCa+KlWkxV9NS5eDQFUJ69ZVZWzXrpHVz/t+i6geq4pMrOcEvj1WdWPF91pN+La1 0t0btX5sapZh6dY1iXhrM4N8Tp6iF25x1JcBsauLfSX79ZvKoGyesFh5mpNRlGMsyCoOtvpkVzBr PbuuPuqc8zjDCs/qdoejYlVMSkdJWz/R5rr8MI8yafdA6gespVadIcZO8YyRzKYnY/o86gG0mfan h0k4OaXe32JWJfHKEKmlOCJM2XCLyxPnmddAIqaFjKpXQSrE8BuzrG9bmPvMdpbZlKWXC7EXysCh 3z6VaEq8tdSUqsd+KSA1DhMXvQqkHOnhPCAt5h782lr3sGOdh1nqKV1BlrJnhvVjLnkzVj2RQ0Pc UbKMVFZc/XzYTyT1cAm7gpNPThlJccsetwQ14RVzY0n26j0+yeURP3ZlciVxCfPcVQulKlKSWCnR 1iAlcjn8mH0uZ2k0a9n3Yxsyrb6O9bUVMozjM5DSGj6Nq0dnOWL65kCX7s1kkvVVSeaZnGTNFfds Nx/PuASK3eTYlGI9WHE55mG/KiwrTKuQ9LBLR2e70bKH6cUYvHtzSe6oBANuSxKKd4RxxIjbwPHL owS5hJAUnIlX1WpCuZTGrITL7BHcus22vag2sItr+XElaYN6WJdXcBboQ57V5ZU50r6TxC5cLlVe LuEyuz3UvzgLwFvDYKIeSZtxbtrY56hKdhDhjEIVC61yyr6Is8ieGixjTSaxGillTYkydashciok p8XOtK2CUjxbiqt8j7xa5y/i6o4iYLVi3rXH7cea/k9B3JN89JCWSDFsX826jL36mhl4bPWC1F2E nMEstpU7ISFKOCp7WSIig5yp71sQ3A9MY2l+KQl1mwQqkJb9Q5mcnZDKnlcq+z0at8Y2JKQlN6jX pIIcNkjbmJlgqz6qsczLKkzOzKfLnuQMfCjmMbvKpohBtTTKmaFM13oXUkDaumxuWA2MQSipcQyq mfMbQ+J+GlDsI3frBcgmElYkBxTJJf10ZVDludAZKNxIp7ssf2aEoS56Xp/uaR4hs5ybfkuAI+kT u7dsrQcmImabBOpZ1VsJXbv6+k8mcQVvJ4+lUqkIhex1gNTIV39xakvTJmq5TGkZULcV69FgcWXK 7+WoEQut1qlX7MKoUUutpsdYatWerRd1Qn35IvUWOTneSLkbCrmcjmW8k1XWrlahAt/abCqyTglr 7J0dtlLclGiVJTTDliRSWIXyisJFBTnDiwtV2dycKHgUs+LWnna9xlCND0OlUsvWq3KXnzUwpCz3 spzIUuFXOXTOFehOtvPE0cw7tMeZ6vz2DTuqd+l3gZgRk8kp1953Xq7jCskThv3qVGfcq4llN9vR IEWv39EgJS1JDmMZYi/aKZfpH6aeJh1NPNxTUUsWjXpWNNIjopGQkGi1KtGJbfVN27ayO3vVe7JV D5g33RZEeLCbdp/R/PoGKMuXWaI40FqK4pRaqpSklqCY6LRHXEifenlU5T+PUt5Er2li/VhQ1N/1 C5LsqoSErna7NsS8ErSJHI+QlZBwxRDT/JufEmTHu4kZ3Wa9cyFkVvK1Vl2VGkqhPalXrynmGdle 3LjwqOXR9fxuZ2KG57rqSYE9GN3qxRf6vnOCzX6Vgx1hctlq1JJzkBQ5ySGkagtpVwrJTpjJz8jh m1ZxtxrXQCd5rn2H0qe+aqIVdl9KWF8Vfl/HTy233O2u7LvtklPlNaLej5jWWw7ViI9PyB2SNTA9 2Royl2xL82RLGsmY9w+Hc7LoIFvlsjBiMpTpsmcEh7ge19u2F7/WVj3ucJQBM9KPUmVNIorRqOTI Czn6UkQn02i0jgLpV1Xtmhqobw0fDdtl0nUH+pUIlh3DKoTGWlg9MoOry8xPlbNWUtMbyH8NZS8+ Nb1RIDHmQFEro+vojE5NCiC06snT0pUWYM3/1yLJSNmCLFfF0YPTpErbP0uKkyYJyRGFqZW04Hgv lKZWspcvJU2W9daqzHVyh6QPbRqIvK9m9dITogI94htnnVuKynirjvxbcSBdmwaKL6bNUpFsXYr6 54Tk6Dbv0NkmAa3KuI8pJSZK3JmZ8yGdtM4rxik8rhrUoHFymq5AvRr31gU2ep6U9ZjFM09DSnSV t3nWo4cM97vgEYTdzUjHkLNggsp6Kfdo+UkptaCc+6q6zOfKN4T0d1YJy/IZrui9W584u8SHiW6L wFC9jIazroO5mGM1PcK1IlI/MUIeWZPu7Tc8eN5C0z+UJ8c0yL6p1r/si+sHvTp95GA3y6NpIgKJ 8pc2ucFQTlKgqYpUSzpzDazx51bnsKDIHjNIJAqKQoXmBe/qTEtE2HliLT7335AxcgaTNX0oshh1 cxaPCDRWlgCn7CmVIDwEz5akizzZGxdqo8wT2YlWw4C0lVbpHVZfWz2EcZ5EZVpWc+vBm16JuCDF OwRDSitl/DePspQAMbOSTCfDGa+sFsgojOx92EPa5IBq9bN6ZNdfLg9nekWZ1j2oljxoZhuZyYLy +XPITI/I8HQZVXYWZNlXT7LnFYy3RF3B+CT9SnAdW9csJTtKcu0668G2fLxXGA65JhzLttS+cW8S 5Vur/yuLapFOFcuKLJfPLxye5JkVoySu1SBYU6zb2k80dYQKjHgukOqwz8lO0ilzjh0DuxGPFREp IayQm2vBn6Fe2mRp1jKrC+Rco7Cyw8iJA/2LQjnWbZq7d6wEOqkjCwAKm3qEWWBr8nLkh5n7Jcu0 fOQnd1RvzGMQyMwaGsrI8j4yknEotKtfgR5FZmKt5YyMslmI2563HBGkHmvuzH4w0U0cLyc42CMr C+WTlbyB42tZz1bs2mFJOWNO95lP4asdWgntmTBpKUSWFhutomjJFIqq//ZyikH3c5igo9bZhhE9 ulnPHdFThe2SUdxVlX4n+wkZusFX003l9M58BKea0pN1Q0a25YzUxG0LnEsrU37V/AM0ELnWQKFe Pzji1NyiQj32xJ3D1sxLVIUWbquQmYqjA3F6O00SdNdPJognw2Rc5UGZxWq4lBblCMIkp8ulVRPb a1ayak4ihAsxcQyiLqOm3VvqgpZHJbowkKVPzsyUs++t8X3yLVv6qV5Rviqb7gD0GMGiwmz5nMrd AiR6GodaukFQ83aLtMLf6orOna+4nJipk+u00gluWV5zsvL/jaDpbKa5+tWRfR1dFSK7mFoXlB1J mdpWK22ZTwrtdznaZaNblh5C0VppWkqPl3WkMJyB9E3k0rWSVJc5rV5aQzV2VHe8aeao3Obq2lKn LlwrMDCsh73JeFfPbVbdNkfqKObppQZcJ9sd4EQZ5YjTg83yC4cQdxOI0Tw84YSjOsWB6lKtqm5C iw4pIyecMViNeyw2mOgKKWdvDgzbCUjAA3ILCVa+MjMlZjDFq9/FBpp07L2oo+xEdVetnpxJYW7J UqeUGU/bNk3rGNGvyrpBrXSRpczR2v4ajCqrVgFVA78LsnJDlDppltVPiDk1R3YiwwOcsJvpXvyQ YCi/ICXC7mY139Ke7V6Z2Sl7EaYDXcgoybHSQsahmbJRWCaKpBhpPsQsXuLNOprt3GZaJU9vnNqw bp00qZvWaXFVl0DjRvF2kWzSuJGy+9RRl0rQAciD0T05Ke9KmpMq9mn1E9Pqx4q5zMUjlkxXR+5Y 7y+tfnxxN1fCbqqUivVimeDC3tn4CfH+Bjg1Qzk+3t8A1yI+3s8AZ1nZZHFSi4i721m3GU2Z2WTG aMuZS84o6eA1glF4VK6nBK5QTVC+CqZVi8vVqBajnujBV2ogsBrzgt/h2iSv9dWoVtpaM8EahqQN sLJKyNqmYp/oDIkpsOqKXINAj5yRrzv0NTRGG+aCRzbMaSXgCHY5VwfN27dNDfRKTe3tTFT2TfMI 05nV1QnladXEEw/dr7B8FGY7w2ZDBTqYHD1fSz7qSomP1/2v4u+z0FEz9TWsBTPVmjhHuL16gV71 o+/OO9VcRbkwbDpd9hLleirrZYV2ebHHozsdKle6yAJhNS9OufLRcuPj+4cKnaKuHmmrEmN3UYP2 MheWMscZGUPsZZiiNNDIdYuCnqVnMjyTmNW1QgWqn6f6Ufbo3huyXAsBRKxu6FGa5AKPIesxamY4 oyhXmSWIoLpOE7XG/g3B2DkpF01RD8GthkmvuWC1ZGYStq23H/FeopZ4StKrjxypLGRFvkTXThlL jbNeKGEliCfGIbVEYuduLZOtFRiDBaECz5KMIfdogMhr6NX1Y63MSLD2uTowdWnzqN8ZRJAUuJFO UrJrlEOBGqBoptgkWVey3lTlHxvvKWTjEClXmwS6tpE6dpvLW7dpLSddmdxzjz8mHXJDOegPeihg SnxM86YeCdrFay+KsLeFbAO6yx7pKWQ6hT1nqRgZS6V/gLZlxbcs1Osti0N8Ca2dqokozrIW6CUV +WvYkgJqZEFyKKtwQHJwaGEy7bRsc3unJMSXyCZmPwDw2Mbi40tqGrOWn/rvtoy5Wws1wgWhKh+U qEonF1+xhxx7DQx+9jMnm12BeC5jCTEnhc0r0lNSjc0j6H6OWgKTh6fd/V+yePyH7BrHZkhJCbTV ZoRc8/Kx6rqIVneF5Lad/lsttTcb+dknMsiK+KOxzEj9/UiGGURDcaaW+HhtauG3ozG2HFG4JMT7 m1ni42ObWY4cqOxKpPsaWHTvwde+oqqhtK+0+E/aV9A8I+0r6sIlsq94TnbbV1r8e/YVO5z8qO7Q v2VfsYPxta/IJr16ZKyso8FCvezuEYKIkiB2aKoSujusgciH7/ZEU7suaZHnU3F9g3TiF2iRN1yd ammDybpwJ5uHIi7rSHVLwUYbrG5rzlZnXOtA1Yu1Lx3B1BLLyGImhcqYKV336IwuWpUskRlIW32O s9EnPl5H4NiMPvHxUkloEBjcvw7d7TadurifzibqzrNOLr/OMxdopNZBTErIbaY9pDdOq1fXsX40 cFk/GiijQp1GdPON/aNBtP2jcVNd6po1amqXimZ1m+oS0axxalqjlql1G/InA9GKcFpdPQWoQbq+ jxYtWgU6tQrIlVO8j5sT5Y3YN+V3QyGVaGnp//ZNpaUf4a5Smwas4t6sgfTbNOC6uYBzd2kN0pT1 y16oIdg/PFTbHu1sdS32F6PfKIcd+XYZ3f1FWWZD7qEF9sQ2ioVfG+7IMWXqc1lbfBJSPSBWZhqv CPT0amMusKmiptdLdC9FEO4vn9MlxbqmNXDc0iy05yy5LkieHLEpa5EZtWvki6ladnW2R9PZ7yvT L7gzExljprps9oL5RjK6ElqHrG/MUWNCebbiGR0XM2JNSgZZU9E2kPQ6CK3OFQ2x+wGOmEHrKXl5 VcY2V3k1hTHVXRhNVVPmxoYpAdMrauXp0SQkuAcqOKOjYw8+UFnl7SYq+VWkLUa2VurfCVOvViwq cM1nl5f3hnbkRUy1rUn2irR9Sa+lOEB3V4Lu1WKs17q7BvW4NHo0hfzhqjVOCbR0z0KXxcK9zrVe RU/3TZRWHTnKx16VGvUuuTCcnCVnzDuh270JZwnnsKWNW9eQZV2ZLlTamfm68p5y5AAA9+vu9LMM Oz1TrAUePSswuxZBVe+MCcjZDnJcqEpjuepLOC+5iD0io98qr0I2nR/1jvlYz/qVBmxZKFTPoUCV GaUjqxQMBoaEC3VGUGzy+JIr+MoJAiE1M56sUKtZNpIzW62lJiiGFTnUGCVE6cI1aQm07i1/Srgm XJAdyg7lhwMdQ4OLyMGE7vJIf5lL+XIZOBnLhNSkQMdwbtHgYChg/ZyckR1OCnQLhoYFQ8mDi/g9 OCxYEBwcSgqkpaYlN6rfKC0p0AHNKS9BPZptEhhuXyllsL5S80IdVEpGOGXQECsqeeH8UKBzsLCg KJSgvjhG9rWRa2jQ/ZeLkRZJFSEoh9+lJAU6dW+dkpBat24DGYPMcG7Q/k7mxKTAFUQpGBGRXBV6 88z8nJTcrJB9dXVfw4sGhwKXc6f5wYTL27SSI/xMGqQnpyanJnUODQ/eKG9TOnKDWfLeza13aNGl xeX2ZQqT81RAzTMyclMyclKQ2va1umWHBmblF9GeDC7KCw4MJlzBZSNvcbh1g4WZ3GByWnJaw0A3 mXy53Far7KKwSnV1f4H66XWTG9RNq6/vM8WOwQAr+PT09ObhweZO21MGiS0ZTkpwn6EhQ6g03bNy 5EqFQ7JVQyP3hmTLRsKdBDIBAu1Dg4P5IW4uOSyT9prw4HABJUOnd8egvOCwyCQfrC7VPK+wcGhm YUp2iNQoLLTjIwtoW7kkVavwkOH5oYHZhYFu1A5llUlIqO4cTWxVSzUbZhBAt3BGKIt6kyjnsdTS cxK6Sq8FlH89b0abR1y2OHV7yvplT/0OqybZEiQZ4SFS2khP9EXztElQNrNSelhzhhG5oaFBZT6S w2KMmMy1htpIk4TyP0yu0Yr+nSOXxpCW1Xw1ily/oFItleSxPhlhli+1XTmiSscmKTDEWCfV9eUT LdWz0Iu5DMsO56jxRrg5sdBZDcuMMrIN2MPV9PIkx+bkNOJKpcowiY2Qk0JFpZZt77DKR75rZmpY DULS09BVbAt8k8jz2lF3bujVF8wKMv3l3KNMow3ICA8LSnuwNc29v/WSIrstjYpv2LXUYYHdYkYV GDuDnF/C+QOD9swfslmucT1EvSxcDouybaay8S6iOug5wplSi+WWiYoJxrYbFuh8Uas9B622zxiD tNnSRL3AqwK4o2tCs5oDM9xR62Qy/1WZ8ox5swt3llIXpZabE8wbWKQGOuu7VhPh2+QNlGXKek6e o9eHkA2ptXBGQYDsVuNzddFQFums/CFZhWrmV16m85ZhNdluaHhwljEc+qW4LPDko7wPNbYl35pS YU2wSbD1JY8GIFOqmLkvFdpm9c8vkqpwmuofJCQEEqyGrI6W43VsIVtHy7s6unGpUKFXF2nUqRLo 0qJdm0DV1HrVeh/9yfLchFKBQMv8YGaeLOTdkNzVu/vnZRcrL5OTkVJDQ0oNqkd3v2UrtFLL4FM3 jQbtiozCsHwKm9q4cYMUGX7EuN4m/MAJ1S9zTfovzMrIzqPLPHB4IFm+Ad2yiisNONlrG8dDF6RF WhPLOk0UWqOn5FqXbOxzyXrH55L1mujMLMEV9U3Wadu6RefUJjKPSxrJYk4JRJ+TenxuLLWJ/do9 31uLKB8ds4ZL6ZhZ4B4oS/YruXWZbYiyRhsoaanHklplJTXdKiypqcS8czAfYcOlGsortadXkpFd lHNjfihPDhLqlhJoFSxQl+5KPxZJgYDOGJwUuCqFljoj3F8OhKtO/ZNTUrqbMd7GGCkj6AwqcZuR iYx5SYJrfF4baSrPylK2nO7BgsFywGxGllQL8lR1NWU6avZiqyu6ph6/Qp2EKsPJxFZq2vkIXHoQ RbmB1Op2kqWpARZSdIi/t7+3v7e/t7+3Em9lhLgELoXrYSzshp/gyROEWAijygvxIDwMz8GLsAJW wmpYAwegbAUhykF5iIeKUAfaQBaMgJEwBh6AsTAOHoTxMAGWw2vwLnwMn8Ie+B7iThSiNIhD4jc+ +8Se7eIDvvaJjbD8g2fEgpli8l2T+T9zgRgh8vmTt1g1rvzIMu3jxAnZF41oe1e59kKEE+NEJVF+ ZAZHM9XRgRw9lyOlB8kz6nY4XfQoH5fRvjQ/T3q5TVv5s3WG+5ATci3fkGtZITtHEou/VqsvW8x3 XasUh8pMa3uh91qJrms5R2v6xqCmdb0Ez8VK46l0xYvKiSSZ/wEr/5vDFTAABsJEWQZgITwFb8JG 2ASfwxfwpVVW9sI+2A+JlJlacBH87i5rB907H01z7RTjrWpcibzd5topxtt1JfPWvGTe3DsfxNzZ XDJv/luZU0XpGnHNL6T4nyoCQpxaI+60GnGlJueI8h/WFaUmHh5+xtyLRNmvzog6s+xFlfxDK0UY pU+VIYnT/tP5fwlcCktgKdxWjvOgDfKiLbSD9nAZdICO0B16QIN4IRpCI2gMTaAjdIKb4Gb47bdf Iv4OHtz3/e59X23/5MN3Nq5f9cqLzyx6cv68mY9MGnffXSNvNglRvlQ1UXbz74cP4zpVlD2sXRwT h+xjlQ7ZxyobVxXjqmpc1aSrNC61d/AweyfgOkHvbzch7zCuz43rC+P60ri+Mq525hoLjGv4Ydt1 o3adJsruOWzH+Rvj2mhcm3SMTiVGpflfqnScKMd36bgTThR1/ow8urCiEDVhMQr6koSICvWre+dn 986Bv3znx5J5O5odz22X8Jej2WErU81IkGpwmpIk1H955GzZnpaBJjAI8uAeWAxL4BXYAl/C11CP /FwN62AX7IbvYJ8sB+TxpdAScuF6GA43whJYB+/DB7ATdsFuKEOZOAHKQjkoD/fDGHgMHocnYAE8 CfvhAJx6khBnwu0nqbs+IPZ8vkW8JdaK1Xz4fku8tHi+eEnwb7Z4eLaQnwflv9XiHhFjc1rOFKvl PLmUbKlH8FvZ8nG0nXpfmP0KegdXJdMWJ1ttcdWoI97WOdm6hmyPnaNJ1lHn7CTfs2vb2oXxVzvq urV9z7Q1HpHqVz/nnSzEozAf3oSN8AxtybPwfFUhXoD7TiePYAysg/Ww60zyE6qdTd7AadANukOV 84gVVINT4TS4GJrBbwd+/Gb3V5/98/23X1/z2kvPLnpi7owpE8bcPfKmoUMGZfbp2fVEKe1O3nX4 cEKcOFFKtHTbzfH6LncDl7uhy91Iu7V8Rljqoz/vcYX4jStEl7vBN86ZwW/tM/t/6xy983v76Kjv raOE96o5+tr3TmgrvnfOm7jXluOTjOuhA/ZZUw44Pm/92T5628/OFR41R+f/7Ph97Gd3WzTtVzvk GqZN+YdxvY0rIOvOHbAQ3oLvoSz5XQnOgQDUgougNtSF+tAA2kI76At5cB9MhDmucrMVypxC/sNZ UA/qQ0PoBJdDF+gJ10AIBsFgyIfhMAruhtEwFsbBfrFXfXZ/tn/v+2+ueGHFm2LRXKr23sn3WX/8 s1wjfGv6mXF2PS6D6n1CdutfW1woawoV2VV/6rp1bVN/6lr1Rx4tXb/8SO2/FP5PRFv31jepw59o 6fBOTa0TVVPr+NbUOrYsiDrijVGK62i0DJPyxblSinOl5KOt7y+5k/LFmDvPl8xb7J3rS+Yt9kWF aF1NtKoR12bdbaSDmLK8TVvxV220u6oN9sSox18ZowRZlxbAk7AQnoJF8DKshPXwJrwHH8N22Anf wj5ZD+EXqEFZ+QdcCClQDxpDa+gAAyAMd8CdsMQqX+thA3wCn8LvcEplIc6DRKgFF0FtSIWGkAs3 w0iYCXPgUXgMnoNlcOC7XeKTLUJ+NovNa5eLLWtxrlUH1i7dMn/qlvlbpm4RfE+dL49NHT9fjFZJ 4tSeelG997So2pjmro2mhqX5So1Udx01flOjJEHqCD9JYJ8t63JxssvRR7SmIvVJranoa7r9i/oy rVbA+7AFtsMO6FJFiK5wLfSCG+AmeAAmwmRYCEvgZ/gN/oDDUBF5UQVqQT3oDFdCGPKhCIbCJJhr yZeV8C/YC4IqcgKcCedATWgGnaAz9ICrIRtCMAhuhJFwJ4yCMbAAnoJFsLyabDO+2f+F+IbvHbjE x+LjTWvEJvGy/Cx5jP/TJsT4OLnVICq3GrhzyxytH+Wvvm+u1o/S4dKjzkz3PTPdrTsav/Usv9Gl uGqUH05sItNlI7wL78FHMp3gINBHEGWhKpwKDaAFXAczYCacSXfiLAhADWgGl0IQMuF2GAUvwHJ4 HTZCd9qQe+BeV7vyIMyHTmdQ/uBlWA4r4HP4FkqjX14K10BvKIKhcBs8Ao/B47AUDuzZvueA/Hyg /m9cGfERr4hnxRNihpjEZ4b8d7+4V0Rq4y2ipEDzqBRt7q7v5mhT33xrap1dFr3BKx8a+LbhDaKu 1sT3ao19j/qXTvuoaHCsunuZAHUVykI5KA+NoDEMri5EDpx7AfIcAtAXZl4gTbiu7Zh3fiuZt/87 Qcfe0ZutiZwj68nz8AK8DAfhzLPQy6ELXAdByIIBMAlmwWx4FN6B9+Fj2AJbYTvshF3wOxyCqla5 qg4toCW0gXbQHjrBla4ylwsjYTQ8CE/C0/AbVDgHxQXqQEsohFHnyPr+udgjDQF8S0PAlrfW8v+t LS9teZ6Krj/PP/HsE2LWpGcn3fvsvbc+69S91r7teCvfdryVbz21jzr+Wrr8SZnirvH1Iz25amfL qBag5Qg/SWKf6pzZIurMFr5n2jJNpMl0ux8mwtOwEtbDZvgVyp1L3YULoAm0h47QCa6Aq6AfZEIR LIbVsPFcLTdsmSFN13EBLSuknOgC3WEQDIZf4BCUPx/9AWpAInSAjtAFroSuMBAGwyi4B/bv3rl7 6/6d7+7cyt/65TvX71w6f+f8nXNmiYfFTjFOjOIzDpd077xx541ODrX3zfX2vmlm+414kkJGRkvy dr7htvMtTW19/bb19dvG128bl19vT6+1byiusl73WGT4DqhZAx0MnoZ90OAf6IrwEvwOl1yITgZv wSk1yT+YCB/Cr/u+2/n5px++8+a6FS89u+jxOdMmj7v3zltuyM8Z0O/a7pcLbd14YbtjP/nF5W66 w3GPcLnXu9wJnzvuK1zuB13u91zual847qtd7odd7s9d7hpfOu5BLvdCl/sbl7v2V447yeVO/sqx 4Hz2lW3X2e46WnmnfbTKTsdq1WqnE0Zrl7uNy93W5W7ncp+kbGLnyvozDqbAVJgBb8BB+Bkqk/dV 4AKoAf+AC6EmJEItaAWtoQ20hXZwGXSATMiCATAQsiEEk+EReAo2wLvwKeyDg3AIylK+ToazXGXv C8rNl7LswG/wO+zfu3PrXtT5zVKlF3tXLVv6sVi1d+4j4z8Wc/eKrXxGq/+3Cenr45so4bntRZk8 cNXvDrY0NUcus47oftT1paL7Ue+832KArF+R/TH7uOyP6bP3xfn0wr5sMd/vbPu4c/Ywc7bTu3Nq +WW+tfwyl6zwSgWXfKt7POrxR1AzkfIAteAiqA39IAjXXEQ/EnrB1Iv+PFXnL9nxPL45mgA8z8CO OQZRm3z2U03YT4POPpr8mwbToXltdDloCUtgKTxeR4gnYHZdIebAXPgCvoSvoHIq8gQS07gWlK+H PgfjYTv8evDHPfpRwOqDry57dvGCR2dNnfzg/Xezc/uIGwryQpl9XTejZGNp82z0fuMaY1w5f9iu XOO63TxDvcM8JV1ijj35i+1aaFzzjCX9UeOaZsKbblzxJpSKxpVgXM41lhrX04dtyR4+5EjnIYcc 2Z9tfIQOO/b/GebozMPOebNc7tku9xzt1s+l1ZEi1ZZeIOXnISv/Zb7XgQbQDjpDIRTBSHgIZsF8 eBGWwUbYDJ/Bj/A7HIK4WkhSqAZnQBLUgUuhOYyCu+BN2AinUJ4qwdXQE/JgKNwGI+EFWAbb4Dv4 AwTlrSLUhESoBZdCV1gE79eWleFn8a34Unz7ic/n3fX6I95d/oxYLh6f+fhk8biY7K2Czua0DJdH ad6XR2nel7uksuOvc5S/zr7Su7NvH6Nz1HU7jIi099jtWNUoP3ZL4LQhouF/uj7vgAvS0R2gfH1+ q/8/Ib6PWUj/WTtRW4T8l3XkY9gJu2EPfANlk+gLQADOh+rQDbrD1TAQ8mA43AsPwhT4ELbAJ/Ap 5CcLUQC3wK3wBCyF5fAl7IIf4Ec4MUWIeDgXLoDakARPwzL4CD6Hf8HXKUL39A/soc9Ph/+jt8RH Yq1Y+9JSMX/6fDF/opgvJKNR+2D0MHnzTr3pFlVvukXVm26ueuP46xpVB7tG1emuI/zq/pVR/q70 vcKVUZpol6i4dfG9whVRV7jC9wpXWOGJFJmO5anf7aAb9IDrYYRV7xfANvgeDsBBOATnUvcD0ASa Qm/oC5NhBsyCz2A7jEU+TIAZMAeWwauwHXbATtgPyciPFEiDepADBfAgMuQzaNyAPgUMgsFwPeTD jTASRsO9MA6mwjSYA4/DE7AInoPnYSeUbojG3VDWmJ8OUWu+3vb1B19vE8r5wRsfiNXia/GB2j0k Xlw8T8yz3NEf4U7xHr4p3sPOwagj0p/XpuD46e7bCthHnXzvHpXv3V2x8C/RsiUQzWPJ6HqkTzrU h8vgBfgIppBeX0NcIyH2wj7YD480Js1hGrwNm+HzprQVsLmZEO/Au9DmEvqIl+gxH19/vvXjD95a 89KS+bOnTho7+o4Rw/JzBgZ7XdXFJa50n/ugow31MOMervrZ1Vt3jYFo/avto82vztGrf7eP9vzd 6UHf97sTxv0u9xiXO82ll9VzudNdOtqFUgOsLF3NcZWvJCrEnVhGxl8dG2uOlTbHuhy2j5Uyx4aY Y2rMa4I8ts0+5hpTGDQ6aH/juv83o/sa1/VmrEe+cT1rXM/hOqe4vD6aJvMZ906O+Ou2ttXEiReK +LaVRJt1t8WJUkKOoza/nuZ4dA0vjrnFieQjeypuK3FsSrIda2xc7X9ZKf/qQRu4Gq6Bu2A0PARP wzrYKeUk9bwUJEEytIP20BOugWuhF1wHvaEP3ADD4Ua4CW6GW+BWeFjKDZgK02B6Iy1DLm8ixBXQ BXrCHHgM1sIG6HMxbQ1kQjaMhDsu1vLlPdgFHvn8/b8++Nf34ntxaP2rzy8V6w/NfWT0XDE3Uoov 1akTQFoqo8vO0rZBpt2XLeaXLR8nJadUmh0LTrsYFpx2LgtO5PP4waWjLUFtY4TT1hWOidd3peyf V73fYoBvvFbFsEutctmllPyv7yfTX3QXluvdOxe5dxKF3yZLVYlLexmfACK3P6/ulfY5OXL782JT yufkyO2YY1PmWNrwyi3o+0GXVkJcCWtaU0dbl7jd8BQzzy/Px/zlP7jjabmOc7+rtBrwpZ66esZ+ fUB9jH3Wf3iTNbWqlJW7YQ/8BHthHwwhf++DGfA4LIZnoOKl6CVQBarC2XAB5EAuFMCNcCuMhrEw DibBNHgNRjUX4gE4k7JzPnSETBgEhXAISrekbwGtoDV0hNkwr6Uua12hG7xGeVsB62A9fAS7YH9b +itQtp0Qp8OPSL2fYC9UuAy9EuKhMlSBqtCnA+0KdOwoRCfoDxmQCYMhB3KhcyfaKMiELBgAuZAH B38S3/4k9hzN5yfxhXXyT+IT5fpJvMe3sJ9AfHqCdwx634h9OSdH70vZ7jzjiGyBsow/0a24eryX 9NsHP7R30u9q0qknJJJOteAt7vltOK0z6QxnwMXQB26DOTAX3oW4y+niQF/oB3fBQnj3cqs/sEM+ DFy7avnzS558dJW2+9pG32tdBVdpr9WMzbWpcQWNq79xPWhcK4zre+M619hhzzOuFsaVYVyjjOtx 43rCuBYYW+ypvzt9gpf/sI8u/8PVy3BZZcdEWWUbfOv82tA1yryeGU+e7hpD3v9H+2jGj87RD3+y 4/WRcVXdb7uqGdcOelXn/9n5/DP8cvlxELDH/JzlPxjaf/OO8Oj/50iZFYb58Bi8Aq/Ca7AO1sMG 2AzvQHUrb++Ge6DxFchpaE6nvQVccKUQNaAJNIWLoRlM7Y78h6fhGXgWnoO0HvQHYAmshg3wOmyE k65CNsHpcAacCWdBfWgADaERNIYmV8lM/FX89Kv49leXVOXYt79a/7d/JLaLj+TX+mVLHv9VLBsv SrTVFuVHuhRpaUjJ+7TFXZYirSfuploTd7WE/bBstI4/OoaOP9ql4/vMCpYGH3k1Za5zbEBXR1kE r46w7TjyX8fpGhMnl/0/zV0nG5GPw+B52A8H4FLy9B54B84kH8+CAiiEIngW9kJaV7oKkA/LQHSj fwgPwFjYDJXI764wASbCoe6OHei9t15fs/Ll5xY/MXf6Qw/eN+rW4QW50hTkyQcltYYbO86NLhvN yy737y53M5e95haX+1aXe53LneCS1N1d7qku9zSX+xOX+0yXZL/G5Z7icj/scj/ilv7q3h4zlpsf jKuxsdfcblxvGtdG44o3Tzw7GNdo49pgXK8b1/e4zvur8v2vF4T/d0R+cfJf5sUfcBgEMjcOUnto ufwm1W8jfA5fwIyeQsyEWbANzrtGiCA8BrsgFSWtAJ6Dg9C4lxA3wStQ6jr0ahgDb0Ol3vb4r49Q +YoZ/3XJPqfG3OZyr3K54/c77i4u93iX+32X+9QDjruny/2Iy/2py13joOMe4HIvdLm/c7nruCzT uS53nssddlmsLzIW69q/Wj5ORQ/91fHd0mXJ/uQ32/envzm+K7qkXoLLfZLLfbLLfYpyn/tX5f/R FN3fSubtmM/5X6//wjX+W+pN3aEHXAVXQx8YDpNgLiyFl2AVvG6Vha9hD/wi9S6Iu5o8hrJwIlSE 0yERroA8yIcCKISb4X4YAw/CYngGnoPn4Q14C77b+vYysUgsnD154WQxRkzGtfD2YQvFQpE3LEvk 3T5MfQ8T7qdh10Q9270mSlu6xv18LMqf93lbz6ize/qe3dN1tnfEnVs3+3e0yTONPhj1kwgIyx7c rZyt2EX4qK6v5L2G109NmcZbYCv8DnHU6wQ4CU6Gf8CFUBNSoA7UhVRIg9FwP4yF6TAQuZ4Nt8Ct cBuMhEfhBXgTNsIn8A38DCf0oSBCHwjDBJgEj8JieBlWwEpYAxthE7wFpfsKUQWuhRAMgdvkEDG5 GoDYKj7YKjZvXStWv7h2tRwDunmrWLtYf+ZPnS9Wi/nj7lbLBeiPU4Z6RT1R7eWb5718S4x91Anv Wjs84+famKXlWteVIrX4zeWitfhKUWH6l/Po+iDq221xN5hn5dNEK/13k4574Nx+yHqo2l+IarAT dsHcDM6B0zPpn8EiWAwJWZQfaAJN4eyB5C9cmI08yC5OOB1fneznknn7S3Zi3+nxjXXUFjH+58/O +3WwHjbA6/BGthrz+c2/dnzy4WapCD63eMG8mQ8fnDDm7ttvHna9UgVltJXO8vFvjv6yxeX+p8v9 yW+OpuT0FW9y2eXuPGQfHeV6gj/A2PAG2n00tKoJrv7aRJf7IZf2lvSLfWbyL87R2eboHNfR64ym 19ul0dU1Gl2qK/YXmnjWtONJjK41R3u5Yr/E2BqX/uEcnWXuaXaUpfH3vfJIQMrKqbAAnoHXYSPs gu/hAJQn/xPgnH66PKRBPbgUekAfyIIcuB6KYCiMhjEwDRbBMngJXoW34V34EHbBN/A7HIIWQSFa wt1wD2yETVCZclcFroX+kAlD4Sa4B0ZDRcrkKfAPqJXhlNPSlM2KsnyC0M97fxK7fjoktn3g+7En iYqN28SLT80TL/I5JJ6KWbccSd87quXo7SuDe0eNCLrOty2xjzpXuC7qCtf5XsFuhfzbMPX892KZ HidBVagG9aA+9IBhcAdMhofgKdgD30BZ6nY5KA8V4EQYAIPgesiHW+B2uAtGwzx5zgDChiDcCLfC PTAN1sDb8CFsg3/B1/Ad/AB/QHlkSUWoBFUGyrkf++XMrs/E+5+Jt8X6t/n36jMLFM+8KmaKmZP5 N3nmGDHzTjFc3CncqRH0TbVgVHr3i9In+0WlbD93WOZo36ic6ut7zb4j3DNNOpcvbrZHH98Q+kTF yF3qlH4RVfI4WEem4ZlwFiRDClwJXSELBsEQuB7uhFHwAEyDWbAAnoSF8AKshs/hS/gOvoc/4ETk fCfoBb0hB0bCHTABZsECWANrs3X7INuG80NCJEF/mA5b4TP4Aw5DeRKoApwNo2A0PADj4UnYL6f7 7xdf6O9/Ujz+Kf/W4VjDhwMv87UMFok1cx/hs2bumrFrrFrtpNkT7rpp0viJqPx9wpXqztHH3XlR v/xIJ98yrHC9s/j7R4Xbf4Rfrve3y2oxpTcYFZar3DeM1Sb/DoegUg5yF6pAc2gBp4Vp92HhEGQC pOTTL4AMyISFhRyHdbAe3hsqxPsw9kYhxkH/m4+DYnPMHfs/yzLwX2a10Jvp//8ZeZ0BPUcIcQ3M vZV2AF6DFbDsNnQC+BimjkSuQP07hGgAf8BhmDgKnRQ2wVtQ6S4hroJp8Dkk3i1EHjwLv0Lze2hz YCNsgh3QdLQQF8MVsPZe4gu74bz7kHvQCwZB+/uFuAz6w1J4GlbASWOkvfL7XV9s2/L+25s2bNq0 btOm1WC2dRZ6ZzXbptWubZP+t0n+W/Gy0s76SO1Ma2Tyf0KcXJ1R/bJfrghmVvG61zyx7fez7Qpq F/rgA2Y87FiXdXGcSz+dZ7TLR132wo+Uu4OUkUtgHWyAjfApbIev4PTB6FNWmZDloQ10hq5wDQyE +2AiJOQKcSqkQCq0hAy4GRbCatgM78MPcHIe4UIzuAQuhU7QG+6AaTAXnoJXYUWebO/F/p305PeK vVv3vqs+6/euX753/dK9S+fvnTpu79S94/aOunHvqL0UWpfMW+qWy0ZaLnFJdcfvEl+/i339Lvb1 u8jX7yLftuEp3xCe8g1hoW8IT/qGsMAVgte+sMDxX1um6Up4Hd6Ct2EzvAsfwFkkY1PoDFdCT7gN HoDxMAG6IRd6wFUwBxbAudeTn9AOCmEBPAfL4FUohewoCxXhZEiHS6EVtIcroTv0tOTM9XAX3AOH fjr09aGfvj706aFP38H904ZDrxx6+tBj0x5T36/wefDQXYfuevDQiPwRwlMKnvXV0uyjjr9nfFP0 mag8kSu+nepa8c05Wi3qqAz3ad9wn/bVLZ72xEqGWdUdpjpbri1X1VpbzhvmUt/y464FSv9Pkun5 KByE3+C8AtIbsiAbcuFGuAXuhGmwFJ6DtbAVPoNDUA75XxcaQ0foBENgGDwEU6y24iCcVMSdwVlQ HVKhPrSCDtAV8qAAboZbYAw8CNPgcVgIv8HJtDeVoQpUhXOgw1Cp++3egd63A83vQ/XZ9KHYzWeV /P/C7oWrdi9U/1btnj1Z/fGZvDu6sbQ3Jx1f8M3HF9xpbo4+H3VU5trp7lwz4T7vq+U9NyJSt3/O 19+zI/x0yejS7aoFDWQ6BeEOGAOT4El4AT6Hk4cJURNSoTFcCQOgCG6HO+BOuBvGwwSYCFNgGsyF RbAYXoDXYTO8C9ug1A3oGHAWTIKl8BxshVrDhbgIBkI2LILFcAj+gAfQL864ify+Sa0BIFcB2Lrz 3fWySZDtwvK9Sx9fyr+9y5funS4/4/cK87nbP4dNWq7wzcuXfWvVy7658ZKda1FHvGe/5CvTl/mW sGW+Ibzo6/fFSPlvyt4ZTtlLlWkXgM3wKRyAP0Cgs50IJ0MiJEM6tIUO0Bl6QT9Lv8uGENwG98FY mAhfwHfwExyE3kjkbMiB6+EeeAhmw9PwPHS6hfDhOhgCI+F+GAeTYDmsgNVwMTpkR+gOt8PdMBrG wGR4BBbdquwEsoTst/4oKe8qBcJGqhB7l/J/PgVmvv7DNXXvEcrJGt9ysto3n1b75vQq39xb5RvC Sl+/K33jsCIy/00oK5xQGv9V+vn/Wrfqv+yisXf0Zvp/sm4sgWes/F4Dm2A3/Ai/QbnbhCgP58D5 0AJaQie4GvpCBtwCY2ECTIFP4UfYD79CacpODWgEF8MlcCvcBkvgZXgN1sAm+AA+gra3I2ugL2TC r3AISlH2KkACVIYa0PoOvR7U/q3v7hR87dy/Xuxcv3P5zqX8nw/r5++cymfczqnjzNe4UTvd7eN6 33q6zrfurfOtp2ujQpD627m++tu5vvrbWl+t4ZworUGGe44rXK+lb41v7NY4sUuX6XUFdIOekA9F cCPcDvfAfXA/zIVXYRd8Cwes+l/+TnQvOA3Ohi5wJRTCDvgGfoD98Ds0Qka0gnbQCbrDMLgd7oL7 YLwlUx6CKbAAOfIkPAVL4Fl4CV6FFbAMubIcPoKPQTbwB+/W/f/z6fNXhwK4AcbAA7ARNkHCveij 92odYv/Ozz7c+SEKwv6de8WbYoXUFd7cu8L9L+qz/PnljwMf9BiTyhusVM4uL3LbV6hIYp/oOEU5 y101yr+3HGxw5WClqBLqaBvrbW3DtxR7S8V6J8yW/ylbycnQGP71gBBfw84Hjk5cHSyZN08z/X1M b3uOdSd2DDzevnLvfB7TmycAjzfP/RxJmFvPc0+oJk6+M69MpTs3l5KHpFt+O/vjyzh+amj5f6Ys 901hGNwMd8CTsBBehtWwxioDW2EbtCXvr7XKwGpYA5XI98r36zIxExbBEqtcPEQ5mAJPwzOwGtbA WlgH62EDvA5fwJewD/bDATgIP8OvcCLlKB4mw0PwKnxplbFdsBu6jaWtgCwIwV2wDF6CLfA5/Lb/ 6/2/qQ+Z5f5sFx/DdvHVGyuX8fWG+eUF+W+hdM6NygGnHg6K0voHuWqwtP3rZzztKkSPEO/zm16V OXKEuH3cWQ/sjfLRT4hkHXekz+slkj6iWay6aqdlDdLqHzBmHDITTnoQ/3AKNINL4FroBQVQCA/A WJgnj43nGAQm0P+bKMSL8C1UmYQeAS3hIfjt573ffr3DeWfPE+aVPcPyc7Mz+lxj0lqPij5oW0Kb GFe2cT1gXKuNa41x9TKrOpUzs+fLG9dHxvWNcX1rXOXMuOzyxhUwrvONq5lxXfKbbakdbI7lGFeu cX1rXN8Z11VmrPbVh+xQHjTP/8e7xq1PcLknutyTXGMEWjr2ZrV/Cvvn/1l5/Wfpx572whN0CVuS Y96JLbq/PYqdL0SJtgq2XI8TCetOEHH9q1jtQdfS8piW/91K62/h6P9nSFn4BeyBMuR52XHypQDk PZwGp0NDaAp9oR+EYBDkw/1WWRkLy2AFvAnvwnuwBf4Jn8Ae2Av74CDEU2YSrHLVzSpXuVa5uscq V3OtsrUAdsGFlK+a0AraQQfoCPlW2XsCFsNbsBm+gW+hGmXy7Am6bKbAFJgL8bJ8QlU4Cy6ApInq ufEXH78tNpEBm7SjuM+aZUt8jsinyI7OljMi0g6X49LQnBYkZ4SfFW9w1NmDfc8ebJ3tnDko6sxB zplt5L02gIbwJrwFm+FT+Az2WHW4uSWvb4JJsB4+gK9hN5SeTBrDqXAanAnnQhrUg3RoCE1hNIyD p+Az+AGSH8IPNIcW0BraQDfoDoVwA4yCu2ACTITHYSE8BYtgI2yCd+Bd+BXKTaGCQACSp6i8lWbg Heqfcu7+cPebH+p/YveqD+VnhzQYL+O3RWLZoke1a5l4RFY2JyXD7jwwR/OiUjzPN6/yovIq1z7T +Mn17cHl+oZn+/WWnGLL3cWR7fBO2GXlaRnyZQJMtPLqn6TdJ7APTn6YdgFS4Z6p5Ck0nUa/AR6E 8VBlhnzngmuLrVd7vO2KueORhp+5d7bE3PnAveMJ7R33zqaj8HZ8dyI3JasvsmT2gjgjw0/Q+45c 72od64asv/oPJdf92gN1bNYJnmOn/SfyvCpUg2YwA2bCcngFfobATPrk0AgaQ7eZ3nmAr7303JIn 58+e9tD4MffcccvwwvCgrH69PEmj9Zlvbe2olXFda1y9jOsO43rVuF4zrk+Na6txXfKd7RpgXAON K9u4dn1vu3Yb16U/2K7mxvWTce01rg7mrV+DjSvHuO42rlnGNdu43jIjAr42rp3GNeyA7XrQuMYb 1wTj+hLX+VIe1ocGcAOMhnWwCbbAXivf68o8h4dhGjwHz8MvUBqpGA/nQHWoBdlQCPfBgzATnoR/ wrfwCxyCUpSheKgC1SBD7lOOToMAxE+nzEElmAyzYDa8DJ9Nl2v+q88uquz2D2TH7QP5TuA3xMo3 xPNPPS8XbePfw+PEuIfFKPlMw94cqXl3lOXkbl/peleUv7t8/Y2KkuqjoiTwKN8z74y6wp0uf87R O3zPvsMl/Z32I+xqPypFHRV1ZBqeYtXZu2E03GvV01LUy9JwClSC86y62hv6wGDIgRthJEyC6bAa 1sJps1AwoTtcBdNgBiyEp+B9+Bi+gK/ga/gDKs1GF4PzoC10hzAUwB+QMEeIREiHNtAROsFUmA4L 4ElYCWthB+yCX+AkOu8BqAMN4VIYA4vhBdgA2+E7OCw7+vOQiXAynAZnQx7cDA/AhHnqXXQ790eb Be2P9ao6OWZlq9j6Pn/S+SafWGe4cmqiXZrMkQlRpWSCu5QYf+NdOe99/jPe8d/laOX1TXAzjIBp Vr6fbuV3Dyu/p1v5/aWVv9PmRHTJfnHveFSAH0vmLfYvHu3i+Abg2fFoCrG9xb7O8d2Rm+zbGX3g 18Pevh96hNQPbN3irGPJS1nXPocv5uh6dD08AGPhPOrFWBgHD8J4q668Cic+Sv8PfoaE+UK8vuCo 2v+8f9kt2R3GdadxXf+17XpFu06ljTTHdhnXbuPaY1zfGNd1O80x4/rWuE7cZbsuNq4pxvWwcW0z rs+Ma/Ie2/WQcW01rm3G9Y9vbNeFxtXfuDKMa5txffaNfb9/mGOHjUsYLScR1/nHOx8/h9ufRBbD d1B+IbIZRj1Fv+2piPpfwh2P5cazE7sixLYDeXZiB+Ax48QOuoT2ptgBlDDWHqNQ7A6S3Oy6bfoJ T8QZe0+kLDhL5uUrVn5WeFTn6RiYBNNhBsyGF2A5vAqvwQEr3yvO13lfFarBmXAO3A2z4RVYBe/D J/Ap/A6H4ILHhKgJWfADDHmcNh5ugpthDDwIE2AifAs/wCGo+ATtMXSGKyEfhsENMBEehkdgBgg5 22ffLrGPf9uFWfDxg12H3uCDsnhIrHz+KcXzYs7DYo54WP6Nk4npaHFTRkQ+c5sS1RJPcbXEzpkP Rel/D43w0+Aeigpvsm/LPsmt0xm/k6KuMsn3KvbZavxfI5k+38E++AV+hfbU4avhJhgNGxbour3D qt9fw04oTf0uAyfIeg7xUBES4RK4FNrBVXANXAe9YeSTWkY8YsmJ1+Eb+NaSGeUWarlREapCNTgb zoFzoaMlU7pBT5gDz8Dz8DZshp/hkAwHmVMHGoP1grAt4iPx0ZaNYqPYsnG1kA75mnCOiZf0f2tP utShqZE1zJXGU31z/JGovHjENy8eieorPBx15sOuM71vJnw46uwpUWdP8b2uXXJFk5LI7EWLhfgI KiyhrsLd8BJ8ClthG/wOh+C856hzMBP2Qfh56jXUfUGIVJj3Ijo8HAaxDKEEpZYdVft/43t2S3aT cd1sXCOM6yPj6vCB7epoXPEf2q6KxnW3cX1qXFuN67qPbNctn9iuWz+x29zp5tgM45ppXCuNa59x nfqp7co3rnnGtcm49m+zXQeMq85221VgXGOMa7tx/WJcD++wXU/jOl/Wi1bQGjpDH8iELBgAgyAP hsItcAfcC2PhJXgNDkGpRcgDGA0T4AXYDbUoNxfBQnhqsS5LH1rlqfwSXaYyrXIVgushH4bDXVZZ W2aVt1dhHayHt+ATq+z9ZpW99Kfpo8ATsAAWw9PwLCyHFbDvafu9oNve2/Dehm1Cfl7bIDY8v+G1 9/Se/DxFM+D+nqOPz9nmrm3To2rbdN/aNj2qnk6LakumRcn+aa6wqkb5i+7VTfX1P9XdVkQdFRcf 7/odWwU6ml88SpinT+jZ8Qz4iO3Ncx3PLyXUFj3eHhe+W1utWdlrvMaJWaS1v9c/YXPpfZXunBsX ZUuuIuvD71D2GSFOhipwKpwJZ0NNqA0pUAduglvhAXgQlsIG+BhOeZYSDeNgJsyCH+En2Ae/g6DM nPucLkd9oR9kQTYUQCFMt8rXKlgNa+F12ARvwTvwFeyE3bAH9lrlsT5lsQE0hUugObSAPKuc3gdj YREshj/gMKRQduuAkPPCUQ53bfuACq/ngu9CVVgpVm50VEd2N658Uf1zHVxs/Xc2p8bNipIBM6Ok x8wRftJjZtSZM6LOnOF75owomeKWT0r/a1XHqrfp0BDaQFu4DK6ErpAJ98BomA2PwWJ4EZbDK/AZ bIfLadevhKuhJ8x9Ubf5h6A07fwSWApvwkbYBG/B2zD5ZSEegvnwGDwBC+A1WAn/gq/h1OXo/lAb msHcV4V4FFq9RjsGI1cRV7gXxsLLsBJWwQZ4fZXsdn2z42P+xA45QeTtNS+jjOj/y8TT4vGn+bdM PKp2Iz4zps4QZep2qOx6E2hlOf6mjFyyUVRW43PW6NE9FS8qJ8fsVNT+rD3v07k5UXk5xzcv50SV gtlRZ872PXN2VCmY5fhrVpxOdg6cC1tfog2AiaT9pJcjFu5+1r3zdMl2ct07g2PulDA0z461Ray0 XUYM39r6L5TC1Zye939X+1CxuHyW9XEePOqqk49b9VLWyRVWvXzPqpc1qIsdoRP0hrvgKXgd3oBP YA9UfQU5DQ2gHQyEyfAMPAur4TsIvCrH6f2w5187Pv3oXWtcmOoXPCk7Bk+Op2vw5PjwoDuezBoj rD5Bb7Mms/P+vabGFWdc1Y2ro3E5q0I7b/FLM65exvW58VfBHGtrXNdGjLJ6ebP9y3Ltoo/wrjn2 nnadJsq+b1wfSJcavfUhrgqltc+PzNlfmbP/ZVxfG9f0d2zXDOPq/Z4KkXP7vOesJDMcd82/Ip89 g6J+c+/EHlUV25p+NKEdcO94lMzY58QOoITn/CUB6E2/f8Be9+k0Ry88O1a9awWtoQ20hfYQhP4w z2pv16xEN4N2tKft4TLosKq42Bzf9b1i73gU9f0xvXl2lpTMm2dnkXvHcx21xVWKaIUWftl6fpSv P2uTw0VOlSXAtf5X1WPN647QCTrD5ZZu9Ra8De/AiauFiIeK8OY6dD7YtM6y93wpBfumDevW6G3l aytXvsb3uiPfy//IVkqtyVVJJMSViotzVnz43owAdtaBPtm0MKcYV1fV1pTtxtcJSHSrxfmnaZ8+ Ma5PjWurcQlOO8cvD6XOPA4ehPEwsZg8HQw5sA0+gy5r0P/hDrgTXoAXofZaIZLWFietY++U8LFq 7FYhthXA4213TG+enZ3/xTtaupelRK0rF9evZtwfF5QqL3dOZKfU+vN7VC+Fj1OULFDS6ay2Ilmk 8mkt0nE1Eo1FG0gWdXHX5ZMuGvA/TX3a4hphXwbGCf2WoilCqHcnvS/0G522wwlwCp7K8X023+X5 rss3HSPRiW+6T6In3yfyXch3PN+38V2R7/v5TpDh8n0S3/P4PpnvhXwTd/Es31X4Xh6nrz+Pi5/L dz0h1xnvEhgSHJ4TDmYGBoTzc4OF8ivQuUubdsnpgRZFmaFwnatCBUXBnEBBYX5WUK5vcK51P4Jz pRvZKDqGBhdlZIfqXB7OLcoP1mlbNLgoLzgwWKdzsLCgKFSnY4iQg6KgyJyLf+mW93G5vG5OSma4 UKhjpLPolh0amJVfFLADEnzJ32T8G4jQQOmW99Q5lJEfLggPKAxcHc7PDDRKqSvymsvwH9i9WV5H uU9/r8bTH74Wp9xf7nt5xRbL3W/2TR/jLm3FSX5fUFZ/H6ouzPutatetO91yqjo5CSbDpQje5vDG Oq+s7pcXJ/pDJgyCHMiD7mTcVdAT+kA/6A/db+A49IQ+0A/6Q9Ub48SpcDoc3/Y+trgooYgpofD5 HwhNt/uq/p8mh+zlxIlpMAN2QiA3TrSHG+BGuBlugd1wLnkegD5WWci2ykHX/DhxPzwA42A8fApV C+LExZADeTAE8mEbVKacVIWuVvm5zio7XYcSFjwA42A8fApVhxEW5EAeDIF82AaVZdmCrlaZu84q b5WtsnY2BGD/Nzs+3P/mKj4vvLlQPCoe2fFNCQ5NAWdzbO6RM28rSjuQWa3X8XOh7/owtVxHK5mj idbRqlFHvGf/w/doDd8wa0aFWdPx10TK89bi2Lbym1/fPfyXl96qdP/tYoHo+ES8FGpS4Evh3Vd0 FVligGpI6qtmpTHNTSOaEyH+b128MdTj4o3E/52LN+SiDUnyenzS/ro7T+d/ffF3sh/b9v9Psssa LrXWxuIvu3gj9v++82Pb/n+4c6eq6Xv/0y/eQN1zPdVD+4uSPQ3XXyJk5MXTVQb835Fwf2mBi072 v7e/t7+3v7e/t/8vtz/T/ve3ze94h3ZUm9v+d+b/sv3v6Ox9R97+h+x/DbJEANUuT2SIsMjElS9S RBLHisQQUSAK2c8SQZHLkVxcBXyCYqCQZ4VwBzgzjC/pv4CjmSiHCeqTiqKoXX9v/81bAfmXq/Kz s+gi2oh2IhnVPkCehvnkqDyWeRsipweWoFwUiBb4zFQhZFtlZAi/5SvfWRyVZcwuPQXqiL5aQJwe SBVnBAK487jycI4MwJ1vhSXjqK+aQxwLCUHHO0PdQS4xy+NYBr/L32QYATEMlzy3+BAiy39AdFe+ 81WnJ6y+S3Y/MqWKVPg6/pH3V1fdX+RdZRGbXM4KcVaA7yF8ciLuRYauz3Knvp0rsc+xUyBMvApL eP9/1///O1tlca44EXWglzhZPYuWz4iTUAN/PFyK74ocO2PQ5Dz9nLqq6Ns+rkxu+wo0cZXKFPBd yHdzzo7j9+b4PkHcN/rXK6+uGyD/5bP6OFG2RlyVeT+IqvMulmOOqoj65Ue26nC26Nj+bHFFh1Li ShCXcLYM4RJPCGkqhFLeEOIqyxAayEBOdwLwbGeLFs1/Ojyb74qirHhucLM77z88+PD0w3cedvuq Ia7lmj/xXZHW+ucBJ/cdVPfquvI+TxblCbksIZcVF4vzmhOzuItVzMYcDh++7fCMw0MOy2f1p4jK mafgSlhXXpRaUqVfzbhS+NLx0mc3EQHOrhzXRF3jfnW2PrfSEc89V9RqPkecH3cux8tx5ZmceTPX HlR0sJuMf4q4hvinxaWo33WajeUK9+NTcN9VRHLrQJy8k3KEV05cKHoQXou4C/FfXtx7OP/wvSrM KaTMDeqMSy6Ka3lRqUvEH1egScVdovx1FW1FKyUPs8QN1HOZI3L88pI4Hf8+uLzxvtg6X6ZYvDm/ vZIimZa8koalU60U8J6dJmo3vzIuPy5N3dXdWbUHnjlyZ87dWVf3Oq2rLKunce1+pSvd2eWPPnz3 41sQ+kXk98i4gMpv+5xV3QZeL0tz+4uESBTVVflKVPmw96rse3QqnijOEFXm3UDRugGflCvCqkkq zbbCuvHweFVudFhliGllQjqXsJ6Oq65iaPuwY1hKnMXdpYurCGVlXDp+Korse5oMv7pu37rRaV5R p3nFIdm3iduQyX+cHCfejcvheAVSrDstcidiJMvmx5d3pmw2FOdQYtLEKRNLJ5ZbfmKXk76sdEO1 imfMOjs9sOGC62r+cNGdKaenLazfvLGI3E4hhcuLLnAl9OlQRjwZJ8SKMkKshnInCBEPD8hBO2cL 8RkC4AzuZstqoeq29yO3fvAetGEXRVuNzAlQEe+FdETIa7DKGm7y9Is6pHJC0L8oJ0edHS4nko1b +ulBLBrgYUkFIebFC1GzBrkGteAiqA39IAjXXCjEtdALpsI0mA7NawrRAlrCElgKj9cW4gmYzR3N gbnwBXwJX0HlZGojJKZwLShfR4gKMB62ww64gJSvAeURaRWgHoIpHerDZfACfART6gnxNZDtYi/s g/3wSH3iCdPgbdgMnzckHrCZrHoH3oU2TYRoC5WbESfocqkQV8Ka5kKshb0tCRN+aC3Ej/ATXN1G iJ6Q2Jb4w1to9W/DaZcJcTqcARdDH7gN5sBceBfiOsipK0L0hX5wFyyEd+Fn+AUadRRiGDwP++EA XNpJiHvgHTizsxBnQQEUQhE8C3sh7XIhrod8WAbiCiHawQMwFjZDpS5CdIUJMBEOwR9wGMSVxBFS IQ3epERuhM/hC5jRXYiZMAu2wXk9KB/wGOyC1KuIFzwHB6Hx1ULcBK9AqZ5CdIQx8DZUukaIbjAP HoWJ1woxCXb3EmIPnHsd4UPVPkJUg52wC+b25Rw4nQpxRj/9ltPFkBAU4iRoAk3h7AwhzoELM8kr WAfrYQO8Dm/A73AIKmVTBqAKNIcWcNpg/SauhTlCPAUptMh1IAMy85y3s62D9fBevhDvw9ihgl60 oDeMX+g5nPoDc28i3vAarIC1N3MufAmPjaDeQItbqUtw4m1IB5g1knoEW+CfcM7thAuPw3eQfode NX4FlL1TiE4wHj6GLfDtnXrF9/bQC965i7IGB6D23eQPDISh0P0eZALkwSvw6j16hfIzR1PeoA38 dC/lDPbBfjgAde8j3+Hh+6l3cOYY/MPZcBl0gAEwEG6F2+ARmApL5LEHOAZJY/Wqo4/CP0GMJ82h DsyBfbAfDsApEyiHMAuWwb8m6VUxxWSuPVkOsReiGUycQpmCdg+TBjAdZsB5U5GdcD5cBgvgSdgA r0OZacQHkqE1tIG+cDfcA6PhcXgCakwX4h8QhP7wBCyAH+BHeHwmx+A7+B46zhJiBDwCU6H2bL5h GkyHGTAT3oBT/x97ZwIfRZE18DfJ5IAAIYghImoARc4YBCEqrgEVAbnkBhET7siRiNz6ScBwqIhR UcMhBrxYT1ABERYQBFZRxBMFdmFlv09Bfn4RVFjEzP5fVyeZzEwyIQQJMJ3ffypVXfW6qru66r3u quol9KfPkx+4CL56GTkwZyl1Bo5D9b9Sx+DxVzhl8N5r3Ktw4eu0BfAkbIEf4AAchPA3aFeh0Vtm 1varOp/Lnml6P7R6h/MHy1ZQF1dSF6ESVIYq0AAawoFVyINs+pvFsASWwfJ3TR/0NrwDK2AbfAyf wF44AvGraU+hD6TAE7AavoKv4Xs4CrHvcW9AG+gO98ISWA8b4FM4Do3X0ORBV7gdukEPGAWjYRks hx3ruBeg+3r2Q0/oDX1hASyEZ2ERZMMuiNlAuwwT4SD8CP3fF7kTHoNM2PS+GbXfciPtOCyGJXAb fXFH+Bp2wi5YJG5bukJFRdPLC7nNWeo4ie5xdtalnyxdCP9ElyDOyUv2Vy7VM86NEH8lVe3Id0i0 V0hJUp0fIb7OalRsQRzVE02IwyskyCsk2CvEWSjE/ehWSOLpDIn2CvEsVwnklCRO6VJ5xymrkMQ/ r6T+2kzV80sUIv7j+GsB1HYIhJx7If7qmNpwgRA/IXI6jxXtFVK6o5eVnEBIWYf4uwf1+UPhq2OF lDpOdOGQUsspT3H8nUN99lL4LsgL8YgjvlKdpjilDimTUvhMFe0V4lfyaQ0pRX4Sz4ZyncHzc1rl /GklTSzBdS9JiJSRnPIfImdUcknilCqVP8tFnxB7h/hLpc+SCx/rFEKkkPb1kGd+Tn/ImT16ICQQ Egg5fSGBu/vsCglcr/IcErg6xYd4nJ/EP/eMleBYSd6papQgpCxqgj+tUt8qly7En2R9N126EH+S v/ZKVdIQf5L1PXnpQvxJ3uCV6vSG+M5PQYi+3S+c6vSGzE80a0uZEMV3SP6WH1I1PyQw/j8w/j8w /v/83QLj/wPj/wPj/wPj/8/s+P+8Mcie4249x9uW5zGSSknilCTkz5RTFlqkklWCkIqJ4rFpnMLH 8g6p6JnI0nwLbDuxUwVCTibE+6x6btqzOkX7BkMHm5k2m4phi5jEwRxmWhXuNirC6moia6l8y2uK TL9EZFZtkRNXinzZSOT7OKK3FDlwg8jojiLX9RLZ3pts3kUvOZg+k27j1btpKdBFZo0hH+NFLqHV eGOKyM0PilR5WOQ7Wo/Gc0X0m+b6XWv9tqV+31C/cabfOdJv3ej65Lrmga41MJQs6pdZRgJi0WQF rVfQeXVetKDT0nrAZOBQ8gBMhQx4CDikPApzgEPrJAF5EsiCPCXWBADLapsHC8S0IM/BEngeXhbz FalX4DUgm9bnVGgwrXPXkPZ4GQr0lhjS1UUGfVmFa2iRWogcSaDFvFnkP51F/ugh8ml/+rnhIgNp RRNnifxApi4gE/p9Z/3G64zXzXd+rO89/M2s3a5rf+h50B45RcxnWejohFOL9WLWleL0WtWFUywz ANHyiJi1n5+B+cCplmyxPpUtL8GrYlbG1xX1l4s1mF8/+2SV6f4IkRsuo2Xluu9rJtL2LyKf22WI ulPkI8pQhZP6zFPmO9P6fUL9RomuU69rkbDb+kiM6iITgOLKNJgupk7OBp2wsRAWg67nQBWwvspE FaDH0XofJj254iMs62UCv1XpbVO55mrhTeK6j8CNlc6WZTnOsvWqSndr7zDLRhrH3rZWPLU61SJK RpvohpZ1M3tusiwqYxk65aMHk0b+dUrKqFDL7kuVgZb1WIUePsWyplJtWXfjH4F/AkS65We4HU/z k2zFSCF1d0t+GnuTLUu3t3VMkzsje7Clc5mS3GbZemoZJsuBcJGQCpwDmA1L4RV4rBJXDl6Ho9yd dS8VuQLqw83QFtrDENDlqvdTI4/DCWjcXKQP9IM7YRLcBw/o/DdY2NzMcTsIR641c9cq3kLthNtu FRkEI6FTO+TDaHgJ1sFWqNuJFgFawYKuXEl4B2qipbSABLgWekIvqEJtqgdXwbC+5APS4cckyp3M XQTPcwt/Cp/Bl/btHARrV4p8A7tWGr3lgnZjXU+l5/1+6fW/9VvJO471G9y8uF+TqpJ7ququp2YX 2mvLbO5xdL0/08Xcl2RUuKUFpcdqdy+o/YvGs34jRXIS9N6T0ByaEQkKN+26ww31J8qlP1e17g+N 65L09HT9ikZVNQtztGGrKuE54XmJnLoge3AOOimuM6e+FV4hJ7+zd9uCpKKVTm/+EDt+G1Fl3oSr LF1krrtE5FCrZL1Dj7XN0jNdDjUVnMHUTrkx2CifUTlOOxcuFzVVKhez5qr7vgTrkURLK7wFcXyn M+v5VS5muT3vdAWLCvval7dSnu5rR1cz1k3m1VZ+4n2ma4rUFsTzLdMsdFnUPl2B03cZzHKwvtOZ VRw3OL2NAjUI9Nas1cmgUzXVQEjqa1RjkYKKFGwutXWtVWnQa6wfAdBrqE2vLpD/PhE+gHAiVYLH YB/HSOUYNyB/DKywb++pbsf4CnbDvzjQQViBjPXQj/SDYRsV4nM4TKf5O4yP5iaBcWg+UyES46YW xEFL6ANDIAsWwyEqoFbCPVTon2BAA5oiSIeH4FF4CZ6hI16mhiWKy60Q3oR6CXHQErqizKTAwqtE 1kBzbpSEeDNV+GuIoeNrCrdAT+gL42EyZMDDMBeWwwfwGeyHXyEX2qME3AmpMBVmwtPwGqyEzbAd nruO5h3qtyIN/ASRKFgxN4rUgXSYB38kco1a01TCWHgZ1kLCTSJtYAiMgcltOQfwEeyE37hex2FQ exQFCEU7rAP330YZYD4shUdR6BZAV65rP0ixr/F3cBBCutBoQTTX/HL4AvbBETgBFW5nH1wJ8dAJ +sEYuB9iMObrwx1wN/wDDkEHmv++UL0PXQispS5tg93aFfQ1U3xfhM/hXxB8B/mAfpACaZAOC+AV +MsAjg2vwRrYCf8H8XQn10IvGAJztXuBJQO5hlBnEF0kNEORbQMd4Q64E0bC57AXeqCJ9YWtsAOO gAONJxntbArMRwtdDKtgHfwEf8AelL1j0BkttCe8jgb0NpxAGw1FG+0FSbABPoR70EofgHmwCHLg BOxCU/0eHkKjexy+gN3QGCXyapgKM6FVNuWAWmhYdSAXzS8ETSseEuAz2Ant0Qb7QBaa7rPwMcrc t/Ak2m42HEBL/BmaoZ1dDyMgDabADPgEvoBYNMl6cBcMhbuXFXwkeArMhifgF7TNXNiMpvcpfIs2 vfcd84HREfAbmrV+iDIUhbICVIPq+lJLX2NBNrwEk9+jrDALHoa/w3ZwQSUU6CoQvcY8ish7HKH0 stFHE33sxxP94F1YB7/C71Bjg3k8cTHUgetRxtvAABgIL8NbsAr+ttG0f2FSK0C5wHmGj3+qOC2C bLdweYKKSKOb9raqHcykh50F2zAStsMBzLmfYHos2gJIbXoZmA6Pw3uwB7phKIyHp+lBX4ZsetDl 0Jee8m7oRY81ADrQY3WES66nN4Aa9FgXQU96qt7wIb3VNpiJGvkIHIPjMJMeaQ7cSk/Usb3plVLg H/Cd3TtVguWwCpLpmYbeZnqradCBHqpLR9NbPQnH6JlytYfCPP3/zqaXirB7qVqQ0hPtAEJ60SLA FJgDzt5osL3NghN39C7ofXShiSN9CnqdvF5hwlDSwijs71TYit29H+pgezeGt7BvV0PXDFruDLOY wr4Ms5BCl+lmEYVdM8yCCXfMMgsZvAO6kEGmvZhBBzgGIdjtNWjpL8syixE8nWUWI2g/zyxA0GaB WXDgYnuRgfELzYIC9ewFBQbZCwq8ai8ocPhZs4hAx2yzkMAD2WYRgcaLzYIBNZeYxQIaQAS9RNQL RfcWeb3EGnqGPbCRnmETVKQHiIDboRvMhafeNAsGNFab/m16ybfNAgHLYQgt/L0QQmtd+b2St9J5 rfKk9ykHvAbLIZLW98JNea1wzQCnDV8tU5BHHJerumVJ+HrYkir9+esk7aWztJYe0gVfO347yS1Y N/2thyH6yKY/KVNlkBXXDHpoXuj/JkjoSshg69HPUKQ3IaW+yh/Kf8ky3goZw2+a9eo+jX3DrHT6 iryJZZ2dWuombqmbShw+za/vUnfGdx3H622V+2bK2xtruj/lv8UqU3/OxThrCILafPqif7yVzgxQ SLZ8OrhgKL9lmedk9gw+T6+U/weKdxVx1Vr7HMoRSwzz+E5Lr/vGWPJTreOqFB0cMpj/Dk79qtuO +E3xb8Yv4XdnfKwMcJXddb06/7r6L2EKeb7Oyu8kK/96XsZZw0i0FtzLnryc9LeGsugevd7dOAdt ka7X9hZc/URha+llhXTjtyuuew24hfOmOW3Kb0HqhDK8rlefxHU9N0vt7+F3W7s263Cj0VaqCVZZ C9ogrZcPuxa5Ul0TXffYAxXKtm42c6ub/vLbxc7vcEm1r8BQjxj9rUfsyVZpku17q+DK6FM289es DM9485M444ESnO4SREmuy94ixWNzyM4p11XMHDS0iyvS809kbeTuKk9H9X/d177nO2bUqSEVnN77 HPJtdPNGkUXsG1S7YTOzzzsvYW22NZu/Pqu1r+OtSElpW5TMI1Vad1yU9vVwX/uWXxzT5XDjD673 te94k//t6igiL7fW+rzna7lLc32li2zYc8hLbS5N8bWv5VWRaTdfNLuer325E36ftPG+7b187dsT 9tXkos7LLxNPFLmvuM0hDa3n177iBcdgEWTsCIrKiP/jwi0h4tgRFDoAfxL+1Pr571T4DT7JpBo/ Ln+IjSM45OSSh9jJ46zRdLaIMF8iEpxRGX//3RKR4EREgjMJPyLC3ETEkZ8CMRVORkwFDzFxKPJu oiK8RWWHRGUkHbdEZYcgKjskCT+iInyIiqOo7uIqe4kLD4vKOHbMEhcehrjwsCT8iKtchLg4CS0s 0q3C+BEZWYzIOM5oYbH5A1tssWnhURmZRy2xaeGITQtPwo/YKD9i4/TFmBEtnpsRPdwRlZGVa4ke 7kD0cEcSfkQH2aLZnCddSZ2Sl688ASdZTUPFvWD5Qk6uooaL59kpEOSrqhZZvyp6CXIWFnYylbWS T2EhHgJPorpWKVJgqKdQrwpbZM2qWqzQMC/BJa6y1fwKDreF5zUH7lsJKm0De3W0U6nxPhJLMYlN ylL2BWfDjdZIKsY76tGbX7Zsx1Wxy5Ja1F4mUmfZHGfdzN2OyzNFrsBfA2KWZSKmQrzv+F3D6mbu 84iP9MBckMBcEJ0L0jIwF6T8boGRu2dZSFmO3NXxsNvgY/gEtsMxyAUXhBAtVF98QDhUgIpQCSrD SBgF/wPTYBE8B59uMiPnd8Me2Av7IAd+hagPRKpBa2gPnaAz3A7doDsMhDEwFu6HaZAB02EGzIWn 4EV4Gd6EFbAK3oXV8CFsh4PwI9TaLHI51IcGm80Y2CabzffvngH9/l1raAN94V4YC1u3mO/i6RjU rJEOawzxfw7/dEgOHT5w2PrnO/4O2X/u/+09xJ+6uw/t3b238L6CNDu26nUr7qtd7l/3CovvEKP/ ONWVysE6iln0/57hGoYmFszeMP0PN39/Nd1f6Dtlnc/CkdsTAyO3rZHbE8ti5Hac15/pqa+h1w70 2Of+FjPZIZdC7GRHMZ/XDGzn2Jb3DdCg4h7Q+9oC84UD84UD84XPv/nCujVrpGdIZ+5K/sxd/b+Z VQaRdjQG7aEDTICJ0BnzowvsDxP5NwypIDIU5sMC2B9BOPwBuVARjTMCtmBIboV5FxAXHquO5gK7 orEp4Dc4Cicwjf6Ai9G0/gl7YSJa6iRozcltAztriXwDVdFco6AHzIO9l5gZTiNgORy91MxNexA+ hMhY0sDl8ABMgScgvA7aHDSBgZAGi+B1eARtbza8CL/ArxB8OXYNdIP7oUE9NERoBI2hCQyD4TAS RsH8eubrZtkQ00DkIugMY2EJPA/R1NXhkAKjYDSkQhqMgbGwElbBu7Aa1sAvcBTiuZ7NGxmb/MK8 S5+//ma0V4hHHPGVym+IBFYfPttCyqpc5f/8+K3zpQuRMpJT/kPkjEouSZxSpVokblu6UjjV2bj6 sOJbcrRXiF85Unyc8hYiJcizMj+x3K+NkeiRyEeq0j8vnmGzETaLlOvngvoEI/Bc0DzR0XNx6s8G S7aqwzq7bIGVHc70yg67sC1Cr8A+gQhoCddeYew29xUE8tYOmGZfwbX2VdQ7/DxZO0A33aNd3SOU IRN0sEcYJmtDSIAsIq+Ez4j0DfwEv8JGTLIPoTYm2JUNjMmVZ3Yp99ioCXavbYaNgy/gW4jkclwI TW3zqyxm7en2BgVbCS9wal6CXK5ZzYtE+tI4D4IDNNA5MJObdOllxrStEWvM2hmxxqSNqmPM1yfq GtNznZqk3NCTrix5OQvKVTbzf87nGT+BeSSBeSSBeSSBeSTn7yyMQAnOhhJ0LScl0FZMW7mbrHZu jFtPGpjNE5jN4x0vMJsnMJsnMJvHTUBgNk9gNk9gNs/ZOpsncKOdqzfaKd0rxSfuQ51baupcH61z fahzSz1qfJGJY4LzjxwTTOKY4EK3uCbLn7zgtkUUk+0uHRxyO1j616qc4o9vRndZIpL0+EnWKK/8 4+vm6/iRxWS+SweRrh2CyYOYPDSx7r5Sn8CKxSYuSXtTqmau9Cm1Rqph455IjQR3vxob7n5V+N39 avy4+9VwcferkePuVwPM3a9Gl7tfjQZ3vxom7n41cNz9aiy4+9XgcveroeHuz7XHs6WvH+XQc6bG ja/9/7b3u05xm42cWDHXp0aiFNr2Q0RVvUr7JSrjEtcA3CRcjxsjT1SfoFGO7E9MUk9Rwx15orSe ZeWa+uV1j7lcBc1VcZt5+1PB6QgKV7eSuq5ER7rDGnumxMbq+TF+kRstd65rw32O6iLhjkHtnDLY mskyzMxkcUSQNaGUxle5IFI9ItHNEhq01rzfECd3clVoUsOMlRthj5FbBC3qi3SHHtATesFdkAL3 wTPwKrwN78Ba2AQfwGbYAl/CL3AComk7ajQoGHu3B47DEMozFIY1LBh7N7Jh4bF3vl6K6Ni7HyAH fobDDc04vMbcJU3sl0FXNzLv6uLlic8kUXRM9HitH00lxnLj5UuXHT7Z+GvVcVj+UNvfqp7xd7PT zbbdObababtP2O4Ltvuu7e6x3eoTjNvKdjvabmfbHWC7I213tO2m2e4Y251ju9tt95+2W22iye/I Bo5EB+5o3GDctAYm/9Xt/b81NP6uE026jxs5EkMI344bhrujkdlfyS7/b39Rf7xkPWrczAzjVrP3 z7X91W1/lu2Ptv0Lbf/l043cabYbM9kc/+nptnzbXWjvr2mnrzLDhNfKk2/lQ1WrW6MzCQoKCg0O cYYEBTs9FUiH7fawH+XrfNrOuBNwu1kP1ZKtEQ3XICdIQkIcQY6w0KB8/c/97Wm6/nSXSaQZKKnW WIhm9ayjR4Q6g3Qr8uitZQzHTzZpLsz8b3vXAh1VdUXPSyY/tYioFNHaKSIilSRAQLSpYEgQCgkU UoQuVAYIJgKZmSTj8leatoosm6KitixLW1Sy+vHXZaFSNYJAsVVMbdUIrUVwWam/ioriB033vue+ mckkk8QQQeCdzM6Zd+fd++69775zf+ec59Qyx1m+lLTMVJ+ek5EZu5Q+loObhzX7pce8r1yKXmC4 iXN0elYG4qR0EGd17oNmgwnxtHZ86b60tPZqx9364xYJu4NRw028jNSslJS0FF878YImToWohbbW LGozWi+4Lb4U3/XntozvmgCUok7K7V2AfEGs2uNitYlYSOXYLLeUzZB7pFht+o1WQkXUsppvW6Ra /lXNv2y+xmxliPTDuG9I5pJM2V3rU8GNMAjBrcCWa8YuTjfrHadhKPJJP5aMEtsntT0xSpEL+4oM /ClD2SmPtsXunyq7e/rEoy5Rffr6jNWyGo9Tr1w+YCfhzqEvENWdptvp/afm5l7221C7OaceBa5E mwkKLSBcDwGq4xHzF9DybZ108EhriaDkyDShVknEtrt4u/1qe63TjdYIF+fnmGX9nBYbjzmtFvdz cDVenany7Hidk463BtqmQ+aJXNL6iRxkn8hUM6G++2T07r/gs8cBMp/Iyc6h80S+Uf8Y7mcW8jRx yjoN0krzqVZWD5l92ezLUqenTm8d9zhfb5FFjgSGikFwkIZvbH2qofidl2TfXboo+i03X+QDCPaB o/W4PX6CxCjfhr8/vjUfCZ4NwZmP+3LZBIzu4s6fO19kALqpLcW0BMIozfJTSvT3RL43CS8o196u sFyPO8P7g9+wENdEvhYFUW4clyN8nx0Bx5Nbbvd6iZQsXy4vt9e9y87rEuvzlIR0efwv8CfQoFOc WLxEzvSfbiOdxOMCe/1Ecu+Dyzu673sT0mM+xmbG8vMqWu525PeEeRh1O63jd5Wyy7W9ueUZO1H1 SFcuefP7W7etc5j/h7Ji7e7xSdrO0su1PX1RaKV4b+7y3tzlvbnLe3NXAnlv7vLe3MX1Bd5Dil7u 6Xhv7hLvzV3F3pu7vDd3eW/u6rf+MHhzF4U/97YShX+G7QBc4c9ztNM2fb5RlOKggauQvezvHh16 dLDb3wGF9+Y2781t3pvbvDe3eYjC7Qc66v85+Wuv/z9edDX0RFGjWipdcdWC+2V9Afq5wjxNIHWE iwWQOuIXI3GkHwDpYla/TwcGAGeIrpJC2ggkjVCZCPNMwRxNIHEEczPhIsYQ4d5ZzAcVpBAmxvR9 pav85wDcQoI0EsyhBNJIzhMx+0GjhTtCeHSE+1EihUARQEWlCwDMjwTSx3hCgJQxOzmQKsIFX0gT s9+DOQwm5GL2jjBfESolQZIIpIdwywRzFYHEEMxBZKbovgbmHZjGY2APYK4hmGcIpInZXywDIFEE 8wezYoq5g/FowJVT7spDyhg9gKCoZ4OwxLwbcGU1ImrpzxXWK0Qt/l1vB1xxhXQyXg8gnaRWPI1R T2PU0xj1NEb3N+aRrDG6b+ISbocm1RidVay/J5+DdY4ykY5fukVjdAGSOugao++jSyJuOrXSaIzy O2mb5fujMVqYomk8dbWmx7Q3YAD9IrAD2Am8BLwOvAdk3IwRCHA2MAoYDYwDJgGTgW8DU4BZQC2w BLgTuAtYBdQD5ctEFgNvA+8A7wJ7gKlxg9i2Bq/PAc/HDWLpNX/rRt3BCnEQNtr08lW872HpY3jI aoKGZYoNr7N8qeU3Wb7M8lWWr7X8BctPqFaeb/lEy0ssv9jyBZZXWh6yvMrypZY3Wr7d8l41ml/V 9AxZTc+Q1fTE9e3vqukZlsk1Gk81PUNW0zNkNT1DVqMyZDU7QzLFxr/VHpfa4+X2eJo9Vs3OsEy3 x6rJGZKZ9rjPYj2+2I3vaW62E8fT3OyMnthZVk/MZzr0ezEF2njI6okdSlSfVHPz0cc8zc3909y8 t03a3NDQ1NTYzseckEgdxvosnyZkA//r61esWXPv9uTU1Ni4Zs2ahgb9NDQ2bm5k7ho2t/nZ3HBr Xd385FRXd+2udi7mXnO7KS9yiLw1WGIG2hvvtSImlFDqxsa9e/fGn6M1UJ+cVpBujR41TDGaTWyf RUY+q3RWyi8r4FrG7vInUsflY37ui5ujL9HlEuktaY57ccrw9CztJ9braWYEv6Pf61vXb1vnuJpx gx1djl6bNibqjiqensZ1d3xsll9aUP95BYlBkKwpLUbWDPP3yc3kNJ3CtLnZ7Uli9CD/QeSHmlLH DTE9xGw8cTp4j++OXdqZLiv3vVFg8hufh1n465FwfS5NHNNGGvFELcDL7dzHdbiV6OCps9RXUhzO Nblu55a/IzqRVbJI64XGbJyepDpciUA6QDrAjcFMIAs4CjgaOAb4EtADOBbo6fCNRSK9gOMdvqtI Zz29HR0t9AE/CegLnAycApxqz/kquB8YBnyC49PA+wOnAwOAM4CBwEei5RpnzyOy8T3Hab3nmIew 4cAI4GxgJHAOcC7wDUe1fb8JnAeMcrS3PR8oAMa0kR7pcN/X/IGoFuaPRLVXrxP1CEqNTDzjUa+o PxbV0PyJxLyjYuJkNDapZHaLtPSSSi+iy0U9pd4u6i2Vmp0YAEW9pq4U1fS8U9R76ipRrU9qov5a 1JPqb0W9qVIz9R5Rj6rUUL1fYlqqdidB3hdtK++C/1PU6+qfgIeAh0X9XFLb7lFpea83iCon8fuf RTXxHgf+AvwVeAJ4EtgCcNbcCPxNVMv578A/gGeAZ0UVnZqA54GtwDbgPeAxUW3ufwPbgReBHcBO 4CXRGfzLwH+AV4BdwH+BV4HXgNeBN4A3gf8BbwG7gbeBd4B+aL97RDUK94pq7X4ZYR+KlvVj8H3A JzwWOz52+Pm0mR59WfZE2c31/OKKOVXB6uC8Gv+Fwaq5/tv+eOPNZjRbPJXHhcE5RmLyezYOIgvL KmuyR8qecx4IS6foU2TEd1RKq3CGpDz31HMrsk/uecvPMuXrZ314HzuctISwlSjDTEf3JcDMmjjj cu2bfQDbJGUj7z3l5CbRPQveSy7z8Z6xW6NMZkl4D7iXwbrmPgbrlGmz7ijXKUeY/qpU3cdgHY0v Kh3rH19ZU1ZVWVbjL6wKzKuJ7nGUBqvLK2YHckqKxuRMml+RUxyoqY4gqAZBpaWqdMf9hVSbL3La F5Ff2yNT3C43GT+1p5abS1VTSif7Q4ErFwQDc/3zglULAzVk/uLJRRcMzvOfH5lbEcyZVlEdCSzw V9dUlQUWVssxPbU4zC6rp7SiZkGZubij6fMZdudmfhvM/RVGOk9iyoNsE5dMHl94yQXfGV8YraHz RXdLrjZqnHkyHP1cHkLzzOh3OIYHdP41BH+FJowKmUXAYKPYmGvUOkcYlUn+jcW370lLStZ+mK8d 1/3qnQ8nlfe8+2a0lTP+sA2TAdnkaD3zd8ovxnTLyLbASdcO0TbD/o3TdPZb3AjJdXRFYKKje17T HS03lwx4P2odbSN1tj0ud3SvbJWjbfEeR9vYakfb2CMJbamL99DENbcLcfmd+2cTKuZH5pRX5JQE F0aqAjljI/MjlYFLA9r+KnImVCDlgFRHonFxPr+zHCW87oLsuUFM1xnG+ppaXnFpWVXE7yYkYPyN +R8hFVQrN2VKkBcjs3OlcjTTX/ra07yO+d7nmf4PNK1zzPeX9zzMsaH5PuuOqzk+dJsfOe0dyWnz mLhG4NH+kyf/D7785zqQ4aKcqxSHt/wf5sl/OXzkf15n5P8jK8s6lP8rb/vahgT5z1VTcq6cevL/ c6Du0SNq23N7y3Pa8+NeksSLeczvMxdKayRorF+4GH+5iUff2DSxu9wszdOLeff5gabvWPUD7fme 93zPe77nPd/znu95z++5V4IDWwLPb7vnt731eR1oQjrRSJ7fds9vu3h+2z130gkJHuHGAUzc89ve cWTvQfMeNM8KJ0aeFc5nkTddEnNdj3kkW+FsKW7fCie3pHuscLZ2nxVOfsmhYIWzWMb0l6LNtcmS PlDk7Ic5UJ3dHxw/VD05PQ8sR7PaBTh5h4+ZUEiWLaBWY0gqFyq/z/LcoPJGy1NCPD9sHcyHrYP5 OLMiG15n+VLLb7J8meWrLF9r+QuWqwP5sHUgH7YO5MPWgXzYOpAPWwfyYetAPmwdyIetA/mwdSAf tg7kw9aBfNg6kFezIpoT0ayI5kJRsyL7e9Ss6AqNt8WaE9GsKEvaMSuy8aNmRfY4alZkj6NmRfY4 alZkj6NmRW58z6yonTieWVFnHMK7ZkVpnlnRAaXuMit6Ny/5b0eqWdFbu3a193mLn7q6utY2REcI 1devaGpsZD20X1Gd/rh2QzH/7/mT1+m9UKnl66T/96ti/t9LbQKb4s5ZHyeBu+b/nUT/7x+kxr6T Lva15v3j4vzQhm8e3JpTVPbOVouQKTmq+eWeH7lI/b/fMwTn4veqYeqJ5nY7D0nkETzO03Dek8PV g0vOCPVE89EM7dz2zdDzOsOZ/59fov7fbwyoxYD/u+hg2lB9css9Z0Tr30iRvJbcPc/lTJc0v0A5 65W93VCfetpxy+cSj2kl8TsIP06l3HiJnOkvyojlz00n8fgjW+5Ecu+Dyzu672553PSYjxGZsfzc 8S31/77lQvX/nhi/q/TKDNX+dMszIFctaNZvmDqKWmzMf+GZsXa385siNyDs0RlfJP/vB9L+z60Z zF+PePs/vtWCdDDs/wpZJVdpvTR/jtQd9n9nOp33Ldod9n9Fjkpt196QYeQTHNX7PdzsAdMwXGOr W2hUO66U8Wh98QNMVd1D72Tb/7No/7+PewYGov3Fp9dWe3PDWa+MTzHCHg4ftNvElt+5/DAvvwkU yEhc3yexdtwZxRPmY2SKGMUTx0wFGT4JUoCe1lzFE9Vznrlxe8PaTfdveVEGZQ9qo2y9cP2MuOu3 cUqbNM/y3AT581kJ8se8j5JlSlb+ROL47PrZWv7/A1BLAQIUABQAAAAIAAOb0yhDLQgSeJcAAACU AgAqAAAAAAAAAAEAIAC2gQAAAABkcmFmdC1pZXRmLWF2dC1ydHAtbXBlZzQtZXMtMDItUlRDUC1y MS5kb2NQSwUGAAAAAAEAAQBYAAAAwJcAAAAA ------=_NextPart_000_029B_01BFDA25.1A56BB40-- From rem-conf Mon Jun 19 12:02:39 2000 From rem-conf-request@es.net Mon Jun 19 12:02:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1346cV-0004Ex-00; Mon, 19 Jun 2000 11:50:03 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (lazzaro) by mail1.es.net with esmtp (Exim 1.81 #2) id 1346cU-0004En-00; Mon, 19 Jun 2000 11:50:02 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id LAA01271; Mon, 19 Jun 2000 11:50:01 -0700 Date: Mon, 19 Jun 2000 11:50:01 -0700 From: John Lazzaro Message-Id: <200006191850.LAA01271@snap.CS.Berkeley.EDU> To: lazzaro@cs.berkeley.edu, rem-conf@es.net, t-nomura@ccm.cl.nec.co.jp Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Dear John and all, > > Thanks for your comments. >> Rare will they be under a kbyte. Is SDP happy >> handling data chunks this large? > I think it is not happy for SDP to handle such large data. [...] > As described in draft-ietf-avt-rtp-mpeg4-es-01.txt, > this can be done by setting the cpresent flag to 1. This sounds like a good solution, I didn't realize there was an alternative mechanism to transmit large config data blocks ... >> So in this sense, >> an uncorrected error in an SA_access_unit can essentially destroy all >> audio produced after the error, for the rest of the performance. > I think re-transmission can be applied. [...] This sounds reasonable -- also, any SA_access_unit can be folded into the StructuredAudioSpecificConfig, which as you note above can be transmitted out of band in a reliable way while staying within the spec. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Mon Jun 19 16:25:44 2000 From rem-conf-request@es.net Mon Jun 19 16:25:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134AjS-0000f7-00; Mon, 19 Jun 2000 16:13:30 -0700 Received: from dnai.com [207.181.194.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 134AjR-0000ep-00; Mon, 19 Jun 2000 16:13:29 -0700 Received: from hariv (cougar.chiplogic.com [216.15.52.34]) by dnai.com (8.9.3/8.9.3) with SMTP id QAA84201 for ; Mon, 19 Jun 2000 16:12:24 -0700 (PDT) Message-ID: <00e101bfda43$2226dee0$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: Subject: DTMF Date: Mon, 19 Jun 2000 16:07:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everyone, I would like to know the need for DTMF generator and Detector? Where is it positioned? And also how is it sent ? Normally speech data is sent as payload in RTP. Do we need to send both Speech as well as DTMF in RTP? If so how? Can anyone clarify DTMF related issues for typical VoN applications? Regards Hari From rem-conf Mon Jun 19 18:36:32 2000 From rem-conf-request@es.net Mon Jun 19 18:36:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134CvW-0002kf-00; Mon, 19 Jun 2000 18:34:06 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 134CvJ-0002jh-00; Mon, 19 Jun 2000 18:33:55 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id KAA18044; Tue, 20 Jun 2000 10:33:40 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id KAA11462; Tue, 20 Jun 2000 10:33:40 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id KAA11132; Tue, 20 Jun 2000 10:33:39 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id KAA42053; Tue, 20 Jun 2000 10:33:38 +0900 (JST) Message-ID: <009901bfda57$8821f540$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" Cc: "Yoshihiro Kikuchi" Subject: Draft revised I/D of MPEG-4 A/V RTP Date: Tue, 20 Jun 2000 10:33:26 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0094_01BFDAA2.F7A4E800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0094_01BFDAA2.F7A4E800 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear Stephan, Injong, John, and all MPEG-4 on RTP experts, Please find attached a revised text of the MPEG-4 Audio/Visual RTP Internet-Draft. Change from the previous version is the upgrade of the English quality. I hope that the English quality is now an acceptable level. There is no technical change from the previous version. Please note that this is NOT a final version. I recognize that we need a conclusion on the following matters to finalize the I/D: (1) How to proceed NEWPRED RTCP. (2) Minor revision on the Audio RTP and its MIME type. Regarding (2), I saw a message from John for the agreement on the revision proposed by Nomura-san. A text for the revision will be sent soon to the reflector by Nomura-san for the final approval. Regarding (1)... It was proposed by Fukunaga-san to keep and revise the NEWPRED RTCP description. I must admit that I hesitated to reflect the proposed text to the I/D. I'm not sure whether we have get an agreement to go such way, or some another. I will reflect the proposed change if we get an agreement. Again, The final I/D will contain ONLY items that can reach to a consensus among the whole group. In other words, a part of the I/D which cannot reach to a consensus may be removed. The decision will be made depend on the comments through the reflector, but not only the opinion of the proponent. We are keen to have discussions to get a consensus. However, we do not want have round discussions again and again. It will defer the process of the agreement of the whole document, including RTP part, that we must avoid. We would like to define a deadline at middle of this week.(except for editorial changes and very minor revisions) An item that cannot get agreement by then may be removed. Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 ------=_NextPart_000_0094_01BFDAA2.F7A4E800 Content-Type: text/plain; name="draft-ietf-avt-rtp-mpeg4-es-02-draft5.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mpeg4-es-02-draft5.txt" Internet Engineering Task Force Yoshihiro Kikuchi - = Toshiba Internet Draft Toshiyuki Nomura - = NEC Document: draft-ietf-avt-rtp-mpeg4-es-02.txt Shigeru Fukunaga - = Oki Yoshinori Matsui - = Matsushita Hideaki Kimata - = NTT June 20, = 2000 RTP payload format for MPEG-4 Audio/Visual streams Status of this Memo This document is an Internet-Draft and is in full conformance with = all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering = Task Force (IETF), its areas, and its working groups. Note that other = groups may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months and may be = updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to = cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes RTP payload formats for carrying of MPEG-4 = Audio and Visual bitstreams[2][3], and an RTCP format for MPEG-4 upstream messages functionalities[4]. For the purpose of directly mapping = MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications = for the use of RTP header fields and also specifies fragmentation rules. = It also specifies an RTCP packet usage to carry MPEG-4 upstream = messages. Finally, it provides specifications for MIME type registrations and = the use of SDP. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 1] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 1. Introduction 1.1 Why MPEG-4 Audio/Visual RTP format needed? The RTP payload formats described in this Internet-Draft specify a = way of how MPEG-4 Audio and Visual streams are to be fragmented and mapped directly onto RTP packets. H.323 terminals are an example where such RTP payload formats may be used. MPEG-4 Audio/Visual streams are not managed by MPEG-4 Systems Object Descriptors [6] but by H.245. The streams are directly mapped = onto RTP packets without using the synchronization functionality of MPEG-4 Systems [6]. The semantics of RTP headers in such cases need to be clearly = defined, including the association with MPEG-4 Audio/Visual data elements. In addition, it would be beneficial to define the fragmentation rules of = RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resilience tools provided inside the MPEG-4 Video stream. These issues, however, have yet to be addressed by other RTP payload format specifications. 1.2 MPEG-4 Visual RTP payload format MPEG-4 Visual is a visual coding standard with many new features: = high coding efficiency; high error resiliency; multiple, arbitrary shape object-based coding; etc. [2]. It covers a wide range of bitrate from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to = mobile networks with high error rates. With respect to the fragmentation rules for an MPEG-4 visual = bitstream defined in this document, since MPEG-4 Visual is used for a wide = variety of networks, it is desirable not to apply too much restriction on fragmentation, and a fragmentation rule such as "a single video = packet shall always be mapped on a single RTP packet" may be inappropriate. = On the other hand, careless, media unaware fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are flexible but = manage to define the minimum rules for preventing meaningless fragmentation and = for utilizing the error resilience of MPEG-4 visual. While the additional media specific RTP header defined for such video coding tools as H.261 or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, in MPEG-4 Visual there = are already error resilience functionalities for recovering corrupt = headers, and these can be used on RTP/IP networks, as well as on other = networks. (H.223/mobile, MPEG-2/TS, etc.) That is why no extra RTP header = fields are defined in the MPEG-4 Visual RTP payload format proposed here. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 2] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 1.3 MPEG-4 Audio RTP payload format MPEG-4 Audio is a new kind of audio standard that integrates many different types of audio coding tools. It also supports a mechanism = for representing synthesized sounds. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequences of audio data with relatively small overhead. In audio-only applications, then, it is desirable for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto the RTP packets without using MPEG-4 Systems. Furthermore, as is true for other audio coders, if the payload of a packet is a single audio frame, packet loss will not impair the decodability of adjacent packets, and a payload specific header for = MPEG- 4 Audio will not be required. 1.4 MPEG-4 Audio/Visual upstream messaging on RTCP packets MPEG-4 Audio/Visual upstream messages are extremely Audio/Visual specific, since coders directly use them for controlling coding parameters, for which purpose, these messages need to be transmitted without delay. For this reason, here, these messages are directly = mapped onto low delay RTCP packets. Such RTCP packets are limited, however, = to use with certain particular profiles (e.g. MPEG-4 Visual Advanced = Real Time Simple Profile, NEWPRED tool). 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [7]. 3. RTP Packetization of MPEG-4 Visual bitstream This section specifies RTP packetization rules for MPEG-4 Visual = content. An MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode is used so that configuration information will be carried to the same = RTP port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC = 14496- 2 [2][9][4]) When the short video header mode is used, the RTP payload format used = MAY be that specified for H.263 in the relevant RFCs or in other relevant standards. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 3] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 4] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | = RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | = Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | | RTP | MPEG-4 Visual stream (byte aligned) | = Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - An RTP packet for MPEG-4 Visual stream 3.1 Use of RTP header fields for MPEG-4 Visual Payload Type (PT): Payload type is to be specifically assigned as the MPEG-4 Visual RTP payload format. If this assignment is to be carried = out dynamically, it can be performed by such out-of-band means as H.245, = SDP, etc. Extension (X) bit: Defined by the RTP profile used. Sequence Number: Incremented by one for each RTP data packet sent, starting, for security reasons, with a random initial value. Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. A constant offset, = which is random, is added for security reasons. For a video object plane, it = is defined as vop_time_increment (in units of 1/vop_time_increment_resolution seconds) plus the cumulative number = of whole seconds specified by module_time_base and, if present, = time_code of Group_of_VideoObjectPlane() fields. In the case of interlaced video, = a VOP will consist of lines from two fields, and the timestamp will indicate the composition time of the first field. If the RTP packet Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 5] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D contains only configuration information and/or Group_of_VideoObjectPlane() fields, the composition time of the next = VOP in the coding order is used. If the RTP packet contains only visual_object_sequence_end_code information, the composition time of = the immediately preceding VOP in the coding order is used. The resolution of the timestamp is set to its default value of 90KHz, unless specified by an out-of-band means (e.g. SDP parameter or MIME parameter as defined in section 6). SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 3.2 Fragmentation of MPEG-4 Visual bitstream A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation. (1) Configuration information and Group_of_VideoObjectPlane() fields SHALL be placed at the beginning of the RTP payload (just after the = RTP header) or just after the header of the syntactically upper layer function. (2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function. Note: The visual_object_sequence_end_code is regarded as the lowest function. (3) A header SHALL NOT be split into a plurality of RTP packets. (4) Two or more VOPs SHALL be fragmented into different RTP packets = so that one RTP packet consists of the data bytes associated with a = unique presentation time (that is indicated in the timestamp field in the = RTP packet header). (5) A single video packet SHOULD NOT be split into a plurality of RTP packets. The size of a video packet SHOULD be adjusted in such a way = that the resulting RTP packet is not larger than the path-MTU. A video = packet MAY be split into a plurality of RTP packets when the size of the = video packet is large. Here, header means: - Configuration information (Visual Object Sequence Header, Visual = Object Header and Video Object Layer Header) - visual_object_sequence_end_code - The header of the entry point function for an elementary stream (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject()) Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 6] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D - The video packet header (video_packet_header() excluding next_resync_marker()) - The header of gob_layer() See 6.2.1 "Start codes" of ISO/IEC 14496-2[2][9][4] for the = definition of the configuration information and the entry point functions. The video packet starts with the VOP header or the video packet = header, followed by motion_shape_texture(), and ends with = next_resync_marker() or next_start_code(). 3.3 Examples of packetized MPEG-4 Visual bitstream Considering the fact that MPEG-4 Visual covers a wide variety of = networks ranging from scores of Kbps to several Mbps, and from those = guaranteed to be almost error-free to mobile networks with high error rates, it is desirable not to apply too much restriction on fragmentation. On the other hand, careless, media unaware fragmentation will cause = degradation in error resiliency and bandwidth efficiency. The fragmentation = criteria described in 3.2 are flexible but to define the minimum rules to = prevent meaningless fragmentation. Figure 2 shows examples of RTP packets generated based on the = criteria described in 3.2 (a) is an example of the first RTP packet or the random access point = of an MPEG-4 visual bitstream containing the configuration information. According to criterion (1), the Visual Object Sequence Header(VS = header) is placed at the beginning of the RTP payload, preceding the Visual Object Header and the Video Object Layer Header(VO header, VOL = header). Since the fragmentation rule defined in 3.2 guarantees that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning = of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code. (b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a video packet in the VOP following the configuration information. Since the length of the configuration information is relatively short (typically scores of bytes) and an RTP packet = containing only the configuration information may thus increase the overhead, = the configuration information and the immediately following GOV and/or (a part of) VOP can be effectively packetized into a single RTP packet = as in this example. (c) is an example of the RTP packet that contains Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is placed at the beginning of the RTP payload. It would be a waste of = RTP/IP Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 7] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D header overhead to generate an RTP packet containing only a GOV whose length is 7 bytes. Therefore, (a part of) the following VOP can be = placed in the same RTP packet as shown in (c). (d) is an example of the case where one video packet is packetized = into one RTP packet. When the packet-loss rate of the underlying network = is high, this kind of packetization is recommended. It is recommended to = set resync_marker_disable to 0 in the VOL header to enable the adjustment = of the video packet size. Even when the RTP packet containing the VOP = header is discarded by a packet loss, the other RTP packets can be decoded = by using the HEC(Header Extension Code) information in the video packet header. No extra RTP header field is necessary. (e) is an example of the case where more than one video packets are packetized into one RTP packet. This kind of packetization is = effective to save the overhead of RTP/IP headers when the bit-rate of the underlying network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single = RTP packet loss. The optimal number of video packets in an RTP packet and = the length of the RTP packet can be determined considering the = packet-loss rate and the bit-rate of the underlying network. Figure 3 shows examples of RTP packets prohibited by the criteria of = 3.2. Fragmentation of a header into multiple RTP packets, as in (a), will = not only increase the overhead of RTP/IP headers but also decrease the = error resiliency. Therefore, it is prohibited by the criterion (3). When concatenating more than one video packets into an RTP packet, = VOP header or video_packet_header() shall not be placed in the middle of = the RTP payload. The packetization as in (b) is not allowed by criterion = (2) due to the aspect of the error resiliency. Comparing this example = with Figure 2(d), although two video packets are mapped onto two RTP = packets in both cases, the packet-loss resiliency is not identical. Namely, = if the second RTP packet is lost, both video packets 1 and 2 are lost in = the case of Figure 3(b) whereas only video packet 2 is lost in the case = of Figure 2(d). An RTP packet containing more than one VOPs, as in (c), is not = allowed. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 8] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+------+------+------+------------+ (b) | RTP | VS | VO | VOL |Video Packet| |header|header|header|header| | +------+------+------+------+------------+ +------+-----+------------------+ (c) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+------+------------+ +------+------+------------+ (d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ = +------+------+------------+------+------------+------+------------+ (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video = Packet| |header|header| (1) |header| (2) |header| (3) = | = +------+------+------------+------+------------+------+------------+ Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream +------+-------------+ +------+------------+------------+ (a) | RTP |First half of| | RTP |Last half of|Video Packet| |header| VP header | |header| VP header | | +------+-------------+ +------+------------+------------+ +------+------+----------+ = +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video = Packet| |header|header| of VP(1) | |header| of VP(1)|header| (2) = | +------+------+----------+ = +------+---------+------+------------+ +------+------+------------------+------+------------------+ (c) | RTP | VOP |Video Object Plane| VOP |Video Object Plane| |header|header| (1) |header| (2) | +------+------+------------------+------+------------------+ Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 9] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 4. RTP Packetization of MPEG-4 Audio bitstream This section specifies RTP packetization rules for MPEG-4 Audio bitstreams. MPEG-4 Audio streams are formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex) tool[5], and the LATM-based streams = are then mapped onto RTP packets as described the three sections below. 4.1 RTP Packet Format LATM-based streams consist of a sequence of audioMuxElements that = include one or more audio frames. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 4). The first byte of = each audioMuxElement SHALL be located at the first payload location in an = RTP packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number = |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp = |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | |RTP : audioMuxElement (byte aligned) = :Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - An RTP packet for MPEG-4 Audio In order to decode the audioMuxElement, the following = muxConfigPresent information is indicated by an out-of-band means. muxConfigPresent: If this value is set to 1, the audioMuxElement = SHALL include an indication bit "useSameStreamMux" and MAY include the configuration information for audio compression "StreamMuxConfig". = The useSameStreamMux bit indicates whether the StreamMuxConfig element in = the previous frame is applied in the current frame. 4.2 Use of RTP Header Fields for MPEG-4 Audio Payload Type (PT): Payload type is to be specifically assigned as the MPEG-4 Audio RTP payload format. If this assignment is to be carried = out dynamically, it can be performed by such out-of-band means as H.245, = SDP, etc. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 10] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Marker (M) bit: The marker bit indicates audioMuxElement boundaries. = It is set to one to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement. Timestamp: The timestamp indicates composition time, or presentation = time in a no-compositor decoder. Timestamps are recommended to start at a random value for security reasons. Unless specified by an out-of-band means, the resolution of the = timestamp is set to its default value of 90 kHz. Sequence Number: Incremented by one for each RTP packet sent, = starting, for security reasons, with a random value. SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 4.3 Fragmentation of MPEG-4 Audio bitstream It is desirable to put one audioMuxElement in each RTP packet. If the size of an audioMuxElement can be kept small enough that the size of = the RTP packet containing it does not exceed the size of the path-MTU, = this will be no problem. If it cannot, the audioMuxElement MAY be = fragmented and spread across multiple packets, following the rules below: (1) "payloadMux", which consists of payload elements, MAY be = fragmented across several RTP packets, so that each of those RTP packets will contain one or more payload elements. Individual payload elements themselves SHOULD NOT be fragmented. (2) If the audioMuxElement includes StreamMuxConfig, StreamMuxConfig SHALL be included in the RTP packet that contains the first payload element. 5. RTCP Packetization of MPEG-4 upstream messages This section specifies the usage of particular RTCP packets to carry = the upstream messages generated by MPEG-4 decoders to advise = corresponding MPEG-4 encoder, using the MPEG-4 Audio/Visual upstream messaging functionalities. This particular RTCP is called _RTCP-MP4U_ in the following. In the current specification, NEWPRED in the MPEG-4 Visual Advance Real Time Simple (ARTS) Profile[4] is the only tool which = uses this RTCP-MP4U payload specification. The RTCP-MP4U packet SHALL ONLY = be used when it is indicated by some out of band means that the corresponding MPEG-4 Visual codec is compliant with the ARTS profile = and it is indicated in the configuration information of the MPEG-4 visual bitstream that the NEWPRED tool is enabled (newpred_enable is set to = 1). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 11] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 5.1. Abstract of NEWPRED in the ARTS profile The NEWPRED tool in the MPEG-4 Visual ARTS profile is an error = resilience oriented tool using the upstream messages from the decoder to the encoder. As the inter-frame coding is used in the MPEG-4 Visual, the image degradation resulting from a packet loss will be propagated = toall predicted frames following the damaged frame. In order to prevent = this type of temporal error propagation, a complying encoder may switch reference frames of the inter-frame coding, according to the = information available in the received NEWPRED RTCP-MP4U. As the correctly = decoded frame is used as the reference frame, the error propagation is = refreshed. As neither the re-transmission nor the intra refresh are used, the = coding efficiency can be kept comparatively high, although using older = reference frames then the most recent one does add bits due to less efficient prediction (e.g. through longer motion vectors due to a longer time interval for prediction). And the NEWPRED can achieve the faster = error recovery than the intra refresh as well. There are two types of upstream messages; acknowledged message = (NP_ACK) and non-acknowledged message (NP_NACK). NP_ACK and/or NP_NACK = messages are transmitted on the RTCP-MP4U packets in the NEWPRED. The = selecting methods of reference frames depend on the kind of used messages. 5.2. RTCP-MP4U packets for low delay The RTCP-MP4U SHALL be treated as a completely different kind of RTCP traffic, not following timing rules associated with normal RTCP information. The performance of MPEG-4 tools using upstream messages (such as NEWPRED) is sensitive to the delay of the upstream message = and does not require the full reliability of the upstream message. = Therefore, it is more effective to send the MPEG-4 upstream message packets as = soon as possible, i.e. as soon as a packet loss is detected, without = adding any random delays. 5.3. Congestion control In the cases of the demand type of intra refresh or the = re-transmission, the number of bits during congestion is greater than that in the = error free condition. This may cause more congestion. While in the = NEWPRED, as the intra-frame coding is not used, the bit increase is much lower = than that of the intra refresh or the re-transmission even in the case of packet loss. NEWPRED is less of a burden for the congestion. The amount of traffic necessary to convey NEWPRED RTCP-MP4U depends = on the strategy of the reference frame selection by the encoder, the = type of upstream messages sent by the decoder, frame rate, and network conditions. In order to avoid the congestion, the amount of upstream message packets should be small. In the NEWPRED, the decoder can = control the amount of the upstream message packets by not sending some = upstream messages; For example, in the case that the NP_NACK messages are = mainly used to select the reference frames in the encoder, the decoder may = not Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 12] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D send the NP_ACK messages even if it receives downstream data. On the other hand, in the case that the NP_ACK messages are mainly used in = the encoder, the decoder may not send the NP_NACK messages. The amount of = the upstream messages is at most 5% (normally about 1%) of the visual downstream data. Especially the amount of NP_ACK messages is decreased in the case of packet loss. Therefore the NP_ACK message has no additional burden = on the congestion. On the other hand, NP_NACK messages corresponding to = the lost packets are usually sent after the congestion, because the = decoder detects the packet loss after it receives the next downstream packet. Again the NP_NACK message has little additional burden on the = congestion. To reduce the number of RTCP-MP4U packets, multiple upstream messages = can be concatenated in the payload of one RTCP-MP4U packet. In this = case, it is desirable to send these concatenated messages as soon as possible. The RTCP-MP4U transmission interval depends on the interval of = decoding the visual downstream data. Both the receiving interval of the = visual RTP packet and the decoding time for each packet data have some = jitter associated with them. Therefore the RTCP-MP4U transmission interval = has some jitter by itself. It is effective for the congestion control, = and there is no need to add any random delays. This means that the = amount of jitter is enough to avoid another congestion in the case of unicast. 5.4. Limited to Unicast Although NEWPRED can work in multicast when the number of decoders is small, in order to avoid additional congestion, the NEWPRED over = RTP/RTCP SHALL NOT be used in multicast. 5.5. Relations with SR and RR The RTCP-MP4U packets SHALL be treated as a completely different kind = of packets from the normal RTCP packets such as SR, RR and so on. For example, if the RTCP-MP4U packets is included in the calculation = of RTCP sending interval, the RR packets should be generated in the = timing of the RTCP-MP4U packets. In this case, the interval of the RR = packets would be smaller than 5 seconds, and the number of the normal RTCP packets is much increased. This is bad from the view point of the congestion. Therefore all RTCP-MP4U packets SHALL be ignored when analyzing the information in the sender and receiver reports (SR and RR), and only normal RTCP packets SHALL be used. Multiple RTCP-MP4U packets can be concatenated without any = intervening separators to form a compound RTCP packet. The normal compound RTCP packet SHOULD start with SR or RR packets. However in the case of compound RTCP-MP4U packet, other normal RTCP packets SHALL NOT be included, and only RTCP-MP4U packets SHALL be included in one = compound RTCP-MP4U packet. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 13] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 5.6. MPEG-4 Visual upstream message packets definition 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P| UMT | PT=3DRTCP_MP4U | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | MPEG-4 Upstream Messages Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets = as in RTP data packets. padding (P): 1 bit If the padding bit is set, this RTCP-MP4U packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of = how many padding octets should be ignored. In the case several = upstream messages are mapped onto one RTCP-MP4U packet, padding should = only be required on the last individual message. upstream message type (UMT): 5 bits Identifies the type of the MPEG-4 upstream messages. 0: forbidden 1: MPEG-4 Visual NEWPRED in the ARTS Profile 2-63: reserved In this internet-draft, only the NEWPRED in the ARTS profile is assigned as the candidate of the UMT for the moment. Some other MPEG-4 Audio/Visual applications using the upstream messages may = be assigned in the future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant RTCP_MP4U (TBD). SSRC: 32 bits SSRC is the synchronization source identifier for the sender of = this packet. MPEG-4 Upstream Message Payload: variable The syntax and semantics of the MPEG-4 upstream messages are = defined in the ISO/IEC 14496-2/3[4][5]. All messages are byte aligned. Normally one message is mapped onto one RTCP packet, and several messages with same UMT could be continuously mapped onto one = RTCP packet. One message SHALL NOT be fragmented into different RTCP packets. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 14] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 6. MIME type registration for MPEG-4 Audio/Visual streams The following sections describe the MIME type registrations for = MPEG-4 Audio/Visual streams. MIME type registration and SDP usage for the = MPEG-4 Visual stream are described in Sections 6.1 and 6.2, respectively, = while MIME type registration and SDP usage for MPEG-4 Audio stream are described in Sections 6.3 and 6.4, respectively. (In the following sections, the RFC number "XXXX" represents the RFC number, which should be assigned for this Internet Draft.) 6.1 MIME type registration for MPEG-4 Visual MIME media type name: video MIME subtype name: MP4V Required parameters: none Optional parameters: rate: This parameter is used only for RTP transport. It indicates = the resolution of the timestamp field in the RTP header. If this = parameter is not specified, its default value of 90000 (90KHz) is used. profile-level-id: A decimal representation of MPEG-4 Visual Profile Level indication value (profile_and_level_indication) defined in = Table G-1 of ISO/IEC 14496-2 [2][4]. mpeg4-newpred-upstream-message: A boolean number to indicate the receiver capability of sending the upstream message of NEWPRED in MPEG-4 video. The upstream messages are delivered on the particular RTCP packets which are described in Section 5. This capability = exist when and only when the "profile-level-id" is 145, 146, 147 or 148 (Advance Real Time Simple Profile/Level 1, 2, 3 or 4). Example usages for these parameters are: - MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v; profile-level-id=3D34 - MPEG-4 Visual Advanced Real Time Simple Profile/Level 1: Content-type: video/mp4v; profile-level-id=3D145; = mpeg4-newpred- upstream-message=3D1 Published specification: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 15] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D The specifications for MPEG-4 Visual streams are presented in = ISO/IEC 14469-2[2][4][9]. The RTP payload format is described in RFCXXXX. Encoding considerations: This type is defined for transfer via RTP. The RTP packets must be packetized according to the MPEG-4 Visual RTP payload format = defined in RFCXXXX. Video bitstreams must be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). A video bitstream is = binary data and must be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer via RTP. The RTP packets must be packetized according to = the MPEG-4 Visual RTP payload format defined in RFCXXXX. Security considerations: See section 9 of RFCXXXX. Interoperability considerations: MPEG-4 Visual provides a large and rich set of tools for the coding = of visual objects. For effective implementation of the standard, = subsets of the MPEG-4 Visual tool sets have been provided for use in = specific applications. These subsets, called 'Profiles', limit the size of = the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each = Profiles. A Profile@Level combination allows: o a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and o checking whether MPEG-4 devices comply with the standard ('conformance testing'). The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this = parameter mutually to the same value. Applications which use this media type: Audio and visual streaming and conferencing tools, Internet = messaging and Email applications. Additional information: none Person & email address to contact for further information: The authors of RFCXXXX. (See section 9) Intended usage: COMMON Author/Change controller: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 16] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D The authors of RFCXXXX. (See section 9) 6.2 SDP usage of MPEG-4 Visual The MIME media type video/MP4V string is mapped to fields in the = Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (video) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4V) goes in SDP "a=3Drtpmap" as the encoding = name. o The optional parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "profile-level-id" MAY go in the "a=3Dfmtp" = line. The optional parameter "mpeg4-newpred-upstream-message" MAY go in the "a=3Dfmtp" line, when and only when the "profile-level-id" is 145, = 146, 147 or 148(Advance Real Time Simple Profile/Level 1, 2, 3 or 4). These = two optional parameters are expressed as a MIME media type string as a semicolon separated list of parameter=3Dvalue pairs. The following are some examples of media representation in SDP: Simple Profile/Level 1, rate=3D90000(90KHz), "profile-level-id" is = present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V/90000 a=3Dfmtp:98 profile-level-id=3D1 Advance Real Time Simple Profile/Level 1, rate=3D25(25Hz), = "profile-level- id" and "mpeg4-newpred-upstream-message" are present in "a=3Dfmtp" = line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V/25 a=3Dfmtp:98 profile-level-id=3D145; = mpeg4-newpred-upstream-message=3D1 6.3 MIME type registration of MPEG-4 Audio MIME media type name: audio MIME subtype name: MP4A Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. = The default value is 90000. Other rates CAN be specified only if they = are set to the same value as the audio sampling rate (number of samples per second). Optional parameters: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 17] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in ISO/IEC 14496-1 [11]. This = parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. object: a decimal representation of the MPEG-4 Audio Object Type = value defined in ISO/IEC 14496-3 [5]. This parameter specifies the tool = to be used by the coder. It CAN be used to limit the capability within the specified "profile-level-id". bitrate: the data rate for the audio bit stream. cpresent: this parameter indicates whether audio payload = configuration data has been multiplexed into an RTP payload (See section 4.1 in = this document). config: a hexadecimal representation of an octet string that = expresses the audio payload configuration data "StreamMuxConfig", as defined = in ISO/IEC 14496-3 [5]. Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration = data SHALL be located at the MSB of the first octet. In the last octet, zero-padding bits, if necessary, shall follow the configuration = data. ptime: RECOMMENDED duration of each packet in milliseconds. Published specification: Payload format specifications are described in this document. = Encoding specifications are provided in ISO/IEC 14496-3 [3][5]. Encoding considerations: This type is only defined for transfer via RTP. Security considerations: See Section 9 of RFCXXXX. Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding = of visual objects. For effective implementation of the standard, = subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 = Visual have been provided (see section 6.1). The audio stream SHALL be compliant with the MPEG-4 Audio Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this = parameter mutually to the same value. Furthermore, the "object" parameter can = be used to limit the capability within the specified Profile@Level in capability exchange. Applications which use this media type: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 18] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Audio and video streaming and conferencing tools. Additional information: none Personal & email address to contact for further information: See Section 9 of RFCXXXX. Intended usage: COMMON Author/Change controller: See Section 9 of RFCXXXX. 6.4 SDP usage of MPEG-4 Audio The MIME media type audio/MP4A string is mapped to fields in the = Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (audio) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4A) goes in SDP "a=3Drtpmap" as the encoding = name. o The required parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "ptime" goes in SDP "a=3Dptime" attribute. o The optional parameter "profile-level-id" goes in the "a=3Dfmtp" = line to indicate the coder capability. The "object" parameter goes in the "a=3Dfmtp" attribute. The payload-format-specific parameters = "bitrate", "cpresent" and "config" go in the "a=3Dfmtp" line. These parameters = are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=3Dvalue pairs. The following are some examples of the media representation in SDP: For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz), m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/8000 a=3Dfmtp:96 = profile-level-id=3D9;object=3D8;cpresent=3D0;config=3D9128B1071070 a=3Dptime:20 For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of = 24 kHz), m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/24000 a=3Dfmtp:96 profile-level-id=3D1; bitrate=3D64000; cpresent=3D0; config=3D9122620000 In the above two examples, audio configuration data is not = multiplexed into the RTP payload and is described only in SDP. Furthermore, the "clock rate" is set to the audio sampling rate. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 19] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D If the clock rate has been set to its default value and it is = necessary to obtain the audio sampling rate, this can be done by parsing the "config" parameter. The following example shows that the audio configuration data appears in the RTP payload. The value specified by = the "config" parameter is used as an initial value to setup coding parameters. m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/90000 a=3Dfmtp:96 cpresent=3D1; config=3D9128B1071070 7. Security Considerations RTP packets using the payload format defined in this specification = are subject to the security considerations discussed in the RTP = specification [8]. This implies that confidentiality of the media streams is = achieved by encryption. Because the data compression used with this payload = format is applied end-to-end, encryption may be performed on the compressed = data so there is no conflict between the two operations. This payload type does not exhibit any significant non-uniformity in = the receiver side computational complexity for packet processing to = cause a potential denial-of-service threat. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP = 9, RFC 2026, October 1996. 2 ISO/IEC 14496-2:1999, "Information technology - Coding of = audio-visual objects - Part2: Visual", December 1999. 3 ISO/IEC 14496-3:1999, "Information technology - Coding of = audio-visual objects - Part3: Audio", December 1999. 4 ISO/IEC 14496-2:1999/FDAM1:2000, December 1999. 5 ISO/IEC 14496-3:1999/FDAM1:2000, December 1999. 6 ISO/IEC 14496-1:1999, "Information technology - Coding of = audio-visual objects - Part1: Systems", December 1999. 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 20] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A = Transport Protocol for Real Time Applications", RFC 1889, Internet = Engineering Task Force, January 1996. 9 ISO/IEC 14496-2/COR1, "Information technology - Coding of = audio-visual objects - Part2: Visual, Technical corrigendum 1", March 2000. 9. Author's Addresses Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan Email: yoshihiro.kikuchi@toshiba.co.jp Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan Email: matsui@drl.mei.co.jp Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN Email: t-nomura@ccm.cl.nec.co.jp Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan. Email: fukunaga444@oki.co.jp Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan Email: kimata@nttvdt.hil.ntt.co.jp Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 21] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. =0C ------=_NextPart_000_0094_01BFDAA2.F7A4E800-- From rem-conf Tue Jun 20 01:20:35 2000 From rem-conf-request@es.net Tue Jun 20 01:20:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134JCS-0006zP-00; Tue, 20 Jun 2000 01:16:00 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 134JCQ-0006zF-00; Tue, 20 Jun 2000 01:15:58 -0700 Received: from kangaroo (dh304.kansai.oki.co.jp [10.173.3.204]) by titanic.kansai.oki.co.jp (8.9.3/8.9.3) with SMTP id RAA20532; Tue, 20 Jun 2000 17:15:16 +0900 (JST) (envelope-from fukunaga444@oki.co.jp) Message-ID: <018401bfda90$097b8920$cc03ad0a@kansai.oki.co.jp> From: "Shigeru Fukunaga" To: "Dr. Injong Rhee" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Stephan Wenger" Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Tue, 20 Jun 2000 17:17:51 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Stephan, Dr. Rhee, and all, I revised the RTCP text again from the latest version which I sent yesterday. At section 5.4, I revised text back to the original expression. Would you please check the RTCP part of our ID? As Kikuchi-san reported this morning, we decided the deadline at the middle of this week. If there is any problem in the RTCP part, would you please indicate it as soon as possible? Best Regards, Shigeru ---- 5. RTCP Packetization of MPEG-4 upstream messages This section specifies the usage of particular RTCP packets to carry the upstream messages generated by MPEG-4 decoders to advise corresponding MPEG-4 encoder, using the MPEG-4 Audio/Visual upstream messaging functionalities. This particular RTCP is called "RTCP-MP4U" in the following. In the current specification, NEWPRED in the MPEG-4 Visual Advance Real Time Simple (ARTS) Profile[4] is the only tool which uses this RTCP-MP4U payload specification. The RTCP-MP4U packet SHALL ONLY be used when it is indicated by some out of band means that the corresponding MPEG-4 Visual codec is compliant with the ARTS profile and it is indicated in the configuration information of the MPEG-4 visual bitstream that the NEWPRED tool is enabled (newpred_enable is set to 1). 5.1. Abstract of NEWPRED in the ARTS profile The NEWPRED tool in the MPEG-4 Visual ARTS profile is an error resilience oriented tool using the upstream messages from the decoder to the encoder. As the inter-frame coding is used in the MPEG-4 Visual, the image degradation resulting from a packet loss will be propagated toall predicted frames following the damaged frame. In order to prevent this type of temporal error propagation, a complying encoder may switch reference frames of the inter-frame coding, according to the information available in the received NEWPRED RTCP-MP4U. As the correctly decoded frame is used as the reference frame, the error propagation is refreshed. As the intra refresh is not used, the coding efficiency can be kept comparatively high, although using older reference frames then the most recent one does add bits due to less efficient prediction (e.g. through longer motion vectors due to a longer time interval for prediction). And the NEWPRED can achieve the faster error recovery than the intra refresh as well. There are two types of upstream messages; acknowledged message (NP_ACK) and non-acknowledged message (NP_NACK). The syntax and semantics of both type of upstream messages are defined in MPEG-4[4]. NP_ACK and/or NP_NACK messages are transmitted on the RTCP-MP4U packets in the NEWPRED. The selecting methods of reference frames depend on the kind of used messages. 5.2. RTCP-MP4U packets for low delay The RTCP-MP4U SHALL be treated as a completely different kind of RTCP traffic, not following timing rules associated with normal RTCP information. The performance of MPEG-4 tools using upstream messages (such as NEWPRED) is sensitive to the delay of the upstream message and does not require the full reliability of the upstream message. Therefore, it is more effective to send the MPEG-4 upstream message packets as soon as possible, i.e. as soon as a packet loss is detected, without adding any random delays. 5.3. Congestion control In the cases of the demand type of intra refresh, the number of bits during congestion is greater than that in the error free condition. This may cause more congestion. While in the NEWPRED, as the intra-frame coding is not used, the bit increase is much lower than that of the intra refresh even in the case of packet loss. NEWPRED is less of a burden for the congestion. The amount of traffic necessary to convey NEWPRED RTCP-MP4U depends on the strategy of the reference frame selection by the encoder, the type of upstream messages sent by the decoder, frame rate, and network conditions. In order to avoid the congestion, the amount of upstream message packets should be small. In the NEWPRED, the decoder can control the amount of the upstream message packets by not sending some upstream messages; For example, in the case that the NP_NACK messages are mainly used to select the reference frames in the encoder, the decoder may not send the NP_ACK messages even if it receives downstream data. On the other hand, in the case that the NP_ACK messages are mainly used in the encoder, the decoder may not send the NP_NACK messages. The amount of the upstream messages is at most 5% (normally about 1%) of the visual downstream data. Especially the amount of NP_ACK messages is decreased in the case of packet loss. Therefore the NP_ACK message has no additional burden on the congestion. On the other hand, NP_NACK messages corresponding to the lost packets are usually sent after the congestion, because the decoder detects the packet loss after it receives the next downstream packet. Again the NP_NACK message has little additional burden on the congestion. To reduce the number of RTCP-MP4U packets, multiple upstream messages can be concatenated in the payload of one RTCP-MP4U packet. In this case, it is desirable to send these concatenated messages as soon as possible. The RTCP-MP4U transmission interval depends on the interval of decoding the visual downstream data. Both the receiving interval of the visual RTP packet and the decoding time for each packet data have some jitter associated with them. Therefore the RTCP-MP4U transmission interval has some jitter by itself. It is effective for the congestion control, and there is no need to add any random delays. This means that the amount of jitter is enough to avoid another congestion in the case of unicast. 5.4. Limited to Unicast Although NEWPRED can work in multicast when the number of decoders is small, in order to avoid additional congestion, the NEWPRED over RTP/RTCP SHALL NOT be used in multicast. 5.5. Relations with SR and RR The RTCP-MP4U packets SHALL be treated as a completely different kind of packets from the normal RTCP packets such as SR, RR and so on. For example, if the RTCP-MP4U packets is included in the calculation of RTCP sending interval, the RR packets should be generated in the timing of the RTCP-MP4U packets. In this case, the interval of the RR packets would be smaller than 5 seconds, and the number of the normal RTCP packets is much increased. This is bad from the view point of the congestion. Therefore all RTCP-MP4U packets SHALL be ignored when analyzing the information in the sender and receiver reports (SR and RR), and only normal RTCP packets SHALL be used. Multiple RTCP-MP4U packets can be concatenated without any intervening separators to form a compound RTCP packet. The normal compound RTCP packet SHOULD start with SR or RR packets. However in the case of compound RTCP-MP4U packet, other normal RTCP packets SHALL NOT be included, and only RTCP-MP4U packets SHALL be included in one compound RTCP-MP4U packet. 5.6. MPEG-4 Visual upstream message packets definition 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| UMT | PT=RTCP_MP4U | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | MPEG-4 Upstream Messages Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. padding (P): 1 bit If the padding bit is set, this RTCP-MP4U packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of how many padding octets should be ignored. In the case several upstream messages are mapped onto one RTCP-MP4U packet, padding should only be required on the last individual message. upstream message type (UMT): 5 bits Identifies the type of the MPEG-4 upstream messages. 0: forbidden 1: MPEG-4 Visual NEWPRED in the ARTS Profile 2-63: reserved In this internet-draft, only the NEWPRED in the ARTS profile is assigned as the candidate of the UMT for the moment. Some other MPEG-4 Audio/Visual applications using the upstream messages may be assigned in the future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant RTCP_MP4U (TBD). SSRC: 32 bits SSRC is the synchronization source identifier for the sender of this packet. MPEG-4 Upstream Message Payload: variable The syntax and semantics of the MPEG-4 upstream messages are defined in the ISO/IEC 14496-2/3[4][5]. All messages are byte aligned. Normally one message is mapped onto one RTCP packet, and several messages with same UMT could be continuously mapped onto one RTCP packet. One message SHALL NOT be fragmented into different RTCP packets. 6. MIME type registration for MPEG-4 Audio/Visual streams ... 6.1 MIME type registration for MPEG-4 Visual ... mpeg4-newpred-upstream-message: A boolean number to indicate the receiver capability of sending the upstream message of NEWPRED in MPEG-4 video. The upstream messages are delivered on the particular RTCP packets which are described in Section 5. This capability exist when and only when the "profile-level-id" is 145, 146, 147 or 148 (Advance Real Time Simple Profile/Level 1, 2, 3 or 4). And this parameter is set to '1' only for the real-time communication with the real-time encoder. Therefore this parameter is usually set to '0' for the e-mail applications or streaming applications without real-time encoder. Example usages for these parameters are: - MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v; profile-level-id=34 - MPEG-4 Visual Advanced Real Time Simple Profile/Level 1, upstream message is not used: Content-type: video/mp4v; profile-level-id=145; mpeg4-newpred-upstream-message=0 ... -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 From rem-conf Tue Jun 20 01:45:05 2000 From rem-conf-request@es.net Tue Jun 20 01:45:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134Jcr-0000Fd-00; Tue, 20 Jun 2000 01:43:17 -0700 Received: from research.gate.nec.co.jp [202.247.6.217] by mail1.es.net with esmtp (Exim 1.81 #2) id 134Jcn-0000FP-00; Tue, 20 Jun 2000 01:43:13 -0700 Received: from luke.dsp.cl.nec.co.jp (root@luke.dsp.cl.nec.co.jp [10.56.47.3]) by research.gate.nec.co.jp (8.9.3+3.2W/000323) with ESMTP id RAA07196; Tue, 20 Jun 2000 17:43:10 +0900 (JST) Received: from kero (dhcp021.dsp.cl.nec.co.jp [10.56.44.21]) by luke.dsp.cl.nec.co.jp (8.9.1b+Sun/CL-000424) with SMTP id RAA17769; Tue, 20 Jun 2000 17:43:09 +0900 (JST) Message-ID: <01c901bfda93$8606bf20$152c380a@dsp.cl.nec.co.jp> From: "Toshiyuki Nomura" To: "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" References: <009901bfda57$8821f540$4f51c485@eel.rdc.toshiba.co.jp> Subject: Re: Draft revised I/D of MPEG-4 A/V RTP Date: Tue, 20 Jun 2000 17:42:52 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01C6_01BFDADE.F5AB43A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01C6_01BFDADE.F5AB43A0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear Kikuchi-san and all, I have revised the I/D as follows and attached it with this mail. > Regarding (2), I saw a message from John for the agreement on the revision > proposed by Nomura-san. A text for the revision will be sent soon to the > reflector by Nomura-san for the final approval. Best Regards, Toshiyuki Nomura, NEC ----- Original Message ----- From: Yoshihiro Kikuchi To: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT Cc: Yoshihiro Kikuchi Sent: Tuesday, June 20, 2000 10:33 AM Subject: Draft revised I/D of MPEG-4 A/V RTP > Dear Stephan, Injong, John, and all MPEG-4 on RTP experts, > > Please find attached a revised text of the MPEG-4 Audio/Visual RTP > Internet-Draft. Change from the previous version is the upgrade of the > English quality. I hope that the English quality is now an acceptable level. > There is no technical change from the previous version. > > Please note that this is NOT a final version. I recognize that we need a > conclusion on the following matters to finalize the I/D: > > (1) How to proceed NEWPRED RTCP. > (2) Minor revision on the Audio RTP and its MIME type. > > Regarding (2), I saw a message from John for the agreement on the revision > proposed by Nomura-san. A text for the revision will be sent soon to the > reflector by Nomura-san for the final approval. > > Regarding (1)... It was proposed by Fukunaga-san to keep and revise the > NEWPRED RTCP description. I must admit that I hesitated to reflect the > proposed text to the I/D. I'm not sure whether we have get an agreement to > go such way, or some another. I will reflect the proposed change if we get > an agreement. > > Again, > > The final I/D will contain ONLY items that can reach to a consensus among > the whole group. In other words, a part of the I/D which cannot reach to a > consensus may be removed. The decision will be made depend on the comments > through the reflector, but not only the opinion of the proponent. > > We are keen to have discussions to get a consensus. However, we do not want > have round discussions again and again. It will defer the process of the > agreement of the whole document, including RTP part, that we must avoid. We > would like to define a deadline at middle of this week.(except for editorial > changes and very minor revisions) An item that cannot get agreement by then > may be removed. > > Best regards, > Yoshihiro > > ---- > Yoshihiro Kikuchi > > E-mail: kiku@eel.rdc.toshiba.co.jp > Corporate Research and Development Center > TOSHIBA Corporation > TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 > > ------=_NextPart_000_01C6_01BFDADE.F5AB43A0 Content-Type: text/plain; name="draft-ietf-avt-rtp-mpeg4-es-02-draft6.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mpeg4-es-02-draft6.txt" Internet Engineering Task Force Yoshihiro Kikuchi - = Toshiba Internet Draft Toshiyuki Nomura - = NEC Document: draft-ietf-avt-rtp-mpeg4-es-02.txt Shigeru Fukunaga - = Oki Yoshinori Matsui - = Matsushita Hideaki Kimata - = NTT June 20, = 2000 RTP payload format for MPEG-4 Audio/Visual streams Status of this Memo This document is an Internet-Draft and is in full conformance with = all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering = Task Force (IETF), its areas, and its working groups. Note that other = groups may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months and may be = updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to = cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes RTP payload formats for carrying of MPEG-4 = Audio and Visual bitstreams[2][3], and an RTCP format for MPEG-4 upstream messages functionalities[4]. For the purpose of directly mapping = MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications = for the use of RTP header fields and also specifies fragmentation rules. = It also specifies an RTCP packet usage to carry MPEG-4 upstream = messages. Finally, it provides specifications for MIME type registrations and = the use of SDP. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 1] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 1. Introduction 1.1 Why MPEG-4 Audio/Visual RTP format needed? The RTP payload formats described in this Internet-Draft specify a = way of how MPEG-4 Audio and Visual streams are to be fragmented and mapped directly onto RTP packets. H.323 terminals are an example where such RTP payload formats may be used. MPEG-4 Audio/Visual streams are not managed by MPEG-4 Systems Object Descriptors [6] but by H.245. The streams are directly mapped = onto RTP packets without using the synchronization functionality of MPEG-4 Systems [6]. The semantics of RTP headers in such cases need to be clearly = defined, including the association with MPEG-4 Audio/Visual data elements. In addition, it would be beneficial to define the fragmentation rules of = RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resilience tools provided inside the MPEG-4 Video stream. These issues, however, have yet to be addressed by other RTP payload format specifications. 1.2 MPEG-4 Visual RTP payload format MPEG-4 Visual is a visual coding standard with many new features: = high coding efficiency; high error resiliency; multiple, arbitrary shape object-based coding; etc. [2]. It covers a wide range of bitrate from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to = mobile networks with high error rates. With respect to the fragmentation rules for an MPEG-4 visual = bitstream defined in this document, since MPEG-4 Visual is used for a wide = variety of networks, it is desirable not to apply too much restriction on fragmentation, and a fragmentation rule such as "a single video = packet shall always be mapped on a single RTP packet" may be inappropriate. = On the other hand, careless, media unaware fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are flexible but = manage to define the minimum rules for preventing meaningless fragmentation and = for utilizing the error resilience of MPEG-4 visual. While the additional media specific RTP header defined for such video coding tools as H.261 or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, in MPEG-4 Visual there = are already error resilience functionalities for recovering corrupt = headers, and these can be used on RTP/IP networks, as well as on other = networks. (H.223/mobile, MPEG-2/TS, etc.) That is why no extra RTP header = fields are defined in the MPEG-4 Visual RTP payload format proposed here. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 2] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 1.3 MPEG-4 Audio RTP payload format MPEG-4 Audio is a new kind of audio standard that integrates many different types of audio coding tools. It also supports a mechanism = for representing synthesized sounds. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequences of audio data with relatively small overhead. In audio-only applications, then, it is desirable for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto the RTP packets without using MPEG-4 Systems. For MPEG-4 Audio coding tools except synthesis tools, as is true for other audio coders, if the payload of a packet is a single audio = frame, packet loss will not impair the decodability of adjacent packets. On = the other hands, MPEG-4 Audio synthesis tools may be sensitive to error. = For example, an SA_access_unit in the payload may set a global value to a = new value, which is then references throughout the audio content to make = a=20 macro change in the performance. In this case, an error in the = payload influences all audio data produced after the error. In order to = enhance=20 error resiliency, the element of SA_access_unit that makes the above=20 macro change should be transmitted across several SA_access_unit repeatedly. The number of repetition will be dependent on the network condition. Therefore, the additional media specific header for = recovering errors will not be required for MPEG-4 Audio. 1.4 MPEG-4 Audio/Visual upstream messaging on RTCP packets MPEG-4 Audio/Visual upstream messages are extremely Audio/Visual specific, since coders directly use them for controlling coding parameters, for which purpose, these messages need to be transmitted without delay. For this reason, here, these messages are directly = mapped onto low delay RTCP packets. Such RTCP packets are limited, however, = to use with certain particular profiles (e.g. MPEG-4 Visual Advanced = Real Time Simple Profile, NEWPRED tool). 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [7]. 3. RTP Packetization of MPEG-4 Visual bitstream This section specifies RTP packetization rules for MPEG-4 Visual = content. An MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode is used so that configuration information will be carried to the same = RTP port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC = 14496- 2 [2][9][4]) When the short video header mode is used, the RTP payload format used = MAY be that specified for H.263 in the relevant RFCs or in other relevant standards. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 3] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 4] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | = RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | = Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | | RTP | MPEG-4 Visual stream (byte aligned) | = Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - An RTP packet for MPEG-4 Visual stream 3.1 Use of RTP header fields for MPEG-4 Visual Payload Type (PT): Payload type is to be specifically assigned as the MPEG-4 Visual RTP payload format. If this assignment is to be carried = out dynamically, it can be performed by such out-of-band means as H.245, = SDP, etc. Extension (X) bit: Defined by the RTP profile used. Sequence Number: Incremented by one for each RTP data packet sent, starting, for security reasons, with a random initial value. Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. A constant offset, = which is random, is added for security reasons. For a video object plane, it = is defined as vop_time_increment (in units of 1/vop_time_increment_resolution seconds) plus the cumulative number = of whole seconds specified by module_time_base and, if present, = time_code of Group_of_VideoObjectPlane() fields. In the case of interlaced video, = a VOP will consist of lines from two fields, and the timestamp will indicate the composition time of the first field. If the RTP packet Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 5] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 contains only configuration information and/or Group_of_VideoObjectPlane() fields, the composition time of the next = VOP in the coding order is used. If the RTP packet contains only visual_object_sequence_end_code information, the composition time of = the immediately preceding VOP in the coding order is used. The resolution of the timestamp is set to its default value of 90KHz, unless specified by an out-of-band means (e.g. SDP parameter or MIME parameter as defined in section 6). SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 3.2 Fragmentation of MPEG-4 Visual bitstream A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation. (1) Configuration information and Group_of_VideoObjectPlane() fields SHALL be placed at the beginning of the RTP payload (just after the = RTP header) or just after the header of the syntactically upper layer function. (2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function. Note: The visual_object_sequence_end_code is regarded as the lowest function. (3) A header SHALL NOT be split into a plurality of RTP packets. (4) Two or more VOPs SHALL be fragmented into different RTP packets = so that one RTP packet consists of the data bytes associated with a = unique presentation time (that is indicated in the timestamp field in the = RTP packet header). (5) A single video packet SHOULD NOT be split into a plurality of RTP packets. The size of a video packet SHOULD be adjusted in such a way = that the resulting RTP packet is not larger than the path-MTU. A video = packet MAY be split into a plurality of RTP packets when the size of the = video packet is large. Here, header means: - Configuration information (Visual Object Sequence Header, Visual = Object Header and Video Object Layer Header) - visual_object_sequence_end_code - The header of the entry point function for an elementary stream (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject()) Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 6] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 - The video packet header (video_packet_header() excluding next_resync_marker()) - The header of gob_layer() See 6.2.1 "Start codes" of ISO/IEC 14496-2[2][9][4] for the = definition of the configuration information and the entry point functions. The video packet starts with the VOP header or the video packet = header, followed by motion_shape_texture(), and ends with = next_resync_marker() or next_start_code(). 3.3 Examples of packetized MPEG-4 Visual bitstream Considering the fact that MPEG-4 Visual covers a wide variety of = networks ranging from scores of Kbps to several Mbps, and from those = guaranteed to be almost error-free to mobile networks with high error rates, it is desirable not to apply too much restriction on fragmentation. On the other hand, careless, media unaware fragmentation will cause = degradation in error resiliency and bandwidth efficiency. The fragmentation = criteria described in 3.2 are flexible but to define the minimum rules to = prevent meaningless fragmentation. Figure 2 shows examples of RTP packets generated based on the = criteria described in 3.2 (a) is an example of the first RTP packet or the random access point = of an MPEG-4 visual bitstream containing the configuration information. According to criterion (1), the Visual Object Sequence Header(VS = header) is placed at the beginning of the RTP payload, preceding the Visual Object Header and the Video Object Layer Header(VO header, VOL = header). Since the fragmentation rule defined in 3.2 guarantees that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning = of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code. (b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a video packet in the VOP following the configuration information. Since the length of the configuration information is relatively short (typically scores of bytes) and an RTP packet = containing only the configuration information may thus increase the overhead, = the configuration information and the immediately following GOV and/or (a part of) VOP can be effectively packetized into a single RTP packet = as in this example. (c) is an example of the RTP packet that contains Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is placed at the beginning of the RTP payload. It would be a waste of = RTP/IP Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 7] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 header overhead to generate an RTP packet containing only a GOV whose length is 7 bytes. Therefore, (a part of) the following VOP can be = placed in the same RTP packet as shown in (c). (d) is an example of the case where one video packet is packetized = into one RTP packet. When the packet-loss rate of the underlying network = is high, this kind of packetization is recommended. It is recommended to = set resync_marker_disable to 0 in the VOL header to enable the adjustment = of the video packet size. Even when the RTP packet containing the VOP = header is discarded by a packet loss, the other RTP packets can be decoded = by using the HEC(Header Extension Code) information in the video packet header. No extra RTP header field is necessary. (e) is an example of the case where more than one video packets are packetized into one RTP packet. This kind of packetization is = effective to save the overhead of RTP/IP headers when the bit-rate of the underlying network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single = RTP packet loss. The optimal number of video packets in an RTP packet and = the length of the RTP packet can be determined considering the = packet-loss rate and the bit-rate of the underlying network. Figure 3 shows examples of RTP packets prohibited by the criteria of = 3.2. Fragmentation of a header into multiple RTP packets, as in (a), will = not only increase the overhead of RTP/IP headers but also decrease the = error resiliency. Therefore, it is prohibited by the criterion (3). When concatenating more than one video packets into an RTP packet, = VOP header or video_packet_header() shall not be placed in the middle of = the RTP payload. The packetization as in (b) is not allowed by criterion = (2) due to the aspect of the error resiliency. Comparing this example = with Figure 2(d), although two video packets are mapped onto two RTP = packets in both cases, the packet-loss resiliency is not identical. Namely, = if the second RTP packet is lost, both video packets 1 and 2 are lost in = the case of Figure 3(b) whereas only video packet 2 is lost in the case = of Figure 2(d). An RTP packet containing more than one VOPs, as in (c), is not = allowed. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 8] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+------+------+------+------------+ (b) | RTP | VS | VO | VOL |Video Packet| |header|header|header|header| | +------+------+------+------+------------+ +------+-----+------------------+ (c) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+------+------------+ +------+------+------------+ (d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ = +------+------+------------+------+------------+------+------------+ (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video = Packet| |header|header| (1) |header| (2) |header| (3) = | = +------+------+------------+------+------------+------+------------+ Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream +------+-------------+ +------+------------+------------+ (a) | RTP |First half of| | RTP |Last half of|Video Packet| |header| VP header | |header| VP header | | +------+-------------+ +------+------------+------------+ +------+------+----------+ = +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video = Packet| |header|header| of VP(1) | |header| of VP(1)|header| (2) = | +------+------+----------+ = +------+---------+------+------------+ +------+------+------------------+------+------------------+ (c) | RTP | VOP |Video Object Plane| VOP |Video Object Plane| |header|header| (1) |header| (2) | +------+------+------------------+------+------------------+ Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 9] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 4. RTP Packetization of MPEG-4 Audio bitstream This section specifies RTP packetization rules for MPEG-4 Audio bitstreams. MPEG-4 Audio streams are formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex) tool[5], and the LATM-based streams = are then mapped onto RTP packets as described the three sections below. 4.1 RTP Packet Format LATM-based streams consist of a sequence of audioMuxElements that = include one or more audio frames. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 4). The first byte of = each audioMuxElement SHALL be located at the first payload location in an = RTP packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number = |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp = |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | |RTP : audioMuxElement (byte aligned) = :Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - An RTP packet for MPEG-4 Audio In order to decode the audioMuxElement, the following = muxConfigPresent information is required to be indicated by an out-of-band means. muxConfigPresent: If this value is set to 1, the audioMuxElement = SHALL include an indication bit "useSameStreamMux" and MAY include the configuration information for audio compression "StreamMuxConfig". = The useSameStreamMux bit indicates whether the StreamMuxConfig element in = the previous frame is applied in the current frame. 4.2 Use of RTP Header Fields for MPEG-4 Audio Payload Type (PT): Payload type is to be specifically assigned as the MPEG-4 Audio RTP payload format. If this assignment is to be carried = out dynamically, it can be performed by such out-of-band means as H.245, = SDP, etc. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 10] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 Marker (M) bit: The marker bit indicates audioMuxElement boundaries. = It is set to one to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement. Timestamp: The timestamp indicates composition time, or presentation = time in a no-compositor decoder. Timestamps are recommended to start at a random value for security reasons. Unless specified by an out-of-band means, the resolution of the = timestamp is set to its default value of 90 kHz. Sequence Number: Incremented by one for each RTP packet sent, = starting, for security reasons, with a random value. SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 4.3 Fragmentation of MPEG-4 Audio bitstream It is desirable to put one audioMuxElement in each RTP packet. If the size of an audioMuxElement can be kept small enough that the size of = the RTP packet containing it does not exceed the size of the path-MTU, = this will be no problem. If it cannot, the audioMuxElement MAY be = fragmented and spread across multiple packets, following the rules below: (1) "payloadMux", which consists of payload elements, MAY be = fragmented across several RTP packets, so that each of those RTP packets will contain one or more payload elements. Individual payload elements themselves SHOULD NOT be fragmented. (2) If the audioMuxElement includes StreamMuxConfig, StreamMuxConfig SHALL be included in the RTP packet that contains the first payload element. 5. RTCP Packetization of MPEG-4 upstream messages This section specifies the usage of particular RTCP packets to carry = the upstream messages generated by MPEG-4 decoders to advise = corresponding MPEG-4 encoder, using the MPEG-4 Audio/Visual upstream messaging functionalities. This particular RTCP is called _RTCP-MP4U_ in the following. In the current specification, NEWPRED in the MPEG-4 Visual Advance Real Time Simple (ARTS) Profile[4] is the only tool which = uses this RTCP-MP4U payload specification. The RTCP-MP4U packet SHALL ONLY = be used when it is indicated by some out of band means that the corresponding MPEG-4 Visual codec is compliant with the ARTS profile = and it is indicated in the configuration information of the MPEG-4 visual bitstream that the NEWPRED tool is enabled (newpred_enable is set to = 1). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 11] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 5.1. Abstract of NEWPRED in the ARTS profile The NEWPRED tool in the MPEG-4 Visual ARTS profile is an error = resilience oriented tool using the upstream messages from the decoder to the encoder. As the inter-frame coding is used in the MPEG-4 Visual, the image degradation resulting from a packet loss will be propagated = toall predicted frames following the damaged frame. In order to prevent = this type of temporal error propagation, a complying encoder may switch reference frames of the inter-frame coding, according to the = information available in the received NEWPRED RTCP-MP4U. As the correctly = decoded frame is used as the reference frame, the error propagation is = refreshed. As neither the re-transmission nor the intra refresh are used, the = coding efficiency can be kept comparatively high, although using older = reference frames then the most recent one does add bits due to less efficient prediction (e.g. through longer motion vectors due to a longer time interval for prediction). And the NEWPRED can achieve the faster = error recovery than the intra refresh as well. There are two types of upstream messages; acknowledged message = (NP_ACK) and non-acknowledged message (NP_NACK). NP_ACK and/or NP_NACK = messages are transmitted on the RTCP-MP4U packets in the NEWPRED. The = selecting methods of reference frames depend on the kind of used messages. 5.2. RTCP-MP4U packets for low delay The RTCP-MP4U SHALL be treated as a completely different kind of RTCP traffic, not following timing rules associated with normal RTCP information. The performance of MPEG-4 tools using upstream messages (such as NEWPRED) is sensitive to the delay of the upstream message = and does not require the full reliability of the upstream message. = Therefore, it is more effective to send the MPEG-4 upstream message packets as = soon as possible, i.e. as soon as a packet loss is detected, without = adding any random delays. 5.3. Congestion control In the cases of the demand type of intra refresh or the = re-transmission, the number of bits during congestion is greater than that in the = error free condition. This may cause more congestion. While in the = NEWPRED, as the intra-frame coding is not used, the bit increase is much lower = than that of the intra refresh or the re-transmission even in the case of packet loss. NEWPRED is less of a burden for the congestion. The amount of traffic necessary to convey NEWPRED RTCP-MP4U depends = on the strategy of the reference frame selection by the encoder, the = type of upstream messages sent by the decoder, frame rate, and network conditions. In order to avoid the congestion, the amount of upstream message packets should be small. In the NEWPRED, the decoder can = control the amount of the upstream message packets by not sending some = upstream messages; For example, in the case that the NP_NACK messages are = mainly used to select the reference frames in the encoder, the decoder may = not Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 12] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 send the NP_ACK messages even if it receives downstream data. On the other hand, in the case that the NP_ACK messages are mainly used in = the encoder, the decoder may not send the NP_NACK messages. The amount of = the upstream messages is at most 5% (normally about 1%) of the visual downstream data. Especially the amount of NP_ACK messages is decreased in the case of packet loss. Therefore the NP_ACK message has no additional burden = on the congestion. On the other hand, NP_NACK messages corresponding to = the lost packets are usually sent after the congestion, because the = decoder detects the packet loss after it receives the next downstream packet. Again the NP_NACK message has little additional burden on the = congestion. To reduce the number of RTCP-MP4U packets, multiple upstream messages = can be concatenated in the payload of one RTCP-MP4U packet. In this = case, it is desirable to send these concatenated messages as soon as possible. The RTCP-MP4U transmission interval depends on the interval of = decoding the visual downstream data. Both the receiving interval of the = visual RTP packet and the decoding time for each packet data have some = jitter associated with them. Therefore the RTCP-MP4U transmission interval = has some jitter by itself. It is effective for the congestion control, = and there is no need to add any random delays. This means that the = amount of jitter is enough to avoid another congestion in the case of unicast. 5.4. Limited to Unicast Although NEWPRED can work in multicast when the number of decoders is small, in order to avoid additional congestion, the NEWPRED over = RTP/RTCP SHALL NOT be used in multicast. 5.5. Relations with SR and RR The RTCP-MP4U packets SHALL be treated as a completely different kind = of packets from the normal RTCP packets such as SR, RR and so on. For example, if the RTCP-MP4U packets is included in the calculation = of RTCP sending interval, the RR packets should be generated in the = timing of the RTCP-MP4U packets. In this case, the interval of the RR = packets would be smaller than 5 seconds, and the number of the normal RTCP packets is much increased. This is bad from the view point of the congestion. Therefore all RTCP-MP4U packets SHALL be ignored when analyzing the information in the sender and receiver reports (SR and RR), and only normal RTCP packets SHALL be used. Multiple RTCP-MP4U packets can be concatenated without any = intervening separators to form a compound RTCP packet. The normal compound RTCP packet SHOULD start with SR or RR packets. However in the case of compound RTCP-MP4U packet, other normal RTCP packets SHALL NOT be included, and only RTCP-MP4U packets SHALL be included in one = compound RTCP-MP4U packet. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 13] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 5.6. MPEG-4 Visual upstream message packets definition 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P| UMT | PT=3DRTCP_MP4U | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | MPEG-4 Upstream Messages Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets = as in RTP data packets. padding (P): 1 bit If the padding bit is set, this RTCP-MP4U packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of = how many padding octets should be ignored. In the case several = upstream messages are mapped onto one RTCP-MP4U packet, padding should = only be required on the last individual message. upstream message type (UMT): 5 bits Identifies the type of the MPEG-4 upstream messages. 0: forbidden 1: MPEG-4 Visual NEWPRED in the ARTS Profile 2-63: reserved In this internet-draft, only the NEWPRED in the ARTS profile is assigned as the candidate of the UMT for the moment. Some other MPEG-4 Audio/Visual applications using the upstream messages may = be assigned in the future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant RTCP_MP4U (TBD). SSRC: 32 bits SSRC is the synchronization source identifier for the sender of = this packet. MPEG-4 Upstream Message Payload: variable The syntax and semantics of the MPEG-4 upstream messages are = defined in the ISO/IEC 14496-2/3[4][5]. All messages are byte aligned. Normally one message is mapped onto one RTCP packet, and several messages with same UMT could be continuously mapped onto one = RTCP packet. One message SHALL NOT be fragmented into different RTCP packets. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 14] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 6. MIME type registration for MPEG-4 Audio/Visual streams The following sections describe the MIME type registrations for = MPEG-4 Audio/Visual streams. MIME type registration and SDP usage for the = MPEG-4 Visual stream are described in Sections 6.1 and 6.2, respectively, = while MIME type registration and SDP usage for MPEG-4 Audio stream are described in Sections 6.3 and 6.4, respectively. (In the following sections, the RFC number "XXXX" represents the RFC number, which should be assigned for this Internet Draft.) 6.1 MIME type registration for MPEG-4 Visual MIME media type name: video MIME subtype name: MP4V Required parameters: none Optional parameters: rate: This parameter is used only for RTP transport. It indicates = the resolution of the timestamp field in the RTP header. If this = parameter is not specified, its default value of 90000 (90KHz) is used. profile-level-id: A decimal representation of MPEG-4 Visual Profile Level indication value (profile_and_level_indication) defined in = Table G-1 of ISO/IEC 14496-2 [2][4]. mpeg4-newpred-upstream-message: A boolean number to indicate the receiver capability of sending the upstream message of NEWPRED in MPEG-4 video. The upstream messages are delivered on the particular RTCP packets which are described in Section 5. This capability = exist when and only when the "profile-level-id" is 145, 146, 147 or 148 (Advance Real Time Simple Profile/Level 1, 2, 3 or 4). Example usages for these parameters are: - MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v; profile-level-id=3D34 - MPEG-4 Visual Advanced Real Time Simple Profile/Level 1: Content-type: video/mp4v; profile-level-id=3D145; = mpeg4-newpred- upstream-message=3D1 Published specification: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 15] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 The specifications for MPEG-4 Visual streams are presented in = ISO/IEC 14469-2[2][4][9]. The RTP payload format is described in RFCXXXX. Encoding considerations: This type is defined for transfer via RTP. The RTP packets must be packetized according to the MPEG-4 Visual RTP payload format = defined in RFCXXXX. Video bitstreams must be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). A video bitstream is = binary data and must be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer via RTP. The RTP packets must be packetized according to = the MPEG-4 Visual RTP payload format defined in RFCXXXX. Security considerations: See section 9 of RFCXXXX. Interoperability considerations: MPEG-4 Visual provides a large and rich set of tools for the coding = of visual objects. For effective implementation of the standard, = subsets of the MPEG-4 Visual tool sets have been provided for use in = specific applications. These subsets, called 'Profiles', limit the size of = the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each = Profiles. A Profile@Level combination allows: o a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and o checking whether MPEG-4 devices comply with the standard ('conformance testing'). The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this = parameter mutually to the same value. Applications which use this media type: Audio and visual streaming and conferencing tools, Internet = messaging and Email applications. Additional information: none Person & email address to contact for further information: The authors of RFCXXXX. (See section 9) Intended usage: COMMON Author/Change controller: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 16] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 The authors of RFCXXXX. (See section 9) 6.2 SDP usage of MPEG-4 Visual The MIME media type video/MP4V string is mapped to fields in the = Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (video) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4V) goes in SDP "a=3Drtpmap" as the encoding = name. o The optional parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "profile-level-id" MAY go in the "a=3Dfmtp" = line. The optional parameter "mpeg4-newpred-upstream-message" MAY go in the "a=3Dfmtp" line, when and only when the "profile-level-id" is 145, = 146, 147 or 148(Advance Real Time Simple Profile/Level 1, 2, 3 or 4). These = two optional parameters are expressed as a MIME media type string as a semicolon separated list of parameter=3Dvalue pairs. The following are some examples of media representation in SDP: Simple Profile/Level 1, rate=3D90000(90KHz), "profile-level-id" is = present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V/90000 a=3Dfmtp:98 profile-level-id=3D1 Advance Real Time Simple Profile/Level 1, rate=3D25(25Hz), = "profile-level- id" and "mpeg4-newpred-upstream-message" are present in "a=3Dfmtp" = line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V/25 a=3Dfmtp:98 profile-level-id=3D145; = mpeg4-newpred-upstream-message=3D1 6.3 MIME type registration of MPEG-4 Audio MIME media type name: audio MIME subtype name: MP4A Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. = The default value is 90000. Other rates CAN be specified only if they = are set to the same value as the audio sampling rate (number of samples per second). Optional parameters: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 17] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in ISO/IEC 14496-1 [11]. This = parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. object: a decimal representation of the MPEG-4 Audio Object Type = value defined in ISO/IEC 14496-3 [5]. This parameter specifies the tool = to be used by the coder. It CAN be used to limit the capability within the specified "profile-level-id". bitrate: the data rate for the audio bit stream. cpresent: this parameter indicates whether audio payload = configuration data has been multiplexed into an RTP payload (See section 4.1 in = this document). config: a hexadecimal representation of an octet string that = expresses the audio payload configuration data "StreamMuxConfig", as defined = in ISO/IEC 14496-3 [5]. Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration = data SHALL be located at the MSB of the first octet. In the last octet, zero-padding bits, if necessary, shall follow the configuration = data. If the size of the configuration data is quite large, such large = config data is RECOMMENDED to be indicated by in-band mode (cpresent is = set to 1). ptime: RECOMMENDED duration of each packet in milliseconds. Published specification: Payload format specifications are described in this document. = Encoding specifications are provided in ISO/IEC 14496-3 [3][5]. Encoding considerations: This type is only defined for transfer via RTP. Security considerations: See Section 9 of RFCXXXX. Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding = of audio objects. For effective implementation of the standard, = subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 = Visual have been provided (see section 6.1). The audio stream SHALL be compliant with the MPEG-4 Audio Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this = parameter mutually to the same value. Furthermore, the "object" parameter can = be used to limit the capability within the specified Profile@Level in capability exchange. Applications which use this media type: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 18] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 Audio and video streaming and conferencing tools. Additional information: none Personal & email address to contact for further information: See Section 9 of RFCXXXX. Intended usage: COMMON Author/Change controller: See Section 9 of RFCXXXX. 6.4 SDP usage of MPEG-4 Audio The MIME media type audio/MP4A string is mapped to fields in the = Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (audio) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4A) goes in SDP "a=3Drtpmap" as the encoding = name. o The required parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "ptime" goes in SDP "a=3Dptime" attribute. o The optional parameter "profile-level-id" goes in the "a=3Dfmtp" = line to indicate the coder capability. The "object" parameter goes in the "a=3Dfmtp" attribute. The payload-format-specific parameters = "bitrate", "cpresent" and "config" go in the "a=3Dfmtp" line. If the string = after=20 "config=3D" is quite large, such large config data should not be=20 transmitted by SDP but should be transmitted by in-band mode. These=20 parameters are expressed as a MIME media type string, in the form of = as a semicolon separated list of parameter=3Dvalue pairs. The following are some examples of the media representation in SDP: For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz), m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/8000 a=3Dfmtp:96 = profile-level-id=3D9;object=3D8;cpresent=3D0;config=3D9128B1071070 a=3Dptime:20 For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of = 24 kHz), m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/24000 a=3Dfmtp:96 profile-level-id=3D1; bitrate=3D64000; cpresent=3D0; config=3D9122620000 In the above two examples, audio configuration data is not = multiplexed into the RTP payload and is described only in SDP. Furthermore, the "clock rate" is set to the audio sampling rate. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 19] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 If the clock rate has been set to its default value and it is = necessary to obtain the audio sampling rate, this can be done by parsing the "config" parameter (see the following example).=20 m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/90000 a=3Dfmtp:96 object=3D8; cpresent=3D0; config=3D9128B1071070 The following example shows that the audio configuration data appears = in the RTP payload. m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/90000 a=3Dfmtp:96 object=3D13; cpresent=3D1 7. Security Considerations RTP packets using the payload format defined in this specification = are subject to the security considerations discussed in the RTP = specification [8]. This implies that confidentiality of the media streams is = achieved by encryption. Because the data compression used with this payload = format is applied end-to-end, encryption may be performed on the compressed = data so there is no conflict between the two operations. This payload type does not exhibit any significant non-uniformity in = the receiver side computational complexity for packet processing to = cause a potential denial-of-service threat. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP = 9, RFC 2026, October 1996. 2 ISO/IEC 14496-2:1999, "Information technology - Coding of = audio-visual objects - Part2: Visual", December 1999. 3 ISO/IEC 14496-3:1999, "Information technology - Coding of = audio-visual objects - Part3: Audio", December 1999. 4 ISO/IEC 14496-2:1999/FDAM1:2000, December 1999. 5 ISO/IEC 14496-3:1999/FDAM1:2000, December 1999. 6 ISO/IEC 14496-1:1999, "Information technology - Coding of = audio-visual objects - Part1: Systems", December 1999. 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 20] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A = Transport Protocol for Real Time Applications", RFC 1889, Internet = Engineering Task Force, January 1996. 9 ISO/IEC 14496-2/COR1, "Information technology - Coding of = audio-visual objects - Part2: Visual, Technical corrigendum 1", March 2000. 9. Author's Addresses Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan Email: yoshihiro.kikuchi@toshiba.co.jp Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan Email: matsui@drl.mei.co.jp Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN Email: t-nomura@ccm.cl.nec.co.jp Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan. Email: fukunaga444@oki.co.jp Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan Email: kimata@nttvdt.hil.ntt.co.jp Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 21] RTP payload format for MPEG-4 Audio/Visual streams February 2000=20 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. ------=_NextPart_000_01C6_01BFDADE.F5AB43A0-- From rem-conf Tue Jun 20 10:02:04 2000 From rem-conf-request@es.net Tue Jun 20 10:02:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134RHC-0001NJ-00; Tue, 20 Jun 2000 09:53:26 -0700 Received: from snap.cs.berkeley.edu [128.32.37.81] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 134RHB-0001N8-00; Tue, 20 Jun 2000 09:53:25 -0700 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3) id JAA01658; Tue, 20 Jun 2000 09:52:40 -0700 Date: Tue, 20 Jun 2000 09:52:40 -0700 From: John Lazzaro Message-Id: <200006201652.JAA01658@snap.CS.Berkeley.EDU> To: 4on2andIP-sys@advent.ee.columbia.edu, kiku@eel.rdc.toshiba.co.jp, rem-conf@es.net, t-nomura@ccm.cl.nec.co.jp Subject: Re: Draft revised I/D of MPEG-4 A/V RTP Cc: eds@media.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ] Dear Kikuchi-san and all, ] ] I have revised the I/D as follows and attached it with this mail. ] ] > Regarding (2), I saw a message from John for the agreement on the revision ] > proposed by Nomura-san. A text for the revision will be sent soon to the ] > reflector by Nomura-san for the final approval. ] ] Best Regards, ] ] Toshiyuki Nomura, NEC [... from revised document ...] ] For MPEG-4 Audio coding tools except synthesis tools, as is true for ] other audio coders, if the payload of a packet is a single audio ] frame, packet loss will not impair the decodability of adjacent ] packets. On the other hands, MPEG-4 Audio synthesis tools may be ] sensitive to error. For example, an SA_access_unit in the payload may ] set a global value to a new value, which is then references throughout ] the audio content to make a macro change in the performance. In ] this case, an error in the payload influences all audio data produced ] after the error. In order to enhance error resiliency, the element ] of SA_access_unit that makes the above macro change should be ] transmitted across several SA_access_unit repeatedly. The number of ] repetition will be dependent on the network condition. Therefore, the ] additional media specific header for recovering errors will not be ] required for MPEG-4 Audio. Looks great ... ] The payload-format-specific parameters "bitrate", "cpresent" and ] "config" go in the "a=3Dfmtp" line. If the string after "config=" is ] quite large, such large config data should not be transmitted by ] SDP but should be transmitted by in-band mode. Looks great ... hopefully these updates will improve the odds of MP4 over RTP implementations working "out of the box" with Structured Audio streams! ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- From rem-conf Tue Jun 20 17:52:36 2000 From rem-conf-request@es.net Tue Jun 20 17:52:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134YXs-0001LN-00; Tue, 20 Jun 2000 17:39:08 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 134YXq-0001LD-00; Tue, 20 Jun 2000 17:39:06 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-125.dialup.cs.tu-berlin.de [130.149.145.125]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id CAA27727; Wed, 21 Jun 2000 02:34:30 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000617155206.02afc100@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 17 Jun 2000 15:52:52 +0200 To: "Dr. Injong Rhee" , "Shigeru Fukunaga" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" From: Stephan Wenger Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <10006170913.ZM17231@unity.ncsu.edu> References: <4.3.2.20000531085222.00dd0b60@mail.cs.tu-berlin.de> <4.3.2.20000601134605.00ac5e60@mail.cs.tu-berlin.de> <4.3.2.7.2.20000617010835.029cbb60@mail.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Oops. I stay corrected. Stephan >Stephan, > >I am afraid I have to disagree on this. :-) >Retx can help even with delays. Retransmitted >packets can be used to restore displayed reference frames and these >restore reference frames can be used by later frames as reference > to stop error >propagation. The same effect as NEWPRED can be achieved. Retx will >take the same delay as NEWPRED and gives the similar benefit (sometimes >with much lower bit overhead) >Additional advantages of retx are that it can be used for >*multicast* and also for >*streaming* without requiring re-encoding to change reference frames.... > >you can find more details about it >from an upcoming jsac paper by me and my student on this: > >Error recovery for Interactive video transmission over the internet. >JSAC, Vol 18. No. 6 June 2000. > >If there is an interest, I can send you the draft electronically. > >Regards, >Injong > >-- >Injong Rhee, Department of Computer Science >North Carolina State University, Raleigh, NC 27695 >Home page: http://www.csc.ncsu.edu/faculty/rhee >Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 From rem-conf Tue Jun 20 17:52:36 2000 From rem-conf-request@es.net Tue Jun 20 17:52:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134YYF-0001NE-00; Tue, 20 Jun 2000 17:39:31 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 134YYE-0001LD-00; Tue, 20 Jun 2000 17:39:30 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-125.dialup.cs.tu-berlin.de [130.149.145.125]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id CAA27916; Wed, 21 Jun 2000 02:34:42 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 Jun 2000 02:24:30 +0200 To: "Shigeru Fukunaga" , "Dr. Injong Rhee" , "Yoshihiro Kikuchi" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" From: Stephan Wenger Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <018401bfda90$097b8920$cc03ad0a@kansai.oki.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, I'm sorry for replying a bit late. I was on travel to VCIP in Australia, where I arrived just about now. I certainly see improvements in the language below concerning the RTCP feedback. There may be still a few places where the language could be improved further, but this is a minor issue compared to my general architectural concerns, which are not addressed in the documents below, and which therefore lead me to keep my concerns. Just briefly, I believe that it is inconsistent with current payload specs to include RTCP-based feedback only for NEWPRED and not for other known feedback schemes. I understand the rationale the proponents follow, but I don't feel it compelling. And, I continue to believe that we can add a well designed, architectural consistent feedback scheme for MPEG-4 into H.323 after finalization of the ES payload spec, without a delay of several years. Stephan At 05:17 PM 6/20/00 +0900, Shigeru Fukunaga wrote: >Dear Stephan, Dr. Rhee, and all, > >I revised the RTCP text again from the latest version which I sent yesterday. >At section 5.4, I revised text back to the original expression. >Would you please check the RTCP part of our ID? > >As Kikuchi-san reported this morning, we decided the deadline at the middle >of this week. If there is any problem in the RTCP part, would you please >indicate it as soon as possible? > >Best Regards, >Shigeru > >---- >5. RTCP Packetization of MPEG-4 upstream messages > >This section specifies the usage of particular RTCP packets to carry >the upstream messages generated by MPEG-4 decoders to advise >corresponding MPEG-4 encoder, using the MPEG-4 Audio/Visual upstream >messaging functionalities. This particular RTCP is called "RTCP-MP4U" >in the following. In the current specification, NEWPRED in the MPEG-4 >Visual Advance Real Time Simple (ARTS) Profile[4] is the only tool >which uses this RTCP-MP4U payload specification. The RTCP-MP4U packet >SHALL ONLY be used when it is indicated by some out of band means >that the corresponding MPEG-4 Visual codec is compliant with the ARTS >profile and it is indicated in the configuration information of the >MPEG-4 visual bitstream that the NEWPRED tool is enabled >(newpred_enable is set to 1). > > >5.1. Abstract of NEWPRED in the ARTS profile > >The NEWPRED tool in the MPEG-4 Visual ARTS profile is an error >resilience oriented tool using the upstream messages from the decoder >to the encoder. As the inter-frame coding is used in the MPEG-4 >Visual, the image degradation resulting from a packet loss will be >propagated toall predicted frames following the damaged frame. In >order to prevent this type of temporal error propagation, a complying >encoder may switch reference frames of the inter-frame coding, >according to the information available in the received NEWPRED >RTCP-MP4U. As the correctly decoded frame is used as the reference >frame, the error propagation is refreshed. > >As the intra refresh is not used, the coding efficiency can be kept >comparatively high, although using older reference frames then the >most recent one does add bits due to less efficient prediction (e.g. >through longer motion vectors due to a longer time interval for >prediction). And the NEWPRED can achieve the faster error recovery >than the intra refresh as well. > >There are two types of upstream messages; acknowledged message >(NP_ACK) and non-acknowledged message (NP_NACK). The syntax and >semantics of both type of upstream messages are defined in MPEG-4[4]. >NP_ACK and/or NP_NACK messages are transmitted on the RTCP-MP4U >packets in the NEWPRED. The selecting methods of reference frames >depend on the kind of used messages. > >5.2. RTCP-MP4U packets for low delay > >The RTCP-MP4U SHALL be treated as a completely different kind of RTCP >traffic, not following timing rules associated with normal RTCP >information. The performance of MPEG-4 tools using upstream messages >(such as NEWPRED) is sensitive to the delay of the upstream message >and does not require the full reliability of the upstream message. >Therefore, it is more effective to send the MPEG-4 upstream message >packets as soon as possible, i.e. as soon as a packet loss is >detected, without adding any random delays. > >5.3. Congestion control > >In the cases of the demand type of intra refresh, the number of bits >during congestion is greater than that in the error free condition. >This may cause more congestion. While in the NEWPRED, as the >intra-frame coding is not used, the bit increase is much lower than >that of the intra refresh even in the case of packet loss. NEWPRED >is less of a burden for the congestion. > >The amount of traffic necessary to convey NEWPRED RTCP-MP4U depends >on the strategy of the reference frame selection by the encoder, the >type of upstream messages sent by the decoder, frame rate, and >network conditions. In order to avoid the congestion, the amount of >upstream message packets should be small. In the NEWPRED, the >decoder can control the amount of the upstream message packets by >not sending some upstream messages; For example, in the case that >the NP_NACK messages are mainly used to select the reference frames >in the encoder, the decoder may not send the NP_ACK messages even if >it receives downstream data. On the other hand, in the case that >the NP_ACK messages are mainly used in the encoder, the decoder may >not send the NP_NACK messages. The amount of the upstream messages >is at most 5% (normally about 1%) of the visual downstream data. > >Especially the amount of NP_ACK messages is decreased in the case of >packet loss. Therefore the NP_ACK message has no additional burden >on the congestion. On the other hand, NP_NACK messages >corresponding to the lost packets are usually sent after the >congestion, because the decoder detects the packet loss after it >receives the next downstream packet. Again the NP_NACK message has >little additional burden on the congestion. > >To reduce the number of RTCP-MP4U packets, multiple upstream >messages can be concatenated in the payload of one RTCP-MP4U >packet. In this case, it is desirable to send these concatenated >messages as soon as possible. > >The RTCP-MP4U transmission interval depends on the interval of >decoding the visual downstream data. Both the receiving interval >of the visual RTP packet and the decoding time for each packet >data have some jitter associated with them. Therefore the >RTCP-MP4U transmission interval has some jitter by itself. It is >effective for the congestion control, and there is no need to add >any random delays. This means that the amount of jitter is enough >to avoid another congestion in the case of unicast. > >5.4. Limited to Unicast > >Although NEWPRED can work in multicast when the number of decoders >is small, in order to avoid additional congestion, the NEWPRED over >RTP/RTCP SHALL NOT be used in multicast. > >5.5. Relations with SR and RR > >The RTCP-MP4U packets SHALL be treated as a completely different >kind of packets from the normal RTCP packets such as SR, RR and so >on. > >For example, if the RTCP-MP4U packets is included in the >calculation of RTCP sending interval, the RR packets should be >generated in the timing of the RTCP-MP4U packets. In this case, >the interval of the RR packets would be smaller than 5 seconds, >and the number of the normal RTCP packets is much increased. This >is bad from the view point of the congestion. > >Therefore all RTCP-MP4U packets SHALL be ignored when analyzing >the information in the sender and receiver reports (SR and RR), >and only normal RTCP packets SHALL be used. > >Multiple RTCP-MP4U packets can be concatenated without any >intervening separators to form a compound RTCP packet. The >normal compound RTCP packet SHOULD start with SR or RR packets. >However in the case of compound RTCP-MP4U packet, other normal >RTCP packets SHALL NOT be included, and only RTCP-MP4U packets >SHALL be included in one compound RTCP-MP4U packet. > >5.6. MPEG-4 Visual upstream message packets definition > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=2|P| UMT | PT=RTCP_MP4U | length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | MPEG-4 Upstream Messages Payload (byte aligned) | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | : padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >version (V): 2 bits >Identifies the version of RTP, which is the same in RTCP >packets as in RTP data packets. > >padding (P): 1 bit >If the padding bit is set, this RTCP-MP4U packet contains >some additional padding octets at the end which are not >part of the control information. The last octet of the >padding is a count of how many padding octets should be >ignored. In the case several upstream messages are mapped >onto one RTCP-MP4U packet, padding should only be required >on the last individual message. > >upstream message type (UMT): 5 bits >Identifies the type of the MPEG-4 upstream messages. >0: forbidden >1: MPEG-4 Visual NEWPRED in the ARTS Profile >2-63: reserved >In this internet-draft, only the NEWPRED in the ARTS profile >is assigned as the candidate of the UMT for the moment. Some >other MPEG-4 Audio/Visual applications using the upstream >messages may be assigned in the future. > >packet type (PT): 8 bits >The value of the packet type (PT) identifier is the constant >RTCP_MP4U (TBD). > >SSRC: 32 bits >SSRC is the synchronization source identifier for the sender >of this packet. > >MPEG-4 Upstream Message Payload: variable >The syntax and semantics of the MPEG-4 upstream messages are >defined in the ISO/IEC 14496-2/3[4][5]. All messages are byte >aligned. Normally one message is mapped onto one RTCP packet, >and several messages with same UMT could be continuously >mapped onto one RTCP packet. One message SHALL NOT be >fragmented into different RTCP packets. > > > > >6. MIME type registration for MPEG-4 Audio/Visual streams > >... > >6.1 MIME type registration for MPEG-4 Visual > >... > >mpeg4-newpred-upstream-message: A boolean number to indicate >the receiver capability of sending the upstream message of >NEWPRED in MPEG-4 video. The upstream messages are delivered >on the particular RTCP packets which are described in Section >5. This capability exist when and only when the >"profile-level-id" is 145, 146, 147 or 148 (Advance Real Time >Simple Profile/Level 1, 2, 3 or 4). And this parameter is set >to '1' only for the real-time communication with the real-time >encoder. Therefore this parameter is usually set to '0' for >the e-mail applications or streaming applications without >real-time encoder. > >Example usages for these parameters are: >- MPEG-4 Visual Core Profile/Level 2: >Content-type: video/mp4v; profile-level-id=34 > >- MPEG-4 Visual Advanced Real Time Simple Profile/Level 1, >upstream message is not used: >Content-type: video/mp4v; profile-level-id=145; >mpeg4-newpred-upstream-message=0 > >... > >-- > Shigeru Fukunaga (fukunaga444@oki.co.jp) > Oki Electric Industry Co., LTD. > Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 From rem-conf Tue Jun 20 17:56:22 2000 From rem-conf-request@es.net Tue Jun 20 17:56:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134Yin-0001a7-00; Tue, 20 Jun 2000 17:50:25 -0700 Received: from rolex.csc.ncsu.edu [152.1.213.197] by mail1.es.net with esmtp (Exim 1.81 #2) id 134Yim-0001Zx-00; Tue, 20 Jun 2000 17:50:24 -0700 Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id UAA12808; Tue, 20 Jun 2000 20:49:12 -0400 (EDT) From: rhee@eos.ncsu.edu Message-Id: <200006210049.UAA12808@rolex.csc.ncsu.edu> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format To: stewe@cs.tu-berlin.de (Stephan Wenger) Date: Tue, 20 Jun 2000 20:49:12 -0400 (EDT) Cc: fukunaga444@oki.co.jp (Shigeru Fukunaga), rhee@unity.ncsu.edu (Dr. Injong Rhee), kiku@eel.rdc.toshiba.co.jp (Yoshihiro Kikuchi), 4on2andIP-sys@advent.ee.columbia.edu (4on2andIP-sys), rem-conf@es.net (IETF AVT) In-Reply-To: <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> from "Stephan Wenger" at Jun 21, 2000 02:24:30 AM X-Mailer: ELM [version 2.5 TKL/POP PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi All, I've been away for a few days to attend a conf in west coast; srry about the delay responding to you. I think I glanced over the document. I am afraid I have to agree with Stephen. I will give more detailed comments once I get to NC tmr. For those who expressed interests in receiving my paper, I will try to send you the paper as soon as I come back to my office. Thanks Injong > > Dear all, > > I'm sorry for replying a bit late. I was on travel to VCIP in > Australia, where I arrived just about now. > > I certainly see improvements in the language below concerning > the RTCP feedback. There may be still a few places where the > language could be improved further, but this is a minor issue > compared to my general architectural concerns, which are not > addressed in the documents below, and which therefore lead me > to keep my concerns. > > Just briefly, I believe that it is inconsistent with current payload > specs to include RTCP-based feedback only for NEWPRED and > not for other known feedback schemes. I understand the rationale > the proponents follow, but I don't feel it compelling. > > And, I continue to believe that we can add a well designed, > architectural consistent feedback scheme for MPEG-4 into H.323 > after finalization of the ES payload spec, without a delay of > several years. > > Stephan > > > > At 05:17 PM 6/20/00 +0900, Shigeru Fukunaga wrote: > >Dear Stephan, Dr. Rhee, and all, > > > >I revised the RTCP text again from the latest version which I sent yesterday. > >At section 5.4, I revised text back to the original expression. > >Would you please check the RTCP part of our ID? > > > >As Kikuchi-san reported this morning, we decided the deadline at the middle > >of this week. If there is any problem in the RTCP part, would you please > >indicate it as soon as possible? > > > >Best Regards, > >Shigeru > > > >---- > >5. RTCP Packetization of MPEG-4 upstream messages > > > >This section specifies the usage of particular RTCP packets to carry > >the upstream messages generated by MPEG-4 decoders to advise > >corresponding MPEG-4 encoder, using the MPEG-4 Audio/Visual upstream > >messaging functionalities. This particular RTCP is called "RTCP-MP4U" > >in the following. In the current specification, NEWPRED in the MPEG-4 > >Visual Advance Real Time Simple (ARTS) Profile[4] is the only tool > >which uses this RTCP-MP4U payload specification. The RTCP-MP4U packet > >SHALL ONLY be used when it is indicated by some out of band means > >that the corresponding MPEG-4 Visual codec is compliant with the ARTS > >profile and it is indicated in the configuration information of the > >MPEG-4 visual bitstream that the NEWPRED tool is enabled > >(newpred_enable is set to 1). > > > > > >5.1. Abstract of NEWPRED in the ARTS profile > > > >The NEWPRED tool in the MPEG-4 Visual ARTS profile is an error > >resilience oriented tool using the upstream messages from the decoder > >to the encoder. As the inter-frame coding is used in the MPEG-4 > >Visual, the image degradation resulting from a packet loss will be > >propagated toall predicted frames following the damaged frame. In > >order to prevent this type of temporal error propagation, a complying > >encoder may switch reference frames of the inter-frame coding, > >according to the information available in the received NEWPRED > >RTCP-MP4U. As the correctly decoded frame is used as the reference > >frame, the error propagation is refreshed. > > > >As the intra refresh is not used, the coding efficiency can be kept > >comparatively high, although using older reference frames then the > >most recent one does add bits due to less efficient prediction (e.g. > >through longer motion vectors due to a longer time interval for > >prediction). And the NEWPRED can achieve the faster error recovery > >than the intra refresh as well. > > > >There are two types of upstream messages; acknowledged message > >(NP_ACK) and non-acknowledged message (NP_NACK). The syntax and > >semantics of both type of upstream messages are defined in MPEG-4[4]. > >NP_ACK and/or NP_NACK messages are transmitted on the RTCP-MP4U > >packets in the NEWPRED. The selecting methods of reference frames > >depend on the kind of used messages. > > > >5.2. RTCP-MP4U packets for low delay > > > >The RTCP-MP4U SHALL be treated as a completely different kind of RTCP > >traffic, not following timing rules associated with normal RTCP > >information. The performance of MPEG-4 tools using upstream messages > >(such as NEWPRED) is sensitive to the delay of the upstream message > >and does not require the full reliability of the upstream message. > >Therefore, it is more effective to send the MPEG-4 upstream message > >packets as soon as possible, i.e. as soon as a packet loss is > >detected, without adding any random delays. > > > >5.3. Congestion control > > > >In the cases of the demand type of intra refresh, the number of bits > >during congestion is greater than that in the error free condition. > >This may cause more congestion. While in the NEWPRED, as the > >intra-frame coding is not used, the bit increase is much lower than > >that of the intra refresh even in the case of packet loss. NEWPRED > >is less of a burden for the congestion. > > > >The amount of traffic necessary to convey NEWPRED RTCP-MP4U depends > >on the strategy of the reference frame selection by the encoder, the > >type of upstream messages sent by the decoder, frame rate, and > >network conditions. In order to avoid the congestion, the amount of > >upstream message packets should be small. In the NEWPRED, the > >decoder can control the amount of the upstream message packets by > >not sending some upstream messages; For example, in the case that > >the NP_NACK messages are mainly used to select the reference frames > >in the encoder, the decoder may not send the NP_ACK messages even if > >it receives downstream data. On the other hand, in the case that > >the NP_ACK messages are mainly used in the encoder, the decoder may > >not send the NP_NACK messages. The amount of the upstream messages > >is at most 5% (normally about 1%) of the visual downstream data. > > > >Especially the amount of NP_ACK messages is decreased in the case of > >packet loss. Therefore the NP_ACK message has no additional burden > >on the congestion. On the other hand, NP_NACK messages > >corresponding to the lost packets are usually sent after the > >congestion, because the decoder detects the packet loss after it > >receives the next downstream packet. Again the NP_NACK message has > >little additional burden on the congestion. > > > >To reduce the number of RTCP-MP4U packets, multiple upstream > >messages can be concatenated in the payload of one RTCP-MP4U > >packet. In this case, it is desirable to send these concatenated > >messages as soon as possible. > > > >The RTCP-MP4U transmission interval depends on the interval of > >decoding the visual downstream data. Both the receiving interval > >of the visual RTP packet and the decoding time for each packet > >data have some jitter associated with them. Therefore the > >RTCP-MP4U transmission interval has some jitter by itself. It is > >effective for the congestion control, and there is no need to add > >any random delays. This means that the amount of jitter is enough > >to avoid another congestion in the case of unicast. > > > >5.4. Limited to Unicast > > > >Although NEWPRED can work in multicast when the number of decoders > >is small, in order to avoid additional congestion, the NEWPRED over > >RTP/RTCP SHALL NOT be used in multicast. > > > >5.5. Relations with SR and RR > > > >The RTCP-MP4U packets SHALL be treated as a completely different > >kind of packets from the normal RTCP packets such as SR, RR and so > >on. > > > >For example, if the RTCP-MP4U packets is included in the > >calculation of RTCP sending interval, the RR packets should be > >generated in the timing of the RTCP-MP4U packets. In this case, > >the interval of the RR packets would be smaller than 5 seconds, > >and the number of the normal RTCP packets is much increased. This > >is bad from the view point of the congestion. > > > >Therefore all RTCP-MP4U packets SHALL be ignored when analyzing > >the information in the sender and receiver reports (SR and RR), > >and only normal RTCP packets SHALL be used. > > > >Multiple RTCP-MP4U packets can be concatenated without any > >intervening separators to form a compound RTCP packet. The > >normal compound RTCP packet SHOULD start with SR or RR packets. > >However in the case of compound RTCP-MP4U packet, other normal > >RTCP packets SHALL NOT be included, and only RTCP-MP4U packets > >SHALL be included in one compound RTCP-MP4U packet. > > > >5.6. MPEG-4 Visual upstream message packets definition > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |V=2|P| UMT | PT=RTCP_MP4U | length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | SSRC | > > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > > | MPEG-4 Upstream Messages Payload (byte aligned) | > > | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | : padding | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >version (V): 2 bits > >Identifies the version of RTP, which is the same in RTCP > >packets as in RTP data packets. > > > >padding (P): 1 bit > >If the padding bit is set, this RTCP-MP4U packet contains > >some additional padding octets at the end which are not > >part of the control information. The last octet of the > >padding is a count of how many padding octets should be > >ignored. In the case several upstream messages are mapped > >onto one RTCP-MP4U packet, padding should only be required > >on the last individual message. > > > >upstream message type (UMT): 5 bits > >Identifies the type of the MPEG-4 upstream messages. > >0: forbidden > >1: MPEG-4 Visual NEWPRED in the ARTS Profile > >2-63: reserved > >In this internet-draft, only the NEWPRED in the ARTS profile > >is assigned as the candidate of the UMT for the moment. Some > >other MPEG-4 Audio/Visual applications using the upstream > >messages may be assigned in the future. > > > >packet type (PT): 8 bits > >The value of the packet type (PT) identifier is the constant > >RTCP_MP4U (TBD). > > > >SSRC: 32 bits > >SSRC is the synchronization source identifier for the sender > >of this packet. > > > >MPEG-4 Upstream Message Payload: variable > >The syntax and semantics of the MPEG-4 upstream messages are > >defined in the ISO/IEC 14496-2/3[4][5]. All messages are byte > >aligned. Normally one message is mapped onto one RTCP packet, > >and several messages with same UMT could be continuously > >mapped onto one RTCP packet. One message SHALL NOT be > >fragmented into different RTCP packets. > > > > > > > > > >6. MIME type registration for MPEG-4 Audio/Visual streams > > > >... > > > >6.1 MIME type registration for MPEG-4 Visual > > > >... > > > >mpeg4-newpred-upstream-message: A boolean number to indicate > >the receiver capability of sending the upstream message of > >NEWPRED in MPEG-4 video. The upstream messages are delivered > >on the particular RTCP packets which are described in Section > >5. This capability exist when and only when the > >"profile-level-id" is 145, 146, 147 or 148 (Advance Real Time > >Simple Profile/Level 1, 2, 3 or 4). And this parameter is set > >to '1' only for the real-time communication with the real-time > >encoder. Therefore this parameter is usually set to '0' for > >the e-mail applications or streaming applications without > >real-time encoder. > > > >Example usages for these parameters are: > >- MPEG-4 Visual Core Profile/Level 2: > >Content-type: video/mp4v; profile-level-id=34 > > > >- MPEG-4 Visual Advanced Real Time Simple Profile/Level 1, > >upstream message is not used: > >Content-type: video/mp4v; profile-level-id=145; > >mpeg4-newpred-upstream-message=0 > > > >... > > > >-- > > Shigeru Fukunaga (fukunaga444@oki.co.jp) > > Oki Electric Industry Co., LTD. > > Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 > > > From rem-conf Tue Jun 20 19:23:53 2000 From rem-conf-request@es.net Tue Jun 20 19:23:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134a4A-0004oL-00; Tue, 20 Jun 2000 19:16:34 -0700 Received: from gw.kkisr.co.jp [210.163.169.34] by mail1.es.net with smtp (Exim 1.81 #2) id 134a49-0004ns-00; Tue, 20 Jun 2000 19:16:33 -0700 Received: from Afu5s877Z (unverified [32.100.175.199]) by gw.kkisr.co.jp (EMWAC SMTPRS 0.83) with SMTP id ; Wed, 21 Jun 2000 11:16:21 +0900 DATE: 20 Jun 00 9:23:20 PM FROM: C7gtcDIyS@dmail0.dion.ne.jp Message-ID: SUBJECT: thriving online business Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Build a residual income from time you spend on the Internet placing FREE advertisements like this. Successful Internet company wants you to help them market their products and services online. Place FREE pre-written ads and get paid commissions on any sales that you bring to the company. A FREE Web Site, and complete training and instructions will be provided to you. To Register with the program and to begin receiving instructions, simply mailto:theteam2@england.com?subject=RegisterMe AND INSERT YOUR FIRST AND LAST NAME AS TEXT to be removed from this list mailto:24remo@england.com.com?subject=remove From rem-conf Wed Jun 21 13:10:53 2000 From rem-conf-request@es.net Wed Jun 21 13:10:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 134qZX-0001Ci-00; Wed, 21 Jun 2000 12:54:03 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 134qZV-0001CY-00; Wed, 21 Jun 2000 12:54:01 -0700 Received: from dynamicsoft.com (1Cust239.tnt2.freehold.nj.da.uu.net [63.17.114.239]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA16318; Wed, 21 Jun 2000 15:55:18 -0400 (EDT) Message-ID: <39511DA2.DE901F31@dynamicsoft.com> Date: Wed, 21 Jun 2000 15:55:14 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Hari Krishna Vuppaladhadiam CC: rem-conf@es.net Subject: Re: DTMF References: <00e101bfda43$2226dee0$03000004@hariv.domain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list RFC2833 describes transport of DTMF in RTP. http://www.ietf.org/rfc/rfc2833.txt -Jonathan R. Hari Krishna Vuppaladhadiam wrote: > > Hi everyone, > > I would like to know the need for DTMF generator and Detector? > Where is it positioned? > And also how is it sent ? > Normally speech data is sent as payload in RTP. Do we need to send both > Speech as well as DTMF in RTP? If so how? > > Can anyone clarify DTMF related issues for typical VoN applications? > > Regards > Hari -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Thu Jun 22 06:50:23 2000 From rem-conf-request@es.net Thu Jun 22 06:50:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13575a-0000Qq-00; Thu, 22 Jun 2000 06:32:14 -0700 Received: from ferao.jungle.bt.co.uk [132.146.107.45] by mail1.es.net with esmtp (Exim 1.81 #2) id 13575Y-0000OP-00; Thu, 22 Jun 2000 06:32:12 -0700 Received: from sherekhan.jungle.bt.co.uk (sherekhan [132.146.107.25]) by ferao.jungle.bt.co.uk (8.9.1b+Sun/Jungle-8.9.1-03) with SMTP id OAA16078 for ; Thu, 22 Jun 2000 14:19:10 +0100 (BST) Received: from jungle.bt.co.uk ([132.146.107.59]) by sherekhan.jungle.bt.co.uk; Thu, 22 Jun 00 14:19:08 BST Message-Id: <39521632.79DA418@jungle.bt.co.uk> Date: Thu, 22 Jun 2000 14:35:46 +0100 From: Sylvie Brunelle X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: rem Subject: minimum RTCP interval Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everybody, I have a question concerning the minimum RTCP interval. A value of 5sec is RECOMMENDED but how was this value chosen (why not 3,4, 6, 7...)? Is this choice based on some study? Cheers, Sylvie Brunelle From rem-conf Thu Jun 22 23:56:53 2000 From rem-conf-request@es.net Thu Jun 22 23:56:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 135NCP-000388-00; Thu, 22 Jun 2000 23:44:21 -0700 Received: from redball.dynamicsoft.com [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 135NCN-00037y-00; Thu, 22 Jun 2000 23:44:19 -0700 Received: from dynamicsoft.com (1Cust1.tnt1.freehold.nj.da.uu.net [63.17.113.1]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA25061; Fri, 23 Jun 2000 02:45:29 -0400 (EDT) Message-ID: <3953078C.6F8DDE89@dynamicsoft.com> Date: Fri, 23 Jun 2000 02:45:32 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sylvie Brunelle CC: rem Subject: Re: minimum RTCP interval References: <39521632.79DA418@jungle.bt.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I was not privy to the initial discussions in the selection; I think it was a reasonable compromise between freshness of data and bandwidth usage. Recent work we have done with timer reconsideration has shown that this number, for receivers, really needs to be several times larger, at least, than typical network latencies. Otherwise, step joins can result in large RTCP floods (multicast only, of course). The latest version of RTP does allow this 5s value to be scaled down if RTCP bandwidth usage is increased. See section 6.2 of: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-07.txt -Jonathan R. Sylvie Brunelle wrote: > > Hi everybody, > > I have a question concerning the minimum RTCP interval. A value of 5sec > is RECOMMENDED but how was this value chosen (why not 3,4, 6, 7...)? Is > this choice based on some study? > Cheers, > Sylvie Brunelle -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Fri Jun 23 06:32:11 2000 From rem-conf-request@es.net Fri Jun 23 06:32:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 135TTy-0000ER-00; Fri, 23 Jun 2000 06:26:54 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 135TTx-0000EH-00; Fri, 23 Jun 2000 06:26:53 -0700 Received: from purple.east.isi.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 23 Jun 2000 14:25:53 +0100 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id CAA03225; Fri, 23 Jun 2000 02:39:53 +0100 Message-Id: <200006230139.CAA03225@purple.east.isi.edu> To: Stephan Wenger cc: Shigeru Fukunaga , "Dr. Injong Rhee" , Yoshihiro Kikuchi , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, IETF AVT Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: Message from Stephan Wenger of "Wed, 21 Jun 2000 02:24:30 +0200." <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> Date: Thu, 22 Jun 2000 21:39:52 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Stephan Wenger writes: >I certainly see improvements in the language below concerning >the RTCP feedback. There may be still a few places where the >language could be improved further, but this is a minor issue >compared to my general architectural concerns, which are not >addressed in the documents below, and which therefore lead me >to keep my concerns. > >Just briefly, I believe that it is inconsistent with current payload >specs to include RTCP-based feedback only for NEWPRED and >not for other known feedback schemes. I understand the rationale >the proponents follow, but I don't feel it compelling. I have to agree with Stephan on this. We clearly do not have consensus on the current approach, which makes me unwilling to push the current spec forward as it stands. >And, I continue to believe that we can add a well designed, >architectural consistent feedback scheme for MPEG-4 into H.323 >after finalization of the ES payload spec, without a delay of >several years. Or, at least, we can derive an ES payload format which allows for a range of backchannel techniques. Consider the means by which we have added RTP- based FEC/reliability to a number of payload formats, where the format is independent of the FEC scheme (e.g. RFC 2198, 2733). I'm not convinced there is a need to closely couple the backchannel to the payload format. Colin From rem-conf Fri Jun 23 06:32:11 2000 From rem-conf-request@es.net Fri Jun 23 06:32:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 135TT6-0000Dr-00; Fri, 23 Jun 2000 06:26:00 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 135TT5-0000Dh-00; Fri, 23 Jun 2000 06:25:59 -0700 Received: from purple.east.isi.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 23 Jun 2000 14:25:32 +0100 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id EAA03552 for ; Fri, 23 Jun 2000 04:34:02 +0100 Message-Id: <200006230334.EAA03552@purple.east.isi.edu> To: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-rtp-g7221-00.txt In-Reply-To: Message from Internet-Drafts@ietf.org of "Fri, 16 Jun 2000 06:43:15 EDT." <200006161043.GAA08305@ietf.org> Date: Thu, 22 Jun 2000 23:34:01 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a two-week working group last call on the RTP Payload Format for ITU-T Recommendation G.722.1 audio. If no significant comments are received by 7th July we shall submit this draft for publication as a proposed standard RFC. Comments should be sent to the mailing list, or directly to the authors of the draft. Thanks, Colin --> Internet-Drafts@ietf.org writes: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Audio/Video Transport Working Group of the IETF. > > Title : RTP Payload Format for ITU-T Recommendation G.722.1 > Author(s) : P. Luthi > Filename : draft-ietf-avt-rtp-g7221-00.txt > Pages : 7 > Date : 15-Jun-00 > >ITU-T Recommendation G.722.1 [2] is a wide-band audio codec, which >operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. >This document describes the payload format for including G.722.1 >generated bit streams within an RTP packet [3]. Also included here >are the necessary details for the use of G.722.1 with MIME [4] and >SDP [5]. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g7221-00.txt From rem-conf Fri Jun 23 06:32:11 2000 From rem-conf-request@es.net Fri Jun 23 06:32:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 135TTq-0000EF-00; Fri, 23 Jun 2000 06:26:46 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 135TTo-0000E5-00; Fri, 23 Jun 2000 06:26:44 -0700 Received: from purple.east.isi.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 23 Jun 2000 14:25:57 +0100 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id CAA03139; Fri, 23 Jun 2000 02:09:30 +0100 Message-Id: <200006230109.CAA03139@purple.east.isi.edu> To: Dave Singer cc: Paul Christ , 4on2andIP-sys@advent.ee.columbia.edu, CURET Dominique FTRD/DMI/REN , peterw@us.ibm.com, rem-conf@es.net, Yan Xiang Chen , Stefan Wesner Subject: Re: MPEG-4 (including Flexmux), over RTP/RTSP In-Reply-To: Message from Dave Singer of "Tue, 13 Jun 2000 12:48:22 PDT." Date: Thu, 22 Jun 2000 21:09:29 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave (et al), Finally managing to catch up on the MPEG-4 related email after changing jobs, I have a couple of comments... --> Dave Singer writes: >At 19:52 +0200 6/13/00, Paul Christ wrote: >>We welcome such a paper and will try to help further to improve it. >>If you don't mind: We should avoid "memoryless" discussions :-) >>AS agreed in the IETF >> >> C.Guillemot et al., >> "RTP Payload Format for MPEG-4 with Flexible Error Resiliency", >> IETF Draft, draft-ietf-avt-mpeg4streams-00, >> March 1 2000, expires Sept 1 2000 >> >> R. Civanlar et al., >> " RTP Payload Format for MPEG-4 Streams", >> IETF Draft, draft-ietf-avt-rtp-mpeg4-02, ? >> ? 2000, expires ?? 20000 >> >>are to become experimental RFCs - for technical reasons. >>which state should not simply be overwritten >>by declarative statements. > >Right. The purpose of my draft was mostly to focus on the areas on >which there was probably agreement, but no actual specification, and >to admit that we were likely to have a plurality of RTP packings >going ahead. I certainly have no desire to discard existing work in >the area; rather to build on it and flesh out all the other areas. > >It seems, from reading your comments, that your disagreements are >only in the area of packing formats. > >1) You don't want to require support for the simple packing done by >Carsten et al., whereas I feel that it would be good if there is one, >simple, general packing that everyone implements and that can carry >any MPEG-4 stream, perhaps in a non-optimal fashion. I think it >would be disappointing if there was no such spec., and Carsten's >draft seems like the best contender. Do you disagree with the >principle (that there should be a simple interoperable draft), or the >specification itself? With the proviso that we may need one format for elementary streams and one for systems streams, I agree on the principle that we should have a single standard format which MUST be supported. This should be as simple as possible, perhaps even to the extent of being knowingly less resistent to packet loss than the alternatives. >2) My recommendation that we look at existing techniques in the IETF >for reliability -- FEC, re-transmission. I didn't mention redundant >audio, though as you say that is another existing technique which is >orthogonal to the encoding schemes used. I only phrased this as a >recommendation, and I guess it could be weakened from there. I >certainly have no quibble in principle with combined source/channel >coding, which is, I think, the essence of your draft. My draft was >explicitly written to get us out of the deadlock of trying to decide, >now, a single packing scheme, and permit (maybe even encourage) >research, development, interoperation, and promotion of schemes. >It's clear from the multiplicity of drafts that we are not yet in >consensus. Also agreed. It would be helpful, I think, if the reliability schemes were written as add-ons to the base format. This would let us mix-and-match the reliability schemes as appropriate. Colin From rem-conf Sat Jun 24 23:37:33 2000 From rem-conf-request@es.net Sat Jun 24 23:37:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1365pE-0007Gz-00; Sat, 24 Jun 2000 23:23:24 -0700 Received: from (vivaldi.vcon.co.il) [212.29.219.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 1365pC-0007EC-00; Sat, 24 Jun 2000 23:23:22 -0700 Received: by vivaldi.vcon.co.il with Internet Mail Service (5.5.2650.21) id ; Sun, 25 Jun 2000 09:27:01 +0200 Message-ID: <28620B5447EFD311919000600860FCB248843A@vivaldi.vcon.co.il> From: Tzvi Kasten To: "'H.323 '" , 'H323 Implementors ' , rem-conf@es.net Subject: G.723.1 Date: Sun, 25 Jun 2000 09:27:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list All, In H.225.0 Annex F ( audio packetization) it is written in the text: "The first packet of a talkspurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header" Would this indicate that the packet needs to start with the talkspurt frame or could it there be several silence frames in the packet and then the first not silence frame and that the marker bit does not necessarily refer to the first frame in the packet? How has this generally been interpreted? Thanks Tzvi Kasten Networking Infrastructures Group Manager Research & Development VCON Ltd. Tel: 09-9590020 ( 972-9-959-0020) Email: zvik@vcon.co.il http://www.vcon.com From rem-conf Sun Jun 25 11:15:57 2000 From rem-conf-request@es.net Sun Jun 25 11:15:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136Gln-0006ZM-00; Sun, 25 Jun 2000 11:04:35 -0700 Received: from adsl-63-196-11-252.dsl.snfc21.pacbell.net (hazard.aciri.org) [63.196.11.252] by mail1.es.net with esmtp (Exim 1.81 #2) id 136Gll-0006ZC-00; Sun, 25 Jun 2000 11:04:33 -0700 Received: from hazard.aciri.org (localhost.aciri.org [127.0.0.1]) by hazard.aciri.org (8.9.3/8.9.3) with ESMTP id LAA43675; Sun, 25 Jun 2000 11:04:22 -0700 (PDT) (envelope-from mjh@hazard.aciri.org) From: Mark Handley X-Organisation: ACIRI To: Tzvi Kasten cc: "'H.323 '" , "'H323 Implementors '" , rem-conf@es.net Subject: Re: G.723.1 In-reply-to: Your message of "Sun, 25 Jun 2000 09:27:00 +0200." <28620B5447EFD311919000600860FCB248843A@vivaldi.vcon.co.il> Date: Sun, 25 Jun 2000 11:04:22 -0700 Message-ID: <43673.961956262@hazard.aciri.org> Sender: mjh@aciri.org X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >In H.225.0 Annex F ( audio packetization) it is written in the text: > >"The first packet of a talkspurt (first packet after a silence period) is >distinguished by setting the marker bit in the RTP data header" > >Would this indicate that the packet needs to start with the talkspurt frame >or could it there be several silence frames in the packet and then the first >not silence frame and that the marker bit does not necessarily refer to the >first frame in the packet? The general idea behind the marker bit with audio is as a hint to the receiver that this is a good time to adjust the adaptive playout buffer. RFC 1890 says: For applications which send no packets during silence, the first packet of a talkspurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero. If you have a codec that inserts explicit silence frames so that there's a continuous packet stream even when the sender is not talking, then I don't think it makes sense to ever set the marker bit. Cheers, Mark From rem-conf Sun Jun 25 14:48:45 2000 From rem-conf-request@es.net Sun Jun 25 14:48:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136KAS-00058y-00; Sun, 25 Jun 2000 14:42:16 -0700 Received: from (hercules.servitel.es) [194.179.119.35] by mail1.es.net with smtp (Exim 1.81 #2) id 136KAM-00057b-00; Sun, 25 Jun 2000 14:42:10 -0700 Received: from wolf (unverified [194.179.119.45]) by hercules.servitel.es (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 25 Jun 2000 23:36:21 +0200 Received: from 171.24.22.36 by 152.224.15.22 (8.8.5/8.7.3) with SMTP id XAA08418 for ; Sun, 25 June 2000 17:42:13 -0700 (EDT) To: Success@AOL.COM Bcc: info@es.net, nisph@es.net, oberma@es.net, oberman@es.net, rem-conf@es.net, rem-conf-request@es.net, ssmith@es.net, videophone@es.net, videophone-request@es.net From: Subject: Business Success! Reply-To: X-PMFLAGS: X-UIDL: Comments: Authenticated Sender is Message-Id: <73118811_99141170> content-length: 2477 Date: Sun, 25 Jun 2000 14:42:10 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The Truth Is Finally Revealed.... How Does The Richest Man In The World Use The Greastest Business Secrets Of All Time To Make Over 32.4 Million Dollars A Day?!! No matter who you are, where you live or what your sex, age or race is by the time you finish reading this special article, you will know: * How to start a proven money making business that requires no inventory, no shipping and no employees within 7 days, guaranteed! * How to get a $300 professionally designed Web Site for FREE! * How to increase your sales by more than 137% in 30 days regardless of your business! * How to get paid for a 1000-hour workweek, without going to work! * How to turn 50 cents into $50, with a simple click of a button! * How to get a $179 business-building CD-ROM for FREE! * If you ever wanted a business where you could hit the ground running.... a business where you could just open a box and start makeing immedate profits.... a business that's completely set up and ready to pull in maximum sales.... with a product that sells itself... then I've got some greats news for you! Act NOW Instant Information Request Directions **>NOTE: You may also just Click Below to send it through your normal e-mail program. mailto:netcash3000@netease.com?subject=maxinfo25 It's much easier to do it this way, it will fill in the return e-mail and subject for you. 2. You will receive the complet info on the reports via e-mail within 24 hours. P.S. Act NOW!-- Only the first 75 request will be granted to recive this Special Web Site e-Report for *FREE* titled "The Greatest Business Secrets Of All Time" P.P.S. *FREE Download Bonus e-Manual* "Microsoft, Viagra & Your Business Success" given to the first 35 people to respond within the next 24 hours, You FREE reports will be fulfilled in the order in which they were received. Privacy Policy: We respect your privacy and your e-mail address/name will be kept strictly private it will never be sold, shared or given away for any reason. Simple Removal Instructions: To Be Removed: mailto:netcash@yeah.net?subject=remove25 NO FLAMES!! You will not be added to the remove database if you do this. No Exceptions, anything but "remove" in the subject and you will not be removed from the list. You will then be deleted from our e-mail database forever, Thank You. From rem-conf Mon Jun 26 03:52:08 2000 From rem-conf-request@es.net Mon Jun 26 03:52:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136WOY-0005vC-00; Mon, 26 Jun 2000 03:45:38 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 136WOW-0005uq-00; Mon, 26 Jun 2000 03:45:36 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29142; Mon, 26 Jun 2000 06:45:24 -0400 (EDT) Message-Id: <200006261045.GAA29142@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-11.txt Date: Mon, 26 Jun 2000 06:45:24 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher,I. Suconick, B. Strahm Filename : draft-ietf-avt-rtp-mib-11.txt Pages : 35 Date : 23-Jun-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol(RTP) systems [RFC1889]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-11.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mib-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000623134649.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000623134649.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jun 26 03:52:08 2000 From rem-conf-request@es.net Mon Jun 26 03:52:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136WIs-0005gZ-00; Mon, 26 Jun 2000 03:39:46 -0700 Received: from tama3.tas.ntt.co.jp [192.68.248.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 136WIi-0005gE-00; Mon, 26 Jun 2000 03:39:45 -0700 Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id TAA17410; Mon, 26 Jun 2000 19:38:40 +0900 (JST) (envelope-from kimata@nttvdt.hil.ntt.co.jp) Received: from nttvdt.hil.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/06/05/00) with ESMTP id TAA22367; Mon, 26 Jun 2000 19:38:38 +0900 (JST) (envelope-from kimata@nttvdt.hil.ntt.co.jp) Received: by nttvdt.hil.ntt.co.jp (8.9.3/hil-1.4b); Mon, 26 Jun 2000 19:38:33 +0900 (JST) Message-Id: <200006261038.TAA19503@nttvdt.hil.ntt.co.jp> Received: from Mary by cartier.hil.ntt.co.jp (8.9.3/3.7W/hil-2.2) with SMTP id TAA18928; Mon, 26 Jun 2000 19:38:35 +0900 (JST) Date: Mon, 26 Jun 2000 19:34:56 +0900 From: Hideaki Kimata To: c.perkins@cs.ucl.ac.uk, fukunaga444@oki.co.jp, rhee@unity.ncsu.edu, kiku@eel.rdc.toshiba.co.jp, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net, stewe@cs.tu-berlin.de Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <200006230139.CAA03225@purple.east.isi.edu> References: of "Wed, 21 Jun 2000 02:24:30 +0200." <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> <200006230139.CAA03225@purple.east.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.09 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colin and Stephan, and all As I pointed out in previous Email, NEWPRED is one tool of ARTS profile in MPEG-4. And NEWPRED RTCP messages are only transmitted between ARTS profile terminals. This means the usage of these messages is not definitly generic, and setup procedure should be also different from other backward channel messages. I mean the setup should be after receiving profile and level indication of MPEG-4. I believe this fact makes objection for NEWPRED RTCP meaningless. Best regards, Hideaki Kimata On Thu, 22 Jun 2000 21:39:52 -0400 Colin Perkins wrote: >--> Stephan Wenger writes: >>I certainly see improvements in the language below concerning >>the RTCP feedback. There may be still a few places where the >>language could be improved further, but this is a minor issue >>compared to my general architectural concerns, which are not >>addressed in the documents below, and which therefore lead me >>to keep my concerns. >> >>Just briefly, I believe that it is inconsistent with current payload >>specs to include RTCP-based feedback only for NEWPRED and >>not for other known feedback schemes. I understand the rationale >>the proponents follow, but I don't feel it compelling. > >I have to agree with Stephan on this. We clearly do not have consensus on >the current approach, which makes me unwilling to push the current spec >forward as it stands. > >>And, I continue to believe that we can add a well designed, >>architectural consistent feedback scheme for MPEG-4 into H.323 >>after finalization of the ES payload spec, without a delay of >>several years. > >Or, at least, we can derive an ES payload format which allows for a range >of backchannel techniques. Consider the means by which we have added RTP- >based FEC/reliability to a number of payload formats, where the format is >independent of the FEC scheme (e.g. RFC 2198, 2733). I'm not convinced >there is a need to closely couple the backchannel to the payload format. > >Colin > > ----------------------------------------- HIDEAKI KIMATA NTT Cyber Space Laboratories Email: kimata@nttvdt.hil.ntt.co.jp Phone: +81 468 59 3124 Fax : +81 468 59 2829 ----------------------------------------- From rem-conf Mon Jun 26 04:03:08 2000 From rem-conf-request@es.net Mon Jun 26 04:03:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136Wbr-0007Gn-00; Mon, 26 Jun 2000 03:59:23 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 136Wbo-0007Ds-00; Mon, 26 Jun 2000 03:59:21 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id TAA17908; Mon, 26 Jun 2000 19:58:45 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id TAA05490; Mon, 26 Jun 2000 19:58:44 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id TAA23212; Mon, 26 Jun 2000 19:58:44 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id TAA00921; Mon, 26 Jun 2000 19:58:44 +0900 (JST) Message-ID: <051a01bfdf5d$77b582c0$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Stephan Wenger" , "Colin Perkins" Cc: "Shigeru Fukunaga" , "Dr. Injong Rhee" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Yoshihiro Kikuchi" References: <200006230139.CAA03225@purple.east.isi.edu> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Mon, 26 Jun 2000 19:58:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colin, all, I agree with Colin. I understand that there are concerns to include NEWPRED RTCP supporting only ARTS profile. On the other hand, I don't think there is a good reason that other backchannel schemes must be rushed into the I/D. I fully support Colin's comment of not to couple backchannel to the payload format. I would like to propose moving NEWPRED RTCP to another I/D and not to include any backchannel scheme in the MPEG-4 Audio/Visual RTP payload format document. Best regards, Yoshihiro ----- Original Message ----- From: Colin Perkins To: Stephan Wenger Cc: Shigeru Fukunaga ; Dr. Injong Rhee ; Yoshihiro Kikuchi ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT Sent: Friday, June 23, 2000 10:39 AM Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > --> Stephan Wenger writes: > >I certainly see improvements in the language below concerning > >the RTCP feedback. There may be still a few places where the > >language could be improved further, but this is a minor issue > >compared to my general architectural concerns, which are not > >addressed in the documents below, and which therefore lead me > >to keep my concerns. > > > >Just briefly, I believe that it is inconsistent with current payload > >specs to include RTCP-based feedback only for NEWPRED and > >not for other known feedback schemes. I understand the rationale > >the proponents follow, but I don't feel it compelling. > > I have to agree with Stephan on this. We clearly do not have consensus on > the current approach, which makes me unwilling to push the current spec > forward as it stands. > > >And, I continue to believe that we can add a well designed, > >architectural consistent feedback scheme for MPEG-4 into H.323 > >after finalization of the ES payload spec, without a delay of > >several years. > > Or, at least, we can derive an ES payload format which allows for a range > of backchannel techniques. Consider the means by which we have added RTP- > based FEC/reliability to a number of payload formats, where the format is > independent of the FEC scheme (e.g. RFC 2198, 2733). I'm not convinced > there is a need to closely couple the backchannel to the payload format. > > Colin > > From rem-conf Mon Jun 26 05:06:32 2000 From rem-conf-request@es.net Mon Jun 26 05:06:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136XYj-0004Gg-00; Mon, 26 Jun 2000 05:00:13 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 136XYg-0004GR-00; Mon, 26 Jun 2000 05:00:11 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-209.dialup.cs.tu-berlin.de [130.149.145.209]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id NAA02870 for ; Mon, 26 Jun 2000 13:54:02 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000626132326.00ddbd80@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Jun 2000 13:55:25 +0200 To: rem-conf@es.net From: Stephan Wenger Subject: Network flooding when using feedback Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, I'm working on an Internet draft covering feedback messages for predictive video coding schemes. This work is triggered by the MPEG-ES packetization discussion, but, in fact, it should have been done much earlier. One of the main concerns when using feedback channels are network flooding problems in multicast environments. The scaling problem on the feedback channel is well understood. Any irregular behavior on the forward channel, such as a packet loss, may result in feedback messages from many receivers at the same time -- a typical scaling problem. RTCP prevents this by allowing only a constant, shared bitrate for all feedback messages, regardless of the size of the multicast group, thus adding latency on the feedback channel. The current MPEG-4 packetization draft supports a scheme called NEWPRED that is not efficient when there is a lot of latency, and, therefore, limits the size of the multicast group to a single receiver for those messages. That draft also discusses a scaling problem on the forward channel, which, I believe, does not exist. The number of negative feedback messages obviously depends on the size of the multicast group. I dare to say that it is proportional to that size, or anything like this. But I think that it is reasonable to expect more negative feedback when the multicast group is big then in case of point-to-point. Any form of loss leads, when using predictive video coding, to the need to regain synchronicity between the encoder's loop and the decoders reference pictures. Regardless of the employed mechanism (intra pictures, intra macroblocks, newpred, whatever) this takes more bits then optimal predictive coding in a loss less environment. Hence, the larger the multicast group is, the more bits must be spent to keep the encoder's loop and the decoders synchronized. But is this a scaling problem? I believe not. The encoder has the full control over its sending bitrate. Upon receiving of negative feedback messages, it MAY respond by using additional bits for intra information or newpred. It MAY also decide to continue as if nothing happened (thus accepting that some, or all, receivers suffer >from artifacts introduced due to the asynchronicity of the encoder and decoders). It MAY decide to spend bits to regain synchronicity, but use a different quantization factor or skip frames in order to keep the sending bitrate constant. Well designed encoders MAY do all the above, choosing adaptively based on the number and importance of the receivers that reported problems. Since the encoder has full control over its sending bitrate, there is no scaling problem, at least none associated with the use of feedback. Am I missing something? Please let me know. Thanks. Stephan From rem-conf Mon Jun 26 05:13:15 2000 From rem-conf-request@es.net Mon Jun 26 05:13:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136Xh0-0004sC-00; Mon, 26 Jun 2000 05:08:46 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 136Xgy-0004rj-00; Mon, 26 Jun 2000 05:08:45 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-209.dialup.cs.tu-berlin.de [130.149.145.209]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id NAA02818; Mon, 26 Jun 2000 13:53:40 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000626131354.02b67260@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Jun 2000 13:23:23 +0200 To: Hideaki Kimata , c.perkins@cs.ucl.ac.uk, fukunaga444@oki.co.jp, rhee@unity.ncsu.edu, kiku@eel.rdc.toshiba.co.jp, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net From: Stephan Wenger Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: <200006261038.TAA19503@nttvdt.hil.ntt.co.jp> References: <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> <200006230139.CAA03225@purple.east.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, > As I pointed out in previous Email, NEWPRED is one tool of ARTS profile > in MPEG-4. And NEWPRED RTCP messages are only transmitted between > ARTS profile terminals. > This means the usage of these messages is not definitly generic, and > setup procedure should be also different from other backward channel > messages. I mean the setup should be after receiving profile and level > indication of MPEG-4. > I believe this fact makes objection for NEWPRED RTCP meaningless. No. I believe not. Sorry. The definition of exactly one (of many possible and known) feedback mechanisms is the very point of my objection. This is regardless of whether that mechanism is specific to MPEG-4 (which it is not, as H.263 has NEWPRED, too), or to a specific MPEG-4 profile. I started working on a general video feedback draft, which covers both conventional feedback messages such as FIR, and special, low delay, point-to-point feedback for things such as NEWPRED. A rough draft should show up on rem-conf within a week. Stephan From rem-conf Mon Jun 26 22:19:48 2000 From rem-conf-request@es.net Mon Jun 26 22:19:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136nZy-0003u4-00; Mon, 26 Jun 2000 22:06:34 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 136nZm-0003tp-00; Mon, 26 Jun 2000 22:06:24 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id OAA05221; Tue, 27 Jun 2000 14:06:09 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id OAA04512; Tue, 27 Jun 2000 14:06:08 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id OAA21298; Tue, 27 Jun 2000 14:06:08 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id OAA43470; Tue, 27 Jun 2000 14:06:08 +0900 (JST) Message-ID: <045e01bfdff5$611f8360$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" Cc: "Yoshihiro Kikuchi" Subject: MPEG-4 A/V RTP new I/D Date: Tue, 27 Jun 2000 14:05:51 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_045B_01BFE040.CD213EA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_045B_01BFE040.CD213EA0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear all MPEG-4 on IP experts, Please find attached a draft of the new version of MPEG-4 ES RTP payload format Internet-Draft. The following is the list of changes from the previous version. (not the draft version I sent at July 20, but '-01' version) (1) Removal of NEWPRED RTCP related descriptions. After a careful discussion among the authors taking all comments through the reflector into account, we decided not to include any backchannel related description, which has not get consensus from the group, on the Internet-Draft. (2) Minor revision on MPEG-4 Audio RTP and its MIME type. Text proposed by Nomura-san and has been agreed upon through the reflector was reflected. (3) Upgrade of English quality. I will submit the attached text at the middle of this week. Please let us know by then if you have any comment on this. Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 ------=_NextPart_000_045B_01BFE040.CD213EA0 Content-Type: text/plain; name="draft-ietf-avt-rtp-mpeg4-es-02-draft7.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mpeg4-es-02-draft7.txt" Internet Engineering Task Force Yoshihiro Kikuchi - = Toshiba Internet Draft Toshiyuki Nomura - = NEC Document: draft-ietf-avt-rtp-mpeg4-es-02.txt Shigeru Fukunaga - = Oki Yoshinori Matsui - = Matsushita Hideaki Kimata - = NTT June 27, = 2000 RTP payload format for MPEG-4 Audio/Visual streams Status of this Memo This document is an Internet-Draft and is in full conformance with = all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering = Task Force (IETF), its areas, and its working groups. Note that other = groups may also distribute working documents as Internet-Drafts. = Internet-Drafts are draft documents valid for a maximum of six months and may be = updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to = cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes RTP payload formats for carrying of MPEG-4 = Audio and Visual bitstreams[2][3]. For the purpose of directly mapping = MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications = for the use of RTP header fields and also specifies fragmentation rules. = It also provides specifications for MIME type registrations and the use = of SDP. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 1] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 1. Introduction The RTP payload formats described in this Internet-Draft specify a = way of how MPEG-4 Audio and Visual streams are to be fragmented and mapped directly onto RTP packets. These RTP payload formats enable to carry MPEG-4 Audio/Visual streams without using the synchronization and stream management functionality = of MPEG-4 Systems [6]. Such RTP payload format would be used within = systems where their own stream management functionality is provided and thus = such functionality in MPEG-4 Systems is not necessary. H.323 terminals are = an example of such systems. MPEG-4 Audio/Visual streams are not managed = by MPEG-4 Systems Object Descriptors but by H.245. The streams are = directly mapped onto RTP packets without using the synchronization = functionality of MPEG-4 Systems. The semantics of RTP headers in such cases need to be clearly = defined, including the association with MPEG-4 Audio/Visual data elements. In addition, it would be beneficial to define the fragmentation rules of = RTP packets for MPEG-4 Video streams so as to enhance error resiliency by utilizing the error resilience tools provided inside the MPEG-4 Video stream. These issues, however, have yet to be addressed by other RTP payload format specifications. 1.1 MPEG-4 Visual RTP payload format MPEG-4 Visual is a visual coding standard with many new features: = high coding efficiency; high error resiliency; multiple, arbitrary shape object-based coding; etc. [2]. It covers a wide range of bitrate from scores of Kbps to several Mbps. It also covers a wide variety of networks, ranging from those guaranteed to be almost error-free to = mobile networks with high error rates. With respect to the fragmentation rules for an MPEG-4 visual = bitstream defined in this document, since MPEG-4 Visual is used for a wide = variety of networks, it is desirable not to apply too much restriction on fragmentation, and a fragmentation rule such as "a single video = packet shall always be mapped on a single RTP packet" may be inappropriate. = On the other hand, careless, media unaware fragmentation may cause degradation in error resiliency and bandwidth efficiency. The fragmentation rules described in this document are flexible but = manage to define the minimum rules for preventing meaningless fragmentation and = for utilizing the error resilience of MPEG-4 visual. While the additional media specific RTP header defined for such video coding tools as H.261 or MPEG-1/2 is effective in helping to recover picture headers corrupted by packet losses, in MPEG-4 Visual there = are already error resilience functionalities for recovering corrupt = headers, and these can be used on RTP/IP networks, as well as on other = networks. (H.223/mobile, MPEG-2/TS, etc.) That is why no extra RTP header = fields are defined in the MPEG-4 Visual RTP payload format proposed here. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 2] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 1.2 MPEG-4 Audio RTP payload format MPEG-4 Audio is a new kind of audio standard that integrates many different types of audio coding tools. It also supports a mechanism = for representing synthesized sounds. Low-overhead MPEG-4 Audio Transport Multiplex (LATM) manages the sequences of audio data with relatively small overhead. In audio-only applications, then, it is desirable for LATM-based MPEG-4 Audio bitstreams to be directly mapped onto the RTP packets without using MPEG-4 Systems. For MPEG-4 Audio coding tools except synthesis tools, as is true for other audio coders, if the payload of a packet is a single audio = frame, packet loss will not impair the decodability of adjacent packets. On = the other hands, MPEG-4 Audio synthesis tools may be sensitive to error. = For example, an SA_access_unit in the payload may set a global value to a = new value, which is then references throughout the audio content to make = a macro change in the performance. In this case, an error in the = payload influences all audio data produced after the error. In order to = enhance error resiliency, the element of SA_access_unit that makes the above macro change should be transmitted across several SA_access_unit repeatedly. The number of repetition will be dependent on the network condition. Therefore, the additional media specific header for = recovering errors will not be required for MPEG-4 Audio. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [7]. 3. RTP Packetization of MPEG-4 Visual bitstream This section specifies RTP packetization rules for MPEG-4 Visual = content. An MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode is used so that configuration information will be carried to the same = RTP port as the elementary stream. (see 6.2.1 "Start codes" of ISO/IEC = 14496- 2 [2][9][4]) When the short video header mode is used, the RTP payload format used = MAY be that specified for H.263 in the relevant RFCs or in other relevant standards. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 3] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 4] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | = RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | = Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | | RTP | MPEG-4 Visual stream (byte aligned) | = Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - An RTP packet for MPEG-4 Visual stream 3.1 Use of RTP header fields for MPEG-4 Visual Payload Type (PT): Payload type is to be specifically assigned as the MPEG-4 Visual RTP payload format. If this assignment is to be carried = out dynamically, it can be performed by such out-of-band means as H.245, = SDP, etc. Extension (X) bit: Defined by the RTP profile used. Sequence Number: Incremented by one for each RTP data packet sent, starting, for security reasons, with a random initial value. Marker (M) bit: The marker bit is set to one to indicate the last RTP packet (or only RTP packet) of a VOP. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. A constant offset, = which is random, is added for security reasons. For a video object plane, it = is defined as vop_time_increment (in units of 1/vop_time_increment_resolution seconds) plus the cumulative number = of whole seconds specified by module_time_base and, if present, = time_code of Group_of_VideoObjectPlane() fields. In the case of interlaced video, = a VOP will consist of lines from two fields, and the timestamp will indicate the composition time of the first field. If the RTP packet Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 5] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D contains only configuration information and/or Group_of_VideoObjectPlane() fields, the composition time of the next = VOP in the coding order is used. If the RTP packet contains only visual_object_sequence_end_code information, the composition time of = the immediately preceding VOP in the coding order is used. The resolution of the timestamp is set to its default value of 90KHz, unless specified by an out-of-band means (e.g. SDP parameter or MIME parameter as defined in section 5). SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 3.2 Fragmentation of MPEG-4 Visual bitstream A fragmented MPEG-4 Visual bitstream is mapped directly onto the RTP payload without any addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary streams mode is used. The following rules apply for the fragmentation. (1) Configuration information and Group_of_VideoObjectPlane() fields SHALL be placed at the beginning of the RTP payload (just after the = RTP header) or just after the header of the syntactically upper layer function. (2) If one or more headers exist in the RTP payload, the RTP payload SHALL begin with the header of the syntactically highest function. Note: The visual_object_sequence_end_code is regarded as the lowest function. (3) A header SHALL NOT be split into a plurality of RTP packets. (4) Two or more VOPs SHALL be fragmented into different RTP packets = so that one RTP packet consists of the data bytes associated with a = unique presentation time (that is indicated in the timestamp field in the = RTP packet header). (5) A single video packet SHOULD NOT be split into a plurality of RTP packets. The size of a video packet SHOULD be adjusted in such a way = that the resulting RTP packet is not larger than the path-MTU. A video = packet MAY be split into a plurality of RTP packets when the size of the = video packet is large. Here, header means: - Configuration information (Visual Object Sequence Header, Visual = Object Header and Video Object Layer Header) - visual_object_sequence_end_code - The header of the entry point function for an elementary stream (Group_of_VideoObjectPlane() or the header of VideoObjectPlane(), video_plane_with_short_header(), MeshObject() or FaceObject()) Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 6] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D - The video packet header (video_packet_header() excluding next_resync_marker()) - The header of gob_layer() See 6.2.1 "Start codes" of ISO/IEC 14496-2[2][9][4] for the = definition of the configuration information and the entry point functions. The video packet starts with the VOP header or the video packet = header, followed by motion_shape_texture(), and ends with = next_resync_marker() or next_start_code(). 3.3 Examples of packetized MPEG-4 Visual bitstream Considering the fact that MPEG-4 Visual covers a wide variety of = networks ranging from scores of Kbps to several Mbps, and from those = guaranteed to be almost error-free to mobile networks with high error rates, it is desirable not to apply too much restriction on fragmentation. On the other hand, careless, media unaware fragmentation will cause = degradation in error resiliency and bandwidth efficiency. The fragmentation = criteria described in 3.2 are flexible but to define the minimum rules to = prevent meaningless fragmentation. Figure 2 shows examples of RTP packets generated based on the = criteria described in 3.2 (a) is an example of the first RTP packet or the random access point = of an MPEG-4 visual bitstream containing the configuration information. According to criterion (1), the Visual Object Sequence Header(VS = header) is placed at the beginning of the RTP payload, preceding the Visual Object Header and the Video Object Layer Header(VO header, VOL = header). Since the fragmentation rule defined in 3.2 guarantees that the configuration information, starting with visual_object_sequence_start_code, is always placed at the beginning = of the RTP payload, RTP receivers can detect the random access point by checking if the first 32-bit field of the RTP payload is visual_object_sequence_start_code. (b) is another example of the RTP packet containing the configuration information. It differs from example (a) in that the RTP packet also contains a video packet in the VOP following the configuration information. Since the length of the configuration information is relatively short (typically scores of bytes) and an RTP packet = containing only the configuration information may thus increase the overhead, = the configuration information and the immediately following GOV and/or (a part of) VOP can be effectively packetized into a single RTP packet = as in this example. (c) is an example of the RTP packet that contains Group_of_VideoObjectPlane(GOV). Following criterion (1), the GOV is placed at the beginning of the RTP payload. It would be a waste of = RTP/IP Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 7] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D header overhead to generate an RTP packet containing only a GOV whose length is 7 bytes. Therefore, (a part of) the following VOP can be = placed in the same RTP packet as shown in (c). (d) is an example of the case where one video packet is packetized = into one RTP packet. When the packet-loss rate of the underlying network = is high, this kind of packetization is recommended. It is recommended to = set resync_marker_disable to 0 in the VOL header to enable the adjustment = of the video packet size. Even when the RTP packet containing the VOP = header is discarded by a packet loss, the other RTP packets can be decoded = by using the HEC(Header Extension Code) information in the video packet header. No extra RTP header field is necessary. (e) is an example of the case where more than one video packets are packetized into one RTP packet. This kind of packetization is = effective to save the overhead of RTP/IP headers when the bit-rate of the underlying network is low. However, it will decrease the packet-loss resiliency because multiple video packets are discarded by a single = RTP packet loss. The optimal number of video packets in an RTP packet and = the length of the RTP packet can be determined considering the = packet-loss rate and the bit-rate of the underlying network. Figure 4 shows examples of RTP packets prohibited by the criteria of = 3.2. Fragmentation of a header into multiple RTP packets, as in (a), will = not only increase the overhead of RTP/IP headers but also decrease the = error resiliency. Therefore, it is prohibited by the criterion (3). When concatenating more than one video packets into an RTP packet, = VOP header or video_packet_header() shall not be placed in the middle of = the RTP payload. The packetization as in (b) is not allowed by criterion = (2) due to the aspect of the error resiliency. Comparing this example = with Figure 2(d), although two video packets are mapped onto two RTP = packets in both cases, the packet-loss resiliency is not identical. Namely, = if the second RTP packet is lost, both video packets 1 and 2 are lost in = the case of Figure 4(b) whereas only video packet 2 is lost in the case = of Figure 2(d). An RTP packet containing more than one VOPs, as in (c), is not = allowed. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 8] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D +------+------+------+------+ (a) | RTP | VS | VO | VOL | |header|header|header|header| +------+------+------+------+ +------+------+------+------+------------+ (b) | RTP | VS | VO | VOL |Video Packet| |header|header|header|header| | +------+------+------+------+------------+ +------+-----+------------------+ (c) | RTP | GOV |Video Object Plane| |header| | | +------+-----+------------------+ +------+------+------------+ +------+------+------------+ (d) | RTP | VOP |Video Packet| | RTP | VP |Video Packet| |header|header| (1) | |header|header| (2) | +------+------+------------+ +------+------+------------+ = +------+------+------------+------+------------+------+------------+ (e) | RTP | VP |Video Packet| VP |Video Packet| VP |Video = Packet| |header|header| (1) |header| (2) |header| (3) = | = +------+------+------------+------+------------+------+------------+ Figure 2 - Examples of RTP packetized MPEG-4 Visual bitstream +------+-------------+ +------+------------+------------+ (a) | RTP |First half of| | RTP |Last half of|Video Packet| |header| VP header | |header| VP header | | +------+-------------+ +------+------------+------------+ +------+------+----------+ = +------+---------+------+------------+ (b) | RTP | VOP |First half| | RTP |Last half| VP |Video = Packet| |header|header| of VP(1) | |header| of VP(1)|header| (2) = | +------+------+----------+ = +------+---------+------+------------+ +------+------+------------------+------+------------------+ (c) | RTP | VOP |Video Object Plane| VOP |Video Object Plane| |header|header| (1) |header| (2) | +------+------+------------------+------+------------------+ Figure 4 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 9] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 4. RTP Packetization of MPEG-4 Audio bitstream This section specifies RTP packetization rules for MPEG-4 Audio bitstreams. MPEG-4 Audio streams are formatted by LATM (Low-overhead MPEG-4 Audio Transport Multiplex) tool[5], and the LATM-based streams = are then mapped onto RTP packets as described the three sections below. 4.1 RTP Packet Format LATM-based streams consist of a sequence of audioMuxElements that = include one or more audio frames. A complete audioMuxElement or a part of one SHALL be mapped directly onto an RTP payload without any removal of audioMuxElement syntax elements (see Figure 6). The first byte of = each audioMuxElement SHALL be located at the first payload location in an = RTP packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number = |RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp = |Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | contributing source (CSRC) identifiers | | .... | = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | |RTP : audioMuxElement (byte aligned) = :Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 - An RTP packet for MPEG-4 Audio In order to decode the audioMuxElement, the following = muxConfigPresent information is required to be indicated by an out-of-band means. muxConfigPresent: If this value is set to 1, the audioMuxElement = SHALL include an indication bit "useSameStreamMux" and MAY include the configuration information for audio compression "StreamMuxConfig". = The useSameStreamMux bit indicates whether the StreamMuxConfig element in = the previous frame is applied in the current frame. 4.2 Use of RTP Header Fields for MPEG-4 Audio Payload Type (PT): Payload type is to be specifically assigned as the MPEG-4 Audio RTP payload format. If this assignment is to be carried = out dynamically, it can be performed by such out-of-band means as H.245, = SDP, etc. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 10] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Marker (M) bit: The marker bit indicates audioMuxElement boundaries. = It is set to one to indicate that the RTP packet contains a complete audioMuxElement or the last fragment of an audioMuxElement. Timestamp: The timestamp indicates composition time, or presentation = time in a no-compositor decoder. Timestamps are recommended to start at a random value for security reasons. Unless specified by an out-of-band means, the resolution of the = timestamp is set to its default value of 90 kHz. Sequence Number: Incremented by one for each RTP packet sent, = starting, for security reasons, with a random value. SSRC, CC and CSRC fields are used as described in RFC 1889 [8]. 4.3 Fragmentation of MPEG-4 Audio bitstream It is desirable to put one audioMuxElement in each RTP packet. If the size of an audioMuxElement can be kept small enough that the size of = the RTP packet containing it does not exceed the size of the path-MTU, = this will be no problem. If it cannot, the audioMuxElement MAY be = fragmented and spread across multiple packets, following the rules below: (1) "payloadMux", which consists of payload elements, MAY be = fragmented across several RTP packets, so that each of those RTP packets will contain one or more payload elements. Individual payload elements themselves SHOULD NOT be fragmented. (2) If the audioMuxElement includes StreamMuxConfig, StreamMuxConfig SHALL be included in the RTP packet that contains the first payload element. 5. MIME type registration for MPEG-4 Audio/Visual streams The following sections describe the MIME type registrations for = MPEG-4 Audio/Visual streams. MIME type registration and SDP usage for the = MPEG-4 Visual stream are described in Sections 5.1 and 5.2, respectively, = while MIME type registration and SDP usage for MPEG-4 Audio stream are described in Sections 5.3 and 5.4, respectively. (In the following sections, the RFC number "XXXX" represents the RFC number, which should be assigned for this Internet Draft.) 5.1 MIME type registration for MPEG-4 Visual MIME media type name: video Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 11] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D MIME subtype name: MP4V Required parameters: none Optional parameters: rate: This parameter is used only for RTP transport. It indicates = the resolution of the timestamp field in the RTP header. If this = parameter is not specified, its default value of 90000 (90KHz) is used. profile-level-id: A decimal representation of MPEG-4 Visual Profile Level indication value (profile_and_level_indication) defined in = Table G-1 of ISO/IEC 14496-2 [2][4]. Example usages for these parameters are: - MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v; profile-level-id=3D34 - MPEG-4 Visual Advanced Real Time Simple Profile/Level 1: Content-type: video/mp4v; profile-level-id=3D145 Published specification: The specifications for MPEG-4 Visual streams are presented in = ISO/IEC 14469-2[2][4][9]. The RTP payload format is described in RFCXXXX. Encoding considerations: Video bitstreams must be generated according to MPEG-4 Visual specifications (ISO/IEC 14496-2). A video bitstream is binary data = and must be encoded for non-binary transport (for Email, the Base64 encoding is sufficient). This type is also defined for transfer = via RTP. The RTP packets must be packetized according to the MPEG-4 = Visual RTP payload format defined in RFCXXXX. Security considerations: See section 6 of RFCXXXX. Interoperability considerations: MPEG-4 Visual provides a large and rich set of tools for the coding = of visual objects. For effective implementation of the standard, = subsets of the MPEG-4 Visual tool sets have been provided for use in = specific applications. These subsets, called 'Profiles', limit the size of = the tool set a decoder is required to implement. In order to restrict computational complexity, one or more Levels are set for each = Profiles. A Profile@Level combination allows: o a codec builder to implement only the subset of the standard he needs, while maintaining interworking with other MPEG-4 devices included in the same combination, and Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 12] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D o checking whether MPEG-4 devices comply with the standard ('conformance testing'). The visual stream SHALL be compliant with the MPEG-4 Visual Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this = parameter mutually to the same value. Applications which use this media type: Audio and visual streaming and conferencing tools, Internet = messaging and Email applications. Additional information: none Person & email address to contact for further information: The authors of RFCXXXX. (See section 8) Intended usage: COMMON Author/Change controller: The authors of RFCXXXX. (See section 8) 5.2 SDP usage of MPEG-4 Visual The MIME media type video/MP4V string is mapped to fields in the = Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (video) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4V) goes in SDP "a=3Drtpmap" as the encoding = name. o The optional parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "profile-level-id" MAY go in the "a=3Dfmtp" = line. The following are some examples of media representation in SDP: Simple Profile/Level 1, rate=3D90000(90KHz), "profile-level-id" is = present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V/90000 a=3Dfmtp:98 profile-level-id=3D1 Advance Real Time Simple Profile/Level 1, rate=3D25(25Hz), = "profile-level- id" is present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V/25 a=3Dfmtp:98 profile-level-id=3D145 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 13] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 5.3 MIME type registration of MPEG-4 Audio MIME media type name: audio MIME subtype name: MP4A Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. = The default value is 90000. Other rates CAN be specified only if they = are set to the same value as the audio sampling rate (number of samples per second). Optional parameters: profile-level-id: a decimal representation of MPEG-4 Audio Profile Level indication value defined in ISO/IEC 14496-1 [11]. This = parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. object: a decimal representation of the MPEG-4 Audio Object Type = value defined in ISO/IEC 14496-3 [5]. This parameter specifies the tool = to be used by the coder. It CAN be used to limit the capability within the specified "profile-level-id". bitrate: the data rate for the audio bit stream. cpresent: this parameter indicates whether audio payload = configuration data has been multiplexed into an RTP payload (See section 4.1 in = this document). config: a hexadecimal representation of an octet string that = expresses the audio payload configuration data "StreamMuxConfig", as defined = in ISO/IEC 14496-3 [5]. Configuration data is mapped onto the octet string in an MSB-first basis. The first bit of the configuration = data SHALL be located at the MSB of the first octet. In the last octet, zero-padding bits, if necessary, shall follow the configuration = data. If the size of the configuration data is quite large, such large config data is RECOMMENDED to be indicated by in-band mode = (cpresent is set to 1). ptime: RECOMMENDED duration of each packet in milliseconds. Published specification: Payload format specifications are described in this document. = Encoding specifications are provided in ISO/IEC 14496-3 [3][5]. Encoding considerations: This type is only defined for transfer via RTP. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 14] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Security considerations: See Section 6 of RFCXXXX. Interoperability considerations: MPEG-4 Audio provides a large and rich set of tools for the coding = of audio objects. For effective implementation of the standard, = subsets of the MPEG-4 Audio tool sets similar to those used in MPEG-4 Visual = have been provided (see section 5.1). The audio stream SHALL be compliant with the MPEG-4 Audio Profile@Level specified by the parameter "profile-level-id". Interoperability between a sender and a receiver may be achieved by specifying the parameter "profile-level-id" in MIME content, or by arranging in the capability exchange procedure to set this = parameter mutually to the same value. Furthermore, the "object" parameter can = be used to limit the capability within the specified Profile@Level in capability exchange. Applications which use this media type: Audio and video streaming and conferencing tools. Additional information: none Personal & email address to contact for further information: See Section 8 of RFCXXXX. Intended usage: COMMON Author/Change controller: See Section 8 of RFCXXXX. 5.4 SDP usage of MPEG-4 Audio The MIME media type audio/MP4A string is mapped to fields in the = Session Description Protocol (SDP), RFC 2327, as follows: o The MIME type (audio) goes in SDP "m=3D" as the media name. o The MIME subtype (MP4A) goes in SDP "a=3Drtpmap" as the encoding = name. o The required parameter "rate" goes in "a=3Drtpmap" as the clock = rate. o The optional parameter "ptime" goes in SDP "a=3Dptime" attribute. o The optional parameter "profile-level-id" goes in the "a=3Dfmtp" = line to indicate the coder capability. The "object" parameter goes in the "a=3Dfmtp" attribute. The payload-format-specific parameters = "bitrate", "cpresent" and "config" go in the "a=3Dfmtp" line. If the string = after "config=3D" is quite large, such large config data should not be Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 15] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D transmitted by SDP but should be transmitted by in-band mode. These parameters are expressed as a MIME media type string, in the form of = as a semicolon separated list of parameter=3Dvalue pairs. The following are some examples of the media representation in SDP: For 6 kb/s CELP bitstreams (with an audio sampling rate of 8 kHz), m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/8000 a=3Dfmtp:96 = profile-level-id=3D9;object=3D8;cpresent=3D0;config=3D9128B1071070 a=3Dptime:20 For 64 kb/s AAC LC stereo bitstreams (with an audio sampling rate of = 24 kHz), m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/24000 a=3Dfmtp:96 profile-level-id=3D1; bitrate=3D64000; cpresent=3D0; config=3D9122620000 In the above two examples, audio configuration data is not = multiplexed into the RTP payload and is described only in SDP. Furthermore, the "clock rate" is set to the audio sampling rate. If the clock rate has been set to its default value and it is = necessary to obtain the audio sampling rate, this can be done by parsing the "config" parameter (see the following example). m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/90000 a=3Dfmtp:96 object=3D8; cpresent=3D0; config=3D9128B1071070 The following example shows that the audio configuration data appears = in the RTP payload. m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A/90000 a=3Dfmtp:96 object=3D13; cpresent=3D1 6. Security Considerations RTP packets using the payload format defined in this specification = are subject to the security considerations discussed in the RTP = specification [8]. This implies that confidentiality of the media streams is = achieved by encryption. Because the data compression used with this payload = format is applied end-to-end, encryption may be performed on the compressed = data so there is no conflict between the two operations. This payload type does not exhibit any significant non-uniformity in = the receiver side computational complexity for packet processing to = cause a potential denial-of-service threat. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 16] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D 7. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP = 9, RFC 2026, October 1996. 2 ISO/IEC 14496-2:1999, "Information technology - Coding of = audio-visual objects - Part2: Visual", December 1999. 3 ISO/IEC 14496-3:1999, "Information technology - Coding of = audio-visual objects - Part3: Audio", December 1999. 4 ISO/IEC 14496-2:1999/FDAM1:2000, December 1999. 5 ISO/IEC 14496-3:1999/FDAM1:2000, December 1999. 6 ISO/IEC 14496-1:1999, "Information technology - Coding of = audio-visual objects - Part1: Systems", December 1999. 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8 H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson "RTP: A = Transport Protocol for Real Time Applications", RFC 1889, Internet = Engineering Task Force, January 1996. 9 ISO/IEC 14496-2/COR1, "Information technology - Coding of = audio-visual objects - Part2: Visual, Technical corrigendum 1", March 2000. 8. Author's Addresses Yoshihiro Kikuchi Toshiba corporation 1, Komukai Toshiba-cho, Saiwai-ku, Kawasaki, 212-8582, Japan Email: yoshihiro.kikuchi@toshiba.co.jp Yoshinori Matsui Matsushita Electric Industrial Co., LTD. 1006, Kadoma, Kadoma-shi, Osaka, Japan Email: matsui@drl.mei.co.jp Toshiyuki Nomura NEC Corporation 4-1-1,Miyazaki,Miyamae-ku,Kawasaki,JAPAN Email: t-nomura@ccm.cl.nec.co.jp Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 17] =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan. Email: fukunaga444@oki.co.jp Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa, Japan Email: kimata@nttvdt.hil.ntt.co.jp =0CRTP payload format for MPEG-4 Audio/Visual streams February = 2000=0D Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. =0C ------=_NextPart_000_045B_01BFE040.CD213EA0-- From rem-conf Tue Jun 27 02:37:32 2000 From rem-conf-request@es.net Tue Jun 27 02:37:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136reJ-0007LE-00; Tue, 27 Jun 2000 02:27:19 -0700 Received: from eau.irisa.fr [131.254.60.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 136reH-0007L2-00; Tue, 27 Jun 2000 02:27:17 -0700 Received: from irisa.fr (borneo.irisa.fr [131.254.41.54]) by eau.irisa.fr (8.9.3/8.9.3) with ESMTP id LAA08818; Tue, 27 Jun 2000 11:26:12 +0200 (MET DST) Message-ID: <39587333.9BA8E2F@irisa.fr> Date: Tue, 27 Jun 2000 11:26:11 +0200 From: Christine Guillemot X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: Stephan Wenger , rhee@unity.ncsu.edu CC: Hideaki Kimata , c.perkins@cs.ucl.ac.uk, fukunaga444@oki.co.jp, kiku@eel.rdc.toshiba.co.jp, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format References: <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000626131354.02b67260@mail.cs.tu-berlin.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eau.irisa.fr id LAA08818 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, Sorry for the very late reaction to the exchange of mails, due to traveling over the last two weeks. I would like first to say that I support the idea of removing the section on NEWPRED RTCP as announced by Kikuchi, sharing completely the concerns of Stephan and Injong on the related issues. I would like to add the following questions/comments: 1- I understood from earlier e-mail/MPEG4-IETF phone meeting discussions that to be MPEG-4 compliant, terminals would have to support the sync layer, because the ESI is not normative. Therefore, what would be the status of the current draft with respect to MPEG-4 compliance issues, since it says: "These RTP payload formats enable to carry MPEG-4 Audio/Visual streams without using the synchronization and stream management functionality of MPEG-4 Systems [6]. Such RTP payload format would be used within systems where their own stream management functionality is provided and thus such functionality in MPEG-4 Systems is not necessary. H.323 terminals are an example of such systems. MPEG-4 Audio/Visual streams are not managed by MPEG-4 Systems Object Descriptors but by H.245. The streams are directly mapped onto RTP packets without using the synchronization functionality of MPEG-4 Systems." 2- It seems to me that some of the fragmentation rules do not apply to scalable streams (or at least to enhancement layers of scalable streams), e.g. below: ---- (5) A single video packet SHOULD NOT be split into a plurality of RTP packets. The size of a video packet SHOULD be adjusted in such a way t= hat the resulting RTP packet is not larger than the path-MTU. A video pack= et MAY be split into a plurality of RTP packets when the size of the vide= o packet is large. ---- since - unless recent changes - enhancement layers do not support the notion of video packets. If this is the case, how the scalable profiles can be really used in a loss-prone environment?. 3- Overall, the draft seems to target extremely specific applications - relying on real-time encoders -. I would like to have some indications on how it can be used for streaming applications. Indeed, considering the video part, protection of headers rely on the usage of the HEC field. A network adaptive usage of this field would require the implementation of a video stream parser (i.e. a part of a decoder), in order to incorporate inside the video packets the important data that needs to be protected. Is it really what we want? Best regards, Christine Stephan Wenger a =E9crit: > Hi all, > > > As I pointed out in previous Email, NEWPRED is one tool of ARTS prof= ile > > in MPEG-4. And NEWPRED RTCP messages are only transmitted between > > ARTS profile terminals. > > > This means the usage of these messages is not definitly generic, and > > setup procedure should be also different from other backward channel > > messages. I mean the setup should be after receiving profile and lev= el > > indication of MPEG-4. > > > I believe this fact makes objection for NEWPRED RTCP meaningless. > > No. I believe not. Sorry. > > The definition of exactly one (of many possible and known) feedback > mechanisms is the very point of my objection. This is regardless of > whether that mechanism is specific to MPEG-4 (which it is not, as > H.263 has NEWPRED, too), or to a specific MPEG-4 profile. > > I started working on a general video feedback draft, which covers both > conventional feedback messages such as FIR, and special, low delay, > point-to-point feedback for things such as NEWPRED. A rough draft > should show up on rem-conf within a week. > > Stephan From rem-conf Tue Jun 27 03:52:54 2000 From rem-conf-request@es.net Tue Jun 27 03:52:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136sqD-0003O0-00; Tue, 27 Jun 2000 03:43:41 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 136sqC-0003Nq-00; Tue, 27 Jun 2000 03:43:40 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06219; Tue, 27 Jun 2000 06:43:38 -0400 (EDT) Message-Id: <200006271043.GAA06219@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-dv-audio-02.txt Date: Tue, 27 Jun 2000 06:43:38 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for 12-bit DAT, 20- and 24 bit Linear Sampled Audio Author(s) : K. Kobayashi, A. Ogawa, S. Casner, C. Bormann Filename : draft-ietf-avt-dv-audio-02.txt Pages : 12 Date : 26-Jun-00 This document specifies the packetization scheme for encapsulating the 12-bit nonlinear, 20-bit linear and 24-bit linear audio data streams into a payload of the Real-time Transport Protocol (RTP). This draft also specifies the way of SDP announcement, when the audio data is preemphasized before sampling. The treatment of preemphasized audio data specified this document could be used in other audio formats such as L16. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-audio-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-dv-audio-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-dv-audio-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000626112249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dv-audio-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dv-audio-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000626112249.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jun 27 03:52:54 2000 From rem-conf-request@es.net Tue Jun 27 03:52:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 136sqI-0003OE-00; Tue, 27 Jun 2000 03:43:46 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 136sqH-0003O2-00; Tue, 27 Jun 2000 03:43:45 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06233; Tue, 27 Jun 2000 06:43:44 -0400 (EDT) Message-Id: <200006271043.GAA06233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-dv-video-03.txt Date: Tue, 27 Jun 2000 06:43:44 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for DV Format Video Author(s) : K. Kobayashi, A. Ogawa, S. Casner, C. Bormann Filename : draft-ietf-avt-dv-video-03.txt Pages : 12 Date : 26-Jun-00 This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as 'DV' into a payload format for the Real-Time Transport Protocol (RTP). There are two kinds of DV, one for consumer use and the other for professional. The original 'DV' specification designed for consumer- use digital VCRs is approved as the IEC 61834 standard set. The specifications for professional DV are published as SMPTE 306M(D-7) and 314M(D-9). Both are based on consumer DV. The RTP payload format specified in this document supports IEC 61834 consumer DV and professional SMPTE 306M and 314M(DV-Based) formats. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-dv-video-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-dv-video-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-dv-video-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000626112307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-dv-video-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-dv-video-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000626112307.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jun 27 14:47:03 2000 From rem-conf-request@es.net Tue Jun 27 14:46:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13732C-0002eW-00; Tue, 27 Jun 2000 14:36:44 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13732A-0002eM-00; Tue, 27 Jun 2000 14:36:43 -0700 Received: from guest6.cs.unc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Tue, 27 Jun 2000 22:36:23 +0100 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id WAA13734; Tue, 27 Jun 2000 22:09:03 +0100 Message-Id: <200006272109.WAA13734@purple.east.isi.edu> To: Stephan Wenger cc: rem-conf@es.net Subject: Re: Network flooding when using feedback In-Reply-To: Message from Stephan Wenger of "Mon, 26 Jun 2000 13:55:25 +0200." <4.3.2.7.2.20000626132326.00ddbd80@mail.cs.tu-berlin.de> Date: Tue, 27 Jun 2000 17:09:03 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Stephan Wenger writes: ... >Any form of loss leads, when using predictive video coding, to >the need to regain synchronicity between the encoder's loop >and the decoders reference pictures. Regardless of the >employed mechanism (intra pictures, intra macroblocks, >newpred, whatever) this takes more bits then optimal >predictive coding in a loss less environment. Hence, >the larger the multicast group is, the more bits must >be spent to keep the encoder's loop and the decoders >synchronized. But is this a scaling problem? > >I believe not. The encoder has the full control over its sending >bitrate. Upon receiving of negative feedback messages, it >MAY respond by using additional bits for intra information >or newpred. It MAY also decide to continue as if nothing >happened (thus accepting that some, or all, receivers suffer >from artifacts introduced due to the asynchronicity of the >encoder and decoders). It MAY decide to spend bits to >regain synchronicity, but use a different quantization factor >or skip frames in order to keep the sending bitrate constant. >Well designed encoders MAY do all the above, choosing >adaptively based on the number and importance of the >receivers that reported problems. > >Since the encoder has full control over its sending bitrate, >there is no scaling problem, at least none associated with >the use of feedback. I wouldn't call this a scaling problem, but there is the obvious potential for a destructive feedback loop if the encoder increases its sending rate (due to the addition of extra error correction information) according to loss feedback from the network. Any scheme which adds error correction information must clearly consider the stability of its control loop, to ensure that this doesn't occur. Colin From rem-conf Tue Jun 27 15:08:06 2000 From rem-conf-request@es.net Tue Jun 27 15:08:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1373Sa-0004fP-00; Tue, 27 Jun 2000 15:04:00 -0700 Received: from diablo.cisco.com [171.68.224.210] by mail1.es.net with esmtp (Exim 1.81 #2) id 1373SY-0004dz-00; Tue, 27 Jun 2000 15:03:58 -0700 Received: from jmpolk-8k (ssh.cisco.com [171.69.10.34]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA22164; Tue, 27 Jun 2000 15:02:49 -0700 (PDT) Message-Id: <4.1.20000627150221.009f5100@diablo.cisco.com> Message-Id: <4.1.20000627150221.009f5100@diablo.cisco.com> X-Sender: jmpolk@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 27 Jun 2000 15:03:23 -0500 To: "Fox, Mike" , Jonathan Rosenberg , IMPP WG From: "James M. Polk" Subject: RE: proposal for IMPP Cc: sip , rem-conf@es.net, "iptel, list" In-Reply-To: <613A6A6A3F09D3118F5C00508B2C24FE7F35E6@sd_exchange.nuera.c om> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1302240==_.ALT" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_1302240==_.ALT Content-Type: text/plain; charset="us-ascii" Mike How long did it take you to think of this acronym? If less than an hour -- you need a life, man! ;-) cheers At 03:18 PM 6/15/2000 -0700, Fox, Mike wrote: >Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol >may be the right way. Call it SIP Control by Unified Methods. > >SOAP SCUM > > >Best regards, >Mike Fox > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_1302240==_.ALT Content-Type: text/html; charset="us-ascii"

Mike

How long did it take you to think of this acronym? If less than an hour -- you need a life, man!

;-)

cheers

At 03:18 PM 6/15/2000 -0700, Fox, Mike wrote:
>Why stop at XML for IMPP? Why not XML for SIP? Simple Object Access Protocol
>may be the right way. Call it SIP Control by Unified Methods.
>
>SOAP SCUM
>
>
>Best regards,
>Mike Fox
>
>
*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_1302240==_.ALT-- From rem-conf Tue Jun 27 20:04:37 2000 From rem-conf-request@es.net Tue Jun 27 20:04:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137834-0001jJ-00; Tue, 27 Jun 2000 19:57:58 -0700 Received: from uni03mr.unity.ncsu.edu [152.1.1.166] by mail1.es.net with esmtp (Exim 1.81 #2) id 137832-0001j9-00; Tue, 27 Jun 2000 19:57:56 -0700 Received: from yiyung (ppp20383.unity.ncsu.edu [152.1.245.73]) by uni03mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with SMTP id WAA26383; Tue, 27 Jun 2000 22:56:03 -0400 (EDT) Reply-To: From: "Injong rhee" To: "Stephan Wenger" , Cc: Subject: RE: Network flooding when using feedback Date: Tue, 27 Jun 2000 23:04:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000626132326.00ddbd80@mail.cs.tu-berlin.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi. Stephan, It is true that use of feedback (per loss or some small collection of losses) *may* create implosion in large multicast groups. However, feedback alone does not cause implosion. Implosion is more to do with *where* feedback is sent to. For instance, if it is sent to one node (i.e., sender) then it obviously causes implosion. However, if feedback reception is distributed (i.e., no centralization of feedback processing), then you *might* be able to avoid implosion. There have been quite a few works in the reliable multicast community on scalability feedback handling. The point is that as long as the use of feedback information in a protocol allows aggregation or distributed processing of feedback, scalability problem due to feedback implosion is not an issue. Retransmission or forward error correction is this kind that allow distributed feedback processing. (Now if one asks how distributed feedback processing can be mapped to the RTP/RTCP framework, I would say that is more of a protocol problem, than of a fundamental problem with the approach. If I am wrong, enlighten me). With respect to NEWPRED, it has inherent limitation in multicast environments. This is not just because there is a feedback channel for each receiver, but also because these channels have to have the sender as an endpoint. Furthermore, since the sender has to attend to each receiver's loss by adjusting reference frames for each receiver, in a large multicast group, there is no way that feedback aggregation is going to help in this situation. Thus, letting alone the feedback implosion problem, the scalability problem exists (in a large multicast group, almost every frame seems to have losses to the sender; so the sender can't find a clean frame to reference). Retransmission or forward error correction does not have this problem though. However, this should not be the reason to preclude NEWPRED from the MPEG-4 RTP profile. I believe that in current Internet, RTP is used more in unicast environments than in multicast environments (partly due to lack of applications and of multicast infrastructures). Although NEWPRED has a problem in a multicast environment, it is useful in unicast scenarios. I think you also share this view (don't you?). In fact, I see a lot of merits in mechanisms which force feedback to be sent immediately rather than waiting for RTCP RR timers to go off as proposed in current draft. My only objection about the currently proposed profile is its strong tie only to NEWPRED. We should work hard to devise (or define) a *generic* RTP feedback format which allows individual profiles to customize it for their own needs. For instance, NACK or ACK are common feedback mechanisms used in many network protocols (especially for retransmission). My two cents, Injong -----Original Message----- From: Stephan Wenger [mailto:stewe@cs.tu-berlin.de] Sent: Monday, June 26, 2000 7:55 AM To: rem-conf@es.net Subject: Network flooding when using feedback Hi all, I'm working on an Internet draft covering feedback messages for predictive video coding schemes. This work is triggered by the MPEG-ES packetization discussion, but, in fact, it should have been done much earlier. One of the main concerns when using feedback channels are network flooding problems in multicast environments. The scaling problem on the feedback channel is well understood. Any irregular behavior on the forward channel, such as a packet loss, may result in feedback messages from many receivers at the same time -- a typical scaling problem. RTCP prevents this by allowing only a constant, shared bitrate for all feedback messages, regardless of the size of the multicast group, thus adding latency on the feedback channel. The current MPEG-4 packetization draft supports a scheme called NEWPRED that is not efficient when there is a lot of latency, and, therefore, limits the size of the multicast group to a single receiver for those messages. That draft also discusses a scaling problem on the forward channel, which, I believe, does not exist. The number of negative feedback messages obviously depends on the size of the multicast group. I dare to say that it is proportional to that size, or anything like this. But I think that it is reasonable to expect more negative feedback when the multicast group is big then in case of point-to-point. Any form of loss leads, when using predictive video coding, to the need to regain synchronicity between the encoder's loop and the decoders reference pictures. Regardless of the employed mechanism (intra pictures, intra macroblocks, newpred, whatever) this takes more bits then optimal predictive coding in a loss less environment. Hence, the larger the multicast group is, the more bits must be spent to keep the encoder's loop and the decoders synchronized. But is this a scaling problem? I believe not. The encoder has the full control over its sending bitrate. Upon receiving of negative feedback messages, it MAY respond by using additional bits for intra information or newpred. It MAY also decide to continue as if nothing happened (thus accepting that some, or all, receivers suffer >from artifacts introduced due to the asynchronicity of the encoder and decoders). It MAY decide to spend bits to regain synchronicity, but use a different quantization factor or skip frames in order to keep the sending bitrate constant. Well designed encoders MAY do all the above, choosing adaptively based on the number and importance of the receivers that reported problems. Since the encoder has full control over its sending bitrate, there is no scaling problem, at least none associated with the use of feedback. Am I missing something? Please let me know. Thanks. Stephan From rem-conf Tue Jun 27 20:05:08 2000 From rem-conf-request@es.net Tue Jun 27 20:05:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13786e-0001y5-00; Tue, 27 Jun 2000 20:01:40 -0700 Received: from mail0.ced.mei.co.jp (vsm.ctmo.mei.co.jp) [202.224.188.243] by mail1.es.net with esmtp (Exim 1.81 #2) id 13786c-0001lo-00; Tue, 27 Jun 2000 20:01:38 -0700 Received: (from root@localhost) by vsm.ctmo.mei.co.jp (8.9.1/8.9.1) id LAA24353; Wed, 28 Jun 2000 11:58:00 +0900 (JST) Received: from kathy.drl.mei.co.jp(132.182.107.40) by vsm.ctmo.mei.co.jp via smap (V2.0) id ; Wed, 28 Jun 00 11:57:53 +0900 Received: by kathy.drl.mei.co.jp (8.9.3/5.2:4.3:drl-FAKEMR:991213) id LAA17745; Wed, 28 Jun 2000 11:53:00 +0900 (JST) Message-ID: <007201bfe0ac$c98cae20$156bb684@lemmon.drl.mei.co.jp> From: "Y. Matsui" To: "Christine Guillemot" , "Stephan Wenger" , Cc: <4on2andIP-sys@advent.ee.columbia.edu>, Subject: RE: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Wed, 28 Jun 2000 11:58:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Christine, I would like to comment on your first question. >1- I understood from earlier e-mail/MPEG4-IETF phone >meeting discussions that to be MPEG-4 compliant, >terminals would have to support the sync layer, because >the ESI is not normative. MPEG-4 system is not mandatory if the underlying transmux provides the functionality such as synchronization, multiplexing, identification, etc., RTP and underlying UDP/IP layer provides them. Another example is ISO/IEC 13818-1 AMD 7, MPEG-4 on MPEG-2 Systems. It has been standardized based on the same concept. This amendment allows to map MPEG-4 AV streams directory into MPEG-2 TS or PS packets in normative way. >Therefore, what would be the status of >the current draft with respect to MPEG-4 compliance >issues, since it says: > >"These RTP payload formats enable to carry MPEG-4 >Audio/Visual streams without using the synchronization >and stream management functionality of MPEG-4 Systems >[6]. Such RTP payload format would be used within systems >where their own stream management functionality is provided >and thus such functionality in MPEG-4 Systems is not necessary. >H.323 terminals are an example of such systems. MPEG-4 >Audio/Visual streams are not managed by >MPEG-4 Systems Object Descriptors but by H.245. The streams >are directly mapped onto RTP packets without using the >synchronization functionality of MPEG-4 Systems." Best regards, Yoshinori Matsui Matsushita / Panasonic From rem-conf Wed Jun 28 02:05:05 2000 From rem-conf-request@es.net Wed Jun 28 02:05:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137DcA-0002aR-00; Wed, 28 Jun 2000 01:54:34 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 137Dc3-0002a4-00; Wed, 28 Jun 2000 01:54:28 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id LAA00146; Wed, 28 Jun 2000 11:49:02 +0300 (IDT) Message-ID: <3959BFBE.AAD7B928@bitband.com> Date: Wed, 28 Jun 2000 11:05:03 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Y. Matsui" CC: Christine Guillemot , Stephan Wenger , rhee@unity.ncsu.edu, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format References: <007201bfe0ac$c98cae20$156bb684@lemmon.drl.mei.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Just a quick (potentially unrelated) question: Are you aware of anyone actually using the apparently normative MPEG-4 transport which maps MPEG-4 ES on top of MPEG-2 TS wich in turn is carried over UDP/IP ? "Y. Matsui" wrote: > Dear Christine, > > I would like to comment on your first question. > > >1- I understood from earlier e-mail/MPEG4-IETF phone > >meeting discussions that to be MPEG-4 compliant, > >terminals would have to support the sync layer, because > >the ESI is not normative. > > MPEG-4 system is not mandatory if the underlying > transmux provides the functionality such as synchronization, > multiplexing, identification, etc., RTP and underlying UDP/IP > layer provides them. > > Another example is ISO/IEC 13818-1 AMD 7, MPEG-4 > on MPEG-2 Systems. It has been standardized based on the > same concept. This amendment allows to map MPEG-4 > AV streams directory into MPEG-2 TS or PS packets in > normative way. > > >Therefore, what would be the status of > >the current draft with respect to MPEG-4 compliance > >issues, since it says: > > > >"These RTP payload formats enable to carry MPEG-4 > >Audio/Visual streams without using the synchronization > >and stream management functionality of MPEG-4 Systems > >[6]. Such RTP payload format would be used within systems > >where their own stream management functionality is provided > >and thus such functionality in MPEG-4 Systems is not necessary. > >H.323 terminals are an example of such systems. MPEG-4 > >Audio/Visual streams are not managed by > >MPEG-4 Systems Object Descriptors but by H.245. The streams > >are directly mapped onto RTP packets without using the > >synchronization functionality of MPEG-4 Systems." > > Best regards, > Yoshinori Matsui > Matsushita / Panasonic From rem-conf Wed Jun 28 02:12:36 2000 From rem-conf-request@es.net Wed Jun 28 02:12:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137DrJ-0003hA-00; Wed, 28 Jun 2000 02:10:13 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 137DrH-0003dT-00; Wed, 28 Jun 2000 02:10:12 -0700 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0FWU001F6X5WT2@ss3000e.cselt.it> for rem-conf@es.net; Wed, 28 Jun 2000 11:03:33 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Jun 2000 11:11:02 +0200 Content-return: allowed Date: Wed, 28 Jun 2000 11:09:01 +0200 From: De Petris Gianluca Subject: RE: Updated I/D for MPEG-4 Audio/Visual RTP payload format To: "Y. Matsui" , "'leonid@bitband.com'" Cc: Christine Guillemot , Stephan Wenger , rhee@unity.ncsu.edu, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Message-id: <85077463E51D6A498C453073E16779400BC568@clu2k02a.cselt.it> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Leonid, we are carrying MPEG-4 over MPEG-2 TS according to AMD7 (I can give you = more details, if you are interested). Then either we send the MPEG-2 TS over a satellite channel (actually we = are just simulating this through a commercial DVB modulator with output in = IF) or we send the same MPEG-2 TS over UDP/IP in unicast. However, as you = say, I cannot see how this question is related with this thread of discussion. Regards, Gianluca De Petris = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D e-mail: Gianluca.DePetris@cselt.it tel.: + 39 011 228 6109 WWW: http://www.cselt.it/ufv/depetris fax : + 39 011 228 6299 Services and Applications - Multimedia Technologies and Services CSELT - Centro Studi E Laboratori Telecomunicazioni Via G. Reiss Romoli, 274 - 10148 TORINO (Italy) > ---------- > From: Leonid Rosenboim[SMTP:leonid@bitband.com] > Reply To: leonid@bitband.com > Sent: mercoled=EC 28 giugno 2000 11.05 > To: Y. Matsui > Cc: Christine Guillemot; Stephan Wenger; rhee@unity.ncsu.edu; > 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net > Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format >=20 > Just a quick (potentially unrelated) question: >=20 > Are you aware of anyone actually using the apparently normative = MPEG-4 > transport > which maps MPEG-4 ES on top of MPEG-2 TS wich in turn is carried over > UDP/IP ? >=20 >=20 > "Y. Matsui" wrote: >=20 > > Dear Christine, > > > > I would like to comment on your first question. > > > > >1- I understood from earlier e-mail/MPEG4-IETF phone > > >meeting discussions that to be MPEG-4 compliant, > > >terminals would have to support the sync layer, because > > >the ESI is not normative. > > > > MPEG-4 system is not mandatory if the underlying > > transmux provides the functionality such as synchronization, > > multiplexing, identification, etc., RTP and underlying UDP/IP > > layer provides them. > > > > Another example is ISO/IEC 13818-1 AMD 7, MPEG-4 > > on MPEG-2 Systems. It has been standardized based on the > > same concept. This amendment allows to map MPEG-4 > > AV streams directory into MPEG-2 TS or PS packets in > > normative way. > > > > >Therefore, what would be the status of > > >the current draft with respect to MPEG-4 compliance > > >issues, since it says: > > > > > >"These RTP payload formats enable to carry MPEG-4 > > >Audio/Visual streams without using the synchronization > > >and stream management functionality of MPEG-4 Systems > > >[6]. Such RTP payload format would be used within systems > > >where their own stream management functionality is provided > > >and thus such functionality in MPEG-4 Systems is not necessary. > > >H.323 terminals are an example of such systems. MPEG-4 > > >Audio/Visual streams are not managed by > > >MPEG-4 Systems Object Descriptors but by H.245. The streams > > >are directly mapped onto RTP packets without using the > > >synchronization functionality of MPEG-4 Systems." > > > > Best regards, > > Yoshinori Matsui > > Matsushita / Panasonic >=20 From rem-conf Wed Jun 28 02:32:57 2000 From rem-conf-request@es.net Wed Jun 28 02:32:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137EAd-0005qj-00; Wed, 28 Jun 2000 02:30:11 -0700 Received: from eau.irisa.fr [131.254.60.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 137EAc-0005qT-00; Wed, 28 Jun 2000 02:30:10 -0700 Received: from irisa.fr (borneo.irisa.fr [131.254.41.54]) by eau.irisa.fr (8.9.3/8.9.3) with ESMTP id LAA04049; Wed, 28 Jun 2000 11:29:08 +0200 (MET DST) Message-ID: <3959C561.6A7BCE42@irisa.fr> Date: Wed, 28 Jun 2000 11:29:06 +0200 From: Christine Guillemot X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: De Petris Gianluca CC: "Y. Matsui" , "'leonid@bitband.com'" , Stephan Wenger , rhee@unity.ncsu.edu, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format References: <85077463E51D6A498C453073E16779400BC568@clu2k02a.cselt.it> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by eau.irisa.fr id LAA04049 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Gianluca, De Petris Gianluca a =E9crit: > Leonid, > we are carrying MPEG-4 over MPEG-2 TS according to AMD7 (I can give you= more > details, if you are interested). Sorry, I have not followed the discussions on MPEG-4 over MPEG-2 TS closely.Could you tell me if for the transport over MPEG-2 TS, the usage of MPEG-4 SL + MPEG-4 Flexmux is requested or whether, if I understood Yoshinori's mail correctly, one can map MPEG-4 ES directly into MPEG-2 TS. Yoshinori wrote: > This amendment allows to map MPEG-4 AV streams directory into MPEG-2 TS= or PS > packets in normative way." Thank you, Christine > Then either we send the MPEG-2 TS over a satellite channel (actually we= are > just simulating this through a commercial DVB modulator with output in = IF) > or we send the same MPEG-2 TS over UDP/IP in unicast. However, as you s= ay, I > cannot see how this question is related with this thread of discussion. > Regards, > Gianluca De Petris =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > e-mail: Gianluca.DePetris@cselt.it tel.: + 39 011 228 6109 > WWW: http://www.cselt.it/ufv/depetris fax : + 39 011 228 6299 > Services and Applications - Multimedia Technologies and Services > CSELT - Centro Studi E Laboratori Telecomunicazioni > Via G. Reiss Romoli, 274 - 10148 TORINO (Italy) > > > ---------- > > From: Leonid Rosenboim[SMTP:leonid@bitband.com] > > Reply To: leonid@bitband.com > > Sent: mercoled=EC 28 giugno 2000 11.05 > > To: Y. Matsui > > Cc: Christine Guillemot; Stephan Wenger; rhee@unity.ncsu.edu; > > 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net > > Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload for= mat > > > > Just a quick (potentially unrelated) question: > > > > Are you aware of anyone actually using the apparently normative MPEG-= 4 > > transport > > which maps MPEG-4 ES on top of MPEG-2 TS wich in turn is carried over > > UDP/IP ? > > > > > > "Y. Matsui" wrote: > > > > > Dear Christine, > > > > > > I would like to comment on your first question. > > > > > > >1- I understood from earlier e-mail/MPEG4-IETF phone > > > >meeting discussions that to be MPEG-4 compliant, > > > >terminals would have to support the sync layer, because > > > >the ESI is not normative. > > > > > > MPEG-4 system is not mandatory if the underlying > > > transmux provides the functionality such as synchronization, > > > multiplexing, identification, etc., RTP and underlying UDP/IP > > > layer provides them. > > > > > > Another example is ISO/IEC 13818-1 AMD 7, MPEG-4 > > > on MPEG-2 Systems. It has been standardized based on the > > > same concept. This amendment allows to map MPEG-4 > > > AV streams directory into MPEG-2 TS or PS packets in > > > normative way. > > > > > > >Therefore, what would be the status of > > > >the current draft with respect to MPEG-4 compliance > > > >issues, since it says: > > > > > > > >"These RTP payload formats enable to carry MPEG-4 > > > >Audio/Visual streams without using the synchronization > > > >and stream management functionality of MPEG-4 Systems > > > >[6]. Such RTP payload format would be used within systems > > > >where their own stream management functionality is provided > > > >and thus such functionality in MPEG-4 Systems is not necessary. > > > >H.323 terminals are an example of such systems. MPEG-4 > > > >Audio/Visual streams are not managed by > > > >MPEG-4 Systems Object Descriptors but by H.245. The streams > > > >are directly mapped onto RTP packets without using the > > > >synchronization functionality of MPEG-4 Systems." > > > > > > Best regards, > > > Yoshinori Matsui > > > Matsushita / Panasonic > > From rem-conf Wed Jun 28 03:56:21 2000 From rem-conf-request@es.net Wed Jun 28 03:56:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137FOs-0002aq-00; Wed, 28 Jun 2000 03:48:58 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 137FOq-0002ae-00; Wed, 28 Jun 2000 03:48:56 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17886; Wed, 28 Jun 2000 06:48:54 -0400 (EDT) Message-Id: <200006281048.GAA17886@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-12.txt Date: Wed, 28 Jun 2000 06:48:54 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, I. Suconick, B. Strahm Filename : draft-ietf-avt-rtp-mib-12.txt Pages : 35 Date : 27-Jun-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol(RTP) systems [RFC1889]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-12.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000627114934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000627114934.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Jun 28 06:16:55 2000 From rem-conf-request@es.net Wed Jun 28 06:16:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137Hcu-0002lL-00; Wed, 28 Jun 2000 06:11:36 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 137Hct-0002l9-00; Wed, 28 Jun 2000 06:11:35 -0700 Received: from guest6.cs.unc.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 28 Jun 2000 14:11:19 +0100 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id XAA14349; Tue, 27 Jun 2000 23:24:24 +0100 Message-Id: <200006272224.XAA14349@purple.east.isi.edu> To: Stephan Wenger cc: Hideaki Kimata , fukunaga444@oki.co.jp, rhee@unity.ncsu.edu, kiku@eel.rdc.toshiba.co.jp, 4on2andIP-sys@advent.ee.columbia.edu, rem-conf@es.net Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format In-Reply-To: Message from Stephan Wenger of "Mon, 26 Jun 2000 13:23:23 +0200." <4.3.2.7.2.20000626131354.02b67260@mail.cs.tu-berlin.de> Date: Tue, 27 Jun 2000 18:24:24 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Stephan Wenger writes: > > As I pointed out in previous Email, NEWPRED is one tool of ARTS profile > > in MPEG-4. And NEWPRED RTCP messages are only transmitted between > > ARTS profile terminals. > > > This means the usage of these messages is not definitly generic, and > > setup procedure should be also different from other backward channel > > messages. I mean the setup should be after receiving profile and level > > indication of MPEG-4. > > > I believe this fact makes objection for NEWPRED RTCP meaningless. > >No. I believe not. Sorry. > >The definition of exactly one (of many possible and known) feedback >mechanisms is the very point of my objection. This is regardless of >whether that mechanism is specific to MPEG-4 (which it is not, as >H.263 has NEWPRED, too), or to a specific MPEG-4 profile. Right. I would like the payload format for elementary streams to be usable with a range of different backchannel and error protection schemes. It is hard to do this if the format includes a specific reference to NEWPRED. I have no problem with NEWPRED being one option for this, but we have to allow the possibility of other schemes, and I think this requires that the NEWPRED support is broken out into a separate document. Colin From rem-conf Wed Jun 28 07:30:17 2000 From rem-conf-request@es.net Wed Jun 28 07:30:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137Imx-0007Qy-00; Wed, 28 Jun 2000 07:26:03 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 137Imv-0007Qn-00; Wed, 28 Jun 2000 07:26:01 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id XAA27212; Wed, 28 Jun 2000 23:25:57 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id XAA20167; Wed, 28 Jun 2000 23:25:57 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id XAA07615; Wed, 28 Jun 2000 23:25:56 +0900 (JST) Received: from ave (kwa0107.mobile.toshiba.co.jp [133.120.199.23]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id XAA48258; Wed, 28 Jun 2000 23:25:53 +0900 (JST) Message-ID: <012801bfe10c$bed8ce40$17c77885@ave> From: "Yoshihiro Kikuchi" To: "Christine Guillemot" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Yoshihiro Kikuchi" References: <85077463E51D6A498C453073E16779400BC568@clu2k02a.cselt.it> <3959C561.6A7BCE42@irisa.fr> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Wed, 28 Jun 2000 23:25:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailhost.eel.rdc.toshiba.co.jp id XAA48258 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Chiristine, Matsui-san, Gianluca, all, > > > > Another example is ISO/IEC 13818-1 AMD 7, MPEG-4 > > > > on MPEG-2 Systems. It has been standardized based on the > > > > same concept. This amendment allows to map MPEG-4 > > > > AV streams directory into MPEG-2 TS or PS packets in > > > > normative way. I think what Matsui-san trying to menthion here is to raise other example= s than RTP that do not mandate MPEG-4 Systems Sync Layer or Flex Mux. I can add other such examples: 3G-324M(H.324), etc. I believe this is also the case for the transport over RTP. > > > > MPEG-4 system is not mandatory if the underlying > > > > transmux provides the functionality such as synchronization, > > > > multiplexing, identification, etc., RTP and underlying UDP/IP > > > > layer provides them. This is very correct. MPEG-4 Audio/Visual elementary streams can be mappe= d directly on RTP packets without any knowledge of MPEG-4 Systems. Attribut= es of the stream such as packetization format, media type and profile@level = can be signaled by H.245 in H.323, and MIME and SDP in systems such as SIP an= d RTSP. Best regards, Yoshihiro ----- Original Message ----- From: Christine Guillemot To: De Petris Gianluca Cc: Y. Matsui ; ; Stephan Wenge= r ; ; <4on2andIP-sys@advent.ee.columbia.edu>; Sent: Wednesday, June 28, 2000 6:29 PM Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > Dear Gianluca, > > > De Petris Gianluca a =E9crit: > > > Leonid, > > we are carrying MPEG-4 over MPEG-2 TS according to AMD7 (I can give y= ou more > > details, if you are interested). > > Sorry, I have not followed the discussions on MPEG-4 over MPEG-2 TS > closely.Could you tell me if for the transport over MPEG-2 TS, > the usage of MPEG-4 SL + MPEG-4 Flexmux is requested or whether, if > I understood Yoshinori's mail correctly, one can map > MPEG-4 ES directly into MPEG-2 TS. > > Yoshinori wrote: > > > This amendment allows to map MPEG-4 AV streams directory into MPEG-2 = TS or PS > > packets in normative way." > > Thank you, > Christine > > > > Then either we send the MPEG-2 TS over a satellite channel (actually = we are > > just simulating this through a commercial DVB modulator with output i= n IF) > > or we send the same MPEG-2 TS over UDP/IP in unicast. However, as you say, I > > cannot see how this question is related with this thread of discussio= n. > > Regards, > > Gianluca De Petris =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > e-mail: Gianluca.DePetris@cselt.it tel.: + 39 011 228 6109 > > WWW: http://www.cselt.it/ufv/depetris fax : + 39 011 228 6299 > > Services and Applications - Multimedia Technologies and Services > > CSELT - Centro Studi E Laboratori Telecomunicazioni > > Via G. Reiss Romoli, 274 - 10148 TORINO (Italy) > > > > > ---------- > > > From: Leonid Rosenboim[SMTP:leonid@bitband.com] > > > Reply To: leonid@bitband.com > > > Sent: mercoled=EC 28 giugno 2000 11.05 > > > To: Y. Matsui > > > Cc: Christine Guillemot; Stephan Wenger; rhee@unity.ncsu.edu; > > > 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net > > > Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > > > > > > Just a quick (potentially unrelated) question: > > > > > > Are you aware of anyone actually using the apparently normative MPE= G-4 > > > transport > > > which maps MPEG-4 ES on top of MPEG-2 TS wich in turn is carried ov= er > > > UDP/IP ? > > > > > > > > > "Y. Matsui" wrote: > > > > > > > Dear Christine, > > > > > > > > I would like to comment on your first question. > > > > > > > > >1- I understood from earlier e-mail/MPEG4-IETF phone > > > > >meeting discussions that to be MPEG-4 compliant, > > > > >terminals would have to support the sync layer, because > > > > >the ESI is not normative. > > > > > > > > MPEG-4 system is not mandatory if the underlying > > > > transmux provides the functionality such as synchronization, > > > > multiplexing, identification, etc., RTP and underlying UDP/IP > > > > layer provides them. > > > > > > > > Another example is ISO/IEC 13818-1 AMD 7, MPEG-4 > > > > on MPEG-2 Systems. It has been standardized based on the > > > > same concept. This amendment allows to map MPEG-4 > > > > AV streams directory into MPEG-2 TS or PS packets in > > > > normative way. > > > > > > > > >Therefore, what would be the status of > > > > >the current draft with respect to MPEG-4 compliance > > > > >issues, since it says: > > > > > > > > > >"These RTP payload formats enable to carry MPEG-4 > > > > >Audio/Visual streams without using the synchronization > > > > >and stream management functionality of MPEG-4 Systems > > > > >[6]. Such RTP payload format would be used within systems > > > > >where their own stream management functionality is provided > > > > >and thus such functionality in MPEG-4 Systems is not necessary. > > > > >H.323 terminals are an example of such systems. MPEG-4 > > > > >Audio/Visual streams are not managed by > > > > >MPEG-4 Systems Object Descriptors but by H.245. The streams > > > > >are directly mapped onto RTP packets without using the > > > > >synchronization functionality of MPEG-4 Systems." > > > > > > > > Best regards, > > > > Yoshinori Matsui > > > > Matsushita / Panasonic > > > > > > > From rem-conf Wed Jun 28 07:30:27 2000 From rem-conf-request@es.net Wed Jun 28 07:30:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137IpB-0007RY-00; Wed, 28 Jun 2000 07:28:21 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 137IpA-0007RO-00; Wed, 28 Jun 2000 07:28:20 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id XAA27465; Wed, 28 Jun 2000 23:28:18 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id XAA20388; Wed, 28 Jun 2000 23:28:18 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id XAA08652; Wed, 28 Jun 2000 23:28:18 +0900 (JST) Received: from ave (kwa0107.mobile.toshiba.co.jp [133.120.199.23]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id XAA48296; Wed, 28 Jun 2000 23:28:15 +0900 (JST) Message-ID: <013701bfe10d$13793c00$17c77885@ave> From: "Yoshihiro Kikuchi" To: "Christine Guillemot" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Yoshihiro Kikuchi" References: <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000626131354.02b67260@mail.cs.tu-berlin.de> <39587333.9BA8E2F@irisa.fr> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Wed, 28 Jun 2000 23:28:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Chiristine, all, Let me try to answer the second and third questions. > 2- It seems to me that some of the fragmentation rules do > not apply to scalable streams (or at least to enhancement > layers of scalable streams), e.g. below: > ---- > (5) A single video packet SHOULD NOT be split into a plurality of RTP > packets. The size of a video packet SHOULD be adjusted in such a way that > the resulting RTP packet is not larger than the path-MTU. A video packet > MAY be split into a plurality of RTP packets when the size of the video > packet is large. > ---- > since - unless recent changes - enhancement layers do not > support the notion of video packets. If this is > the case, how the scalable profiles can be really used > in a loss-prone environment?. > I'm not sure if this question is relevant to an RTP payload format spec. or something more general. It's true that the video packet is not supported in the enhancement layer. (It is supported in the base layer.) But this is the specification of the ISO/IEC 14496-2 itself but not specific to RTP payload formats. There was a discussion inside MPEG when defining enhancement layer syntax which does not support video packet. The understanding of the group was that the scalable video coding scheme itself has loss resiliency. It is possible to decode using only the base layer stream even when the enhancement layer is corrupt. Therefore, the base layer should be protected well but not so much for the enhancement layer. This is why MPEG-4 error resiliency tools (video packet and others) are supported in the base layer. > 3- Overall, the draft seems to target extremely specific > applications - relying on real-time encoders -. I would like > to have some indications on how it can be used for > streaming applications. > I think network oriented delivery shemes used in the existing streaming frameworks can also be applied to this RTP payload format. One way is to prepare a pare of streams with a variety of encoding parameters, and select one of them when transporting a stream depend on the network environment. This is the way used widely in streaming frameworks, and I believe this works properly also for MPEG-4 audio/video. > Indeed, considering the video part, protection of headers > rely on the usage of the HEC field. > A network adaptive usage of this field would require the > implementation of a video stream parser (i.e. a part of a > decoder), in order to incorporate inside the video packets > the important data that needs to be protected. Is it really > what we want? > I'm sorry but I cannot understand what you are trying to address. Are you trying to do something like an adjustment of an RTP packet size depend on the network environment? Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 From rem-conf Wed Jun 28 10:10:30 2000 From rem-conf-request@es.net Wed Jun 28 10:10:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137LJD-00021P-00; Wed, 28 Jun 2000 10:07:31 -0700 Received: from eau.irisa.fr [131.254.60.97] by mail1.es.net with esmtp (Exim 1.81 #2) id 137LJB-00021E-00; Wed, 28 Jun 2000 10:07:29 -0700 Received: from irisa.fr (borneo.irisa.fr [131.254.41.54]) by eau.irisa.fr (8.9.3/8.9.3) with ESMTP id TAA27397; Wed, 28 Jun 2000 19:07:12 +0200 (MET DST) Message-ID: <395A30BD.D493AAA1@irisa.fr> Date: Wed, 28 Jun 2000 19:07:09 +0200 From: Christine Guillemot X-Mailer: Mozilla 4.03 [fr] (WinNT; I) MIME-Version: 1.0 To: Yoshihiro Kikuchi CC: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, IETF AVT Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format References: <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000626131354.02b67260@mail.cs.tu-berlin.de> <39587333.9BA8E2F@irisa.fr> <013701bfe10d$13793c00$17c77885@ave> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Yoshihiro, > > 2- It seems to me that some of the fragmentation rules do > > not apply to scalable streams (or at least to enhancement > > layers of scalable streams), e.g. below: > > ---- > > (5) A single video packet SHOULD NOT be split into a plurality of RTP > > packets. The size of a video packet SHOULD be adjusted in such a way > that > > the resulting RTP packet is not larger than the path-MTU. A video > packet > > MAY be split into a plurality of RTP packets when the size of the video > > packet is large. > > ---- > > since - unless recent changes - enhancement layers do not > > support the notion of video packets. If this is > > the case, how the scalable profiles can be really used > > in a loss-prone environment?. > > > I'm not sure if this question is relevant to an RTP payload format spec. or > something more general. It's true that the video packet is not supported in > the enhancement layer. (It is supported in the base layer.) But this is the > specification of the ISO/IEC 14496-2 itself but not specific to RTP payload > formats. Since the comment refers to a fragmentation rule of the videostream, a rule which is part of the payload format spec., i would think the question to be relevant to the payload format spec. > > > There was a discussion inside MPEG when defining enhancement layer syntax > which does not support video packet. The understanding of the group was that > the scalable video coding scheme itself has loss resiliency. It is possible > to decode using only the base layer stream even when the enhancement layer > is corrupt. Therefore, the base layer should be protected well but not so > much for the enhancement layer. This is why MPEG-4 error resiliency tools > (video packet and others) are supported in the base layer. > > > 3- Overall, the draft seems to target extremely specific > > applications - relying on real-time encoders -. I would like > > to have some indications on how it can be used for > > streaming applications. > > > I think network oriented delivery shemes used in the existing streaming > frameworks can also be applied to this RTP payload format. > > One way is to prepare a pare of streams with a variety of encoding > parameters, How many streams for the same content to be storedon the server? > and select one of them when transporting a stream depend on the > network environment. This is the way used widely in streaming frameworks, > and I believe this works properly also for MPEG-4 audio/video. > > > Indeed, considering the video part, protection of headers > > rely on the usage of the HEC field. > > A network adaptive usage of this field would require the > > implementation of a video stream parser (i.e. a part of a > > decoder), in order to incorporate inside the video packets > > the important data that needs to be protected. Is it really > > what we want? > > > I'm sorry but I cannot understand what you are trying to address. Are you > trying to do something like an adjustment of an RTP packet size depend on > the network environment? > Definitely not! simply pointing out that relying entirely on theHEC field for protection of header information may not be that suited in the case of streaming applications. Regards, Christine > Best regards, > Yoshihiro > ---- > Yoshihiro Kikuchi > > E-mail: kiku@eel.rdc.toshiba.co.jp > Corporate Research and Development Center > TOSHIBA Corporation > TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 From rem-conf Wed Jun 28 18:13:46 2000 From rem-conf-request@es.net Wed Jun 28 18:13:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137Sms-0000lF-00; Wed, 28 Jun 2000 18:06:38 -0700 Received: from mickey.ee.pdx.edu [131.252.208.42] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 137Smr-0000iz-00; Wed, 28 Jun 2000 18:06:37 -0700 Received: from chip.ee.pdx.edu (videoc@chip.ee.pdx.edu [131.252.221.60]) by mickey.ee.pdx.edu (8.9.1/8.9.1) with ESMTP id RAA10184; Wed, 28 Jun 2000 17:55:57 -0700 (PDT) From: Video Compression Workshop Received: (from videoc@localhost) by chip.ee.pdx.edu (8.8.6/8.8.5) id RAA23518; Wed, 28 Jun 2000 17:31:17 -0700 (PDT) Date: Wed, 28 Jun 2000 17:31:17 -0700 (PDT) Message-Id: <200006290031.RAA23518@chip.ee.pdx.edu> To: compress@ee.pdx.edu Subject: Video Compression Short Course in Portland 8/7-12/2000 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Subject: Video Compression Short Course in Portland 8/7-12/2000 4 & 1/2 Days (August 7 - 12, 2000) in Portland Oregon on IMAGE AND VIDEO COMPRESSION: FUNDAMENTALS, STANDARDS, AND APPLICATIONS Featured: Majid Rabbani - Eastman Kodak M. Ibrahim Sezan - Sharp Labs. of America Thomas Gardos - Intel Corporation Organized by Fu Li Portland State University, Portland, Oregon, USA please visit http://www.ee.pdx.edu/~compress Contact Don Mueller at Telephone: (503) 725-3806 Facsimile: (503) 725-3807 Email: donm@eas.pdx.edu Comprehensive Coverage on JPEG-2000, MPEG -4 and -7, and H.26x Standards! With Latest Technology Demos Seats limited. Please register today! From rem-conf Wed Jun 28 21:47:26 2000 From rem-conf-request@es.net Wed Jun 28 21:47:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137WAf-0002Ep-00; Wed, 28 Jun 2000 21:43:25 -0700 Received: from mail0.yrp.nttdocomo.co.jp [202.245.184.18] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 137WAc-0002Eb-00; Wed, 28 Jun 2000 21:43:23 -0700 Received: from spg.yrp.nttdocomo.co.jp (spg.yrp.nttdocomo.co.jp [172.21.48.130]) by mail0.yrp.nttdocomo.co.jp (8.9.0/YRPHUB0-8819980304) with ESMTP id NAA07536; Thu, 29 Jun 2000 13:43:17 +0900 (JST) Message-Id: <4.2.0.58.J.20000629131321.00d12250@spg.yrp.nttdocomo.co.jp> X-Sender: kawahara@spg.yrp.nttdocomo.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Thu, 29 Jun 2000 13:21:53 +0900 To: "Yoshihiro Kikuchi" , "Christine Guillemot" From: Toshiro Kawahara Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Yoshihiro Kikuchi" In-Reply-To: <012801bfe10c$bed8ce40$17c77885@ave> References: <85077463E51D6A498C453073E16779400BC568@clu2k02a.cselt.it> <3959C561.6A7BCE42@irisa.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Kikuchi-san and all, I have an comment on the MIME parameters for MPEG-4 visual, or a request to add another important parameter to them. That is decoderConfiguraitonInformation, which indicates the configuration of the transmitted bitstream (i.e., VO/VOL headers). H.245 have this field for the use of MPEG-4 Visual, and thus considering interworking with systems using H.245 as H.323 or H.324, this field should also be supported by SIP with MIME parameters. Regards, Toshiro --- Toshiro Kawahara NTT DoCoMo, Inc. (We have changed our corporate name from April!) Multimedia Laboratories, Multimedia Signal Processing Laboratory TEL: +81 468 40 3518 FAX: +81 468 40 3788 $B2O86(B $BIRO/(B (in Japanese) From rem-conf Thu Jun 29 02:29:55 2000 From rem-conf-request@es.net Thu Jun 29 02:29:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137aWq-0007S8-00; Thu, 29 Jun 2000 02:22:36 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 137aWk-0007NS-00; Thu, 29 Jun 2000 02:22:33 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id SAA28909; Thu, 29 Jun 2000 18:22:09 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id SAA00303; Thu, 29 Jun 2000 18:22:08 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id SAA17465; Thu, 29 Jun 2000 18:22:07 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id SAA03122; Thu, 29 Jun 2000 18:22:07 +0900 (JST) Message-ID: <007101bfe1ab$780df0e0$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Toshiro Kawahara" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Yoshihiro Kikuchi" References: <85077463E51D6A498C453073E16779400BC568@clu2k02a.cselt.it><3959C561.6A7BCE42@irisa.fr> <4.2.0.58.J.20000629131321.00d12250@spg.yrp.nttdocomo.co.jp> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Thu, 29 Jun 2000 18:21:55 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Kawahara-san and all, Thank you very much for your comment. I agree with Kawahara-san that the interworking between the systems is the matter to be covered in this Internet-Draft. Does the following minor revision on section 5 meet your request? - In section 5.1 "MIME type registration for MPEG-4 Visual", add the following parameter to "Optional parameters": config: A hexadecimal representation of an octet string that expresses the MPEG-4 Visual configuration information, as defined in subclause 6.2.1 Start codes of ISO/IEC14496-2[2][4][9]. The configuration information is mapped onto the octet string in an MSB-first basis. The first bit of the configuration information SHALL be located at the MSB of the first octet. The configuration information indicated by this parameter SHALL be the same as the configuration information in the corresponding MPEG-4 Visual stream, except for first_half_vbv_occupancy and latter_half_vbv_occupancy which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2). - In section 5.2 "SDP usage of MPEG-4 Visual", replace the description for "a=fmtp" parameter with the following: o The optional parameter "profile-level-id" and "config" MAY go in the "a=fmtp" line to indicate the coder capability and configuration. These parameters are expressed as a MIME media type string, in the form of as a semicolon separated list of parameter=value pairs. Best regards, Yoshihiro ----- Original Message ----- From: Toshiro Kawahara To: Yoshihiro Kikuchi ; Christine Guillemot Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT ; Yoshihiro Kikuchi Sent: Thursday, June 29, 2000 1:21 PM Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > Kikuchi-san and all, > > I have an comment on the MIME parameters for MPEG-4 visual, or a > request to add another important parameter to them. > > That is decoderConfiguraitonInformation, which indicates the > configuration of the transmitted bitstream (i.e., VO/VOL headers). > H.245 have this field for the use of MPEG-4 Visual, and thus > considering interworking with systems using H.245 as H.323 or H.324, > this field should also be supported by SIP with MIME parameters. > > Regards, > Toshiro > --- > Toshiro Kawahara > NTT DoCoMo, Inc. > (We have changed our corporate name from April!) > Multimedia Laboratories, Multimedia Signal Processing Laboratory > TEL: +81 468 40 3518 FAX: +81 468 40 3788 > $B2O86(B $BIRO/(B (in Japanese) > From rem-conf Thu Jun 29 03:09:15 2000 From rem-conf-request@es.net Thu Jun 29 03:09:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137bD8-0002Id-00; Thu, 29 Jun 2000 03:06:18 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 137bD0-0002IB-00; Thu, 29 Jun 2000 03:06:13 -0700 Received: from tis2.tis.toshiba.co.jp (tis2 [133.199.160.66]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id TAA13626; Thu, 29 Jun 2000 19:05:46 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id TAA15604; Thu, 29 Jun 2000 19:05:45 +0900 (JST) Received: from mailhost.eel.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id TAA10687; Thu, 29 Jun 2000 19:05:44 +0900 (JST) Received: from ave (srg-79 [133.196.81.79]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id TAA05884; Thu, 29 Jun 2000 19:05:45 +0900 (JST) Message-ID: <00e001bfe1b1$90395280$4f51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Christine Guillemot" Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Yoshihiro Kikuchi" References: <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000621020820.02b2a7f0@mail.cs.tu-berlin.de> <200006230139.CAA03225@purple.east.isi.edu> <4.3.2.7.2.20000626131354.02b67260@mail.cs.tu-berlin.de> <39587333.9BA8E2F@irisa.fr> <013701bfe10d$13793c00$17c77885@ave> <395A30BD.D493AAA1@irisa.fr> Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Date: Thu, 29 Jun 2000 19:05:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Christine, all, > > > 2- It seems to me that some of the fragmentation rules do > > > not apply to scalable streams (or at least to enhancement > > > layers of scalable streams), e.g. below: > > > ---- > > > (5) A single video packet SHOULD NOT be split into a plurality of RTP > > > packets. The size of a video packet SHOULD be adjusted in such a way > > that > > > the resulting RTP packet is not larger than the path-MTU. A video > > packet > > > MAY be split into a plurality of RTP packets when the size of the video > > > packet is large. Christine is correct in the meaning that the video packet size cannot be adjusted for the enhancement layer stream where the video packet is not supported. To be more precise, I would like to propose the following change on the fragmentation rule: (5) A single video packet SHOULD NOT be split into a plurality of RTP packets, except for the enhancement layer of the scalable streams where the video packet is not supported. The size of a video packet SHOULD be adjusted in such a way that the resulting RTP packet is not larger than the path-MTU in this case. A video packet MAY be split into a plurality of RTP packets when the size of the video packet is large. Best regards, Yoshihiro ---- Yoshihiro Kikuchi E-mail: kiku@eel.rdc.toshiba.co.jp Corporate Research and Development Center TOSHIBA Corporation TEL: +81 +44 549 2288 FAX: +81 +44 520 1267 From rem-conf Thu Jun 29 06:50:59 2000 From rem-conf-request@es.net Thu Jun 29 06:50:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137eWg-0005aZ-00; Thu, 29 Jun 2000 06:38:42 -0700 Received: from netsys.kaist.ac.kr [143.248.148.90] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 137eWd-0005aB-00; Thu, 29 Jun 2000 06:38:39 -0700 Received: from host (netsys16.kaist.ac.kr [143.248.148.96]) by netsys.kaist.ac.kr (8.9.3/8.9.3) with SMTP id PAA01143; Thu, 29 Jun 2000 15:40:15 +0900 Message-ID: <000b01bfe19d$15155d60$6094f88f@kaist.ac.kr> From: "PV2001 Secretariat" To: , , Subject: PV 2001 Date: Thu, 29 Jun 2000 16:38:56 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01BFE1E8.84DB73A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BFE1E8.84DB73A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01BFE1E8.84DB73A0" ------=_NextPart_001_0008_01BFE1E8.84DB73A0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQo8PEFQT0xPR0lFUyBUTyBUSE9TRSBXSE8gUkVDRUlWRSBUSElTIEVNQUlMIE1PUkUgVEhBTiBP TkNFLj4+DQoNCkludml0YXRpb24gdG8gUFYoUGFja2V0IFZpZGVvIFdvcmtzaG9wKSAyMDAxIDog MzAgQXByaWwgLSAxIE1heSAyMDAxLA0KS3lvbmdqdSwgS29yZWENCg0KICAgIFRoZSAxMXRoIElu dGVybmF0aW9uYWwgUGFja2V0IFZpZGVvIFdvcmtzaG9wIChQViAyMDAxKSB3aWxsIGJlIGhlbGQg b24gMzAgQXByaWwgLSANCjEgTWF5IDIwMDEgaW4gS3lvbmdqdSwgS29yZWEsIHdoaWNoIHdhcyB0 aGUgY2FwaXRhbCBjaXR5IG9mIGFuY2llbnQgS29yZWEgKEEuRCA2NzYgLQ0KQS5EIDkzNSksIGxv Y2F0ZWQgaW4gMzUwLWtpbG9tZXRlciBzb3V0aGVhc3Qgb2YgU2VvdWwuIFRoZSB3b3Jrc2hvcCBp cyBkZXZvdGVkIHRvIA0KcHJlc2VudGluZyB0ZWNobm9sb2dpY2FsIGFkdmFuY2VtZW50cyBhbmQg aW5ub3ZhdGlvbnMgaW4gdmlkZW8gdHJhbnNtaXNzaW9uIG92ZXINCnBhY2tldCBuZXR3b3Jrcywg aW4gcGFydGljdWxhciwgdGhlIEludGVybmV0LiBQYWNrZXQgVmlkZW8gV29ya3Nob3AgaGFzIGJl ZW4gdW5pcXVlDQppbiBwcm92aWRpbmcgYSBjb21tb24gZ3JvdW5kIGZvciBwZW9wbGUgZnJvbSB2 aWRlbyBjb2RpbmcgYW5kIG5ldHdvcmtpbmcgZmllbGRzLiANClByZXNlbnRhdGlvbnMgb24gdGhl b3J5IGFuZCBwcmFjdGljZSwgc3RhbmRhcmRzIGFjdGl2aXRpZXMsIGFuZCBidXNpbmVzcyBhbmQg Y29uc3VtZXINCmFwcGxpY2F0aW9ucyBhcmUgZW5jb3VyYWdlZC4gSW4gMjAwMSwgdGhlIHdvcmtz aG9wIGlzIHNjaGVkdWxlZCB0byB0YWtlIHBsYWNlIGluIHRoZQ0Kd2VlayBmb2xsb3dpbmcgUGlj dHVyZSBDb2RpbmcgU3ltcG9zaXVtIChQQ1MgMjAwMSkgd2hpY2ggd2lsbCBiZSBoZWxkIGluIFNl b3VsLCANCktvcmVhIG9uIDI1LTI3IEFwcmlsIDIwMDEgKGh0dHA6Ly9wY3Mua2Fpc3QuYWMua3Ip LiBXZSBjb3JkaWFsbHkgaW52aXRlIHlvdSB0YWtlIHBhcnQgaW4gDQp0aGlzIHdvcmtzaG9wIGJ5 IHN1Ym1pdHRpbmcgeW91ciB3b3JrLiANCg0KSW1wb3J0YW50IGR1ZSBkYXRlOg0KICAgIE5vdmVt YmVyIDE1LCAyMDAwOiBQYXBlciBzdWJtaXNzaW9uDQogICAgSmFudWFyeSAzMSwgMjAwMTogICAg Tm90aWNlIG9mIGFjY2VwdGFuY2UNCiAgICBNYXJjaCAxNSwgMjAwMTogICAgICBGaW5hbCBwYXBl ciBkZWxpdmVyeQ0KDQpGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBQViAyMDAxIGFuZCB0aGUg Y29uZmVyZW5jZSBjaXR5LCBreW9uZ2p1LCBwbGVhc2UgY2hlY2sgdGhlIA0KYXR0YWNoZWQgZmls ZSBhcyB3ZWxsIGFzIHRoZSB3ZWIgc2l0ZSBvZiBodHRwOi8vcHYyMDAxLmthaXN0LmFjLmtyLg0K DQpCZXN0IHJlZ2FyZHMsDQoNCkphZS1reW9vbiBLaW0sIEdlbmVyYWwgQ2hhaXINCg== ------=_NextPart_001_0008_01BFE1E8.84DB73A0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI2MTQuMzUwMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48QlI+Jmx0OyZsdDtBUE9MT0dJRVMgVE8gVEhPU0UgV0hP IFJFQ0VJVkUgVEhJUyANCkVNQUlMIE1PUkUgVEhBTiBPTkNFLiZndDsmZ3Q7PC9GT05UPjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNUUk9O Rz5JbnZpdGF0aW9uIHRvIFBWKFBhY2tldCZuYnNwO1ZpZGVvIA0KV29ya3Nob3ApIDIwMDEgOiZu YnNwOzMwIEFwcmlsIC0gMSBNYXkgMjAwMSw8QlI+S3lvbmdqdSwgDQpLb3JlYTwvU1RST05HPjwv Rk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgMTF0aCBJbnRlcm5hdGlvbmFsIFBhY2tldCANClZp ZGVvIFdvcmtzaG9wIChQViAyMDAxKSB3aWxsIGJlIGhlbGQgb24mbmJzcDszMDwvRk9OVD48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj4gDQpBcHJpbCAtIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+MSBNYXkgMjAwMSBpbiBLeW9uZ2p1LCBLb3JlYSwgd2hpY2ggd2Fz IHRoZSBjYXBpdGFsIA0KY2l0eSBvZiBhbmNpZW50IEtvcmVhIChBLkQgNjc2IC08L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkEuRCA5MzUpLCBsb2NhdGVkIGluIDM1 MC1raWxvbWV0ZXIgc291dGhlYXN0IG9mIA0KU2VvdWwuIFRoZSB3b3Jrc2hvcCBpcyBkZXZvdGVk IHRvJm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5wcmVz ZW50aW5nIHRlY2hub2xvZ2ljYWwgYWR2YW5jZW1lbnRzIGFuZCANCmlubm92YXRpb25zIGluIHZp ZGVvIHRyYW5zbWlzc2lvbiZuYnNwO292ZXI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgc2l6ZT0yPnBhY2tldCBuZXR3b3JrcywgaW4gcGFydGljdWxhciwgdGhlIEludGVybmV0 LiANClBhY2tldCZuYnNwO1ZpZGVvIFdvcmtzaG9wIGhhcyBiZWVuIHVuaXF1ZTwvRk9OVD48L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+aW4gcHJvdmlkaW5nIGEgY29tbW9uIGdy b3VuZCBmb3IgcGVvcGxlIGZyb20gdmlkZW8gDQpjb2RpbmcgYW5kIG5ldHdvcmtpbmcgZmllbGRz LiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UHJlc2Vu dGF0aW9ucyBvbiB0aGVvcnkgYW5kIHByYWN0aWNlLCBzdGFuZGFyZHMgDQphY3Rpdml0aWVzLCBh bmQgYnVzaW5lc3MgYW5kIGNvbnN1bWVyPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj5hcHBsaWNhdGlvbnMgYXJlIGVuY291cmFnZWQuIEluIDIwMDEsIHRoZSB3b3Jr c2hvcCANCmlzJm5ic3A7c2NoZWR1bGVkJm5ic3A7dG8gdGFrZSBwbGFjZSBpbiB0aGU8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48Rk9OVCBmYWNlPUFyaWFsPndlZWsgZm9sbG93aW5n IDwvRk9OVD48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48U1RST05HPlBpY3R1cmUg Q29kaW5nIFN5bXBvc2l1bSAoUENTIDIwMDEpIDwvU1RST05HPndoaWNoJm5ic3A7d2lsbCBiZSAN CmhlbGQgaW4gU2VvdWwsIDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXpl PTI+S29yZWEgb24gPC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjI1LTI3IEFwcmlsIA0K MjAwMSAoPEEgaHJlZj0iaHR0cDovL3Bjcy5rYWlzdC5hYy5rciI+aHR0cDovL3Bjcy5rYWlzdC5h Yy5rcjwvQT4pLiBXZSBjb3JkaWFsbHkgDQppbnZpdGUgeW91IHRha2UgcGFydCBpbiA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPnRoaXMgd29ya3Nob3A8L0ZPTlQ+ PEZPTlQgc2l6ZT0yPiBieSBzdWJtaXR0aW5nIA0KeW91ciB3b3JrLiA8L0ZPTlQ+PC9ESVY+DQo8 RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5JbXBvcnRhbnQg ZHVlIGRhdGU6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBOb3ZlbWJlciANCjE1LCAyMDAwOiZuYnNw O1BhcGVyIHN1Ym1pc3Npb248QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEphbnVhcnkgMzEsIA0KMjAw MTombmJzcDsmbmJzcDsmbmJzcDsgTm90aWNlIG9mIGFjY2VwdGFuY2U8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IE1hcmNoIDE1LCANCjIwMDE6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZp bmFsIHBhcGVyIGRlbGl2ZXJ5PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Rm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgUFYgMjAw MSBhbmQgdGhlIA0KY29uZmVyZW5jZSBjaXR5LCBreW9uZ2p1LCBwbGVhc2UgY2hlY2sgdGhlIDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+YXR0YWNoZWQgZmlsZSBh cyB3ZWxsIGFzIHRoZSB3ZWIgc2l0ZSBvZiA8QSANCmhyZWY9Imh0dHA6Ly9wdjIwMDEua2Fpc3Qu YWMua3IiPmh0dHA6Ly9wdjIwMDEua2Fpc3QuYWMua3I8L0E+LjwvRk9OVD48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPkJlc3QgcmVnYXJkcyw8 L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNp emU9Mj5KYWUta3lvb24gS2ltLCBHZW5lcmFsIA0KQ2hhaXI8L0ZPTlQ+PC9ESVY+PC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_001_0008_01BFE1E8.84DB73A0-- ------=_NextPart_000_0007_01BFE1E8.84DB73A0 Content-Type: application/msword; name="PV2001-callforpaper.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PV2001-callforpaper.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAATwAAAAAAAAAA EAAAUQAAAAEAAAD+////AAAAAE4AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAOSAJBAAA+FK/AAAAAAAAEAAAAAAABAAAMhYAAA4AYmpiav3P/c8AAAAAAAAAAAAAAAAAAAAA AAASBBYANiwAAJ+lAACfpQAAMhIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAIABAAAAAAAAgAEAAIAB AAAAAAAAgAEAAAAAAACAAQAAAAAAAIABAAAAAAAAgAEAABQAAAAAAAAAAAAAAJQBAAAAAAAAAgcA AAAAAAACBwAAAAAAAAIHAAAAAAAAAgcAACQAAAAmBwAALAAAAJQBAAAAAAAA7RgAAE4CAABeBwAA KAAAAIYHAAAAAAAAhgcAAAAAAACGBwAAAAAAAIYHAAAAAAAAHQkAAK4AAADLCQAANAAAAP8JAAAc AAAAbBgAAAIAAABuGAAAAAAAAG4YAAAAAAAAbhgAAAAAAABuGAAAAAAAAG4YAAAAAAAAbhgAACQA AAA7GwAAIAIAAFsdAABmAAAAkhgAABUAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAAAAAAAbCgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAZCQAABAAAAB0JAAAAAAAAGwoAAAAAAAAbCgAAAAAAAJIYAAAAAAAA eQwAAAAAAACAAQAAAAAAAIABAAAAAAAAhgcAAAAAAAAAAAAAAAAAAIYHAACTAQAApxgAABYAAAB5 DAAAAAAAAHkMAAAAAAAAeQwAAAAAAAAbCgAAMgIAAIABAAAAAAAAhgcAAAAAAACAAQAAAAAAAIYH AAAAAAAAbBgAAAAAAAAAAAAAAAAAAHkMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGwoAAAAAAABsGAAAAAAAAHkMAADIAwAAeQwAAAAAAABBEAAA VgAAAKgXAABAAAAAgAEAAAAAAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAACGBwAAAAAAAFIHAAAMAAAAsL0Ptojh vwGUAQAAbgUAAAIHAAAAAAAATQwAACIAAADoFwAADAAAAAAAAAAAAAAAABgAAGwAAAC9GAAAMAAA AO0YAAAAAAAA9BcAAAwAAADBHQAAmAAAAG8MAAAKAAAAWR4AAAAAAAAAGAAAAAAAAHkMAAAAAAAA lAEAAAAAAACUAQAAAAAAAIABAAAAAAAAgAEAAAAAAACAAQAAAAAAAIABAAAAAAAAAgDZAAAAKFBy ZWxpbWluYXJ5KQcgIFBWIDIwMDEgICAgICBDYWxsIGZvciBQYXBlcnMgYW5kIEFubm91bmNlbWVu dAcHMTF0aCBJbnRlcm5hdGlvbmFsIFBhY2tldCBWaWRlbyBXb3Jrc2hvcAcHDTMwIEFwcmlsIJYg MSBNYXksIDIwMDEsIEt5b25nanUsIEtvcmVhDVNwb25zb3JlZCBhbmQgb3JnYW5pemVkIGJ5OiBL SUNTIChLb3JlYSBJbnN0aXR1dGUgb2YgQ29tbXVuaWNhdGlvbiBTY2llbmNlcykNSW4gY29vcGVy YXRpb24gd2l0aCAodGVjaG5pY2FsIGNvLXNwb25zb3IpOiBFVVJBU0lQLCBJRUVFIENPTVNPQywg SUVFRSBTUCBzb2NpZXRpZXMgKHBlbmRpbmcpDQ1UaGUgMTF0aCBJbnRlcm5hdGlvbmFsIFBhY2tl dCBWaWRlbyBXb3Jrc2hvcCAoUFYgMjAwMSkgd2lsbCBiZSBoZWxkIG9uIDMwIEFwcmlsIC0gMSBN YXkgMjAwMSBpbiBLeW9uZ2p1LCBLb3JlYSwgd2hpY2ggd2FzIHRoZSBjYXBpdGFsIGNpdHkgb2Yg YW5jaWVudCBLb3JlYSAoQS5EIDY3Ni1BLkQgOTM1KSwgbG9jYXRlZCBpbiAzNTAta2lsb21ldGVy IHNvdXRoZWFzdCBvZiBTZW91bC4gVGhlIHdvcmtzaG9wIGlzIGRldm90ZWQgdG8gcHJlc2VudGlu ZyB0ZWNobm9sb2dpY2FsIGFkdmFuY2VtZW50cyBhbmQgaW5ub3ZhdGlvbnMgaW4gdmlkZW8gdHJh bnNtaXNzaW9uIG92ZXIgcGFja2V0IG5ldHdvcmtzLCBpbiBwYXJ0aWN1bGFyLCB0aGUgSW50ZXJu ZXQuIFBhY2tldCBWaWRlbyBXb3Jrc2hvcHMgaGF2ZSBiZWVuIHVuaXF1ZSBpbiBwcm92aWRpbmcg YSBjb21tb24gZ3JvdW5kIGZvciBwZW9wbGUgZnJvbSB2aWRlbyBjb2RpbmcgYW5kIG5ldHdvcmtp bmcgZmllbGRzLiBQcmVzZW50YXRpb25zIG9uIHRoZW9yeSBhbmQgcHJhY3RpY2UsIHN0YW5kYXJk cyBhY3Rpdml0aWVzLCBhbmQgYnVzaW5lc3MgYW5kIGNvbnN1bWVyIGFwcGxpY2F0aW9ucyBhcmUg ZW5jb3VyYWdlZC4gSW4gMjAwMSwgdGhlIHdvcmtzaG9wIGlzIHNjaGVkdWxlZCB0byB0YWtlIHBs YWNlIGluIHRoZSB3ZWVrIGZvbGxvd2luZyBQaWN0dXJlIENvZGluZyBTeW1wb3NpdW0gKFBDUyAy MDAxKSB3aGljaCB3aWxsIGJlIGhlbGQgaW4gU2VvdWwgb24gMjUtMjcgQXByaWwgMjAwMS4gV2Ug Y29yZGlhbGx5IGludml0ZSB5b3UgdG8gdGFrZSBwYXJ0IGluIHRoaXMgd29ya3Nob3AgYnkgc3Vi bWl0dGluZyB5b3VyIHdvcmsuIEFkZGl0aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHJlZ2lz dHJhdGlvbiwgaG90ZWwgcmVzZXJ2YXRpb24sIGFuZCB2ZW51ZSB3aWxsIGJlIGFubm91bmNlZCBv biB0aGUgd2ViIHNpdGUuIA0NUHJvc3BlY3RpdmUgYXV0aG9ycyBhcmUgYXNrZWQgdG8gc3VibWl0 IGFuIGVsZWN0cm9uaWMgbWFudXNjcmlwdCB3cml0dGVuIGluIE1TLVdvcmQgb3IgUG9zdHNjcmlw dCwgbm90IGV4Y2VlZGluZyAxMCBwcmludGVkIHBhZ2VzLiBUd28gdHlwZXMgb2YgcHJlc2VudGF0 aW9uIHdpbGwgYmUgdXNlZCwgb3JhbCBhbmQgcG9zdGVyIGF0IHRoZSB3b3Jrc2hvcC4gQWJvdXQg MjAgbWludXRlcyB3aWxsIGJlIGFsbG90dGVkIHRvIGVhY2ggb3JhbCBwcmVzZW50YXRpb24sIGlu Y2x1ZGluZyBkaXNjdXNzaW9uLg0NVG9waWNzIG9mIGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUg bm90IGxpbWl0ZWQgdG86DVZpZGVvIHN0cmVhbWluZyBvdmVyIEludGVybmV0DU5ldHdvcmsgYWRh cHRpdmUgdmlkZW8gY29kaW5nIGFuZCB0cmFuc3BvcnQNRXJyb3IvbG9zcyByZXNpbGllbnQgdmlk ZW8gY29kaW5nIGFuZCB0cmFuc3BvcnQNTGF5ZXJlZCBjb2RpbmcgZm9yIGVycm9yIHJlc2lsaWVu Y2UgYW5kIGhldGVyb2dlbmVvdXMgbmV0d29ya3MNUmF0ZSBjb250cm9sIGZvciBWQlIgdmlkZW8N U3RhdGlzdGljYWwgbXVsdGlwbGV4aW5nIGZvciBncmVhdGVyIG5ldHdvcmsgYW5kIHRlcm1pbmFs IHV0aWxpemF0aW9uIA1Db25nZXN0aW9uIGNvbnRyb2wgYW5kIGJhbmR3aWR0aCBhbGxvY2F0aW9u B0VmZmljaWVudCB0cmFuc2NvZGluZyBmb3IgaGV0ZXJvZ2VuZW91cyBuZXR3b3Jrcw1FcnJvciBj b25jZWFsbWVudCBhbmQgcG9zdCBwcm9jZXNzaW5nDVRyYWZmaWMgc2hhcGluZyBmb3IgZWZmaWNp ZW50IG5ldHdvcmsgYW5kIHRlcm1pbmFsIHV0aWxpemF0aW9uDVBlcmZvcm1hbmNlIG1vZGVsaW5n IGFuZCBldmFsdWF0aW9uIGZvciBwYWNrZXQgdmlkZW8gbmV0d29yaw1JbnRlcnN0cmVhbSBzeW5j aHJvbml6YXRpb24gZm9yIG11bHRpcGxlIHZpZGVvIHByZXNlbnRhdGlvbnMHUGFja2V0aXplZCB2 aWRlbyBmb3Igd2lyZWxlc3MvbW9iaWxlIHN5c3RlbXMNUGFja2V0aXplZCB2aWRlbyBmb3IgaG9t ZSBMQU6Scw1NdWx0aWNhc3RpbmcsIE1CT05FIGFwcGxpY2F0aW9ucw1JbnRlcm5hdGlvbmFsIHN0 YW5kYXJkczogTVBFRy00LCBNUEVHLTcsIEguMjZMLCBILjMyMywgUlRQLCBSVFNQLCBTSVAsIFNE UA1UZXJtaW5hbCBhbmQgc2VydmVyIGFyY2hpdGVjdHVyZSBmb3IgSW50ZXJuZXQgVFYNSW1wbGVt ZW50YXRpb25zIGFuZCBjb21tZXJjaWFsIGFwcGxpY2F0aW9ucyAHBw1HZW5lcmFsIENoYWlyOiAg SmFlLWt5b29uIEtpbSwgS0FJU1QsIEtvcmVhDVByb2dyYW0gQ29tbWl0dGVlOg1Kb2huIEFybm9s ZAkgICAgICBVLiBvZiBOZXcgU291dGggV2FsZXMsIEF1c3RyYWxpYQkJICBKYW1lcyBNb2Rlc3Rp bm8JIAlSZW5zc2VsYWVyIFBvbHl0ZWNobmljIEluc3QuLCBVU0ENQW5kcmVhIEJhc3NvCSAgICAg IEFUJlQgTGFicy1SZXNlYXJjaCwgVVNBCSAJICBHZW9mZiBNb3JyaXNvbgkJQlQgTGFicywgVUsN Sm9uIENyb3djcm9mdAkgICAgICBVLiBDb2xsZWdlIG9mIExvbmRvbiwgVUsJCSAgSGFucyBHLiBN dXNtYW5uCQlVLiBvZiBIYW5vdmVyLCBHZXJtYW55DUxlb25hcmRvIENoaWFyaWdsaW9uZSAgICAg IENTRUxULCBJdGFseQkJCQkgIFN0ZXZlbiBNY0Nhbm5lCSAgICAgCVUuIEMuIEJlcmtlbGV5LCBV U0ENTS4gUmVoYSBDaXZhbmxhcgkgICAgICBBVCZUIExhYnMtUmVzZWFyY2gsIFVTQQkJICBKb2Vy ZyBPdHQJCVUuIG9mIEJyZW1lbiwgR2VybWFueQ1TaGloLUZ1IENoYW5nCSAgICAgIENvbHVtYmlh IFUuLCBVU0EJCQkgIE5hb2hpc2EgT2h0YQkJU29ueSwgSmFwYW4NU3RlcGhlbiBDYXNuZXIJICAg ICAgQ0lTQ08sIFVTQQkJCQkgIEZlcm5hbmRvIFBlcmVpcmEJCUlTVC9VVEwsIFBvcnR1Z2FsDVlh bmdoZWUgQ2hvaQkgICAgICBTZW91bCBOYXRpb25hbCBVLiwgS29yZWEgCQkgIEFteSBSZWlibWFu CQlBVCZUIExhYnMtUmVzZWFyY2gsIFVTQQ1GcmFuY2VzY28gRy4gQi4gRGUgTmF0YWxlICAgVS4g b2YgVHJlbnRvLCBJdGFseSAJCQkgIEluam9uZyBSaGVlCSAgICAgCU5vcnRoIENhcm9saW5hIFN0 YXRlIFVuaXYuLCBVU0ENVG91cmFkaiBFYnJhaGltaQkgICAgICBFUEZMLCBTd2l0emVybGFuZAkJ CSAgU2hpbmppIFNoaW1vam8JCU9zYWthIFVuaXYuLCBKYXBhbg1CZXJuZCBHaXJvZAkgICAgICBT dGFuZm9yZCBVLiwgVVNBCQkJICBHYXJ5IFN1bGxpdmFuCQlNaWNyb3NvZnQsIFVTQQ1EYW5pZWwg RC4gR2l1c3RvCSAgICAgIFUuIG9mIENhZ2xpYXJpLCBJdGFseQkJCSAgTWluZy1UaW5nIFN1bgkJ VS4gb2YgV2FzaGluZ3RvbiwgVVNBDU1vaGFtbWVkIEdoYW5iYXJpCSAgICAgIFUuIG9mIEVzc2V4 LCBVSwkgCQkgIFJhbGYgU2NoYWVmZXIJCUhlaW5yaWNoLUhlcnR6IEluc3RpdHV0ZSwgR2VybWFu eQ1CYXJyeSBHLiBIYXNrZWxsCSAgICAgIEFUJlQgTGFicy1SZXNlYXJjaCwgVVNBCQkgIEEuIE11 cmF0IFRla2FscAkJVW5pdi4gb2YgUm9jaGVzdGVyLCBVU0ENSHN1ZWgtTWluZyBIYW5nCSAgICAg IE5hdGlvbmFsIENoaWFvIFR1bmcgVS4sIFRhaXdhbgkJICBUaGllcnJ5IFR1cmxldHRpCQlJTlJJ QSwgRnJhbmNlDUMuIJZDLiBKYXkgS3VvCSAgICAgIFUuIG9mIFNvdXRoZXJuIENhbGlmb3JuaWEs IFVTQQkgCSAgU3RlcGhhbiBXZW5nZXIgCQlUZWNobmljYWwgVS4gb2YgQmVybGluLCBHZXJtYW55 DUZhb3V6aSBLb3NzZW50aW5pCSAgICAgIFUuIG9mIEJyaXRpc2ggQ29sdW1iaWEsIENhbmFkYQkJ ICBIaXJvc2hpIFlhc3VkYQkgIAlVLiBvZiBUb2t5bywgSmFwYW4NSmFlLWt5b29uIEtpbQkgICAg ICBLQUlTVCwgS29yZWEgCQkJICBZYS1RaW4gWmhhbmcgCQlNaWNyb3NvZnQgUmVzZWFyY2gsIENo aW5hDQ1Pcmdhbml6aW5nIENvbW1pdHRlZSBDaGFpcjogIENoaWV0ZXVrIEFobiwgRVRSSSwgS29y ZWEJDVN1Ym1pdCBwYXBlcnMgdG86IGZ0cDovL3B2MjAwMS5rYWlzdC5hYy5rcgkJSW1wb3J0YW50 IERhdGVzIDoNCQkJUGFwZXIgc3VibWlzc2lvbgkJTm92ZW1iZXIgMTUsIDIwMDAgIA0JCU5vdGlm aWNhdGlvbiBvZiBhY2NlcHRhbmNlICAgSmFudWFyeSAzMSwgMjAwMQkJCQkJCUZpbmFsIHBhcGVy IGRlbGl2ZXJ5ICAgICAgICBNYXJjaCAxNSwgMjAwMQkgIA0NRm9yIGFueSBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uIG9yIGZvciByZWNlaXZpbmcgcmVndWxhciB1cGRhdGVzIG9uIFBWIDIwMDEsIHBs ZWFzZSB2aXNpdCB0aGUgd2ViIHBhZ2UgYXQ6IBMgSFlQRVJMSU5LICJodHRwOi8vcHZ3LmthaXN0 LmFjLmtyIiABFGh0dHA6Ly9wdjIwMDEua2Fpc3QuYWMua3IVLiAgU2VuZCBhbnkgY29tbWVudHMg b3Igc3VnZ2VzdGlvbnMgdG86IBMgSFlQRVJMSU5LICJtYWlsdG86cHZAcHYyMDAxLmthaXN0LmFj LmtyIiABFHB2QHB2MjAwMS5rYWlzdC5hYy5rchUuDQ0BCQEJAQ0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADgQAABcEAAAx BAAAMgQAAD0EAAA+BAAAPwQAAEEEAABDBAAAZwQAAGgEAABpBAAAagQAAHMEAAB0BAAAkQQAAKsE AACsBAAArQQAAN4EAAAIBQAAMQUAADwFAAA9BQAAQwUAAEUFAABtBQAAhAUAAIcFAACOBQAAkAUA AJkFAACaBQAAnwUAAKAFAACzBQAAtgUAANoFAADhBQAA5QUAAOYFAADqBQAA+wUAAAQGAAAXBgAA GQYAAJ8HAACgBwAA5QcAAPvs5N3k0wDJvcmvAKehnaGWofuhlqH7kIqCin2KfYp9in2KfYp9in2K fYp9in2KfYoACENKEgBPSgAAAA5DShIASCoBT0oAAG8oAQALQ0oSAE9KAABvKAELQ0oQAE9KAABv KAENNQiBNgiBT0oAAG8oAQc1CIFPSgAACjUIgU9KAABvKAEADjUIgUNKEgBPSgAAbygBABs1CIFC KgJDSh4AT0oAAFFKAABvKAFwaAAA/wAWNQiBQioCQ0oeAEgqAW8oAXBoAAD/AAATNQiBQioCQ0oe AG8oAXBoAAD/ABNPSgQAUEoFAFFKBABSSHgAbygBDE9KBABQSgUAUUoEAAAPT0oEAFBKBQBRSgQA bygBHDUIgTYIgTkIgUNKKgBPSgMAUUoDAFJItABvKAEAB09KAABvKAEAMQAEAAAOBAAAPgQAAD8E AABoBAAA9gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAACEqAAAAAAAAAAAAAAAfgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAYBABYkAUlmAQAAAABrAAAWJAEXJAFJZgEAAAAClmMABdYYBAEAAAQBAAAEAQAA BAEAAAQBAAAEAQAAB5QkAgjWMAACnf/cBWspAAc/Bv////////////////////8AB48j//////// /////////////xPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/ BAEAABT2AQAAGtYI//////////8b1gj//////////xzWCP//////////HdYI//////////801gYA AQoDYwBh9gMAAAYAABYkAUlmAQAAAAkAAAMkABYkAUlmAQAAAGEkAAAEAAQAADIWAAD9AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQFoBAAAaQQAAGoEAACRBAAA 3gQAADwFAAA9BQAA+ggAAPsIAAAaCgAAGwoAAE8KAABtCgAAmQoAAKYAAAAAAAAAAAAAAACgAAAA AAAAAAAAAAAAmgAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAACaAAAAAAAAAAAAAAAAmgAAAAAAAAAA AAAAAJoAAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAKAAAAAAAAAAAAAAAACS AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAAAAAAAAAAAHgAAAyQACiYAC0YD AA3GBwFoAQG0AAYPhAAAEYQAABJkyAAAABYkAUckAElmAQAAAF6EAABghAAAYSQAAAEAAAYAABJk oAAAAEckAAYAABJk8AAAAEckAAYAABJkjAAAAEckAABYAAAWJAEXJAFJZgEAAAAClmMABdYYBAEA AAQBAAAEAQAABAEAAAQBAAAEAQAAB5T5AQjWGgABnf9rKYAGzikMAQAA/////xIBAAD/////E9Yw AAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAa1gQA AAD/G9YE/////xzWBAAAAP8d1gT/////NNYGAAEKA2MAYfYDAAAADeUHAADmBwAA5wcAAP4HAAD/ BwAACQgAAB0IAAAgCAAAOQgAADsIAACKCAAAiwgAAJQIAAD4CAAA+QgAAPoIAAD7CAAAMQkAAEcJ AABcCQAAfQkAABgKAAAZCgAAGwoAACEKAABOCgAATwoAAPAMAADxDAAAvQ0AAL4NAAC/DQAAwg0A AMMNAADHDQAAyA0AAM0NAADPDQAA3A0AAN0NAADeDQAA5A0AAOUNAADqDQAA6w0AAPwNAAD9DQAA /g0AAAoOAABGDgAAZw4AAI0OAACSDgAA4A4AAOEOAAALDwAAHg8AACcPAAAzDwAARw8AAEwPAABT DwAAWw8AAHEPAAB3DwAAig8AAI8PAADBDwAAwg8AANMPAADYDwAABRAAAAYQAAAREAAAFhAAAPv1 7fXt5/vn++f75/vn4tz75/vn++Lc1tLO5/vn3MbS1tLW0tb7577nvufO0vW7++f75/vn++f75/vn ++f75/vn++f75/vn++f7BENKEgAAD0NKEgBPSgAAUkjIAG8oAQ41CIFDSgoAT0oAAG8oAQAHT0oA AG8oAQc1CIFPSgAACjUIgU9KAABvKAEAC0NKEABPSgAAbygBCENKEABPSgAAAAtDShIAT0oAAG8o AQ41CIFDShIAT0oAAG8oAQALNQiBQ0oSAE9KAAAIQ0oSAE9KAABKmQoAAMkKAAAICwAAIwsAAGoL AACWCwAAxwsAAO0LAAAsDAAAaQwAAKYMAADTDAAA8wwAABQNAABfDQAAkA0AAL0NAADhAAAAAAAA AAAAAAAAwwAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAA4QAAAAAAAAAAAAAA AMMAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAAwwAAAAAAAAAAAAAAAMMAAAAAAAAAAAAAAADDAAAA AAAAAAAAAAAAwwAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAADhAAAAAAAAAAAAAAAAwwAAAAAAAAAA AAAAAMMAAAAAAAAAAAAAAADDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHgAAAyQACiYAC0YDAA3GBwFoAQG0AAYPhLUA EYRL/xJkyAAAABYkAUckAElmAQAAAF6EtQBghEv/YSQAHgAAAyQACiYAC0YDAA3GBwFoAQG0AAYP hAAAEYQAABJkyAAAABYkAUckAElmAQAAAF6EAABghAAAYSQAABC9DQAAvg0AAL8NAADrDQAA/g0A AGgOAACzDgAACw8AAGEPAAC0DwAA9w8AAEAQAACVEAAAggAAAAAAAAAAAAAAAH0AAAAAAAAAAAAA AAB4AAAAAAAAAAAAAAAAdgAAAAAAAAAAAAAAAHAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAcAAA AAAAAAAAAAAAAHAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAcAAAAAAAAAAAAAAAAHAAAAAAAAAA AAAAAABwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABJkyAAAAEckAAABAAAABAAAEmTc AAAAAAQAABJktAAAAAB8AAAWJAEXJAFJZgEAAAAClmMABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAE AQAACNZGAAOd/xAObBswKgAGcw7/////////////////////AAZcDf////////////////////8A BsQO/////////////////////xPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAABT2AQAAGtYM////////////////G9YM////////////////HNYM//////// ////////HdYM////////////////NNYGAAEKA2MAYfYDAAAADBYQAAAsEAAALhAAAHsQAAB8EAAA jxAAAJQQAACwEAAAsRAAAIARAACBEQAAghEAAI0RAADnEQAA7BEAAO0RAAD5EQAA/xEAAA4SAAAU EgAAIRIAACMSAAA6EgAAOxIAAEQSAABuEgAAcxIAAHoSAACEEgAAhRIAAIcSAACIEgAAnxIAAPsS AAD8EgAABhMAAAcTAAByEwAAcxMAAJcTAACYEwAAmxMAAKoTAACzEwAAvxMAAMATAADNEwAA1BMA AOATAAAQFAAAKxQAAC0UAAA6FAAAOxQAAEAUAABBFAAARhQAAEcUAABIFAAAWhQAAHIUAABzFAAA dBQAAIUUAACGFAAAiBQAAJsUAACgFAAArBQAAK4UAACwFAAAsRQAAPn0+fT59Pns+fT59Pn0+fT5 9Pn0+fT59Pn0+fT59Pn0+fT59Pn0+fT59Pn0+fT59Pnm4vna+dr59PnW4tDI5tbF4ry14sXiAAAA DUIqAk9KAABwaAAA/wAQQioCT0oAAG8oAXBoAAD/AAAET0oAAAAONQiBQ0oSAE9KAABvKAEACzUI gUNKEgBPSgAABzUIgU9KAAAPQ0oSAE9KAABSSMgAbygBB09KAABvKAEKNQiBT0oAAG8oAQAPQ0oS AE9KAABSSEEAbygBCENKEgBPSgAAAAtDShIAT0oAAG8oAQBHlRAAAPwQAABMEQAAkREAAOcRAABF EgAAoBIAAPgSAABhEwAAwBMAAA8UAAAQFAAASBQAAIYUAACvFAAAEhUAABMVAAArFgAALBYAADIW AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAA AAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA 4wAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAA AAAAAAAAAADKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAyQBYSQBAAUAAA3G BQABUwcADgAAD4RgCRGEeAUSZPAAAABHJABehGAJYIR4BQsAAA+EBQcRhHgFRyQAXoQFB2CEeAUA BAAAEmQsAQAABgAAEmTwAAAARyQABgAAEmTIAAAARyQAABOxFAAAtRQAAMAUAADMFAAAzhQAANYU AADYFAAA3hQAAPgUAAD5FAAAABUAAAEVAAAOFQAADxUAABEVAAASFQAAExUAAFcVAABYFQAAfBUA AH0VAAB+FQAAihUAAKAVAACiFQAAoxUAAKQVAAC9FQAAvhUAAMAVAADmFQAA5xUAAPoVAAAPFgAA ERYAABIWAAATFgAAKBYAACkWAAAsFgAALRYAAC4WAAAvFgAAMBYAADEWAAAyFgAA/fn9+fLp8vn9 +eny5N7W3v35/fnNycPJt82pzfn9zcnDyZ3Nqc35mJaRlozeAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQNq+yYAAFUIAQkDamkdAABVCAEDbygBCQNq rgEAAFUIARYCCIEDatMAAAAGCAE1CIFPSgAAVQgBABowSg8ANQiBPioAQioAT0oAAG8oAXBoAAAA /wAWAgiBA2oAAAAABggBNQiBT0oAAFUIAQAKNQiBT0oAAG8oAQAHNQiBT0oAABADagAAAAA1CIFP SgAAVQgBAA41CIFDShIAT0oAAG8oAQALQ0oSAE9KAABvKAEIQ0oSAE9KAAAAEEIqAk9KAABvKAFw aAAA/wAADUIqAk9KAABwaAAA/wAHT0oAAG8oAQRPSgAALTQAJlAJADGQEQEyUAIAH7CCLiCwxkEh sIYCIrC/AiOQegMkkKgCJbAAABewUwMYsOADDJCpAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCq AEupCwIAAAAXAAAAFwAAAGgAdAB0AHAAOgAvAC8AcAB2AHcALgBrAGEAaQBzAHQALgBhAGMALgBr AHIAAADgyep5+brOEYyCAKoAS6kLMAAAAGgAdAB0AHAAOgAvAC8AcAB2AHcALgBrAGEAaQBzAHQA LgBhAGMALgBrAHIALwAAANsAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABYAAABw AHYAQABwAHYAMgAwADAAMQAuAGsAYQBpAHMAdAAuAGEAYwAuAGsAcgAAAODJ6nn5us4RjIIAqgBL qQs6AAAAbQBhAGkAbAB0AG8AOgBwAHYAQABwAHYAMgAwADAAMQAuAGsAYQBpAHMAdAAuAGEAYwAu AGsAcgAAALsbAABEAGQAAAAAAAAAAgAAAAAAAAAAAAAAAABTB1MHQAJAAgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADwAE8DwAAACyBArwCAAAAAEEAAAACgAAQwAL8BgAAAAEQQEAAACB AREAABC/AQAAEAD/AQAACAAAABDwBAAAAAAAAIBiAAfwKxsAAAYGH6F26T4UPKdf/DOzh4STIv8A BxsAAAEAAADyAQAAAAB3AABuHvD/GgAAH6F26T4UPKdf/DOzh4STIv+JUE5HDQoaCgAAAA1JSERS AAAAfQAAAH0IAwAAALhenBcAAAABc1JHQgCuzhzpAAADAFBMVEX///+MjIyUlJQAAACcnJwYCFrv 7++9vb3n5+fOzs7Gxsatra3e3t739/dCQkIQEBB7e3tjY2MhISHGCCmlpaXGACHW1tZSUlK1tbUx MTFzc3MhEFqEhISMhK0ICAg5OTkpKSkYGBhaWlrGxtZSSoRKSkopGGOUjK1ra2u9EDFKQnv/7/et Qmvn5+9aUoQ5KWuUjJRCOXvvnK3OIUIxIWutpcZjUoy9tc5za4SEc6WUhIz3vc7WY3ucnKXnjKX3 ztbWUmvOKUrWQlrW1t6trbWlpa1KQnOclLVzY5x7QnP/3ufvrb3OOVLOEDGMjJxza5RjWoyMhJSE Y5Tnxs7GMVKcc3veY3vGIUK9GDnv5+fW1uelnL2tpb17c4ylnLVCKWvGvc6cjJS9c4zGY3u1MUre c4TOMUrn3t7e1ta1ra3ezs6UlKV7c6VrY5R7c5yEe6UxIWNjWnt7a5wxGGO9tcZ7Y5RzMWulMVrG lKWle4TelKW9Umu1IUKlUmPOUmvGSmPepa21a3OEhJyUjLVrY4xaUntSOXNKMWsxCFI5CFJKGFp7 UoS9pb21lLWcc5x7MWucY4yMQnOlY4yEMWOEIVrOvcbWxs6lUnuMIVLGhJy1UnOtIUrevca1IUq9 e4ytY3Pne5StOVLWrbW9a3vGGDnWc4S9Y3PGMUq1KULWa3ulY2vvpa0AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABY01yoAAAXnElEQVRoQ+1b5WMcR5bvrq7paia1pkHjmZFkyTLFdhzHicMMm2wYlpmZ bpmOmZkZ/8n7vfeqe0a2bMvevfu0FUWeaajHWE+O84t1NxwwkcFPeDev3v07fuT2WeetrTzbm8X/ D1gkuqw8r8qKAlT7TEFoIj0rF0AmK6K7p+m2b4Z95eV7M3P0g6Hul57X6PS2+9zFAwlAL/vbsDfV TQ4E7mL7W76iM2+7T461q268/JiPHms/R1deE6896s6KJstWJMbgtr9iS1JUXnk8VG8PH7Cv28sr ZtotgvHVHKrglus73fjO7eEc9YQ5gg6oPfR+5IbvgdBZcfhtwO/FKO5+JZnXDDz0ZwO8zI3A/BF6 70EIi5VofIGq89y9e8h4082rwb6SPl82drMiW1SLWSvf/CJ386lTTe1NXWsL1e+97O7FD8IHdiYl ZD+dC4B2J8uqHNxn0looRT93vIHMcLtTlX0v7O6a/DhfDvQ426x3eVkRjNiNQP0oh5C0PeQ7xO+s bPKdwLFEF15zV9LvvZ3DbovpZwjTfNnPis5qeUMsMINUMlV4RdYVw/cor+48AvjZvD6kMoCdJVpU q6iU0WVu2btoitakA4XlThrm0LgR5A07Hdr2yC8Q2Mh1eiAp57M4ryqRru82WekODwRukS09qxNF kW2XuT9gxo+Xo/rcHjA9Eead0NJZlS+KoKg67XTrLu+ovaZVpmemqfL1B2vvkCu6DQ4WeOrC5MJG EMgXFD7d2epVSi3oZ+XzmC997rqVnxy6qu8AvAUebpdl1nuWC+uaa2Z7h7ILxPt2dd9U5Hllxalh Jhwf/MD2vN8B5Ow6piVuBjfbFDH5+lq5Sh30ex0iezeE33RbjQwqlrOco9FxwY8yDzsv9/KwWnOX qca1MgadodKtMsZVsdIq0iqJEf+rgixyFW9Sd9bkVv2PB97vLKudroEzy4pwJD7p53PrzuFwAmVS 17ipMrUKWrdNHZPNvXI983G7cg41EE5oiga3W1k+SDB2Myh/6FjwfultuwkzNVE68JVx4jpwnalK auXTpbpODra9bLD0ItCdU89VbsTdFd5t075+vrJznfew2zDv+d28KgCwRWyJXDgXFTuBGwA6cHBq 7aSxq4JQRXHnlYJ/v/TzJqlMO7fcK+eHzeMGRsTeuofTM3JcxDDoceGDzDrQSQw/k+o6dWIgAF6k bkhfjVKaPZCuLLNLOGRvGc0HK/W75S05n+SCZjxzxaN3SwbeewtG26+h5gqk1UhdQTr+x9VIgRVK TbUSySaNDS0lVGi65rEtG2+GQsYaF+cIEjkLK6UENenmVnN8BzYGuRrCAKQL9FSFoVK1qhNd+9NY KbfPxc+XXXwoXGjvJuk4Pex69I5hL+k3mcUxzLeHdyIAMa6OiMNEukCHIsDsFGUbtetGITBL90TD s0GSoWF9aqqbxttAYkMlzsKvhI/aa2YUaqM4CjT0DfqllEmYdJY7jN9VrmkVnoLw7fYFOVffuvu4 qrI5pUm+qPBRa8EZQjJkKeI1tLfjGOOkdfyTH2ooPRFYT2vAa8MgCN0kakE3IaFbx1cRrI/3nvYM nj/XrDyKULkp743Yo4HHiBsqy4j12su0T9YEuN/7T+ZGxPvHKtauCyTiNvSN0iaIVKtgMTWsAcDh AIfQ4s/F0OMcv3jXI1Yl6UjglVmGZD3Jdgj4Aq5cKEjrnz7xGAV3Ug5fwrvIHcmdS9xwIwCG9QG4 C2wH8PWehUbxOjza5WnKymlZx55u106E7CqM4UkZdeX8z+l7nZqDVijKIXIn70cEg/eEmGojl6nV kncWiHkhSGoWZPmSG16/qsGfGw6Q/k7mJHOww7Spoc1CFyy4d/PH15gTWpg50C7fA/ESoRryHuUR qjMkwHlpjGbxJ0cRP5Iu9l7Os5QDjk9UhSqeMsOdn2y+8z7awpWMc4QesUq09BtmOSi+s5cDn9CG jtRjHh5FvCWdCUv1rIBYD8hlpIjggFJbPxb9w+bL7wEYmziN0H3iDPmdqQYb6jqWdMOtOvzO2PP7 S7G2I4i3pNcFP8DLCIsSliERBJ2CT793Y/NTzsDaQe4QBbOmdckj4J02IvzCeEo+xM+qIiqqIbMv CaNDKxOFX+TWx5C3kUshaQFJNIKviYEQwP/HNfvySLtjasdnFBkJ7SIphE766cwj44jL7GCMr+H1 /jZh9XCME23nuVhkMYcGw7vxfqLocDI6Ok/gTz8k4FfQp4g/OkoRcXBZwTkBug79Wm3faOBDHTLQ 34sZwB02qmCGB17jaq2mjo/tplbJIo0kSj39Lxubm48KdLG4hC7HrFMKEvAV0AIvFLngdk3H46yg Z7R32Ntvs0KEDbi0kPRip6r1dHhIS5iBUlGTon3k2xsbm49/PqAIG4QGoaWOglqeIeUPwKm6hhNA shGNOp6USVWWpB7pYaObDp4Gt3pGL/Fq+Feb50xhQWdxcWp9Sxs/vAnuv8WeVrcRE81qRnQnDF25 0IKApD/oeF2Ens+xydkZqjx+5UC0MEZl6kvLi40ycqVGJ9Ifu3z5ye//+0PMDcjj7U2Q/z1EGX6A 8R2cbkvQAyigQcwhhlgDD1EeOA3v2B5ifcWMN03kWh2x+GIPeIuEncfZJ0Evfp58+9/++w3HIeo3 H/7sKnVP2eJZRyKTRq5Gqhkx86xKO0UTOvGCiPPXWZ9wVuGwq7UKT+GIMXLjYHAtnyB66Wdzc/Py k/zxnbdG2okjvFTYtgpKZ50xrjTC6LSIDoAVfWzWahQtsDgXF38kzKAVxAhdQUQOXP+9Bb7BWMgv OD67oGCCsIbMo2gIRLgSi1qFfdI5PsNV2+NrTim4IbLrGUfDUJghC3mTW9cR9On8Yy8R5SQA/pcl 8anhOSNKguQSET5o4RfHpo1Ncnec/qBhuKG4fF7bnPPGFAYL1rl+O4yY3IDyVxNQpuiH4NlZiPsQ eHx7icyBsIQ6w9uolkwloTxjTCGtby3zvHFFU1aCT8Xz9V2JyojvVXsmimodRBQyKLjBibqqJrV6 lOgVqi0eg+NLXKQ3KvJjrqmxEaErKxYdZ49Z8JVsFK2RTM5t97rKpnaMDqqjaepO4ysnZD39tPx7 ZWPXXrny5mnyO7/7xZMnX7kaqF9+DlS3V+/fv+/+D0xP7krcE1LZzBNKXAwzerYYbhXiZpMdJHY2 k5RbEewNudqvXpjQ+upTuyf38e99X9v8w4/wld/8HXjah964fzL5rd/Yn1z6wIUT4P0HJlvPnro0 uTDZZa8ry5LK+sWaZRUdn3q2stDr9XbGnJcLsuAuk6f2tyZbv0YCuzrZ+hVVf3/z8snJ1uQbL2/+ 9LV4emmy9bXPRckJoHMKMtqffBSZ2KuTrV2nHQVfiDujfae8uRn9jbh+arspEbtcsEtPnc8SrPcS 805MPuhcDJx7X359azL5JXD9k38Gyu/nR1+ZTED7c5NLNWiut0B7NBaFsQi3yJA0iUceo2zHwND2 Agpyh/OvKat/SiXLScD6EG6/f/I8AguuP/Y68HmBtP/38OEqv5XeR7SfmZw0ykz1KUBPLg4kBNaE 62zPNlg9+69FY4buh8co+pB/EmvDaQpHcKL9gQj7n6HikZ4Bn7deAPDHL00m+xbGh4j2yeQCKhqd nAf0VfS3MAyOc1w5vRn5K1UE9K1IWRONh7qMUrpY2yr1JGA9MHUenDw1BLoTlvaP486vW+jP7IN2 XN/lcHdpF2Y0+pSONT3qjSvl6QjdFxFkji7Fz0arji9q8otxHN8Dzj8Q7E6eo7sst1O4QrQ/SPL/ 9IsMP36WaZ/sn6JHrp5fhy6k+v7U1ugO5/ZMKiNTFJFBrwRL274jfU5NjSSCOf/UhZOMG0Mnzj/4 0ublewDtDzZOs7ePnwZAWMdk8nXZ2ZEyhNZCvEtNtbj4NmtXltRV02K2nokxMHB+Mrt/8uo69C3o 2Nsv3Qdgfwke/CNBJwnCBHDp0vsZ2Irzdk8vz5qmoFuFBWJd3UEznLQUi2C12jpI/DOg6Hls+1Fc J2YEwVfw7StB8AYgbZ0j3X/yM8itcOPDRPvWZP+DPr64KHNlHQgwUO77rGbXQYfe7UhXdFYhZRoX isP4HtoS/5/BF6oW3Wuv4NsrrhuSyzvHPn/jrYt082OQBT08OaXci/jPrj2Gjp6AmS7Z/Q/QLed9 5PwVy3S4wdhaiyMaseWVUe74Bh0jFZ8w7Yg7P2Qpp+Qc8LMPc13jPFtTVPhZYjjKXUd7kw+nTLMl w5Ul0LHbFy5gzwvpqHUkd1LxLaGdIt7jEmsfFFSfQ0Ywat0eu3hTpAX1IrCGMJNI5sGZDX+yiiDQ uYpknX+OIJ0YLE68OtP++xTomPrLqO+xPoxgtDU5ue5txOIiPrhmudtsa3C5BkE8Zums7J2+EffY 3sMzZMupVO7kbYjzpBEnXnxioP70X32RNohJTSdjBo5LmSQwRJ2clV/v6xazg5xDUbiW3XP6zLR/ qN2lLb8k5csJkftnHgRGz0uGy3neuQu0f5QSpkOKT89Lp3q2N0M5yQweocsd0D40iA9VeWTF5GkR 48jst745+nlwPvgCEHoWb9/L6c7lzXOTT7xI9ewu0U5tVbtkSzrAXUgKO7a+BzSaZZowXtXaCQQT QFr3jHLOk5TPfIweOSWcD9p9fKBg+Ng7Gxt/+vXL5yZ/cvo9pGx40EEqapfxOGDigAWulK+NLWOb XJdevyP1c7PjBEbae9KhIeleQU3xPIF/L210Cmwg6Io+fPmhhx5yzr70N/vfOn1ucunlzX9Cob81 edBZJbVKnDcdTUqab0sIwohtMdBoATrihyqDJgTqQL6OeE5SvIq9zpMuf5Wgk9Z9Cb06F7q4tf8m 6ovNv/vGfT8C57de2Nh44uyVySQIuJrmJTn7tODd6dfKrtoxptlnI4/fs2K7OL1KQO95BJg9y14s jp9Bqre1/wDaWfEzMK+PfPvJN/9of//j0DqYxV9sbLx5H0hf5bSOHI0mGeKZzSqXA2LrOi5CET1M BfeIdI6gvkaBjT5+mT9gnSRf9H5GCVA/DsU7N3kVyPz2/uSedE3pEm5gUJu26KmPNDCDLw6NiwAH jGyM1hXU7Kqmj+zS+uYjrz3y3g9/dHf3mQ+eP89XdnefCi7SE1de3Z+cef1hcjh//a2XP/H6yZPP //ETPz47FHawWhG7cdzMHp0M58S4KvluSzMr1PAYmwsto+Jfo+5FfNH2ZNbtaM2b3QvJW5unKhNf /vWtUexLKRqrg1SKSCRvY7rrSL7rozNq813bXAiofiYtbdU16krLG6HtltHntcztb9+VEmvz3R/8 gEvMobtCCs6Gb9oQ5QpTZHNc4YhkN4GjG1u/2+Y8NwVTnLvxK7Y7OrQJroMexY9KXfvuNXTxU+fF 737nDVvh2XIl3EZaFTMi6xWDremKTk/tMaKteZ04QJsUfQBG0halvm0hMfRV9wA+8cXHubo9fe0R PjOipiavQchT49QL3mtN7IOW+bGD5qwUX7Z1iSM/VBNDH8AWpSsnss55bvJ85zQx/53PqdfQTBqA 67VyWcrsQxX6WFWhx1FKMSW9S1+6dZGlEKcvJPOVA12Djs4gbrV//jAx/9Pvi8dO8UhJMWBDDdTV Z2phiSY1eZEk4pyJ+KnSwnPbvIrVtAWF8PxpEhm4GmRSOo4S0m1xLSqNvvsEwD9xFgcKtoYc+s9d Ns5grVojAla6FzjUS/Idtj+8Y5T0t6gZIki0NToi3EtQdRxFOBlRYYTWCrI1lsqUuzXQvs1P43RW 0QwScrmxR6O2D6SFst4aEVh02W9i0zlyltgtFap3MVmfHUeAg88aTZkaLQLBynI+CEGpDlNHT6m1 5/iPb258UgcBDofpbEAaKAalWtcf3SO3owooaDIjJ6mGDrNaqzpMfILSDo16ABnr8tHeE9cQWk4t If09pzc+iRNLnJkmnoRr41Xc+yBabhiDsY1a3aCDW3SMbT/H0zbSoDMOtqo6YmbIif6KdrqEtiza ukwtVvSx/9r8ESGsuEGPNfXdjKMoMXp0gnaboZ2pyeCMTb7xDyeVWDidUFAj6V5Oxw7laO+4p8I0 hUKQ0qb4/c/vvo1PhRVxuANbqkXVK3Kqh9faeQXmm6RfTrMiMHfarlUqhUhVxCn62ryJ7AJ7CyCk RKFbrdFugaCeDh/9FJXDfD/JjMoX0h5YN/8Bh4F40y6ryJcDSxf+2RAt6B8Zha3BcjaDMWEb5A7G U2uYDqXgHGOgSOH57OdzsSWHzjd8O/azsoE1+i3xfg4tMVreKucQlw9vgz5Cq0KFw5aA6B5ZP3Ae jId9yNEAtXrwDpBZzTEU4KIjbYO146c16KPkcS20NZXTzcMQms7ct4NGhkAModvSzqcHmIAQRxXr Fo0/HGctrbGh+4I5gEAOBY8kHTpuD64SqMosrsQBdHloT1/hdmVzggFOpwH6ma2KEghJAhefxuIe pkFwKkzv2sT0II/DxttjqQ/mv0Y3fxzOh0E4mrKJDH/43bxH25c/T4UH6EniaBBeR8dx7cKhuy3b WejWdEKNribOh3EOuxxmreLGzYc5w4QEe+SS43eoCJym3wwHdB2CbiQ+hM/doXPo/GPIgz4S51M6 kaZJjAhn4/goz5rtgfIw00G47KR50WwPbvIGFLLxoCzsFn4pxuI3yHCtgdPMAXRa6dSeE4nW0Rmg osNfB1WeTYDyzjrERGa2xIHGt5g7SYbRsIwO6eGbBD8MKA7ODTJ19TSA6OXEd5i7QNi1xxgC3F0N 9XVhSaYmKeLND//5JVGskAyuHIUV59u2JkqEsaGa8uCDcJ5CKXQCTj0koZFvWZtpg/Mp55KaOdnN Bx/odjMXxwotgq2P9UCwkPHU1iUtxweIAGM2klmRlSd0FahJrZiPI5489QjRLKWMuy6y8r215VdD 55qmjDA6M7TYaTwVB4ugd8quPlYJ9e2JdpBOg0fkjTWyEQzgYjTHrsTrKEGRcfPIut3rga6+h0M3 zyAn0KWWHi5WWni5RIeA9D2tMedAnk+mbYAQR/O6zLy9sV0CDjZAuxStmQ4zRzeHvhrGwhkGEEBm MmYSO958RoadQgApqVmdosRUoY9xC4RyDH24GLNalQkuxjw08mRhu78cxsduAR3CGTIKklm5jJYj LWmx7XWU0WK+bZqSaQduqwNgMUX41XuYMJDwziszKRJASNK6rfz6qH4kFuXaUV2R+5hrG8M5HWXn yI90hDZ0iKwSP0a1oVvu4Y8HGpuD8q5JKP3BsuB/yGXfiubVvRF8UpK/6rt6nKWmh8yM/kyhqhZN treHn4pa611PM3/jSrLeUCqRauqy3wlwGkG1qk6BNoSm6jXqGUIYz4osyxb0089Wp44C3u97F1Ot 1HMXLTg+5cyuATzCZNf3GGW9g5X4Pgwm68N51VlnfWy2C5jVAG6DFhOJrs+z48zDp7qnUbzGD9Ew sJLGaPAxZT7QiDkhK8e4Ia+mEfx1Ea3r1Y3sgJT93pgsy9EGK5dDKTKMBt8B/8wYpHz6GwzqqkWZ 75XlTaWgG/KkSe9kvsnyoRCBBY8e4w7AJ510b2Rl8OM7DcY0fSgixifgv8xMOwmdehrMkwO5bNuh xn/jUKyVzB36lt3Wvd4Ep35t9l0foLNimkUPRTYQKUEMVZd08CY4Vm7QCck8eDYoSZLaIzdsi8nv OxT5ChfMco7k62wvdryQWm48G28oXlUYoY38zsOlqnUrk+bGzxx/cI4YsDyOpt5MIPSXD2u4N5J3 zg7oNzX5MjObbbvoaUc6254uFGTCQyWyMAS7cvo3A3HL6yZb/2MZCdcxcgTfJyvKw8LHsbUH/5JU SbOz7u4w2CqH+T/TOuIPb9ws28FItUGDt1S6116hy0HNLCy8hT+e+Hksgn+E7iQR0go55rhupT8/ 2LQzduuO/adnYYlh7rVI+3NggCk9r+ROyK1X6HZeNQ733e7p49/H374hhMuE4dEr5Rn62/0N3fEh Xvekz3+XmBWrYZLhgSQq5NZd+5bjIZXoHn+6QNO2WV/M8B+GRelvxrrGxvLjbfOzPOWbuCh6Si0W 2U6Bufr/Y5J/Flx/8e5RHPhfs5minhzlEdAAAAAASUVORK5CYIKSCQAARABkAAAAAAAAAAAAAAAA AAAAAAAAAAAAuAttCx8BeQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPCYAAAA sgQK8AgAAAABBAAAAAoAAGMAC/B0AAAABEEBAAAABcFQAAAABgECAAAAgQERAAAQvwEAABAA/wEA AAgAQwA6AFwATQB5ACAARABvAGMAdQBtAGUAbgB0AHMAXABXAG8AagB0AGUAawBcAEUAVQBSAEEA UwBJAFAAXwBTAEkARwBOAC4ARwBJAEYAAAAAABDwBAAAAAAAAIBiAAfwpggAAAYGaYe+kNp2oNnE 4G3KLQ/NuP8AgggAAAEAAACtHQAAAADvAQBuHvB6CAAAaYe+kNp2oNnE4G3KLQ/NuP+JUE5HDQoa CgAAAA1JSERSAAAAyAAAAMMIAwAAAPBBrm8AAAMAUExURQAAAIAAAACAAICAAAAAgIAAgACAgICA gAQEBPz8/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMDAwP8AAAD/AP//AAAA//8A/wD/ //////4bMToAAAABdFJOUwBA5thmAAAAAWJLR0QAiAUdSAAABQpJREFUeJzt2NsSozAIANA+6v// 8M7s7EaTAOEedOQp1Qqcqon1d74kfrsb8IoPUi1eCDmeFxBkd0+6mCHjZmWgZfwDh/ilj1e0Wten H7DNmj3HMfz6v3mTNXkS42+xaxwCccrFKdbGERCnVKxibewMSXV8EFbmREccJNkRBsl2REHSHUGQ fEcMZIMjBLLDEQUxZjAW/SBEzrT4IHTOd9zsr5l+37MgvgcikTi9odj99Ov2zmjz/5F/BgfJ3n+I F8As2fqf/X4irJKdr4P6C8p4eUVCFpJxr00SCiEl8z6TJBZC9AbtsEiCIWhvss28Qm0cAUEkohPF rdPGIRBQQrSrlcRDgN7IZpWSDMjY26JVnWQDZDU3FYZ0va3nWJUkBzI8Ha4KaCRJEOHzukKSBRH+ g5JL0iDtpAi+LMzexsEQWUglZSFSiQRiesyWh6ycACK5WX1CUo0NuWadmhIu5L+grIQJuSUsKuFB unQ1JSzIkKykhAMZU+XeJ36QOVNFyRoC5SkoWULgLPUkKwiao5pkASEypEuW/4/beIaQh9eSkJDF waUkFIRzOstIQMjRD+jk1gb5sbrQ2/iC/A9bbvegqpEQY27/oCfRNh4h1twBgVcjIObcEUEt0G3c Q+y5QwKrhkJkqfc/rWAQae7dksMDUkGCQRS590qcINufVg43yF7J4QjZKRknWvXNfqWzNigqdn9K RyHlJa1aexIxr+xz7pw4xmh7dM9aY26nNpnVOJBnzF0syMMkbfsMKS4RQEpLBJeWFpIjEUEKS0bH AlJWMjlWkJrrycxYQypKIMcaUk8COhiQahLYwYHUkiAOFqSSBHPwIHUkqIMJqfK0gjvYkBISwsGH FJBQDgFku4R0SCCbJbQjAeIlcYRslSwcMsi+9WTFkEJ2SdYOKWSPhOEQQ3ZIOA45JF/Ccigg2RKe QwPJlTAdKkjmGs91KCFpErZDC0mS8B1qSIpE4NBDEiQShwESLhE58iH8w9IgwRKZwwSJXBmFDCMk TiJ2GCFRErnDComRKBxmSIRE47BD/CUqhwPEW6JzeEB813ilwwfiKNE6nCBuErXDC+Ik0TvcIC4S g8MP4iCxOLZDjvHzfoh1PTExXCE2idHhCrFIrA5fiFbiEb6QjRJnSOjLRF5hJ4hcYi/Z1/WCiCke JY8QSOB7UU5RR0jce1FOTU9I2HtRTklXCFviVS8MwpS4lYuDcCR+xY5AyFriWOuIhCworpWOWIj/ WzhOqRDIAVv8qyRAjtESUiIHkhIfpFq8HwLPNeMde//ImpqwXdCRRPI5RxwE7HjVRbdflDwWMna8 aqLfL0oeDOmrYUAlBM6dC8E2Q8V4yVeQ/qdjQdAff+VDxnM7mRCo2B0C9DB9QCHQi+8wyFysc0A9 DLUICNBdHGTK0EOgM/UMyOCALzkmBPh6HAT56kJyzqcQLSSCDAXYkKkWnA/eSSTHMuStI3Qf4K5S EMKBPWOMxdDj4cNjHxpBBzrhsiDYoX43O1SKCekrEMnx4wIgYBl2Q3ByQB4PIa/T21fQlJEQaoVt zU0Q1DH1m3ZGhiZPoNaJr4VwnjvqAMY+kP7HI6dRrDfIAbGnlKEQYkLXQtCU6ZC5tW5BAB0LydS8 PwSfnKAmzuvexypDObtvREGGXXBn96sL6wF2z7+MEULHMq8mLBlPJaRanK+FPFRyzpBHSk4I8jjJ OcRv3PDU+CDV4oNUi9dA/gABxitpl2Y6RAAAAABJRU5ErkJgggMGAABEAGQAAAAAAAAAAAAAAAAA AAAAAAAAAADeA2UE+gPoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FoAAACy BArwCAAAAAIEAAAACgAAYwAL8DYAAAAEQQIAAAAFwRIAAAAGAQIAAACBAREAABC/AQAAEAD/AQAA CABpAGUAZQBlAC4AZwBpAGYAAAAAABDwBAAAAAEAAIBiAAfwVQUAAAYGkZJ53zJB5+PrjRao5W4X dv8AMQUAAAEAAAA/JwAAAADvAQBuHvApBQAAkZJ53zJB5+PrjRao5W4Xdv+JUE5HDQoaCgAAAA1J SERSAAAAQgAAAEsIAwAAAPOFoRIAAAADc0JJVAgICNvhT+AAAABgUExURf///+/v79bW3tbW1rW9 xqurq6WlpZStxpSUlIycrYiIiISEhHOMrXN7e2trc2tra1p7pVJrhFJja1JSUj4+PjlSazFjlC0t LSFKcxhKhBYWFg4ODghCewBKhABCewAAAOLII+0AAAABYktHRP+lB/LFAAAEV0lEQVR4nLWYi3Kr OAyG8aUxDiYx9ODFZ22//2Ou5AuYNAmQzrozHZHQL79+ScZp0/zvi3BOfknQ1hn+K4T2IQTLfkGQ DgjBD5/nwmyIy6tPCTQTQnCXzwjEFELw9iNLiY5/bbUBQ7yhnxKMFEJIlHPeUqLQAi20C84I5YLX ZxkSc5DKpWSksMA7x0ANRgyLnwPETp5gENSg5VoR5IE38jhBoQ05idIZVqjjDKJ8cKoQjMoMJw8z CBZB6vLxgpQedRJG5ogfVIea4EizxEEd0kENElYjddPw1RBMT+3oYGajAfKAF6vKoI73DG7jR1WF wNtFqHWAsjcM6fGmSgPmAQbbigES3fBq5rCYSeo2j6apoRb69NXc0tjOg9h0lIJ7qajbFPoULp9u ydz6+L4NmwVmmO0rcM8MYn7sYymJMK+ENOjB0YhwlTan0N/H4Wf5k9Sw3IY3cFdUCMLlqi9VXdeG lPx1Lp+z8V2KuwRphugJbciixPA5ObvakN9zxbdIIMqGtcEtVIEvjFw2u0xMfGRFn4qatZKAKFXW SwQy8nZWCtNmhC1mGoQnWzyNeyCuYe2PgvBtlsEnv9GXZKQ+CST3N2yddElEJ6z3XUawdvIR4njp gdh+XBlrBTNutlpSUhU83+enS64K5f3okOGq3hxE9JRSxikhUJ16fKNa76ZbQRDGu3H2m1TQGqOV 4FxwobSpm1bFNPw83lq29Bfj7S0a4sRDO1shfza4jRKAwMnaooRd+gmn5HFIwFjqHghTSqK/sE2P A6MbXfgxqoAgmxcsh8c0JtHVEoqpbWToDUM9IOY4fEC4PDvGgSFoqlOy+huxRVgsjJ/GxySWZMBU ZEi1QVBfE2B4gcCfE6IhjwxRb50zagAjO/76DLgw9DNEfNS7WMuXhCc6YG8qpzbcNL3b9NMrRl8z nDFmITgHBDBy53lWGGp7OIBaWxdsJLwH1Iy6Ty081R001KtivmDodV7wwOaCO6YhM244/IYnQwA2 hOjkUUJkQK87POmZGc6MMaVThMIIOHScc5yKcxoig7dpQ4WiRhbuUKcIDVkYaflE+Lrfv45DGO9n XxGwJ6/ff76v11OM0lxuTnNxb/79B34dzwUsTTL8jFtUg4i/f88gKkvHvMl9f/25Xr9PIIDRw47s /dSX/eF+v58ioB3wiDpfzo0M1o7j/gbxnsEv/cHhfKOD8d0tZru41rwRWiv4gQguew1XsqEqvbh3 AsfzL3y71j6tgcgSUZ6j/S+siGDK+3mC1VGZI0CEHB1DgIobBw8YXk4xIqBibmN0WIXulI6IeYAI XIEcBqX0/pf3oiKutiledCR5ceT/EEkFDnff9xztnDG6EPRihKjd/e5eVAycYtpwOWJEMZH5EqOj Xlh4iBkVE8FIx0RitMtQtRcTK17MbOmLXT/ZMLYw4+PtdhtuLWUpGjvGOoxucLLYzYTARBDCIGsG h388d6IBlMQI1y//y/V8/QfL0MLKntzkZQAAAABJRU5ErkJgggAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABQAEQAKAAEAaQAPAAMAAAAGAAAAAABOAABA8f8CAE4ADAACAFzUAMkAABQAAAAD JAMxJAA0JAA3JAA4JABhJAMkAEtIAgBPSgYAUEoGAF9IAQRhShgAbUgJBG5IEgRzSAkEdEgSBDQA AUABAAIANAAMAAQAHMipuiAAMQAAAA4AAQADJAEGJAFAJgBhJAEMAENKIABPSgcAUUoHAAAAUgAD AAEAAgBSAAwABAAcyKm6IAAzAAAAJgADAAMkAAYkARGEeAUxJAE0JAE3JAE4JAFAJgJXRLwCYIR4 BWEkABIANgiBS0gAAE9KAABQSggAXQiBAAAAAAAAAAAAAAAAIABBQPL/oQAgAAwACAAwrvi8IADo sn23IAAArjSvAAAAAAAAAAAAAAAAJgBVQKIA8QAmAAwABQBY1XTHfNPBuWzQAAAMAD4qAUIqAnBo AAD/AC4AVkCiAAEBLgAMAAkA9MW0xfi8IABY1XTHfNPBuWzQAAAMAD4qAUIqDHBogACAAAAAAAAy EgAABQAALAAAAAD/////AAAAAA4AAAA/AAAAaAAAAGkAAABqAAAAkQAAAN4AAAA8AQAAPQEAAPoE AAD7BAAAGgYAABsGAABPBgAAbQYAAJkGAADJBgAACAcAACMHAABqBwAAlgcAAMcHAADtBwAALAgA AGkIAACmCAAA0wgAAPMIAAAUCQAAXwkAAJAJAAC9CQAAvgkAAL8JAADrCQAA/gkAAGgKAACzCgAA CwsAAGELAAC0CwAA9wsAAEAMAACVDAAA/AwAAEwNAACRDQAA5w0AAEUOAACgDgAA+A4AAGEPAADA DwAADxAAABAQAABIEAAAhhAAAK8QAAASEQAAExEAACsSAAAsEgAANBIAAKkAAAAAMAAAAAAAAACA AAAAgJpAAAAAMAAAAAAAAACAAAAAgKkAAAABMAAAAAAAAACAAAAAgJkAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAA AACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACA AAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAA gKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkA AyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAA MAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgKkAAyAAMAAAAAAAAACAAAAAgJoAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgAAEAADlBwAAFhAAALEUAAAyFgAA DAAAABAAAAATAAAAFQAAAAAEAABoBAAAmQoAAL0NAACVEAAAMhYAAA0AAAAPAAAAEQAAABIAAAAU AAAAAAQAADIWAAAOAAAAfREAAKMRAAC9EQAA5hEAABISAAAoEgAAMhIAABNYFP8VjBNYFP8VhA8A APDwAAAAAAAG8BgAAAACCAAAAgAAAAYAAAABAAAAAQAAAAcAAABPAAHwsAAAAGIAB/AkAAAABgYf oXbpPhQ8p1/8M7OHhJMi/wAHGwAAAAAAAP////8AAO8BYgAH8CQAAAAGBmmHvpDadqDZxOBtyi0P zbj/AIIIAAAAAAAA/////wAA7wFiAAfwJAAAAAYGkZJ53zJB5+PrjRao5W4Xdv8AMQUAAAAAAAD/ ////AADvAWIAB/AkAAAABgZFqsrGBpqfEQcSWFlAu/Kh/wBdawAAAAAAAP////8AAO8BQAAe8RAA AAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAABgQAAA8AA/AwAAAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAA AAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEA AAAyEgAA//8GAAAADQBfAEgAbAB0ADQAOAAxADMAOAA2ADMANwAwAA0AXwBIAGwAdAA0ADgAMQAz ADgANgAzADcAMQANAF8ASABsAHQANAA3ADkANgA2ADMAMAA2ADEADQBfAEgAbAB0ADQANwA5ADYA NgAzADAANgAyAA0AXwBIAGwAdAA0ADgAMQA0ADAAMQA0ADMAOAANAF8ASABsAHQANAA4ADEANAAw ADEANAAzADkApBEAAKQRAAAUEgAAFBIAABQSAAAUEgAANBIAAAAAAEABAABABAAAQAUAAEACAABA AwAAQLIRAACyEQAAFRIAABUSAAAWEgAAFhIAADQSAAAAAAAAggAAAIkAAACdAQAApAEAAKAHAACr BwAAaQgAAHQIAACmCAAAsAgAANMIAADdCAAAzwkAANgJAAA6CgAAQwoAALcKAADACgAA6woAAPIK AAAUCwAAIAsAAD8LAABGCwAAZAsAAGgLAABpCwAAcQsAAJMLAACYCwAAmQsAAJwLAADdCwAA5AsA AOULAADpCwAA/wsAAAUMAABADAAARwwAAEgMAABMDAAAdAwAAHsMAACoDAAArgwAALcMAAC9DAAA ygwAANAMAADRDAAA1QwAAPwMAAADDQAABA0AAAwNAAAwDQAANw0AAFINAABXDQAAmw0AAKENAACu DQAAtg0AAPANAAD4DQAAeg4AAH8OAACADgAAhg4AAKAOAAClDgAAvw4AAMQOAADFDgAAyQ4AAOAO AADoDgAAAw8AAAYPAABhDwAAZw8AAGgPAAByDwAAwA8AAMkPAADmDwAA7A8AAC0QAAA1EAAANhAA ADkQAAA0EgAABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAAAAgEAAAPBAAAfhAAAIUQAAA0EgAABwAzAAcAMwAH AAAAAAA0EgAABwD//xQAAAAQAEgAeQBlAG8AbgAtAGMAaABlAG8AbgAgAFAAYQByAGsAZABDADoA XABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBzAFwAQQBkAG0AaQBu AGkAcwB0AHIAYQB0AG8AcgBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkA YwByAG8AcwBvAGYAdABcAFcAbwByAGQAXACQx9mzIAD1vGytIAAAyKXHUABWAFcALQBjAGEAbABs AGYAbwByAHAAYQBwAGUAcgAuAGEAcwBkABAASAB5AGUAbwBuAC0AYwBoAGUAbwBuACAAUABhAHIA awAXAEEAOgBcAFAAVgBXAC0AYwBhAGwAbABmAG8AcgBwAGEAcABlAHIALgBkAG8AYwAQAEgAeQBl AG8AbgAtAGMAaABlAG8AbgAgAFAAYQByAGsAFwBBADoAXABQAFYAVwAtAGMAYQBsAGwAZgBvAHIA cABhAHAAZQByAC4AZABvAGMABwAEyDCuBMiQx/WsWdWAvRcAQQA6AFwAUABWAFcALQBjAGEAbABs AGYAbwByAHAAYQBwAGUAcgAuAGQAbwBjABAASAB5AGUAbwBuAC0AYwBoAGUAbwBuACAAUABhAHIA awAXAEEAOgBcAFAAVgBXAC0AYwBhAGwAbABmAG8AcgBwAGEAcABlAHIALgBkAG8AYwADACTH7MXE yRkAQQA6AFwAUABWAFcALQBjAGEAbABsAGYAbwByAHAAYQBwAGUAcgAyADIALgBkAG8AYwAHAATI MK4EyJDH9axZ1YC9JwBEADoAXACJ1azAXABwAHYAMgAwADAAMQBcAFAAVgBXAC0AYwBhAGwAbABm AG8AcgBwAGEAcABlAHIALQBmAGkAbgBhAGwALgBkAG8AYwAGAHYAaQBzAGMAbwBtAB0ARAA6AFwA UABWAFcALQBjAGEAbABsAGYAbwByAHAAYQBwAGUAcgAtAGYAaQBuAGEAbAAuAGQAbwBjAAcABMgw rgTIkMf1rFnVgL0nAEQAOgBcAInVrMBcAHAAdgAyADAAMAAxAFwAUABWAFcALQBjAGEAbABsAGYA bwByAHAAYQBwAGUAcgAtAGYAaQBuAGEAbAAuAGQAbwBjAAcABMgwrgTIkMf1rFnVgL0kAEQAOgBc AInVrMBcAHAAdgAyADAAMAAxAFwAUABWADIAMAAwADEALQBjAGEAbABsAGYAbwByAHAAYQBwAGUA cgAuAGQAbwBjAAMAFVySDVhh3Nb/D/8P/w//D/8P/w//D/8P/w8QAGge5zFYYdzW/w//D/8P/w// D/8P/w//D/8PEADvBrY+Uk7iRf8P/w//D/8P/w//D/8P/w//DxAAAQAAABcQAAAAAAAAAAAAAJAB AAAAAAAACxgAAA+EkAERhHD+FcYFAAGQAQZehJABYIRw/k9KCQBRSgkAbygAAQBs8AEAAAAXkAAA AAAAAAAAAACQAQAAAAAAAAsYAAAPhCADEYRw/hXGBQABIAMGXoQgA2CEcP5PSgkAUUoJAG8oAAEA bvABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4SwBBGEcP4VxgUAAbAEBl6EsARghHD+T0oJ AFFKCQBvKAABAHXwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EQAYRhHD+FcYFAAFABgZe hEAGYIRw/k9KCQBRSgkAbygAAQBs8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhNAHEYRw /hXGBQAB0AcGXoTQB2CEcP5PSgkAUUoJAG8oAAEAbvABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAAL GAAAD4RgCRGEcP4VxgUAAWAJBl6EYAlghHD+T0oJAFFKCQBvKAABAHXwAQAAABeQAAAAAAAAAAAA AJABAAAAAAAACxgAAA+E8AoRhHD+FcYFAAHwCgZehPAKYIRw/k9KCQBRSgkAbygAAQBs8AEAAAAX kAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhIAMEYRw/hXGBQABgAwGXoSADGCEcP5PSgkAUUoJAG8o AAEAbvABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4QQDhGEcP4VxgUAARAOBl6EEA5ghHD+ T0oJAFFKCQBvKAABAHXwAQAAABcQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EyAARhDj/FcYFAAFo AQZehMgAYIQ4/09KCQBRSgkAbygAAQB38AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhCAD EYRw/hXGBQABIAMGXoQgA2CEcP5PSgkAUUoJAG8oAAEAbvABAAAAF5AAAAAAAAAAAAAAkAEAAAAA AAALGAAAD4SwBBGEcP4VxgUAAbAEBl6EsARghHD+T0oJAFFKCQBvKAABAHXwAQAAABeQAAAAAAAA AAAAAJABAAAAAAAACxgAAA+EQAYRhHD+FcYFAAFABgZehEAGYIRw/k9KCQBRSgkAbygAAQBs8AEA AAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhNAHEYRw/hXGBQAB0AcGXoTQB2CEcP5PSgkAUUoJ AG8oAAEAbvABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4RgCRGEcP4VxgUAAWAJBl6EYAlg hHD+T0oJAFFKCQBvKAABAHXwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+E8AoRhHD+FcYF AAHwCgZehPAKYIRw/k9KCQBRSgkAbygAAQBs8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAP hIAMEYRw/hXGBQABgAwGXoSADGCEcP5PSgkAUUoJAG8oAAEAbvABAAAAF5AAAAAAAAAAAAAAkAEA AAAAAAALGAAAD4QQDhGEcP4VxgUAARAOBl6EEA5ghHD+T0oJAFFKCQBvKAABAHXwAQAAABcQAAAA AAAAAAAAAJABAAAAAAAACxgAAA+EIAMRhHD+FcYFAAEgAwZehCADYIRw/k9KCQBRSgkAbygAAQBs 8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP5PSgkA UUoJAG8oAAEAbvABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4RABhGEcP4VxgUAAUAGBl6E QAZghHD+T0oJAFFKCQBvKAABAHXwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+E0AcRhHD+ FcYFAAHQBwZehNAHYIRw/k9KCQBRSgkAbygAAQBs8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsY AAAPhGAJEYRw/hXGBQABYAkGXoRgCWCEcP5PSgkAUUoJAG8oAAEAbvABAAAAF5AAAAAAAAAAAAAA kAEAAAAAAAALGAAAD4TwChGEcP4VxgUAAfAKBl6E8ApghHD+T0oJAFFKCQBvKAABAHXwAQAAABeQ AAAAAAAAAAAAAJABAAAAAAAACxgAAA+EgAwRhHD+FcYFAAGADAZehIAMYIRw/k9KCQBRSgkAbygA AQBs8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCEcP5P SgkAUUoJAG8oAAEAbvABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4SgDxGEcP4VxgUAAaAP Bl6EoA9ghHD+T0oJAFFKCQBvKAABAHXwAwAAAO8Gtj4AAAAAAAAAAAAAAAAVXJINAAAAAAAAAAAA AAAAaB7nMQAAAAAAAAAAAAAAAP//////////////////AwAAAAAAAAAAAP//AwAAAAAAAAAAAAAA AAAOAAAAPgAAAD8AAABoAAAAaQAAABoGAAAbBgAATwYAAJYHAACmCAAAvQkAAL4JAAA0EgAAAQAA AAIBAAACAQAAngEAAAIBAACWAQAAAAAAAAAAAAAIAAAAAgEAAAIBAAACAQAAlgEAAP9ADIABAAAA AAAAAAAAGPPeAAEAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAAAAAAAAMhIAAFAAAAgAQAAA//8BAAAA BwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAAC AP//AAAAAAoAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0A ZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAA AAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8B AAAAAAAAQQByAGkAYQBsAAAAOVaQAQAABAIHBQQKAgYHAgMAAAAAAAAAAAAAAAAAAAABAAAAAAAA AEEAbABnAGUAcgBpAGEAbgAAAEUmkAEAAAILBQICAgICAgSHAgAAAAAAAAAAAAAAAAAAnwAAAAAA AABDAGUAbgB0AHUAcgB5ACAARwBvAHQAaABpAGMAAAAtFpABgQACAwYAAAEBAQEBrwIAsPt812kw AAAAAAAAAJ8ACAAAAAAAga0cwQAAOxaQAYEDAgMGAAABAQEBAa8CALD7fNdpMAAAAAAAAACfAAgA AAAAABS81dAAAEIAYQB0AGEAbgBnAAAANyaQAQAAAgsGBAMFBAQCBIcCACAAAAAAAAAAAAAAAACf AQAAAAAAAFYAZQByAGQAYQBuAGEAAAA5EZABgQMCCwYAAAEBAQEBAQAAAAAABgkQAAAAAAAAAAAA CAAAAAAAdK28uQAARwB1AGwAaQBtAAAAOwaQAQIABQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAA AACAAAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAIAAEAHEIiBgAACADAABoAQAAAACN60aGjetGhmzc RkYCAAEAAAChAgAAAA8AAAEABwAAAAQAAxAgAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDAAAA AAAAAAAiABMAIQAlACkALAAuADoAOwA/AF0AfQCiALAAGSAdIDIgMyADIQkwCzANMA8wETAVMAH/ Bf8J/wz/Dv8a/xv/H/89/13/4P8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAWwBcAHsAowClABggHCAI MAowDDAOMBAwFDAE/wj/O/9b/+b/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCegNkABEBgYAyAAAAEAAZAGQAAAAZAAAAaxIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAAAAAAAAATKDUQAAAADfAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP//EgAAAAAAAAANACgAUAByAGUAbABpAG0AaQBuAGEAcgB5ACkAAAAAAAAACgBKAGEAZQB5AG8A dQBuACAAWQBpAAcABMgwrgTIkMf1rFnVgL0AAAAAAAAAAAAAAAAAAAAAAAAAABrwBgAAAAAAwAAA AAAAAEYGAAAA4IDpWgAAAADggOlaAAAAAAAAAAAAAAAA4IDpWuCA6VoAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAQAAABYAUFZXLWNhbGxmb3JwYXBlcjIyLmRvYwAAIwHK3AEAAAAAAAAAIwHK3AEAAAAA AAAAAAAAAAAAAAAAAAAAkL5PAGsAcgAQxU4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUA AgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAkAEAABIAAAABAAAAmAAA AAIAAACgAAAAAwAAALgAAAAEAAAAxAAAAAUAAADYAAAABgAAAOQAAAAHAAAA8AAAAAgAAAAAAQAA CQAAABgBAAASAAAAJAEAAAoAAABAAQAACwAAAEwBAAAMAAAAWAEAAA0AAABkAQAADgAAAHABAAAP AAAAeAEAABAAAACAAQAAEwAAAIgBAAACAAAAtQMAAB4AAAAOAAAAKFByZWxpbWluYXJ5KQBvAB4A AAABAAAAAFByZR4AAAALAAAASmFleW91biBZaQB5HgAAAAEAAAAAYWV5HgAAAAEAAAAAYWV5HgAA AAcAAABOb3JtYWwAIB4AAAAPAAAAwPyx4sD8wNqw+MfQus4AAB4AAAACAAAAMgCx4h4AAAATAAAA TWljcm9zb2Z0IFdvcmQgOS4wAABAAAAAAEbDIwAAAABAAAAAAAio1hPgvwFAAAAAANaIsYjhvwFA AAAAANaIsYjhvwEDAAAAAQAAAAMAAAChAgAAAwAAAAAPAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAA AAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5cAQAAGAEA AAwAAAABAAAAaAAAAA8AAABwAAAABQAAAKAAAAAGAAAAqAAAABEAAACwAAAAFwAAALgAAAALAAAA wAAAABAAAADIAAAAEwAAANAAAAAWAAAA2AAAAA0AAADgAAAADAAAAPoAAAACAAAAtQMAAB4AAAAm AAAASVNMLCBEaXYuIG9mIEVFLCBEZXB0LiBvZiBFRUNTLCBLQUlTVABFAAMAAAAgAAAAAwAAAAcA AAADAAAAaxIAAAMAAAD8CgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAA AA4AAAAoUHJlbGltaW5hcnkpAAwQAAACAAAAHgAAAAUAAADBprjxAAMAAAABAAAAAOwBAAADAAAA AAAAACAAAAABAAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAALUDAABB AAAApAEAABgAAAADAAAAVABuAAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8AAAAdAAAAbQBhAGkA bAB0AG8AOgBwAHYAQABwAHYAMgAwADAAMQAuAGsAYQBpAHMAdAAuAGEAYwAuAGsAcgAAAAAAHwAA AAEAAAAAAAAAAwAAAGUAZwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGAAAAGgAdAB0AHAA OgAvAC8AcAB2AHcALgBrAGEAaQBzAHQALgBhAGMALgBrAHIALwAAAB8AAAABAAAAAAAAAAMAAABX ABcAAwAAAC4WAAADAAAAAQQAAAMAAAABAAAAHwAAACgAAABDADoAXABNAHkAIABEAG8AYwB1AG0A ZQBuAHQAcwBcAFcAbwBqAHQAZQBrAFwARQBVAFIAQQBTAEkAUABfAFMASQBHAE4ALgBHAEkARgAA AB8AAAABAAAAAAAAAAMAAABLAAEAAwAAADAWAAADAAAAAgQAAAMAAAABAAAAHwAAAAkAAABpAGUA ZQBlAC4AZwBpAGYAAAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYA AAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAA ABUAAAAWAAAA/v///xgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAD+////LwAAADAAAAAx AAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA/v///z8A AABAAAAAQQAAAEIAAABDAAAARAAAAEUAAAD+////RwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAA AP7////9////UAAAAP7////+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAA BgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAALDyG7aI4b8BUgAAAIAAAAAAAAAARABhAHQAYQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXAAAA/iwA AAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADgACAAEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAC4AAABZHgAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBBgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYsAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+AAAAABAAAAAAAAAFAEQAbwBjAHUA bQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAAC AQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEYAAAAAEAAA AAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAIBAgAAAAcAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAGYAAAAAAAAATwBiAGoAZQBjAHQAUABvAG8AbAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAQD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAALDyG7aI4b8BsPIbtojhvwEAAAAAAAAAAAAAAAABAAAA/v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAA AEYUAAAATWljcm9zb2Z0IFdvcmQgua68rQAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50 LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------=_NextPart_000_0007_01BFE1E8.84DB73A0-- From rem-conf Thu Jun 29 12:35:50 2000 From rem-conf-request@es.net Thu Jun 29 12:35:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137jyG-0003Lm-00; Thu, 29 Jun 2000 12:27:32 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 137jyF-0003Lb-00; Thu, 29 Jun 2000 12:27:31 -0700 Received: from purple.east.isi.edu by bells.cs.ucl.ac.uk with Internet SMTP id ; Thu, 29 Jun 2000 20:27:24 +0100 Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id UAA19736 for ; Thu, 29 Jun 2000 20:27:52 +0100 Message-Id: <200006291927.UAA19736@purple.east.isi.edu> To: rem-conf@es.net Subject: Working group last call on RTP MIB Date: Thu, 29 Jun 2000 15:27:51 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a one week working group last call on the RTP MIB, draft-ietf-avt-rtp-mib-12.txt, for proposed standard. This revision addresses comments from the previous last call and IESG. Comments should be sent to the AVT working group's mailing list by 6th July. Thanks, Colin From rem-conf Thu Jun 29 15:31:17 2000 From rem-conf-request@es.net Thu Jun 29 15:31:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137mkf-00072d-00; Thu, 29 Jun 2000 15:25:41 -0700 Received: from boreas.isi.edu [128.9.160.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 137mke-00072T-00; Thu, 29 Jun 2000 15:25:40 -0700 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id PAA23270; Thu, 29 Jun 2000 15:25:38 -0700 (PDT) Message-Id: <200006292225.PAA23270@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2862 on RTP Payload Format for Real-Time Pointers Cc: rfc-ed@ISI.EDU, rem-conf@es.net Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 29 Jun 2000 15:25:37 -0700 From: RFC Editor X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2862 Title: RTP Payload Format for Real-Time Pointers Author(s): M. Civanlar, G. Cash Status: Standards Track Date: June 2000 Mailbox: civanlar@research.att.com, glenn@research.att.com Pages: 7 Characters: 12031 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-pointer-02.txt This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000629151846.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2862 --OtherAccess Content-Type: Message/External-body; name="rfc2862.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000629151846.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From rem-conf Thu Jun 29 22:45:19 2000 From rem-conf-request@es.net Thu Jun 29 22:45:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 137tTt-0006NZ-00; Thu, 29 Jun 2000 22:36:49 -0700 Received: from jprieto.cce.udp.cl [200.14.86.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 137tTs-0006ND-00; Thu, 29 Jun 2000 22:36:48 -0700 Received: from pjsaaa16 (05-051.dial.008.popsite.net [209.69.13.51]) by jprieto.cce.udp.cl (8.8.5/8.8.5) with SMTP id IAA04495; Thu, 22 Jun 2000 08:33:59 -0400 Date: Thu, 22 Jun 2000 08:33:59 -0400 From: getcruisefree16@indiatimes.com Message-Id: <200006221233.IAA04495@jprieto.cce.udp.cl> To: vacationnow9@excite.com Subject: FREE: 3 Day Trip to Paradise & Deluxe Hotel ... X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list


WEALTH IN THE NEW MILLENNIUM

The Internet and new technology are creating more 7 Figure ($1,000,000)
incomes than any time in history. If you feel you are not being paid what
your worth, please visit our web site. The information is FREE.

HUGE COMPENSATION AVAILABLE!
This is your chance to get in on the ground floor of the
Multi-Billion-Dollar Home Based Business Revolution.

PLUS, RECEIVE A COMPLIMENTARY GIFT WHEN VISITING OUR WEB SITE.

Click Here For FREE Vacation





To Be Removed from out list: Click here
From rem-conf Fri Jun 30 10:15:18 2000 From rem-conf-request@es.net Fri Jun 30 10:15:17 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1384Cd-0000Wc-00; Fri, 30 Jun 2000 10:03:43 -0700 Received: from smtprch1.nortelnetworks.com (smtprch1.nortel.com) [192.135.215.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 1384Cc-0000WP-00; Fri, 30 Jun 2000 10:03:42 -0700 Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Fri, 30 Jun 2000 10:22:31 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NZBMXSDK; Fri, 30 Jun 2000 08:20:23 -0700 Received: from egunduzhan (egunduzhan.us.nortel.com [47.184.48.130]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N70C6YAW; Fri, 30 Jun 2000 11:20:20 -0400 Message-Id: <3.0.1.32.20000630111842.009636e0@ZBL6C008.corpeast.baynetworks.com> X-Sender: egunduzh@ZBL6C008.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 30 Jun 2000 11:18:42 -0400 To: rem-conf@es.net X-Sybari-Space: 00000000 00000000 00000000 From: "Emre Gunduzhan" Subject: Re: I-D ACTION:draft-ietf-avt-rtp-g7221-00.txt In-Reply-To: <200006230334.EAA03552@purple.east.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I was not monitoring the list for a while, so my apologies if this issue has been raised before. I am a bit concerned about the "non-standard" rates mentioned in the draft. G.722.1 gives a bit-exact definition for only two rates, so the non-standard rates are not defined anywhere including this I-D. It is only mentioned that "the algorithm has the capability to run at any user specified bit rate", but which implementation of the algorithm and with what changes? Without a precise definition of running at these rates, I can not be sure that my G7221/16000 with bitrate=20000 will be compatible with someone else's. Regards, Emre Gunduzhan >This is to announce a two-week working group last call on the RTP Payload >Format for ITU-T Recommendation G.722.1 audio. If no significant comments >are received by 7th July we shall submit this draft for publication as a >proposed standard RFC. Comments should be sent to the mailing list, or >directly to the authors of the draft. > >Thanks, >Colin > > >--> Internet-Drafts@ietf.org writes: >>A New Internet-Draft is available from the on-line Internet-Drafts directories. >>This draft is a work item of the Audio/Video Transport Working Group of the IETF. >> >> Title : RTP Payload Format for ITU-T Recommendation G.722.1 >> Author(s) : P. Luthi >> Filename : draft-ietf-avt-rtp-g7221-00.txt >> Pages : 7 >> Date : 15-Jun-00 >> >>ITU-T Recommendation G.722.1 [2] is a wide-band audio codec, which >>operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. >>This document describes the payload format for including G.722.1 >>generated bit streams within an RTP packet [3]. Also included here >>are the necessary details for the use of G.722.1 with MIME [4] and >>SDP [5]. >> >>A URL for this Internet-Draft is: >>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g7221-00.txt > > From rem-conf Fri Jun 30 10:15:21 2000 From rem-conf-request@es.net Fri Jun 30 10:15:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1384IT-0000iY-00; Fri, 30 Jun 2000 10:09:45 -0700 Received: from ns.di.fct.unl.pt [193.136.122.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 1384IS-0000he-00; Fri, 30 Jun 2000 10:09:44 -0700 Received: from FACULDADF0QADT (gatekeeper.di.fct.unl.pt [193.136.122.225]) by ns.di.fct.unl.pt (8.9.3/8.9.3) with SMTP id SAA07801; Fri, 30 Jun 2000 18:16:52 +0100 Message-ID: <021001bfe2af$e9d04d40$3301000a@FACULDADF0QADT> Reply-To: =?iso-8859-1?Q?Miguel_Goul=E3o?= From: =?iso-8859-1?Q?Miguel_Goul=E3o?= To: Subject: CSMR 2001 call for papers Date: Fri, 30 Jun 2000 15:25:26 +0100 Organization: =?iso-8859-1?Q?Faculdade_de_Ci=EAncias_e_Tecnologia?= MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ns.di.fct.unl.pt id SAA07801 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Fifth European Conference on Software Maintenance and Reengineering Lisbon area, Portugal 14 to 16 March 2001 http://www.esw.inesc.pt/csmr2001 Call for Papers CSMR is the premier European Conference on Software Maintenance and Reengineering. Its purpose is to promote both discussion and interaction about maintenance and reengineering. Topics of interest include, but are not restricted to: * Maintenance and reengineering metrics and economics * Patterns languages for maintenance and reengineering * Experience reports on maintenance and reengineering * Maintenance and reengineering tools * Enabling technologies for maintenance and reengineering * Formal methods to support maintenance and reengineering * Software evolution and architecture recovery * System assessment for reengineering or maintenance * Migration and maintenance issues * Dealing with legacy systems towards new technologies One of the basic intentions of this conference is to offer an European forum for discussion and exchange of experiences among researchers and practitioners. Therefore, besides academics, we kindly invite all those in companies developing maintenance tools, offering reengineering services or going through legacy systems migration experiences to contribute by submitting papers or presenting innovative tools, solutions or experience reports. This conference is not limited to European participants. Authors from outside Europe are especially welcomed. SUBMISSIONS: Two types of submissions will be accepted: full length papers (not exceeding 4000 words in length and including a 150-200 word abstract) and short papers (not exceeding 2000 words in length and including a 75-100 word abstract). All papers should be in English. Authors are requested to submit electronically a PostScript or PDF version of their papers. In addition, they should send a separate file containing the title of the paper, full names, affiliations, postal and e-mail addresses, fax and telephone numbers of all authors. We encourage authors to make submissions through the web based submission system that will be available. For submission details please look at the conference web site. IEEE Computer Society Press will publish the CSMR=3D922001 Proceedings. Full papers exceeding 10 pages (4 pages for short papers) will be charged for pages in excess. Authors of accepted papers must sign the IEEE copyright form. At least one author of each accepted submission should register and present the paper at the conference. The official language will be English. IMPORTANT DATES: DEADLINE for submissions - Friday, September 15, 2000 Author's notification - Monday, November 20, 2000 DEADLINE for camera-ready of accepted papers - Friday, December 15, 2000 SPECIAL SESSIONS: Sessions of special interest proposed by delegates will be welcomed. Please send suggestions to the program chair before the submissions closing date. Program Chair: Pedro Sousa Lisbon Technical University (IST) & Link Av. D. =3DC1vila 23, 1000 Lisboa, Portugal. Phone: +351-21-3100124 Fax: +351-21-3100079 Email: pedro.sousa@link.pt Program Co-Chair: J=FCrgen Ebert Institut f=FCr Softwaretechnik University of Koblenz-Landau Rheinau 1, D-56076 Koblenz, Germany Phone: +49-261-287-2722 Fax: +49-261-287-2721 Email: ebert@uni-koblenz.de General Chair: Fernando Brito e Abreu Lisbon New University (FCT) & INESC R Alves Redol 9, 1000 Lisboa, Portugal. Phone: +351-21-3100263 Fax: +351-21-3145843 Email: fba@inesc.pt Web Chair: Miguel Goul=E3o Lisbon New University (FCT) & INESC R Alves Redol 9, 1000 Lisboa, Portugal. Phone: +351-21-3100263 Fax: +351-21-3145843 Email: miguel.goulao@di.fct.unl.pt Sponsors Chair: Mendes dos Santos Instituto de Inform=E1tica (Min. Finan=E7as) Email: mendes.santos@inst-informatica.pt Finance Chair: Paulo Gomes EUROCIBER Email: pagomes@eurociber.pt Local Arrangements Chair: Judite Delgado APESI Email: apesi@treal.pt CSMR Steering Committee: Lutz Richter, University of Zurich, Switzerland (Chair) Elliot Chikofsky, META Group, USA Franz Lehner, University of Regensburg, Germany Paolo Nesi, Universit=E0 degli Studi di Firenze, Italy Harry Sneed, SES GmbH, Germany Chris Verhoef, University of Amsterdam, The Netherlands ------------------------------------------------------------------------- Please take our apologies if you receive this information more than once! -- Miguel Goul=E3o Departamento de Inform=E1tica - FCT/UNL email: mg@di.fct.unl.pt Tel: 351 21 2948536 Ext: 0749 (DI) 351 21 2948300 Ext: 0749 (Geral) From rem-conf Fri Jun 30 11:36:25 2000 From rem-conf-request@es.net Fri Jun 30 11:36:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1385be-0004Yh-00; Fri, 30 Jun 2000 11:33:38 -0700 Received: from boreas.isi.edu [128.9.160.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 1385bd-0004YX-00; Fri, 30 Jun 2000 11:33:37 -0700 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id LAA12297; Fri, 30 Jun 2000 11:33:34 -0700 (PDT) Message-Id: <200006301833.LAA12297@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2862 on RTP Payload Format for Real-Time Pointers Cc: rfc-ed@ISI.EDU, rem-conf@es.net Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 30 Jun 2000 11:33:34 -0700 From: RFC Editor X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2862 Title: RTP Payload Format for Real-Time Pointers Author(s): M. Civanlar, G. Cash Status: Standards Track Date: June 2000 Mailbox: civanlar@research.att.com, glenn@research.att.com Pages: 7 Characters: 12031 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-pointer-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2862.txt This document describes an RTP [1] payload format for transporting the coordinates of a dynamic pointer that may be used during a presentation. Although a mouse can be used as the pointer, this payload format is not intended and may not have all functionalities needed to implement a general mouse event transmission mechanism. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000630113155.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2862 --OtherAccess Content-Type: Message/External-body; name="rfc2862.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000630113155.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From rem-conf Fri Jun 30 11:58:02 2000 From rem-conf-request@es.net Fri Jun 30 11:58:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1385uB-0005tO-00; Fri, 30 Jun 2000 11:52:47 -0700 Received: from smtprch1.nortelnetworks.com (smtprch1.nortel.com) [192.135.215.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 1385uA-0005tE-00; Fri, 30 Jun 2000 11:52:46 -0700 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Fri, 30 Jun 2000 13:22:04 -0500 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 30 Jun 2000 13:22:35 -0500 Message-ID: From: "Peter Barany" To: "'rem-conf@es.net'" Subject: Liaison Statement (LS) from ETSI SMG2 to IETF AVT Working Group Date: Fri, 30 Jun 2000 13:22:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFE2C0.299C5E18" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFE2C0.299C5E18 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE2C0.299C5E18" ------_=_NextPart_001_01BFE2C0.299C5E18 Content-Type: text/plain Hello, My name is Peter Barany and I work for Nortel Networks. I regularly attend ETSI SMG2 meetings and our current Work Plan includes the standardization of wireless Internet telephony for EDGE Phase 2 (what we commonly now call GSM/EDGE Radio Access Network or GERAN, for short). We are planning on using the GSM AMR speech codec along with the GSM FR, HR, and EFR speech codecs for this. On behalf of ETSI SMG2, I am forwarding the attached Liaison Statement to be presented/discussed at the upcoming IETF AVT Working Group meeting in Pittsburgh, PA (July 30 - August 4, 2000). The Liaison Statement discusses issues associated with the RTP payload format for the aforementioned speech codecs. I plan to attend the next IETF AVT Working Group and hope to discuss this issue with you. Thanks. Regards, Peter Barany TDMA-EDGE Standards Prime Nortel Networks +1 972 685-2471 +1 972 467-8346 (Mobile) +1 972 684 3775 (Fax) e-mail: pbarany@nortelnetworks.com <<2-001137.zip>> ------_=_NextPart_001_01BFE2C0.299C5E18 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Liaison Statement (LS) from ETSI SMG2 to IETF AVT Working = Group

Hello,

My name is Peter Barany and I work for = Nortel Networks. I regularly attend ETSI SMG2 meetings and our current = Work Plan includes the standardization of wireless Internet telephony = for EDGE Phase 2 (what we commonly now call GSM/EDGE Radio Access = Network or GERAN, for short). We are planning on using the GSM AMR = speech codec along with the GSM FR, HR, and EFR speech codecs for = this.

On behalf of ETSI SMG2, I am = forwarding the attached Liaison Statement to be presented/discussed at = the upcoming IETF AVT Working Group meeting in Pittsburgh, PA (July 30 = - August 4, 2000). The Liaison Statement discusses issues associated = with the RTP payload format for the aforementioned speech = codecs.

I plan to attend the next IETF AVT = Working Group and hope to discuss this issue with you. Thanks.

Regards,

Peter Barany
TDMA-EDGE Standards Prime
Nortel Networks
+1 972 685-2471
+1 972 467-8346 (Mobile)
+1 972 684 3775 (Fax)
e-mail: = pbarany@nortelnetworks.com
= <<2-001137.zip>>

------_=_NextPart_001_01BFE2C0.299C5E18-- ------_=_NextPart_000_01BFE2C0.299C5E18 Content-Type: application/zip; name="2-001137.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2-001137.zip" UEsDBBQAAAAIAMyNwSg2koAWohUAAABqAAAMAAAAMi0wMDExMzcuZG9j7F0NkBzVce7Z31tJJ92d QAhJwNMP0p24W+5OPwiZyHe6XymWdOhO4CJyYG537nbQ7s4yM3vSgZMSlMJPoFIyxI4roSrCZVwx YJdIMEklqRKmHCr/UK5QiSkbEHFiFzZEApfNry5fvze7N7u3eycJA7bZvuqZeW9e9+vu193vvdkZ 6blnG19+6PFlJ6kMtlGQzkzFKOKr04DthUIDUadXd2ZqaoqrrgRO1eDXCn768LfpFootwNA1nSiO LCBEdPoCooU0evPoze4V7hU0A2KhJZRaQ7SkW5N4umFmGz9MTS2a87oAn5PHJz3347P/utp5o4/D q5G5z6z2z3Fe4at/sAl1OF8aVeXzPevgE8A50aTKZ3OGMen+xUQ/Q1jdeSHRfSjfhfoLaSYU9C70 Vw5zyXeX1+/eOnUut2c533L6Al35me//Ec3kU17Wvf7LoXyc5hr3cn4sx2h4Wp4n6okewflEI9Hn K9CfL+xCfwiQYv9NUeVPXff+7T0v/8sJrVyPx3D/azh/CnRVVP8YoG9keIcYHukRw7sGOutHklZC XomOjg1XXdneXr9gl2G4ZnZcZC2xYXP9dlO3bdO9tVX023o2YYjOzrbOzWKXPik629G8e9zIJnWx wzUyW8WmVrE5vnFBff2I6aaNrSIW+8ywsLJi78iQ6MsmrCTztcbEwPAu0b1rr+ixkkaivn7YytsJ bl4qG8OItTW2o2+kX3RfNyKut+wDzGHAtvK5+voeKze5NbZhYGhIjAwPiOFucf3ARq7OunrCLbJj 5YaNhG24uj25VQzpVtqK73N0s8twHTM+ZqOb6ZamIxJ52zaybnpSJE0nkXcc7tNNGVINw6cG1+lJ PeeaE4bI5NOu2WbrriGaoVuLcHKGkUiJBOsYhyZozDr7q8VB3RFJY8JIWzkjKUYnJcu+vI2inhUj RtpIWJlMPmsmdNe0so4YdnWY2046YkfWcU03z92x9C1xUbGHFHoYNYyscDxK81b0NGbZchBQNd0i kbIcnCDFBjspBoysYcteYTLbRcFJmTkxZFs3GwlXNLPdWwRoWeQM83Yte7K0c+7GTZngNj7NzZl0 4CwOm8QSOdtwDBvmS5njqQLxLXk9bbqTIp9NGrbQxUEzaQh437ghrY4rJ2NiWMAsYWWTpjRNqxSk ioUdczwLtV3u0Jpgdtx4zEqnrYMYzK2ivn4vj5wcTSlmlQGDe+j+oS7ty3RTYovIoOCwpBhFT+cJ uB47zZhtZcBg1HSFJEejjfGrNokDozlH5HMsYEdnvFOWYaDekc9Wl6OolexWFxOWifCE55sTbLyk 4WKcMADN13X3tsiR9gYBdegXjoXhcRHmpgMf6tndInK6rWdAZoN53mZ5HTNtcNBDEdNKOnEhBrk8 bWslTQLOahvJfELZNZvPjBq2b6xcl73bdB0pRk5PHEDoVemDbQATm1kzk8+gQ1Z/2pC4CR9Nip7d fml1mNMYz6d1W5hZ1Ezo6arsOcD1dBoCcXQjV5jZvJV3St2qGZZvwQAMK5v3c09iOD+qQq66e8js ANZepVQ5pcO9k+bYmMFZheVIGDkXLs6aOKY3XFCMvcKwbctmO/cY6bRUyAsXYRzKpS20QDw5HKN5 mZbyWYOjRdGxc/OgswZsaOUCUp99fUOyal9fLzKFr8QRlIBcyh2zcvwSFhJgJTbSbWw7n+PxXDWt CVJlxnLcokLGKqk61OgumGJMmhCiW1m0xmghFYEJojPNlBA+qWf0cVSZY54VhG4bXudcrWQr7UdZ uNmIj8dbxYSpw3N69va0zJ1bWqEZWCa9xArW8KGEYbs6+vGL7I2fSpBF3T3fsvWkaZV5jpIlmTd4 SMd0OVckUno2a6R92aqFTeGPDjQuy1/wJ4vzn6d4wrQTedNtcxDuiRQosoZ7EBOiaDbjBnossXMh g5pZxHhGqVjWoTVh2JUZFzi38PjZmUKGkY7nYzgj4RYE5mxgZnJpI8P+XiKX4wshzm/KSjIXp41D 5qgppWans63RvINZx3EKM215sFVJ+Jyh0w7SBHTSR9OGnIT0XC5dnEMt0LHqEHOG7onysPPG0zb0 dJtrsgpwKSRaRxlQ5bJZ6FWYYuXA1qyyzJiemqVTlXflTaOGGOjb271bDA2LpJVhP80XVyblVuC8 iYTCmROcilN+iaeenfxOHjwRpWV9t/p0GTXSJtYwjgoiu3QebRVIpa1ySKt6ghjLZ2WCUU6bwcCz 7IX4TcJTupMqcDjXFKOLNbeR/0xbupqcOlg4FcT5XI7nN9Y7jXSTmFTqJwzkDdtp/fAGgxdW/fl0 uk0uKZr797a0ikE9PeaVB7nM9ujr34u1WzbFy+rkNEWLaD6YMmEoudZgOxlutRgoXWU6cg3olK5K iuGgzIHRmH0wvKXqtHWmDeKt39hR8l5gKStUd0TRzJ3xnf69sMLeac1LZGwRrC1chyNTHx/HyDuc 3psdFcNY9mLxt0G4xiGsWAxDLRPgI/qEbqZlE0yJvUbCkCsP3pkg3rATcOAeclz9433QyqeTIm0e kF6kOwekgJW3GaULRSRWw5FZZGt9/Q619oVInOe8EcKSImdIJZH0bddbBlVnr2bCgvngC8m0t7vY 298jkrY+5nqBhck9hwW63IXk9Mm0pcugRjJ2Ck45Y+gL1jdtgQjNqlVH2XgiXizuDIPg5MfGzITJ 6nAoYSM4bbV1jn9gPhKn+HR9/aB1EAFmOLOZMJfW5cJQLv3GdMSonK9Gked9g85dyL1iqcXLFfFG a6aRi4H/AbSp4H1yjyOFkCwwb2IFX1iIFYVzvFzqSSfn/VGDdUhaWYOXCGybeDGdYZhycFKzMP/J TCkXK9NGKmOOuN/hesIhsJAjORNz8s8hESdM3VVrs1kGQhEXdlhjCNNRTC9lBsfsgxgqbK0LCzvI nDZ104HiacPlsBk1ILjaT3Tnx3lKuKqto6NVxrZvWJWvsRxOysqJ1RvklkHPHhCTVj5ej43d3I9E alCDGtTgkwEhIgFcCbwSuAeYACaBB4BfAN4PfBD4deAjwMeB/wx8Fvgy8CfApjDRYuAFwAuBS6NE zVH11Ps4sC1GNAD8MRLwtxaq35bo3bfo9P+cfJFOvvjCyRf574WT/0X/If/+fU7Bf/Nh3vb1gVQd ZQdjIYpsrrt923qNglazFu3ZuZQG12shPlN0U93tfHGRPC+hPTsDdC0wA7LsYGNogb+SQqiuo7pC +VIe/4Wz+IDhjf8D3tg/CnwM+A3gN4H/5PkC+8HJUKkPHAQeAv5hhOgdv2Jv+gun/YX/8xde8xde 9Rd+VLXwA3/hP3+FCyWCltigeoEI1qx/JkzatxFSiKZFR5rCjUdef6dQFyQKrgnKY4C0FURag/qJ PhLkqnlraX4/mATJu6KLP6rxvxd4UXQ6L7QAH/Xlh8eBrbHpPDEI/N95GFzgvQuI7lug8saTwFVQ ajVwRyPRTuA3miAL8LbFRJ8HLkNuWQ58HXjqApVr3nvvrTdff/VHP6SK8EoBX3nFq3mJvv/C9ys3 /tghGGiicF2EYlq4LoxjMLCcwpFHpqamwpFHcYxGTuAYC9QFVlDkJVxSXaCBIq/xVTTyOt8LhgNB Cgfo6o9ybN73K1G98HbVO7+oeudDpKleOEt9zqfwk6p3XvIXYHgZyRFkgtZQ/TNRLaVpraFIoT5c Vk/acuIksejIdwIyLyybLWZK+q2eps+yUIOPAbTqPkIawjIi6LLjd8TF8We6Vx6/J7wKuProPeE1 R7Ohy48TzR/SaDXF2udsdNlcjWrwqwlNdAnNg5v8Di2SbysxrCHqOj0VkG8jRWg3WWRThnRKk3qj KcRry7o7SJOt7kCNoEEy0CJJJmVpHOUOakUdH1PyqFMOfwKlme3SODIPjcJrtMgaTbqrRou/eoou +OoTtCa5AOverrXUQD071/jXt3WDFOhqhEyDxMuhchk6JdcA3F9T/JgXK9i1VuM46AogFCIhcBW0 HT2sRNvtFTltQO0y4mVTQHE6BB4B5rElVOCxgnphmQ7w6CWOunIeG6Ut+A21JWg3b22QOXWtDTKX Y+ECl6W0DYu8bnDZVlGSTZI+DPqQopcRfSpYoF9C/RgzDfT9Fek3S00iRUuHC/qwpbvWhuuK9u2n 6Cx8rpJ8okU+kVI+kWk+W6mOeIy2VuSzRepTB32iSp/otD0INDG6vSrt1ZI2Bto6RVvHtO0RRXsN dXe9MfUQztyqF7RjoM7D21zQDuHaBo7LYw4jI6CpBc4u+WEjUtvpqTfkuEWKEhig4sX4IupAkCwi ufVqmt5lxenMHthOi8tW3GsbqJhzAF7cQKX7tGhoO51ZdHqqSdsuW9xAIzgvhdWwZl++tgt9NCVP oWr1Gu3iI29NLVb9rSoJBXjXFV0ardJapff1QZMk0EKvBnQbwfGQJwG/fbaZ1nd9hTo09ofGGa33 SmuxlgZqEzjysgFbTmh2Cbxiu9SsXlqMaSr3w1v8LbQW/Vyr8Tg3VWg/W0+rpP9xT1HqkaPkYux5 jDClYUyVux1Ce9iDnkYbjWztaeJXWLejXZImfRIJ2iG1NLwxPkoXYUZcobHD9qzR+p45zNPlDff1 rqWPDdoht0Z3aPyWdayCDmzVpdB9+sFALyyo0f0a55ymObVWObEe2z4E7aIjzwUaj7TzKm8jfE6j r2js5fMQG2lYm6OstOdl8Ks9O4NwuaB8unANDcPj/lK75iz75iwaoeVq9YmYHgL10xrH9vyK1J2y /QpaeGQwtqAkZhhWAhNAfus4pl6dlW+fx2iV73qgeF14o1n+AhBSu1Je/aq3nNVrz43ePa4rvJP8 WY3oc8C3gCF03YP18yDwAXR6DPg68BdAMR87JGAHFlxdQA1MG4BLgMuA/cB9wEVgfCnwzQb26xXn gAxZDx8CPgw8Cfwx8GfAJkiIfT+tA24H9gNvgqQ68OI6ovXA27Fnewj4JPAHkPaLkPRPgTthlscg 3X9DqtcaCtKFynCZ71wNp6Y47hfCiwwZ4zbx7KqybVaOcCd9Cvl4K+2nXbLci7FPIEdmPE9xcKcP fjAM/7kRx100AJobUdeLqz5cXQ9uB3DugOfuB20S1za4ZHDmmk5wasdfG1psxlwVRwvuY3apOpBB WKqD0veZ4qCUZQR97gLlfszLeVBbMmslcJ6QnJjaAZ8JmdEs5DNRQQIdbZJzSnA+dlmNyNqMe2ql xrzTNRt8ABv81i9RgrRsz7PbBCzqePMXS9YmJevA34bfAMl+uX5TLsHZ+M3HaZt5cj1pgc5C3/uk RiZd4dmkl/bgah/67KPfB+V+yKVa7KfPyHvdOA9793j+y2CtU723CL175Zsrv3tw4pWZH85odPry L3ZrFAtVurdN/7Oeave+tOyy327aM/Y2r7mCyPJh9BPFyhxTG303cfLaanTrfvcis5GiuFf+p8lH TBeVkwDmN/AzqJTWeOTLZy7kZ9dYse/ZqWFu18hqBlnbqfMm/esPSqqemJeBJD0O0iFFelyLaMWW WrBy+y6sr556X7bvCkS4UZy0Ik24Io1ak0maLaFI2KOJU2CaLlqJ7qZg45Fj70m6Y+FI1EcXx3BO 08Yq0J4CbYOiPRWMxMpo43AGH/38mfSHQ41HDr8r6Q+HIvMr0MfhTn4eJa9hSB4N4cYjp96RPBrC kfoqPOJyc+vj43dIyecY+Nz0TsEOi2bhE5cbXD+vxjJe7ZHGI8+9LXm1RyKNc/CKI1g+BNcLViAF CS+CW+TnmRy4fgIOSH+Zk4W/zMHsL3PC8Jc5SfjLlT4bVFD+BRXLFKRYnRZgS8RCfJ7qCh7WaDH0 Ynxv9beCrOJiT8/COVD4dJBX80cJluySC3EaWHIUTQKInnAoHAiG7rpVNjvsfdxFU955BNmUc72D /Lsb54PEe0tLPrfi9fIm8AlQOKwFtGgkUAyhQreSJx+GMXtkaFTmcqINa2Xv8yOhAEPV3rsxV5ik npB9epOkiQZjgUA4EKpK04M+8pJOzWdKaqzcofctdXcvJeJd0telgYJG39eyC/rvvO+GvjvnY1Yg cnDvrXr2F1YFlmq4BOcJtL6ujmvZdgV3XjkzPdXgrOHhyFPRJ+gJuEdTOzvMxcTPEC8GroOB/7Us n1aH7Cz3pqYKXwQuL65SRHGVIoo7H4GdjyX3Pg6lcMVPVFfLXZCCBVVXSJVXKDX4pMOZKX5CGaBy 4LTz8h/8+Rtv70k1PPqFOrpi3V99j59KHdPU16t8/8ukUv4xkj8q0ndI5eznSL6oIJ9L8BTBzyai HlPOghdo8okNNXu8Nmr81IloSOMnQUT7NfUlbUpTT2tcTT2hwTwin8rcranEzXl2McuhKTl+iM4v JfU19/QroX29A32+N0I7Nso2Mq2iDV9zH0P86ZjYrtt6dpLQvtgG9eXXLONufgs4HU9aLk0W6uS3 pIK/JVV1bJOODkrzNcu5y0zYlmONuSxOUmyJt5PTxXx3D+9gO8nruuf/WPzdCU1ej9bvuebvveuf Pnsbf1Uc9GThM88BfOZ5oJbia1CDGtSgBjWoQQ1qUIMa1KAGs0G1/T/XBJ7/t+cfjC9veOBPsP9v ffub/I5JuKxuhPfi3n6d96UpUnv0HKlnAHeTegZwlNTzSH5mwA/Ij5HaM/8Fqb38cVJ75L8hfluL 6ClS+/J/JMX7FJXu8ZkGe3DXSIvd6t+ncOQemJ+C8jnqnfkZndyHX1hHhV8uqp0vbVA6zPX8YEGD koXlYN3kP29FhZ250rGwHxdeLb9nxTTbvDJf8zOPG4d29N44sG9Hb1G7bpx3A2+jq2gj9aLcg7/t OLfJqx7wapO/CfbSBlxdjXabca1+K9wsj1tk+43UiXMn/R7VoAY1qEENalCDGtSgBjWoQQ0+6VDY i/J+lX+75z0772l5/8y/1fPv9LxP5T0y78N5T86/xfMen/fgvKfn3/D5/wDg9/75Xyrn/Tvv8ZeS ek9mGfF7LWpfzfvzS732gtRXHKuAq0l9wnE5cK13v5n4FTei9UD+5+f5yyZ+9ynu3X8f2OFdF7AG 5wb8jpwlv7bpk+9J8xvZ5wJLKKwVeLEPRWLqWdJT6na/PEZ/vuF7/3BCu+lLL8h/GZ2/Azrs0XfQ COk0Smky6HxgIbzXr8/cFOo5U9MSda3ep0rOeF/8bGEZBTSOmXPpnyG1Rp3DNCx7zch3tSblF1Nj VPjidvp7t2rQjP7Z4hy7Z9v/ZXzw3nwMz9D83OTZgv7P1f7r+OD1r8n3IPl99z3wgptnI6sITf8/ oP2gMgxUZpES/jCbILaCdiSUMASA80IOXn3oQAzoA0L+h6V7GI1NDSWA1PBHBiDHjJabIxcwAmOf mQuShtDLblD9jbZmzSU/uRR0uC64TeAbDBIDCoEzM4itB5PXs2D4YrmpEHuaGwWDBwAAUEsBAhQA FAAAAAgAzI3BKDaSgBaiFQAAAGoAAAwAAAAAAAAAAAAgALaBAAAAADItMDAxMTM3LmRvY1BLBQYA AAAAAQABADoAAADMFQAAAAA= ------_=_NextPart_000_01BFE2C0.299C5E18-- From rem-conf Fri Jun 30 12:01:24 2000 From rem-conf-request@es.net Fri Jun 30 12:01:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1385xp-0005yn-00; Fri, 30 Jun 2000 11:56:33 -0700 Received: from h-135-207-30-103.research.att.com (mail-green.research.att.com) [135.207.30.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 1385xn-0005yc-00; Fri, 30 Jun 2000 11:56:32 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 5FE511E00B; Fri, 30 Jun 2000 14:56:24 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA19846; Fri, 30 Jun 2000 14:56:23 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA25769; Fri, 30 Jun 2000 11:56:22 -0700 (PDT) Message-Id: <200006301856.LAA25769@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: c.perkins@cs.ucl.ac.uk Subject: Re: Working group last call on RTP MIB Cc: rem-conf@es.net Date: Fri, 30 Jun 2000 11:56:22 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The LAST-UPDATED clause was removed from the MODULE-IDENTITY between draft -11 and -12. LAST-UPDATED is not optional, so this MIB no longer compiles. Bill From rem-conf Fri Jun 30 14:04:03 2000 From rem-conf-request@es.net Fri Jun 30 14:04:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1387uL-0002t3-00; Fri, 30 Jun 2000 14:01:05 -0700 Received: from thalia.fm.intel.com [132.233.247.11] by mail1.es.net with esmtp (Exim 1.81 #2) id 1387uJ-0002st-00; Fri, 30 Jun 2000 14:01:04 -0700 Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with ESMTP id VAA29108; Fri, 30 Jun 2000 21:01:48 GMT Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 30 Jun 2000 14:00:54 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB20344B8DD@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Bill Fenner'" , c.perkins@cs.ucl.ac.uk Cc: rem-conf@es.net Subject: RE: Working group last call on RTP MIB Date: Fri, 30 Jun 2000 14:00:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Bill, >From http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-12.txt it looks like it is there to me... ? What are you seeing ??? rtpMIB MODULE-IDENTITY LAST-UPDATED "200006260000Z" -- 26 June 2000 ORGANIZATION "IETF AVT Working Group Email: rem-conf@es.net" CONTACT-INFO "Mark Baugher Postal: Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 United States Tel: +1 503 466 8406 Email: mbaugher@passedge.com Bill Strahm Postal: Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 United States Tel: +1 503 264 4632 Email: bill.strahm@intel.com Irina Suconick Postal: Ennovate Networks 60 Codman Hill Rd., Boxboro, Ma 01719 Tel: +1 781-505-2155 Email: irina@ennovatenetworks.com" Baugher, Strahm, Suconick Expires September 6, 2000 [Page 7] Internet Draft RTP MIB March 2000 DESCRIPTION "The managed objects of RTP systems. The MIB is structured around three types of information. 1. General information about RTP sessions such as the session address. 2. Information about RTP streams being sent to an RTP session by a particular sender. 3. Information about RTP streams received on an RTP session by a particular receiver from a particular sender. There are two types of RTP Systems, RTP hosts and RTP monitors. As described below, certain objects are unique to a particular type of RTP System. An RTP host may also function as an RTP monitor. Refer to RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' section 3.0, for definitions." REVISION "200006260000Z" -- 26 June 2000 DESCRIPTION "Initial version of this MIB. Published as RFC xxx." -- RFC-Editor assigns xxx ::= { mib-2 xxx } -- to be assigned by IANA Bill ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me > -----Original Message----- > From: Bill Fenner [mailto:fenner@research.att.com] > Sent: Friday, June 30, 2000 11:56 AM > To: c.perkins@cs.ucl.ac.uk > Cc: rem-conf@es.net > Subject: Re: Working group last call on RTP MIB > > > > The LAST-UPDATED clause was removed from the MODULE-IDENTITY between > draft -11 and -12. LAST-UPDATED is not optional, so this MIB > no longer > compiles. > > > Bill > > From rem-conf Fri Jun 30 14:07:54 2000 From rem-conf-request@es.net Fri Jun 30 14:07:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13880I-0003UU-00; Fri, 30 Jun 2000 14:07:14 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 13880H-0003UB-00; Fri, 30 Jun 2000 14:07:13 -0700 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 2C2184CE04; Fri, 30 Jun 2000 17:07:12 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id RAA26032; Fri, 30 Jun 2000 17:07:11 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id OAA26508; Fri, 30 Jun 2000 14:07:11 -0700 (PDT) Message-Id: <200006302107.OAA26508@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bill.strahm@intel.com Subject: RE: Working group last call on RTP MIB Cc: c.perkins@cs.ucl.ac.uk, rem-conf@es.net Date: Fri, 30 Jun 2000 14:07:10 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Oh, how embarassing. I modified my mib-extractor to try to deal with a certain style of footers and it decided that the LAST-UPDATED line in this MIB was a footer. Sorry for forgetting to check the pre-extracted copy! Bill