Glenn Parsons (gparsons@nortelnetworks.com)
Tue, 12 Dec 2000 10:29:57 -0500
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/
>
This archive was generated by hypermail 2.0b3 on Tue Dec 12 2000 - 20:33:19 IST