W3C home > Mailing lists > Public > www-smil@w3.org > October to December 2000

Re: 3GPP-T-WG3 codecs

From: Patrik Fältström <paf@cisco.com>
Date: Fri, 8 Dec 2000 05:57:10 -0800
Message-Id: <p05100622b656986eb0df@[171.70.85.72]>
To: Henning Timcke <henning.timcke@werft22.com>, Philipp Hoschka <ph@w3.org>
Cc: discuss@apps.ietf.org, www-smil@w3.org, "Leuca, Ileana" <ileana.leuca@attws.com>
At 12.56 +0100 00-12-08, Henning Timcke wrote:
>Hi
>Choosing MPEG 4 among a  minimum set of supported formats really sounds
>like joke to me.
>Who should be a able to take advantage of this minimal set as of today ?
>
>>  Suggested formats or codecs for media type Video:
>>  - MPEG 4 (Visual Simple Profile, Level 1)
>>  - ITU-T H.263
>>  - Quicktime
>
>This would look more realistic to me:
>
>>  Suggested formats or codecs for media type Video:
>>  - MPX (MPEG-1, MPEG-2, MPEG 4)
>>  - AVI
>>  - Sure Stream (TM) RS G2
>>  - Windows Media (TM)
>>  - ITU-T H.263
>>  - MOV Quicktime (TM)

I think it is important to be much much more detailed when specifying 
a list like this.

I am not working in this area much personally, but I feel we have 
three layers of "things" that needs to be standardized for a sender 
to be able to send data to a receiver:

   (a) Codec
   (b) Format
   (c) Transport Protocol

All three layers have to match for things to work. Several client 
(and server) software can handle many different permutations of the 
alternatives for each layer in this micro-stack.

Is it not something like this which have to be specified?

      paf


>
>
>Regards
>Henning
>
>----------------
>Ideen Werft22 GmbH
>
>Stadtturmstrasse 5 und 19
>CH 5400 Baden
>Telefon 056 204 29 13
>Telefax 056 202 29 01
>http://www.werft22.com
>
>Labor für Datenarchitektur
>Telefon 056 210 91 32
>Telefax 056 210 91 34
>http://virt.uals.com/
>
>Henning Timcke
>
>Streaming Live with Linux by Ideen Werft 22 GmbH:
>http://bahnhof.baden.ch
>
>
>Philipp Hoschka wrote:
>>
>>  Patrick,
>>
>>  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 ?
>>
>>  -Philipp
>>
>>  > 3GPP-T-WG3 codecs
>>  >
>>  > From: Patrik Fältström (paf@cisco.com)
>>  > Date: Thu, Nov 30 2000
>>  >
>>  > *Next message: Glenn Parsons: "RE: 3GPP-T-WG3 codecs"
>>  >
>>  >    * Previous message: Jacob Palme: "Language translation in e-mail"
>>  >    * In reply to: Jacob Palme: "Language translation in e-mail"
>  > >    * Next in thread: Glenn Parsons: "RE: 3GPP-T-WG3 codecs"
>>  >    * Reply: Glenn Parsons: "RE: 3GPP-T-WG3 codecs"
>>  >    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>  >    * Other mail archives: [this mailing list] [other W3C mailing lists]
>>  >    * Mail actions: [ respond to this message ] [ mail a new topic ]
>>  >
>>  >   ------------------------------------------------------------------------
>>  >
>>  > Message-Id: <p05100543b64c4580118a@[10.0.1.28]>
>>  > Date: Thu, 30 Nov 2000 18:58:56 +0100
>>  > To: discuss@apps.ietf.org
>>  > From: Patrik Fältström  <paf@cisco.com>
>>  > Subject: 3GPP-T-WG3 codecs
>>  >
>>  > I need people interested in the are of codecs. Can someone help with
>>  > the following request?
>>  >
>>  > Let me know if you are interested (or know someone which are interested).
>>  >
>>  >     Patrik
>>  >     Co-Area Director, Applications Area
>>  >
>>  > Date: Wednesday, 29 November, 2000 15:06 -0800
>>  > From: "Leuca, Ileana" <ileana.leuca@attws.com>
>>  > To: "'sob@harvard.edu'" <sob@harvard.edu>
>>  > Subject: 3GPP-T-WG3 codecs
>>  >
>>  > Scott,
>>  >
>>  > the 3GPP-T2-WG3 defines the minimum set of supported formats for
>>  > Multimedia Messaging Services.
>>  >
>>  > Please help to find an IETF person(s) to be included in the
>>  > process of standardizing the minimum set of codex for audio,
>>  > video and image types.
>>  >
>>  > In summary the following text is proposed today:
>>  > ==========================================
>>  > Multiple media elements shall be combined into a composite
>>  > single MM using MIME multipart format as defined in RFC 2046
>>  > [x]. The media type of a single MM element shall be identified
>>  > by its appropriate MIME type whereas the media format shall be
>>  > indicated by its appropriate MIME subtype.
>>  >
>>  > In order to guarantee a minimum support and compatibility
>>  > between multimedia messaging capable terminals, the following
>>  > media formats shall be at least supported.
>>  >
>>  > Suggested formats or codecs for media type Audio:
>>  > - AMR / EFR; organised in octet format as specified in 3G TS
>>  > 26.101 and 3G TS 26.101
>>  > - MP3
>>  > - MIDI
>>  > - WAV
>>  >
>>  > Suggested formats or codecs for media type Image:
>>  > - JPEG
>>  > - GIF 89a .
>>  >
>>  > Suggested formats or codecs for media type Video:
>>  > - MPEG 4 (Visual Simple Profile, Level 1)
>>  > - ITU-T H.263
>>  > - Quicktime
>>  >
>>  > Minimum set of supported media shall support type Text formats.
>>  > Any character encoding (charset) that contains a subset of the
>>  > logical characters in Unicode [7] shall be used (e.g. US-ASCII
>>  > [8], ISO-8859-1[9], UTF-8[10], Shift_JIS, etc.).
>>  > Unrecognised subtypes of "text" shall be treated as subtype
>>  > "plain" as long as the MIME implementation knows how to handle
>>  > the charset. Any other unrecognised subtype and unrecognised
>>  > charset shall be treated as "application/octet - stream".
>>  >
>>  > ================================================================
>>  > ============ ==
>>  > thanks,
>>  > ileana
>>  >
>>  > --
>>  >
>>  >   ------------------------------------------------------------------------
>>  >
>>  >    * Next message: Glenn Parsons: "RE: 3GPP-T-WG3 codecs"
>>  >    * Previous message: Jacob Palme: "Language translation in e-mail"
>>  >    * In reply to: Jacob Palme: "Language translation in e-mail"
>>  >    * Next in thread: Glenn Parsons: "RE: 3GPP-T-WG3 codecs"
>>  >    * Reply: Glenn Parsons: "RE: 3GPP-T-WG3 codecs"
>>  >    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>>  >    * Other mail archives: [this mailing list] [other W3C mailing lists]
>>  >    * Mail actions: [ respond to this message ] [ mail a new topic ]




-- 
Received on Friday, 8 December 2000 09:04:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:23 UTC