any byte order mark (BOM). See Figure 9 for details.
fragment or text sample fragment
A fraction of a text sample. A fragment may contain either text
strings or modifier (decoration) contents, but not both at the
same time.
sample contents
General term to identify timed text data transported when using
this payload format. Sample contents may be one or several text
samples, sample descriptions, and sample fragments (note that,
as per Section 4.6, there is only one case in which more than
one fragment may be included in a payload).
decoration or modifiers
These terms are used interchangeably throughout the document to
denote the contents of the text sample that modify the default
text formatting. Modifiers may, for example, specify different
font size for a particular sequence of characters or define
karaoke timing for the sample.
sample description
Information that is potentially shared by more than one text
sample. In a 3GP file, a sample description is stored in a
place where it can be shared. It contains setup and default
information such as scrolling direction, text box position,
delay value, default font, background color, etc.
units or transport units
The payload headers specified in this document encapsulate text
samples, fragments thereof, and sample descriptions by placing a
common header and specific payload header (Sections 4.1.1 to
4.1.6) before them, thus building what is here called a
(transport) unit.
aggregation or aggregate packet
The payload of an aggregate (RTP) packet consists of several
(transport) units.
track or stream
3GP files contain audio/video and text tracks. This document
enables streaming of text tracks using RTP. Therefore, these
terms are used interchangeably in this document in the context
of 3GP files.
Media Header Box / Track Header Box / ...
The 3GP file format makes use of these structures defined in the
ISO Base File Format [2]. When referring to these in this
document, initials are capitalized for clarity.
4. RTP Payload Format for 3GPP Timed Text
The format of an RTP packet containing 3GPP timed text is shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |U| R | TYPE| LEN | :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
U| : (variable header fields depending on TYPE :
N| : :
I< +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
T| | |
| : SAMPLE CONTENTS :
| | +-+-+-+-+-+-+-+-+
| | |
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. 3GPP Timed Text RTP Packet Format
Marker bit (M): The marker bit SHALL be set to 1 if the RTP packet
includes one or more whole text samples or the last fragment of a
text sample; otherwise, it is set to zero (0).
Timestamp: The timestamp MUST indicate the sampling instant of the
earliest (or only) unit contained in the RTP packet. The initial
value SHOULD be randomly determined, as specified in RTP [3].
The timestamp value should provide enough timing resolution for
expressing the duration of text samples, for synchronizing text
with other media, and for performing RTP Control Protocol (RTCP)
measurements such as the interarrival delay jitter or the RTCP
Packet Receipt Times Report Block (Section 4.3 of RFC 3611
[20]). This is compliant to RTP, Section 5.1:
"The resolution of the clock MUST be sufficient for the
desired synchronization accuracy and for measuring packet
arrival jitter (one tick per video frame is typically not
sufficient)".
The above observation applies to both timed text tracks included
in a 3GP file and live streaming sessions. In the case of a 3GP
timed text track, the timestamp clockrate is the value of the
"timescale" parameter in the Media Header Box for that text
track. Each track in a 3GP file MAY have its own clockrate as
specified in the Media Header Box. Likewise, live streaming
applications SHALL use an appropriate timestamp clockrate. A
default value of 1000 Hz is RECOMMENDED. Other timestamp
clockrates MAY be used. In this case, the typical behavior here
is to match the 3GPP timed text clockrate to that used by an
associated audio or video stream.
In an aggregate payload, units MUST be placed in play-out order,
i.e., earliest first in the payload. If TYPE 1 units are
aggregated, the timestamp of the subsequent units MUST be
obtained by adding the timed text sample duration of previous
samples to the RTP timestamp value. There are two exceptions to
this rule: TYPE 5 units and an aggregate payload containing two
fragments of the same text sample. The details of the timestamp
calculation are given in Section 4.6.
Finally, timestamp clockrates MUST be signaled by out-of-band
means at session setup, e.g., using the media type "rate"
parameter in SDP. See Section 9 for details.
Payload Type (PT): The payload type is set dynamically and sent by
out-of-band means.
The usage of the remaining RTP header fields (namely, V, P, X, CC, SN
and SSRC) follows the rules of RTP and the profile in use.
4.1. Payload Header Definitions
The (transport) units specified in this document consist of a set of
common fields (U, R, TYPE, LEN), followed by specific header fields
(TYPES 1-5) and text sample contents. See Figure 1 and Figure 2.
In Figure 2, two example RTP packets are depicted. The first
contains an aggregate RTP payload with two complete text samples, and
the second contains one text sample fragment. After each unit header
is explained, detailed payload examples follow in Section 4.7.
+----------------------+
| |
| RTP Header |
| |
---------+----------------------+
| | |
| |COMMON + TYPE 1 Header|
| ........................
UNIT 1 - | |
| | Text Sample |
| | |
|-------\........................
-------/| |
| |COMMON + TYPE 1 Header|
| ........................
UNIT 2 - | |
| | Text Sample |
| | |
| | |
---------+----------------------+
+----------------------+
| |
| RTP Header |
| |
---------+----------------------+
| | COMMON + TYPE 2 |
| | (or 3 or 4) Hdr |
| ........................
UNIT 3 - | |
| | Text Sample Fragment |
| | |
| | |
---------+----------------------+
Figure 2. Example RTP packets
4.1.1. Common Payload Header Fields
The fields common to all payload headers have the following format:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Common payload header fields
Where:
o U (1 bit) "UTF Transformation flag": This is used to inform RTP
receivers whether UTF-8 (U=0) or UTF-16 (U=1) was used to encode
the text string. UTF-16 text strings transported by this payload
format MUST be serialized in big endian order, a.k.a. network byte
order.
Informative note: Timed text clients complying with the 3GPP
Timed Text format [1] are only required to understand the big
endian serialization. Thus, in order to ease interoperability,
the reverse serialization (little endian) is not supported by
this payload format.
For the payload formats defined in this document, the U bit is only
used in TYPE 1 and TYPE 2 headers. Senders MUST set the U bit to
zero in TYPE 3, TYPE 4, and TYPE 5 headers. Consequently,
receivers MUST ignore the U bit in TYPE 3, TYPE 4, and TYPE 5
headers.
o R (4 bits) "Reserved bits": for future extensions. This field MUST
be set to zero (0x0) and MUST be ignored by receivers.
o TYPE (3 bits) "Type Field": This field specifies which specific
header fields follow. The following TYPE values are defined:
- TYPE 1, for a whole text sample.
- TYPE 2, for a text string fragment (without modifiers).
- TYPE 3, for a whole modifier box or the first fragment of a
modifier box.
- TYPE 4, for a modifier fragment other than first.
- TYPE 5, for a sample description. Exactly one header per
sample description.
- TYPE 0, 6, and 7 are reserved for future extensions. Note
that future extensions are possible, e.g., a unit that
explicitly signals the number of characters present in a
fragment (see Section 2.5). In order to guarantee backwards-
compatibility, it SHALL be possible that older clients ignore
(newer) units they do not understand, without invalidating the
timestamp calculation mechanisms or otherwise preventing them
from decoding the other units.
o Finally, the LEN (16 bits) "Length Field": indicates the size (in
bytes) of this header field and all the fields following, i.e., the
LEN field followed by the unit payload: text strings and modifiers
(if any). This definition only excludes the initial U/R/TYPE byte
of the common header. The LEN field follows network byte order.
The way in which LEN is obtained when streaming out of a 3GP file
depends on the particular unit type. This is explained for each
unit in the sections below.
For live streaming, both sample length and the LEN value for the
current fragment MUST be calculated during the sampling process or
during fragmentation.
In general, LEN may take the following values:
- TYPE = 1, LEN >= 8
- TYPE = 2, LEN > 9
- TYPE = 3, LEN > 6
- TYPE = 4, LEN > 6
- TYPE = 5, LEN > 3
Receivers MUST discard units that do not comply with these values.
However, the RTP header fields and the rest of the units in the
payload (if any) are still useful, as guaranteed by the requirement
for future extensions above.
In the following subsections the different payload headers for the
values of TYPE are specified.
4.1.2. TYPE 1 Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| R |TYPE | LEN (always >=8) | SIDX |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDUR | TLEN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLEN |
+-+-+-+-+-+-+-+-+
Figure 4. TYPE 1 Header Format
This header type is used to transport whole text samples. This unit
should be the most common case, i.e., the text sample should usually
be small enough to be transported in one unit without having to
separate text strings from modifiers. In an aggregate (RTP packet)
payload containing several text samples, every sample is preceded by
its own TYPE 1 header (see Figure 12).
Informative note: As indicated in Section 3, "Terminology", a
text sample is composed of the text strings followed by the
modifiers (if any). This is also how text samples are stored in
3GP files. The separation of a text sample into text strings
and modifiers is only needed for large samples (or small
available IP MTU sizes; see Section 4.4), and it is accomplished
with TYPE 2 and TYPE 3 headers, as explained in the sections
below.
Note also that empty text samples are considered whole text samples,
although they do not contain sample contents. Empty text samples may
be used to clear the display or to put an end to samples of unknown
duration, for example. Units without sample contents SHALL have a
LEN field value of 8 (0x0008).
The fields above have the following meaning:
o U, R, and TYPE, as defined in Section 4.1.1.
o LEN, in this case, represents the length of the (complete) text
sample plus eight (8) bytes of headers. For finding the length of
the text sample in the Sample Size Box of 3GP files, see Section
4.3.
o SIDX (8 bits) "Text Sample Entry Index": This is an index used to
identify the sample descriptions.
The SIDX field is used to find the sample description corresponding
to the unit’s payload. There are two types of SIDX values: static
and dynamic.
Static SIDX values are used to identify sample descriptions that
MUST be sent out-of-band and MUST remain active during the whole
session. A static SIDX value is unequivocally linked to one
particular sample description during the whole session. Carrying
many sample descriptions out-of-band SHOULD be avoided, since these
may become large and, ultimately, transport is not the goal of the
out-of-band channel. Thus, this feature is RECOMMENDED for
transporting those sample descriptions that provide a set of
minimum default format settings. Static SIDX values MUST fall in
the (closed) interval [129,254].
Dynamic SIDX values are used for sample descriptions sent in-band.
Sample descriptions MAY be sent in-band for several reasons:
because they are generated in real time, for transport resiliency,
or both. A dynamic SIDX value is unequivocally linked to one
particular sample description during the period in which this is
active in the session, and it SHALL NOT be modified during that
period. This period MAY be smaller than or equal to the session
duration. This period is not known a priori. A maximum of 64
dynamic simultaneously active SIDX values is allowed at any moment.
Dynamic SIDX values MUST fall in the closed interval [0,127]. This
should be enough for both recorded content and live streaming
applications. Nevertheless, a wraparound mechanism is provided in
Section 4.2.1 to handle streaming sessions where more than 64 SIDX
values might be needed. Servers MAY make use of dynamic sample
descriptions. Clients MUST be able to receive and interpret
dynamic sample descriptions.
Finally, SIDX values 128 and 255 are reserved for future use.
o SDUR (24 bits) "Text Sample Duration": indicates the sample
duration in RTP timestamp units of the text sample. For this
field, a length of 3 bytes is preferred to 2 bytes. This is
because, for a typical clockrate of 1000 Hz, 16 bits would allow
for a maximum duration of just 65 seconds, which might be too short
for some streams. On the other hand, 24 bits at 1000 Hz allow for
a maximum duration of about 4.6 hours, while for 90 KHz, this value
is about 3 minutes. These values should be enough for streaming
applications. However, if a larger duration is needed, the
extension mechanism specified in Section 4.3 SHALL be used.
Apart from defining the time period during which the text is
displayed, the duration field is also used to find the timestamp of
subsequent units within the aggregate RTP packet payload (if any).
This is explained in Section 4.6.
Text samples have generally a known duration at the time of
transmission. However, in some cases such as live streaming, the
time for which a text piece shall be presented might not be known a
priori. Thus, the value zero SDUR=0 (0x000000) is reserved to
signal unknown duration. The amount of time that a sample of
unknown duration is presented is determined by the timestamp of the
next sample that shall be displayed at the receiver: Text samples
of unknown duration SHALL be displayed until the next text sample
becomes active, as indicated by its timestamp.
The next example illustrates how units of unknown duration MUST be