Brian Cruickshank (cruicb@nortelnetworks.com)
Mon, 11 Dec 2000 14:28:54 -0600
Glenn, I understand that MS-GSM is currently viewed as the codec of choice
for VPIM but has this decision been finalized yet? I think a good case can
be made for adopting the 'audio / basic' G.711 codec as a baseline VPIM
codec. As well as being a MIME standard, G.711 is the PSTN standard and
preferred codec for Voice over IP on higher bandwidth connections, is simple
to implement (low complexity, low MIPs), and offers toll-quality sound that
is suitable for voice signals (single or multiple talker) and non voice
signals.
Another important consideration is voice quality degradation in an
evironment where multiple codecs are used in tandem. Because G.711 is a
waveform coder instead of a parametric "vocal tract" coder, it introduces
fewer transcoding artifacts than MS-GSM. This helps to keep the
intelligibility of voice messages high in situations where the signal has
already been encoded with one or more different encoding technologies. You
can easily come up with scenarios where the voice message will go through
several different transcodings on its way from the caller to the called
party and will be truly mangled in the process (e.g. Cell Phone + Frame
Relay + Voice Messaging System A + VPIM + Voice Messaging System B +
Satellite link + PSTN + Voice over IP gateway) The fewer the number of
different encodings, the better the voice quality will be.
There is also the matter of back-to-back VPIM encodings. If MS-GSM is used,
a signal that is forwarded via VPIM twice will be encoded using MS-GSM
twice, which will introduce more signal quality degradation than if it was
encoded using G.711 twice.
The only drawback to G.711 that I can see is that it is a 64kbps codec and
is thus slower than real-time over a modem connection. This bandwidth
constraint is disappearing, however - the FCC says that there are over 4
million high speed lines linking households and small businesses to the
Internet in the US, with growth at around 60% in the last 6 months. DSL grew
by 157% in the same time period. To address short-term bandwidth concerns,
perhaps a VPIM codec strategy that had G.711 used as a baseline with a
secondary codec used to support low bandwidth connections would be
appropriate. At least then the user could decide whether they were more
concerned about voice quality or minimizing bandwidth utilization.
Regards,
Brian Cruickshank,
Nortel Networks
-----Original Message-----
From: Parsons, Glenn [NORSE:9T01:EXCH]
Sent: Thursday, December 07, 2000 9:19 PM
To: discuss@apps.ietf.org; www-smil@w3.org; 'Philipp Hoschka'
Cc: 'IETF VPIM List'
Subject: [VPIM] RE: 3GPP-T-WG3 codecs
Philipp, I'd be interested in the rational that made you pick audio/basic
FWIW, there is a set of "recommended" codecs in the SMIL 2.0
draft of W3C, and I'm happy to explain why we chose those, if
needed:
http://www.w3.org/TR/2000/WD-smil20-20000921/smil20-profile.html#BaselineFor
matsNS
<http://www.w3.org/TR/2000/WD-smil20-20000921/smil20-profile.html#BaselineFo
rmatsNS>
> Widely Supported MIME Types
>
> This section is informative.
>
> The members of the W3C SYMM Working Group believe that the following
> MIME types will be widely supported by SMIL players:
> * audio/basic [592][MIME-2]
> * image/png ([593][PNG-MIME], [594][PNG-REC])
> * image/jpeg ([595][MIME-2], [596][JFIF])
> Implementers of SMIL players should thus strive to provide support for
> each of these types. Note, however, that this section is
> non-normative, and that support for these MIME types is not a
> precondition for conformance to this specification.
>
> Authors are encouraged to encode media objects using one of the widely
> supported MIME types whenever possible. This will ensure that their
> SMIL documents can be played back by a wide range of SMIL players.
>
> If authors use a MIME type that is not in the list of widely supported
> types, they should provide an alternative version encoded using a
> baseline format. This can be achieved by using a switch element as
> shown in the following example:
> <switch>
> <audio src="non-baseline-format-object" />
> <audio src="baseline-format-object" />
> </switch>
>
> In this example, a player that supports the non-baseline format will
> play the first audio media object, and a player that does not support
> the non-baseline format will play the second media object.
In general, I'm a bit confused about the request - why would the
IETF have to comment on the minimal set of codecs in a format
defined by another organisation ? This would make sense if the
goal is to define a minimal set of codecs that need to be supported
by MIME mail readers, but otherwise, I don't see the point - am
I missing something ?
I don't think the IETF _has_ to comment, we've just been asked..
This is more about the codecs available on various devices. Few if any mail
clients have audio codecs included.
Cheers,
Glenn.
This archive was generated by hypermail 2.0b3 on Mon Dec 11 2000 - 22:32:11 IST