- From: Glenn Parsons <gparsons@nortelnetworks.com>
- Date: Thu, 7 Dec 2000 21:19:06 -0500
- To: discuss@apps.ietf.org, www-smil@w3.org, "'Philipp Hoschka'" <ph@w3.org>
- Cc: "'IETF VPIM List'" <vpim@lists.neystadt.org>
- Message-ID: <488891341182D4118A870000F80822E782B7F3@zcard00p.ca.nortel.com>
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#BaselineF > ormatsNS > > > 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.
Received on Monday, 11 December 2000 14:28:36 UTC