RE: 3GPP-T-WG3 codecs

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#BaselineFormatsNS 

    > 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.