From rem-conf-request@es.net Sun Oct 1 04:50:19 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07191 for ; Sun, 1 Oct 2000 04:50:19 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13febr-0005Jx-00; Sun, 1 Oct 2000 01:36:35 -0700 Received: from www.sigmatel.it (relay.sigmatel.it) [194.91.230.161] by mail1.es.net with esmtp (Exim 1.81 #2) id 13febp-0005Jn-00; Sun, 1 Oct 2000 01:36:34 -0700 Received: from 207.36.161.230 (tsbrk1-230.gate.net [207.36.161.230]) by relay.sigmatel.it (8.8.5/SCO5) with SMTP id JAA02744; Sun, 1 Oct 2000 09:40:18 +0100 (cet) From: noriyuki@new-prodmail.com Message-Id: <200010010840.JAA02744@relay.sigmatel.it> Subject: Program Your Own Channels Date: Sun, 01 Oct 00 04:28:57 Eastern Daylight Time X-Priority: 3 X-MSMailPriority: Normal Importance: Normal To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list OPEN EVERY CHANNEL ON YOUR SATELLITE SYSTEM REGARDLESS OF THE TYPE OR BRAND WHY WASTE $400 - $600 $$$$$$$ BUYING AN AFTER MARKET CARD WHEN THEY AREN'T GUARANTEED TO STAY UP! WHEN YOU CAN PROGRAM YOUR CARD YOURSELF IN AS LITTLE AS 5-10 MIN. Unlock the full Potential of YOUR Satellite System ALL SPORTING EVENTS ALL PAY-PER-VIEWS ALL PREMIUMS ALL NBA ALL NFL FOOTBALL EVERY ADULT CHANNEL EXTRA HIDDEN CHANNELS 100'S OF CHANNELS. EVERY CHANNEL IS UNLOCKED VISIT OUR WEBSITE BELOW FOR MORE INFORMATION http://www.priprod.com/lucas/ From rem-conf-request@es.net Sun Oct 1 18:35:24 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12933 for ; Sun, 1 Oct 2000 18:35:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13frMZ-0003lK-00; Sun, 1 Oct 2000 15:13:39 -0700 Received: from (galaxy.uss-inc.com) [207.114.155.130] by mail1.es.net with esmtp (Exim 1.81 #2) id 13frMY-0003l9-00; Sun, 1 Oct 2000 15:13:38 -0700 Received: from quotepool.com (impacs.bc.ca [209.153.207.2]) by galaxy.uss-inc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TXYB4KR8; Sun, 1 Oct 2000 15:13:25 -0700 X-Mailer: Internet Mail Service [29.5.1754.73] (Solaris; Sparc10) Date: Sun, 01 Oct 2000 15:13:21 X-Accept-Language: en From: To: Subject: save on a 2nd mortgage or refinance... X-References: 0F6FF594D, 0BF817A8A Message-ID: <7fgc66tveml5vru.011020001513@quotepool.com> Content-Type: text/html X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

FREE NO OBLIGATION LOAN QUOTE
YOU COULD SAVE SUBSTANTIALLY!!!

For A Quick Quote Now
Click Here

WE SPECIALIZE IN THESE LOANS

Refinancing
Consolidating Debt
2nd Mortgage
Making Home Improvements

WITHOUT ANY OBLIGATION

COMPARE!
Fill out this 1 minute form and receive a custom quote
from some of the top loan sources in the country!

SAVE TIME!
Harness the power of the internet by submitting your
information instantly! Your quote is on the way!!

SAVE MONEY!
These companies spend less trying to get your
business, so you save on interest rates!

SATELLITE TV SYSTEM GIVAWAY!
The first 100 complete quote requests will recieve
a free DIGITAL SATELLITE SYSTEM!
(Name, Phone # and Email required fields)


From rem-conf-request@es.net Sun Oct 1 23:27:58 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17343 for ; Sun, 1 Oct 2000 23:27:57 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13fw8c-0001vx-00; Sun, 1 Oct 2000 20:19:34 -0700 Received: from mercury.internetsecure.com [216.98.32.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13fw8b-0001vn-00; Sun, 1 Oct 2000 20:19:33 -0700 Received: from 2RS5dD25f (sdn-ar-001calangP293.dialsprint.net [168.191.247.31]) by mercury.internetsecure.com (8.8.5/8.8.5) with SMTP id XAA22719; Sun, 1 Oct 2000 23:09:45 -0400 (EDT) From: mail.ru@mercury.internetsecure.com DATE: 01 Oct 00 8:20:49 PM Message-ID: SUBJECT: 100 minutes long distance for under a buck! To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Talk to Anyone, Anywhere in the U.S. for Less than a Penny per Minute. With our calling card you'll get the lowest long distance prices anywhere! No connection fees, or any hidden costs of any kind. We can offer this fantastic deal because of our high volume of repeat business. We deliver the highest value in the industry and, best of all, your satisfaction is absolutely guaranteed! For just $39 you get 3910 minutes to call anywhere in the U.S., any time. That's less than a buck for 100 minutes! Don't wait! This is the best deal going from one of America's most dependable telecommunication's companies. For your convenience we accept personal checks, cash, cashiers checks and money orders. CA residents please add 8.25% sales Tax. Mark your order then print the following form and mail to: SMARTEC 1626 N. Wilcox, Suite 590 Hollywood, CA 90028 ___$39 for 3910 minutes ___ $59 for 6000 minutes ___$49 for 4950 minutes ___ $79 for 8300 minutes Ship to: _______________________________________________ Shipping Address: _______________________________________ City: __________________________________________________ State: _________________________________________________ Zip Code: ______________________________________________ Your email: _____________________________________________ Your telephone: _________________________________________ Make all checks payable to: SMARTEC All orders are shipped within 48 hours. To be removed from our future mailing please email list2299@losangeles.usa.com and you will be removed instantly. From rem-conf-request@es.net Mon Oct 2 02:22:07 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02673 for ; Mon, 2 Oct 2000 02:22:07 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13fyrw-0005vn-00; Sun, 1 Oct 2000 23:14:32 -0700 Received: from research.gate.nec.co.jp [202.247.6.217] by mail1.es.net with esmtp (Exim 1.81 #2) id 13fyru-0005vc-00; Sun, 1 Oct 2000 23:14:30 -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 PAA08200; Mon, 2 Oct 2000 15:14:26 +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 PAA08365; Mon, 2 Oct 2000 15:14:23 +0900 (JST) Message-ID: <010601c02c38$01841d00$152c380a@dsp.cl.nec.co.jp> From: "Toshiyuki Nomura" To: "John Lazzaro" Cc: , References: <200009251800.LAA05183@snap.CS.Berkeley.EDU> Subject: Re: LATM specified in a public MPEG document? Date: Mon, 2 Oct 2000 15:14:20 +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 Content-Transfer-Encoding: 7bit Dear John and members, As you pointed out, it seems difficult to transmit SA data by LATM. I have forwarded this issue to MPEG Audio Experts and have not been received any objections. Therefore, I'll modify the I/D text so that SA data MUST NOT be handled by the LATM-based RTP specification, following the suggestion below: John Lazzaro wrote: > it sounds like the earlier suggestions I > made on the draft-ietf-avt-rtp-mpeg4-es-04.txt document about > Structured Audio issues, which made it into the current draft, > are inappropriate, since they assume the header described in > "4.1 RTP Packet Format" is meant for all audio, not only > "natural" audio. Perhaps the I-D should simply state that > Structured Audio isn't currently transportable over any of > the packet formats described in the document. The modified text will be published as draft-ietf-avt-rtp-mpeg4-es-05.txt. Best Regards, Toshiyuki Nomura, NEC ---------------------- From rem-conf-request@es.net Mon Oct 2 06:35:20 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04680 for ; Mon, 2 Oct 2000 06:35:19 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g2kE-0002oN-00; Mon, 2 Oct 2000 03:22:50 -0700 Received: from proxy2.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13g2kC-0002oD-00; Mon, 2 Oct 2000 03:22:48 -0700 Received: from rsf-laptop.live.com (dhcp0.live.com [208.184.148.170]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id DAA11071 for ; Mon, 2 Oct 2000 03:21:58 -0700 (PDT) Message-Id: <4.3.1.1.20001002024141.00baf550@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 02 Oct 2000 03:21:53 -0700 To: rem-conf@es.net From: Ross Finlayson Subject: Announcing: An open-source library for RTP/RTCP streaming Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [This is something that I've been promising people for a long time. I'm pleased to report that I finally have it in a releasable state. (Not perfect, but releasable..)] The C++ source code that forms the basis of my "liveCaster" (& "playRTPMPEG") media streaming tools is now available as "open source" (released under the LGPL). This code forms a set of libraries that can be used within RTP/RTCP streaming applications, and/or can be extended to support additional media types and codecs (in addition to MP3 audio). For a description of these libraries, and instructions for how to install and build them, see . You can use this code right now to build real applications - in fact, the distribution includes code for building two demo applications: (i) a server that reads a MP3 file and streams it (using RTP/RTCP), and (ii) a client that reads from the same RTP/RTCP stream, and outputs the resulting MP3 stream to stdout. These libraries can be built and run on Unix (various flavors) and Windows. (However, the demo applications mentioned above don't yet compile on Windows.) These libraries are similar to existing toolkits such as "Open Mash", although - for now, at least - not nearly as rich in functionality. Also, they do not require the use of a specific scripting language - or any scripting language at all. (However, the libraries can, and have, been used with scripting languages - e.g., "liveCaster" and "playRTPMPEG" were built using these libraries in combination with Tcl.) Once again, the URL for this code is . Ross. From rem-conf-request@es.net Mon Oct 2 09:24:31 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07636 for ; Mon, 2 Oct 2000 09:24:31 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g5Mq-0006bG-00; Mon, 2 Oct 2000 06:10:52 -0700 Received: from olympus.noc.uoa.gr [195.134.100.100] by mail1.es.net with esmtp (Exim 1.81 #2) id 13g5Mn-0006ay-00; Mon, 2 Oct 2000 06:10:50 -0700 Received: from Aragorn (Aragorn.noc.uoa.gr [195.134.90.37]) by olympus.noc.uoa.gr (8.10.2/8.10.2) with SMTP id e92DAfE25924 for ; Mon, 2 Oct 2000 16:10:41 +0300 (EET DST) Message-ID: <013501c02c71$9aa4ebc0$255a86c3@noc.uoa.gr> From: "Nikos Laoutaris" To: Subject: video frame arrival traces Date: Mon, 2 Oct 2000 16:06:40 +0300 Organization: University of Athens, Networks Operation Center MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0132_01C02C8A.BFC8F0E0" 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_0132_01C02C8A.BFC8F0E0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable Dear list members I am searching for traces of interarrival distributions or (better) = one-way delay distributions of streaming video, at the frame level. That = is, i would like to have a real measurement of the distortion of = interstream synchronization of a series of equally spaced frames (at the = source) as they travel over a (multi hop) network path. This information = is to be used for the evaluation of an adaptive playout controller for = packet video receivers. Thanking you in advance Nikos Laoutaris Communication Networks Laboratory National and Kapodestrian University of Athens, Greece e-mail : laoutaris@noc.uoa.gr tel. : +301 7275603 fax : +301 7275601 ------=_NextPart_000_0132_01C02C8A.BFC8F0E0 Content-Type: text/html; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable
Dear list members
 
    I am searching for traces of = interarrival distributions or (better) one-way delay distributions of = streaming=20 video, at the frame level. That is, i would like to have a real = measurement of=20 the distortion of interstream synchronization of a series of = equally=20 spaced frames (at the source) as they travel over a = (multi hop)=20 network path. This information is to be used for the evaluation of an = adaptive=20 playout controller for packet video receivers.
 
Thanking you in advance
 
Nikos Laoutaris
Communication Networks=20 Laboratory
National and Kapodestrian University of Athens, = Greece
e-mail :=20 laoutaris@noc.uoa.gr
tel. = : +301=20 7275603
fax : +301 7275601
------=_NextPart_000_0132_01C02C8A.BFC8F0E0-- From rem-conf-request@es.net Mon Oct 2 09:39:45 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07819 for ; Mon, 2 Oct 2000 09:39:45 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g5jO-00006b-00; Mon, 2 Oct 2000 06:34:10 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13g5jI-00006R-00; Mon, 2 Oct 2000 06:34:04 -0700 Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e92DY1t24002; Mon, 2 Oct 2000 15:34:01 +0200 (MEST) Received: from era.ericsson.se (rcur34ip54.ericsson.se [147.214.34.54]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id PAA26659; Mon, 2 Oct 2000 15:34:00 +0200 (MET DST) Message-ID: <39D88E7D.DFCD1BC7@era.ericsson.se> Date: Mon, 02 Oct 2000 15:32:45 +0200 From: Magnus Westerlund Organization: Ericsson Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie CC: rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hello, The payload format is designed with IP networks in mind. The problem we see is that IP is transported over a wide range of different links with different behavior, e.g. different radio and wireline links. Radio and wire do not have the same error characteristics. AMR will be widly used over wireless links and on these links bandwidth efficiency is extremely important. This lead to the bitwise sorting. Octet sorting needs octet alignement for each block of the payload, i.e. padding at the end of each block. Which we considered to be to expensive. The optional sensitivity sorting facilitates the use of different error robustness schemes. The need for different robustness enhancing schemes may depend on the application and the lower transport layers. The application can be for example conversational speech or streaming. Lower layers are here layer 1 and 2. Regards Magnus W. Qiaobing Xie wrote: > Magnus, > > Correct me if I am wrong, but I find hard to understand your reasoning. > > What you are saying is basically that, in order to make the current > payload format design general enough and flexible enough to be used "for > a wide range of networks and applications" and with "any mechanism that > exploit" unequal bit sensitivity, you've chosen to compromise the > implementation efficiency and performance (and even some functionality) > for AMR over RTP/whatever-partial-checksum-UDP/IP. > > I think it should be the other way around - the AMR payload design > should primarily focus on finding the optimal solution for > AMR/RTP/UDP*/IP. It doesn't sound right to me for IETF AVT WG to design > something that is meant for a wide range of networks but is > suboptimal/compromised (even functionally handicapped) for IP networks. > > Regards, > -Qiaobing Xie > > Magnus Westerlund wrote: > > > > Dear Qiaobing, everyone, > > > > The unequal error protection/correction scheme is not designed just for > > UDP-Lite. Any mechanism that can exploit the fact that the data is > > sorted in sensitivity order is possible to use, e.g. a partial FEC > > scheme based on the same techniques as RFC2733. > > > > We have made some design choices that makes the payload format flexible > > and bit efficient, i.e. usefull for a wide range of networks and > > applications. > > > > Best regards > > > > Magnus Westerlund > > > > Qiaobing Xie wrote: > > > > > Hello, everyone: > > > > > > I have some serious concerns on the design of the AMR payload format as > > > defined in . In brief, the design seems > > > very limiting in terms of taking advantage of the error tolerant > > > features built into the AMR codec algorithm. Also, it seems that not > > > enough consideration has been given to implemenation efficiency and > > > performance. > > > > > > Since my concerns are rather fundamental to the design, the email is a > > > little long, please bear with me.. > > > > > > 1) Basic idea > > > > > > The basic idea of the draft is to transport AMR frames over IP in an RTP > > > payload, i.e., AMR-frame/RTP/UDP/IP. I have no problem with that. > > > > > > Therefore, the packet *passed to the UDP layer* will contain three types > > > of bits: > > > > > > +--------------+ > > > | header bits | > > > +--------------+ > > > | Class A bits | > > > | and/or | > > > | other bits | > > > +--------------+ > > > > > > Here, the "header bits" will include all the AMR speech frame control > > > bits (ie., frame header), the RTP payload header bits, and the RTP > > > header bits. > > > > > > "Class A bits" is the most sensitive coded speech data bits, as defined > > > by the AMR codec. The "other bits" (also called Class B and C bits in > > > AMR terminology) are less sensitive coded speech data bits. > > > > > > 2) Problems with the current AMR payload format design > > > > > > The design in the current draft apparently was guided under the > > > misconception that the "Class A bits" of an AMR speech frame need to be > > > delivered error-free, and if that part of the frame is corrupted the > > > whole frame should be tossed. This is not correct. > > > > > > What the AMR codec really wants from the transport is: "if Class A bits > > > is found corrupted in a frame, raise a Bad Frame flag but still pass the > > > whole frame to the decoder since the decoder still may want to use Class > > > B and C bits to help error concealment." The purpose of the flag is to > > > tell the decoder that Class A bits are bad and do not use them. > > > > > > However, the draft seems to suggest on the use of a partial checksum > > > (such as the one provided by the proposed UDP-lite) to protect the > > > "header bits" AND the "Class A bits" at the transport leverl. This means > > > if Class A bits have any error, the whole packet will be tossed by the > > > transport. Even worse, if the packet is a compound payload, you will > > > have all the AMR frames tossed by the transport if a bit error occurs in > > > the Class A bits of any one of the enclosed frames. > > > > > > It becomes more problematic when, in order to support multiple AMR > > > frames in a compound RTP payload and to use > > > the partial checksum, a *very ugly* bit-wise shuffling scheme is > > > proposed to copy (bit by bit) all the "Class A bits" of each enclosed > > > AMR speech frame to the front of the packet!! The hugely computational > > > intensive operation is required no each RTP packet on both ends of the > > > RTP session. > > > > > > 3) A better way to do it: > > > > > > To get what AMR codec wants, we should only checksum the "header bits", > > > and carry an 8-bit CRC in the AMR frame header to cover the "Class A > > > bits" of the frame. This CRC is for the RTP receiver (that is above the > > > transport) to verify the integrity of the Class A bits and to raise the > > > Bad Frame flag before passing the AMR frame to the decoder. > > > > > > In other words, > > > > > > 1. Partial checksum at the transport level to cover all the "header > > > bits" -- if checksum fails, toss the whole packet. > > > 2. CRC in AMR frame header to cover the "Class A bits" -- if CRC fails, > > > raise the bad frame flag. > > > 3. No error checking on the "other bits". > > > > > > When bundling multiple AMR frames in one RTP packet (the compound > > > payload), we should use a table of contents (TOC) structure to avoid > > > bit-wise copying (AMR frames are bit-stuffed to byte boundary). and then > > > use the transport level checksum to cover the header bits and TOC bits > > > only (the Class A CRC of each AMR frame is in the TOC). > > > > > > +------------------+ > > > | RTP header bits | -- RTP and payload headers > > > +------------------+ > > > | Table of Contents| -- list of frame headers of the > > > +==================+ \ included AMR frames > > > | Fmr1 Cls A bits | \ > > > +------------------+ | > > > | Fmr1 Cls B bits | | > > > +------------------+ | > > > | Fmr1 Cls C bits | | > > > +==================+ | > > > | Fmr2 Cls A bits | > not covered by transport level chksum > > > +------------------+ | > > > | Fmr2 Cls B bits | | > > > +------------------+ | > > > | Fmr2 Cls C bits | | > > > +==================+ | > > > | Fmr3 Cls A bits | / > > > +------------------+ / > > > ..... > > > ..... > > > > > > This way, you get what the AMR codec asks for and yet avoid bit-wise > > > copying. > > > > > > =============================================================== > > > Qiaobing Xie, Ph.D > > > Principal Staff Engineer > > > Network Architecture & Technology > > > Motorola, Inc. > > > TEL: (847) 632-3028 > > > =============================================================== > > > > -- > > > > Magnus Westerlund > > > > Audio Technology, Ericsson Research > > ---------------------------------------------------------------------- > > Ericsson Radio Systems AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se -- Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se From rem-conf-request@es.net Mon Oct 2 13:17:56 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11225 for ; Mon, 2 Oct 2000 13:17:56 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13g93U-0004dA-00; Mon, 2 Oct 2000 10:07:08 -0700 Received: from audrey.enst-bretagne.fr [192.108.115.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13g93S-0004Zv-00; Mon, 2 Oct 2000 10:07:06 -0700 Received: from antares.enst-bretagne.fr (antares.enst-bretagne.fr [192.44.75.8]) by audrey.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e92H3Ro39908; Mon, 2 Oct 2000 19:03:31 +0200 Received: from pchoukair (pchoukair.enst-bretagne.fr [192.44.75.57]) by antares.enst-bretagne.fr (8.8.8/8.8.8) with SMTP id TAA07126; Mon, 2 Oct 2000 19:02:59 +0200 (MET DST) From: ddma-announcement@enst-bretagne.fr Message-Id: <3.0.3.32.20001002185642.00989790@antares.enst-bretagne.fr> X-Sender: choukair@antares.enst-bretagne.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 02 Oct 2000 18:56:42 +0200 To: ddma@enst-bretagne.fr Subject: DDMA workshop CFP Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_970498602==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_970498602==_ Content-Type: text/plain; charset="us-ascii" Dear Colleague, You are invited to submit a paper to the International "Distributed Dynamic Multiservice Architectures" (DDMA) Workshop. This workshop is in conjunction with the 21st International Conference on Distributed Computing Systems (ICDCS2001), one of the major conferences in the Distributed Computing Systems Area. DDMA workshop covers aspects concerning adaptive architectures and service composition and management. The submission deadline is November 1st. Further details are at the web site http://ddma.enst-bretagne.fr/. A text version is also in attachment. The DDMA workshop will be held in Phoenix, Arizona; April 16-19, 2001. [We apologize if you receive multiple copies of this announcement] --=====================_970498602==_ Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: attachment; filename="ddma-cfp.txt" Content-Transfer-Encoding: quoted-printable Call for Papers International Workshop on Distributed Dynamic Multiservice Architectures http://ddma.enst-bretagne.fr/ in conjunction with ICDCS2001 sponsored by IEEE Computer Society April 16 =96 19, 2001 Phoenix, Arizona, USA The growing need to integrate new services while complying with the= requirements of end=20 users puts strong emphasis on the management and combination of future= services and the QoS=20 they should be able to provide and guarantee. Dynamic Multiservice= Architectures constitute a=20 challenging paradigm for distribution theory and practice due to their= unique requirements in terms=20 of adaptability, behavioural integration, separation of concerns, service= composition and service=20 management. In particular, the deployment of multimedia telecommunication= services is a highly=20 challenging area where those paradigms should apply because advanced= services require that the=20 user's profiles, preferences and context be taken into account. "Distributed= Dynamic=20 Multiservice Architectures" hence add a new dimension to distributed= computing to help the=20 composition and deployment of new services guaranteeing final user's= requirements. The goals of this workshop are to bring together users and researchers to= present their=20 recent work related to diverse aspects of dynamic multiservice= architectures, their fundamental=20 issues, their paradigms and some appropriate approaches and experiments. The= workshop will=20 thus present opportunities for discussing further evolutions and their= expected benefits. Scope of Workshop ----------------- The scope of this workshop encompasses but is not limited to : Evolution of distributed multiservice architectures Separation of aspects and composition of aspects. Methodological approaches for aspect oriented programming. Components as cornerstones for dynamic composition. Composition requirements for reflection. Auto-adaptive ad hoc architectures and protocols. Impact on the management and control Management of adaptive architectures Management and monitoring of composed services. Platforms, tools, languages, ...=20 Languages, tools and platforms for auto-adaptive systems. Environments for specification and design of dynamic architectures. Experience with design, implementation and use of auto-adaptive systems. Application to telecommunication services Open critical issues in terms of composition of services. Panorama of QoS integration approaches for multimedia telecom services. Paradigms and requirements for telecom services architectures. Architectures for 3rd generation multimedia services. Distribution protocols for telecom (WAP, CORBA, CAMEL, mobile agents). Submission Instructions and Workshop Format ------------------------------------------- Interested participants should submit a 4-8 pages position paper that= focuses on one of the=20 relevant topics or related issues. Papers will be reviewed by the program= committee. Electronic=20 submissions should be sent to zied.choukair@enst-bretagne.fr. Mail body= should include name,=20 address, affiliation and a brief biography along with paper's title and= abstract. The workshop will follow the following format: The morning and part of the= afternoon will=20 be dedicated to presentations and discussions of accepted proposals,= including demonstrations of=20 existing software. The afternoon session will end with an identification of= issues, followed by=20 discussion. The organisers will then elaborate a summary of the workshop= based upon a summary=20 of the papers and the major outlined points of the discussion. Program Committee Members : Mehmet Aksit, Twente University, NL Zi=E8d Choukair, ENST Bretagne, FR Jaime Delgado, Universitat Pompeu Fabra, ES Byung-Guk Kim, University of Massachusetts Lowell, USA Marwan Krunz, University of Arizona, USA Abdul H. Sadka, University of Surrey, GB Antonio Rito Silva, University of Lisbon, PT Timothy K. Shih, Tamkang University, TW Katsuya Tanaka, Tokyo Denki University, JP Important Dates : Paper submission due : Nov 1, 2000 Notification : Dec 30, 2000 Camera ready : Jan 20, 2001 Conference : April 16-19, 2001 Web Pages : Conference URL : http://cactus.eas.asu.edu/ICDCS2001/ --=====================_970498602==_-- From rem-conf-request@es.net Mon Oct 2 14:39:23 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12264 for ; Mon, 2 Oct 2000 14:39:23 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gANV-00077q-00; Mon, 2 Oct 2000 11:31:53 -0700 Received: from hum.cari.net [209.126.133.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gANU-00077g-00; Mon, 2 Oct 2000 11:31:52 -0700 Received: (from httpd@localhost) by hum.cari.net (8.9.3/8.9.3) id LAA31236; Mon, 2 Oct 2000 11:32:18 -0700 Date: Mon, 2 Oct 2000 11:32:18 -0700 Message-Id: <200010021832.LAA31236@hum.cari.net> To: rem-conf@es.net Subject: ADV: Free Search Engine Placement Report - Get Yours Today From: "Doug Solomon" Organization: the Ad Network X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Comments: This advertisement is brought to you by the Ad Network Comments: www.adnetwork.cc Comments: Specialists in Inter-Networking and Promotions. Comments: Removal Instructions in plain text following message. X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ****************************************************************************** Complete list REMOVAL instructions outlined below message. ****************************************************************************** F R E E R E P O R T Is your website at the top of the major search engines? It needs to be! If it is not, you are missing out on serious amounts of web traffic and business! Did you know that 85% of web traffic originates from search engines? AND did you know that 98.2% of searches do NOT go past the third page of search results? (from the GVU 10th WWW User survey, Oct-Dec 1999) As a means of introduction we are offering you FREE a one time, no obligation, report of your website`s rank on the major search engines. You must know whether or not your website is achieving top rank on the major search engines. If you are not within the first 30 results you loose a distinct advantage over your competition. Obviously the higher the better. Click the link below and find out immediately if your website has the ranking that will make you money. http://www.adnetwork.cc/search-engine-free-report.htm If you have any questions or comments either before or after you have received your free report, please don`t hesitate to write us at info@adnetwork.cc Thank you for your time Your search engine Placement Specialists http://www.adnetwork.cc Creating Positive Solutions for Your Internet Business We apologies if you are not interested in internet traffic building technologies. E-mail is the fastest method of distributing this type of timely business information. If you wish to have your e-mail address removed from our business information update data base simply click on the hyperlink below: http://www.adnetwork.cc/removal.htm This message is being sent to you in compliance with the Federal legislation for commercial e-mail (S.1618-SECTION 301) This letter is not considered spam as long as we include contact information and a remove link. Doug Solomon Inter-Networking Promotions Specialist ****************************************************************************** Removal Instructions To unsubscribe from the Ad Network (www.adnetwork.cc) emailing list, please browse to the following URL: https://marketing.adnetwork.cc/removal.htm This page is secured by a 40 bit SSL Encryption for your protection and email privacy. You may list as many emails you wish to be removed from this and all sequent messages. We keep an extensive and complete database of removes that is cross referenced before any new promotions are broadcast. You may also email with "UNSUBSCRIBE" in the Subject Line: removes@adnetwork.cc This email is in complete compliance to Opt-Out mailing practices as stated in the Rules under California Business & Professions Code Section 17538.45 ****************************************************************************** From rem-conf-request@es.net Mon Oct 2 19:00:43 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15423 for ; Mon, 2 Oct 2000 19:00:42 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gEF6-0004qZ-00; Mon, 2 Oct 2000 15:39:28 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gEF4-0004qP-00; Mon, 2 Oct 2000 15:39:27 -0700 Received: from fokus.gmd.de (dhcp082 [195.37.78.210]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id AAA10539; Tue, 3 Oct 2000 00:38:48 +0200 (MET DST) Message-ID: <39D90E55.217B38D@fokus.gmd.de> Date: Tue, 03 Oct 2000 00:38:13 +0200 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kuthan@fokus.gmd.de Subject: iptel2001 Call for Papers Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by mailhub.fokus.gmd.de id AAA10539 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA15423 Call for Papers 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony are solicited. Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms, architectures, measurements, theoretical and/or analytical contributions) - Surveys, state-of-the-art studies, technology comparisons - Implementation and deployment reports - Standardization reports Particular areas of interest include, but are not limited to, the following: - Integration with Internet services (e.g., web, instant messaging, games) - Added-value services (e.g., call centers, conferencing) - Mobility and 3rd generation wireless - Authentication, authorization, accounting, charging, settlement - QoS support - Security (e.g., privacy, authentication, certification authorities, firewall traversal) - Call signaling & processing - Feature creation - Supporting services (e.g., call routing, lookup services) - Audio & video encoding and transmission - Management and provisioning - Interworking with the PSTN - Design and deployment considerations (e.g., performance, scalability, reliability) Important Dates --------------- Full paper due November 27th, 2000 Notification of acceptance January 12th, 2001 Final version due January 31st, 2001 Program published and February 5th, 2001 registration opens Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research K. Mehdi University of Kansas D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. Stüttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig Submission Instructions ----------------------- Authors are invited to submit full papers written in English before November 27th, 2000. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for submission of camera-ready copies is January 31st, 2001. Authors of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry. Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents cannot be accepted. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/ Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract, list of keywords, and contact information. One of the authors of each accepted paper must present the paper at iptel'2001. Contact Address --------------- Please, send all your inquiries regarding iptel2001 to iptel2001@egroups.com. From rem-conf-request@es.net Mon Oct 2 19:43:52 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15805 for ; Mon, 2 Oct 2000 19:43:51 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gF91-0006v3-00; Mon, 2 Oct 2000 16:37:15 -0700 Received: from (hhrhk.robertson.com.hk) [202.64.226.2] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gF8w-0006te-00; Mon, 2 Oct 2000 16:37:10 -0700 Received: from 202.64.226.2 (cranston-ip-1-238.dynamic.ziplink.net [209.206.4.238]) by hhrhk.robertson.com.hk (8.7.5/8.6.9) with SMTP id KAA18326; Tue, 3 Oct 2000 10:29:00 +0800 From: dont8@planet-mail.com Message-Id: <200010030229.KAA18326@hhrhk.robertson.com.hk> Date: Mon, 02 Oct 00 18:20:06 EST To: jhzk9@2s31hg.com Subject: They All Laughed at Me X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Now I am the one laughing! THE PROGRAM $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ INCREDIBLE $0 to $50,000 in 90 days!!! Dear Friend, You can earn $50,000 or more in next the 90 days sending e-mail. Seem impossible? Read on for details. "AS SEEN ON NATIONAL TV" 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, MONEY MAKING 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 'vebeen waiting for, THIS IS IT! Simply follow the instructions, andyour dreams will come true. This multi-level e-mail order marketingprogram works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized 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!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave somethought 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 get my money back. But like most of you I was still a little skeptical 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, my 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 made 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, 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 and 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, and 100+ 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 in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke 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 such a program, and one that is legal, could not have been created by an amateur. 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 thousands and thousands of programs. 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: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. 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 youdon't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF 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, 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 ALL INFORMATION, 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! 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 mail 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 justthat, 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 Advertising on the internet 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. CHECKS NOT ACCEPTED. -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. -- Make sure the cash is concealed by wrapping it in at least two sheets of paper. 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 Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: Becki Owens 30 Sea Star Court Dana Point, CA 92629 REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #2 FROM: Kristin Butler 32 McCullough Rd. Cody, WY 82414 REPORT #3 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #3 FROM: ADRP10 PO Box 7794 Athens, GA 30604-7794 REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet" ORDER REPORT #4 FROM: P. Drucker 1517A Rolling Glen Rd. Boothwyn, PA 19061 About 50,000 new people get online every month! ******* 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, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense--other than your initial $20 investment--is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW!Take your first step toward achieving financial independence. Orderthe reports and follow the program outlined above--SUCCESSwill be yourreward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your localoffice of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the InternalRevenue Service offers free help via telephone and free seminars aboutbusiness tax requirements. Your earnings are highly dependant on youractivities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ///////////////////////////////////////////////////////////////// Remove at derr9@goplay.com ///////////////////////////////////////////////////////////////// From rem-conf-request@es.net Mon Oct 2 19:54:12 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15869 for ; Mon, 2 Oct 2000 19:54:11 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gFKY-0000NX-00; Mon, 2 Oct 2000 16:49:10 -0700 Received: from (motgate3.mot.com) [144.189.100.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gFKS-0000NI-00; Mon, 2 Oct 2000 16:49:05 -0700 Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA12805; Mon, 2 Oct 2000 16:46:23 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA09556; Mon, 2 Oct 2000 16:47:15 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id SAA02874; Mon, 2 Oct 2000 18:48:51 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id SAA16501; Mon, 2 Oct 2000 18:48:51 -0500 (CDT) Message-Id: <200010022348.SAA16501@agevole.cig.mot.com> Date: Mon, 02 Oct 2000 18:49:07 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: Qiaobing Xie , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hi, Magnus, See my comments below.... Magnus Westerlund wrote: > > Hello, > > The payload format is designed with IP networks in mind. The problem we see is > that IP is transported over a wide range of different links with different > behavior, e.g. different radio and wireline links. Radio and wire do not have > the same error characteristics. AMR will be widly used over wireless links and > on these links bandwidth efficiency is extremely important. This lead to the > bitwise sorting. Octet sorting needs octet alignement for each block of the > payload, i.e. padding at the end of each block. Which we considered to be to > expensive. This further convinces me that the current design presented in the AMR draft is a radio-link-centric design, which is wrong in my opinion, because: 1) bandwidth efficiency over wireless links is more of a concern for ROHC working group. Architecturally, it should be delt with below IP by header compression/stripping, as being worked upon in rohc. It doesn't belong to RTP payload layer (unless it is something facilitating the underlying header compression/stripping). 2) AMR itself is not specfic to radio links, it is a general purpose codec. It is in the best interest of the AVT working group to define a *general* RTP payload format for carrying AMR speech over any IP connection, not something optimized for radio links only. This is why I am against the bitwise sorting - it may be inevitable for a radio link (even for radio links, it is expensive and often done at a lower layer by DSP or with hardware assistance), but it is a magnitude more expensive than byte-oriented handling to most applications running on a general purpose machine. > The optional sensitivity sorting facilitates the use of different > error robustness schemes. The need for different robustness enhancing schemes > may depend on the application and the lower transport layers. The application > can be for example conversational speech or streaming. Lower layers are here > layer 1 and 2. Since the bitwise sorting is so expensive, I think it is more than necessary that you justify it by showing exactly what "robustness echancing schemes" you have in mind and exactly how they would work together. Here you also brought out another concern of mine: the current design put no consideration on frame quality classification support (you would need CRC and bad frame indicator to do so, as I pointed out in my original email). Is this because you assume those functions are provided by "the lower transport layers", such as by the Iu-UP protocols defined in 3GPP? Unfortunately, in a general IP network, there is no such support from the transport layer. In order to make the AMR over IP work effectively over any IP connections (not only for a 3GPP Iu-UP interface), you will need to support those functions in your RTP payload format. regards, -Qiaobing > > Regards > > Magnus W. > > Qiaobing Xie wrote: > > > Magnus, > > > > Correct me if I am wrong, but I find hard to understand your reasoning. > > > > What you are saying is basically that, in order to make the current > > payload format design general enough and flexible enough to be used "for > > a wide range of networks and applications" and with "any mechanism that > > exploit" unequal bit sensitivity, you've chosen to compromise the > > implementation efficiency and performance (and even some functionality) > > for AMR over RTP/whatever-partial-checksum-UDP/IP. > > > > I think it should be the other way around - the AMR payload design > > should primarily focus on finding the optimal solution for > > AMR/RTP/UDP*/IP. It doesn't sound right to me for IETF AVT WG to design > > something that is meant for a wide range of networks but is > > suboptimal/compromised (even functionally handicapped) for IP networks. > > > > Regards, > > -Qiaobing Xie > > > > Magnus Westerlund wrote: > > > > > > Dear Qiaobing, everyone, > > > > > > The unequal error protection/correction scheme is not designed just for > > > UDP-Lite. Any mechanism that can exploit the fact that the data is > > > sorted in sensitivity order is possible to use, e.g. a partial FEC > > > scheme based on the same techniques as RFC2733. > > > > > > We have made some design choices that makes the payload format flexible > > > and bit efficient, i.e. usefull for a wide range of networks and > > > applications. > > > > > > Best regards > > > > > > Magnus Westerlund > > > > > > Qiaobing Xie wrote: > > > > > > > Hello, everyone: > > > > > > > > I have some serious concerns on the design of the AMR payload format as > > > > defined in . In brief, the design seems > > > > very limiting in terms of taking advantage of the error tolerant > > > > features built into the AMR codec algorithm. Also, it seems that not > > > > enough consideration has been given to implemenation efficiency and > > > > performance. > > > > > > > > Since my concerns are rather fundamental to the design, the email is a > > > > little long, please bear with me.. > > > > > > > > 1) Basic idea > > > > > > > > The basic idea of the draft is to transport AMR frames over IP in an RTP > > > > payload, i.e., AMR-frame/RTP/UDP/IP. I have no problem with that. > > > > > > > > Therefore, the packet *passed to the UDP layer* will contain three types > > > > of bits: > > > > > > > > +--------------+ > > > > | header bits | > > > > +--------------+ > > > > | Class A bits | > > > > | and/or | > > > > | other bits | > > > > +--------------+ > > > > > > > > Here, the "header bits" will include all the AMR speech frame control > > > > bits (ie., frame header), the RTP payload header bits, and the RTP > > > > header bits. > > > > > > > > "Class A bits" is the most sensitive coded speech data bits, as defined > > > > by the AMR codec. The "other bits" (also called Class B and C bits in > > > > AMR terminology) are less sensitive coded speech data bits. > > > > > > > > 2) Problems with the current AMR payload format design > > > > > > > > The design in the current draft apparently was guided under the > > > > misconception that the "Class A bits" of an AMR speech frame need to be > > > > delivered error-free, and if that part of the frame is corrupted the > > > > whole frame should be tossed. This is not correct. > > > > > > > > What the AMR codec really wants from the transport is: "if Class A bits > > > > is found corrupted in a frame, raise a Bad Frame flag but still pass the > > > > whole frame to the decoder since the decoder still may want to use Class > > > > B and C bits to help error concealment." The purpose of the flag is to > > > > tell the decoder that Class A bits are bad and do not use them. > > > > > > > > However, the draft seems to suggest on the use of a partial checksum > > > > (such as the one provided by the proposed UDP-lite) to protect the > > > > "header bits" AND the "Class A bits" at the transport leverl. This means > > > > if Class A bits have any error, the whole packet will be tossed by the > > > > transport. Even worse, if the packet is a compound payload, you will > > > > have all the AMR frames tossed by the transport if a bit error occurs in > > > > the Class A bits of any one of the enclosed frames. > > > > > > > > It becomes more problematic when, in order to support multiple AMR > > > > frames in a compound RTP payload and to use > > > > the partial checksum, a *very ugly* bit-wise shuffling scheme is > > > > proposed to copy (bit by bit) all the "Class A bits" of each enclosed > > > > AMR speech frame to the front of the packet!! The hugely computational > > > > intensive operation is required no each RTP packet on both ends of the > > > > RTP session. > > > > > > > > 3) A better way to do it: > > > > > > > > To get what AMR codec wants, we should only checksum the "header bits", > > > > and carry an 8-bit CRC in the AMR frame header to cover the "Class A > > > > bits" of the frame. This CRC is for the RTP receiver (that is above the > > > > transport) to verify the integrity of the Class A bits and to raise the > > > > Bad Frame flag before passing the AMR frame to the decoder. > > > > > > > > In other words, > > > > > > > > 1. Partial checksum at the transport level to cover all the "header > > > > bits" -- if checksum fails, toss the whole packet. > > > > 2. CRC in AMR frame header to cover the "Class A bits" -- if CRC fails, > > > > raise the bad frame flag. > > > > 3. No error checking on the "other bits". > > > > > > > > When bundling multiple AMR frames in one RTP packet (the compound > > > > payload), we should use a table of contents (TOC) structure to avoid > > > > bit-wise copying (AMR frames are bit-stuffed to byte boundary). and then > > > > use the transport level checksum to cover the header bits and TOC bits > > > > only (the Class A CRC of each AMR frame is in the TOC). > > > > > > > > +------------------+ > > > > | RTP header bits | -- RTP and payload headers > > > > +------------------+ > > > > | Table of Contents| -- list of frame headers of the > > > > +==================+ \ included AMR frames > > > > | Fmr1 Cls A bits | \ > > > > +------------------+ | > > > > | Fmr1 Cls B bits | | > > > > +------------------+ | > > > > | Fmr1 Cls C bits | | > > > > +==================+ | > > > > | Fmr2 Cls A bits | > not covered by transport level chksum > > > > +------------------+ | > > > > | Fmr2 Cls B bits | | > > > > +------------------+ | > > > > | Fmr2 Cls C bits | | > > > > +==================+ | > > > > | Fmr3 Cls A bits | / > > > > +------------------+ / > > > > ..... > > > > ..... > > > > > > > > This way, you get what the AMR codec asks for and yet avoid bit-wise > > > > copying. > > > > > > > > =============================================================== > > > > Qiaobing Xie, Ph.D > > > > Principal Staff Engineer > > > > Network Architecture & Technology > > > > Motorola, Inc. > > > > TEL: (847) 632-3028 > > > > =============================================================== > > > > > > -- > > > > > > Magnus Westerlund > > > > > > Audio Technology, Ericsson Research > > > ---------------------------------------------------------------------- > > > Ericsson Radio Systems AB | Phone +46 8 4048287 > > > Torshamsgatan 23 | Fax +46 8 7575550 > > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > -- > > Magnus Westerlund > > Audio Technology, Ericsson Research > ---------------------------------------------------------------------- > Ericsson Radio Systems AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se From rem-conf-request@es.net Mon Oct 2 21:48:01 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17849 for ; Mon, 2 Oct 2000 21:48:00 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gH0z-0003zP-00; Mon, 2 Oct 2000 18:37:05 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gH0r-0003yK-00; Mon, 2 Oct 2000 18:36:58 -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 KAA18910; Tue, 3 Oct 2000 10:36:21 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id KAA19861; Tue, 3 Oct 2000 10:36:21 +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 KAA17654; Tue, 3 Oct 2000 10:36:19 +0900 (JST) Received: from ave (kwa0106.mobile.toshiba.co.jp [133.120.199.22]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id KAA90983; Tue, 3 Oct 2000 10:36:08 +0900 (JST) Message-ID: <024601c02cda$592eb5e0$16c77885@ave> From: "Yoshihiro Kikuchi" To: "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "Yoshihiro Kikuchi" Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Tue, 3 Oct 2000 10:36:25 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0243_01C02D25.C7F165E0" 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_0243_01C02D25.C7F165E0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear experts, Attached find please a draft text for the revision of MPEG-4 Audio/Visual RTP Internet-Draft. The revisions are mostly to reflect suggestions by the AVT chair. Most of them are editorial and there are some minor revisions and clarifications. The following is a summary of the changes: (1) MIME subtype names were changed to "video/MP4V-ES" for video and "audio/MP4A-LATM" for audio. (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short video header mode was changed to "MAY" to "SHOULD". (3) Clarification of timestamp definition There was a suggestion not to describe the detailed definition of the video timestamp in the RTP spec. and change it as a reference to MPEG-4 visual document, so as to keep consistency with the MPEG-4 visual. A description about the RTP timestamp in the RTCP SR packet was added. (4) SA/TTSI over LATM A description was added to restrict the LATM usage so as not to transmit SA data by LATM. (5) Other editorial and wording changes. Please let us know if there is comment on the attached draft. The authors need to submit it soon as an updated I-D and hopefully final before RFC. Best regards, Yoshihiro Kikuchi and authors of the Internet Draft ---- 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_0243_01C02D25.C7F165E0 Content-Type: text/plain; name="draft-ietf-avt-rtp-mpeg4-es-05-Sep29.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mpeg4-es-05-Sep29.txt" Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Yoshihiro Kikuchi - = Toshiba Internet Draft Toshiyuki Nomura - = NEC Document: draft-ietf-avt-rtp-mpeg4-es-05.txt Shigeru Fukunaga - = Oki Yoshinori Matsui - = Matsushita Hideaki Kimata - = NTT September 29, = 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 each of = MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. 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 September = 2000=0D 1. Introduction The RTP payload formats described in this document specify how MPEG-4 Audio [3][5] and MPEG-4 Visual streams [2][4] are to be fragmented = and mapped directly onto RTP packets. These RTP payload formats enable transport of MPEG-4 Audio/Visual = streams without using the synchronization and stream management functionality = of MPEG-4 Systems [6]. Such RTP payload formats will be used in systems = that have intrinsic stream management functionality and thus require no = such functionality from MPEG-4 Systems. H.323 terminals are an example of = such a systems, where 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 MPEG-4 Systems Sync Layer. Other = examples are SIP and RTSP where MIME and SDP are used. MIME types and SDP = usages of the RTP payload formats described in this document are defined to directly specify the attribute of Audio/Visual streams (e.g. media = type, packetization format and codec configuration) without using MPEG-4 Systems. The obvious benefit is that these MPEG-4 Audio/Visual RTP payload formats can be handled in an unified way together with those formats defined for non-MPEG-4 codecs. The disadvantage is that interoperability with environments using MPEG-4 Systems may be = difficult, other payload formats may be better suited to those applications. 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 is 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. 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 bitrates = 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 = while utilizing the error resilience functionalities of MPEG-4 Visual. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 2] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D The fragmentation rule recommends not to map more than one VOP in an = RTP packet so that the RTP timestamp uniquely indicates the VOP time = framing. On the other hand, MPEG-4 video may generate VOPs of very small size, = in cases with an empty VOP (vop_coded=3D0) containing only VOP header or = an arbitrary shaped VOP with a small number of coding blocks. To reduce = the overhead for such cases, the fragmentation rule permits concatenating multiple VOPs in an RTP packet. (See fragmentation rule (4) in = section 3.2 and marker bit and timestamp in section 3.1.) 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, MPEG-4 Visual has 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.). Therefore, no extra RTP header = fields are defined in this MPEG-4 Visual RTP payload format. 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. 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. While LATM has several multiplexing features as follows; - Carrying configuration information with audio data, - Concatenation of multiple audio frames in one audio stream, - Multiplexing multiple objects (programs), - Multiplexing scalable layers, in RTP transmission there is no need for the last two features. Therefore, these two features MUST NOT be used in applications based = on RTP packetization specified by this document. Since LATM has been developed for only natural audio coding tools, i.e. not for synthesis tools, it seems difficult to transmit Structured Audio (SA) data and = Text to Speech Interface (TTSI) data by LATM. Therefore, SA data and TTSI = data MUST NOT be transported by the RTP packetization in this document For transmission of scalable streams, audio data of each layer should = be packetized onto different RTP packets allowing for the different = layers to be treated differently at the IP level, for example via some means = of differentiated service. On the other hand, all configuration data of = the scalable streams are contained in one LATM configuration data "StreamMuxConfig" and every scalable layer shares the = StreamMuxConfig. The mapping between each layer and its configuration data is achieved = by LATM header information attached to the audio data. In order to = indicate the dependency information of the scalable streams, a restriction is applied to the dynamic assignment rule of payload type (PT) values = (see section 4.2). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 3] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D For MPEG-4 Audio coding tools, as is true for other audio coders, if = the payload is a single audio frame, packet loss will not impair the decodability of adjacent packets. Therefore, the additional media specific header for recovering errors will not be required for MPEG-4 Audio. Existing RTP protection mechanisms, such as Generic Forward = Error Correction (RFC 2733) and Redundant Audio Data (RFC 2198), MAY be = applied to improve error resiliency. 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 RTP packets = without the addition of extra header fields or any removal of Visual syntax elements. The Combined Configuration/Elementary stream mode MUST be = 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]) The configuration information MAY additionally be = specified by some out-of-band means. If needed for an H.323 terminal, H.245 = codepoint "decoderConfigurationInformation" MUST be used for this purpose. If needed by systems using MIME content type and SDP parameters, e.g. = SIP and RTSP, the optional parameter "config" MUST be used to specify the configuration information. (see 5.1 and 5.2) When the short video header mode is used, RTP payload format for = H.263 (e.g., RFC 2190 or RFC 2429) SHOULD be used. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 4] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 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): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, = or if that is not done then a payload type in the dynamic range shall be = chosen by means of an out of band signaling protocol (e.g. H.245, SIP, 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. When multiple VOPs are carried = in the same RTP packet, the marker bit is set to 1. Timestamp: The timestamp indicates the composition time, or the presentation time in a no-compositor decoder. It is the same time instance as that conveyed in the timestamp field (modulo_time_base = and vop_time_increment) of the video stream. (See ISO/IEC 14496-2[2], = section 6 for the detailed definition.) A constant offset, which is random, = is Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 5] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D added for security reasons. The detailed definition of the timestamp = is as follows: - When multiple VOPs are carried in the same RTP packet, the = timestamp indicates the earliest of the presentation times within the VOPs carried in the RTP packet. Timestamp information of the rest of the VOPs are derived from the timestamp fields in the VOP header (modulo_time_base and vop_time_increment). - If the RTP packet contains only configuration information and/or Group_of_VideoObjectPlane() fields, the presentation time of the = next VOP in the coding order is used. - If the RTP packet contains only visual_object_sequence_end_code information, the presentation 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). Other header fields are used as described in RFC 1889 [8]. RTP timestamps in RTCP SR packets: According to the RTP timing model, = the RTP timestamp that is carried into an RTCP SR packet is the same as = the presentation time that would be applied to an RTP packet for data = that was sampled at the instant the SR packet is being generated and sent. = The RTP timestamp value is calculated from the NTP timestamp for the = current time which also goes in the RTCP SR packet. To perform that = calculation, an implementation needs to periodically establish a correspondence between the presentation time of a data packet and the NTP time at = which that data was sampled. 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. In the following header means one of the following: - 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()) - 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. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 6] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D (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) Different VOPs SHOULD 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), with the exception that multiple consecutive VOPs MAY = be carried within one RTP packet in the decoding order if the size of = the VOPs is small. Note: When multiple VOPs are carried in one RTP payload, the = presentation time of the VOPs after the first one may be calculated by the = decoder. This operation is necessary only for RTP packets in which the marker = bit equals to one and the beginning of RTP payload corresponds to a start code. (See timestamp and marker bit in section 3.1) (5) It is RECOMMENDED that a single video packet is sent as a single = RTP packet. 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. Note: Rule (5) does not apply when the video packet is disabled by = the coder configuration (by setting resync_marker_disable in the VOL = header to 1), or in coding tools where the video packet is not supported. In this case, a VOP MAY be split at arbitrary byte-positions. 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 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 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 7] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 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 packetized into a single RTP packet as in this example. (c) is an example of an 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 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. 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 packet is 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. (f) is an example of the case when the video packet is disabled by setting resync_marker_disable in the VOL header to 1. In this case, a = VOP may be split into a plurality of RTP packets at arbitrary = byte-positions. For example, it is possible to split a VOP into fixed-length packets. This kind of coder configuration and RTP packet fragmentation may be = used when the underlying network is guaranteed to be error-free. On the = other hand, it is not recommended to use it in error-prone environment = since it provides only poor packet loss resiliency. 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). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 8] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 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). Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 9] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 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) = | = +------+------+------------+------+------------+------+------------+ +------+------+------------+ +------+------------+ (f) | RTP | VOP |VOP fragment| | RTP |VOP fragment| |header|header| (1) | |header| (2) | ___ +------+------+------------+ +------+------------+ 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) = | +------+------+----------+ = +------+---------+------+------------+ Figure 3 - Examples of prohibited RTP packetization for MPEG-4 Visual bitstream Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 10] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 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 MUST be 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. When = SDP is utilized for this indication, MIME parameter "cpresent" = corresponds to the muxConfigPresent information (see section 5.3). muxConfigPresent: If this value is set to 1 (in-band mode), 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. If the useSameStreamMux bit indicates to use the = StreamMuxConfig from the previous frame, but if the previous frame has been lost, the current frame may not be decodable. Therefore, in case of in-band = mode, the StreamMuxConfig element SHOULD be transmitted repeatedly = depending on the network condition. On the other hand, if muxConfigPresent is set = to 0 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 11] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D (out-band mode), the StreamMuxConfig element is required to be transmitted by an out-of-band means. In case of SDP, MIME parameter "config" is utilized (see section 5.3). 4.2 Use of RTP Header Fields for MPEG-4 Audio Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, = or if that is not done then a payload type in the dynamic range shall be = chosen by means of an out of band signaling protocol (e.g. H.245, SIP, etc). = In the dynamic assignment of RTP payload types for scalable streams, a different value should be assigned to each layer. The assigned values should be in order of enhance layer dependency, where the base layer = has the smallest value. 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 the sampling instance of the first audio frame contained in the RTP packet. 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. Other header fields are used as described in RFC 1889 [8]. 4.3 Fragmentation of MPEG-4 Audio bitstream It is RECOMMENDED 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. 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. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 12] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D (In the following sections, the RFC number "XXXX" represents the RFC number, which should be assigned for this document.) 5.1 MIME type registration for MPEG-4 Visual MIME media type name: video MIME subtype name: MP4V-ES 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]. This parameter MAY be used in the capability exchange or session setup procedure to indicate MPEG-4 Visual Profile and Level combination of which the MPEG-4 Visual = codec is capable. If this parameter is not specified by the procedure, = its default value of 1 (Simple Profile/Level 1) is used. config: This parameter indicates the configuration of the corresponding MPEG-4 visual bitstream. It SHALL NOT be used to indicate the codec capability in the capability exchange procedure. = It is 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, if exist, which may vary in the repeated configuration information inside an MPEG-4 Visual stream (See 6.2.1 Start codes of ISO/IEC14496-2). Example usages for these parameters are: - MPEG-4 Visual Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=3D1 - MPEG-4 Visual Core Profile/Level 2: Content-type: video/mp4v-es; profile-level-id=3D34 - MPEG-4 Visual Advanced Real Time Simple Profile/Level 1: Content-type: video/mp4v-es; profile-level-id=3D145 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 13] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 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 = Profile. 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/announcement 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: Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 14] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D The authors of RFCXXXX. (See section 8) 5.2 SDP usage of MPEG-4 Visual The MIME media type video/MP4V-ES 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-ES) 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" and "config" go in the "a=3Dfmtp" line to indicate the coder capability and configuration, respectively. 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 media representation in SDP: Simple Profile/Level 1, rate=3D90000(90KHz), "profile-level-id" and "config" are present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V-ES/90000 a=3Dfmtp:98 profile-level- = id=3D1;config=3D000001B001000001B5090000010000000120008440FA282C2090A21F Core Profile/Level 2, rate=3D90000(90KHz), "profile-level-id" is = present in "a=3Dfmtp" line: m=3Dvideo 49170/2 RTP/AVP 98 a=3Drtpmap:98 MP4V-ES/90000 a=3Dfmtp:98 profile-level-id=3D34 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-ES/25 a=3Dfmtp:98 profile-level-id=3D145 5.3 MIME type registration of MPEG-4 Audio MIME media type name: audio MIME subtype name: MP4A-LATM Required parameters: rate: the rate parameter indicates the RTP time stamp clock rate. = The default value is 90000. Other rates MAY be specified only if they = are Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 15] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 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 [10]. This = parameter indicates which MPEG-4 Audio tool subsets the decoder is capable of using. If this parameter is not specified in the capability = exchange or session setup procedure, its default value of 30 (Natural Audio Profile/Level 1) is used. 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). If not specified, the default value is 1. config: a hexadecimal representation of an octet string that = expresses the audio payload configuration data "StreamMuxConfig", as defined = in ISO/IEC 14496-3 [5] (see section 4.1). 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 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 Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 16] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 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-LATM 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-LATM) 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-LATM/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), Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 17] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D m=3Daudio 49230 RTP/AVP 96 a=3Drtpmap:96 MP4A-LATM/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-LATM/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-LATM/90000 a=3Dfmtp:96 object=3D2; 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. The complete MPEG-4 system allows for transport of a wide range of content, including Java applets (MPEG-J) and scripts. Since this = payload format is restricted to audio and video streams, it is not possible = to transport such active content in this format. 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. Kikuchi/Nomura/Fukunaga/Kimata/Matsui [Page 18] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 2000=0D 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:1999/COR1:2000, "Information technology - Coding = of audio-visual objects - Part2: Visual, Technical corrigendum 1", = August 2000. 10 ISO/IEC 14496-1:1999/FDAM1:2000, December 1999. 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 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 19] =0CRTP payload format for MPEG-4 Audio/Visual streams September = 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_0243_01C02D25.C7F165E0-- From rem-conf-request@es.net Tue Oct 3 02:32:04 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03748 for ; Tue, 3 Oct 2000 02:32:03 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gLS2-0001p8-00; Mon, 2 Oct 2000 23:21:18 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gLS0-0001lg-00; Mon, 2 Oct 2000 23:21:16 -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 <0G1U0027WC8HS3@ss3000e.cselt.it> for rem-conf@es.net; Tue, 3 Oct 2000 08:19:29 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Tue, 03 Oct 2000 08:22:09 +0200 Content-return: allowed Date: Tue, 03 Oct 2000 08:20:06 +0200 From: Franceschini Guido Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision To: IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, "'Yoshihiro Kikuchi'" Message-id: <85077463E51D6A498C453073E167794039BD69@exc2k02.cselt.it> 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 Change (2) means that significantly different packets are generated in case of Short Video Headers (H263) between the original proposal and this new version. Am I right, or is this just an editorial matter ? Best regards Guido > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Tuesday, October 03, 2000 3:36 AM > To: IETF AVT; 4on2andIP-sys > Cc: Yoshihiro Kikuchi > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > <> > Dear experts, > > Attached find please a draft text for the revision of MPEG-4 Audio/Visual > RTP Internet-Draft. > > The revisions are mostly to reflect suggestions by the AVT chair. Most of > them are editorial and there are some minor revisions and clarifications. > The following is a summary of the changes: > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > "audio/MP4A-LATM" for audio. > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > video header mode was changed to "MAY" to "SHOULD". > (3) Clarification of timestamp definition > There was a suggestion not to describe the detailed definition of the > video timestamp in the RTP spec. and change it as a reference to MPEG-4 > visual document, so as to keep consistency with the MPEG-4 visual. A > description about the RTP timestamp in the RTCP SR packet was added. > (4) SA/TTSI over LATM > A description was added to restrict the LATM usage so as not to > transmit > SA data by LATM. > (5) Other editorial and wording changes. > > Please let us know if there is comment on the attached draft. The authors > need to submit it soon as an updated I-D and hopefully final before RFC. > > Best regards, > Yoshihiro Kikuchi > and authors of the Internet Draft > > ---- > 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-request@es.net Tue Oct 3 05:20:29 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04732 for ; Tue, 3 Oct 2000 05:20:28 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gNwL-0005fb-00; Tue, 3 Oct 2000 02:00:45 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gNwH-0005fI-00; Tue, 3 Oct 2000 02:00:42 -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 SAA20130; Tue, 3 Oct 2000 18:00:17 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id SAA28792; Tue, 3 Oct 2000 18:00:17 +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 SAA12005; Tue, 3 Oct 2000 18:00:15 +0900 (JST) Received: from ave (kwa0106.mobile.toshiba.co.jp [133.120.199.22]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id SAA22256; Tue, 3 Oct 2000 18:00:13 +0900 (JST) Message-ID: <038001c02d18$6335a920$16c77885@ave> From: "Yoshihiro Kikuchi" To: "Franceschini Guido" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "Yoshihiro Kikuchi" References: <85077463E51D6A498C453073E167794039BD69@exc2k02.cselt.it> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Tue, 3 Oct 2000 18:00: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 Content-Transfer-Encoding: 7bit Dear Guido, Excerpt from the new text: > When the short video header mode is used, RTP payload format for H.263 < (e.g., RFC 2190 or RFC 2429) SHOULD be used. This means that it is RECOMMENDED to use the H.263 RTP payload format for the short video header which is compatible with H.263 baseline. Regardless of MAY or SHOULD, there is a possibility that the H.263 RTP payload format may be used, although the possibility may be higher for SHOULD than MAY. If you really don't want to use the H.263 RTP payload format in some circumstances, you don't have to use it. The payload format is signaled through the MIME type. (IETF experts, please correct me if my understanding on the definition of SHOULD is wrong.) Best regards, Yoshihiro ----- Original Message ----- From: Franceschini Guido To: IETF AVT ; 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; 'Yoshihiro Kikuchi' Sent: Tuesday, October 03, 2000 3:20 PM Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision > Change (2) means that significantly different packets are generated in case > of Short Video Headers (H263) between the original proposal and this new > version. Am I right, or is this just an editorial matter ? > > Best regards > Guido > > > ---------- > > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > > Sent: Tuesday, October 03, 2000 3:36 AM > > To: IETF AVT; 4on2andIP-sys > > Cc: Yoshihiro Kikuchi > > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > > > <> > > Dear experts, > > > > Attached find please a draft text for the revision of MPEG-4 Audio/Visual > > RTP Internet-Draft. > > > > The revisions are mostly to reflect suggestions by the AVT chair. Most of > > them are editorial and there are some minor revisions and clarifications. > > The following is a summary of the changes: > > > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > > "audio/MP4A-LATM" for audio. > > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > > video header mode was changed to "MAY" to "SHOULD". > > (3) Clarification of timestamp definition > > There was a suggestion not to describe the detailed definition of the > > video timestamp in the RTP spec. and change it as a reference to MPEG-4 > > visual document, so as to keep consistency with the MPEG-4 visual. A > > description about the RTP timestamp in the RTCP SR packet was added. > > (4) SA/TTSI over LATM > > A description was added to restrict the LATM usage so as not to > > transmit > > SA data by LATM. > > (5) Other editorial and wording changes. > > > > Please let us know if there is comment on the attached draft. The authors > > need to submit it soon as an updated I-D and hopefully final before RFC. > > > > Best regards, > > Yoshihiro Kikuchi > > and authors of the Internet Draft > > > > ---- > > 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-request@es.net Tue Oct 3 12:36:17 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16312 for ; Tue, 3 Oct 2000 12:36:17 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gUqP-0000CD-00; Tue, 3 Oct 2000 09:23:05 -0700 Received: from ss3000e.cselt.it [163.162.41.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gUqN-0000AM-00; Tue, 3 Oct 2000 09:23:04 -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 <0G1V00H2R42B30@ss3000e.cselt.it> for rem-conf@es.net; Tue, 3 Oct 2000 18:20:35 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Tue, 03 Oct 2000 18:23:17 +0200 Content-return: allowed Date: Tue, 03 Oct 2000 18:21:15 +0200 From: Franceschini Guido Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision To: Franceschini Guido , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, "'Yoshihiro Kikuchi'" Message-id: <85077463E51D6A498C453073E167794039BD70@exc2k02.cselt.it> 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 Does it mean that a stream with short video header (H263) SHOULD use the traditional Payload Format for H263, but could as well (not recommended) use the new Payload Format for MPEG-4 Video, and that the choosen PF is notified as usual (SDP etc) ? If so, OK Guido > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Tuesday, October 03, 2000 11:00 AM > To: Franceschini Guido; IETF AVT; 4on2andIP-sys > Cc: Yoshihiro Kikuchi > Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision > > Dear Guido, > > Excerpt from the new text: > > > When the short video header mode is used, RTP payload format for H.263 > < (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > This means that it is RECOMMENDED to use the H.263 RTP payload format for > the short video header which is compatible with H.263 baseline. Regardless > of MAY or SHOULD, there is a possibility that the H.263 RTP payload format > may be used, although the possibility may be higher for SHOULD than MAY. > If > you really don't want to use the H.263 RTP payload format in some > circumstances, you don't have to use it. The payload format is signaled > through the MIME type. > > (IETF experts, please correct me if my understanding on the definition of > SHOULD is wrong.) > > Best regards, > Yoshihiro > > ----- Original Message ----- > From: Franceschini Guido > To: IETF AVT ; 4on2andIP-sys > <4on2andIP-sys@advent.ee.columbia.edu>; 'Yoshihiro Kikuchi' > > Sent: Tuesday, October 03, 2000 3:20 PM > Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision > > > > Change (2) means that significantly different packets are generated in > case > > of Short Video Headers (H263) between the original proposal and this new > > version. Am I right, or is this just an editorial matter ? > > > > Best regards > > Guido > > > > > ---------- > > > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > > > Sent: Tuesday, October 03, 2000 3:36 AM > > > To: IETF AVT; 4on2andIP-sys > > > Cc: Yoshihiro Kikuchi > > > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > > > > > <> > > > Dear experts, > > > > > > Attached find please a draft text for the revision of MPEG-4 > Audio/Visual > > > RTP Internet-Draft. > > > > > > The revisions are mostly to reflect suggestions by the AVT chair. Most > of > > > them are editorial and there are some minor revisions and > clarifications. > > > The following is a summary of the changes: > > > > > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > > > "audio/MP4A-LATM" for audio. > > > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > > > video header mode was changed to "MAY" to "SHOULD". > > > (3) Clarification of timestamp definition > > > There was a suggestion not to describe the detailed definition of > the > > > video timestamp in the RTP spec. and change it as a reference to > MPEG-4 > > > visual document, so as to keep consistency with the MPEG-4 visual. A > > > description about the RTP timestamp in the RTCP SR packet was added. > > > (4) SA/TTSI over LATM > > > A description was added to restrict the LATM usage so as not to > > > transmit > > > SA data by LATM. > > > (5) Other editorial and wording changes. > > > > > > Please let us know if there is comment on the attached draft. The > authors > > > need to submit it soon as an updated I-D and hopefully final before > RFC. > > > > > > Best regards, > > > Yoshihiro Kikuchi > > > and authors of the Internet Draft > > > > > > ---- > > > 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-request@es.net Tue Oct 3 12:45:21 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16809 for ; Tue, 3 Oct 2000 12:45:21 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gV4o-00019m-00; Tue, 3 Oct 2000 09:37:58 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gV4n-00019c-00; Tue, 3 Oct 2000 09:37:57 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by gumby.cs.berkeley.edu (8.9.3/8.9.3) with SMTP id JAA04910; Tue, 3 Oct 2000 09:27:33 -0700 Message-Id: <3.0.3.32.20001003093000.00aae9c0@plateau.cs.berkeley.edu> X-Sender: florissa@plateau.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 03 Oct 2000 09:30:00 -0700 To: (Recipient list suppressed) From: Florissa Colina Subject: 10/4 Studying and Modeling Real Audio Traffic -- John Heidemann, USC Information Sciences Institute Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Berkeley Multimedia, Graphics and Interfaces Seminar Studying and Modeling Real Audio Traffic Wednesday October 4, 2000, 1:10-2:30 p.m. PDT Fujitsu Seminar Room (405 Soda Hall) John Heidemann USC Information Sciences Institute The delivery of multimedia content on the Internet is rapidly growing in importance. While there have been extensive studies on the growth and effects of Hyper Text Transfer Protocol (HTTP) traffic used on the Web, little work has been performed in analyzing streaming multimedia traffic. Based on traces from broadcast.com, we will present a study of Real Audio traffic. We will describe the characteristics of typical real audio flows and compare them to web traffic. In addition, we observed consistencies in audio traffic packet sizes and data rate patterns that may be useful as a tool for identifying audio data flows. Finally, we will present recent analysis of real audio traffic and show how it has guided our approaches to model this traffic in simulation. This is joint work with Art Mena and Kun-chan Lan at USC. --------------- The seminar is broadcast live on the Internet Mbone and as a Real Networks G2 broadcast. You can connect to the live RealNetworks broadcast at: http://bmrc.berkeley.edu/bibs/cs298-5 You can also directly put in this url into the Real Player: rtsp://media2.bmrc.berkeley.edu/encoder/cs298-5.rm To do so you will need to have the "Real Player G2" installed, which is available from: http://www.real.com/products/player/downloadrealplayer.html To tune into the Internet MBone broadcast, look for the announcement in your MBone session directory program ('sdr'). If you are not receiving the announcement you may be able to receive the session by manually configuring the client programs ('vic', and 'vat') with the session addresses: medium bit rate video: 233.0.25.129/22334 audio: 233.0.25.2/22446 You can get further information about this seminar, and access to replays of previous seminars at the MIG Seminar web page: http://media2.bmrc.berkeley.edu/bibs/archive.cfm Sponsored by the Berkeley Multimedia Research Center From rem-conf-request@es.net Tue Oct 3 14:49:41 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20918 for ; Tue, 3 Oct 2000 14:49:40 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gWth-0004ky-00; Tue, 3 Oct 2000 11:34:37 -0700 Received: from out2.prserv.net (prserv.net) [32.97.166.32] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gWtg-0004ko-00; Tue, 3 Oct 2000 11:34:36 -0700 Received: from rpcaragonite ([139.92.226.87]) by prserv.net (out2) with SMTP id <2000100318343222902f428he>; Tue, 3 Oct 2000 18:34:34 +0000 Message-ID: <000d01c02d68$b8ef19a0$57e25c8b@rpcaragonite> Reply-To: "Olivier Avaro" From: "Olivier Avaro" To: , "rem-conf" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu> Cc: "CURET Dominique FTRD/DMI" References: <0056890014249640000002L902*@MHS> Subject: Re: Types of MPEG-4 streams over IP Date: Tue, 3 Oct 2000 12:14:13 +0200 Organization: France Telecom R&D 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Dear Jan, > I would like to verify my understanding on the types of MPEG-4 streams that > need tools for transport over IP. I summarized my understanding by the > following list. Here is the list you can find in V2 : 0x00 Forbidden 0x01 ObjectDescriptorStream (see 8.5) 0x02 ClockReferenceStream (see 10.2.519) 0x03 SceneDescriptionStream (see 9.2.1) 0x04 VisualStream 0x05 AudioStream 0x06 MPEG7Stream 0x07 IPMPStream (see 8.3.2) 0x08 ObjectContentInfoStream (see 8.4.2) 0x09 MPEGJStream I don't have anything for Flexmux. cu, O. From rem-conf-request@es.net Tue Oct 3 14:59:40 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21063 for ; Tue, 3 Oct 2000 14:59:39 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gX9i-0007EG-00; Tue, 3 Oct 2000 11:51:10 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gX9h-0007C2-00; Tue, 3 Oct 2000 11:51:09 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2650.21) id <41BTA9P4>; Tue, 3 Oct 2000 12:50:11 -0600 Message-ID: <6E031E06378BD311AEF20090273CE1BA81E6EF@el-postino.s-vision.com> From: Kris Huber To: Franceschini Guido Cc: IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, "'Yoshihiro Kikuchi'" Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Tue, 3 Oct 2000 12:50:10 -0600 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 Hello Guido, I think you are right. It appears that the other alternative (change MAY to SHALL or SHOULD) was taken rather than insertion of the MPEG-4 visual semantics regarding picture rate in short header mode (which lacks modulo_time_base, vop_time_increment, and vop_time_increment_resolution). These were spelled out for short header in draft-ietf-avt-rtp-mpeg4-es-04.txt based on a suggestion I made (e-mail of 9/8/00 "RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - timestamp of short header VOP"). Since then, I have learned that a more typical way (I think) that hardware-assisted compression systems are used with PAL devices is with the picture clock frequency driving the temporal_reference/TR field set to 25 Hz rather than giving rounded values of a 30 Hz picture clock. However, my suggestion does match baseline H.263 and MPEG-4 short-header mode, although I think H.263 implementers have been a little loose in their interpretation, perhaps with good reason. Another opinion I respect is that a better partitioning of functions would have placed all timing information in the systems part, as (I think) was done for the audio part. But on the other hand you can't properly decode video without some timing information (sequence number at least) due to temporal prediction and B-VOPs. I heard no discussion of the text I proposed for clarification of the timestamp relationship to temporal_reference in short header mode after Gary Sullivan's clarifications and suggestion that MAY be changed to SHALL. I'm not on the IETF AVT mailing list or at other meetings where the discussion probably occurred. Regards, Kris -----Original Message----- From: Franceschini Guido [mailto:Guido.Franceschini@cselt.it] Sent: Tuesday, October 03, 2000 12:20 AM To: IETF AVT; 4on2andIP-sys; 'Yoshihiro Kikuchi' Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision Change (2) means that significantly different packets are generated in case of Short Video Headers (H263) between the original proposal and this new version. Am I right, or is this just an editorial matter ? Best regards Guido > ---------- > From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] > Sent: Tuesday, October 03, 2000 3:36 AM > To: IETF AVT; 4on2andIP-sys > Cc: Yoshihiro Kikuchi > Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision > > <> > Dear experts, > > Attached find please a draft text for the revision of MPEG-4 Audio/Visual > RTP Internet-Draft. > > The revisions are mostly to reflect suggestions by the AVT chair. Most of > them are editorial and there are some minor revisions and clarifications. > The following is a summary of the changes: > > (1) MIME subtype names were changed to "video/MP4V-ES" for video and > "audio/MP4A-LATM" for audio. > (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short > video header mode was changed to "MAY" to "SHOULD". > (3) Clarification of timestamp definition > There was a suggestion not to describe the detailed definition of the > video timestamp in the RTP spec. and change it as a reference to MPEG-4 > visual document, so as to keep consistency with the MPEG-4 visual. A > description about the RTP timestamp in the RTCP SR packet was added. > (4) SA/TTSI over LATM > A description was added to restrict the LATM usage so as not to > transmit > SA data by LATM. > (5) Other editorial and wording changes. > > Please let us know if there is comment on the attached draft. The authors > need to submit it soon as an updated I-D and hopefully final before RFC. > > Best regards, > Yoshihiro Kikuchi > and authors of the Internet Draft > > ---- > 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-request@es.net Tue Oct 3 20:36:16 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25206 for ; Tue, 3 Oct 2000 20:36:15 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gby3-0002di-00; Tue, 3 Oct 2000 16:59:27 -0700 Received: from netsys.kaist.ac.kr [143.248.148.90] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gby0-0002dY-00; Tue, 3 Oct 2000 16:59:24 -0700 Received: from eunhasu.kjist.ac.kr (eunhasu.kjist.ac.kr [203.237.32.200]) by netsys.kaist.ac.kr (8.9.3/8.9.3) with ESMTP id HAA20722; Wed, 4 Oct 2000 07:29:34 +0900 Received: from vivaldi (vivaldi.kjist.ac.kr [203.237.51.8]) by eunhasu.kjist.ac.kr (8.9.3/8.9.3) with SMTP id IAA05797; Wed, 4 Oct 2000 08:35:41 +0900 (KST) Message-ID: <004101c02d8f$7ccda8c0$0833edcb@vivaldi.kjist.ac.kr> From: "=?euc-kr?B?yKO/5Ly6?=" To: "PV2001" , , , , , , Subject: PCS2001 Final Call for Papers Date: Wed, 4 Oct 2000 08:13:05 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_003D_01C02DDA.EC7B5500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 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_003D_01C02DDA.EC7B5500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_003E_01C02DDA.EC7B5500" ------=_NextPart_001_003E_01C02DDA.EC7B5500 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 UGxlYXNlIGZpbmQgYXR0YWNoZWQgRmluYWwgQ2FsbCBmb3IgUGFwZXJzIG9mIFBpY3R1cmUgQ29k aW5nIFN5bXBvc2l1bSANCjIwMDEgdG8gYmUgaGVsZCBpbiBTZW91bCwgS29yZWEgZHVyaW5nIDI1 IEFwcmlsIC0gMjcgQXByaWwsIDIwMDEuDQoNClRoZSBkZWFkbGluZSBmb3IgcGFwZXIgc3VibWlz c2lvbiwgMTUgT2N0b2JlciAyMDAwLCBpcyBjb21pbmcgc29vbi4NCg0KVXBkYXRlZCBwYXBlciBz dWJtaXNzaW9pbiBpbmZvcm1hdGlvbiBpcyBhdCBodHRwOi8vcGNzLmthaXN0LmFjLmtyLg0KDQpG b3IgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlbmQgYW4gZW1haWwgdG8gcGNzQHBjcy5r YWlzdC5hYy5rci4NCg0KV2UgbG9vayBmb3J3YXJkIHRvIHNlZWluZyB5b3UgYXQgdGhlIGV4Y2l0 aW5nIFBDUzIwMDEuDQoNCkJlc3QgUmVnYXJkcywNCg0KDQpZby1TdW5nIEhvDQoNCg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KWW8t U3VuZyBIbywgQXNzb2NpYXRlIFByb2Zlc3Nvcg0KDQpEZXBhcnRtZW50IG9mIEluZm9ybWF0aW9u IGFuZCBDb21tdW5pY2F0aW9ucw0KS3dhbmctSnUgSW5zdGl0dXRlIG9mIFNjaWVuY2UgYW5kIFRl Y2hub2xvZ3kgKEstSklTVCkNCjEgT3J5b25nLURvbmcgUHVrLUd1DQpLd2FuZ2p1LCA1MDAtNzEy LCBLb3JlYQ0KDQpURUw6ICAgKzgyLTYyLTk3MC0yMjExDQpGQVg6ICAgKzgyLTYyLTk3MC0yMjA0 DQpFTUFJTDogaG95b0BramlzdC5hYy5rcg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQo= ------=_NextPart_001_003E_01C02DDA.EC7B5500 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PXRleHQvaHRtbDtjaGFyc2V0PWtzX2NfNTYwMS0xOTg3 IGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0nIk1TSFRNTCA0LjcyLjMx MTAuNyInIG5hbWU9R0VORVJBVE9SPg0KPC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0K PERJVj48Rk9OVCBzaXplPTI+UGxlYXNlIGZpbmQgYXR0YWNoZWQgRmluYWwgQ2FsbCBmb3IgUGFw ZXJzIG9mIFBpY3R1cmUgQ29kaW5nIA0KPC9GT05UPjxGT05UIHNpemU9Mj5TeW1wb3NpdW0gPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+MjAwMSB0byBiZSBoZWxkIGluIFNlb3VsLCBL b3JlYSA8L0ZPTlQ+PEZPTlQgc2l6ZT0yPmR1cmluZyAyNSANCkFwcmlsIC0gMjcgQXByaWwsIDIw MDEuPEJSPjxCUj48Rk9OVCBjb2xvcj0jZmYwMDAwPlRoZSBkZWFkbGluZSBmb3IgcGFwZXIgDQpz dWJtaXNzaW9uLCAxNSBPY3RvYmVyIDIwMDAsIGlzIGNvbWluZyBzb29uLjxCUj48L0ZPTlQ+PEJS PlVwZGF0ZWQgcGFwZXIgDQpzdWJtaXNzaW9pbiBpbmZvcm1hdGlvbiBpcyBhdCA8QSANCmhyZWY9 Imh0dHA6Ly9wY3Mua2Fpc3QuYWMua3IiPmh0dHA6Ly9wY3Mua2Fpc3QuYWMua3I8L0E+LjxCUj48 QlI+Rm9yIGZ1cnRoZXIgDQppbmZvcm1hdGlvbiwgcGxlYXNlIHNlbmQgYW4gZW1haWwgdG8gPEEg DQpocmVmPSJtYWlsdG86cGNzQHBjcy5rYWlzdC5hYy5rciI+cGNzQHBjcy5rYWlzdC5hYy5rcjwv QT4uPEJSPjxCUj5XZSBsb29rIA0KZm9yd2FyZCB0byBzZWVpbmcgeW91IGF0IHRoZSBleGNpdGlu ZyBQQ1MyMDAxLjxCUj48QlI+QmVzdCBSZWdhcmRzLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPjxCUj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAg ZmFjZT0iIiBzaXplPTI+WW8tU3VuZyBIbzwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjxGT05UIGNv bG9yPSMwMDAwMDAgDQpzaXplPTI+PEJSPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKio8QlI+WW8tU3VuZyANCkhvLCBBc3NvY2lhdGUgUHJv ZmVzc29yPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkRlcGFydG1l bnQgb2YgSW5mb3JtYXRpb24gYW5kIA0KQ29tbXVuaWNhdGlvbnM8QlI+S3dhbmctSnUgSW5zdGl0 dXRlIG9mIFNjaWVuY2UgYW5kIFRlY2hub2xvZ3kgKEstSklTVCk8QlI+MSANCk9yeW9uZy1Eb25n IFB1ay1HdTxCUj5Ld2FuZ2p1LCA1MDAtNzEyLCBLb3JlYTwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgY29sb3I9IzAwMDAwMCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBj b2xvcj0jMDAwMDAwIHNpemU9Mj5URUw6Jm5ic3A7Jm5ic3A7IA0KKzgyLTYyLTk3MC0yMjExPEJS PkZBWDombmJzcDsmbmJzcDsgKzgyLTYyLTk3MC0yMjA0PEJSPkVNQUlMOiA8QSANCmhyZWY9Im1h aWx0bzpob3lvQGtqaXN0LmFjLmtyIj5ob3lvQGtqaXN0LmFjLmtyPC9BPjxCUj4qKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPEJSPjwvRk9O VD48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_001_003E_01C02DDA.EC7B5500-- ------=_NextPart_000_003D_01C02DDA.EC7B5500 Content-Type: application/msword; name="PCS-callforpapers.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PCS-callforpapers.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAASAAAAAAAAAAA EAAASgAAAAEAAAD+////AAAAAEcAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEATQAJBAAACFK/AAAAAAAAEAAAAAAABAAAlxMAAA4AYmpiaicyJzIAAAAAAAAAAAAAAAAAAAAA AAASBBYANiYAAEVYAABFWAAAlw8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAIQBAAAAAAAAhAEAAIQB AAAAAAAAhAEAAAAAAACEAQAAAAAAAIQBAAAAAAAAhAEAABQAAAAAAAAAAAAAAJgBAAAAAAAAmAEA AAAAAACYAQAAAAAAAJgBAAAAAAAAmAEAACQAAAC8AQAAJAAAAJgBAAAAAAAA6BEAAIQCAADsAQAA KAAAABQCAAAAAAAAFAIAAAAAAAAUAgAAAAAAABQCAAAAAAAAqwMAAD4AAADpAwAAFAAAAP0DAAAM AAAA0REAAAIAAADTEQAAAAAAANMRAAAAAAAA0xEAAAAAAADTEQAAAAAAANMRAAAAAAAA0xEAAAAA AABsFAAA9AEAAGAWAABiAAAA0xEAABUAAAAAAAAAAAAAAAAAAAAAAAAAhAEAAAAAAAAJBAAAAAAA AAAAAAAAAAAAAAAAAAAAAACnAwAABAAAAKsDAAAAAAAACQQAAAAAAAAJBAAAAAAAANMRAAAAAAAA tQUAAAAAAACEAQAAAAAAAIQBAAAAAAAAFAIAAAAAAAAAAAAAAAAAABQCAACTAQAA7AEAAAAAAAC1 BQAAAAAAALUFAAAAAAAAtQUAAAAAAAAJBAAAigEAAIQBAAAAAAAAFAIAAAAAAACEAQAAAAAAABQC AAAAAAAA0REAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmAEAAAAAAACYAQAAAAAAAIQBAAAAAAAAhAEA AAAAAACEAQAAAAAAAIQBAAAAAAAACQQAAAAAAADREQAAAAAAALUFAAD0AwAAtQUAAAAAAACpCQAA cgAAAG8RAABUAAAAhAEAAAAAAACEAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0REAAAAAAAAUAgAAAAAAAOABAAAMAAAAwOE/GfTq vwGYAQAAAAAAAJgBAAAAAAAAkwUAACIAAADDEQAADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKFBy ZWxpbWluYXJ5KQdDYWxsIGZvciBQYXBlcnMgYW5kIEFubm91bmNlbWVudAcHUGljdHVyZSBDb2Rp bmcgU3ltcG9zaXVtIDIwMDEHBw0yNS0yNyBBcHJpbCAyMDAxLCBTZW91bCwgS29yZWENU3BvbnNv cmVkIGFuZCBvcmdhbml6ZWQgYnk6IEtJQ1MgKEtvcmVhIEluc3RpdHV0ZSBvZiBDb21tdW5pY2F0 aW9uIFNjaWVuY2VzKQ1JbiBjb29wZXJhdGlvbiB3aXRoICh0ZWNobmljYWwgY28tc3BvbnNvcik6 IEVVUkFTSVAsIElFRUUgQ0FTLCBJRUVFIFNQIChwZW5kaW5nKQ0NUENTIGlzIHRoZSBwcmVtaWVy IGludGVybmF0aW9uYWwgZm9ydW0gZGV2b3RlZCBzcGVjaWZpY2FsbHkgdG8gcGljdHVyZSBjb2Rp bmcuIEZvciBtb3JlIHRoYW4gdGhyZWUgZGVjYWRlcyB0aGUgSW50ZXJuYXRpb25hbCBQaWN0dXJl IENvZGluZyBTeW1wb3NpdW0gaGFzIHByb3ZpZGVkIHRoZSBtZWV0aW5nIHBsYWNlIGZvciB0aGUg cGljdHVyZSBjb2RpbmcgY29tbXVuaXR5OiBpbmR1c3RyeSwgcmVzZWFyY2gsIGFjYWRlbWlhIGFu ZCB1c2Vycy4gVGhlIDIybmQgUENTIHdpbGwgYmUgaGVsZCBpbiBTZW91bCBvbiAyNSAtIDI3IEFw cmlsIDIwMDEsIGluIHRoZSB3ZWVrIHByaW9yIHRvIHRoZSAxMXRoIEludGVybmF0aW9uYWwgUGFj a2V0IFZpZGVvIFdvcmtzaG9wIHRoYXQgd2lsbCB0YWtlIHBsYWNlIGluIEt5b25nanUsIEtvcmVh IGZyb20gMzAgQXByaWwgdG8gMSBNYXkuIEZ1cnRoZXIgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHJl Z2lzdHJhdGlvbiwgaG90ZWwgcmVzZXJ2YXRpb24sIGFuZCB2ZW51ZSB3aWxsIGJlIGFubm91bmNl ZCBvbiB0aGUgd2ViIHNpdGUuDQ1Qcm9zcGVjdGl2ZSBhdXRob3JzIGFyZSBhc2tlZCB0byBzdWJt aXQgZm9yIHJldmlldyBlaXRoZXIgYW4gZWxlY3Ryb25pYyB2ZXJzaW9uIChNUy1Xb3JkIDcuMCBv ciBQb3N0c2NyaXB0KSBieSBlLW1haWwgb3IgMyBjb3BpZXMgb2YgYSAxMDAwIHdvcmQgYWJzdHJh Y3Qgb2YgdGhlaXIgcGFwZXIuIFRoZSBhdXRob3JzIG9mIGFjY2VwdGVkIHBhcGVycyBhcmUgcmVx dWVzdGVkIHRvIHN1Ym1pdCB0aGUgZmluYWwgNC10by02IHBhZ2UgY2FtZXJhLXJlYWR5IG1hbnVz Y3JpcHQgdGhhdCB3aWxsIGFwcGVhciBpbiB0aGUgcHJvY2VlZGluZ3Mgb2YgdGhlIHN5bXBvc2l1 bS4gVHdvIHR5cGVzIG9mIHByZXNlbnRhdGlvbiB3aWxsIGJlIHVzZWQsIG9yYWwgYW5kIHBvc3Rl ciBhdCB0aGUgc3ltcG9zaXVtLiBBYm91dCAyMCBtaW51dGVzIHdpbGwgYmUgYWxsb3R0ZWQgdG8g ZWFjaCBvcmFsIHByZXNlbnRhdGlvbiwgaW5jbHVkaW5nIGRpc2N1c3Npb24uIE92ZXJoZWFkIHBy b2plY3RvciwgMzUgbW0gc2xpZGUgcHJvamVjdG9yLCBhbmQgbW9zdCBjb21tb24gdmlkZW90YXBl IGZvcm1hdHMgc3VjaCBhcyBWSFMgYW5kIEQxIGNhbiBiZSBhY2NvbW1vZGF0ZWQuIEF1dGhvcnMg YXJlIGVuY291cmFnZWQgdG8gdXNlIHRoZXNlIGZhY2lsaXRpZXMgdG8gZGVtb25zdHJhdGUgdGhl aXIgcmVzdWx0cy4NDUFyZWFzIG9mIGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0 ZWQgdG86DUh1bWFuIG9ic2VydmVyL3BzeWNob3BoeXNpY3MNRmVhdHVyZSBleHRyYWN0aW9uIGFu ZCBwaWN0dXJlIHByb2Nlc3NpbmcNTW90aW9uIGVzdGltYXRpb24gYW5kIG9iamVjdCBzZWdtZW50 YXRpb24NQ29kaW5nIGZvciBzdGlsbCBhbmQgbW92aW5nIHBpY3R1cmVzDUNvZGluZyBvZiBzdGVy ZW8gYW5kIG11bHRpdmlldyBpbWFnZXMvc2VxdWVuY2VzIA1Db250ZW50LWJhc2VkIG9yIG9iamVj dC1vcmllbnRlZCBjb2RpbmcHTW9kZWxpbmcgYW5kIHN5bnRoZXRpYyBjb2RpbmcNSHlicmlkIG5h dHVyYWwgc3ludGhldGljIGNvZGluZw1WZXJ5IGhpZ2ggcmVzb2x1dGlvbiBpbWFnaW5nIGFuZCBw cm9jZXNzaW5nDUpvaW50IHZpZGVvLWF1ZGlvIHByb2Nlc3NpbmcsIGNvZGluZyBhbmQgcmVwcmVz ZW50YXRpb24NQ29kaW5nIGZvciBtb2JpbGUgYW5kIElQIGNvbW11bmljYXRpb25zB0NvZGluZyBh bmQgaW5kZXhpbmcgZm9yIGRhdGFiYXNlIGFwcGxpY2F0aW9ucw1FcnJvciBwcm90ZWN0aW9uIGFu ZCByZXNpbGllbmNlDUpvaW50IHNvdXJjZSBhbmQgY2hhbm5lbCBjb2RpbmcNVmlydHVhbCByZWFs aXR5IGFuZCB0ZWxlcHJlc2VuY2UNTWVkaWEgdHJhbnNmb3JtIChpbWFnZSBhbmltYXRpb24gYnkg dm9pY2UgYW5kIHRleHQpDUltcGxlbWVudGF0aW9uIGFyY2hpdGVjdHVyZXMgYW5kIFZMU0kHBw1H ZW5lcmFsIENoYWlyOiAJSmFlLWt5b29uIEtpbSwgS0FJU1QsIEtvcmVhDUludGVybmF0aW9uYWwg U3RlZXJpbmcgQ29tbWl0dGVlOg1Kb2huIEFybm9sZAkgICAgVS4gb2YgTmV3IFNvdXRoIFdhbGVz LCBBdXN0cmFsaWEJCUtpbmcgTi4gTmdhbgkgICBVLiBvZiBXZXN0ZXJuIEF1c3RyYWxpYSwgQXVz dHJhbGlhDUxlb25hcmRvIENoaWFyaWdsaW9uZSAgICBDU0VMVCwgSXRhbHkJCQkJSm9lcm4gT3N0 ZXJtYW5uCSAgIEFUJlQsIFVTQQ1Nb2hhbW1lZCBHaGFuYmFyaQkgICAgVS4gb2YgRXNzZXgsIFVL CQkJCUZlcm5hbmRvIFBlcmVpcmEJICAgSVNUL1VUTCwgUG9ydHVnYWwNSGFtaWQgR2hhcmF2aQkg ICAgTklTVCwgVVNBCQkJCVJhbGYgU2NoYWVmZXIJICAgSGVpbnJpY2gtSGVydHogSW5zdGl0dXQs IEdlcm1hbnkNQmVybmQgR2lyb2QJICAgIFN0YW5mb3JkIFUuLCBVU0EJCQlBbGkgVGFiYXRhYmFp CSAgIFNvbnksIFVTQQ1UaG9tYXMgSHVhbmcJICAgIFUuIG9mIElsbGlub2lzLCBVcmJhbmEsIFVT QQkJCU1hc2F5dWtpIFRhbmltb3RvCSAgIE5hZ295YSBVLiwgSmFwYW4NSmFlLWt5b29uIEtpbQkg ICAgS0FJU1QsIEtvcmVhCQkJCUEuIE11cmF0IFRla2FscAkgICBVbml2LiBvZiBSb2NoZXN0ZXIs IFVTQQ1NdXJhdCBLdW50CSAgICBFUEZMLCBTd2l0emVybGFuZAkJCUpvaG4gV29vZHMJICAgUmVu c3NlbGFlciBQb2x5dGVjaG5pYyBJbnN0LiwgVVNBDUNsYXVkZSBMYWJpdAkgICAgSVJJU0EsIEZy YW5jZQkJCQlIaXJvc2hpIFlhc3VkYQkgICBVLiBvZiBUb2t5bywgSmFwYW4NU2FuZyBVayBMZWUJ ICAgIFNlb3VsIE5hdGlvbmFsIFUuLCBLb3JlYQkJCVlhc3VoaWtvIFlhc3VkYQkgICBXYXNlZGEg VS4sIEphcGFuDU1pbmcgTC4gTGlvdQkgICAgSG9uZyBLb25nIFUuIG9mIFNjaS4gJiBUZWNobm9s b2d5CQlBdmlkZWggWmFraG9yCSAgIFUuIG9mIENhbGlmb3JuaWEsIEJlcmtlbGV5LCBVU0ENSGFu cyBHLiBNdXNtYW5uCSAgICBVLiBvZiBIYW5vdmVyLCBHZXJtYW55CQkJWWEtUWluIFpoYW5nCSAg IE1pY3Jvc29mdCBSZXNlYXJjaCwgQ2hpbmENR2VvZmYgTW9ycmlzb24JICAgIEJyaXRpc2ggVGVs ZWNvbSwgVUsJCQkNVGVjaG5pY2FsIFByb2dyYW0gQ2hhaXI6IAkgICAgIFNhbmcgVWsgTGVlLCBT ZW91bCBOYXRpb25hbCBVbml2LiwgS29yZWENT3JnYW5pemluZyBDb21taXR0ZWUgQ2hhaXI6ICAg Sm9uZyBCZW9tIFJhLCBLQUlTVCwgS29yZWENDVN1Ym1pdCBwYXBlcnMgdG86IFBDUyAyMDAxCQkJ CURlYWRsaW5lczoNRGVwdC4gb2YgRUVDUywgS0FJU1QJCU9jdG9iZXIgMTUsIDIwMDAJU3VibWl0 IGFic3RyYWN0cw1ZdXNvbmctZ3UsIFRhZWpvbiAzMDUtNzAxCQlKYW51YXJ5IDE1LCAyMDAxCU5v dGljZSBvZiBhY2NlcHRhbmNlDVJlcHVibGljIG9mIEtvcmVhCQkJTWFyY2ggMTUsIDIwMDEJU3Vi bWl0IG1hbnVzY3JpcHRzDQ1PciBhbm9ueW1vdXMgZnRwIHRvOiBmdHA6Ly9wY3Mua2Fpc3QuYWMu a3INDUZvciBhbnkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBvciBmb3IgcmVjZWl2aW5nIHJlZ3Vs YXIgdXBkYXRlcyBvbiBQQ1MgMjAwMSwgcGxlYXNlIHZpc2l0IHRoZSB3ZWIgcGFnZSBhdDogEyBI WVBFUkxJTksgImh0dHA6Ly9wY3Mua2Fpc3QuYWMua3IiIAEUaHR0cDovL3Bjcy5rYWlzdC5hYy5r chUgIFNlbmQgYW55IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIHRvOiATIEhZUEVSTElOSyAibWFp bHRvOnBjc0BwY3Mua2Fpc3QuYWMua3IiIAEUcGNzQHBjcy5rYWlzdC5hYy5rchUNDQEJAQkBDQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAOBAAAIgQA ACMEAAAvBAAAMAQAAE4EAABPBAAAUAQAAG8EAACJBAAAigQAAIsEAAC8BAAA5gQAAAIFAAAMBQAA DQUAAA4FAABrBQAAcAUAAA0GAAAQBgAAEgYAABMGAAAVBgAALwYAADIGAAAzBgAANQYAADYGAAA3 BgAAOQYAADoGAABFBgAARgYAAGAGAABiBgAAZAYAAGUGAACIBgAAiQYAAMYGAADHBgAANAcAADUH AACOBwAAjwcAACAIAAAnCAAA2AkAANoJAAAMCgAAsQwAALkMAAC/DAAAwAwAAMEMAADODAAAzwwA ANAMAADWDAAA1wwAANwMAADdDAAA/gwAAPv18PUA7gDm4Nng++DZ4PvTzcjCyMLIwrrIwsjCyMLI wsjCyMK6wrTIwsjC08jCyMLIwrDC4LDIwsjCqMKowuCwAAAAAAAAAA9DShIAT0oAAFJIyABvKAEH NQiBT0oAAAs1CIFDShIAT0oAAA5DShIASCoBT0oAAG8oAQALQ0oSAE9KAABvKAEIQ0oSAE9KAAAA C0NKDgBPSgAAbygBC0NKEABPSgAAbygBDTUIgTYIgU9KAABvKAEKNQiBT0oAAG8oAQAPQ0oQAE9K BwBRSgcAbygBA28oAQhPSgYAUUoGAAALT0oGAFFKBgBvKAEHT0oAAG8oAQBBAAQAAA4EAAAvBAAA MAQAAE4EAABPBAAAUAQAAG8EAAC8BAAADQUAAA4FAAA0BwAANQcAANkJAADaCQAADQoAAPwAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAAyXwAAAAAAAAAAAAAAMYAAAAAAAAAAAAAAAChAAAAAAAAAAAA AAAAnwAAAAAAAAAAAAAAAJkAAAAAAAAAAAAAAACZAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAJkA AAAAAAAAAAAAAACZAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAJkAAAAAAAAAAAAAAACfAAAAAAAA AAAAAAAAnwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAABgAAEmTwAAAARyQAAAEAAAAkAAAWJAEXJAEClmMAB5T5AQXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWGgABnf9rKYAGzikMAQAA/////xIBAAD/////AwEAFiQBAC0AABYkARck AQKWYwAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1jAAAp3/RgtrKQAGqQv///////////// ////////AAYlHv////////////////////8ABAAAAyQCFiQBAwAAFiQBAA8ABAAADgQAAC8EAACX EwAA/f37AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAAQDAQUKAw0KAAAqCgAAVAoAAH4K AACjCgAA1AoAAPwKAAAaCwAAOgsAAGYLAACeCwAAxgsAAPQLAAAUDAAANAwAAFUMAACJDAAArwwA ALAMAACxDAAA3QwAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAA AAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAA AAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsA AAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAA AAAAAAAAsgAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAA ADgAABYkARckAQKWYwAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1kYAA53/jA17G2spAAbv Df////////////////////8ABu8N/////////////////////wAG8A3///////////////////// ABMAAAMkAAomAAtGAwAOhMgAEmTIAAAARyQAFiQBDcYHAWgBAbQABgAU3QwAAP8MAABkDQAAqg0A APkNAABKDgAAiA4AAN0OAAAqDwAAfQ8AAMQPAAATEAAAeBAAAM8QAAD5EAAAQREAAHoRAAB7EQAA pBEAANwRAAAdEgAAUxIAAFQSAAB/EgAAgBIAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAA AAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAA AAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAADqAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADbAAAAAAAAAAAA AAAA2wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAAAF AAANxgUAAVMHAAAGAAASZDj/AAATpIgACgAAD4TIABGEeAUSZPAAAABHJAAABAAAEmTIAAAAAAQA ABJktAAAAAgAABJk8AAAABOkiABHJAAGAAASZMgAAABHJAAAAQAAABj+DAAA/wwAAAsNAAAmDQAA Lw0AAGQNAAB5DQAAfQ0AAIkNAACNDQAAnA0AAKANAACpDQAAqg0AALwNAADADQAA0A0AAPkNAAAG DgAADw4AABQOAAAYDgAAJQ4AACkOAABJDgAASg4AAFYOAABaDgAAaw4AAIgOAACVDgAAmQ4AALQO AAC3DgAAyQ4AAMwOAADcDgAA3Q4AAOoOAAACDwAADA8AAA0PAAAPDwAAEg8AACkPAAAqDwAANQ8A ADkPAABMDwAATQ8AAFgPAABbDwAAfA8AAJ8PAACuDwAAtw8AAMMPAADvDwAA/w8AAAIQAAAKEAAA CxAAABIQAAATEAAAIBAAACQQAABFEAAARxAAAFUQAABYEAAAdxAAAHgQAACIEAAAjBAAAKIQAACl EAAAshAAALUQAAC+EAAAxxAAAM4QAADPEAAA3RAAAOIQAAD1EAAA+RAAABERAAASEQAAJBEAAP34 8vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy+PL48vjy +PL48vjy+PL48vjy+PL48vjy+PL48vjy+PLs6PIAAAAAAAAAAAAAAAAAAAAAAAAAAAdPSgAAbygB CjUIgU9KAABvKAEAC0NKEgBPSgAAbygBCENKEgBPSgAAAARDShIAWCQRAAAlEQAAOhEAADsRAABB EQAAXBEAAF8RAABsEQAAbREAAHMRAAB0EQAAehEAAHsRAACNEQAAlREAAJgRAACZEQAApBEAALgR AADcEQAA5hEAAOcRAAD1EQAA9hEAAPcRAAAdEgAAMRIAAFISAABTEgAAVBIAAGgSAABpEgAAfhIA AH8SAACAEgAA6hIAAOsSAADsEgAA+BIAAA4TAAAQEwAAERMAABITAAAoEwAAKRMAACoTAABQEwAA URMAAGQTAAB3EwAAeRMAAHoTAAB7EwAAjhMAAI8TAACQEwAAkRMAAJITAACTEwAA9/H38evn8ffx 9/Hf29jb69vn2OfY59jn2OfY5/Hb2NLKxNjnu9vr26+7prvn2Lvb69uau6a768SVkwNvKAEJA2qm AQAAVQgBFgIIgQNq0wAAAAYIATUIgU9KAABVCAEAETBKDwA1CIE+KgBPSgAAbygBFgIIgQNqAAAA AAYIATUIgU9KAABVCAEAEANqAAAAADUIgU9KAABVCAEAC0NKEABPSgAAbygBDjUIgUNKFgBPSgAA bygBAAtDShcAT0oAAG8oAQRPSgAAAAc1CIFPSgAADjUIgUNKDgBPSgAAbygBAAdPSgAAbygBCjUI gU9KAABvKAEAC0NKEgBPSgAAbygBD0NKEgBPSgAAUkjIAG8oAQA6gBIAAJATAACREwAAlxMAAPkA AAAAAAAAAAAAAADzAAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAwAAAyQBBgAAEmTIAAAARyQABgAAEmTwAAAARyQAAAOTEwAAlBMAAJUTAACWEwAAlxMA APr48+0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL Q0oSAE9KAABvKAEJA2rzJgAAVQgBA28oAQkDamEdAABVCAEABDQAJlAJADGQEQEyUAIAH7CCLiCw xkEhsL0CIrC9AiOQiQMkkIUDJbAAABewUwMYsOADDJCpAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0wAAAEQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGM ggCqAEupCwIAAAAXAAAAFwAAAGgAdAB0AHAAOgAvAC8AcABjAHMALgBrAGEAaQBzAHQALgBhAGMA LgBrAHIAAADgyep5+brOEYyCAKoAS6kLMAAAAGgAdAB0AHAAOgAvAC8AcABjAHMALgBrAGEAaQBz AHQALgBhAGMALgBrAHIALwAAANMAAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABQA AABwAGMAcwBAAHAAYwBzAC4AawBhAGkAcwB0AC4AYQBjAC4AawByAAAA4Mnqefm6zhGMggCqAEup CzYAAABtAGEAaQBsAHQAbwA6AHAAYwBzAEAAcABjAHMALgBrAGEAaQBzAHQALgBhAGMALgBrAHIA AAC7GwAARABkAAAAAAAAAAIAAAAAAAAAAAAAAAAAUwdTB0ACQAIAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAA8ABPA8AAAAsgQK8AgAAAABBAAAAAoAAEMAC/AYAAAABEEBAAAAgQERAAAQ vwEAABAA/wEAAAgAAAAQ8AQAAAAAAACAYgAH8CsbAAAGBh+hduk+FDynX/wzs4eEkyL/AAcbAAAB AAAA6gEAAAAAwQAAbh7w/xoAAB+hduk+FDynX/wzs4eEkyL/iVBORw0KGgoAAAANSUhEUgAAAH0A AAB9CAMAAAC4XpwXAAAAAXNSR0IArs4c6QAAAwBQTFRF////jIyMlJSUAAAAnJycGAha7+/vvb29 5+fnzs7OxsbGra2t3t7e9/f3QkJCEBAQe3t7Y2NjISEhxggppaWlxgAh1tbWUlJStbW1MTExc3Nz IRBahISEjIStCAgIOTk5KSkpGBgYWlpaxsbWUkqESkpKKRhjlIyta2trvRAxSkJ7/+/3rUJr5+fv WlKEOSlrlIyUQjl775ytziFCMSFrraXGY1KMvbXOc2uEhHOllISM973O1mN7nJyl54yl987W1lJr zilK1kJa1tbera21paWtSkJznJS1c2Oce0Jz/97n7629zjlSzhAxjIycc2uUY1qMjISUhGOU58bO xjFSnHN73mN7xiFCvRg57+fn1tbnpZy9raW9e3OMpZy1Qilrxr3OnIyUvXOMxmN7tTFK3nOEzjFK 597e3tbWta2t3s7OlJSle3Ola2OUe3OchHulMSFjY1p7e2ucMRhjvbXGe2OUczFrpTFaxpSlpXuE 3pSlvVJrtSFCpVJjzlJrxkpj3qWttWtzhISclIy1a2OMWlJ7UjlzSjFrMQhSOQhSShhae1KEvaW9 tZS1nHOcezFrnGOMjEJzpWOMhDFjhCFazr3G1sbOpVJ7jCFSxoSctVJzrSFK3r3GtSFKvXuMrWNz 53uUrTlS1q21vWt7xhg51nOEvWNzxjFKtSlC1mt7pWNr76WtAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAWNNcqAAAF5xJREFUaEPtW+VjHEeW766u6WomtaZB45mRZMkyxXYcx4nDDJtsGJaZmW6ZjpmZ Gf/J+733qntGtmzL3r37tBVFnmmox1hPjvOLdTccMJHBT3g3r979O37k9lnnra0825vF/w9YJLqs PK/KigJU+0xBaCI9KxdAJiuiu6fptm+GfeXlezNz9IOh7pee1+j0tvvcxQMJQC/727A31U0OBO5i +1u+ojNvu0+OtatuvPyYjx5rP0dXXhOvPerOiibLViTG4La/YktSVF55PFRvDx+wr9vLK2baLYLx 1Ryq4JbrO934zu3hHPWEOYIOqD30fuSG74HQWXH4bcDvxSjufiWZ1ww89GcDvMyNwPwReu9BCIuV aHyBqvPcvXvIeNPNq8G+kj5fNnazIltUi1kr3/wid/OpU03tTV1rC9XvvezuxQ/CB3YmJWQ/nQuA difLqhzcZ9JaKEU/d7yBzHC7U5V9L+zumvw4Xw70ONusd3lZEYzYjUD9KIeQtD3kO8TvrGzyncCx RBdec1fS772dw26L6WcI03zZz4rOanlDLDCDVDJVeEXWFcP3KK/uPAL42bw+pDKAnSVaVKuolNFl btm7aIrWpAOF5U4a5tC4EeQNOx3a9sgvENjIdXogKeezOK8qka7vNlnpDg8EbpEtPasTRZFtl7k/ YMaPl6P63B4wPRHmndDSWZUviqCoOu106y7vqL2mVaZnpqny9Qdr75Arug0OFnjqwuTCRhDIFxQ+ 3dnqVUot6Gfl85gvfe66lZ8cuqrvALwFHm6XZdZ7lgvrmmtme4eyC8T7dnXfVOR5ZcWpYSYcH/zA 9rzfAeTsOqYlbgY32xQx+fpauUod9HsdIns3hN90W40MKpaznKPRccGPMg87L/fysFpzl6nGtTIG naHSrTLGVbHSKtIqiRH/q4IschVvUnfW5Fb9jwfe7yyrna6BM8uKcCQ+6edz687hcAJlUte4qTK1 Clq3TR2Tzb1yPfNxu3IONRBOaIoGt1tZPkgwdjMof+hY8H7pbbsJMzVROvCVceI6cJ2pSmrl06W6 Tg62vWyw9CLQnVPPVW7E3RXebdO+fr6yc533sNsw7/ndvCoAsEVsiVw4FxU7gRsAOnBwau2ksauC UEVx55WCf7/08yapTDu33Cvnh83jBkbE3rqH0zNyXMQw6HHhg8w60EkMP5PqOnViIABepG5IX41S mj2QriyzSzhkbxnNByv1u+UtOZ/kgmY8c8Wjd0sG3nsLRtuvoeYKpNVIXUE6/sfVSIEVSk21Eskm jQ0tJVRouuaxLRtvhkLGGhfnCBI5CyulBDXp5lZzfAc2BrkawgCkC/RUhaFStaoTXfvTWCm3z8XP l118KFxo7ybpOD3sevSOYS/pN5nFMcy3h3ciADGujojDRLpAhyLA7BRlG7XrRiEwS/dEw7NBkqFh fWqqm8bbQGJDJc7Cr4SP2mtmFGqjOAo09A36pZRJmHSWO4zfVa5pFZ6C8O32BTlX37r7uKqyOaVJ vqjwUWvBGUIyZCniNbS34xjjpHX8kx9qKD0RWE9rwGvDIAjdJGpBNyGhW8dXEayP9572DJ4/16w8 ilC5Ke+N2KOBx4gbKsuI9drLtE/WBLjf+0/mRsT7xyrWrgsk4jb0jdImiFSrYDE1rAHA4QCH0OLP xdDjHL941yNWJelI4JVZhmQ9yXYI+AKuXChI658+8RgFd1IOX8K7yB3JnUvccCMAhvUBuAtsB/D1 noVG8To82uVpysppWceebtdOhOwqjOFJGXXl/M/pe52ag1YoyiFyJ+9HBIP3hJhqI5ep1ZJ3Foh5 IUhqFmT5khtev6rBnxsOkP5O5iRzsMO0qaHNQhcsuHfzx9eYE1qYOdAu3wPxEqEa8h7lEaozJMB5 aYxm8SdHET+SLvZezrOUA45PVIUqnjLDnZ9svvM+2sKVjHOEHrFKtPQbZjkovrOXA5/Qho7UYx4e RbwlnQlL9ayAWA/IZaSI4IBSWz8W/cPmy+8BGJs4jdB94gz5nakGG+o6lnTDrTr8ztjz+0uxtiOI t6TXBT/AywiLEpYhEQSdgk+/d2PzU87A2kHuEAWzpnXJI+CdNiL8wnhKPsTPqiIqqiGzLwmjQysT hV/k1seQt5FLIWkBSTSCr4mBEMD/xzX78ki7Y2rHZxQZCe0iKYRO+unMI+OIy+xgjK/h9f42YfVw jBNt57lYZDGHBsO78X6i6HAyOjpP4E8/JOBX0KeIPzpKEXFwWcE5AboO/Vpt32jgQx0y0N+LGcAd Nqpghgde42qtpo6P7aZWySKNJEo9/S8bm5uPCnSxuIQux6xTChLwFdACLxS54HZNx+OsoGe0d9jb b7NChA24tJD0Yqeq9XR4SEuYgVJRk6J95NsbG5uPfz6gCBuEBqGljoJaniHlD8CpuoYTQLIRjTqe lElVlqQe6WGjmw6eBrd6Ri/xavhXm+dMYUFncXFqfUsbP7wJ7r/Fnla3ERPNakZ0JwxdudCCgKQ/ 6HhdhJ7PscnZGao8fuVAtDBGZepLy4uNMnKlRifSH7t8+cnv//tDzA3I4+1NkP89RBl+gPEdnG5L 0AMooEHMIYZYAw9RHjgN79geYn3FjDdN5FodsfhiD3iLhJ3H2SdBL36efPvf/vsNxyHqNx/+7Cp1 T9niWUcik0auRqoZMfOsSjtFEzrxgojz11mfcFbhsKu1Ck/hiDFy42BwLZ8geulnc3Pz8pP88Z23 RtqJI7xU2LYKSmedMa40wui0iA6AFX1s1moULbA4Fxd/JMygFcQIXUFEDlz/vQW+wVjILzg+u6Bg grCGzKNoCES4EotahX3SOT7DVdvja04puCGy6xlHw1CYIQt5k1vXEfTp/GMvEeUkAP6XJfGp4Tkj SoLkEhE+aOEXx6aNTXJ3nP6gYbihuHxe25zzxhQGC9a5fjuMmNyA8lcTUKboh+DZWYj7EHh8e4nM gbCEOsPbqJZMJaE8Y0whrW8t87xxRVNWgk/F8/VdicqI71V7JopqHUQUMii4wYm6qia1epToFaot HoPjS1ykNyryY66psRGhKysWHWePWfCVbBStkUzObfe6yqZ2jA6qo2nqTuMrJ2Q9/bT8e2Vj1165 8uZp8ju/+8WTJ1+5Gqhffg5Ut1fv37/v/g9MT+5K3BNS2cwTSlwMM3q2GG4V4maTHSR2NpOUWxHs Dbnar16Y0PrqU7sn9/HvfV/b/MOP8JXf/B142ofeuH8y+a3f2J9c+sCFE+D9ByZbz566NLkw2WWv K8uSyvrFmmUVHZ96trLQ6/V2xpyXC7LgLpOn9rcmW79GArs62foVVX9/8/LJydbkGy9v/vS1eHpp svW1z0XJCaBzCjLan3wUmdirk61dpx0FX4g7o32nvLkZ/Y24fmq7KRG7XLBLT53PEqz3EvNOTD7o XAyce19+fWsy+SVw/ZN/Bsrv50dfmUxA+3OTSzVorrdAezQWhbEIt8iQNIlHHqNsx8DQ9gIKcofz rymrf0oly0nA+hBuv3/yPAILrj/2OvB5gbT/9/DhKr+V3ke0n5mcNMpM9SlATy4OJATWhOtszzZY PfuvRWOG7ofHKPqQfxJrw2kKR3Ci/YEI+5+h4pGeAZ+3XgDwxy9NJvsWxoeI9snkAioanZwH9FX0 tzAMjnNcOb0Z+StVBPStSFkTjYe6jFK6WNsq9SRgPTB1Hpw8NQS6E5b2j+POr1voz+yDdlzf5XB3 aRdmNPqUjjU96o0r5ekI3RcRZI4uxc9Gq44vavKLcRzfA84/EOxOnqO7LLdTuEK0P0jy//SLDD9+ lmmf7J+iR66eX4cupPr+1NboDuf2TCojUxSRQa8ES9u+I31OTY0kgjn/1IWTjBtDJ84/+NLm5XsA 7Q82TrO3j58GQFjHZPJ12dmRMoTWQrxLTbW4+DZrV5bUVdNitp6JMTBwfjK7f/LqOvQt6NjbL90H YH8JHvwjQScJwgRw6dL7GdiK83ZPL8+apqBbhQViXd1BM5y0FItgtdo6SPwzoOh5bPtRXCdmBMFX 8O0rQfAGIG2dI91/8jPIrXDjw0T71mT/gz6+uChzZR0IMFDu+6xm10GH3u1IV3RWIWUaF4rD+B7a Ev+fwReqFt1rr+DbK64bkss7xz5/462LdPNjkAU9PDml3Iv4z649ho6egJku2f0P0C3nfeT8Fct0 uMHYWosjGrHllVHu+AYdIxWfMO2IOz9kKafkHPCzD3Nd4zxbU1T4WWI4yl1He5MPp0yzJcOVJdCx 2xcuYM8L6ah1JHdS8S2hnSLe4xJrHxRUn0NGMGrdHrt4U6QF9SKwhjCTSObBmQ1/soog0LmKZJ1/ jiCdGCxOvDrT/vsU6Jj6y6jvsT6MYLQ1ObnubcTiIj64ZrnbbGtwuQZBPGbprOydvhH32N7DM2TL qVTu5G2I86QRJ158YqD+9F99kTaISU0nYwaOS5kkMESdnJVf7+sWs4OcQ1G4lt1z+sy0f6jdpS2/ JOXLCZH7Zx4ERs9Lhst53rkLtH+UEqZDik/PS6d6tjdDOckMHqHLHdA+NIgPVXlkxeRpEePI7Le+ Ofp5cD74AhB6Fm/fy+nO5c1zk0+8SPXsLtFObVW7ZEs6wF1ICju2vgc0mmWaMF7V2gkEE0Ba94xy zpOUz3yMHjklnA/afXygYPjYOxsbf/r1y+cmf3L6PaRseNBBKmqX8Thg4oAFrpSvjS1jm1yXXr8j 9XOz4wRG2nvSoSHpXkFN8TyBfy9tdApsIOiKPnz5oYcecs6+9Df73zp9bnLp5c1/QqG/NXnQWSW1 Spw3HU1Kmm9LCMKIbTHQaAE64ocqgyYE6kC+jnhOUryKvc6TLn+VoJPWfQm9Ohe6uLX/JuqLzb/7 xn0/Aue3XtjYeOLslckkCLia5iU5+7Tg3enXyq7aMabZZyOP37Niuzi9SkDveQSYPcteLI6fQaq3 tf8A2lnxMzCvj3z7yTf/aH//49A6mMVfbGy8eR9IX+W0jhyNJhnimc0qlwNi6zouQhE9TAX3iHSO oL5GgY0+fpk/YJ0kX/R+RglQPw7FOzd5Fcj89v7knnRN6RJuYFCbtuipjzQwgy8OjYsAB4xsjNYV 1Oyqpo/s0vrmI6898t4Pf3R395kPnj/PV3Z3nwou0hNXXt2fnHn9YXI4f/2tlz/x+smTz//xEz8+ OxR2sFoRu3HczB6dDOfEuCr5bkszK9TwGJsLLaPiX6PuRXzR9mTW7WjNm90LyVubpyoTX/71rVHs Sykaq4NUikgkb2O660i+66MzavNd21wIqH4mLW3VNepKyxuh7ZbR57XM7W/flRJr890f/IBLzKG7 QgrOhm/aEOUKU2RzXOGIZDeBoxtbv9vmPDcFU5y78Su2Ozq0Ca6DHsWPSl377jV08VPnxe9+5w1b 4dlyJdxGWhUzIusVg63pik5P7TGirXmdOECbFH0ARtIWpb5tITH0VfcAPvHFx7m6PX3tET4zoqYm r0HIU+PUC95rTeyDlvmxg+asFF+2dYkjP1QTQx/AFqUrJ7LOeW7yfOc0Mf+dz6nX0EwagOu1clnK 7EMV+lhVocdRSjElvUtfunWRpRCnLyTzlQNdg47OIG61f/4wMf/T74vHTvFISTFgQw3U1WdqYYkm NXmRJOKcifip0sJz27yK1bQFhfD8aRIZuBpkUjqOEtJtcS0qjb77BMA/cRYHCraGHPrPXTbOYK1a IwJWuhc41EvyHbY/vGOU9LeoGSJItDU6ItxLUHUcRTgZUWGE1gqyNZbKlLs10L7NT+N0VtEMEnK5 sUejtg+khbLeGhFYdNlvYtM5cpbYLRWqdzFZnx1HgIPPGk2ZGi0CwcpyPghBqQ5TR0+ptef4j29u fFIHAQ6H6WxAGigGpVrXH90jt6MKKGgyIyephg6zWqs6THyC0g6NegAZ6/LR3hPXEFpOLSH9Pac3 PokTS5yZJp6Ea+NV3PsgWm4Yg7GNWt2gg1t0jG0/x9M20qAzDraqOmJmyIn+ina6hLYs2rpMLVb0 sf/a/BEhrLhBjzX13YyjKDF6dIJ2m6GdqcngjE2+8Q8nlVg4nVBQI+leTscO5WjvuKfCNIVCkNKm +P3P776NT4UVcbgDW6pF1StyqofX2nkF5pukX06zIjB32q5VKoVIVcQp+tq8iewCewsgpEShW63R boGgng4f/RSVw3w/yYzKF9IeWDf/AYeBeNMuq8iXA0sX/tkQLegfGYWtwXI2gzFhG+QOxlNrmA6l 4BxjoEjh+eznc7Elh843fDv2s7KBNfot8X4OLTFa3irnEJcPb4M+QqtChcOWgOgeWT9wHoyHfcjR ALV68A6QWc0xFOCiI22DteOnNeij5HEttDWV083DEJrO3LeDRoZADKHb0s6nB5iAEEcV6xaNPxxn La2xofuCOYBADgWPJB06bg+uEqjKLK7EAXR5aE9f4XZlc4IBTqcB+pmtihIISQIXn8biHqZBcCpM 79rE9CCPw8bbY6kP5r9GN38czodBOJqyiQx/+N28R9uXP0+FB+hJ4mgQXkfHce3Cobst21no1nRC ja4mzodxDrscZq3ixs2HOcOEBHvkkuN3qAicpt8MB3Qdgm4kPoTP3aFz6PxjyIM+EudTOpGmSYwI Z+P4KM+a7YHyMNNBuOykedFsD27yBhSy8aAs7BZ+KcbiN8hwrYHTzAF0WunUnhOJ1tEZoKLDXwdV nk2A8s46xERmtsSBxreYO0mG0bCMDunhmwQ/DCgOzg0ydfU0gOjlxHeYu0DYtccYAtxdDfV1YUmm JinizQ//+SVRrJAMrhyFFefbtiZKhLGhmvLgg3CeQil0Ak49JKGRb1mbaYPzKeeSmjnZzQcf6HYz F8cKLYKtj/VAsJDx1NYlLccHiABjNpJZkZUndBWoSa2YjyOePPUI0SyljLsusvK9teVXQ+eapoww OjO02Gk8FQeLoHfKrj5WCfXtiXaQToNH5I01shEM4GI0x67E6yhBkXHzyLrd64GuvodDN88gJ9Cl lh4uVlp4uUSHgPQ9rTHnQJ5Ppm2AEEfzusy8vbFdAg42QLsUrZkOM0c3h74axsIZBhBAZjJmEjve fEaGnUIAKalZnaLEVKGPcQuEcgx9uBizWpUJLsY8NPJkYbu/HMbHbgEdwhkyCpJZuYyWIy1pse11 lNFivm2akmkHbqsDYDFF+NV7mDCQ8M4rMykSQEjSuq38+qh+JBbl2lFdkfuYaxvDOR1l58iPdIQ2 dIisEj9GtaFb7uGPBxqbg/KuSSj9wbLgf8hl34rm1b0RfFKSv+q7epylpofMjP5MoaoWTba3h5+K WutdTzN/40qy3lAqkWrqst8JcBpBtapOgTaEpuo16hlCGM+KLMsW9NPPVqeOAt7vexdTrdRzFy04 PuXMrgE8wmTX9xhlvYOV+D4MJuvDedVZZ31stguY1QBugxYTia7Ps+PMw6e6p1G8xg/RMLCSxmjw MWU+0Ig5ISvHuCGvphH8dRGt69WN7ICU/d6YLMvRBiuXQykyjAbfAf/MGKR8+hsM6qpFme+V5U2l oBvypEnvZL7J8qEQgQWPHuMOwCeddG9kZfDjOw3GNH0oIsYn4L/MTDsJnXoazJMDuWzbocZ/41Cs lcwd+pbd1r3eBKd+bfZdH6CzYppFD0U2EClBDFWXdPAmOFZu0AnJPHg2KEmS2iM3bIvJ7zsU+QoX zHKO5OtsL3a8kFpuPBtvKF5VGKGN/M7Dpap1K5Pmxs8cf3COGLA8jqbeTCD0lw9ruDeSd84O6Dc1 +TIzm2276GlHOtueLhRkwkMlsjAEu3L6NwNxy+smW/9jGQnXMXIE3ycrysPCx7G1B/+SVEmzs+7u MNgqh/k/0zriD2/cLNvBSLVBg7dUutdeoctBzSwsvIU/nvh5LIJ/hO4kEdIKOea4bqU/P9i0M3br jv2nZ2GJYe61SPtzYIApPa/kTsitV+h2XjUO993u6ePfx9++IYTLhOHRK+UZ+tv9Dd3xIV73pM9/ l5gVq2GS4YEkKuTWXfuW4yGV6B5/ukDTtllfzPAfhkXpb8a6xsby423zszzlm7goekotFtlOgbn6 /2OSfxZcf/HuURz4X7OZop4c5RHQAAAAAElFTkSuQmCCkgkAAEQAZAAAAAAAAAAAAAAAAAAAAAAA AAAAALgLbQsfAXkBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwmAAAALIECvAI AAAAAgQAAAAKAABjAAvwdAAAAARBAgAAAAXBUAAAAAYBAgAAAIEBEQAAEL8BAAAQAP8BAAAIAEMA OgBcAE0AeQAgAEQAbwBjAHUAbQBlAG4AdABzAFwAVwBvAGoAdABlAGsAXABFAFUAUgBBAFMASQBQ AF8AUwBJAEcATgAuAEcASQBGAAAAAAAQ8AQAAAABAACAYgAH8KYIAAAGBmmHvpDadqDZxOBtyi0P zbj/AIIIAAABAAAApR0AAAAAwQAAbh7weggAAGmHvpDadqDZxOBtyi0Pzbj/iVBORw0KGgoAAAAN SUhEUgAAAMgAAADDCAMAAADwQa5vAAADAFBMVEUAAACAAAAAgACAgAAAAICAAIAAgICAgIAEBAT8 /PwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADAwMD/AAAA/wD//wAAAP//AP8A///////+ GzE6AAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAUKSURBVHic7djbEqMwCADQPur///DO7OxG kwDhHnTkKdUKnKqJ9Xe+JH67G/CKD1ItXgg5nhcQZHdPupgh42ZloGX8A4f4pY9XtFrXpx+wzZo9 xzH8+r95kzV5EuNvsWscAnHKxSnWxhEQp1SsYm3sDEl1fBBW5kRHHCTZEQbJdkRB0h1BkHxHDGSD IwSywxEFMWYwFv0gRM60+CB0znfc7K+Zft+zIL4HIpE4vaHY/fTr9s5o8/+RfwYHyd5/iBfALNn6 n/1+IqySna+D+gvKeHlFQhaSca9NEgohJfM+kyQWQvQG7bBIgiFob7LNvEJtHAFBJKITxa3TxiEQ UEK0q5XEQ4DeyGaVkgzI2NuiVZ1kA2Q1NxWGdL2t51iVJAcyPB2uCmgkSRDh87pCkgUR/oOSS9Ig 7aQIvizM3sbBEFlIJWUhUokEYnrMloesnAAiuVl9QlKNDblmnZoSLuS/oKyECbklLCrhQbp0NSUs yJCspIQDGVPl3id+kDlTRckaAuUpKFlC4Cz1JCsImqOaZAEhMqRLlv+P23iGkIfXkpCQxcGlJBSE czrLSEDI0Q/o5NYG+bG60Nv4gvwPW273oKqREGNu/6An0TYeIdbcAYFXIyDm3BFBLdBt3EPsuUMC q4ZCZKn3P61gEGnu3ZLDA1JBgkEUufdKnCDbn1YON8heyeEI2SkZJ1r1zX6lszYoKnZ/Skch5SWt WnsSMa/sc+6cOMZoe3TPWmNupzaZ1TiQZ8xdLMjDJG37DCkuEUBKSwSXlhaSIxFBCktGxwJSVjI5 VpCa68nMWEMqSiDHGlJPAjoYkGoS2MGB1JIgDhakkgRz8CB1JKiDCanytII72JASEsLBhxSQUA4B ZLuEdEggmyW0IwHiJXGEbJUsHDLIvvVkxZBCdknWDilkj4ThEEN2SDgOOSRfwnIoINkSnkMDyZUw HSpI5hrPdSghaRK2QwtJkvAdakiKRODQQxIkEocBEi4ROfIh/MPSIMESmcMEiVwZhQwjJE4idhgh URK5wwqJkSgcZkiEROOwQ/wlKocDxFuic3hAfNd4pcMH4ijROpwgbhK1wwviJNE73CAuEoPDD+Ig sTi2Q47x836IdT0xMVwhNonR4QqxSKwOX4hW4hG+kI0SZ0joy0ReYSeIXGIv2df1gogpHiWPEEjg e1FOUUdI3HtRTk1PSNh7UU5JVwhb4lUvDMKUuJWLg3AkfsWOQMha4ljriIQsKK6VjliI/1s4TqkQ yAFb/KskQI7RElIiB5ISH6RavB8CzzXjHXv/yJqasF3QkUTyOUccBOx41UW3X5Q8FjJ2vGqi3y9K Hgzpq2FAJQTOnQvBNkPFeMlXkP6nY0HQH3/lQ8ZzO5kQqNgdAvQwfUAh0IvvMMhcrHNAPQy1CAjQ XRxkytBDoDP1DMjggC85JgT4ehwE+epCcs6nEC0kggwF2JCpFpwP3kkkxzLkrSN0H+CuUhDCgT1j jMXQ4+HDYx8aQQc64bIg2KF+NztUignpKxDJ8eMCIGAZdkNwckAeDyGv09tX0JSREGqFbc1NENQx 9Zt2RoYmT6DWia+FcJ476gDGPpD+xyOnUaw3yAGxp5ShEGJC10LQlOmQubVuQQAdC8nUvD8En5yg Js7r3scqQzm7b0RBhl1wZ/erC+sBds+/jBFCxzKvJiwZTyWkWpyvhTxUcs6QR0pOCPI4yTnEb9zw 1Pgg1eKDVIvXQP4AAcYraZdmOkQAAAAASUVORK5CYIIDBgAARABkAAAAAAAAAAAAAAAAAAAAAAAA AAAA3gNlBPoD6AMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBaAAAAsgQK8AgA AAADBAAAAAoAAGMAC/A2AAAABEEDAAAABcESAAAABgECAAAAgQERAAAQvwEAABAA/wEAAAgAaQBl AGUAZQAuAGcAaQBmAAAAAAAQ8AQAAAACAACAYgAH8FUFAAAGBpGSed8yQefj640WqOVuF3b/ADEF AAABAAAANycAAAAAwQAAbh7wKQUAAJGSed8yQefj640WqOVuF3b/iVBORw0KGgoAAAANSUhEUgAA AEIAAABLCAMAAADzhaESAAAAA3NCSVQICAjb4U/gAAAAYFBMVEX////v7+/W1t7W1ta1vcarq6ul paWUrcaUlJSMnK2IiIiEhIRzjK1ze3tra3Nra2tae6VSa4RSY2tSUlI+Pj45UmsxY5QtLS0hSnMY SoQWFhYODg4IQnsASoQAQnsAAADiyCPtAAAAAWJLR0T/pQfyxQAABFdJREFUeJy1mItyqzgMhvGl MQ4mMfTgxWdtv/9jruQLmDQJkM66Mx2R0C+/fknGadP874twTn5J0NYZ/iuE9iEEy35BkA4IwQ+f 58JsiMurTwk0E0Jwl88IxBRC8PYjS4mOf221AUO8oZ8SjBRCSJRz3lKi0AIttAvOCOWC12cZEnOQ yqVkpLDAO8dADUYMi58DxE6eYBDUoOVaEeSBN/I4QaENOYnSGVao4wyifHCqEIzKDCcPMwgWQery 8YKUHnUSRuaIH1SHmuBIs8RBHdJBDRJWI3XT8NUQTE/t6GBmowHygBeryqCO9wxu40dVhcDbRah1 gLI3DOnxpkoD5gEG24oBEt3wauawmEnqNo+mqaEW+vTV3NLYzoPYdJSCe6mo2xT6FC6fbsnc+vi+ DZsFZpjtK3DPDGJ+7GMpiTCvhDTowdGIcJU2p9Dfx+Fn+ZPUsNyGN3BXVAjC5aovVV3XhpT8dS6f s/FdirsEaYboCW3IosTwOTm72pDfc8W3SCDKhrXBLVSBL4xcNrtMTHxkRZ+KmrWSgChV1ksEMvJ2 VgrTZoQtZhqEJ1s8jXsgrmHtj4LwbZbBJ7/Rl2SkPgkk9zdsnXRJRCes911GsHbyEeJ46YHYflwZ awUzbrZaUlIVPN/np0uuCuX96JDhqt4cRPSUUsYpIVCdenyjWu+mW0EQxrtx9ptU0BqjleBccKG0 qZtWxTT8PN5atvQX4+0tGuLEQztbIX82uI0SgMDJ2qKEXfoJp+RxSMBY6h4IU0qiv7BNjwOjG134 MaqAIJsXLIfHNCbR1RKKqW1k6A1DPSDmOHxAuDw7xoEhaKpTsvobsUVYLIyfxscklmTAVGRItUFQ XxNgeIHAnxOiIY8MUW+dM2oAIzv++gy4MPQzRHzUu1jLl4QnOmBvKqc23DS92/TTK0ZfM5wxZiE4 BwQwcud5VhhqeziAWlsXbCS8B9SMuk8tPNUdNNSrYr5g6HVe8MDmgjumITNuOPyGJ0MANoTo5FFC ZECvOzzpmRnOjDGlU4TCCDh0nHOcinMaIoO3aUOFokYW7lCnCA1ZGGn5RPi637+OQxjvZ18RsCev 33++r9dTjNJcbk5zcW/+/Qd+Hc8FLE0y/IxbVIOIv3/PICpLx7zJfX/9uV6/TyCA0cOO7P3Ul/3h fr+fIqAd8Ig6X86NDNaO4/4G8Z7BL/3B4Xyjg/HdLWa7uNa8EVor+IEILnsNV7KhKr24dwLH8y98 u9Y+rYHIElGeo/0vrIhgyvt5gtVRmSNAhBwdQ4CKGwcPGF5OMSKgYm5jdFiF7pSOiHmACFyBHAal 9P6X96IirrYpXnQkeXHk/xBJBQ533/cc7ZwxuhD0YoSo3f3uXlQMnGLacDliRDGR+RKjo15YeIgZ FRPBSMdEYrTLULUXEytezGzpi10/2TC2MOPj7XYbbi1lKRo7xjqMbnCy2M2EwEQQwiBrBod/PHei AZTECNcv/8v1fP0Hy9DCyp7c5GUAAAAASUVORK5CYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABIAEQAKAAEAWwAPAAIAAAAIAAAATgAAQPH/AgBOAAwAAgBc1ADJAAAUAAAA AyQDMSQANCQANyQAOCQAYSQDJABLSAIAT0oIAFBKCABfSAEEYUoYAG1ICQRuSBIEc0gJBHRIEgQ0 AAFAAQACADQADAAEABzIqbogADEAAAAOAAEAAyQBBiQBQCYAYSQBDABDSiAAT0oHAFFKBwAAAFIA AwABAAIAUgAMAAQAHMipuiAAMwAAACYAAwADJAAGJAERhHgFMSQBNCQBNyQBOCQBQCYCV0S8AmCE eAVhJAASADYIgUtIAABPSgAAUEoJAF0IgQAAAAAAAAAAAAAAACAAQUDy/6EAIAAMAAgAMK74vCAA 6LJ9tyAAAK40rwAAAAAAAAAAAAAAACYAVUCiAPEAJgAMAAUAWNV0x3zTwbls0AAADAA+KgFCKgJw aAAA/wA0AFZAogABATQADAAMAFjVdMd808G5bNAgAOSyTMcgADi7kMf0xQAADAA+KgFCKgxwaIAA gAAAAAAAlw8AAAUAACYAAAAA/////wAEAAD+DAAAJBEAAJMTAACXEwAACgAAAA8AAAAQAAAAEgAA AAAEAAANCgAA3QwAAIASAACXEwAACwAAAA0AAAAOAAAAEQAAAAAEAACXEwAADAAAAOsOAAARDwAA KA8AAFAPAAB6DwAAjg8AAJcPAAATWBT/FYQTWBT/FYQPAADw8AAAAAAABvAYAAAAAggAAAIAAAAG AAAAAQAAAAEAAAAHAAAATwAB8LAAAABiAAfwJAAAAAYGH6F26T4UPKdf/DOzh4STIv8ABxsAAAAA AAD/////AAAAAGIAB/AkAAAABgZph76Q2nag2cTgbcotD824/wCCCAAAAAAAAP////8AAAAAYgAH 8CQAAAAGBpGSed8yQefj640WqOVuF3b/ADEFAAAAAAAA/////wAAAABiAAfwJAAAAAYGRarKxgaa nxEHElhZQLvyof8AXWsAAAAAAAD/////AAAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALw kgAAABAACPAIAAAAAQAAAAYEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAA ywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAAlw8AAP//AgAAAA0AXwBIAGwAdAA0 ADcAOQA2ADYAMwAwADYAMQANAF8ASABsAHQANAA3ADkANgA2ADMAMAA2ADIAfg8AAH4PAACZDwAA AAAAQAEAAEB/DwAAfw8AAJkPAAAAAAAAoQIAAKgCAAC4BgAAwQYAAEgIAABUCAAAwQgAAMoIAAA5 CQAAPQkAAG0JAAB5CQAAjQkAAJIJAACTCQAAnAkAALMJAAC7CQAA+QkAAP4JAAD/CQAABgoAADgK AABACgAAUAoAAFUKAABxCgAAegoAAMAKAADICgAA3QoAAOYKAAACCwAABwsAAAgLAAAOCwAAKgsA AC8LAAAwCwAANAsAAIQLAACJCwAAyQsAAMsLAAACDAAACAwAABsMAAAfDAAANAwAADcMAABHDAAA TQwAAE4MAABUDAAAgAwAAIcMAAClDAAAqwwAAB0NAAAfDQAA3A0AAOUNAADnDQAA7Q0AAJkPAAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAAAAAAFsNAABjDQAAKQ8AAC8PAACZDwAABwAzAAcAMwAHAP//FAAAAAoA SgBhAGUAeQBvAHUAbgAgAFkAaQAbAEQAOgBcALXR4MKpxlwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAwASgBvAG4AZwAgAEIAZQBvAG0AIABSAGEAKwBDADoAXABqAGIA cgBhAFwATABhAGIASgBvAGIAcwBcAPzIXM1cAFAAQwBTAFwAUABDAFMALQBjAGEAbABsAGYAbwBy AHAAYQBwAGUAcgAuAGQAbwBjAAYAdgBpAHMAYwBvAG0AFwBEADoAXABQAEMAUwAtAGMAYQBsAGwA ZgBvAHIAcABhAHAAZQByAC4AZABvAGMABgB2AGkAcwBjAG8AbQAsAEMAOgBcAFcASQBOAEQATwBX AFMAXABUAEUATQBQAFwAkMfZsyAA9bxsrSAAAMilx1AAQwBTAC0AYwBhAGwAbABmAG8AcgBwAGEA cABlAHIALgBhAHMAZAAMAEoAbwBuAGcAIABCAGUAbwBtACAAUgBhACsAQwA6AFwAagBiAHIAYQBc AEwAYQBiAEoAbwBiAHMAXAD8yFzNXABQAEMAUwBcAFAAQwBTAC0AYwBhAGwAbABmAG8AcgBwAGEA cABlAHIALgBkAG8AYwAMAEoAbwBuAGcAIABCAGUAbwBtACAAUgBhACsAQwA6AFwAagBiAHIAYQBc AEwAYQBiAEoAbwBiAHMAXAD8yFzNXABQAEMAUwBcAFAAQwBTAC0AYwBhAGwAbABmAG8AcgBwAGEA cABlAHIALgBkAG8AYwAFADjWIACUxiAAMcEgAEUAOgBcAFAAQwBTADIAMAAwADEAXABQAEMAUwAt AGMAYQBsAGwAZgBvAHIAcABhAHAAZQByAHMALgBkAG8AYwAEABVckg1YYdzW/w//D/8P/w//D/8P /w//D/8PEABoHucxWGHc1v8P/w//D/8P/w//D/8P/w//DxAA7wa2PlJO4kX/D/8P/w//D/8P/w// D/8P/w8QAHIN43sBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQABAAAAFxAAAAAAAAAAAAAAkAEAAAAA AAALGAAAD4SQARGEcP4VxgUAAZABBl6EkAFghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAA AAAAAJABAAAAAAAACxgAAA+EIAMRhHD+FcYFAAEgAwZehCADYIRw/k9KCgBRSgoAbygAAQBu8AEA AAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP5PSgoAUUoK AG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4RABhGEcP4VxgUAAUAGBl6EQAZg hHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+E0AcRhHD+FcYF AAHQBwZehNAHYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAP hGAJEYRw/hXGBQABYAkGXoRgCWCEcP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEA AAAAAAALGAAAD4TwChGEcP4VxgUAAfAKBl6E8ApghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAA AAAAAAAAAJABAAAAAAAACxgAAA+EgAwRhHD+FcYFAAGADAZehIAMYIRw/k9KCgBRSgoAbygAAQBu 8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCEcP5PSgoA UUoKAG8oAAEAdfABAAAAFxAAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4TIABGEOP8VxgUAAWgBBl6E yABghDj/T0oKAFFKCgBvKAABAHfwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EIAMRhHD+ FcYFAAEgAwZehCADYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsY AAAPhLAEEYRw/hXGBQABsAQGXoSwBGCEcP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAA kAEAAAAAAAALGAAAD4RABhGEcP4VxgUAAUAGBl6EQAZghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQ AAAAAAAAAAAAAJABAAAAAAAACxgAAA+E0AcRhHD+FcYFAAHQBwZehNAHYIRw/k9KCgBRSgoAbygA AQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhGAJEYRw/hXGBQABYAkGXoRgCWCEcP5P SgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4TwChGEcP4VxgUAAfAK Bl6E8ApghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EgAwR hHD+FcYFAAGADAZehIAMYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAA AAsYAAAPhBAOEYRw/hXGBQABEA4GXoQQDmCEcP5PSgoAUUoKAG8oAAEAdfABAAAAFxAAAAAAAAAA AAAAkAEAAAAAAAALGAAAD4QgAxGEcP4VxgUAASADBl6EIANghHD+T0oKAFFKCgBvKAABAGzwAQAA ABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EsAQRhHD+FcYFAAGwBAZehLAEYIRw/k9KCgBRSgoA bygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhEAGEYRw/hXGBQABQAYGXoRABmCE cP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAAAAAAAAAAkAEAAAAAAAALGAAAD4TQBxGEcP4VxgUA AdAHBl6E0AdghHD+T0oKAFFKCgBvKAABAGzwAQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+E YAkRhHD+FcYFAAFgCQZehGAJYIRw/k9KCgBRSgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAA AAAAAAsYAAAPhPAKEYRw/hXGBQAB8AoGXoTwCmCEcP5PSgoAUUoKAG8oAAEAdfABAAAAF5AAAAAA AAAAAAAAkAEAAAAAAAALGAAAD4SADBGEcP4VxgUAAYAMBl6EgAxghHD+T0oKAFFKCgBvKAABAGzw AQAAABeQAAAAAAAAAAAAAJABAAAAAAAACxgAAA+EEA4RhHD+FcYFAAEQDgZehBAOYIRw/k9KCgBR SgoAbygAAQBu8AEAAAAXkAAAAAAAAAAAAACQAQAAAAAAAAsYAAAPhKAPEYRw/hXGBQABoA8GXoSg D2CEcP5PSgoAUUoKAG8oAAEAdfABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SpARGEV/4V xgUAAakBBl6EqQFghFf+T0oKAFFKCgBvKAABAGzwBAAAAO8Gtj4AAAAAAAAAAAAAAAAVXJINAAAA AAAAAAAAAAAAaB7nMQAAAAAAAAAAAAAAAHIN43sAAAAAAAAAAAAAAAD///////////////////// //8EAAAAAAAAAAAAAAD/QAIQAAAAAAAAAJcPAABQAAAIAEAAAAsAAABHFpABAAACAgYDBQQFAgME AwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1 FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpAB AAACCwYEAgICAgIEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAAAALxWQAYEAAgMG CQABAQEBAQEAAAAAAAYJEAAAAAAAAAAAAAgAAAAAABS81dC0zAAALzWQAYEAAgsGCQABAQEBAQEA AAAAAAYJEAAAAAAAAAAAAAgAAAAAAMuzwMa0zAAAVxKQAQAIAAAAAAAAAAAAAAMAAAAAAAAAAAAA AAAAAAABAAAAAAAAAEMAZQBuAHQAdQByAHkAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEA bgAAAEUmkAEAAAILBQICAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABDAGUAbgB0AHUAcgB5 ACAARwBvAHQAaABpAGMAAAA3JpABAAACCwYEAwUEBAIEhwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAA VgBlAHIAZABhAG4AYQAAAC0WkAGBAAIDBgAAAQEBAQEBAAAAAAAGCRAAAAAAAAAAAAAIAAAAAAAU vNXQAAAtNpABgQACCwYAAAEBAQEBAQAAAAAABgkQAAAAAAAAAAAACAAAAAAAdK28uQAAOwaQAQIA BQAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFcAaQBuAGcAZABpAG4AZwBzAAAAIAAE AHEIiBgAACADAABoAQAAAAB2W0dGdltHRu/bRIYDAAAAAABBAgAA2gwAAAEABgAAAAQAAxAbAAAA AAAAAAAAAAABAAEAAAABAAAAAAAAACEDAAAAAAAAAAAiABMAIQAlACkALAAuADoAOwA/AF0AfQCi ALAAGSAdIDIgMyADIQkwCzANMA8wETAVMAH/Bf8J/wz/Dv8a/xv/H/89/13/4P8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACgAWwBcAHsAowClABggHCAIMAowDDAOMBAwFDAE/wj/O/9b/+b/AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL0C iQO0ABEBgYAyAAAAEAAZAGQAAAAZAAAAyA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD//xIAAAAAAAAADQAoAFAA cgBlAGwAaQBtAGkAbgBhAHIAeQApAAAAAAAAAAoASgBhAGUAeQBvAHUAbgAgAFkAaQAFADjWIACU xiAAMcEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJABAAASAAAA AQAAAJgAAAACAAAAoAAAAAMAAAC4AAAABAAAAMQAAAAFAAAA2AAAAAYAAADkAAAABwAAAPAAAAAI AAAABAEAAAkAAAAYAQAAEgAAACQBAAAKAAAAQAEAAAsAAABMAQAADAAAAFgBAAANAAAAZAEAAA4A AABwAQAADwAAAHgBAAAQAAAAgAEAABMAAACIAQAAAgAAALUDAAAeAAAADgAAAChQcmVsaW1pbmFy eSkAbwAeAAAAAQAAAABQcmUeAAAACwAAAEphZXlvdW4gWWkAeR4AAAABAAAAAGFleR4AAAABAAAA AGFleR4AAAALAAAATm9ybWFsLmRvdAB5HgAAAAkAAADIoyC/5CC8ugB0AHkeAAAAAgAAADMAIL8e AAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAAAQAAAAAAAAAAAAAAAQAAAAABKNmMUsL8BQAAAAACk /wb06r8BQAAAAACk/wb06r8BAwAAAAEAAAADAAAAQQIAAAMAAADaDAAAAwAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoC AAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmu XAEAABgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACgAAAABgAAAKgAAAARAAAAsAAAABcAAAC4 AAAACwAAAMAAAAAQAAAAyAAAABMAAADQAAAAFgAAANgAAAANAAAA4AAAAAwAAAD6AAAAAgAAALUD AAAeAAAAJgAAAElTTCwgRGl2LiBvZiBFRSwgRGVwdC4gb2YgRUVDUywgS0FJU1QARQADAAAAGwAA AAMAAAAGAAAAAwAAAMgPAAADAAAA8Q4IAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA HhAAAAEAAAAOAAAAKFByZWxpbWluYXJ5KQAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAABc AgAABAAAAAAAAAAoAAAAAQAAAFIAAAACAAAAWgAAAAMAAACyAAAAAgAAAAIAAAAKAAAAX1BJRF9H VUlEAAMAAAAMAAAAX1BJRF9ITElOS1MAAgAAALUDAABBAAAATgAAAHsAQgAyADMAMgAyADgAQwAw AC0ANQA3ADMAMgAtADEAMQBEADQALQA4ADcAOQA2AC0AMAAwADYAMAA5ADcAMQA5ADcAOAA2ADMA fQAAAAAAQQAAAKABAAAYAAAAAwAAABAAKQADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGwAA AG0AYQBpAGwAdABvADoAcABjAHMAQABwAGMAcwAuAGsAYQBpAHMAdAAuAGEAYwAuAGsAcgAAAAAA HwAAAAEAAAAAAAAAAwAAAHAAYwADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGAAAAGgAdAB0 AHAAOgAvAC8AcABjAHMALgBrAGEAaQBzAHQALgBhAGMALgBrAHIALwAAAB8AAAABAAAAAAAAAAMA AABXABcAAwAAAJMTAAADAAAAAgQAAAMAAAABAAAAHwAAACgAAABDADoAXABNAHkAIABEAG8AYwB1 AG0AZQBuAHQAcwBcAFcAbwBqAHQAZQBrAFwARQBVAFIAQQBTAEkAUABfAFMASQBHAE4ALgBHAEkA RgAAAB8AAAABAAAAAAAAAAMAAABLAAEAAwAAAJUTAAADAAAAAwQAAAMAAAABAAAAHwAAAAkAAABp AGUAZQBlAC4AZwBpAGYAAAAAAB8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAA AAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAA EwAAAP7///8VAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAh AAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA/v///ywAAAAtAAAALgAAAC8A AAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAA/v///zgAAAA5AAAAOgAAADsAAAA8AAAAPQAA AD4AAAD+////QAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAP7////9////SQAAAP7////+//// /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQA cgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf////// ////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAYPxkFvTqvwGgqlAZ9Oq/AUsAAACAAAAAAAAAAEQA YQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FAAAAPYsAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAArAAAAwhYAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2JgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJ AG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANwAAAAAQAAAAAAAABQBE AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/ AAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAABmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAA AMAAAAAAAABGFAAAAE1pY3Jvc29mdCBXb3JkILmuvK0ACgAAAE1TV29yZERvYwAQAAAAV29yZC5E b2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== ------=_NextPart_000_003D_01C02DDA.EC7B5500-- From rem-conf-request@es.net Wed Oct 4 01:24:20 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02495 for ; Wed, 4 Oct 2000 01:24:19 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ggpE-0001I6-00; Tue, 3 Oct 2000 22:10:40 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ggp9-0001GU-00; Tue, 3 Oct 2000 22:10:37 -0700 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 AAA09294; Wed, 4 Oct 2000 00:44:46 -0400 Message-Id: <200010040444.AAA09294@purple.east.isi.edu> To: Yoshihiro Kikuchi cc: Franceschini Guido , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision In-Reply-To: Message from Yoshihiro Kikuchi of "Tue, 03 Oct 2000 18:00:30 +0900." <038001c02d18$6335a920$16c77885@ave> Date: Wed, 04 Oct 2000 00:44:46 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Yoshihiro Kikuchi writes: >> When the short video header mode is used, RTP payload format for H.263 >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. You should specify which of RFC 2190 or RFC 2429 is intended. >This means that it is RECOMMENDED to use the H.263 RTP payload format for >the short video header which is compatible with H.263 baseline. Regardless >of MAY or SHOULD, there is a possibility that the H.263 RTP payload format >may be used, although the possibility may be higher for SHOULD than MAY. If >you really don't want to use the H.263 RTP payload format in some >circumstances, you don't have to use it. The payload format is signaled >through the MIME type. > >(IETF experts, please correct me if my understanding on the definition of >SHOULD is wrong.) SHOULD = "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." MAY = "an item is truly optional" [see RFC 2119 for the full wording] Colin From rem-conf-request@es.net Wed Oct 4 01:24:41 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02559 for ; Wed, 4 Oct 2000 01:24:41 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ggpA-0001H8-00; Tue, 3 Oct 2000 22:10:36 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ggp3-0001GR-00; Tue, 3 Oct 2000 22:10:32 -0700 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 AAA09317; Wed, 4 Oct 2000 00:50:31 -0400 Message-Id: <200010040450.AAA09317@purple.east.isi.edu> To: Kris Huber cc: Franceschini Guido , IETF AVT , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, "'Yoshihiro Kikuchi'" Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision In-Reply-To: Message from Kris Huber of "Tue, 03 Oct 2000 12:50:10 MDT." <6E031E06378BD311AEF20090273CE1BA81E6EF@el-postino.s-vision.com> Date: Wed, 04 Oct 2000 00:50:31 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A brief note - the issue of the timestamp is one area where I had some concerns with this draft, but unfortunately I haven't had enough spare cycles this past week to follow up on them. This is likely just my mis- understanding, but input from those who know both MPEG4 and RTP, to ensure that this is both accurate and consistent with the two timing models, would be greatly appreciated. Colin --> Kris Huber writes: >Hello Guido, > >I think you are right. It appears that the other alternative (change MAY to >SHALL or SHOULD) was taken rather than insertion of the MPEG-4 visual >semantics regarding picture rate in short header mode (which lacks >modulo_time_base, vop_time_increment, and vop_time_increment_resolution). >These were spelled out for short header in >draft-ietf-avt-rtp-mpeg4-es-04.txt based on a suggestion I made (e-mail of >9/8/00 "RE: IETF AVT last call on draft-ietf-avt-rtp-mpeg4-es-03.txt - >timestamp of short header VOP"). > >Since then, I have learned that a more typical way (I think) that >hardware-assisted compression systems are used with PAL devices is with the >picture clock frequency driving the temporal_reference/TR field set to 25 Hz >rather than giving rounded values of a 30 Hz picture clock. However, my >suggestion does match baseline H.263 and MPEG-4 short-header mode, although >I think H.263 implementers have been a little loose in their interpretation, >perhaps with good reason. > >Another opinion I respect is that a better partitioning of functions would >have placed all timing information in the systems part, as (I think) was >done for the audio part. But on the other hand you can't properly decode >video without some timing information (sequence number at least) due to >temporal prediction and B-VOPs. > >I heard no discussion of the text I proposed for clarification of the >timestamp relationship to temporal_reference in short header mode after Gary >Sullivan's clarifications and suggestion that MAY be changed to SHALL. I'm >not on the IETF AVT mailing list or at other meetings where the discussion >probably occurred. > >Regards, >Kris > >-----Original Message----- >From: Franceschini Guido [mailto:Guido.Franceschini@cselt.it] >Sent: Tuesday, October 03, 2000 12:20 AM >To: IETF AVT; 4on2andIP-sys; 'Yoshihiro Kikuchi' >Subject: RE: draft text for MPEG-4 Audio/Visual RTP I-D revision > > >Change (2) means that significantly different packets are generated in case >of Short Video Headers (H263) between the original proposal and this new >version. Am I right, or is this just an editorial matter ? > >Best regards >Guido > >> ---------- >> From: Yoshihiro Kikuchi[SMTP:kiku@eel.rdc.toshiba.co.jp] >> Sent: Tuesday, October 03, 2000 3:36 AM >> To: IETF AVT; 4on2andIP-sys >> Cc: Yoshihiro Kikuchi >> Subject: draft text for MPEG-4 Audio/Visual RTP I-D revision >> >> <> >> Dear experts, >> >> Attached find please a draft text for the revision of MPEG-4 Audio/Visual >> RTP Internet-Draft. >> >> The revisions are mostly to reflect suggestions by the AVT chair. Most of >> them are editorial and there are some minor revisions and clarifications. >> The following is a summary of the changes: >> >> (1) MIME subtype names were changed to "video/MP4V-ES" for video and >> "audio/MP4A-LATM" for audio. >> (2) The use of H.263 RTP payload formats (RFC 2190, 2429) in the short >> video header mode was changed to "MAY" to "SHOULD". >> (3) Clarification of timestamp definition >> There was a suggestion not to describe the detailed definition of the >> video timestamp in the RTP spec. and change it as a reference to MPEG-4 >> visual document, so as to keep consistency with the MPEG-4 visual. A >> description about the RTP timestamp in the RTCP SR packet was added. >> (4) SA/TTSI over LATM >> A description was added to restrict the LATM usage so as not to >> transmit >> SA data by LATM. >> (5) Other editorial and wording changes. >> >> Please let us know if there is comment on the attached draft. The authors >> need to submit it soon as an updated I-D and hopefully final before RFC. >> >> Best regards, >> Yoshihiro Kikuchi >> and authors of the Internet Draft >> >> ---- >> 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-request@es.net Wed Oct 4 04:41:38 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13745 for ; Wed, 4 Oct 2000 04:41:37 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gk1G-0007NF-00; Wed, 4 Oct 2000 01:35:18 -0700 Received: from p-mail2.rd.francetelecom.fr (p-mail2.cnet.fr) [193.49.124.32] by mail1.es.net with smtp (Exim 1.81 #2) id 13gk1F-0007Li-00; Wed, 4 Oct 2000 01:35:17 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4HLBQZS7>; Wed, 4 Oct 2000 10:34:02 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN To: rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu> Cc: CURET Dominique FTRD/DMI , jan.vandermeer@philips.com, "'Olivier Avaro'" Subject: RE: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 10:35:35 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA13745 dear all, *********Jan proposed: - ObjectDescriptorStream - ClockReferenceStream (is this needed over IP ?) - SceneDescriptionStream - VisualStream (with and without use of MPEG-4 Systems) - AudioStream (with and without use of MPEG-4 Systems) - MPEG-7Stream - IPMPStream - ObjectContentInfoStream - FlexMux stream - MP4 file *****Olivier found in V2 : 0x00 Forbidden 0x01 ObjectDescriptorStream (see 8.5) 0x02 ClockReferenceStream (see 10.2.519) 0x03 SceneDescriptionStream (see 9.2.1) 0x04 VisualStream 0x05 AudioStream 0x06 MPEG7Stream 0x07 IPMPStream (see 8.3.2) 0x08 ObjectContentInfoStream (see 8.4.2) 0x09 MPEGJStream (or MPEG-J Streams as Viswanathan said) *******so, to my understanding, at least: 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams ******about the muxcode table in band/out of band: Dave said that :"The MuxCodeTable needs to be delivered out-of-band". **it certainly needs to be delivered. Pierre showed how it is possible to deliver it, accurately in time, by out of band means **But is 'out of band' compatible with a multicast or broadcast scenario. **So, I think agree with Jan that an inband means is necessary. regards Dominique _________________________________________ > Dominique Curet > France Télécom R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ From rem-conf-request@es.net Wed Oct 4 05:44:22 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14158 for ; Wed, 4 Oct 2000 05:44:22 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gkz0-00021R-00; Wed, 4 Oct 2000 02:37:02 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gkyx-00021H-00; Wed, 4 Oct 2000 02:36:59 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA00725; Wed, 4 Oct 2000 11:36:57 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma000721; Wed, 4 Oct 00 11:36:57 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA21804; Wed, 4 Oct 2000 11:36:57 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA08319; Wed, 4 Oct 2000 11:36:56 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014577469; Wed, 4 Oct 2000 11:38:00 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014577469000002L992*@MHS> Date: Wed, 4 Oct 2000 11:38:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/04/00 12:35:15" Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA14158 Dominique, all, Dominique wrote: *******so, to my understanding, at least: 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams A few comments : 1) I don't think that SL stream is an additional stream type; in my view SL streams are included in the stream types that use MPEG-4 systems. 2) The wording MP4 file stream is confusing; I don't think there is a need to "stream" an MP4 file; instead only a mime type is needed for file transfer. A question : for which streams we need to specify use of RTP and SDP ? In my understanding for : - VisualStream (with and without use of MPEG-4 Systems) - AudioStream (with and without use of MPEG-4 Systems) - FlexMux stream Can we assume that the following streams are probably most efficiently contained in a FlexMux stream, and consequently that is no need to specify use of RTP and SDP for those streams: - ObjectDescriptorStream - ClockReferenceStream - SceneDescriptionStream - MPEG-7Stream - IPMPStream - ObjectContentInfoStream - MPEGJStream Regards, Jan -----Original Message----- From: dominique.curet@rd.francetelecom.fr [mailto:dominique.curet@rd.francetelecom.fr] Sent: woensdag, 04 oktober, 2000 10:39 To: 4on2andIP-sys@advent.ee.columbia.edu; rem-conf@es.net Cc: olivier.avaro@francetelecom.fr; Jan vanderMeer; dominique.curet@francetelecom.fr Subject: RE: Types of MPEG-4 streams over IP dear all, *********Jan proposed: - ObjectDescriptorStream - ClockReferenceStream (is this needed over IP ?) - SceneDescriptionStream - VisualStream (with and without use of MPEG-4 Systems) - AudioStream (with and without use of MPEG-4 Systems) - MPEG-7Stream - IPMPStream - ObjectContentInfoStream - FlexMux stream - MP4 file *****Olivier found in V2 : 0x00 Forbidden 0x01 ObjectDescriptorStream (see 8.5) 0x02 ClockReferenceStream (see 10.2.519) 0x03 SceneDescriptionStream (see 9.2.1) 0x04 VisualStream 0x05 AudioStream 0x06 MPEG7Stream 0x07 IPMPStream (see 8.3.2) 0x08 ObjectContentInfoStream (see 8.4.2) 0x09 MPEGJStream (or MPEG-J Streams as Viswanathan said) *******so, to my understanding, at least: 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams ******about the muxcode table in band/out of band: Dave said that :"The MuxCodeTable needs to be delivered out-of-band". **it certainly needs to be delivered. Pierre showed how it is possible to deliver it, accurately in time, by out of band means **But is 'out of band' compatible with a multicast or broadcast scenario. **So, I think agree with Jan that an inband means is necessary. regards Dominique _________________________________________ > Dominique Curet > France Télécom R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ From rem-conf-request@es.net Wed Oct 4 07:23:02 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15474 for ; Wed, 4 Oct 2000 07:23:02 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gmVy-0005r6-00; Wed, 4 Oct 2000 04:15:10 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gmVu-0005qU-00; Wed, 4 Oct 2000 04:15: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 UAA14754; Wed, 4 Oct 2000 20:15:02 +0900 (JST) Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id UAA13966; Wed, 4 Oct 2000 20:15:02 +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 UAA04794; Wed, 4 Oct 2000 20:15:01 +0900 (JST) Received: from ave (srg-204 [133.196.81.204]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id UAA98250; Wed, 4 Oct 2000 20:15:01 +0900 (JST) Message-ID: <067f01c02df4$61442560$cc51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Colin Perkins" Cc: "IETF AVT" , "Yoshihiro Kikuchi" References: <200010040444.AAA09294@purple.east.isi.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Wed, 4 Oct 2000 20:15:19 +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 Content-Transfer-Encoding: 7bit Dear Colin, all, > >> When the short video header mode is used, RTP payload format for H.263 > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > You should specify which of RFC 2190 or RFC 2429 is intended. > Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? Or, if ITU-T does not have any preference, I'm not sure if it is really necessary to change the text to decide this in "MPEG-4" RTP payload spec. 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-request@es.net Wed Oct 4 07:23:22 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15487 for ; Wed, 4 Oct 2000 07:23:21 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gmYV-0005zI-00; Wed, 4 Oct 2000 04:17:47 -0700 Received: from eolo.inm.es (inm.es) [193.144.152.132] by mail1.es.net with smtp (Exim 1.81 #2) id 13gmYJ-0005sL-00; Wed, 4 Oct 2000 04:17:36 -0700 Received: from maish13 (sdn-ar-001wimadiP290.dialsprint.net) by inm.es (5.x/SMI-SVR4) id AA02301; Wed, 4 Oct 2000 11:04:11 +0100 Message-Id: <10010041004.AA02301@inm.es> From: "Dave" Reply-To: Dave_Bo821@mail.sol.dk Subject: Re: Here Is The Information As Your Requested To: Dave_93@mail.sol.dk X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Wed, 04 Oct 2000 07:46:05 -0500 Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA15487 You were recently referred to me as someone who was ready for a CHANGE, a financial breakthrough, so I'll get right to the point. I am the one that can help you make $125,000 plus this year from HOME with your computer and phone. This is Not MLM and it IS very REAL. Are you Serious about making $2000 plus per week starting Right Away with a SIMPLE system where customers are contacting you and you do absolutely ZERO selling? Can you follow simple step-by-step instructions and put forth the effort to make this a reality for yourself starting today? If your answer is YES, then we need to talk. I have few positions available on my team and its in my best interest to train you for success. In fact, I'm so sure that I can do so, I'm willing to put my money where my mouth is! Upon accepting you as a member on my team, I will provide you with complete Professional Training and Advertising Assistance to put you immediately on the road to success. No experience necessary.... However you must have two qualities: moderate people skills and a serious desire for a personal and financial change. Take a moment to take the next step by calling me at my Home Office and I will get you the details. 1-800-318-8477 24 Hrs/ 7 Days Prosperous Regards! Dave "Profits are better than wages. Wages make you a living; Profits make you a fortune" - Jim Rohn To be removed send email to boonmeri@yahoo.com From rem-conf-request@es.net Wed Oct 4 09:52:31 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20355 for ; Wed, 4 Oct 2000 09:52:31 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gokg-0004lz-00; Wed, 4 Oct 2000 06:38:30 -0700 Received: from (notes.techway.co.kr) [203.238.126.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gokf-0004li-00; Wed, 4 Oct 2000 06:38:29 -0700 Received: from young ([203.238.126.154]) by notes.techway.co.kr (Lotus Domino Release 5.0.2c) with SMTP id 2000100422375907:32895 ; Wed, 4 Oct 2000 22:37:59 +0900 Message-ID: <007f01c02e07$a9411f40$9a7eeecb@techway.co.kr> Reply-To: "Young-Kwon LIM" From: "Young-Kwon LIM" To: , Cc: , <4on2andIP-sys@advent.ee.columbia.edu> References: <0056890014577469000002L992*@MHS> Subject: Re: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 22:33:20 +0900 Organization: MP4CAST MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-04 10:37:59 PM, Serialize by Router on Domino/Techway(Release 5.0.2c|2000. 2. 18.) at 2000-10-04 10:38:10 PM, Serialize complete at 2000-10-04 10:38:10 PM Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA20355 Dear Jan, Dominique and all, >Dominique wrote: >*******so, to my understanding, at least: > 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams >A few comments : >1) I don't think that SL stream is an additional stream type; in my view SL >streams are included in the stream types that use MPEG-4 systems. ==> In my understanding, the streamtype identify the content of the bitstream. If you want to identify the format of the stream it is useful to differentiate SL stream, FlexMux stream and ES of each media streams and etc. But if you want to differentiate the content of the streams, then there is no need to differentiate SL streams from others. What is your intention for stream type discussions? >2) The wording MP4 file stream is confusing; I don't think there is a need >to "stream" an MP4 file; instead only a mime type is needed for file >transfer. ==> I agree with this. In any case there is no MP4 stream. >A question : for which streams we need to specify use of RTP and SDP ? In my >understanding for : >- VisualStream (with and without use of MPEG-4 Systems) >- AudioStream (with and without use of MPEG-4 Systems) >- FlexMux stream >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream In general we are not allowed to assume this condition because there is no normative limitation to this even though practically it is valid. Do you want to put a normative usage of FlexMux for those cases? And I think IPMP streams should not be multiplexed with other streams. Sincerely, Young. From rem-conf-request@es.net Wed Oct 4 10:32:50 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21321 for ; Wed, 4 Oct 2000 10:32:49 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gpTn-0000PU-00; Wed, 4 Oct 2000 07:25:07 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gpTm-0000PI-00; Wed, 4 Oct 2000 07:25:06 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id QAA06267; Wed, 4 Oct 2000 16:24:59 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma006265; Wed, 4 Oct 00 16:24:59 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA23312; Wed, 4 Oct 2000 16:24:59 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id QAA25697; Wed, 4 Oct 2000 16:24:58 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014590674; Wed, 4 Oct 2000 16:26:02 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014590674000002L942*@MHS> Date: Wed, 4 Oct 2000 16:26:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/04/00 17:23:14" Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA21321 Dear Young, You wrote : >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream In general we are not allowed to assume this condition because there is no normative limitation to this even though practically it is valid. Do you want to put a normative usage of FlexMux for those cases? And I think IPMP streams should not be multiplexed with other streams. I am asking just for getting opinions; I am not sure how practical it is to have a separate session for each of the above streams. You may be right that IPMP streams should not be multiplexed with other streams, but for that case FlexMux could offer a useful multiplex solution for multiple IPMP messages within an RTP payload. Kind regards, Jan From rem-conf-request@es.net Wed Oct 4 11:11:48 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22204 for ; Wed, 4 Oct 2000 11:11:46 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gq78-0003Jd-00; Wed, 4 Oct 2000 08:05:46 -0700 Received: from albatross-ext.wise.edt.ericsson.se [194.237.142.116] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gq73-0003J0-00; Wed, 4 Oct 2000 08:05:43 -0700 Received: from lms001.lu.erisoft.se (lms001.lu.erisoft.se [150.132.144.19]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e94F5Ut16023; Wed, 4 Oct 2000 17:05:30 +0200 (MEST) Received: by lms001.lu.erisoft.se id RAA16490; Wed, 4 Oct 2000 17:05:28 +0200 (MET DST) Message-ID: <39DB4736.8DEF25F9@lu.erisoft.se> Date: Wed, 04 Oct 2000 17:05:26 +0200 From: Krister Svanbro Organization: Ericsson Research X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Qiaobing Xie , Magnus Westerlund CC: rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Qiaobing, Magnus and others, I am Krister Svanbro and work mainly in the ROHC WG. I noticed that the ROHC WG name was mentioned below and thought I perhaps could bring some information from a ROHC point of view, which might help somewhat in this issue. The ROHC WG has spent year 2000 on mainly developing a robust header compression scheme for RTP/UDP/IP. We have also created a framework based on compression profiles to enable development of other compression profiles such as compression of TCP/IP the coming year. The term robust origins from that fact we realised that we need to design header compression schemes more robust to make them cope with the relative large amount of packet loss that occur in e.g. cellular systems. That does not, however, preclude in any way the usage of the ROHC scheme in other types of (possible error prone) environments. We have to this date not looked upon compression of RTP payloadformats and we do not plan to that either. I also think that there should not be any need for compression of payloadformats. They should be as efficient as possible from the beginning. AMR is certainly a highly interesting codec in usage together with ROHC to enable VoIP to a mobile, hence it is important that the AMR format is efficient and does not waste any bits. It becomes kind of strange if we in the ROHC WG maximize compression efficiency with rather sofisticated methods to enable to go down to a compressed header size of 1 byte for the IP/UDP/RTP header, and then is 1 byte extra used for the RTP payloadformat only. Hence, I would like to encourage you to keep efficiency in mind when developing this payload format. I look forward to see the results of this work. Cheers, / Krister Qiaobing Xie wrote: > > Hi, Magnus, > > See my comments below.... > > Magnus Westerlund wrote: > > > > Hello, > > > > The payload format is designed with IP networks in mind. The problem we see is > > that IP is transported over a wide range of different links with different > > behavior, e.g. different radio and wireline links. Radio and wire do not have > > the same error characteristics. AMR will be widly used over wireless links and > > on these links bandwidth efficiency is extremely important. This lead to the > > bitwise sorting. Octet sorting needs octet alignement for each block of the > > payload, i.e. padding at the end of each block. Which we considered to be to > > expensive. > > This further convinces me that the current design presented in the AMR > draft is a radio-link-centric design, which is wrong in my opinion, > because: > > 1) bandwidth efficiency over wireless links is more of a concern for > ROHC working group. Architecturally, it should be delt with below IP by > header compression/stripping, as being worked upon in rohc. It doesn't > belong to RTP payload layer (unless it is something facilitating the > underlying header compression/stripping). From rem-conf-request@es.net Wed Oct 4 11:21:43 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22519 for ; Wed, 4 Oct 2000 11:21:43 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gqIB-0004Wu-00; Wed, 4 Oct 2000 08:17:11 -0700 Received: from mailhost.talarian.com (phobos.talarian.com) [207.5.32.17] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gqIA-0004T9-00; Wed, 4 Oct 2000 08:17:10 -0700 Received: from VAIO (ta037.talarian.com [204.147.187.37]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id IAA02018; Wed, 4 Oct 2000 08:16:11 -0700 (PDT) From: "Phil Farrar" To: Subject: Seminar: Catch the Vision of IP Multicast Date: Wed, 4 Oct 2000 10:07:05 -0500 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.6700 X-MIME-Autoconverted: from 8bit to quoted-printable by phobos.talarian.com id IAA02018 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA22519 Learn first hand about the latest advances in IP multicast technology in a half-day seminar. (Registration is filling fast! Reserve your seat now!) Get expert advice on creating efficient one-to-many communications from industry leaders Talarian, Nortel Networks and SkyStream. Join us for registration and continental breakfast beginning at 8:00 am. The seminar program runs from 9 am – 12 noon. Talarian, a leader in real-time publish-subscribe messaging and reliable multicast is hosting the seminar series. Seating is limited so register now! www.talarian.com/seminar or call 800-543-8096 If you're a software developer, network architect, CIO, CTO or Director of MIS, this seminar is for you. Hear presentations about: · New developments in IP multicast technology · How to know when to use reliable multicast technology · Applications enabled by IP and reliable multicast · What multicast is doing for customers today · Where multicast needs to go in the future Learn how to: · Optimize satellite uplink/downlink throughput using PGM forward error correction · Re-architect your network to stream audio and video content to client applications · Reduce overhead of global data distribution and software updates · Instantly transfer financial data to wireless devices in real-time · Easily and effectively scale the distribution of data · Ensure your network infrastructure (e.g., routers) is multicast enabled Attend and you could win a TiVo with a 1-year subscription! This series of Talarian Seminars are being held in the following cities: New York, NY Wednesday, October 18 Marriott World Trade Center Richardson, TX Tuesday, October 24 Omni Richardson Hotel Denver, CO Wednesday, October 25 Hilton Denver Tech South Redwood City, CA Tuesday, October 31 Hotel Sofitel To attend a seminar or obtain information regarding other seminars in your area, please register at www.talarian.com/seminars or call 800-543-8096. To learn more about Talarian and their reliable multicasting and real-time publish-subscribe messaging products, visit www.talarian.com. From rem-conf-request@es.net Wed Oct 4 11:39:22 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23858 for ; Wed, 4 Oct 2000 11:39:21 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gqYM-0006En-00; Wed, 4 Oct 2000 08:33:54 -0700 Received: from jack.see.plymouth.ac.uk (jack.see.plym.ac.uk) [141.163.49.98] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gqYL-0006Ec-00; Wed, 4 Oct 2000 08:33:53 -0700 Received: from len (sfres1.see.plymouth.ac.uk [141.163.49.101]) by jack.see.plym.ac.uk (8.9.3/8.9.3) with SMTP id QAA29432 for ; Wed, 4 Oct 2000 16:29:51 +0100 Message-ID: <004c01c02e18$cf2587d0$6531a38d@see.plym.ac.uk> From: "Bogdan Ghita" To: Subject: Routing for UDP/real-time vs TCP Date: Wed, 4 Oct 2000 16:36:05 +0100 Organization: NRG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C02E21.30CFFF30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C02E21.30CFFF30 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear all I have a question related to general routing issues: I am looking into measuring RTT for a specific path using 2 different = methods: TCP acknowledgements and RTCP NTP/LSR/DLSR fields. Is there any specification regarding different handling by the servers = of packets that carry TCP segments vs packets carrying UDP datagrams? I = had several discussions lately about how some/all routers tend to drop = first ICMP traffic, then TCP traffic and, at the end, UDP traffic, as = the first category is not critical and the second can recover. If so, it = would mean that there are several different transport performance rates = for the same path, depending on the type of traffic being sent. Are the = assumption/conclusion correct? Could you point me to some materials that = detail this matter? Thank you very much Best regards Bogdan Ghita ------=_NextPart_000_0049_01C02E21.30CFFF30 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Dear all
 
I have a question related to general = routing=20 issues:
I am looking into measuring RTT for a = specific path=20 using 2 different methods: TCP acknowledgements and RTCP NTP/LSR/DLSR=20 fields.
Is there any = specification regarding different=20 handling by the servers of packets that carry TCP segments vs packets = carrying=20 UDP datagrams? I had several discussions lately about how some/all = routers tend=20 to drop first ICMP traffic, then TCP traffic and, at the end, UDP = traffic, as=20 the first category is not critical and the second can recover. If so, it = would=20 mean that there are several different transport performance rates for = the same=20 path, depending on the type of traffic being sent. Are the = assumption/conclusion=20 correct? Could you point me to some materials that detail this=20 matter?
 
Thank you very much
 
Best regards
Bogdan Ghita
 
 
 
------=_NextPart_000_0049_01C02E21.30CFFF30-- From rem-conf-request@es.net Wed Oct 4 11:54:13 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24292 for ; Wed, 4 Oct 2000 11:54:12 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gqnK-00005N-00; Wed, 4 Oct 2000 08:49:22 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13gqnJ-00005C-00; Wed, 4 Oct 2000 08:49:21 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-174.dialup.cs.tu-berlin.de [130.149.145.174]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id RAA19580; Wed, 4 Oct 2000 17:43:35 +0200 (MET DST) Message-Id: <5.0.0.25.2.20001004173727.02f62990@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 04 Oct 2000 17:39:19 +0200 To: "Yoshihiro Kikuchi" From: Stephan Wenger Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Cc: "Colin Perkins" , "IETF AVT" , "Yoshihiro Kikuchi" In-Reply-To: <067f01c02df4$61442560$cc51c485@eel.rdc.toshiba.co.jp> References: <200010040444.AAA09294@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 Dear Yoshihiro, Group, To my knowledge the only reason why RFC2190 is not yet OBSOLETE is that some early H.323 products still use it. Interoperability with such products is probably not your main concern. So I would suggest to select RFC2429 only. Stephan At 08:15 PM 10/4/2000 +0900, Yoshihiro Kikuchi wrote: >Dear Colin, all, > > > >> When the short video header mode is used, RTP payload format for >H.263 > > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > > > You should specify which of RFC 2190 or RFC 2429 is intended. > > >Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? >Or, if ITU-T does not have any preference, I'm not sure if it is really >necessary to change the text to decide this in "MPEG-4" RTP payload spec. > >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-request@es.net Wed Oct 4 12:23:29 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24906 for ; Wed, 4 Oct 2000 12:23:28 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13grEi-0001rX-00; Wed, 4 Oct 2000 09:17:40 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13grEf-0001rH-00; Wed, 4 Oct 2000 09:17:37 -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 JAA05157 for ; Wed, 4 Oct 2000 09:17:33 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 4 Oct 2000 09:17:33 -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 JAA24057; Wed, 4 Oct 2000 09:17:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <0056890014577469000002L992*@MHS> References: <0056890014577469000002L992*@MHS> Date: Wed, 4 Oct 2000 09:17:04 -0700 To: jan.vandermeer@philips.com From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Cc: dominique.curet@rd.francetelecom.fr, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any stream. What is wrong with Carsten et al.'s sync layer mapping into RTP? -- David Singer Apple Computer/QuickTime From rem-conf-request@es.net Wed Oct 4 12:23:36 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24921 for ; Wed, 4 Oct 2000 12:23:35 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13grEq-0001rx-00; Wed, 4 Oct 2000 09:17:48 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13grEf-0001rF-00; Wed, 4 Oct 2000 09:17:37 -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 JAA05138 for ; Wed, 4 Oct 2000 09:17:32 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 4 Oct 2000 09:17:31 -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 JAA24025; Wed, 4 Oct 2000 09:17:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B1D@l-rmhs.lannion.cnet.fr> Date: Wed, 4 Oct 2000 09:15:55 -0700 To: CURET Dominique FTRD/DMI/REN From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Cc: rem-conf , 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, CURET Dominique FTRD/DMI , jan.vandermeer@philips.com, "'Olivier Avaro'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >*******so, to my understanding, at least: > 3 streams are missing: Flexmux steeams, SL steams & MP4 file streams SL is not a stream type. It's the layer that carries streams. MP4 files are not directly streamed; they may be downloaded, but that requires a MIME type, not a stream type. >******about the muxcode table in band/out of band: >Dave said that :"The MuxCodeTable needs to be delivered out-of-band". >**it certainly needs to be delivered. > >Pierre showed how it is possible to deliver it, accurately in time, by >out of band means > >**But is 'out of band' compatible with a multicast or broadcast scenario. >**So, I think agree with Jan that an inband means is necessary. of course it is. my framework proposal showed how. in a multicast or broadcast, there is always some information that is given to the terminal to enable it to open the streams. in IETF world, that is an SDP file. I showed how to put the IOD and the flexmux info into the SDP file. -- David Singer Apple Computer/QuickTime From rem-conf-request@es.net Wed Oct 4 13:24:38 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26784 for ; Wed, 4 Oct 2000 13:24:38 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gs8R-0005YX-00; Wed, 4 Oct 2000 10:15:15 -0700 Received: from p-mail2.rd.francetelecom.fr (p-mail2.cnet.fr) [193.49.124.32] by mail1.es.net with smtp (Exim 1.81 #2) id 13gs8P-0005Wf-00; Wed, 4 Oct 2000 10:15:14 -0700 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4HLBRC33>; Wed, 4 Oct 2000 19:13:38 +0200 Message-ID: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B38@l-rmhs.lannion.cnet.fr> From: CURET Dominique FTRD/DMI/REN To: "'Dave Singer'" , jan.vandermeer@philips.com Cc: CURET Dominique FTRD/DMI/REN , rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 19:15:11 +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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA26784 Dear all, dear Dave, Dave said: "I would be strongly opposed to mandating the use of flexmux for any stream." answer: The applications that you have in mind don't seem to need multiplexing at the application level. Fine with me. When some other applications find this approach interesting, our job is to give solutions to them. There should not be any technical fundamentalism. Dominique _________________________________________ > Dominique Curet > France Télécom R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ -----Message d'origine----- De: Dave Singer [mailto:singer@apple.com] Date: mercredi 4 octobre 2000 18:17 À: jan.vandermeer@philips.com Cc: dominique.curet@rd.francetelecom.fr; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Objet: RE: Types of MPEG-4 streams over IP >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any stream. What is wrong with Carsten et al.'s sync layer mapping into RTP? -- David Singer Apple Computer/QuickTime From rem-conf-request@es.net Wed Oct 4 13:33:50 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26991 for ; Wed, 4 Oct 2000 13:33:50 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gsJu-0006bz-00; Wed, 4 Oct 2000 10:27:06 -0700 Received: from ariel.gi.com [168.84.84.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gsJt-0006ZS-00; Wed, 4 Oct 2000 10:27:05 -0700 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JUXPGEBVIQEVQYUX@GI.COM> for rem-conf@es.net; Wed, 4 Oct 2000 10:25:47 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 04 Oct 2000 10:25:00 -0400 Content-return: allowed Date: Wed, 04 Oct 2000 13:28:24 -0400 From: "Narasimhan, Sam (SD-EX)" Subject: RE: Types of MPEG-4 streams over IP To: "'Dave Singer'" , jan.vandermeer@philips.com Cc: dominique.curet@rd.francetelecom.fr, rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Message-id: <973597126BDDD11197AA00805FA7EBC9034239DD@ntas0026.gi.com> 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 Dave, The MPEG requirements document asks for a payload mapping scheme to carry flexmux streams. This is possible in MPEG-2 transport and must be possible in RTP. We need to define a mapping scheme which will be normative for those applications that want to transmit flexmux streams over RTP. I will strongly object to a mapping scheme that excludes or precludes the carriage of flexmux streams over RTP. Regards Sam Narasimhan Motorola -----Original Message----- From: Dave Singer [mailto:singer@apple.com] Sent: Wednesday, October 04, 2000 9:17 AM To: jan.vandermeer@philips.com Cc: dominique.curet@rd.francetelecom.fr; rem-conf@es.net; 4on2andIP-sys@advent.ee.columbia.edu Subject: RE: Types of MPEG-4 streams over IP >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any stream. What is wrong with Carsten et al.'s sync layer mapping into RTP? -- David Singer Apple Computer/QuickTime From rem-conf-request@es.net Wed Oct 4 16:07:07 2000 Received: from mail2.es.net (mail2.es.net [198.128.3.182]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00484 for ; Wed, 4 Oct 2000 16:07:06 -0400 (EDT) Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13guZQ-000276-00; Wed, 4 Oct 2000 12:51:16 -0700 Received: from sdn-ar-003flmiamp018.dialsprint.net ([168.191.253.26] helo=50460l3t.aol.com) by mail2.es.net with smtp (Exim 1.92 #1) id 13guZG-00026T-00; Wed, 4 Oct 2000 12:51:08 -0700 To: sturtevantap@es.net Message-Id: <1g7jvs70.86y67u28e@50460l3t.aol.com> Subject: 3000 VISITORS TO YOUR SITE IN 24 HOURS--GUARANTEED Date: Thu, 05 Oct 2000 03:49:23 -0500 From: sowens7426@lxafehtcsc.earthlink.net Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8BIT Give us 10 key words and 24 hours...Let us send you 3000 vistors minimum! YOU MAY HAVE THE BEST PRODUCT OR SERVICE IN THE WORLD BUT, without effective exposure...what good does it do?? Add 3,000 eager visitors (minimum) to your web site, in 24 hours, guaranteed, through OBC. For More Information call us at the number below or mailto:hitgenerator@n2mail.com, CALL IN BONUS: With your first order receive our BONUS worth over $250 FREE. 919-839-2942. Today, there are almost 30 million sites on the Internet. To merely have a "net presence"- without actively promoting your site, is comparable to … taking out a 2-line ad in the "New York Times": not many people will see it and even fewer will respond. The OBC has developed a proven technique to generate and deliver thousands of visitors directly to your web site, within 24 hours. We absolutely guarantee it. Our campaign will bring active visitors, looking to learn more about your offers. These are not just surfers. They are excited, expectant visitors, who find your web site through our heavily and strategically advertised portals, search engines, key words directories and other techniques. We are interested in your marketing your web site. Do you have an interest in our services which GUARANTEES 3000 visitors or more to your site within any 24 hour period? NO BULK MAILING INVOLVED! NO SPAMMING INVOLVED! NO PAID SURFERS INVOLVED! NO PAID EMAIL READERS INVOLVED! ALL CAMPAIGNS ARE 100% GUARANTEED! We also create various new forms of revenue which could be created for your site. If you are interested please do drop us a line including your name and phone number and mailto:hitgenerator@n2mail.com, or feel free to ring us directly at: 919-839-2942. Act Now!!!! Reap the Benefits in 24 Hours!!! ___________________________________________________ This message is sent in compliance of current rules and regulations related to bulk email transmission. ================================================= If you wish to be removed from future mailings, please mailto:nohitgenerator@n2mail.com ============================= From rem-conf-request@es.net Wed Oct 4 17:28:24 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02163 for ; Wed, 4 Oct 2000 17:28:24 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gvyc-0001M5-00; Wed, 4 Oct 2000 14:21:22 -0700 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gvyb-0001Lu-00; Wed, 4 Oct 2000 14:21:21 -0700 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.9.3/8.9.3) with ESMTP id OAA19582; Wed, 4 Oct 2000 14:21:19 -0700 (MST) Received: from P-micke (P-micke.CS.Arizona.EDU [150.135.82.100]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id OAA19379; Wed, 4 Oct 2000 14:21:16 -0700 (MST) Message-Id: <200010042121.OAA19379@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 04 Oct 2000 23:23:19 +0200 To: Krister Svanbro From: Mikael Degermark Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: Qiaobing Xie , Magnus Westerlund , rem-conf@es.net In-Reply-To: <39DB4736.8DEF25F9@lu.erisoft.se> References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ROHC WG co-chair speaking. I have a couple of comments to this letter: >Qiaobing Xie wrote: >> >> Hi, Magnus, >> >> See my comments below.... >> >> Magnus Westerlund wrote: >> > >> > Hello, >> > >> > The payload format is designed with IP networks in mind. The problem we see is >> > that IP is transported over a wide range of different links with different >> > behavior, e.g. different radio and wireline links. Radio and wire do not have >> > the same error characteristics. AMR will be widly used over wireless links and >> > on these links bandwidth efficiency is extremely important. This lead to the >> > bitwise sorting. Octet sorting needs octet alignement for each block of the >> > payload, i.e. padding at the end of each block. Which we considered to be to >> > expensive. >> >> This further convinces me that the current design presented in the AMR >> draft is a radio-link-centric design, which is wrong in my opinion, >> because: >> >> 1) bandwidth efficiency over wireless links is more of a concern for >> ROHC working group. That statement is too general. ROHC deals with the efficient transmission of the RTP/UDP/IP header. The payload format is NOT a concern of the ROHC WG. If a payload format is to be efficient over a wireless link, it must be made so by others than ROHC. >> Architecturally, it should be delt with below IP by >> header compression/stripping, as being worked upon in rohc. It doesn't >> belong to RTP payload layer (unless it is something facilitating the >> underlying header compression/stripping). Architecturally speaking (and here I remove my ROHC chair hat), bandwidth efficiency over wireless links will best be obtained by a) having an efficiently compressed payload, which might be somewhat resilient to errors introduced by the wireless link. b) compressing the RTP/UDP/IP header robustly and efficiently. ROHC deals with b). Others, perhaps you people, need to deal with a). The best result will be obtained if a) is done close to the application, i.e., above the IP layer. a) is certainly not the task of ROHC, and neither should it be. The IETF should not worry ONLY about wireless, of course, but it certainly seems appropriate to ensure that things work over wireless as well as over the rest of the currently largely wired Internet. Cheers, Mikael Degermark From rem-conf-request@es.net Wed Oct 4 18:53:49 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03492 for ; Wed, 4 Oct 2000 18:53:48 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gxFC-0004T9-00; Wed, 4 Oct 2000 15:42:34 -0700 Received: from (motgate3.mot.com) [144.189.100.103] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gxFB-0004Sx-00; Wed, 4 Oct 2000 15:42:33 -0700 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA08568; Wed, 4 Oct 2000 15:39:49 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA12322; Wed, 4 Oct 2000 15:40:57 -0700 (MST)] Received: from agevole.cig.mot.com (agevole [136.182.3.251]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id RAA20206; Wed, 4 Oct 2000 17:40:57 -0500 (CDT) Received: from cig.mot.com (d42-5077.cig.mot.com [160.15.80.119]) by agevole.cig.mot.com (8.7.5 Motorola CIG/ITS v1.1 (Solaris 2.5)) with ESMTP id RAA22247; Wed, 4 Oct 2000 17:40:56 -0500 (CDT) Message-Id: <200010042240.RAA22247@agevole.cig.mot.com> Date: Wed, 04 Oct 2000 17:41:11 -0500 From: Qiaobing Xie X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mikael Degermark CC: Krister Svanbro , Qiaobing Xie , Magnus Westerlund , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Mikael and Krister (and other ROHCers on the list): Ok, I know I was getting myself in trouble when I mentioned the "dreadful" word ROHC :-) :-) Mikael Degermark wrote: ...snip... > >> Architecturally, it should be delt with below IP by > >> header compression/stripping, as being worked upon in rohc. It doesn't > >> belong to RTP payload layer (unless it is something facilitating the > >> underlying header compression/stripping). > > Architecturally speaking (and here I remove my ROHC chair hat), bandwidth > efficiency over wireless links will best be obtained by > > a) having an efficiently compressed payload, which might be somewhat resilient to > errors introduced by the wireless link. > > b) compressing the RTP/UDP/IP header robustly and efficiently. > > ROHC deals with b). Others, perhaps you people, need to deal with a). > The best result will be obtained if a) is done close to the application, > i.e., above the IP layer. a) is certainly not the task of ROHC, and neither should > it be. I think we are in "violent" agreement here :) The point I was trying to make is, when you are looking at optimizing the bandwidth efficiency over a *link* with a unique error characteristics, the framework/approach used by ROHC is more appropriate, which is to look for header compression/stripping solutions below the IP layer. This matches your b) above. But if you are designing an RTP payload format, which is meant to be sent end-to-end over a routable IP connection, it does not make much sense to optimize the payload format design according to the error characteristics of any one type of the link which, after all, may or may not be present in the connection. I have not problem with a) and I think it is in deed the job of AVT WG. No doubt that it is universally desirable to design any protocol message as compact and as compressed as possible (as Krister said: not to waste a bit) But in reality, you often have to make trade-off between saving a bit in the message and the associated processing cost, especially when the processing is done in a higher stack layer. The error resilience part (or the lack of it) in the current AMR draft is exactly one of my big concerns as I talked about in my first email. Cheers, -Qiaobing > > The IETF should not worry ONLY about wireless, of course, but it certainly > seems appropriate to ensure that things work over wireless as well as over > the rest of the currently largely wired Internet. > > Cheers, > > Mikael Degermark From rem-conf-request@es.net Wed Oct 4 19:44:32 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04547 for ; Wed, 4 Oct 2000 19:44:31 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13gy6v-0006SL-00; Wed, 4 Oct 2000 16:38:05 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13gy6t-0006S2-00; Wed, 4 Oct 2000 16:38:03 -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 QAA00297 for ; Wed, 4 Oct 2000 16:38:02 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 4 Oct 2000 16:38:01 -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 QAA07580; Wed, 4 Oct 2000 16:38:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B38@l-rmhs.lannion.cnet.fr> References: <8D0FCE51EA3DD411B8D80004AC4CCB5B132B38@l-rmhs.lannion.cnet.fr> Date: Wed, 4 Oct 2000 16:36:23 -0700 To: CURET Dominique FTRD/DMI/REN From: Dave Singer Subject: RE: Types of MPEG-4 streams over IP Cc: jan.vandermeer@philips.com, CURET Dominique FTRD/DMI/REN , rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 7:15 PM +0200 10/4/00, CURET Dominique FTRD/DMI/REN wrote: >Dear all, dear Dave, > >Dave said: >"I would be strongly opposed to mandating the use of flexmux for any >stream." > >answer: >The applications that you have in mind don't seem to need multiplexing >at the application level. Fine with me. >When some other applications find this approach interesting, our job >is to give solutions to them. There should not be any technical >fundamentalism. and Sam said: > The MPEG requirements document asks for a payload >mapping scheme to carry flexmux streams. This is possible in >MPEG-2 transport and must be possible in RTP. We need to >define a mapping scheme which will be normative for those >applications that want to transmit flexmux streams over >RTP. I will strongly object to a mapping scheme that >excludes or precludes the carriage of flexmux streams >over RTP. I am not opposed to allowing the use of flexmux. The proposal was that certain stream types (e.g. MPEG-7) could *only* be carried in flexmux. Flexmux is not always suitable; it should be possible to carry a single MPEG-4 stream in a simple RTP stream, without requiring flexmux. Indeed, I am not being a fundamentalist; though I personally do not see much need for flexmux, I am happy that it be allowed. I would like a technical solution for MPEG-4 which does not *mandate* it, that's all. -- David Singer Apple Computer/QuickTime From rem-conf-request@es.net Wed Oct 4 21:57:06 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06975 for ; Wed, 4 Oct 2000 21:57:06 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h0Av-0002Gt-00; Wed, 4 Oct 2000 18:50:21 -0700 Received: from u-mail.rd.francetelecom.com [208.25.178.63] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h0At-0002GS-00; Wed, 4 Oct 2000 18:50:20 -0700 Received: by u-mail.rd.francetelecom.com with Internet Mail Service (5.5.2448.0) id ; Wed, 4 Oct 2000 18:48:54 -0700 Message-ID: <337055FBC675D311A85D00508B5A9C4F355324@u-mail.rd.francetelecom.com> From: SIGNES Julien / ENVIVIO To: "'Y. Matsui'" , 4on2andIP-sys@advent.ee.columbia.edu Cc: rem-conf@es.net Subject: RE: Types of MPEG-4 streams over IP Date: Wed, 4 Oct 2000 18:48:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E6E.69E69BD8" 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_001_01C02E6E.69E69BD8 Content-Type: text/plain; charset="iso-8859-1" Hello, > -----Original Message----- > From: Y. Matsui [mailto:matsui@drl.mei.co.jp] > Sent: Wednesday, October 04, 2000 6:42 PM > To: 4on2andIP-sys@advent.ee.columbia.edu > Cc: rem-conf@es.net > Subject: Re: Types of MPEG-4 streams over IP > > > Dear Jan and all, > > >Can we assume that the following streams are probably most > efficiently > >contained in a FlexMux stream, and consequently that is no > need to specify > >use of RTP and SDP for those streams: > > > >- ObjectDescriptorStream > >- ClockReferenceStream > >- SceneDescriptionStream > >- MPEG-7Stream > >- IPMPStream > >- ObjectContentInfoStream > >- MPEGJStream > > In my opinion, those streams should be carried on a reliable channel > rather than RTP. > I agree in general they should be fully reliable channels carrying those,as well as BIFS comands. However, note that a lot of streaming those days is actually done by RTP over TCP. > What I am not sure is the scene description stream. > There are two kind of the scene description stream, one is BIFS-update > and another is BIFS-Anim. In my understanding, BIFS-Anim should > be streamed like audio/visual streams. I agree. > > Best regards, > Yoshinori Matsui > Julien ------_=_NextPart_001_01C02E6E.69E69BD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Types of MPEG-4 streams over IP

Hello,

> -----Original Message-----
> From: Y. Matsui [mailto:matsui@drl.mei.co.jp]
> Sent: Wednesday, October 04, 2000 6:42 = PM
> To: 4on2andIP-sys@advent.ee.columbia.edu
> Cc: rem-conf@es.net
> Subject: Re: Types of MPEG-4 streams over = IP
>
>
> Dear Jan and all,
>
> >Can we assume that the following streams = are probably most
> efficiently
> >contained in a FlexMux stream, and = consequently that is no
> need to specify
> >use of RTP and SDP for those = streams:
> >
> >- ObjectDescriptorStream
> >- ClockReferenceStream
> >- SceneDescriptionStream
> >- MPEG-7Stream
> >- IPMPStream
> >- ObjectContentInfoStream
> >- MPEGJStream
>
> In my opinion, those streams should be carried = on a reliable channel
> rather than RTP.
>

I agree in general they should be fully reliable = channels carrying those,as well as BIFS comands. However, note that a = lot of streaming those days is actually done by RTP over = TCP.

> What I am not sure is the scene description = stream.
> There are two kind of the scene description = stream, one is BIFS-update
> and another is BIFS-Anim.  In my = understanding, BIFS-Anim should
> be streamed like audio/visual streams.

I agree.


>
> Best regards,
> Yoshinori Matsui
>

Julien

------_=_NextPart_001_01C02E6E.69E69BD8-- From rem-conf-request@es.net Wed Oct 4 21:57:21 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06986 for ; Wed, 4 Oct 2000 21:57:21 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h05i-00029f-00; Wed, 4 Oct 2000 18:44:58 -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 13h05h-000288-00; Wed, 4 Oct 2000 18:44:57 -0700 Received: (from root@localhost) by vsm.ctmo.mei.co.jp (8.9.1/8.9.1) id KAA00727; Thu, 5 Oct 2000 10:43:04 +0900 (JST) Received: from dragon.drl.mei.co.jp(132.182.104.28) by vsm.ctmo.mei.co.jp via smap (V2.0) id ; Thu, 5 Oct 00 10:43:01 +0900 Received: by dragon.drl.mei.co.jp (8.9.3/5.9:4.9:drl-mx-com:20000202) id KAA28437; Thu, 5 Oct 2000 10:41:57 +0900 (JST) Message-ID: <00b301c02e6d$6663bfa0$156bb684@drl.mei.co.jp> From: "Y. Matsui" To: <4on2andIP-sys@advent.ee.columbia.edu> Cc: References: <0056890014577469000002L992*@MHS> Subject: Re: Types of MPEG-4 streams over IP Date: Thu, 5 Oct 2000 10:41:35 +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 Content-Transfer-Encoding: 7bit Dear Jan and all, >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream In my opinion, those streams should be carried on a reliable channel rather than RTP. What I am not sure is the scene description stream. There are two kind of the scene description stream, one is BIFS-update and another is BIFS-Anim. In my understanding, BIFS-Anim should be streamed like audio/visual streams. Best regards, Yoshinori Matsui From rem-conf-request@es.net Wed Oct 4 22:33:13 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08138 for ; Wed, 4 Oct 2000 22:33:13 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h0lr-0004Kn-00; Wed, 4 Oct 2000 19:28:31 -0700 Received: from optima.cs.arizona.edu [192.12.69.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h0lp-0004Kd-00; Wed, 4 Oct 2000 19:28:30 -0700 Received: from baskerville.CS.Arizona.EDU (baskerville.CS.Arizona.EDU [192.12.69.35]) by optima.cs.arizona.edu (8.9.3/8.9.3) with ESMTP id TAA24267; Wed, 4 Oct 2000 19:28:28 -0700 (MST) Received: from P-micke (P-micke.CS.Arizona.EDU [150.135.82.100]) by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id TAA27598; Wed, 4 Oct 2000 19:28:26 -0700 (MST) Message-Id: <200010050228.TAA27598@baskerville.CS.Arizona.EDU> X-Sender: micke@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 05 Oct 2000 04:30:33 +0200 To: Qiaobing Xie From: Mikael Degermark Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt Cc: Mikael Degermark , Krister Svanbro , Qiaobing Xie , Magnus Westerlund , rem-conf@es.net In-Reply-To: <200010042240.RAA22247@agevole.cig.mot.com> References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 05:41 PM 10/4/00 -0500, Qiaobing Xie wrote: (snip) >The point I was trying to make is, when you are looking at optimizing >the bandwidth efficiency over a *link* with a unique error >characteristics, the framework/approach used by ROHC is more >appropriate, which is to look for header compression/stripping solutions >below the IP layer. This matches your b) above. >But if you are designing an RTP payload format, which is meant to be >sent end-to-end over a routable IP connection, it does not make much >sense to optimize the payload format design according to the error >characteristics of any one type of the link which, after all, may or may >not be present in the connection. If one expects that a common case will be that the payload is sent across such links, it may make a lot of sense. But this is of course difficult to predict. >I have not problem with a) and I think it is in deed the job of AVT WG. >No doubt that it is universally desirable to design any protocol message >as compact and as compressed as possible (as Krister said: not to waste >a bit) But in reality, you often have to make trade-off between saving >a bit in the message and the associated processing cost, especially when >the processing is done in a higher stack layer. The tradeoff is between the cost of sending the bits across the link and the processing cost at the sender/receiver. As the end user will ultimately pay for both, one has to consider the relative costs. When the amr format is used for voice, it seems that either of two scenarios will occur: 1) users use some sort of mobile terminal. 2) users use stationary terminals. For 1, the cost of bandwidth is very likely to be higher than the processing cost if the mobile uses cellular radio. For 2, the cost of bandwidth is very low, but on the other hand the incremental processing cost is zero when something like a PC is used as the stationary terminal. So this very simple analysis does seem to favor a high degree of compression. >The error resilience >part (or the lack of it) in the current AMR draft is exactly one of my >big concerns as I talked about in my first email. > >Cheers, >-Qiaobing > >> >> The IETF should not worry ONLY about wireless, of course, but it certainly >> seems appropriate to ensure that things work over wireless as well as over >> the rest of the currently largely wired Internet. >> >> Cheers, >> >> Mikael Degermark > From rem-conf-request@es.net Thu Oct 5 00:43:14 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA10045 for ; Thu, 5 Oct 2000 00:43:13 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h2mQ-000717-00; Wed, 4 Oct 2000 21:37:14 -0700 Received: from inet-tsb.toshiba.co.jp [202.33.96.40] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h2mM-00070v-00; Wed, 4 Oct 2000 21:37:11 -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 NAA17396; Thu, 5 Oct 2000 13:36:43 +0900 (JST) Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id NAA29241; Thu, 5 Oct 2000 13:36:42 +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 NAA19575; Thu, 5 Oct 2000 13:36:34 +0900 (JST) Received: from ave (srg-204 [133.196.81.204]) by mailhost.eel.rdc.toshiba.co.jp (8.9.3/1.10) with SMTP id NAA35856; Thu, 5 Oct 2000 13:36:33 +0900 (JST) Message-ID: <046501c02e85$e2994f00$cc51c485@eel.rdc.toshiba.co.jp> From: "Yoshihiro Kikuchi" To: "Stephan Wenger" Cc: "Colin Perkins" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" References: <200010040444.AAA09294@purple.east.isi.edu> <5.0.0.25.2.20001004173727.02f62990@mail.cs.tu-berlin.de> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Date: Thu, 5 Oct 2000 13:36:52 +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 Content-Transfer-Encoding: 7bit Dear Stephan, Kris and all, Thank you very much for your comments. Seeing a comment from Kris and a suggestion form Stephan about H.263 RTP format, I think it is reasonable to keep the use of H.263 RTP format as "SHOULD", specifying only RFC2429 as suggested, and not to add the detailed timestamp definition of the short video header mode. When the short video header mode is used, RTP payload format for H.263 (RFC 2429) SHOULD be used. Best regards, Yoshihiro ----- Original Message ----- From: Stephan Wenger To: Yoshihiro Kikuchi Cc: Colin Perkins ; IETF AVT ; Yoshihiro Kikuchi Sent: Thursday, October 05, 2000 12:39 AM Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision > Dear Yoshihiro, Group, > > To my knowledge the only reason why RFC2190 is not yet OBSOLETE is > that some early H.323 products still use it. Interoperability with such > products is probably not your main concern. So I would suggest to select > RFC2429 only. > > Stephan > > At 08:15 PM 10/4/2000 +0900, Yoshihiro Kikuchi wrote: > >Dear Colin, all, > > > > > >> When the short video header mode is used, RTP payload format for > >H.263 > > > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > > > > > You should specify which of RFC 2190 or RFC 2429 is intended. > > > > >Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? > >Or, if ITU-T does not have any preference, I'm not sure if it is really > >necessary to change the text to decide this in "MPEG-4" RTP payload spec. > > > >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-request@es.net Thu Oct 5 04:16:57 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23678 for ; Thu, 5 Oct 2000 04:16:56 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h5yD-0004gO-00; Thu, 5 Oct 2000 01:01:37 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h5yC-0004gD-00; Thu, 5 Oct 2000 01:01:36 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id KAA01377; Thu, 5 Oct 2000 10:01:26 +0200 (MEST) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma001346; Thu, 5 Oct 00 10:01:28 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA11541; Thu, 5 Oct 2000 10:01:23 +0200 (MET DST) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA15956; Thu, 5 Oct 2000 10:01:21 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900012513789; Thu, 5 Oct 2000 10:08:11 +0200 To: <4on2andIP-sys@advent.ee.columbia.edu>, Subject: Re: Types of MPEG-4 streams over IP Message-ID: <0056900012513789000002L092*@MHS> Date: Thu, 5 Oct 2000 10:08:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 09:55:29" Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA23678 matsui@drl.mei.co.jp wrote: > Dear Jan and all, > > >Can we assume that the following streams are probably most efficiently > >contained in a FlexMux stream, and consequently that is no need to specify > >use of RTP and SDP for those streams: > > > >- ObjectDescriptorStream > >- ClockReferenceStream > >- SceneDescriptionStream > >- MPEG-7Stream > >- IPMPStream > >- ObjectContentInfoStream > >- MPEGJStream > > In my opinion, those streams should be carried on a reliable channel > rather than RTP. I wish that was possible too, however ... In a truly scalable distribution architecture you must use connectionless protocols. RTP on UDP multicast is the key candidate. NB: Retransmission of lost data requires a return channel that is not always present and if it were present would probably be not very scalable so forget about absolute reliability too, repetition (and FEC) are what we have to make sure can work Therefore scalable broadcast requires RTP transport of ALL these streams as well as SDP in repeated SAP packets. > > > What I am not sure is the scene description stream. > There are two kind of the scene description stream, one is BIFS-update > and another is BIFS-Anim. In my understanding, BIFS-Anim should > be streamed like audio/visual streams. > Same thing for both, must be possible to broadcast them too. Regards, -- Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com From rem-conf-request@es.net Thu Oct 5 04:33:58 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23781 for ; Thu, 5 Oct 2000 04:33:58 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h6Jh-0006CV-00; Thu, 5 Oct 2000 01:23:49 -0700 Received: from penguin-ext.wise.edt.ericsson.se [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h6Jf-0006C6-00; Thu, 5 Oct 2000 01:23:48 -0700 Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e958NbZ21280; Thu, 5 Oct 2000 10:23:38 +0200 (MEST) Received: from era.ericsson.se (rcur34ip54.ericsson.se [147.214.34.54]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id KAA25011; Thu, 5 Oct 2000 10:23:36 +0200 (MET DST) Message-ID: <39DC3A89.2DF44B03@era.ericsson.se> Date: Thu, 05 Oct 2000 10:23:37 +0200 From: Magnus Westerlund Organization: Ericsson Research X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Mikael Degermark CC: Qiaobing Xie , Krister Svanbro , Qiaobing Xie , rem-conf@es.net Subject: Re: Comments on draft-ietf-avt-rtp-amr-00.txt References: <39D203BA.561299A1@era.ericsson.se> <200009271749.MAA02664@agevole.cig.mot.com> <39D88E7D.DFCD1BC7@era.ericsson.se> <200010022348.SAA16501@agevole.cig.mot.com> <200010042121.OAA19379@baskerville.CS.Arizona.EDU> <200010050228.TAA27598@baskerville.CS.Arizona.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 7bit Hello everyone! We agree with the comments from Mikael Degermark, and would like to address some issues raised in the last days: 1) AMR is of course suitable for a multitude of applications. We know that it will be used for wireless and also over internet. The wireless case is important and in this case saving an octet per packet is very desirable. Therefore, bandwidth efficiency should be prioritiesed. 2) The IAB supports, as I see it, the design of bandwidth efficient solutions, see e.g. section 3.8 in http://www.ietf.org/internet-drafts/draft-iab-wirelessws-01.txt . 3) What is to complex? We have compared the payload packetization with the speech codec. We are using the optimized official ETSI/3GPP floating point AMR codec and an unoptimized payload packetizer. The load is expressed in percent of an Windows NT machine with a Pentium III 500 MHz processor. Speech encoder: 7.1% Payload packetizer: 0.058 % Payload depacketizer: 0.058 % Speech decoder: 1.1% All figures are for the AMR mode with the most complex packetization and the least favorable number of frames per packet, i.e. worst case for the payload packetizer. The data bits are already reshuffled bitwise in the speech encoder. If the robust sorting is done in conjunction with the reshuffling in the speech encoder the extra complexity would decrease. Note also that the default operation is the simple and not the robust sorting. 4) UEP/UED schemes under development that can utilise the fact that the payload is sorted in error sensitivity order. The UDP Lite Protocol, http://search.ietf.org/internet-drafts/draft-larzon-udplite-03.txt An RTP Payload Format for Generic FEC with Uneven Level Protection, http://search.ietf.org/internet-drafts/draft-li-ulp-00.txt An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams, http://search.ietf.org/internet-drafts/draft-lnt-avt-uxp-02.txt Best regards Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se From rem-conf-request@es.net Thu Oct 5 05:15:13 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24038 for ; Thu, 5 Oct 2000 05:15:12 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h71f-0000lV-00; Thu, 5 Oct 2000 02:09:15 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h71d-0000lB-00; Thu, 5 Oct 2000 02:09:13 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id LAA06318; Thu, 5 Oct 2000 11:09:07 +0200 (MEST) (envelope-from philippe.gentric@philips.com) From: philippe.gentric@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma006316; Thu, 5 Oct 00 11:09:08 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA22987; Thu, 5 Oct 2000 11:09:07 +0200 (MET DST) Received: from EMLMS01.DIAMOND.PHILIPS.COM (emlms01sv1.diamond.philips.com [130.143.165.213]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id LAA15192; Thu, 5 Oct 2000 11:09:06 +0200 (MET DST) Received: by EMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA1 id 0056900012516881; Thu, 5 Oct 2000 11:15:55 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Message-ID: <0056900012516881000002L012*@MHS> Date: Thu, 5 Oct 2000 11:15:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 10:53:31" Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA24038 kiku@eel.rdc.toshiba.co.jp wrote: > Dear experts, > > Attached find please a draft text for the revision of MPEG-4 Audio/Visual > RTP Internet-Draft. > > > > Please let us know if there is comment on the attached draft. The authors > need to submit it soon as an updated I-D and hopefully final before RFC. > I would like to know why the presence of configuration information in the SDP is OPTIONAL. I would think much preferable if the profile-level-id and config fields would be REQUIRED. The reasons being that: - it is only a few bytes anyway - a decoder implementation would always have the possibility to be initialized using the information in the SDP, which is easier for many implementation because parsing the video syntax requires a video decoder and when you instanciate a video decoder it is VERY handy to already have the configuration ! - it would help a receiver discover that it cannot decode a given stream (without having to request and start receiving the actual stream and parse it) and that may be the key reason: in all modes of delivery this would solve a "security" issue: A malignant (or stupid) user of a non-capable decoder could generate a lot of traffic by requesting repeatedly streams that cannot be decoded, which the decoder could discover "at once" by parsing the SDP, if the SDP would always contain the config info... - it would save (a little) bandwidth since frequent repetition of VOL in the stream is required only for clients who do not use SDP info, you could then have streams that actually do not repeat the VOL, or only rarely. In point to point delivery, in case the stream cannot be decoded by client, it saves: - several round trips - quite some network traffic - quite some server load In broadcast (IP multicast) it saves: - some start time since the decoder can start parsing immediatly after receiving the SDP, without having to wait for repeated VOL - quite some traffic too (in case the stream cannot be decoded by client) since issuing a IGMP "join" in order to receive the stream will "flood" all the network legs between broadcaster and client. ************************************************************* Furtheremore I would like to know the exact status of video B frames relative to this proposal. > Regards, Philippe Gentric Software Architect PHILIPS DIGITAL NETWORKS Broadcast & Internet Delivery Solutions Laboratoires d'Electronique Philips B.P. 15 - 22, Av. Descartes 94453 Limeil-Brevannes Cedex France Phone : 33 (0)1 45 10 68 12 Fax : 33 (0)1 45 10 69 60 philippe.gentric@philips.com From rem-conf-request@es.net Thu Oct 5 06:38:55 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24818 for ; Thu, 5 Oct 2000 06:38:55 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h8IW-0003O1-00; Thu, 5 Oct 2000 03:30:44 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13h8IV-0003Nr-00; Thu, 5 Oct 2000 03:30:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24608; Thu, 5 Oct 2000 06:30:42 -0400 (EDT) Message-Id: <200010051030.GAA24608@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-amr-01.txt Date: Thu, 05 Oct 2000 06:30:42 -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 AMR Author(s) : J. Sjoberg, M. Westerlund, A. Lakaniemi, P. Koskelainen, B. Wimmer, T. Fingscheidt Filename : draft-ietf-avt-rtp-amr-01.txt Pages : 17 Date : 04-Oct-00 This document describes a proposed real-time transport protocol (RTP) [8] payload format for AMR speech encoded [1] signals. The AMR payload format is designed to be able to interoperate with existing AMR transport formats. This document also includes a MIME type registration for AMR. The MIME type is specified for both real-time transport and storage. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-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-amr-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-amr-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: <20001004102612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-amr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-amr-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001004102612.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 5 07:25:58 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25854 for ; Thu, 5 Oct 2000 07:25:57 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13h91u-00058R-00; Thu, 5 Oct 2000 04:17:38 -0700 Received: from katto.comm.waseda.ac.jp (pisces.katto.comm.waseda.ac.jp) [133.9.196.230] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13h91o-00058A-00; Thu, 5 Oct 2000 04:17:32 -0700 Received: from i810 ([133.9.250.220]) by pisces.katto.comm.waseda.ac.jp (8.9.3/3.7W) with SMTP id UAA13785; Thu, 5 Oct 2000 20:17:10 +0900 Message-ID: <026f01c02ebd$ce12a940$dcfa0985@katto.comm.waseda.ac.jp> From: "Jiro Katto" To: "SIGNES Julien / ENVIVIO" , "'Y. Matsui'" , <4on2andIP-sys@advent.ee.columbia.edu> Cc: References: <337055FBC675D311A85D00508B5A9C4F355324@u-mail.rd.francetelecom.com> Subject: Re: Types of MPEG-4 streams over IP Date: Thu, 5 Oct 2000 20:17:10 +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 Content-Transfer-Encoding: 7bit Dear all, I completely agree with Yoshinori, > Hello, > > > Dear Jan and all, > > > > >Can we assume that the following streams are probably most > > efficiently > > >contained in a FlexMux stream, and consequently that is no > > need to specify > > >use of RTP and SDP for those streams: > > > > > >- ObjectDescriptorStream > > >- ClockReferenceStream > > >- SceneDescriptionStream > > >- MPEG-7Stream > > >- IPMPStream > > >- ObjectContentInfoStream > > >- MPEGJStream > > > > In my opinion, those streams should be carried on a reliable channel > > rather than RTP. > > I agree in general they should be fully reliable channels carrying those,as > well as BIFS comands. However, note that a lot of streaming those days is > actually done by RTP over TCP. That may be. But, I guess RTP is still used for video and audio streams even in this case, too. When we say the listed streams above are conveyed as "data" or "control" (not "video" nor "audio"), this is fully aligned with the underlying layers (TransMux, in MPEG world), i.e. H.323 and SIP/SDP. I think it is free for MPEG to attach a SL header to the listed streams in order to treat them as synchronized time events. However, I cannot find any reason why RTP usage is forced. > > What I am not sure is the scene description stream. > > There are two kind of the scene description stream, one is BIFS-update > > and another is BIFS-Anim. In my understanding, BIFS-Anim should > > be streamed like audio/visual streams. > > I agree. I agree, too. This is the final thing to complete the "MPEG4 over IP" framework, in my mind. Quite sorry for my noises. -- Jiro Katto Waseda University From rem-conf-request@es.net Thu Oct 5 08:53:09 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27949 for ; Thu, 5 Oct 2000 08:53:09 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hAMg-0007l2-00; Thu, 5 Oct 2000 05:43:10 -0700 Received: from purple.east.isi.edu [38.245.76.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hAMZ-0007kA-00; Thu, 5 Oct 2000 05:43:05 -0700 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 IAA02405; Thu, 5 Oct 2000 08:38:26 -0400 Message-Id: <200010051238.IAA02405@purple.east.isi.edu> To: philippe.gentric@philips.com cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>, rem-conf Subject: Re: Types of MPEG-4 streams over IP In-Reply-To: Message from philippe.gentric@philips.com of "Thu, 05 Oct 2000 10:08:11 +0200." <0056900012513789000002L092*@MHS> Date: Thu, 05 Oct 2000 08:38:26 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> philippe.gentric@philips.com writes: >matsui@drl.mei.co.jp wrote: >> In my opinion, those streams should be carried on a reliable channel >> rather than RTP. > >I wish that was possible too, however ... > >In a truly scalable distribution architecture >you must use connectionless protocols. > >RTP on UDP multicast is the key candidate. > >NB: Retransmission of lost data requires a return channel >that is not always present and if it were present >would probably be not very scalable so forget >about absolute reliability too, repetition (and FEC) >are what we have to make sure can work > >Therefore scalable broadcast requires RTP transport >of ALL these streams as well as SDP in repeated SAP packets. ...or some form of reliable multicast. You will never get 100% reliability from RTP, whereas there are reliable multicast protocols which achieve this with no backchannel. See the work ongoing in the IETF RMT working group. I'm very nervous about the use of RTP here - it's NOT appropriate for reliable transport. Colin From rem-conf-request@es.net Thu Oct 5 09:02:55 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28166 for ; Thu, 5 Oct 2000 09:02:54 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hAZ6-0000oI-00; Thu, 5 Oct 2000 05:56:00 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hAZ5-0000o8-00; Thu, 5 Oct 2000 05:55:59 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id OAA14117; Thu, 5 Oct 2000 14:55:55 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma014108; Thu, 5 Oct 00 14:55:56 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA20860; Thu, 5 Oct 2000 14:55:53 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA12149; Thu, 5 Oct 2000 14:55:53 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014616933; Thu, 5 Oct 2000 14:56:57 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014616933000002L932*@MHS> Date: Thu, 5 Oct 2000 14:56:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 15:54:04" Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA28166 Dave, all, Dave wrote : >I am not opposed to allowing the use of flexmux. The proposal was >that certain stream types (e.g. MPEG-7) could *only* be carried in >flexmux. I was not that strong, but only asked whether there is a need for direct carriage over RTP, given that there is a solution to carry such streams inside a FlexMux. But anyhow, I think the answer is clear, though I still don't understand how to reduce the huge overhead in case of the (usually) small messages if not by using FlexMux. Regards, Jan From rem-conf-request@es.net Thu Oct 5 11:05:18 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00521 for ; Thu, 5 Oct 2000 11:05:16 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hCPX-0004Na-00; Thu, 5 Oct 2000 07:54:15 -0700 Received: from gateway-gw.pictel.com [140.242.1.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hCPV-0004NO-00; Thu, 5 Oct 2000 07:54:13 -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 ESMTP id KAA17619; Thu, 5 Oct 2000 10:58:39 -0400 (EDT) Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision To: "Yoshihiro Kikuchi" Cc: "Stephan Wenger" , "Colin Perkins" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" From: Qunshan_Gu@pictel.com Date: Thu, 5 Oct 2000 10:54:18 -0400 Message-ID: X-MIMETrack: Serialize by Router on SMTPMail/PicTel(Release 5.0.4 |June 8, 2000) at 10/05/2000 10:53:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Yoshihiro-san, Stephan, and Kris, Since short-video-header mode of MPEG-4 is essentially H.263V1 baseline, RFC 2190 and RFC 2429 are both allowed to be the packetization format in the H.263 world. For maximal inter-operability with today's implementation, and for compatibility with H.263 definition, I would suggest the inclusion of both RFC2190 and RFC2429 in the statement. I know for a fact that many H.263 over IP implementations are still only using RFC2190. Best regards, Qunshan ------------- "Yoshihiro Kikuchi" @advent.ee.columbia.edu on 10/05/2000 12:36:52 AM Sent by: owner-4on2andIP-sys@advent.ee.columbia.edu To: "Stephan Wenger" cc: "Colin Perkins" , "IETF AVT" , "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "Yoshihiro Kikuchi" Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision Dear Stephan, Kris and all, Thank you very much for your comments. Seeing a comment from Kris and a suggestion form Stephan about H.263 RTP format, I think it is reasonable to keep the use of H.263 RTP format as "SHOULD", specifying only RFC2429 as suggested, and not to add the detailed timestamp definition of the short video header mode. When the short video header mode is used, RTP payload format for H.263 (RFC 2429) SHOULD be used. Best regards, Yoshihiro ----- Original Message ----- From: Stephan Wenger To: Yoshihiro Kikuchi Cc: Colin Perkins ; IETF AVT ; Yoshihiro Kikuchi Sent: Thursday, October 05, 2000 12:39 AM Subject: Re: draft text for MPEG-4 Audio/Visual RTP I-D revision > Dear Yoshihiro, Group, > > To my knowledge the only reason why RFC2190 is not yet OBSOLETE is > that some early H.323 products still use it. Interoperability with such > products is probably not your main concern. So I would suggest to select > RFC2429 only. > > Stephan > > At 08:15 PM 10/4/2000 +0900, Yoshihiro Kikuchi wrote: > >Dear Colin, all, > > > > > >> When the short video header mode is used, RTP payload format for > >H.263 > > > >< (e.g., RFC 2190 or RFC 2429) SHOULD be used. > > > > > > You should specify which of RFC 2190 or RFC 2429 is intended. > > > > >Can I ask suggestions from ITU-T H.263 experts on this selection of RFCs? > >Or, if ITU-T does not have any preference, I'm not sure if it is really > >necessary to change the text to decide this in "MPEG-4" RTP payload spec. > > > >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-request@es.net Thu Oct 5 11:23:00 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01002 for ; Thu, 5 Oct 2000 11:22:58 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hCk0-0005Wc-00; Thu, 5 Oct 2000 08:15:24 -0700 Received: from mgw-x1.nokia.com [131.228.20.21] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hCjy-0005WS-00; Thu, 5 Oct 2000 08:15:22 -0700 Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-x1.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id e95FF6K29827; Thu, 5 Oct 2000 18:15:06 +0300 (EET DST) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Thu, 5 Oct 2000 10:15:05 -0500 Message-ID: <8572CF1E2A95D211A1190008C7EAA2460213B8DA@daeis05nok> From: zhigang.liu@nokia.com To: micke@CS.Arizona.EDU, xieqb@cig.mot.com Cc: micke@optima.CS.Arizona.EDU, krister.svanbro@lu.erisoft.se, Qiaobing_Xie-QXIE1@email.mot.com, magnus.westerlund@era.ericsson.se, rem-conf@es.net Subject: RE: Comments on draft-ietf-avt-rtp-amr-00.txt Date: Thu, 5 Oct 2000 10:11:06 -0500 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 > The tradeoff is between the cost of sending the bits across the link and > the processing cost at the sender/receiver. > ... > So this very simple analysis does seem to favor a high degree > of compression. I agree with Mikael (not only because I happen to participate the rohc work as well :-)). Another reason: it is the physical law that limits the bandwidth of radio links. You cannot increase bandwidth infinitely like it is done in wireline links by putting more and more optical fibers/cables. On the other hand, the power of chips (per volume) has keep increasing and will continue to do so in the future. So, the processing cost at the sender/receiver will become less significant as time passes by. Br, Zhigang From rem-conf-request@es.net Thu Oct 5 11:51:10 2000 Received: from mail1.es.net (mail1.es.net [198.128.3.181]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01778 for ; Thu, 5 Oct 2000 11:51:09 -0400 (EDT) Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13hDCa-0006io-00; Thu, 5 Oct 2000 08:44:56 -0700 Received: from gw-nl4.philips.com [212.153.190.6] by mail1.es.net with esmtp (Exim 1.81 #2) id 13hDCY-0006ie-00; Thu, 5 Oct 2000 08:44:54 -0700 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id RAA17214; Thu, 5 Oct 2000 17:44:52 +0200 (MEST) (envelope-from jan.vandermeer@philips.com) From: jan.vandermeer@philips.com Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma017204; Thu, 5 Oct 00 17:44:52 +0200 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA08033; Thu, 5 Oct 2000 17:44:51 +0200 (MET DST) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA01245; Thu, 5 Oct 2000 17:44:50 +0200 (MET DST) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA3 id 0056890014623506; Thu, 5 Oct 2000 17:45:55 +0200 To: Cc: , <4on2andIP-sys@advent.ee.columbia.edu> Subject: RE: Types of MPEG-4 streams over IP Message-ID: <0056890014623506000002L962*@MHS> Date: Thu, 5 Oct 2000 17:45:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 10/05/00 18:43:13" Content-Disposition: inline X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA01778 Dave, You wrote : >What is wrong with Carsten et al.'s sync layer mapping into RTP Good question, as usual. Let me list a few issues : 1) Substantial overhead for small access units; a solution is being discussed for audio, but not yet for the other streams I listed; some may indeed deserve a more reliable transport method, but an RTP solution will be required too, I think. Perhaps use of FlexMux the only solution here. 2) Inclusion of a plain SL header with associated fields; I would prefer to start with a byte indicating the length of the subsequent field that contains the SL header. Such field is easily decodable by non-MPEG-4 system receivers, provides a future proof solution (in future more information may be contained in the SL header with a length that is unknown by now), and creates room for fully compatible extensions. 3) Little commonality with the Kikuchi-san drafts for audio and video. Perhaps it is possible to merge both solutions by extending the Kikuchi-san drafts with the option to carry an SL header (preceded by the above length field), for example signaled by a new attribute "MPEG-4 SL header carried" at SDP level. Kind regards, Jan >Can we assume that the following streams are probably most efficiently >contained in a FlexMux stream, and consequently that is no need to specify >use of RTP and SDP for those streams: > >- ObjectDescriptorStream >- ClockReferenceStream >- SceneDescriptionStream >- MPEG-7Stream >- IPMPStream >- ObjectContentInfoStream >- MPEGJStream I would be strongly opposed to mandating the use of flexmux for any stream. What is wrong with Carsten et al.'s sync layer mapping into RTP? -- David Singer Apple Computer/QuickTime