Re: [codec] #16: Multicast?
stephen botzko <stephen.botzko@gmail.com> Sat, 24 April 2010 23:37 UTC
Return-Path: <stephen.botzko@gmail.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CEE3A67FD for <codec@core3.amsl.com>; Sat, 24 Apr 2010 16:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.764
X-Spam-Level:
X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_05=-1.11, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K10te-iUB71F for <codec@core3.amsl.com>; Sat, 24 Apr 2010 16:37:06 -0700 (PDT)
Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by core3.amsl.com (Postfix) with ESMTP id 393F33A6782 for <codec@ietf.org>; Sat, 24 Apr 2010 16:37:05 -0700 (PDT)
Received: by iwn32 with SMTP id 32so7228479iwn.18 for <codec@ietf.org>; Sat, 24 Apr 2010 16:36:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JhzUziPFY/Yglq2Y+Cq6jYGYSjlbBTzpmBnmTv0eV+U=; b=xGpfmguTNOD19OcIfCs8AGlqExZj0tC6gg2J+5+Xis4dUtd4sE293ZaKX08fXYTQg8 2vzNlSaUJs1Mft3OFl8BJWzayeb27EDPXc42K0owdCA1ty9I1Kvg7vzUU6y9rODXMvBo 9MdjyWtHlSQbC/ro36RSBRFxrwMvOnsw+oF2I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ym3BqF1zNn0Vc0e/1DQIWHmeeYBMfkFfcIx5gxzZNEz/ISaY3xCNTIFzukKSrbmTbM g6eEU7+5w9wVRgmZkmQ3FnV55Zs0oVGDt64c630wGzFCoHmLxliEi8bluQsMOef2hBRO 8dPNBWJx8tMl7COK7vDOI3uoGnfWsipaPVb3g=
MIME-Version: 1.0
Received: by 10.231.190.197 with SMTP id dj5mr651484ibb.58.1272152212076; Sat, 24 Apr 2010 16:36:52 -0700 (PDT)
Received: by 10.231.79.213 with HTTP; Sat, 24 Apr 2010 16:36:51 -0700 (PDT)
In-Reply-To: <20100424135607.84293hkaa13j1zvr@mail.skype.net>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A270@IRVEXCHCCR01.corp.ad.broadcom.com> <20100424135607.84293hkaa13j1zvr@mail.skype.net>
Date: Sat, 24 Apr 2010 19:36:51 -0400
Message-ID: <x2r6e9223711004241636uc9a8eb69l8b95dfc9ad59a1e9@mail.gmail.com>
From: stephen botzko <stephen.botzko@gmail.com>
To: Koen Vos <koen.vos@skype.net>
Content-Type: multipart/alternative; boundary="0016367b6332b3798c048504048d"
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Apr 2010 23:37:08 -0000
>>> Sure - for certain frame sizes. But 1 ms frames won't give you 5 ms one-way delay. >>> Agreed, this delay model is too simplisti to be useful. There's algorithmic delay (including framing) + flight time + dejittering. Flight time depends on the network path, not on the frame size. And the amount of jitter is due principally to cross-congestion. Stephen Botzko On Sat, Apr 24, 2010 at 4:56 PM, Koen Vos <koen.vos@skype.net> wrote: > Quoting "Raymond (Juin-Hwey) Chen" > > An IP phone guru told me that for a typical IP phone application, it is >> also quite common to see a one-way delay of 5 times the codec frame size. >> > > Sure - for certain frame sizes. But 1 ms frames won't give you 5 ms > one-way delay. > > For a well-designed system and a typical Internet connection: > - most delay comes from the network and is not codec related, and > - one-way delay grows almost linearly with frame size. > > > > Furthermore, it is possible to use header compression technology to shrink >> that 48 kb/s penalty to almost nothing. >> > > Afaik, only RTP headers can be compressed between arbitrary Internet end > points. You're still stuck with IP and UDP headers. > > best, > koen. > > > > > Quoting "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>: > >> Hi Jean-Marc, >> >> I agree that the 20 ms frame size or packet size is more efficient in >> bit-rate. However, this comment doesn't address my original point on the >> need to have a low-delay IETF codec for the conferencing bridge scenario, >> where the voice signal will travel through the codec twice (2 tandems), thus >> doubling the one-way codec delay. >> >> As you are well aware of, codec design involves many trade-offs between >> the four major attributes of a codec: delay, complexity, bit-rate, and >> quality. For a given codec architecture, improving one attribute normally >> means sacrificing at least one other attribute. Nothing comes for free. >> Therefore, yes, to get low delay, you need to pay the price of lower >> bit-rate efficiency, but you can also view it another way: to get higher >> bit-rate efficiency by using a 20 ms frame size, you pay the price of a >> higher codec delay. The question to ask then, is not which frame size is >> more bit-rate efficient, but whether there are application scenarios where a >> 20 ms frame size will simply make the one-way delay way too long and greatly >> degrade the users' communication experience. I believe the answer to the >> latter question is a definite "yes". >> >> Let's do some math to see why that is so. Essentially all cellular codecs >> use a frame size of 20 ms, yet the one-way delay of a cell-to-landline call >> is typically 80 to 110 ms, or 4 to 5.5 times the codec frame size. This is >> because you have not only the codec buffering delay, but also processing >> delay, transmission delay, and delay due to processor sharing using >> real-time OS, etc. An IP phone guru told me that for a typical IP phone >> application, it is also quite common to see a one-way delay of 5 times the >> codec frame size. Let's just take 5X codec frame size as the one-way delay >> of a typical implementation. Then, even if all conference participants use >> their computers to call the conference bridge, if the IETF codec has a frame >> size of 20 ms, then after the voice signal of a talker goes through the IETF >> codec to the bridge, it already takes 100 ms one-way delay. After the >> bridge decodes all channels, mixes, and re-encodes with the IETF codec and >> send to every particip >> ant, the one-way delay is now already up to 200 ms, way more than the 150 >> ms limit I mentioned in my last email. Now if a talker call into the >> conference bridge through a cell phone call that has 100 ms one-way delay to >> the edge of the Internet, by the time everyone else hears his voice, it is >> already 300 ms later. Anyone trying to interrupt that cell phone caller >> will experience the talk-stop-talk-stop problem I mentioned before. Now if >> another cell phone caller call into the conference bridge, then the one-way >> delay of his voice to the first cell phone caller will be a whopping 400 ms! >> That would probably turn it into half-duplex effectively. >> >> When we talk about "high-quality" conference call, it is much more than >> just the quality or distortion level of the voice signal; the one-way delay >> is also an important and integral part of the perceived quality of the >> communication link. This is clearly documented and well-modeled in the >> E-model of the ITU-T G.107, and the 150 ms limit, beyond which the perceived >> quality sort of "falls off the cliff", was also obtained after careful study >> by telephony experts at the ITU-T. It would be wise for the IETF codec WG >> to heed the warning of the ITU-T experts and keep the one-way delay less >> than 150 ms. >> >> In contrast, if the IETF codec has a codec frame size and packet size of 5 >> ms, then the on-the-net one-way conferencing delay is only 50 ms. Even if >> you use a longer jitter buffer, the one-way delay is still unlikely to go >> above 100 ms, which is still well within the ITU-T's 150 ms guideline. >> >> True, sending 5 ms packets means the packet header overhead would be >> higher, but that's a small price to pay to enable the conference >> participants to have a high-quality experience by avoiding the problems >> associated with a long one-way delay. The bit-rate penalty is not 64 kb/s >> as you said, but 3/4 of that, or 48 kb/s, because you don't get zero packet >> header overhead for a 20 ms frame size, but 16 kb/s, so 64 - 16 = 48. >> >> Now, with the exception of a small percentage of Internet users who still >> use dial-up modems, the vast majority of the Internet users today connect to >> the Internet at a speed of at least several hundred kb/s, and most are in >> the Mbps range. A 48 kb/s penalty is really a fairly small price to pay for >> the majority of Internet users when it can give them a much better >> high-quality experience with an much lower delay. >> >> Furthermore, it is possible to use header compression technology to shrink >> that 48 kb/s penalty to almost nothing. >> >> Also, even if a 5 ms packet size is an overkill in some situations, a >> codec with a 5 ms frame size can easily packs two frames of compressed >> bit-stream into a 10 ms packet. Then the packet header overhead bit-rate >> would be 32 kb/s, so the penalty shrinks by a factor of 3 from 48 kb/s to 32 >> - 16 = 16 kb/s. With 10 ms packets, the one-way conferencing delay would be >> 100 ms, still well within the 150 ms guideline. (Actually, since the >> internal "thread rate" of real-time OS can still run at 5 ms intervals, the >> one-way delay can be made less than 100 ms, but that's too much detail to go >> into.) In contrast, a codec with a 20 ms frame size cannot send its >> bit-stream with 10 ms packets, unless it spreads each frame into two >> packets, which is what IETF AVT advises against, because it will effectively >> double the packet loss rate. >> >> The way I see it, for conference bridge applications at least, I think it >> would be a big mistake for IETF to recommend a codec with a frame size of 20 >> ms or higher. From my analysis above, by doing that we will be stuck with >> too long a delay and the associated problems. >> >> Best Regards, >> >> Raymond >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] >> Sent: Thursday, April 22, 2010 9:05 PM >> To: Raymond (Juin-Hwey) Chen >> Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Hi, >> >> See me comments below. >> >> [Raymond]: High quality is a given, but I would like to emphasize the >>> importance of low latency. >>> >>> (1) It is well-known that the longer the latency, the lower the >>> perceived quality of the communication link. The E-model in the ITU-T >>> Recommendation G.107 models such communication quality in MOS_cqe, >>> which among other things depends on the so-called "delay impairment >>> factor" /Id/. Basically, MOS_cqe is a monotonically decreasing >>> function of increasing latency, and beyond about 150 ms one-way delay, >>> the perceived quality of the communication link drops rapidly with >>> further delay increase. >>> >>> >> As the author of CELT, I obviously agree that latency is an important >> aspect for this codec :-) That being said, I tend to say that 20 ms is >> still the most widely used frame size, so we might as well optimise for >> that. This is not really a problem because as the frame size goes down, >> the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate >> becomes a bit less of an issue. For example, with 5 ms frames, we would >> already be sending 64 kb/s worth of headers (excluding the link layer), >> so we might as well spend about as many bits on the actual payload as we >> spend on the headers. And with 64 kb/s of payload, we can actually have >> high-quality full-band audio. >> >> 1) If a conference bridge has to decode a large number of voice >>> channels, mix, and re-encode, and if compressed-domain mixing cannot >>> be done (which is usually the case), then it is important to keep the >>> decoder complexity low. >>> >> >> Definitely agree here. The decoder complexity is very important. Not >> only because of mixing issue, but also because the decoder is generally >> not allowed to take shortcuts to save on complexity (unlike the >> encoder). As for compressed-domain mixing, as you say it is not always >> available, but *if* we can do it (even if only partially), then that can >> result in a "free" reduction in decoder complexity for mixing. >> >> 2) In topology b) of your other email >>> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or >>> VoIP gateway, often has to encode and decode thousands of voice >>> channels in a single box, so not only the computational complexity, >>> but also the per-instance RAM size requirement of the codec become >>> very important for achieving high channel density in the gateway. >>> >>> >> Agreed here, although I would say that per-instance RAM -- as long as >> it's reasonable -- is probably a bit less important than complexity. >> >> 3) Many telephone terminal devices at the edge of the Internet use >>> embedded processors with limited processing power, and the processors >>> also have to handle many tasks other than speech coding. If the IETF >>> codec complexity is too high, some of such devices may not have >>> sufficient processing power to run it. Even if the codec can fit, some >>> battery-powered mobile devices may prefer to run a lower-complexity >>> codec to reduce power consumption and battery drain. For example, even >>> if you make a Internet phone call from a computer, you may like the >>> convenience of using a Bluetooth headset that allows you to walk >>> around a bit and have hands-free operation. Currently most Bluetooth >>> headsets have small form factors with a tiny battery. This puts a >>> severe constraint on power consumption. Bluetooth headset chips >>> typically have very limited processing capability, and it has to >>> handle many other tasks such as echo cancellation and noise reduction. >>> There is just not enough processing power to handle a relatively >>> high-complexity codec. Most BT headsets today relies on the extremely >>> low-complexity, hardware-based CVSD codec at 64 kb/s to transmit >>> narrowband voice, but CVSD has audible coding noise, so it degrades >>> the overall audio quality. If the IETF codec has low enough >>> complexity, it would be possible to directly encode and decode the >>> IETF codec bit-stream at the BT headset, thus avoiding the quality >>> degradation of CVSD transcoding. >>> >>> >> Any idea what the complexity requirements would be for this use-case to >> be possible? >> >> Cheers, >> >> Jean-Marc >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >
- [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? Colin Perkins
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? (USB) Roni Even
- Re: [codec] #16: Multicast? codec issue tracker
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Mikael Abrahamsson
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? (Bluetooth) Koen Vos
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #19: How large is the frame size depe… Christian Hoene
- Re: [codec] #19: How large is the frame size depe… stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #19: How large is the frame size depe… Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? (Bluetooth) Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Gregory Maxwell
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Benjamin M. Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Kevin P. Fleming
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Ben Schwartz
- Re: [codec] #16: Multicast? Marshall Eubanks
- Re: [codec] #16: Multicast? Brian Rosen
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] #20: Computational complexity? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] Thresholds and delay. jari.hagqvist
- Re: [codec] Thresholds and delay. stephen botzko
- Re: [codec] Thresholds and delay. Ben Schwartz
- Re: [codec] Thresholds and delay. Marshall Eubanks
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] Thresholds and delay. Michael Knappe
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Delay factor: algorithmic delay … Christian Hoene
- Re: [codec] #16: Delay factor: algorithmic delay … Mikael Abrahamsson
- Re: [codec] #16: Delay factor: algorithmic delay … Roman Shpount
- Re: [codec] #16: Delay factor: algorithmic delay … stephen botzko
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Cullen Jennings
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Koen Vos
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Jean-Marc Valin
- Re: [codec] #16: Multicast? Sandy (Alexander) MacInnis
- Re: [codec] #16: Multicast? Christian Hoene
- Re: [codec] #16: Multicast? Raymond (Juin-Hwey) Chen
- Re: [codec] #16: Multicast? Roman Shpount
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] #16: Multicast? Herve Taddei
- Re: [codec] #16: Multicast? Cullen Jennings
- [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Michael Knappe
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... stephen botzko
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen
- Re: [codec] Suggested summary... Christian Hoene
- Re: [codec] Suggested summary... Herve Taddei
- Re: [codec] Suggested summary... Raymond (Juin-Hwey) Chen