Registration of media type text/3gpp-tt
Rey Jose
Rey at panasonic.de
Fri Oct 8 10:24:17 CEST 2004
Hi
Thanks for the answer.
> -----Original Message-----
> From: Martin Duerst [mailto:duerst at w3.org]
> Sent: Friday, October 08, 2004 7:05 AM
> To: Rey Jose; IETF-Types
> Cc: Colin Perkins
> Subject: RE: Registration of media type text/3gpp-tt
>
> Quickly looking at this, I see that it deals with text, but
> there is no mention about how this text is encoded.
Text is encoded using UTF-8 or UTF-16. But there is not only text in the payload; there is also modifiers, which are binary. Modifiers are information pieces that allow, e.g., to make karaoke. As I understand from draft-freed-media-type-reg-01 the "Encoding Considerations"section only takes a value. In this case I think "binary" is appropriate since both UTF-8/-16s strings and the binary modifiers are mixed in the payload. I don't think it is needed to explain this again in the registration since a client accepting this media type already knows this.
Looking forward to your comments,
Jose
> 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