Registration of media type text/3gpp-tt
Rey Jose
Rey at panasonic.de
Thu Oct 7 10:27:31 CEST 2004
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
> ---------------------------------
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5944 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/ietf-types/attachments/20041007/153ad662/attachment-0002.bin
More information about the Ietf-types
mailing list