Request for Comments: 4396 Y. Matsui
Category: Standards Track Panasonic
February 2006
RTP Payload Format
for 3rd Generation Partnership Project (3GPP) Timed Text
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies an RTP payload format for the transmission of
3GPP (3rd Generation Partnership Project) timed text. 3GPP timed
text is a time-lined, decorated text media format with defined
storage in a 3GP file. Timed Text can be synchronized with
audio/video contents and used in applications such as captioning,
titling, and multimedia presentations. In the following sections,
the problems of streaming timed text are addressed, and a payload
format for streaming 3GPP timed text over RTP is specified.
Table of Contents
1. Introduction ....................................................3
2. Motivation, Requirements, and Design Rationale ..................3
2.1. Motivation .................................................3
2.2. Basic Components of the 3GPP Timed Text Media Format .......4
2.3. Requirements ...............................................5
2.4. Limitations ................................................6
2.5. Design Rationale ...........................................7
3. Terminology ....................................................10
4. RTP Payload Format for 3GPP Timed Text .........................12
4.1. Payload Header Definitions ................................13
4.1.1. Common Payload Header Fields .......................15
4.1.2. TYPE 1 Header ......................................17
4.1.3. TYPE 2 Header ......................................20
4.1.4. TYPE 3 Header ......................................23
4.1.5. TYPE 4 Header ......................................24
4.1.6. TYPE 5 Header ......................................25
4.2. Buffering of Sample Descriptions ..........................25
4.2.1. Dynamic SIDX Wraparound Mechanism ..................26
4.3. Finding Payload Header Values in 3GP Files ................28
4.4. Fragmentation of Timed Text Samples .......................31
4.5. Reassembling Text Samples at the Receiver .................33
4.6. On Aggregate Payloads .....................................35
4.7. Payload Examples ..........................................39
4.8. Relation to RFC 3640 ......................................43
4.9. Relation to RFC 2793 ......................................44
5. Resilient Transport ............................................45
6. Congestion Control .............................................46
7. Scene Description ..............................................47
7.1. Text Rendering Position and Composition ...................47
7.2. SMIL Usage ................................................48
7.3. Finding Layout Values in a 3GP File .......................48
8. 3GPP Timed Text Media Type .....................................49
9. SDP Usage ......................................................53
9.1. Mapping to SDP ............................................53
9.2. Parameter Usage in the SDP Offer/Answer Model .............53
9.2.1. Unicast Usage ......................................54
9.2.2. Multicast Usage ....................................57
9.3. Offer/Answer Examples .....................................58
9.4. Parameter Usage outside of Offer/Answer ...................60
10. IANA Considerations ...........................................60
11. Security Considerations .......................................60
12. References ....................................................61
12.1. Normative References .....................................61
12.2. Informative References ...................................61
13. Basics of the 3GP File Structure ..............................64
14. Acknowledgements ..............................................65
1. Introduction
3GPP timed text is a media format for time-lined, decorated text
specified in the 3GPP Technical Specification TS 26.245, "Transparent
end-to-end packet switched streaming service (PSS); Timed Text Format
(Release 6)" [1]. Besides plain text, the 3GPP timed text format
allows the creation of decorated text such as that for karaoke
applications, scrolling text for newscasts, or hyperlinked text.
These contents may or may not be synchronized with other media, such
as audio or video.
The purpose of this document is to provide a means to stream 3GPP
timed text contents using RTP [3]. This includes the streaming of
timed text being read out of a (3GP) file, as well as the streaming
of timed text generated in real-time, a.k.a. live streaming.
Section 2 contains the motivation for this document, an overview of
the media format, the requirements, and the design rationale.
Section 3 defines the terminology used. Section 4 specifies the
payload headers, the fragmentation and re-assembly rules for text
samples, the rules for payload aggregation, and the relations of this
document to RFC 3640 [12] and RFC 2793 [22]. Section 5 specifies
some simple schemes for resilient transport and gives pointers to
other possible mechanisms. Section 6 addresses congestion control.
Section 7 specifies scene description. Section 8 defines the media
type. Section 9 specifies SDP for unicast and multicast sessions,
including usage in the Offer/Answer model [13]. Sections 10 and 11
address IANA and security considerations. Section 12 lists
references. Basics of the 3GP File Structure are in Section 13.
2. Motivation, Requirements, and Design Rationale
2.1. Motivation
The 3GPP timed text format was developed for use in the services
specified in the 3GPP Transparent End-to-end Packet-switched
Streaming Services (3GPP PSS) specification [16].
As of today, PSS allows downloading 3GPP timed text contents stored
in 3GP files. However, due to the lack of a RTP payload format, it
is not possible to stream 3GPP timed text contents over RTP.
This document specifies such a payload format.
2.2. Basic Components of the 3GPP Timed Text Media Format
Before going into the details of the design, it is necessary to know
how the media format is constructed. We can identify four
differentiated functional components: layout information, default
formatting, text strings, and decoration. In the following, we
shortly explain these and match them to their designations in a 3GP
file:
o Initial spatial layout information related to the text
strings: These are the height and width of the text region
where text is displayed, the position of the text region in
the display, and the layer or proximity of the text to the
user. In 3GP files, this information is contained in the
Track Header Box (3GP file designations are capitalized for
clarity).
o Default settings for formatting and positioning of text: style
(font, size, color,...), background color, horizontal and
vertical justification, line width, scrolling, etc. For 3GP
files, this corresponds to the Sample Descriptions.
o The actual text strings: encoded characters using either UTF-8
[18] or UTF-16 [19] encoding.
o The decoration: If some characters have different style,
delay, blink, etc., this needs to be indicated. The
decoration is only present in the text samples if it is
actually needed. Otherwise, the default settings as above
apply. In 3GP files, within each Text Sample, the decoration
(i.e., Modifier Boxes) is appended to the text strings, if
needed. At the time of writing this payload format, the
following modifiers are specified in the 3GPP timed text media
format specification [1]:
- text highlight
- highlight color
- blinking text
- karaoke feature
- hyperlink
- text delay
- text style
- positioning of the text box
- text wrap indication
2.3. Requirements
Once the basic components are known, it is necessary to define which
requirements the payload format shall fulfill:
1. It shall enable both live streaming and streaming from a 3GP
file.
Informative note: For the purpose of this document, the
term "live streaming" refers to those scenarios where
the timed text stream is sent from a live encoder. Upon
reception, the content may or may not be stored in a 3GP
file. Typically, in live streaming applications, the
sender encapsulates the timed text content in RTP
packets following the guidelines given in this document.
At the receiving side, a buffer is used to cancel the
network delay and delay jitter. If receiver and sender
support packet loss resilience mechanisms (see Section
5), it may also be possible to recover from packet
losses. Note that how sender and receiver actually
manage and dimension the buffers is an implementation
design choice.
2. Furthermore, it shall be possible for an RTP receiver using this
payload format, and capable of storing in 3GP format, to obtain
all necessary information from the RTP packets for storing the
received text contents according to the 3GP file format. This
file may or may not be the same as the original file.
Informative note: The 3GP file format itself is based on
the ISO Base Media File Format recommendation [2].
Section 13.1 gives some insight into the 3GP file
structure. Further, Sections 4.3 and 7.3 specify where
the information needed for filling in payload headers is
found in a 3GP file. For live streaming, appropriate
values complying with the format and units described in
[1] shall be used. Where needed, clarifications on
appropriate values are given in this document.
3. It shall enable efficient and resilient transport of timed text
contents over RTP. In particular:
a. Enable the transmission of the sample descriptions by both
out-of-band and in-band means. Sample descriptions are
important information, which potentially apply to several
text samples. These default formatting settings are
typically transmitted out-of-band (reliably) once at the
initialization phase. If additional sample descriptions
are needed in the course of a session, these may also be
sent out-of-band or in-band. In-band transmission,
although unreliable, may be more appropriate for sending
sample descriptions if these should be sent frequently, as
opposed to establishing an additional communication channel
for SDP, for example. It is also useful in cases where an
out-of-band channel may not be available and for live
streaming, where contents are not known a priori. Thus,
the payload format shall enable out-of-band and in-band
transmission of sample descriptions. Section 4.1.6
specifies a payload header for transmitting sample
descriptions in-band. Section 9 specifies how sample
descriptions are mapped to SDP.
b. Enable the fragmentation of a text sample into several RTP
packets in order to cover a wide range of applications and
network environments. In general, fragmentation should be
a rare event, given the low bit rates and relatively small
text sample sizes. However, the 3GPP Timed Text media
format does allow for larger text samples. Therefore, the
payload format shall take this into account and provide a
means for coping with fragmentation and reassembly. Section
4.4 deals with fragmentation.
c. Enable the aggregation of units into an RTP packet for
making the transport more efficient. In a mobile
communication environment, a typical text sample size is
around 100-200 bytes. If the available bit rate and the
packet size allow it, units should be aggregated into one
RTP packet. Section 4.6 deals with aggregation.
d. Enable the use of resilient transport mechanisms, such as
repetition, retransmission [11], and FEC [7] (see Section
5). For a more general discussion, refer to RFC 2354 [8],
which discusses available mechanisms for stream repair.
2.4. Limitations
The payload headers have been optimized in size for RTP. Instead
of using 32-bit (S)LEN, SDUR, and SIDX header fields, which would
carry many unused bits much of the time, it has been a design
choice to reduce the size of these fields. As a consequence, this
payload format has reduced maximum values with respect to sizes and
durations of (text) samples and sample descriptions. These maximum
values differ from those allowed in 3GP files, where they are
expressed using 32-bit (unsigned) integers. In some cases,
extension mechanisms are provided to deal with larger values.
However, it is noted that the values used here should be enough for
the streaming applications targeted.
The following limitations apply:
1. The maximum size of text samples carried in RTP packets is
restricted to be a 16-bit (unsigned) integer (this includes the
text strings and modifiers). This means a maximum size for the
unit would be about 64 Kbytes. No extension mechanism is
provided.
2. The sample description index values are restricted to be an 8-
bit (unsigned) integer. An extension mechanism is given in
Section 4.3.
3. The text sample duration is restricted to be a 24-bit (unsigned)
integer. This yields a maximum duration at a timestamp
clockrate of 1000 Hz of about 4.6 hours. Nevertheless, an
extension mechanism is provided in Section 4.3.
4. Sample descriptions are also restricted in size: If the size
cannot be expressed as a 16-bit (unsigned) integer, the sample
description shall not be conveyed. As in the case of the sample
size, no extension mechanism is provided.
5. A further limitation concerns the UTF-16 encodings supported:
Only transport of text strings following big endian byte order
is supported. See Section 4.1.1 for details.
2.5. Design Rationale
The following design choices were made:
1. ’Unit’ approach: The payload formats specified in this document
follow a simple scheme: a 3-byte common header (Common Payload
Header) followed by a specific header for each text sample
(fragment) type. Following these headers, the text sample
contents are placed (Section 4.1.1 and following). This
structure is called a ’unit’.
The following units have been devised to comply with the
requirements mentioned in Section 2.3:
a. A TYPE 1 unit that contains one complete text sample,
b. A TYPE 2 unit that contains a complete text string or a
fragment thereof,
c. A TYPE 3 unit that contains the complete modifiers or only
the first fragment thereof,
d. A TYPE 4 unit that contains one modifier fragment other
than the first, and
e. A TYPE 5 unit that contains one sample description.
This ’unit’ approach was motivated by the following reasons:
1. Allows a simple classification of the text samples and
text sample fragments that can be conveyed by the
payload format.
2. Enables easy interoperability with RFC 3640 [12].
During the development of this payload format, interest
was shown from MPEG-4 standardization participants in
developing a common payload structure for the transport
of 3GPP Timed Text. While interoperability is not
strictly necessary for this payload format to work, it
has been pursued in this payload format. Section 4.8
explains how this is done.
2. Character count is not implemented. This payload format does
detect lost text samples fragments, but it does not enable an
RTP receiver to find out the exact number of text characters
lost. In fact, the fragment size included in the payload
headers does not help in finding the number of lost characters
because the UTF-8/UTF-16 [18][19] encodings used yield a
variable number of bytes per character.
For finding the exact number of lost characters, an additional
field reflecting the character count (and possibly the character
offset) upon fragmentation would be required. This would
additionally require that the entity performing fragmentation
count the characters included in each text fragment.
One benefit of having a character count would be that the
display application would be able to replace missing characters
through some other character representing character loss. For
example:
If we take the "Some text is lost now" and assume the loss
of a packet containing the text in the middle, this could
be displayed (with a character count):
"Some ############now"
As opposed to:
"Some #now"
which is what this payload format enables ("#" indicates a
missing character or packet, respectively).
However, it is the consensus of the working group that for
applications such as subtitling applications and multimedia
presentations that use this payload format, such partial error
correction is not worth the cost of including two additional
fields; namely, character count and character offset. Instead,
it is recommended that some more overhead be invested to provide
full error correction by protecting the less text sample
fragments using the measures outlined in Section 5.
3. Fragment re-assembly: In order to re-assemble the text samples,
offset information is needed. Instead of a character or byte
offset, a single byte, TOTAL/THIS, is used. These two values
indicate the total number and current index of fragments of a
text sample. This is simpler than having a character offset
field in each fragment. Details in Section 4.1.3.
4. A length field, LEN, is present in the common header fields.
While the length in the RTP payload format is not needed by most
RTP applications (typically lower layers, like UDP, provide this
information), it does ease interoperability with RFC 3640. This
is because the Access Units (AUs) used for carriage of data in
RFC 3640 must include a length indication. Details are in
Section 4.8.
5. The header fields in the specific payload headers (TYPE headers
in Sections 4.1.2 to 4.1.6) have been arranged for easy
processing on 32-bit machines. For this reason, the fields SIDX
and SDUR are swapped in TYPE 1 unit, compared to the other
units.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
Furthermore, the following terms are used and have specific meaning
within the context of this document:
text sample or whole text sample
In the 3GPP Timed Text media format [1], these terms refer to a
unit of timed text data as contained in the source (3GP) file.
This includes the text string byte count, possibly a Byte Order
Mark, the text string and any modifiers that may follow. Its
equivalent in audio/video would be a frame.
In this document, however, a text sample contains only text
strings followed by zero or more modifiers. This definition of
text sample excludes the 16-bit text string byte count and the
16-bit Byte Order Mark (BOM) present in 3GP file text samples
(see Section 4.3 and Figure 9). The 16-bit BOM is not
transported in RTP, as explained in Section 4.1.1.
text strings
The actual text characters encoded either as UTF-8 or UTF-16.
When using this payload format, the text string does not contain