- From: Philipp Hoschka <ph@w3.org>
- Date: Tue, 12 Dec 2000 13:35:03 -0500
- To: Glenn Parsons <gparsons@nortelnetworks.com>
- CC: thierry michel <tmichel@w3.org>, www-smil <www-smil@w3.org>, discuss <discuss@apps.ietf.org>, vpim <vpim@lists.neystadt.org>
Glenn, see http://www.w3.org/AudioVideo/#SMIL Note that audio/basic, while ok for interoperability, is certainly not the most frequently used audio codec in the SMIL area - but this was the best we felt we could do in the interop area, for the reasons already stated. -Philipp Glenn Parsons a écrit : > > Forgive my ignorance, but could you give us an example of a SMIL player? > > On 12/12/00 5:54 am, "Philipp Hoschka" <hoschka@yahoo.com> wrote: > > > The rationale for picking audio/basic was that it > > is widely supported in SMIL players today, and doesn't > > require paying a license fee. > > > > If you know of another license-free, widely > > supported audio format with better > > characteristics than audio/basic, that may be > > interesting. > > > > --- thierry michel <tmichel@w3.org> wrote: > >> RE: 3GPP-T-WG3 codecs > >> ----- Original Message ----- > >> From: Glenn Parsons > >> To: discuss@apps.ietf.org ; www-smil@w3.org ; > >> 'Philipp Hoschka' > >> Cc: 'IETF VPIM List' > >> Sent: Monday, December 11, 2000 8:28 PM > >> Subject: [Moderator Action] 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#BaselineForma > > tsNS > >> > >> > >>> 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. > >> > >> > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Shopping - Thousands of Stores. Millions of Products. > > http://shopping.yahoo.com/ > >
Received on Tuesday, 12 December 2000 13:39:43 UTC