Registration of media type text/3gpp-tt
Martin Duerst
duerst at w3.org
Fri Oct 8 07:04:39 CEST 2004
Quickly looking at this, I see that it deals with text,
but there is no mention about how this text is encoded.
This is usually (but not always!) a sign that something
may have been overlooked.
Regards, Martin.
At 10:27 04/10/07 +0200, Rey Jose wrote:
>
>Hello,
>
>It is more than 2 weeks since I sent this in for consideration. Could you
>please inform me about the status? I would like to proceed ASAP with WGLC
>in AVT but cannot without passing this review.
>
>Thanks,
>
>Jos骼
> > -----Original Message-----
> > From: Jose Rey [mailto:rey at panasonic.de]
> > Sent: Monday, September 13, 2004 10:30 AM
> > To: IETF-Types
> > Cc: Yoshinori Matsui; Dave Singer; Jan van der Meer; Colin
> > Perkins; Magnus Westerlund (KI/EAB)
> > Subject: Registration of media type text/3gpp-tt
> >
> >
> > Hello,
> >
> > please consider the following media type text/3gpp-tt for
> > registration under the IETF tree. This section is copied from
> > the draft
> > http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-ti
> > med-text-06.txt.
> >
> > MIME type: text
> >
> > MIME subtype: 3gpp-tt
> >
> > Required parameters
> >
> > rate:
> > the RTP timestamp clockrate is equal to the
> > clockrate of
> > the media. If RTP packets are generated out of a 3GP
> > file, the clockrate of the text media MUST be copied
> > from the 3GP file, i.e. the clockrate is the value of
> > "timescale" parameter in the Media Header Box
> > describing
> > that text track. Other tracks
> > (audio/video/text) in the
> > 3GP file may have their own clockrates as
> > indicated in
> > their corresponding Media Header Box. For live
> > encoding, a clockrate of 1000 Hz is RECOMMENDED but
> > other values MAY be used. If a different
> > timestamp rate
> > value is used, this MUST be chosen carefully as per
> > Section 3 in RFCXXXX.
> >
> > sver:
> > The parameter "sver" contains a list of supported
> > backwards-compatible versions of the timed
> > text format
> > specification (3GPP TS 26.245) that the
> > sender accepts
> > to receive (and which are the same that it would be
> > willing to send). The first value is the value
> > preferred to be received ( or preferred to
> > send). The
> > first value MAY be followed by a
> > comma-separated list of
> > versions that SHOULD be used as alternatives.
> > The order
> > is meaningful, being first the most preferred
> > and last
> > the least preferred. Each entry has the format
> > Zi(xi*256+yi), where "Zi" is the number of
> > the Release,
> > "xi" and "yi" are taken from the 3GPP specification
> > version, i.e. vZi.xi.yi. For example, for 3GPP TS
> > 26.245 v6.0.0, Zi(xi*256+yi)=6(0), the
> > version value is
> > "60". (Note that "60" is the concatenation of the
> > values Zi=6 and (xi*256+yi)=0 and not its product.)
> >
> > width:
> > This parameter indicates the width in pixels
> > of the text
> > track or area of the text being sent. This
> > is a 16 bit
> > integer.
> >
> > height:
> > This parameter indicates the height in pixels of the
> > text track being sent. This is a 16 bit integer.
> >
> > max-w:
> > This parameter indicates display
> > capabilities. This is
> > the maximum "width" value that the sender of this
> > parameter supports. This is a 16 bit
> > unsigned integer.
> >
> > max-h:
> > This parameter indicates display
> > capabilities. This is
> > the maximum "height" value that the sender of this
> > parameter supports. This is a 16 bit
> > unsigned integer.
> >
> > tx:
> > This parameter indicates the horizontal translation
> > offset in pixels of the text track with
> > respect to the
> > origin of the video track. This is a 16 bit integer.
> >
> > ty:
> > This parameter indicates the vertical
> > translation offset
> > in pixels of the text track with respect to
> > the origin
> > of the video track. This is a 16 bit integer.
> >
> > layer:
> > This parameter indicates the proximity of the
> > text track
> > to the viewer. More negative values mean
> > closer to the
> > viewer. This parameter has no units. This
> > is a 16 bit
> > integer.
> >
> > Optional parameters:
> >
> >
> > tx3g:
> > This parameter MUST be used for conveying sample
> > descriptions out-of-band. It contains a
> > comma-separated
> > list of base64-encoded entries. The entries of this
> > list that MAY follow any particular order and
> > the list
> > MAY be empty. The absence of this parameter is
> > equivalent to an empty list of sample descriptions.
> > Each entry is the result of running base64
> > encoding over
> > the concatenation of the SIDX and the sample
> > description
> > for that SIDX, in this order. The format of a sample
> > description entry can be found in 3GPP TS
> > 26.245 Release
> > 6 and later releases. All servers and clients MUST
> > understand this parameter and MUST be capable
> > of using
> > the sample description(s) contained in it.
> > Please refer
> > to RFC 3548 [6] for details on the base64 encoding.
> >
> > Encoding considerations:
> >
> > RTP payloads complying with this payload format
> > contain binary
> > data.
> >
> > Note that this type is incompatible with the use of
> > text media
> > types in other protocols, e.g. text/html. This is because in
> > order to extract and decode any of the timed text media it is
> > necessary understand the (binary) payload headers defined in
> > RFCXXXX.
> >
> > Restrictions on usage:
> >
> > This type is only defined for transfer via RTP.
> >
> > Security considerations:
> >
> > Please refer to Section 10 of RFCXXXX.
> >
> > Interoperability considerations:
> >
> > The 3GPP Timed Text media format for which this
> > payload format
> > is defined is specified in Release 6 of 3GPP TS 26.245
> > "Transparent end-to-end packet switched streaming
> > service (PSS);
> > Timed Text Format (Release 6)". The 3GPP file format
> > (3GP) and
> > the SMIL language profile used can be found in
> > Release 5 of 3GPP
> > TS 26.234 and in the corresponding specifications for later
> > Releases. Note also that 3GPP may in future Releases specify
> > extensions or updates to the media format in a backwards-
> > compatible way, e.g. new modifier boxes or extensions to the
> > sample descriptions. The payload format defined in RFCXXXX
> >
> > Rey & Matsui
> > [Page 29]
> > > Internet Draft Payload Format for 3GPP Timed Text
> > September 10, 2004
> >
> >
> > allows for such extensions. For future 3GPP Releases of the
> > Timed Text Format, the parameter "sver" is used to
> > identify the
> > exact specification used.
> >
> > Published specification: RFC XXXX
> >
> > Applications which use this media type:
> >
> > Multimedia streaming applications.
> >
> > Additional information:
> >
> > the 3GPP Timed Text media format is specified in 3GPP
> > TS 26.245
> > "Transparent end-to-end packet switched streaming
> > service (PSS);
> > Timed Text Format (Release 6)". This document and future
> > extensions to the 3GPP Timed Text format are publicly
> > available
> > at http://www.3gpp.org.
> >
> > Magic number(s): None.
> >
> > File extension(s): None.
> >
> > Macintosh File Type Code(s): None.
> >
> > Person & email address to contact for further information:
> >
> > Jose Rey, rey at panasonic.de
> > Yoshinori Matsui, matsui.yoshinori at jp.panasonic.com
> > Audio/Video Transport Working Group.
> >
> > Intended usage: COMMON
> >
> > Author/Change controller:
> >
> > Jose Rey
> > Yoshinori Matsui
> > IETF AVT WG
> >
> >
> > Thank,
> >
> > ---------------------------------
> > Jose Rey
> > Mobile Multimedia Team
> > Panasonic R&D Center Germany GmbH
> > D-63225 Langen, Germany
> > Tel.:+49-6103-766-134
> > Fax :+49-6103-766-166
> > Email: rey at panasonic.de
> > Web: www.prdcg.panasonic.de
> > ---------------------------------
> >
More information about the Ietf-types
mailing list