ETSI TS 126 244 V10.0.0 (2011-04)
Technical Specification

Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS);
LTE;
Transparent end-to-end packet
switched streaming service (PSS);
3GPP file format (3GP)(3GPP TS 26.244 version 10.0.0 Release 10)

3GPP TS 26.244 version 10.0.0 Release 10

1

ETSI TS 126 244 V10.0.0 (2011-04)

Reference
RTS/TSGS-0426244va00

Keywords
GSM, LTE, UMTS

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing orperceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2011.
All rights reserved.
TM

TM

TM

TM

DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

2

ETSI TS 126 244 V10.0.0 (2011-04)

Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.

Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

3

ETSI TS 126 244 V10.0.0 (2011-04)

Contents
Intellectual Property Rights ................................................................................................................................2
Foreword.............................................................................................................................................................2
Foreword.............................................................................................................................................................5
Introduction ........................................................................................................................................................5
1

Scope ........................................................................................................................................................62

References ................................................................................................................................................63

Definitions and abbreviations ...................................................................................................................8

3.1
3.2

Definitions .......................................................................................................................................................... 8
Abbreviations ..................................................................................................................................................... 8

4

Overview ..................................................................................................................................................95

Conformance ............................................................................................................................................9

5.1
General ............................................................................................................................................................... 9
5.2
Definition ........................................................................................................................................................... 9
5.2.1
Limitations to the ISO base media file format .............................................................................................. 9
5.2.2
Registration of codecs ................................................................................................................................... 9
5.2.3
Extensions ..................................................................................................................................................... 9
5.2.4
MPEG-4 systems specific elements ............................................................................................................ 10
5.2.5
Template fields ........................................................................................................................................... 10
5.2.6
Interpretation of the 3GPP file format ........................................................................................................ 10
5.3
Identification .................................................................................................................................................... 10
5.3.1
General........................................................................................................................................................ 10
5.3.2
File extension .............................................................................................................................................. 10
5.3.3
MIME types ................................................................................................................................................ 10
5.3.4
Brands ......................................................................................................................................................... 10
5.4
Profiles ............................................................................................................................................................. 11
5.4.1
General........................................................................................................................................................ 11
5.4.2
General profile ............................................................................................................................................ 11
5.4.3
Basic profile ................................................................................................................................................ 11
5.4.4
Streaming-server profile ............................................................................................................................. 12
5.4.5
Progressive-download profile ..................................................................................................................... 12
5.4.6
Extended-presentation profile ..................................................................................................................... 13
5.4.7
Media Stream Recording profile ................................................................................................................. 13
5.4.8 File-delivery server profile ....................................................................................................................................... 13
5.4.9
Adaptive-Streaming profile ........................................................................................................................ 14
5.4.10Media Segment Profile ............................................................................................................................... 14
5.5
File-branding guidelines ................................................................................................................................... 14

6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10

7
7.1
7.2
7.2.1

Codec registration ..................................................................................................................................17
General ............................................................................................................................................................. 17
Sample Description box ................................................................................................................................... 17
MP4VisualSampleEntry box ............................................................................................................................ 18
MP4AudioSampleEntry box ............................................................................................................................ 19
AMRSampleEntry box ..................................................................................................................................... 20
H263SampleEntry box ..................................................................................................................................... 21
AMRSpecificBox field for AMRSampleEntry box ......................................................................................... 22
H263SpecificBox field for H263SampleEntry box .......................................................................................... 23
AMRWPSampleEntry box ............................................................................................................................... 25
AMRWPSpecificBox field for AMRWPSampleEntry box.............................................................................. 26

Streaming-server extensions...................................................................................................................26
General ............................................................................................................................................................. 26Groupings of alternative tracks ........................................................................................................................ 27
Alternate group ........................................................................................................................................... 27

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

7.2.2
7.3
7.4
7.5
7.5.1
7.5.2
7.5.3
7.6
7.7

8
8.1
8.2
8.3

9
9.1
9.2
9.2.1
9.2.2

4

ETSI TS 126 244 V10.0.0 (2011-04)

Switch group ............................................................................................................................................... 27
Track Selection box .......................................................................................................................................... 27
Combining alternative tracks ............................................................................................................................ 28
SDP .................................................................................................................................................................. 28
Session- and media-level SDP .................................................................................................................... 28
Stored versus generated SDP fields ............................................................................................................ 28
SDP attributes for alternatives .................................................................................................................... 30
SRTP ................................................................................................................................................................ 30
Aggregated RTP payloads ................................................................................................................................ 31

Asset information ...................................................................................................................................32
General ............................................................................................................................................................. 32
3GPP asset meta data ....................................................................................................................................... 32
ID3 version 2 meta data.................................................................................................................................... 37

Video buffer information........................................................................................................................38
General ............................................................................................................................................................. 38
Sample groupings for video-buffer parameters ................................................................................................ 39
3GPP PSS Annex G sample grouping ........................................................................................................ 39
AVC HRD sample grouping ....................................................................................................................... 40

10

Encryption ..............................................................................................................................................41

10.1
10.2
10.3

General ............................................................................................................................................................. 41
Sample entries for encrypted media tracks ....................................................................................................... 41
Key management .............................................................................................................................................. 42

11

Extended presentation format .................................................................................................................43

11.1
11.2
11.3
11.4
11.4.1
11.4.2

12
12.1
12.2
12.2.112.2.2
12.3

General ............................................................................................................................................................. 43
Storage format .................................................................................................................................................. 44
URL forms for items and tracks ....................................................................................................................... 44
Examples .......................................................................................................................................................... 44
SMIL presentation ...................................................................................................................................... 44
DIMS presentation ...................................................................................................................................... 45

Media Stream Recording ........................................................................................................................46
Unprotected Stream Recording ........................................................................................................................ 46
Protected Stream recording .............................................................................................................................. 46
Key message tracks ..................................................................................................................................... 46
Protection Description ................................................................................................................................ 46
SDP .................................................................................................................................................................. 46

13

HTTP streaming extensions ...................................................................................................................47

13.1
13.2
13.3
13.4
13.5

Introduction ...................................................................................................................................................... 47
Segment types .................................................................................................................................................. 47
Track Fragment Adjustment Box ..................................................................................................................... 47
Segment Index Box .......................................................................................................................................... 48
Track Fragment Decode Time Box .................................................................................................................. 49

Annex A (normative):

MIME Type Registrations for 3GP files ......................................................51

A.1

MIME Types ..........................................................................................................................................51

A.1.1
A.1.2
A.1.3
A.1.4

General ............................................................................................................................................................. 51
Files with audio but no visual content .............................................................................................................. 51
Any files ........................................................................................................................................................... 52
video/vnd.3gpp.segment ................................................................................................................................... 52

A.2

Optional parameters ...............................................................................................................................54

A.2.1
A.2.2
A.2.3

General ............................................................................................................................................................. 54
Codecs parameter ............................................................................................................................................. 54
Types parameter ............................................................................................................................................... 55

A.3

Security considerations...........................................................................................................................55

Annex B (informative):

Change history ...............................................................................................56

History ..............................................................................................................................................................57

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

5

ETSI TS 126 244 V10.0.0 (2011-04)

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
The 3GPP transparent end-to-end packet-switched streaming service (PSS) specification consists of six 3GPP TSs:
3GPP TS 22.233 [1], 3GPP TS 26.233 [2], 3GPP TS 26.234 [3], 3GPP TS 26.245 [4], 3GPP TS 26.246 [5] and thepresent document.
The TS 22.233 contains the service requirements for the PSS. The TS 26.233 provides an overview of the PSS. The TS
26.234 provides the details of protocol and codecs used by the PSS. The TS 26.245 defines the Timed text format usedby the PSS. The TS 26.246 defines the 3GPP SMIL language profile. The present document defines the 3GPP fileformat (3GP) used by the PPS and MMS services.
The TS 26.244 (present document), TS 26.245 and TS 26.246 started with Release 6. Earlier releases of the 3GPP fileformat, the Timed text format and the 3GPP SMIL language profile can be found in TS 26.234.

Introduction
A file format contains data in a structured way. The 3GPP file format can contain timing, structure and media data for
multimedia streams. It is used by MMS, PSS and MBMS for timed visual and aural multimedia.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

1

6

ETSI TS 126 244 V10.0.0 (2011-04)

Scope

The present document defines the 3GPP file format (3GP) as an instance of the ISO base media file format. The
definition addresses 3GPP specific features such as codec registration and conformance within the MMS, PSS and
MBMS services.

2

References

The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (includinga GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1]

3GPP TS 22.233: "Transparent End-to-End Packet-switched Streaming Service; Stage 1".

[2]

3GPP TS 26.233: "Transparent end-to-end packet switched streaming service (PSS); Generaldescription".

[3]

3GPP TS 26.234: "Transparent end-to-end packet switched streaming service (PSS); Protocols andcodecs".

[4]

3GPP TS 26.245: "Transparent end-to-end packet switched streaming service (PSS); Timed text
format".

[5]

3GPP TS 26.246: "Transparent end-to-end packet switched streaming service (PSS); 3GPP SMIL
Language Profile".

[6]

3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[7]

ISO/IEC 14496-12:2008 | 15444-12:2008: "Information technology – Coding of audio-visualobjects – Part 12: ISO base media file format" | "Information technology – JPEG 2000 image
coding system – Part 12: ISO base media file format".

[8]

3GPP TS 26.140: "Multimedia Messaging Service (MMS); Media formats and codecs".

[9]

ITU-T Recommendation H.263 (01/05): "Video coding for low bit rate communication".

[10]

ISO/IEC 14496-2:2004: "Information technology – Coding of audio-visual objects – Part 2:
Visual".

[11]

3GPP TS 26.071: "Mandatory Speech CODEC speech processing functions; AMR Speech
CODEC; General description".

[12]

3GPP TS 26.171: "AMR Wideband Speech Codec; General Description".

[13]

ISO/IEC 14496-3:2005: "Information technology – Coding of audio-visual objects – Part 3:
Audio".

[14]

ISO/IEC 14496-14:2003: "Information technology – Coding of audio-visual objects – Part 14:
MP4 file format".

[15]

IETF RFC 4867: " RTP Payload Format and File Storage Format for the Adaptive Multi-Rate(AMR) Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs", Sjoberg J. et al., April 2007.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

7

ETSI TS 126 244 V10.0.0 (2011-04)[16]

3GPP TS 26.101: "Mandatory Speech Codec speech processing functions; Adaptive Multi-Rate(AMR) speech codec frame structure".

[17]

3GPP TS 26.201: "Speech Codec speech processing functions; AMR Wideband Speech Codec;
Frame Structure".

[18]

void

[19]

IETF RFC 3711: "The Secure Real-time Transport Protocol", Baugher M. et al., March 2004.

[20]

ISO/IEC 14496-15: 2004: "Information technology – Coding of audio-visual objects – Part 15:
Advanced Video Coding (AVC) file format".

[21]

3GPP TS 26.290: "Extended AMR Wideband codec; Transcoding functions".

[22]

void

[23]

3GPP TS 26.401: "General audio codec audio processing functions; Enhanced aacPlus general
audio codec; General description".

[24]

3GPP TS 26.410: "General audio codec audio processing functions; Enhanced aacPlus general
audio codec; Floating-point ANSI-C code".

[25]

3GPP TS 26.411: "General audio codec audio processing functions; Enhanced aacPlus general
audio codec; Fixed-point ANSI-C code".

[26]

void

[27]

IETF RFC 3839: "MIME Type Registrations for 3rd Generation Partnership Project (3GPP)
Multimedia files", Castagno R. and Singer D., July 2004.

[28]

IETF RFC 4396: "RTP Payload Format for 3rd Generation Partnership Project (3GPP) Timed
Text", Rey J. and Matsui Y., February 2006.

[29]

ITU-T Recommendation H.264 (03/05): "Advanced video coding for generic audiovisual services"| ISO/IEC 14496-10:2005: "Information technology – Coding of audio-visual objects – Part 10:
Advanced Video Coding".

[30]

IETF RFC 3984: "RTP Payload Format for H.264 Video", Wenger S. et al, February 2005.

[31]

IETF RFC 4234: "Augmented BNF for Syntax Specifications: ABNF", Crocker D. and Overell P.,
October 2005.

[32]

MP4REG, MP4 Registration Authority, www.mp4ra.org.

[33]

ID3v2, http://www.id3.org/.

[34]

IETF RFC 4281: "The Codecs Parameter for ``Bucket´´ Media Types", Gellens R., Singer D. andFrojdh P., November 2005.

[35]

IETF RFC 4648: "The Base16, Base32, and Base64 Data Encodings", Josefsson S., October 2006.

[36]

3GPP TS 26.142: "Dynamic and Interactive Multimedia Scene".

[37]

Open Mobile Alliance: "DRM Specification 2.0".

[38]

ISO/IEC 14496-12:2008/PDAM1: "Part 12: ISO base media file format/AMENDMENT 1:
General improvements including hint tracks, metadata support, and sample groups".

[39]

3GPP TS 33.246: 'Security of Multimedia Broadcast/Multicast Service (MBMS)'.

[40]

3GPP TS 26.346: 'Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs'

[41]

Void

[42]

IETF RFC 4288: " Media Type Specifications and Registration Procedures", Freed N. and KlensinJ., December 2005.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

8

ETSI TS 126 244 V10.0.0 (2011-04)[43]

IETF RFC 5322: 'Internet Message Format', Resnick, P. October 2008.

[44]

IETF RFC 5234: 'Augmented BNF for Syntax Specifications: ABNF', Crocker D., Overell, P.,
January 2008

[45]

IETF RFC 2045: 'Multipurpose Internet Mail Extensions, (MIME) Part One: Format of Internet
Message Bodies', Freed, N., Borenstein, N., November 1996

[46]

IETF RFC 3926: "FLUTE - File Delivery over Unidirectional Transport", Paila T., Luby M.,
Lehtonen R., Roca V., and Walsh R., October 2004.

[47]

ISO/IEC 14496-15/Amd 1:2006: "Information technology – Coding of audio-visual objects – Part
15: Advanced Video Coding (AVC) file format – Amendment 1: Support of FRExt".

[48]

IETF RFC 2616: "Hypertext Transfer Protocol – HTTP/1.1", Fielding R. et al., June 1999.

3

Definitions and abbreviations

3.1

Definitions

For the purposes of the present document, the following terms and definitions apply:
continuous media: media with an inherent notion of time. In the present document speech, audio, video, timed text andDIMS
discrete media: media that itself does not contain an element of time. In the present document all media not defined ascontinuous media
PSS client: client for the 3GPP packet switched streaming service based on the IETF RTSP/SDP and/or HTTP
standards, with possible additional 3GPP requirements according to [3]PSS server: server for the 3GPP packet switched streaming service based on the IETF RTSP/SDP and/or HTTP
standards, with possible additional 3GPP requirements according to [3]3.2

Abbreviations

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [6] and the following apply.
3GP
3GPP file format
AAC
Advanced Audio Coding
AMR-WB+
Extended Adaptive Multi-Rate Wideband Codec
AVC
Advanced Video Coding
ADU
Application Data Unit
BIFS
Binary Format for Scenes
DIMS
Dynamic and Interactive Multimedia Scenes
Enhanced aacPlus MPEG-4 High Efficiency AAC plus MPEG-4 Parametric StereoFLUTE File Delivery overUnidirectional Transport
HTTP
HyperText Transport Protocol
ITU-TInternational Telecommunications Union – Telecommunications
MIKEY
Multimedia Internet KEYing
MIME
Multipurpose Internet Mail Extensions
MMS
Multimedia Messaging Service
MP4
MPEG-4 file format
MPDMedia Presentation Description
PSS
Packet-switched Streaming Service
RAP
Random Access Point
RTP
Real-time Transport Protocol
RTSP
Real-Time Streaming Protocol
SDP
Session Description Protocol
SRTP
Secure Real-time Transport Protocol

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

URL

4

9

ETSI TS 126 244 V10.0.0 (2011-04)

Uniform Resource Locator

Overview

The 3GPP file format (3GP) is defined in this specification as an instance of the ISO base media file format [7]. 3GP is
mandated in [8] to be used for continuous media along the entire delivery chain envisaged by the MMS, independent of
whether the final delivery is done by streaming or download, thus enhancing interoperability.
In particular, the following stages are considered:-

upload from the originating terminal to the MMS proxy;-

file exchange between MMS servers;-

transfer of the media content to the receiving terminal, either by file download or by streaming. In the first casethe self-contained file is transferred, whereas in the second case the content is extracted from the file andstreamed according to open payload formats. In this case, no trace of the file format remains in the content that
goes on the wire/in the air.

For the PSS, the 3GPP file format is mandated in [3] to be used for timed text and it should be supported by PSS
servers; 3GP files with streaming-server extensions should be used for storage in streaming servers and the "hint track"mechanism should be used for the preparation for streaming. For Adaptive HTTP Streaming, HTTP streaming
extensions are defined.

5

Conformance

5.1

GeneralThe 3GPP file format is structurally based on the ISO base media file format defined in [7]. However, the conformancestatement for 3GP files is defined here by addressing constraints and extensions to the ISO base media file format,
registration of codecs, file identification (file extension, brand identifier and MIME type) and profiles. If a 3GP filecontains codecs or functionalities not conforming to this specification they may be ignored, i.e. a 3GP compliant fileparser may ignore non-compliant boxes.

5.2

Definition

5.2.1

Limitations to the ISO base media file format

The following limitation to the ISO base media file format [7] shall apply to a 3GP file:-compact sample sizes ('stz2') shall not be used for tracks containing H.263, MPEG-4 video, AMR, AMR-WB,
AAC or Timed text.

NOTE:

5.2.2

The extended presentation format (see clause 11) is defined by using the Meta box of the ISO base media
file format [7] that was not present in the first edition. Hence, extended presentations in 3GP files are
explicitly signalled via the Extended-presentation profile (see clause 5.4.6).

Registration of codecs

Code streams for H.263 video [9], MPEG-4 video [10], H.264 (AVC) video [29], AMR narrow-band speech [11], AMR
wide-band speech [12], Extended AMR wide-band audio [21], Enhanced aacPlus audio [23, 24, 25], MPEG-4 AAC
audio [13], and timed text [4] can be included in 3GP files as described in clause 6 of the present document.

5.2.3

Extensions

The following extensions to the ISO base media file format [7] can be used in a 3GP file:ETSI

3GPP TS 26.244 version 10.0.0 Release 10

10

ETSI TS 126 244 V10.0.0 (2011-04)-

streaming-server extensions (see clause 7);-

asset information (see clause 8);-

video-buffer information (see clause 9);-

AVC file format (see [20] [47]);-

RTP and RTCP reception hint tracks (see [38]);-

SRTP and SRTCP reception hint tracks with key management information for SRTP recordings (see [38] andclause 12).

If SDP information is included in a 3GP file, it shall be used as defined by the streaming-server extensions.

5.2.4

MPEG-4 systems specific elements

For the storage of MPEG-4 media specific information in 3GP files, this specification refers to MP4 [14] and the AVC
file format [20] [47], which are also based on the ISO base media file format. However, tracks relative to MPEG-4
system architectural elements (e.g. BIFS scene description tracks or OD Object descriptors) are optional in 3GP files
and shall be ignored. The inclusion of MPEG-4 media does not imply the usage of MPEG-4 systems architecture.
Terminals and servers are not required to implement any of the specific MPEG-4 system architectural elements.

5.2.5

Template fields

The ISO base media file format [7] defines the concept of template fields that may be used by derived file formats. The
template field 'alternate group' can be used in 3GP files, as defined in clause 7.2. No other template fields are used.

5.2.6

Interpretation of the 3GPP file format

All index numbers used in the 3GPP file format start with the value one rather than zero, in particular 'first-chunk' in
Sample to chunk box, 'sample-number' in Sync sample box and 'shadowed-sample-number', 'sync-sample-number' inShadow sync sample box.

5.3

Identification

5.3.1

General

3GP files can be identified using several mechanisms: file extension, MIME types and brands.

5.3.2

File extension

When stored in traditional computer file systems, 3GP files should be given the file extension '.3gp'. Readers should
allow mixed case for the alphabetic characters.

5.3.3

MIME types

The MIME types 'video/3gpp' (for visual or audio/visual content, where visual includes both video and timed text) and'audio/3gpp' (for purely audio content) shall be used as defined in [27].

5.3.4

BrandsThis specification defines several brand identifiers corresponding to the profiles defined in clause 5.4. Brands areindicated in a file-type box, defined in [7], which shall be present in conforming files. The fields of the file-type box
shall be used as follows:-

Brand: Identifies the "best use" of the file and should match the file extension. For files with extension '.3gp'
and conforming to this specification, the brand shall be one of the profile brands defined in clause 5.4.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

11

ETSI TS 126 244 V10.0.0 (2011-04)-

MinorVersion: This identifies the minor version of the brand. For files with brand '3gLZ', where L is a letter
and Z a digit, and conforming to version Z.x.y of this specification, this field takes the value x*256 + y.

-CompatibleBrands: a list of brand identifiers (to the end of the box). Any profile of a 3GP file is declared byincluding the corresponding brand from clause 5.4 in this list.

The brand identifier (of one of the profiles) must occur in the compatible-brands list, and may also be the primarybrand. Conformance to more than one profile is indicated by listing the corresponding brands in the compatible-brands
list. If the file is also conformant to earlier releases of this specification, it is recommended that the corresponding
brands ('3gp4', '3gp5', '3gp6', '3gp7' and/or '3gp8') also occur in the compatible-brands list. If, for instance, '3gp4' is notin the compatible-brands list, then the file will not be processed by a Release 4 reader. Readers should check thecompatible-brands list for the identifiers they recognize, and not rely on the file having a particular primary brand, formaximum compatibility. Files may be compatible with more than one brand, and have a 'best use' other than thisspecification, yet still be compatible with this specification.

5.4

Profiles

5.4.1

GeneralAll 3GP files of this release shall conform to the general definitions in clauses 5.1-5.3. Additional profile-specificconstraints are listed below. A 3GP file must conform to at least one profile and may conform to several profiles.

5.4.2

General profile

The 3GP General profile is branded "3gg9" and is a superset of all other profiles. It is used to identify 3GP files
conformant to this specification, although they may not conform to any of the specific profiles listed below.
NOTE:

5.4.3

The General profile of 3GP has fewer restrictions than other profiles and is suitable for files not yet readyto be delivered by MMS or to be streamed by a PSS server. A General 3GP file may for instance containseveral alternative tracks of media. After extracting a suitable set of tracks the file may be ready for MMS
and can be re-profiled as a Basic file. Alternatively, by adding streaming-server extensions, it may be reprofiled as a Streaming-server profile.

Basic profile

The 3GP Basic profile is branded "3gp9".
The following constraints shall apply to a 3GP file conforming to Basic profile:-

there shall be no references to external media outside the file, i.e. a file shall be self-contained;-

the maximum number of tracks shall be one for video (or alternatively one for scene description), one for audio
and one for text;-

the maximum number of sample entries shall be one per track for video and audio (but unrestricted for text andscene description);-

there shall be no references between tracks, e.g., a scene description track shall not refer to a media track since
all tracks are on equal footing and played in parallel by a conforming player.

NOTE 1: The Basic profile of 3GP in Release 6 or higher corresponds to 3GP files of earlier releases, which did not
define profiles.
NOTE 2: In order to maintain backward compatibility with Release 4 and Release 5, it is not recommended to use
movie fragments in 3GP files for MMS.
NOTE 3: For H.264 (AVC) video in a Basic profile 3GP file, the restriction on the number of video tracks implies
in particular that there shall be no alternative tracks (including switching tracks) and no separate tracks
for parameter sets.
NOTE 4: For DIMS scene description in a Basic profile 3GP file, the restriction on the number of scene description
tracks implies in particular that there shall be no separate tracks for redundant DIMS units.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

12

ETSI TS 126 244 V10.0.0 (2011-04)

NOTE 5: The handler types for tracks with video, audio, text and scene description are "vide", "soun", "text", and"sdsm", respectively.

5.4.4

Streaming-server profile

The 3GP Streaming-server profile is branded "3gs9" and is used in PSS. Conformance to this profile will guarantee
interoperability between content creation tools and streaming servers, in particular for the selection of alternative
encodings of content and adaptation during streaming.
The following constraints shall apply to 3GP files conforming to Streaming-server profile:-

RTP hint tracks shall be included for all media tracks;-

RTP hint tracks shall comply with streaming as specified by PSS [3];-SDP information shall be included, as specified in clause 7.5, where SDP fragments shall be stored in the hint
tracks with media-level control URLs referring to (the same) hint tracks.

-

streaming-server extensions should be used for hint tracks, as defined in chapter 7.

The following requirements shall apply to servers conforming to this profile. A conforming server-

shall understand and respect directions given in the streaming-server extensions, as defined in chapter 7;-

should understand hint tracks;-

may override instructions in hint tracks.

NOTE 1: The instructions given in RTP hint tracks shall be consistent with the PSS. In particular, sending times of
RTP packets shall respect buffer constraints and be consistent with parameters used in SDP.
NOTE 2: Earlier releases of the 3GPP file format did not define streaming-server extensions or profiles. The usageof hint tracks was an internal implementation matter for servers outside the scope of the PSS
specification.

5.4.5

Progressive-download profile

The 3GP Progressive-download profile is branded "3gr9". It is used to label 3GP files that are suitable for progressive
download, i.e. a scenario where a file may be played during download (with some delay).
The following constraints shall apply to 3GP files conforming to Progressive-download profile:-the "moov" box shall be placed right after the "ftyp" box in the beginning of the file;-

all media tracks (if more than one) shall be interleaved with an interleaving depth of one second or less.

NOTE 1: This profile functions as an aid and not a requirement for progressive download, which has been an
inherent feature of the 3GPP file format since the first version in Release 4. By parsing a 3GP file, a client
can always determine whether a file can be progressively downloaded, and then calculate the interleaving
depth from the meta-data in the "moov" box.
NOTE 2: The "interleaving depth of one second or less" means that:- Each chunk contains one or more samples, with the total duration of the samples being either: nogreater than 1 second, or the duration of a single sample if that sample"s duration is greater than 1
second;- Within a track, chunks must be in decoding time order within the media-data box "mdat";- It is recommended that, in "mdat", regardless of media type, the chunks for all tracks are stored inascending order by decoding time. However, this order may be perturbed so that, when two chunks
from different tracks overlap in time, the chunk of one track (e.g. audio) is stored before the chunk of
the other track (e.g. video), even if the first sample in the second track has a slightly earlier
timestamp than the first sample in the first track.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

5.4.6

13

ETSI TS 126 244 V10.0.0 (2011-04)

Extended-presentation profile

The 3GP Extended-presentation profile is branded "3ge9". It enables a 3GP file to carry any kind of multimedia
presentation composed of tracks, media files and a scene description.
The following constraint shall apply to 3GP files conforming to Extended-presentation profile:-

there shall be an extended presentation as defined in clause 11.

The following requirement shall apply to a player conforming to this profile. A conforming player-

shall render the content of the 3GP file as prescribed by the contained scene description (primary item).

NOTE:

5.4.7

The scene description can address resources by using URLs as described in clause 11.3. In particular, it
can refer to media in tracks and items and also to scene description updates in scene description tracks.

Media Stream Recording profile

The 3GP Media Stream Recording Profile is branded "3gt9". It is used to label 3GP files that contain recordings ofmultimedia streams, e.g., from a PSS or an MBMS session.
The following constraints apply to 3GP files conforming to the Media Stream Recording Profile:- Non-protected media streams may be contained in RTP reception hint tracks or in media tracks or in both as
specified in [38]-

One RTCP hint track per media stream may be contained as specified in [38].

-Protected media data may be contained in SRTP reception hint tracks as specified in [38].

- Control information, i.e., SRTCP sender reports, necessary to render the protected media in SRTP reception hint
tracks shall be contained in one SRTCP reception hint track per SRTP reception hint tracks specified in [38].
- MIKEY MBMS Traffic Key messages [39] necessary to access the information stored in SRTP and SRTCP
reception hint tracks shall be contained in key message tracks as described in clause 12.2.
- Key management information necessary to render the content of the 3GP file shall be contained as described inclause 12.2, provided that at least one SRTP reception hint track is present.
-

SDP information shall be included as specified in clause 12.3.

The following requirements shall apply to 3GP players conforming to this profile. A conforming player:-

shall be able to reconstruct the received media stream from media tracks and RTP/RTCP hint tracks.

- shall be able to extract the unprotected content from the 3GP file, provided that the player has access to required
MBMS Service Keys or is able to obtain these using the methods specified in [39].

5.4.8 File-delivery server profile
The File-delivery server profile is branded "3gf9". Conformance to this profile will guarantee interoperability between
content creation tools and file delivery servers.
The following constraints shall apply to 3GP files conforming to File-delivery server profile:-

File Delivery Hint Tracks and File Delivery Format Extensions, as specified in [7], shall be used for files
intended for transmission over FLUTE [42].

The following requirements shall apply to servers conforming to this profile.
-

A conforming server shall understand and respect Filed Delivery Hint Tracks and File Delivery Format
Extensions, as specified in [7].

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

5.4.9

14

ETSI TS 126 244 V10.0.0 (2011-04)

Adaptive-Streaming profile

The 3GP Adaptive-Streaming profile is branded "3gh9". It is used to label 3GP files that are primarily suitable foradaptive file-based streaming.
The following constraints shall apply to 3GP files conforming to Adaptive-Streaming profile:•the "moov" box shall be placed in the beginning of the file right after the "ftyp" box and a possibly present"pdin" box;•

all movie data shall be contained in Movie Fragments, i.e. the tracks in the "moov" box shall not containany samples (i.e. the entry_count in the 'stts', 'stsc', and 'stco' boxes shall be set to 0).

•

the "moov" box shall contain an "mvex" box to indicate the presence of movie fragments.

•

the "moov" box shall be followed by one or more "moof" and optionally "mdat" box pairs.

•

each "moof" box shall contain at least one track fragment.

•

The "moof" boxes shall use movie-fragment relative addressing for media data that does not use external
data references and the flag "default-base-is-moof" shall also be set; absolute byte-offsets shall not be used
for this media data. In a movie fragment, the durations by which each track extends should be as close toequal as practical. In particular, as movie fragments are accumulated, the track durations should remainclose to each other and there should be no 'drift'.

•

For any track, any 'tfad' or any 'tfdt' box, if present, shall duplicate the operations of a possibly present 'elst'
box; when any 'tfad' or any 'tfdt' is used, the 'elst' box, if present, shall be ignored.

3GP files conforming to this profile may contain:•

segment ("styp") type boxes as specified in clause 13.2,•

track fragment adjustment ("tfad") boxes as specified in clause 13.3, and•segment index ("sidx") boxes as specified in clause 13.4,•

track fragment decode time ("tfdt") as specified in clause 13.5.

If the "meta" box is present and contains the Media Presentation Description (MPD as defined in TS 26.234 [3]) thenthe "meta" box shall be contained within the "moov" box. In this case the "meta" box shall contain a 'hdlr' box withhandler_type 'mpd ' followed by an 'xml ' box containing the MPD.
If the 'meta' box is present and contains a link to the MPD, then the 'meta' box shall be contained within the 'moov' box.
In this case the 'meta' box shall contain a 'hdlr' box with handler_type 'mpdl' followed by a 'dinf' box. The 'dinf' box
shall contain a 'dref' box with exactly one entry, which is a 'url ' box containing the URL of the MPD.

5.4.10Media Segment Profile

The 3GP Media Segment profile is branded "3gm9". It is used to label segments conforming to this release. Media
Segments are defined in clause 12.4.2.3 of TS 26.234 [3].

5.5File-branding guidelines

The file-type brands defined in this specification are used to label 3GP files belonging to this release and conforming to
one or more profiles. 3GP files may also conform to earlier Releases or even to other file formats, such as MP4, whichis also derived from the ISO base media file format [7].
Table 5.1 contains a non-exhaustive list of examples with 3GP files for various purposes. Note, however, that it only
gives typical or suggested uses. Both writers and readers of files should exercise care when using brand identifiers. It is
worth repeating the general guidelines here, remembering that a brand identifies a specification or a conformance point
in a specification; its presence in a file indicates both:-that the file conforms to the specification; it includes everything required by, and nothing contrary to thespecification (though there may be other material);ETSI

3GPP TS 26.244 version 10.0.0 Release 10-

15

ETSI TS 126 244 V10.0.0 (2011-04)

that a reader implementing that specification (possibly only that specification) is given permission to read andinterpret the file.

All 3GP files of Release 5 or later shall contain the compatible brand "isom" indicating that they conform to the ISObase media file format, unless the reader is required to interpret extensions specific to the AVC file format [20], forwhich case the compatible brand "avc1" shall be used instead (see note 2), or extensions specific to extended
presentations (see clause 11), for which case the compatible brand "iso2" shall be used (see note 3). The major brandshall be included in the compatible brands list as well. If a file contains more than one (3GPP) brand in the compatible
brands list, the major brand indicates the 'best use' of the file. For example, a Release-5 file with audio combined with
Timed text is best played by a Release-5 player, but may also be played by a Release-4 player that does not support
timed text.
NOTE 1: Since movie fragments are not allowed in Release 4 and Release 5, a fragmented 3GP file should notcontain "3gp4" or "3gp5" as brand or compatible brand. A player that does not support movie fragments
will only be able to play the first fragment of a fragmented file.
NOTE 2: Consider the brands "isom" and "avc1". The first indicates conformance to the base structure of the ISObase media file format [7]. The second, conformance to the AVC-specific extensions (structures such as
sample groups, for example) [20]. A file labelled as "isom" and "avc1" conformant is indicating thateither these extensions are not present, or if present, they can be ignored (as an "isom" reader will notunderstand them). If the writer desires that only readers supporting the extensions read a file, then the"isom" brand would be omitted. These extensions are all optional (i.e. none are required to be in a file,though if they are, an "avc1"-conformant reader must interpret them), and therefore a file not using themis still "avc1" conformant.
NOTE 3: The second version of the ISO base media file format defines the brand "iso2" that in addition to "isom"indicates conformance to extensions to the first version.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

16

ETSI TS 126 244 V10.0.0 (2011-04)

Table 5.1: Examples of brand usage in 3GP files
Conformance

SuffixBrand

Compatible brands

Example content

MMS and download: Files shall contain one or more of the brands 3gp4, 3gp5, 3gp6, 3gp7 and 3gp8. It is goodpractice to include compatible brands of earlier releases to enable legacy players to play the files.
Release 4
.3gp
3gp4
3gp4
H.263 and AMR
Release 5, 4
.3gp
3gp5
3gp5, 3gp4, isomH.263 and AMR
Release 6, 5, 4
.3gp
3gp6
3gp6, 3gp5, 3gp4, isomH.263 and AMR
Release 7, 6, 5, 4
.3gp
3gp7
3gp7, 3gp6, 3gp5, 3gp4, isomH.263 and AMR
Release 8, 7, 6, 5, 4
.3gp
3gp8
3gp8, 3gp7, 3gp6, 3gp5, 3gp4, H.263 and AMR
isom
Release 6, 5, 4
.3gp
3gp6
3gp6, 3gp5, 3gp4, isomH.263, AMR and Timed text
Release 6, 5
.3gp
3gp6
3gp6, 3gp5, isom
Timed text
Release 6.3gp
3gp6
3gp6, isom
H.264 (AVC) Baseline profile and
AMR
Release 6.3gp
3gp6
3gp6, isomfragmented H.263 and AMR
Release 7.3gp
3gp7
3gp7, isom
DIMS and AMR
Progressive download and MMS
Release 6, 5, 4
.3gp
3gr6
Release 6, 5, 4
.3gp
3gr6
Release 6
.3gp
3gr6

3gr6, 3gp6, 3gp5, 3gp4, isom
3gr6, 3gp6, 3gp5, 3gp4, isom
3gr6, 3gp6, isom

Release 6

3gr6, 3gp6, avc1

.3gp

3gr6

H.263
interleaved H.263 and AMR
fragmented and interleaved H.263 andAMRinterleaved H.264 (AVC) Baseline
profile and AMR

Streaming servers: Some files may in principle also be used for MMS or download.
Release 6.3gp
3gs6
3gs6, isom
AMR and hint track
Release 6.3gp
3gs6
3gs6, isom
2 tracks H.263 and 2 hint tracks
Release 6, 5, 4
.3gp
3gs6
3gs6, 3gp6, 3gp5, 3gp4, isomH.263, AMR and hint tracks
Extended presentations:
Release 7, 6
.3gp
Release 7
.3gp

3ge7
3ge7

3ge7, 3ge6, iso2
3ge7, iso2

SMIL, AMR and JPEG images
DIMS, AMR, H.264 (AVC) Baseline
profile and JPEG images

General purpose: Files that are not yet suitable for MMS, download or PSS streaming servers.
Release 6.3gp
3gg6
3gg6, isom
4 tracks H.263 (and no hint tracks)
Release 6.3gp
3gg6
3gg6, isom
2 tracks H.263, 3 tracks AMR
3GP file, also conforming to MP4
Release 4, 5 and MP4 .3gp
3gp5

3gp5, 3gp4, mp42, isom

MPEG-4 video

MP4 file, also conforming to 3GP
Release 5 and MP4
.mp4
mp42

mp42, 3gp5, isom

MPEG-4 video and AAC

Media Stream Recording fileRelease 8
.3gp

3gt8

3gt8, isom

Release 8

.3gp

3gt8

3gt8, isom

Release 9

.3gp

3gt9

3gt9, isom

SRTP reception hint and key message
tracksH.264 (AVC) Baseline profile andcorresponding RTP reception hint
track, reception hint track for AAC
H.264 (AVC) High Profile andcorresponding RTP reception hint
track, reception hint track for AAC

Adaptive HTTP
Streaming:
Release 9

.3gp

3gh9

3gp6, 3gp7, 3gp8, 3ge7, isom

ETSI

7 H.264 (AVC) tracks at different
bitrates in one alternate track group, 3
AAC tracks with different languages in
one alternate group, no hint tracks,
movie fragments

3GPP TS 26.244 version 10.0.0 Release 10

17

6

Codec registration

6.1

GeneralETSI TS 126 244 V10.0.0 (2011-04)

The purpose of this clause is to define the necessary structure for integration of the H.263, MPEG-4 Visual, AMR,
AMR-WB, Extended AMR-WB (AMR-WB+), Enhanced aacPlus and AAC media specific information in a 3GP file.
Clause 6.2 gives some background information about the Sample Description box in the ISO base media file format [7]and clauses 6.3 and 6.4 about the MP4VisualSampleEntry box and the MP4AudioSampleEntry box in the MPEG-4 fileformat [14]. The definitions of the Sample Entry boxes for AMR, AMR-WB, AMR-WB+ and H.263 are given inclauses 6.5 to 6.10. The integration of timed text in a 3GP file is specified in [4], the integration of H.264 (AVC) is
specified in [20] [47] and the integration of DIMS is specified in [36] and clauses 5.4.3, 5.4.6 and 11 of the present
document.
AMR and AMR-WB data is stored in the stream according to the AMR and AMR-WB storage format for single
channel header of Annex E [15], without the AMR magic numbers.
The 3GPP file format is the native storage format for AMR-WB+. The data stream, stored in samples of a 3GP file,shall be formatted according to clause 8.3 of [21]. Each sample contains one or more AMR-WB+ storage units. The
number of storage units per sample may differ from sample to sample.

6.2

Sample Description box

In an ISO file, Sample Description Box gives detailed information about the coding type used, and any initialisation
information needed for that coding. The Sample Description Box can be found in the ISO file format Box Structure
Hierarchy shown in figure 6.1.

Movie Box

Track BoxMedia BoxMedia Information Box

Sample Table Box

Sample Description Box

Figure 6.1: ISO File Format Box Structure Hierarchy

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

18

ETSI TS 126 244 V10.0.0 (2011-04)

The Sample Description Box can have one or more Sample Entries. Valid Sample Entries already defined for ISO andMP4 include MP4AudioSampleEntry, MP4VisualSampleEntry and HintSampleEntry. The Sample Entries for AMR
and AMR-WB shall be AMRSampleEntry, for AMR-WB+ it shall be AMRWPSampleEntry, for H.263 it shall be
H263SampleEntry, for H.264 (AVC) it shall be AVCSampleEntry, for timed text it shall be TextSampleEntry, for
DIMS it shall be DIMSSampleEntry, and for hint tracks it shall be HintSampleEntry.
The format of SampleEntry and its fields are explained as follows:
SampleEntry ::=MP4VisualSampleEntry |MP4AudioSampleEntry |AMRSampleEntry |AMRWPSampleEntry |H263SampleEntry |AVCSampleEntry |TextSampleEntry |DIMSSampleEntry |HintSampleEntry
Table 6.1: SampleEntry fields

Field
MP4VisualSampleEntry

Type

MP4AudioSampleEntry
AMRSampleEntry

AMRWPSampleEntry

H263SampleEntry

AVCSampleEntry

TextSampleEntry
DIMSSampleEntry

HintSampleEntry

Details
Entry type for visual samples definedin the MP4 specification.
Entry type for audio samples definedin the MP4 specification.
Entry type for AMR and AMR-WB
speech samples defined in clause 6.5of the present document.
Entry type for AMR-WB+ audio
samples defined in clause 6.9 of thepresent document.
Entry type for H.263 visual samples
defined in clause 6.6 of the present
document.
Entry type for H.264 (AVC) visualsamples defined in the AVC fileformat specification.
Entry type for timed text samples
defined in the timed text specification
Entry type for DIMS scene description
samples defined in the DIMS
specification.
Entry type for hint track samples
defined in the ISO specification.

Value

From the above 9 Sample Entries, only the MP4VisualSampleEntry, MP4AudioSampleEntry, H263SampleEntry,
AMRSampleEntry and AMRWPSampleEntry are taken into consideration here. TextSampleEntry is defined in [4],HintSampleEntry in [7], AVCSampleEntry in [20], and DIMSSampleEntry in [36].

6.3

MP4VisualSampleEntry box

The MP4VisualSampleEntry Box is defined as follows:
MP4VisualSampleEntry ::= BoxHeader
Reserved_6
Data-reference-index
Reserved_16
Width
HeightReserved_4
Reserved_4
Reserved_4
Reserved_2

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

19

ETSI TS 126 244 V10.0.0 (2011-04)

Reserved_32
Reserved_2
Reserved_2
ESDBox
Table 6.2: MP4VisualSampleEntry fields
Field
BoxHeader.Size
BoxHeader.Type
Reserved_6
Data-reference-index

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8) [6]Unsigned int(16)Reserved_16
WidthConst unsigned
int(32) [4]Unsigned int(16)HeightUnsigned int(16)Reserved_4

Const unsigned
int(32)
Const unsigned
int(32)
Const unsigned
int(32)
Const unsigned
int(16)
Const unsigned
int(8) [32]Const unsigned
int(16)
Const int(16)Reserved_4
Reserved_4
Reserved_2
Reserved_32
Reserved_2
Reserved_2
ESDBox

DetailsValue'mp4v'
0Index to a data reference that touse to retrieve the sample data.
Data references are stored in data
reference boxes.
0
Maximum width, in pixels of thestreamMaximum height, in pixels of thestream
0x00480000
0x00480000
0
1
0
24
-1
Box containing an elementarystream descriptor for this stream.

The stream type specific information is in the ESDBox structure, as defined in [14].
This version of the MP4VisualSampleEntry, with explicit width and height, shall be used for MPEG-4 video streams
conformant to this specification.
NOTE:

6.4

width and height parameters together may be used to allocate the necessary memory in the playback
device without need to analyse the video stream.

MP4AudioSampleEntry box

MP4AudioSampleEntryBox is defined as follows:
MP4AudioSampleEntry ::= BoxHeader
Reserved_6
Data-reference-index
Reserved_8
Reserved_2
Reserved_2
Reserved_4
TimeScale
Reserved_2
ESDBoxETSI

3GPP TS 26.244 version 10.0.0 Release 10

20

ETSI TS 126 244 V10.0.0 (2011-04)

Table 6.3: MP4AudioSampleEntry fields
Field
BoxHeader.Size
BoxHeader.Type
Reserved_6
Data-reference-index

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8) [6]Unsigned int(16)Reserved_8

Const unsigned
int(32) [2]Const unsigned
int(16)
Const unsigned
int(16)
Const unsigned
int(32)
Unsigned int(16)Const unsigned
int(16)

Reserved_2
Reserved_2
Reserved_4
TimeScale
Reserved_2
ESDBox

DetailsValue'mp4a'
0Index to a data reference that touse to retrieve the sample data.
Data references are stored in data
reference boxes.
02
160
Copied from track0
Box containing an elementarystream descriptor for this stream.

The stream type specific information is in the ESDBox structure, as defined in [14]. Enhanced aacPlus stored in .3GP
files shall not use implicit signalling (as defined in [13]).

6.5

AMRSampleEntry box

For narrow-band AMR, the box type of the AMRSampleEntry Box shall be 'samr'. For AMR wideband (AMR-WB),
the box type of the AMRSampleEntry Box shall be 'sawb'.
The AMRSampleEntry Box is defined as follows:
AMRSampleEntry ::=BoxHeader
Reserved_6
Data-reference-index
Reserved_8
Reserved_2
Reserved_2
Reserved_4
TimeScale
Reserved_2
AMRSpecificBox

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

21

ETSI TS 126 244 V10.0.0 (2011-04)

Table 6.4: AMRSampleEntry fields
Field
BoxHeader.Size
BoxHeader.Type
Reserved_6
Data-reference-index

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8) [6]Unsigned int(16)Reserved_8

Const unsigned
int(32) [2]Const unsigned
int(16)
Const unsigned
int(16)
Const unsigned
int(32)
Unsigned int(16)Reserved_2
Reserved_2
Reserved_4
TimeScale
Reserved_2

Details'samr' or "sawb"
0
Index to a data reference that touse to retrieve the sample data.
Data references are stored in data
reference boxes.
02
160
Copied from media header box ofthis media

Const unsigned
int(16)

AMRSpecificBox

Value

0
Information specific to the decoder.

If one compares the MP4AudioSampleEntry Box - AMRSampleEntry Box the main difference is in the replacement of
the ESDBox, which is specific to MPEG-4 systems, with a box suitable for AMR and AMR-WB. The
AMRSpecificBox field structure is described in clause 6.7.

6.6

H263SampleEntry box

The box type of the H263SampleEntry Box shall be 's263'.
The H263SampleEntry Box is defined as follows:
H263SampleEntry ::=BoxHeader
Reserved_6
Data-reference-index
Reserved_16
Width
HeightReserved_4
Reserved_4
Reserved_4
Reserved_2
Reserved_32
Reserved_2
Reserved_2
H263SpecificBox

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

22

ETSI TS 126 244 V10.0.0 (2011-04)

Table 6.5: H263SampleEntry fields
Field
BoxHeader.Size
BoxHeader.Type
Reserved_6
Data-reference-index

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8) [6]Unsigned int(16)Reserved_16
WidthConst unsigned
int(32) [4]Unsigned int(16)HeightUnsigned int(16)Reserved_4

Const unsigned
int(32)
Const unsigned
int(32)
Const unsigned
int(32)
Const unsigned
int(16)
Const unsigned
int(8) [32]Const unsigned
int(16)
Const int(16)Reserved_4
Reserved_4
Reserved_2
Reserved_32
Reserved_2
Reserved_2
H263SpecificBox

DetailsValue's263'
0Index to a data reference that touse to retrieve the sample data.
Data references are stored in data
reference boxes.
0
Maximum width, in pixels of thestreamMaximum height, in pixels of thestream
0x00480000
0x00480000
0
1
0
24
-1
Information specific to the H.263
decoder.

If one compares the MP4VisualSampleEntry – H263SampleEntry Box the main difference is in the replacement of the
ESDBox, which is specific to MPEG-4 systems, with a box suitable for H.263. The H263SpecificBox field structure forH.263 is described in clause 6.8.

6.7

AMRSpecificBox field for AMRSampleEntry box

The AMRSpecificBox fields for AMR and AMR-WB shall be as defined in table 6.6. The AMRSpecificBox for the
AMRSampleEntry Box shall always be included if the 3GP file contains AMR or AMR-WB media.
Table 6.6: The AMRSpecificBox fields for AMRSampleEntry
Field
BoxHeader.Size
BoxHeader.Type
DecSpecificInfo

Type
Unsigned int(32)Unsigned int(32)AMRDecSpecStruc

DetailsValue"damr"

Structure which holds the AMR
and AMR-WB Specific information

BoxHeader Size and Type: indicate the size and type of the AMR decoder-specific box. The type must be "damr".
DecSpecificInfo: the structure where the AMR and AMR-WB stream specific information resides.
The AMRDecSpecStruc is defined as follows:
struct AMRDecSpecStruc{
Unsigned int (32)
Unsigned int (8)Unsigned int (16)Unsigned int (8)Unsigned int (8)vendordecoder_version
mode_set
mode_change_period
frames_per_sample

}

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

23

ETSI TS 126 244 V10.0.0 (2011-04)

The definitions of AMRDecSpecStruc members are as follows:
vendor: four character code of the manufacturer of the codec, e.g. 'VXYZ'. The vendor field gives information about
the vendor whose codec is used to create the encoded data. It is an informative field, which may be used by the
decoding end. If a manufacturer already has a four-character code, it is recommended that it uses the same code in thisfield. Else, it is recommended that the manufacturer creates a four character code which best addresses the
manufacturer"s name. It can be safely ignored.
decoder_version: version of the vendor"s decoder which can decode the encoded stream in the best (i.e. optimal) way.
This field is closely tied to the vendor field. It may give advantage to the vendor which has optimal encoder-decoder
version pairs. The value is set to 0 if decoder version has no importance for the vendor. It can be safely ignored.
mode_set: the active codec modes. Each bit of the mode_set parameter corresponds to one mode. The bit index of themode is calculated according to the 4 bit FT field of the AMR or AMR-WB frame structure. The mode_set bit structure
is as follows: (B15xxxxxxB8B7xxxxxxB0) where B0 (Least Significant Bit) corresponds to Mode 0, and B8
corresponds to Mode 8.
The mapping of existing AMR modes to FT is given in table 1.a in [16]. A value of 0x81FF means all modes andcomfort noise frames are possibly present in an AMR stream.
The mapping of existing AMR-WB modes to FT is given in Table 1.a in TS 26.201 [17]. A value of 0x83FF means allmodes and comfort noise frames are possibly present in an AMR-WB stream.
As an example, if mode_set = 0000000110010101b, only Modes 0, 2, 4, 7 and 8 are present in the stream.
mode_change_period: defines a number N, which restricts the mode changes only at a multiple of N frames. If norestriction is applied, this value should be set to 0. If mode_change_period is not 0, the following restrictions apply to it
according to the frames_per_sample field:
if (mode_change_period < frames_per_sample)
frames_per_sample = k x (mode_change_period)
else if (mode_change_period > frames_per_sample)
mode_change_period = k x (frames_per_sample)
where k : integer [2, …]
If mode_change_period is equal to frames_per_sample, then the mode is the same for all frames inside one sample.
frames_per_sample: defines the number of frames to be considered as 'one sample' inside the 3GP file. This number
shall be greater than 0 and less than 16. A value of 1 means each frame is treated as one sample. A value of 10 meansthat 10 frames (of duration 20 msec each) are put together and treated as one sample. It must be noted that, in this case,one sample duration is 20 (msec/frame) x 10 (frame) = 200 msec. For the last sample of the stream, the number offrames can be smaller than frames_per_sample, if the number of remaining frames is smaller than frames_per_sample.
NOTE1: The "hinter", for the creation of the hint tracks, can use the information given by the AMRDecSpecStrucmembers.
NOTE2: The following AMR MIME parameters are not relevant to PSS: {mode_set, mode_change_period,
mode_change_neighbor}. PSS servers should not send these parameters in SDP, and PSS clients shall
ignore these parameters if received.

6.8

H263SpecificBox field for H263SampleEntry box

The H263SpecificBox fields for H. 263 shall be as defined in table 6.7. The H263SpecificBox for the
H263SampleEntry Box shall always be included if the 3GP file contains H.263 media.
The H263SpecificBox for H263 is composed of the following fields.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

24

ETSI TS 126 244 V10.0.0 (2011-04)

Table 6.7: The H263SpecificBox fields H263SampleEntry
Field
BoxHeader.Size
BoxHeader.Type
DecSpecificInfo

Type
Unsigned int(32)Unsigned int(32)H263DecSpecStruc

BitrateBox

DetailsValue"d263"

Structure which holds the H.263
Specific information
Specific bitrate information(optional)

BoxHeader Size and Type: indicate the size and type of the H.263 decoder-specific box. The type must be "d263".
DecSpecificInfo: This is the structure where the H263 stream specific information resides.
H263DecSpecStruc is defined as follows:
struct H263DecSpecStruc{
Unsigned int (32)
Unsigned int (8)Unsigned int (8)Unsigned int (8)vendordecoder_version
H263_Level
H263_Profile}
The definitions of H263DecSpecStruc members are as follows:
vendor: four character code of the manufacturer of the codec, e.g. 'VXYZ'. The vendor field gives information about
the vendor whose codec is used to create the encoded data. It is an informative field which may be used by the decoding
end. If a manufacturer already has a four-character code, it is recommended that it uses the same code in this field. Else,
it is recommended that the manufacturer creates a four character code which best addresses the manufacturer"s name. It
can be safely ignored.
decoder_version: version of the vendor"s decoder which can decode the encoded stream in the best (i.e. optimal) way.
This field is closely tied to the vendor field. It may give advantage to the vendor which has optimal encoder-decoder
version pairs. . The value is set to 0 if decoder version has no importance for the vendor. It can be safely ignored.
H263_Level and H263_Profile: These two parameters define which H263 profile and level is used. These parameters
are based on the MIME media type video/H263-2000. The profile and level specifications can be found in [9].
EXAMPLE 1:

H.263 Baseline = {H263_Level = 10, H263_Profile = 0}

EXAMPLE 2:

H.263 Profile 3 @ Level 10 = {H263_Level = 10 , H263_Profile = 3}

NOTE:

The "hinter", for the creation of the hint tracks, can use the information given by the H263DecSpecStrucmembers.

The BitrateBox field shall be as defined in table 6.8. The BitrateBox may be included if the 3GP file contains H.263
media.
The BitrateBox is composed of the following fields.
Table 6.8: The BitrateBox fields
Field
BoxHeader.Size
BoxHeader.Type
DecBitrateInfo

Type
Unsigned int(32)Unsigned int(32)DecBitrStruc

Details

Value"bitr"

Structure which holds the Bitrate
information

BoxHeader Size and Type: indicate the size and type of the bitrate box. The type must be "bitr".
DecBitrateInfo: This is the structure where the stream bitrate information resides.
DecBitrStruc is defined as follows:

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

25

ETSI TS 126 244 V10.0.0 (2011-04)

struct DecBitrStruc{
Unsigned int (32)
Unsigned int (32)

Avg_Bitrate
Max_Bitrate}
The definitions of DecBitrStruc members are as follows:
Avg_Bitrate: the average bitrate in bits per second of this elementary stream. For streams with variable bitrate thisvalue shall be set to zero.
Max_Bitrate: the maximum bitrate in bits per second of this elementary stream in any time window of one second
duration.

6.9

AMRWPSampleEntry box

The box type of the AMRWPSampleEntry Box shall be 'sawp'.
The AMRWPSampleEntry Box is defined as follows:
AMRWPSampleEntry ::= BoxHeader
Reserved_6
Data-reference-index
Reserved_8
Reserved_2
Reserved_2
Reserved_4
TimeScale
Reserved_2
AMRWPSpecificBox
Table 6.9: AMRWPSampleEntry fields
Field
BoxHeader.Size
BoxHeader.Type
Reserved_6
Data-reference-index

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8) [6]Unsigned int(16)Reserved_8

Const unsigned
int(32) [2]Const unsigned
int(16)
Const unsigned
int(16)
Const unsigned
int(32)
Unsigned int(16)Const unsigned
int(16)

Reserved_2
Reserved_2
Reserved_4
Sampling rate
Reserved_2
AMRWPSpecificBox

DetailsValue"sawp"
0Index to a data reference that touse to retrieve the sample data.
Data references are stored in data
reference boxes.
02
160
See note 3.
0
Information specific to the AMRWB+ decoder.

If one compares the MP4AudioSampleEntry Box - AMRWPSampleEntry Box the main difference is in the replacementof the ESDBox, which is specific to MPEG-4 systems, with a box suitable for AMR-WB+. The AMRWPSpecificBox
field structure is described in clause 6.10.
NOTE 1: In order to maintain backward compatibility with Release 4 and 5, the AMRWPSampleEntry should not
be used for AMR-WB+ streams that only contain AMR-WB modes. Such streams should be stored as
AMR-WB, i.e. by using the AMRSampleEntry with box type 'sawb', defined in clause 6.5, and thestorage format for single channel header of Annex E [15], without the AMR magic numbers. This way
file readers of previous releases will always be able to read AMR-WB streams stored in 3GP files.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

26

ETSI TS 126 244 V10.0.0 (2011-04)

NOTE 2: In order to enhance interoperability in Release 6, file readers capable of parsing tracks with AMR-WB+
should also be capable of parsing AMR-WB tracks (see note 1).
NOTE 3: The timescale of AMR-WB+ is fixed to 72kHz to accommodate the internal sampling rate which mayvary over time. The sampling rate field of the AMRWPSampleEntry is therefore not coupled to thetimescale, but contains the recommended playback sampling rate.

6.10

AMRWPSpecificBox field for AMRWPSampleEntry box

The AMRWPSpecificBox fields for AMR-WB+ shall be as defined in table 6.10. The AMRWPSpecificBox for the
AMRWPSampleEntry Box shall always be included if the 3GP file contains AMR-WB+ media.
Table 6.10: The AMRWPSpecificBox fields for AMRWPSampleEntry
Field
BoxHeader.Size
BoxHeader.Type
DecSpecificInfo

Type
Unsigned int(32)Unsigned int(32)AMRWPDecSpecStruc

Details

Value"dawp"

Structure which holds the AMRWB+ Specific information

BoxHeader Size and Type: indicate the size and type of the AMR-WB+ decoder-specific box. The type must be"dawp".
DecSpecificInfo: the structure where the AMR-WB+ stream specific information resides.
The AMRWPDecSpecStruc is defined as follows:
struct AMRWPDecSpecStruc{
Unsigned int (32)
Unsigned int (8)}vendordecoder_version

The definitions of AMRWPDecSpecStruc members are as follows:
vendor: four character code of the manufacturer of the codec, e.g. 'VXYZ'. The vendor field gives information about
the vendor whose codec is used to create the encoded data. It is an informative field, which may be used by the
decoding end. If a manufacturer already has a four-character code, it is recommended that it uses the same code in thisfield. Else, it is recommended that the manufacturer creates a four character code which best addresses the
manufacturer"s name. It can be safely ignored.
decoder_version: version of the vendor"s decoder which can decode the encoded stream in the best (i.e. optimal) way.
This field is closely tied to the vendor field. It may give advantage to the vendor which has optimal encoder-decoder
version pairs. The value is set to 0 if decoder version has no importance for the vendor. It can be safely ignored.
NOTE:

For AMR and AMR-WB the AMRSpecificBox defines the number of frames that are stored in a sample.
For AMR-WB+, however, the AMRWPSpecificBox does not specify an overall sample structure, as thenumber of storage units per sample may differ from sample to sample.

7

Streaming-server extensions

7.1

GeneralThis clause defines extensions to 3GP files to be used by streaming servers. The extensions enable a PSS server to relatedifferent tracks and use them for selection and adaptation. In particular, they enable a PSS server to-generate SDP descriptions with alternatives, as specified in subclauses 5.3.3.3 - 5.3.3.4 of [3];-select and combine tracks with alternative encodings of media before a presentation;ETSI

3GPP TS 26.244 version 10.0.0 Release 10

27

ETSI TS 126 244 V10.0.0 (2011-04)-

switch between tracks with alternative encodings during a streaming session;-

determine the decoding order, playout timestamp, and size for any ADU in an RTP payload.

In addition, the streaming server extensions enable a PSS server to-

use SRTP hint tracks for integrity protection.

The streaming-server extensions are intended to be used with hint tracks, although they are not limited to be used withhint tracks. Hint tracks are defined in the ISO base media file format [7] and provide (RTP) packetization instructions
for media stored in a file.
NOTE:

7.2

The present document defines syntax and semantics for streaming-server extensions in 3GP files. It does
not define protocols for, e.g., how a PSS server signals alternative encodings or switches between
different bitrate encodings. All protocols used by a PSS server are defined in [3].

Groupings of alternative tracks

By default all enabled tracks in a 3GP file are streamed (played) simultaneously. However, the ISO base media fileformat [7] specifies that tracks that are alternatives to each other can be grouped into an alternate group. Tracks in analternate group that can be used for switching can be further grouped into a switch group, as defined here.

7.2.1

Alternate group

Alternate group is identified by an integer, alternate_group, in the Track Header box of each track. If this integer is 0
(default value), there is no information on possible relations to other tracks. If this integer is not 0, it should be the samefor tracks that contain alternate data for one another and different for tracks belonging to different such groups. Only
one track within an alternate group should be streamed or played at any time and must be distinguishable from othertracks in the group via attributes such as bitrate, codec, language, packet size etc.

7.2.2

Switch group

Switch group is identified by an integer, switch_group, in the Track Selection box of each track, as defined below. If
this box is absent or if this integer is 0 (default value), there is no information on whether the track can be used forswitching during streaming or playing. If this integer is not 0, it shall be the same for tracks that can be used forswitching between each other. Tracks that belong to the same switch group shall belong to the same alternate group.

7.3

Track Selection box

This subclause defines an optional box that aids the selection between tracks. It is used to encode switch groups and thecriteria that should be used to differentiate tracks within alternate and switch groups.
The Track Selection box is defined in table 7.1. It is contained in the User data box of the track it modifies.
Note that Track Selection box is also defined in [7], with a slightly different set of defined attributes. One difference isthat herein the definition of the attribute "Language" identified by 'lang' is included; while in [7] the definition of theattribute "Media language" identified by 'mela' is included.
Table 7.1: Track Selection box fields
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
SwitchGroup
AttributeList

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)int(32)
Unsigned int(32) [N]Details

Switch group of track.
List of N attributes to the end of
the box.

Value"tsel"00
0 (default)

BoxHeader Size, Type, Version and Flags: indicate the size, type, version and flags of the Track Selection box. The
type shall be "tsel" and the version shall be 0. No flags are defined.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

28

ETSI TS 126 244 V10.0.0 (2011-04)

SwitchGroup: indicates switch group as defined in clause 7.2.2. It shall be 0 if the track is not intended for switching.
AttributeList: is a list of attributes to the end of the box. The attributes in this list should be used as differentiation
criteria for tracks in the same alternate or switch group. Each attribute is associated with a pointer to the field or
information that distinguishes the track. Attributes and pointers are listed in table 7.2.
Table 7.2: Attributes for AttributeList of the Track Selection box

7.4

Name
Language

Attribute"lang"

Bandwidth
Codec
Screen size

"bwas""cdec""scsz"Max packet size
Media type"mpsz""mtyp"

Pointer
Value of grouping type LANG of 'alt-group' attribute insession-level SDP (defined in clause 5.3.3.4 of [3])Value of 'b=AS' attribute in media-level SDP
SampleEntry (in Sample Description box of media track)
Width and height fields of MP4VisualSampleEntry and
H263SampleEntry (in media track)Maxpacketsize field in RTPHintSampleEntry
Handlertype in Handler box (of media track)

Combining alternative tracks

Tracks from different alternate groups are streamed (played) simultaneously. However, all combinations of tracks may
not form suitable presentations. In order to suggest suitable combinations of tracks and also to reduce the number ofpossible combinations, a content provider can encode preferred combinations of alternative tracks in a 3GP file. Suchcombinations are encoded by the 'alt-group' attribute in the session-level SDP fragment, as described in clause 7.5.3.
If information on suitable combinations of tracks is missing, tracks with the lowest track IDs of each alternate groupshould be streamed (played) by default.

7.5

SDP

7.5.1

Session- and media-level SDP

Fragments that together constitute an SDP description shall be contained in a 3GP file with streaming-server extensions.
Session-level SDP, i.e. all lines before the first media-specific line ('m=' line), shall be stored as Movie SDP information
within the User Data box, as specified in [7]. Media-level SDP, i.e. an 'm=' line and the lines before the next 'm=' line(or end of SDP) shall be stored as Track SDP information within the User data box of the corresponding track. Medialevel SDP shall be contained in hint tracks (if provided).

7.5.2

Stored versus generated SDP fields

The SDP information stored in a 3GP file should be as complete as possible, although some fields must be generated or
modified by the server when a presentation is composed. Table 7.3 gives an overview of the SDP fields used by PSS,
c.f. Table A.1 in [3], and whether they are required to be included in 3GP files or whether the server is required togenerate them.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

29

ETSI TS 126 244 V10.0.0 (2011-04)

Table 7.3: Overview of stored and generated fields in SDP
Type

Description

Contained in
3GP file

Session Description
V
Protocol version
O
Owner/creator and session identifierS
Session Name
I
Session informationU
URI of description
E
Email addressP
Phone number
C
Connection Information
B
BandwidthAS
information
RS
RR
TIAS
One or more Time Descriptions (See below)
Z
Time zone adjustments
K
Encryption key
A
Session attributes
controlrange
alt-group
QoE-Metrics
3GPP-Asset-Information
3GPP-Integrity-Key
3GPP-SDP-Authmaxprate
One or more Media Descriptions (See below)

Generated by
PSS server

R
O
R
O
O
O
O
O
O
O
O
O

O
R
O
O
O
O
O
R
O (see note 7)
O
O
O

O
O
O
R
R (see note 4)
O
O
N
N
O

O
O
R
O
O
O
O
R (see note 6)
R (see note 6)OTime Description
T
Time the session is active

R

O

R

O

O

R
O
O
R
O
O
R
O
O
R
R
R
R (see note 5)
R (see note 5)
R (see note 5)
R (see note 5)
R
N
N
N
O
O
N
N
R

O
O
R
O (see note 7)
R
R
O
O
R
O
O
O
O
O
O
O
O
R
R
O
O
O
R (see note 6)RO

Repeat times

Media Description
M
Media name and transport address
I
Media title
C
Connection information
B
BandwidthAS
information
RS
RR
TIAS
K
Encryption Key
A
Attribute Lines
controlrange
fmtp
rtpmapX-predecbufsize
X-initpredecbufperiod
X-initpostdecbufperiod
X-decbyterate
framesize
alt
alt-default-id
3GPP-Adaptation-Support
QoE-Metrics
3GPP-Asset-Information
3GPP-SRTP-Config
rtcp-fb
maxprateETSI

3GPP TS 26.244 version 10.0.0 Release 10

30

ETSI TS 126 244 V10.0.0 (2011-04)

Note 1: Fields in 3GP files are Required (R), Optional (O), or Not allowed (N).
Note 2: Servers are Required (R) to generate (possibly by copying or modifying from file), or have the
Option (O) to generate/copy/modify, or are Not allowed (N) to modify fields. If a field ispresent in a file, it shall be copied or modified, but not omitted, by the server.
Note 3: Some types shall only be included under certain conditions, as specified by PSS [3].
Note 4: The 'alt-group' attribute is required to be stored in 3GP files if it is used.
Note 5: The "X-" attributes are required to be stored in 3GP files if they are used. They may either be
specified in the PSS Annex G box '3gag' (see Clause 9) or in media-level SDP fragments.
Note 6: The server is required to generate the "3GPP-Integrity-Key", "3GPP-SDP-Auth", and "3GPPSRTP-Config" attributes if integrity protection is used.
Note 7: The "b=AS" session bandwidth shall include UDP/IP overhead. The value shall be based on
IPv4 when stored in a file, but may be modified by the server to accommodate for IPv6. The"maxprate" attribute is useful for such a conversion.

7.5.3

SDP attributes for alternatives

Clauses 5.3.3.3 and 5.3.3.4 of [3] define SDP attributes that a server can use for presenting options to a client. These
attributes can be used to encode suggested groupings of tracks, e.g. for selecting a certain language or target bitrate.
Suggested groupings of tracks from different alternate groups, i.e. groupings of tracks that should be streamed together,are encoded by using the 'alt-group' attribute in the session-level SDP. Note that a server may have to prune options
from such groupings if certain tracks are not presented to the client.
Media-level SDP fragments shall not contain alternative-media attributes ('alt' and 'alt-default-id') as they are difficult topre-encode. When the server combines several media-level SDP fragments from alternative tracks into one media-level
SDP, it must generate the appropriate 'alt' and 'alt-default-id' attributes. This can be done by using the information
provided in the 'alt-group' attributes in the session-level SDP.
NOTE 1: Track IDs given by the Track Header boxes shall be used for alternative IDs ('alt-id') in attributes for SDP
alternatives.
NOTE 2: Tracks with the lowest track IDs of each alternate group should be used as default tracks, i.e. used withthe 'alt-default-id' attributes.

7.6

SRTP

Hinted content may require the use of SRTP [19] for streaming, e.g. for integrity protection, by using the hint-trackformat for SRTP defined here. It consists of a dedicated sample entry, which will be ignored by 3GP servers not capableof handling SRTP.
SRTP hint tracks are formatted identically to RTP hint tracks defined in [7], except that:-the sample entry name is changed from 'rtp ' to 'srtp' to indicate to the server that SRTP is required;-an extra box is added to the sample entry which can be used to instruct the server in the nature of the on-the-fly
encryption and integrity protection that must be applied.

Samples of an SRTP hint track follow the same syntax for constructing RTP packets as RTP hint tracks.
An SRTP Hint Sample Entry ('srtp') shall include an SRTP Process Box ('srpp') that may instruct the server as to which
SRTP algorithms should be applied. It is defined in [7] and included in Table 7.4 for information.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

31

ETSI TS 126 244 V10.0.0 (2011-04)

Table 7.4: SRTPProcessBox
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
EncryptionAlgorithmRTP
EncryptionAlgorithmRTCP
IntegrityAlgorithmRTP
IntegrityAlgorithmRTCP
SchemeTypeBox

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)
Unsigned int(32)Unsigned int(32)Unsigned int(32)Unsigned int(32)DetailsValue"srpp"
00

4cc identifying the algorithm
4cc identifying the algorithm
4cc identifying the algorithm
4cc identifying the algorithm
Box containing the protection
scheme.
Box containing the scheme
information.

SchemeInformationBox

The SchemeTypeBox and SchemeInformationBox have the syntax defined in Tables 10.7 and 10.8, respectively.
They serve to provide the parameters required for applying SRTP. The Scheme Type Box is used to indicate thenecessary key management and security policy for the stream in extension to the defined algorithmic pointers provided
by the SRTP Process Box. The key management functionality is also used to establish all the necessary SRTP
parameters. The key management functionality is also used to establish all the necessary SRTP parameters as listed in
section 8.2 of [19]. The exact definition of protection schemes is out of the scope of the file format.
The algorithms for encryption and integrity protection are defined by SRTP. Table 7.5 summarizes the format
identifiers defined here. An entry of four spaces ($20$20$20$20) may be used to indicate that a process outside the fileformat decides the choice of algorithm for either encryption or integrity protection.
Table 7.5: Algorithms for encryption and integrity protection
Format$20$20$20$20
ACM1
AF81
ENUL
SHM2
ANUL

7.7

Algorithm
The choice of algorithm for either encryption or integrity protection is decided
by a process outside the file format
Encryption using AES in Counter Mode with 128-bit key, as defined in
Section 4.1.1 of [19]Encryption using AES in F8-mode with 128-bit key, as defined in Section
4.1.2 of [19]Encryption using the NULL-algorithm as defined in Section 4.1.3 of [19]Integrity protection using HMAC-SHA-1 with 160-bit key, as defined in
Section 4.2.1 of [19]Integrity protection not applied to RTP (but still applied to RTCP). Note: thisis valid only for IntegrityAlgorithmRTP.

Aggregated RTP payloads

An application data unit (ADU), normally being the smallest independently usable data unit, is specified as follows forcoding formats and RTP payload formats allowed in 3GP files:-

For audio and speech, an ADU is specified as a coded frame intended for transport.

-

For H.263 an ADU consists of an entire RTP payload.

-

For MPEG-4 Visual an ADU consists of a complete or partial VOP in the RTP payload.

-

For H.264 (AVC), an ADU is a Network Adaptation Layer Unit (NALU).

-

For timed text, an ADU consists of any of the type 1-5 RTP payload units [28].

For encrypted RTP payloads, the actual ADUs are hidden within the encrypted payload. Some RTP payload formats
allow aggregation of multiple ADUs into a single RTP payload. When any hint sample in an RTP hint track defines apayload including multiple ADUs, each hint sample in the hint track shall comply with the following requirements:-

The extra-flag in the RTPPacket class of the hint sample shall be set to 1. This indicates that there is extra
information before the RTP constructors in the form of type-length-value sets.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10-

32

ETSI TS 126 244 V10.0.0 (2011-04)

The extra information in the hint sample shall include a "3gau" structure as specified below.

class 3gppApplicationDataUnitInfoTLV extends Box("3gau") {unsigned int(16) entrycount;for(i=1; i<=entrycount; i++){unsigned int(32) numbytes;
unsigned int(64) decorder;
unsigned int(32) timestampoffset}}
entrycount indicates the number of ADUs in the RTP payload.
numbytes indicates the number of bytes of the i"th ADU in the RTP payload.
decorder indicates the decoding order of ADUs within the RTP hint track. The smaller value of decorder, the earlier the
ADU is in decoding order. All ADUs shall have a unique value of decorder, and the assignment shall be done using
consecutive numbers. If two or more ADUs can be decoded virtually simultaneously, i.e. their relative decoding order is
undefined, they shall still be assigned consecutive numbers.
timestampoffset indicates the RTP timestamp offset of the i"th ADU relative to the timestamp of RTP header of thepacket it will be transmitted in. Where the ADU's timestamp value is equal to what it would have had if it weretransmitted in an RTP packet containing only the ADU.

8

Asset information

8.1

GeneralAsset information in a 3GP file describes the contained media. Clause 8.2 defines 3GPP asset meta data that isbackward compatible with Release 6. However, in order to provide more enriched information for audio, it is also
possible to include ID3 version 2 (ID3v2) tags as described in clause 8.3.

8.2

3GPP asset meta data

A user-data box ('udta'), as defined in [7] may be present in conforming files. It should reside within the Movie box, but
may reside within the Track box, following the hierarchy of boxes described in Clause 6.2.
Within the user-data box, there may reside sub-boxes that contain asset meta-data, taken from the list of boxes in tables
8.1 through 8.10 below (zero or more sub-boxes of each kind, zero or one for each language or role of location
information). Each of the sub-boxes conforms to the definition of a "full box" as specified in [7] (hence the 'Version'and 'Flags' fields).
The following sub-boxes are in use for the following purposes:-

titl – title for the media (see table 8.1)-

dscp – caption or description for the media (see table 8.2)-

cprt – notice about organisation holding copyright for the media file (see table 8.3)-

perf – performer or artist (see table 8.4)-

auth – author of the media (see table 8.5)-

gnre – genre (category and style) of the media (see table 8.6)-

rtng – media rating (see table 8.7)-

clsf – classification of the media (see table 8.8)-

kywd – media keywords (see table 8.9)

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

33

ETSI TS 126 244 V10.0.0 (2011-04)-

loci – location information (see table 8.10)-

albm – album title and track number for the media (see table 8.11)-

yrrc – recording year for the media (see table 8.12)

Table 8.1: The Title box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
Title

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String

Details

Value'titl'
0
0
0

Packed ISO-639-2/T language code
Text of title

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
Title: null-terminated string in either UTF-8 or UTF-16 characters, giving a title information. If UTF-16 is used, thestring shall start with the BYTE ORDER MARK (0xFEFF).
Table 8.2: The Description box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
Description

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String

Details

Value'dscp'
0
0
0

Packed ISO-639-2/T language code
Text of description

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
Description: null-terminated string in either UTF-8 or UTF-16 characters, giving a description information. If UTF-16
is used, the string shall start with the BYTE ORDER MARK (0xFEFF).
Table 8.3: The Copyright box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
Copyright

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String

DetailsValue'cprt'
0
0
0

Packed ISO-639-2/T language code
Text of copyright notice

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
Copyright: null-terminated string in either UTF-8 or UTF-16 characters, giving a copyright information. If UTF-16 isused, the string shall start with the BYTE ORDER MARK (0xFEFF).

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

34

ETSI TS 126 244 V10.0.0 (2011-04)

Table 8.4: The Performer box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
Performer

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String

DetailsValue'perf'
0
0
0

Packed ISO-639-2/T language code
Text of performer

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
Performer: null-terminated string in either UTF-8 or UTF-16 characters, giving a performer information. If UTF-16 isused, the string shall start with the BYTE ORDER MARK (0xFEFF).
Table 8.5: The Author box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
AuthorType
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String

DetailsValue'auth'
0
0
0

Packed ISO-639-2/T language code
Text of author

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
Author: null-terminated string in either UTF-8 or UTF-16 characters, giving an author information. If UTF-16 is used,
the string shall start with the BYTE ORDER MARK (0xFEFF).
Table 8.6: The Genre box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
Genre

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String

DetailsValue'gnre'
0
0
0

Packed ISO-639-2/T language code
Text of genre

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
Genre: null-terminated string in either UTF-8 or UTF-16 characters, giving a genre information. If UTF-16 is used,
the string shall start with the BYTE ORDER MARK (0xFEFF).

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

35

ETSI TS 126 244 V10.0.0 (2011-04)

Table 8.7: The Rating box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
RatingEntity
RatingCriteria
Pad
Language
RatingInfo

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)
Unsigned int(32)Unsigned int(32)Bit(1)
Unsigned int(5)[3]String

Details

Value'rtng'
00

Four-character code rating entity
Four-character code rating criteria
0
Packed ISO-639-2/T language code
Text of media-rating information

RatingEntity: four-character code that indicates the rating entity grading the asset, e.g., 'BBFC'. The values of thisfield should follow common names of worldwide movie rating systems, such as those mentioned in[http://www.movie-ratings.net/, October 2002].
RatingCriteria: four-character code that indicates which rating criteria are being used for the corresponding rating
entity, e.g., "PG13".
Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
RatingInfo: null-terminated string in either UTF-8 or UTF-16 characters, giving a rating information. If UTF-16 isused, the string shall start with the BYTE ORDER MARK (0xFEFF).
Table 8.8: The Classification box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
ClassificationEntity

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)
Unsigned int(32)ClassificationTable
Pad
Language
ClassificationInfo

Unsigned int(16)Bit(1)
Unsigned int(5)[3]String

DetailsValue'clsf'
00

Four-character code classification
entityIndex to classification table
0
Packed ISO-639-2/T language code
Text of media-classification
information

ClassificationEntity: four-character code that indicates the classification entity classifying the asset. The values of thisfield should follow names of worldwide classification systems to be identified, but may be assigned blanks toindicate no specific classification entity.
ClassificationTable: binary code that indicates which classification table is being used for the correspondingclassification entity. 0x00 is reserved to indicate no specific classification table.
Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
ClassificationInfo: null-terminated string in either UTF-8 or UTF-16 characters, giving a classification information,
taken from the corresponding classification table, if specified. If UTF-16 is used, the string shall start with the
BYTE ORDER MARK (0xFEFF).

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

36

ETSI TS 126 244 V10.0.0 (2011-04)

Table 8.9: The Keywords box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
KeywordCnt
Keywords

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]Unsigned int(8)KeywordStruct[KeywordCnt]

DetailsValue'kywd'
0
0
0

Packed ISO-639-2/T language code
Binary number of keywords
Array of structures that hold theactual keywords (see Table 8.9.1)

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
KeywordCnt: binary code that indicates the number of keywords provided. This number shall be greater than 0.
Keywords: Array of structures that hold the actual keywords, according to table 8.9.1.
Table 8.9.1: The Keyword Struct
Field
KeywordSize
KeywordInfo

Type
Unsigned int(8)String

Details
Binary size of keyword
Text of keyword

Value

KeywordSize: binary code that indicates the total size (in bytes) of the keyword information field.
KeywordInfo: null-terminated string in either UTF-8 or UTF-16 characters, giving a keyword information. If UTF-16
is used, the string shall start with the BYTE ORDER MARK (0xFEFF).
Table 8.10: The Location Information box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
Name
Role

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String
Unsigned int(8)Longitude
Latitude
Altitude
Astronomical_body
Additional_notes

Unsigned int(32)Unsigned int(32)Unsigned int(32)StringString

DetailsValue'loci'
0
0
0

Packed ISO-639-2/T language code
Text of place nameNon-negative value indicating roleof location
Fixed-point value of the longitude
Fixed-point value of the latitude
Fixed-point value of the Altitude
Text of astronomical body
Text of additional location-related
information

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
Name: null-terminated string in either UTF-8 or UTF-16 characters, indicating the name of the place. If UTF-16 isused, the string shall start with the BYTE ORDER MARK (0xFEFF).
Role: indicates the role of the place. Value 0 indicates 'shooting location', 1 indicates 'real location', and 2 indicates'fictional location'. Other values are reserved.
Longitude: fixed-point 16.16 number indicating the longitude in degrees. Negative values represent western longitude.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

37

ETSI TS 126 244 V10.0.0 (2011-04)

Latitude: fixed-point 16.16 number indicating the latitude in degrees. Negative values represent southern latitude.
Altitude: fixed-point 16.16 number indicating the altitude in meters. The reference altitude, indicated by zero, is set tothe sea level.
Astronomical_body: null-terminated string in either UTF-8 or UTF-16 characters, indicating the astronomical body on
which the location exists, e.g. 'earth'. If UTF-16 is used, the string shall start with the BYTE ORDER MARK
(0xFEFF).
Additional_notes: null-terminated string in either UTF-8 or UTF-16 characters, containing any additional locationrelated information. If UTF-16 is used, the string shall start with the BYTE ORDER MARK (0xFEFF).
NOTE 1: If the location information refers to a time-variant location, 'Name' should express a high-level location,such as 'Finland' for several places in Finland or 'Finland-Sweden' for several places in Finland andSweden. Further details on time-variant locations can be provided as 'Additional notes'.
NOTE 2: The values of longitude, latitude and altitude provide cursory Global Positioning System (GPS)information of the media content.
NOTE 3: A value of longitude (latitude) that is less than –180 (-90) or greater than 180 (90) indicates that the GPS
coordinates (longitude, latitude, altitude) are unspecified, i.e. none of the given values for longitude,
latitude or altitude are valid.
Table 8.11: The Album box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
AlbumTitle
TrackNumber

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]String
Unsigned int(8)DetailsValue'albm'
0
0
0

Packed ISO-639-2/T language code
Text of album title
Optional integer with track number

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive.
AlbumTitle: null-terminated string in either UTF-8 or UTF-16 characters, giving an album information. If UTF-16 isused, the string shall start with the BYTE ORDER MARK (0xFEFF).
TrackNumber: the track number (order number) of the media on this album. This is an optional field.
Table 8.12: The Recording Year box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
RecordingYear

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)
Unsigned int(16)DetailsValue'yrrc'
00Integer value of recording year

RecordingYear: the year when the media was recorded.

8.3

ID3 version 2 meta data

ID3 version 2 meta-data can be stored in 3GP files by using the Meta box defined by the ISO base media file format [7].
The procedure is specified by MP4REG, the MP4 Registration Authority [32] and is provided here for information.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

38

ETSI TS 126 244 V10.0.0 (2011-04)

The ID3v2 meta data is stored in the Meta box ("meta"), which shall contain a Handler box with handler "ID32". The
actual meta data is either stored in one or more ID3v2 box(es) inside the meta-data box, or this entire set of box(es) is
referenced as the primary item, and stored elsewhere. The ID3v2 box is defined in Table 8.13.
Table 8.13: ID3v2 box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
Pad
Language
ID3v2data

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)Bit(1)
Unsigned int(5)[3]Unsigned int(8)[]DetailsValue'ID32'
0
0
0

Packed ISO-639-2/T language code
Complete ID3 version 2.x.x data

Language: declares the language code for the following text. See ISO 639-2/T for the set of three character codes.
Each character is packed as the difference between its ASCII value and 0x60. The code is confined to being three
lower-case letters, so these values are strictly positive. If there are some language fields inside ID3 tag, language
must not conflict with them. Instead codes 'mul' (multiple languages) and 'und' (undetermined language) should be
used in such cases.
ID3v2data: binary data that corresponds to ID3v2 tag format (e.g. for v.2.4.0: http://www.id3.org/id3v2.4.0structure.txt) and its native frames (e.g. for v.2.4.0: http://www.id3.org/id3v2.4.0-frames.txt). ID3 tag must notcontain any footer information, because it is never needed. Both ID3v2 tag format and its native frames must use
the same version of the specification. Size of this field can be derived from the box size. The version of the ID3
data may be found by inspecting it
The ID3v2 box contains a complete ID3 version 2.x.x data. It should be parsed according to ID3v2 [33] specifications
for v.2.x.x tags. There may be multiple ID3v2 boxes using different language codes.

9Video buffer information

9.1

General

A 3GP file can include video-buffer parameters associated with video streams. For the case when only one set ofparameters is associated to an entire video stream, these can be included in the corresponding media-level SDP
fragment. However, in order to provide buffer parameters for different operation points, as defined below, and for
different synchronization points, a track can contain a video buffer sample grouping. The type of sample grouping
depends on which video-buffer model that is used for a particular video codec.
For H.263 and MPEG-4 visual, the PSS buffering model, defined in Annex G of TS 26.234 [3] (PSS Annex G), is used.
Buffer parameters for several operation points and synchronization points may be specified by a 3GPP PSS Annex G
sample grouping as defined in clause 9.2.1.
For H.264 (AVC), there are two types of buffers:-

H.264 (AVC) Hypothetical Reference Decoder (HRD) model;-

de-interleaving buffer of the interleaved RTP packetization mode of H.264 (AVC).

Buffer parameters for several operation points and synchronization points of the HRD model may be specified by an
AVC HRD sample grouping as defined in clause 9.2.2. Only one set of de-interleaving parameters can be associated toa stream and therefore the de-interleaving parameters are included in the corresponding media-level SDP fragment
according to the H.264 (AVC) MIME/SDP specification in [30].
NOTE:

Any VUI HRD parameters, buffering period SEI message, and picture timing SEI message in H.264(AVC) streams or included in the sprop-parameter-sets MIME/SDP parameter of a media-level SDP
fragment must not contradict each other or the information in the AVC HRD sample grouping, if any.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

9.2

39

ETSI TS 126 244 V10.0.0 (2011-04)

Sample groupings for video-buffer parameters

A sample grouping is an assignment of each sample in a track to be a member of one (or none) of several sample
groups, based on a grouping criterion. The assignment of buffer parameters to synchronization points (sync samples)
provides one sample grouping of the samples in a track. The usage of sample groups in 3GP files shall follow the syntax
defined in [20].
Each sample is associated to zero or one sample group entries of any given grouping type in the sample group
description box ('sgpd'). Sample group entries for sample groups defined by the grouping type '3gag' are given by the
3GPP PSS Annex G Sample group entry, defined in Table 9.1, and sample group entries for sample groups defined by
the grouping type 'avcb' are given by the AVC HRD Sample group entry, defined in Table 9.2.
Sample group entries provide buffer parameters relevant to all samples in the corresponding sample group(s). A sync
sample and all following non-sync samples before the next sync sample shall be members of the same sample groupwith respect to the video-buffer grouping type. The indicated buffer parameters for a sync sample are applicable for the
stream from that sync sample onwards.
NOTE:

9.2.1

A file, in which some but not all samples are associated with sample groups with respect to the grouping
type '3gag' or 'avcb', may have been edited and may therefore no longer conform to corresponding buffer
model.

3GPP PSS Annex G sample grouping

The grouping type '3gag' defines the grouping criterion for 3GPP PSS Annex G buffer parameters. Zero or one sampleto-group box ('sbgp') for the grouping type '3gag' can be contained in the sample table box ('stbl') of a track. It shallreside in a hint track, if a hint track is used, otherwise in the video track. The presence of this box and grouping typeindicates that the associated video stream complies with PSS Annex G. Note that the nature of the track defines themedia transport for which the buffer parameters are calculated, e.g. for an RTP hint track, the media transport is RTP.
Table 9.1: 3GPP PSS Annex G sample group entry
Field
BufferParameters

Type
AnnexGstruc

Details
Structure which holds the buffer
parameters of PSS Annex G

Value

BufferParameters: the structure where the PSS Annex G buffer parameters reside.
AnnexGstruc is defined as follows:
struct AnnexGstruc{
Unsigned int(16)operation_point_countfor (i = 0; i < operation_point_count; i++){
Unsigned int (32)tx_byte_rate
Unsigned int (32)dec_byte_rate
Unsigned int (32)pre_dec_buf_size
Unsigned int (32)init_pre_dec_buf_period
Unsigned int (32)init_post_dec_buf_period}}
The definitions of the AnnexGstruc members are as follows:
operation_point_count: specifies the number of operation points, each characterized by a pair of transmission byte rateand decoding byte rate. Values of buffering parameters are specified separately for each operation point. The value of
operation_point_count shall be greater than 0.
tx_byte_rate: indicates the transmission byte rate (in bytes per second) that is used to calculate the transmission
timestamps of media-transport packets for the PSS Annex G buffering verifier as follows. Let t1 be the transmission
time of the previous media-transport packet and size1 be the number of bytes in the payload of the previous mediatransport packet in transmission order, excluding the media-transport payload header and any lower-layer headers. For
the first media-transport packet of the stream, t1 and size1 are equal to 0. The media track shall comply with PSS Annex
G when each sample is packetized in one media-transport packet, the transmission order of media-transport packets is

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

40

ETSI TS 126 244 V10.0.0 (2011-04)

the same as their decoding order, and the transmission time of an media-transport packet is equal to t1 + size1 /tx_byte_rate. The value of tx_byte_rate shall be greater than 0.
dec_byte_rate: indicates the peak decoding byte rate that was used in this operation point to verify the compatibility ofthe stream with PSS Annex G. Values are given in bytes per second. The value of dec_byte_rate shall be greater than 0.
pre_dec_buf_size: indicates the size of the PSS Annex G hypothetical pre-decoder buffer in bytes that guarantees
pauseless playback of the entire stream under the assumptions of PSS Annex G.
init_pre_dec_buf_period: indicates the required initial pre-decoder buffering period that guarantees pauselessplayback of the entire stream under the assumptions of PSS Annex G. Values are interpreted as clock ticks of a 90-kHz
block. That is, the value is incremented by one for each 1/90 000 seconds. For example, value 180 000 corresponds to a
two second initial pre-decoder buffering.
init_post_dec_buf_period: indicates the required initial post-decoder buffering period that guarantees pauselessplayback of the entire stream under the assumptions of PSS Annex G. Values are interpreted as clock ticks of a 90-kHz
clock.

9.2.2

AVC HRD sample grouping

The grouping type 'avcb' defines the grouping criterion for AVC HRD parameters. Zero or one sample-to-group box('sbgp') for the grouping type 'avcb' can be contained in the sample table box ('stbl') of a track. It shall reside either in ahint track or a video track. The presence of this box and grouping type indicates that the associated video stream
complies with AVC HRD with the indicated parameters.

Table 9.2: AVC HRD sample group entry
Field
AVCHRDParametersType
AVCHRDstruc

Details
Structure which holds the AVC HRD
parameters

Value

AVCHRDParameters: the structure where the AVC HRD parameters reside.
AVCHRDstruc is defined as follows:
struct AVCHRDstruc{
Unsigned int(16)operation_point_countfor (i = 0; i < operation_point_count; i++){
Unsigned int (32)tx_byte_rate
Unsigned int (32)pre_dec_buf_size
Unsigned int (32)post_dec_buf_size
Unsigned int (32)init_pre_dec_buf_period
Unsigned int (32)init_post_dec_buf_period}}
The definitions of the AVCHRDstruc members are as follows:
operation_point_count: specifies the number of operation points. Values of AVC HRD parameters are specified
separately for each operation point. The value of operation_point_count shall be greater than 0.
tx_byte_rate: indicates the input byte rate (in bytes per second) to the coded picture buffer (CPB) of AVC HRD. The
bitstream is constrained by the value of BitRate equal to 8 * the value of tx_byte_rate for NAL HRD parameters as
specified in [29]. For VCL HRD parameters, the value of BitRate is equal to tx_byte_rate * 40 / 6. The value of
tx_byte_rate shall be greater than 0.
pre_dec_buf_size: gives the required size of the pre-decoder buffer or coded picture buffer in bytes. The bitstream isconstrained by the value of CpbSize equal to pre_dec_buf_size * 8 for NAL HRD parameters as specified in [29]. For
VCL HRD parameters, the value of CpbSize is equal to pre_dec_buf_size * 40 / 6.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

41

ETSI TS 126 244 V10.0.0 (2011-04)

At least one pair of values of tx_byte_rate and pre_dec_buf_size of the same operation point shall conform to the
maximum bitrate and CPB size allowed by profile and level of the stream.
post_dec_buf_size: gives the required size of the post-decoder buffer, or the decoded picture buffer, in unit of bytes.
The bitstream is constrained by the value of max_dec_frame_buffering equal to Min( 16, Floor( post_dec_buf_size ) /( PicWidthMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ) ) ) as specified in [29]. If the SDP attribute 3gppvideopostdecbufsize is not present for an H.264 (AVC) stream, the value of max_dec_frame_buffering is inferred as
specified in [29].
init_pre_dec_buf_period: gives the required delay between the time of arrival in the pre-decoder buffer of the first bitof the first access unit and the time of removal from the pre-decoder buffer of the first access unit. It is in units of a 90
kHz clock. The bitstream is constrained by the value of the nominal removal time of the first access unit from the coded
picture buffer (CPB), tr,n( 0 ), equal to init_pre_dec_buf_period as specified in [29].
init_post_dec_buf_period: gives the required delay between the time of arrival in the post-decoder buffer of the first
decoded picture and the time of output from the post-decoder buffer of the first decoded picture. It is in units of a 90
kHz clock. The bitstream is constrained by the value of dpb_output_delay for the first decoded picture in output orderequal to init_post_dec_buf_period as specified in [29] assuming that the clock tick variable, tc, is equal to 1 / 90 000.

10

Encryption

10.1

General

A 3GP file may include encrypted media together with information on key management and requirements fordecrypting and/or serving encrypted media. Tracks containing encrypted media use dedicated sample entries forencrypted media, which will be ignored by 3GP readers not capable of handling encrypted media. 3GP readers capableof detecting encrypted media are able to obtain 'in the clear' the sample entries that apply to the decrypted media as well
as all requirements for decrypting the media. Moreover, 3GP readers supporting extended presentations (see clause 11)
referring to media files rather than media tracks are provided with all requirements for decrypting media files.
Clause 10.2 and 10.3 are provided here for information in the context of 3GP files. The definitions follow from [7].

10.2

Sample entries for encrypted media tracks

The sample entries stored in the sample description box of a media track in a 3GP file identify the format of theencoded media, i.e. codec and other coding parameters. All valid sample entries for unencrypted media in a 3GP file aredescribed in Clause 6. The principle behind storing encrypted media in a track is to 'disguise' the original sample entry
with a generic sample entry for encrypted media. Table 10.1 gives an overview of the formats (identifying sample
entries) that can be used in 3GP files for signalling encrypted video, audio and text.
Table 10.1: Formats for encrypted media tracks
Format'encv''enca''enct'

Original format's263', 'mp4v', 'avc1', …
'samr', 'sawb', 'sawp','mp4a', …
'tx3g', …

Media content
encrypted video: H.263, MPEG-4 visual, H.264(AVC), …
encrypted audio: AMR, AMR-WB, AMR-WB+, Enhanced
aacPlus, AAC, …
encrypted text: timed text, …

The generic sample entries for encrypted media replicate the original sample entries and include a Protection scheme
information box with details on the original format, as well as all requirements for decrypting the encoded media. The
EncryptedVideoSampleEntry and the EncryptedAudioSampleEntry are defined in Tables 10.2 and 10.3, where theProtectionSchemeInfoBox (defined in clause 10.2) is simply added to the list of boxes contained in a sample entry.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

42

ETSI TS 126 244 V10.0.0 (2011-04)

Table 10.2: EncryptedVideoSampleEntry
Field
BoxHeader.Size
BoxHeader.TypeType
Unsigned int(32)Unsigned int(32)DetailsValue"encv"All fields and boxes of a visual sample entry, e.g. MP4VisualSampleEntry or H263SampleEntry.
ProtectionSchemeInfoBox

Box with information on theoriginal format and encryption

Table 10.3: EncryptedAudioSampleEntry
Field
BoxHeader.Size
BoxHeader.TypeType
Unsigned int(32)Unsigned int(32)DetailsValue"enca"All fields and boxes in an audio sample entry, e.g. MP4AudioSampleEntry or AMRSampleEntry.
ProtectionSchemeInfoBox

Box with information on theoriginal format and encryption

The EncryptedVideoSampleEntry and the EncryptedAudioSampleEntry can also be used with any additional codecs
added to the 3GP file format, as long as their sample entries are based on the SampleEntry of the ISO base media fileformat [7].
The EncryptedTextSampleEntry is defined in Table 10.4. Text tracks are specific to 3GP files and defined by the Timedtext format [4]. In analogy with the cases for audio and video, a ProtectionSchemeInfoBox is added to the list ofcontained boxes.
Table 10.4: EncryptedTextSampleEntry
Field
BoxHeader.Size
BoxHeader.TypeType
Unsigned int(32)Unsigned int(32)Details

Value"enct"All fields and boxes of TextSampleEntry.
ProtectionSchemeInfoBox

NOTE:

10.3

Box with information on theoriginal format and encryption

The boxes within the sample entries defined in Tables 10.2-10.4 may not precede any of the fields. The
order of the boxes (including the ProtectionSchemeInfoBox) is not important though.

Key management

The necessary requirements for decrypting media are stored in the Protection scheme information box. For the case of
media tracks, it contains the Original format box, which identifies the codec of the decrypted media. For both media
tracks and media files, it contains the Scheme type box, which identifies the protection scheme used to protect themedia, and the Scheme information box, which contains scheme-specific data (defined for each scheme). It is out of thescope of this specification to define a protection scheme.
The Protection scheme information box and its contained boxes are defined in Tables 10.5 – 10.8.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

43

ETSI TS 126 244 V10.0.0 (2011-04)

Table 10.5: ProtectionSchemeInfoBox
Field
BoxHeader.Size
BoxHeader.Type
OriginalFormatBox

Type
Unsigned int(32)Unsigned int(32)DetailsValue"sinf"

Box containing identifying theoriginal format
Optional box containing theprotection scheme.
Optional box containing thescheme information.

SchemeTypeBox
SchemeInformationBox

Table 10.6: OriginalFormatBox
Field
BoxHeader.Size
BoxHeader.Type
DataFormat

Type
Unsigned int(32)Unsigned int(32)Unsigned int(32)DetailsValue"frma"

original format

DataFormat identifies the format (sample entry) of the decrypted, encoded data. The currently defined formats in 3GP
files include 'mp4v', 'h263', 'avc1', 'mp4a', 'samr', 'sawb', 'sawp' and 'tx3g'.
Table 10.7: SchemeTypeBox
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
BoxHeader.Flags
SchemeType

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Bit(24)
Unsigned int(32)SchemeVersion
SchemeURI

Unsigned int(32)Unsigned int(8)[ ]DetailsValue"schm"
00 or 1four-character code identifying
the scheme
Version number
Browser URI (null-terminated
UTF-8 string). Present if(Flags & 1) true

SchemeType and SchemeVersion identifiy the encryption scheme and its version. As an option, it is possible toinclude SchemeURI with an URI pointing to a web page for users that don"t have the encryption scheme installed.
Table 10.8: SchemeInformationBox
Field
BoxHeader.Size
BoxHeader.TypeType
Unsigned int(32)Unsigned int(32)DetailsValue"schi"

Box(es) specific to scheme
identified by SchemeType

The boxes contained in the Scheme information box are defined by the scheme type, which is out of the scope of thisspecification to define.

11

Extended presentation format

11.1

General

A 3GP file may include an extended presentation that consists of media files in addition to tracks for audio, video andtext. Examples of such media files are static images, e.g. JPEG files, which can be stored in a 3GP 'container file'. A
3GP container file that includes an extended presentation must include a scene description that governs the rendering of
all parts of the 3GP file.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

11.2

44

ETSI TS 126 244 V10.0.0 (2011-04)

Storage format

A 3GP file with an extended presentation shall include a Meta box ("meta") at the top level of the file as defined in [7].
The Meta box shall include the following boxes:-

Handler box with handler type "3gsd" (3GPP scene description);-

Primary item box or XML box identifying the scene description;-

Item information box;-

Item location box (see below).

A scene description (e.g. an SVG scene, in the case of DIMS, or a SMIL file) shall be included either in an XML box oras an item located by the Item location box. The scene description may refer to both tracks and media files (items).
A 3GP file that contains media files and/or a scene description not stored in an XML box shall include an Item location
box locating all contained files and the scene description. Each item corresponding to a media file of the Item location
box shall also be included in the Item information box in order to specify its filename (item name) and MIME type. The
Item information box shall also include an entry for the scene description that specifies its MIME type. By referring to a
Protection scheme information box in the Item protection box, the Item information box can also indicate whether thecontent of an item is protected (encrypted) as defined in [7] and discussed in clause 10 of the present specification.

11.3

URL forms for items and tracks

All media files and the scene description included in a 3GP file are logically located in the same directory as the 3GP
file itself. In general, the Meta box of a 3GP file serve as a container of files that logically 'shadow' files outside the3GP file. See the description of URL forms for Meta boxes in [7] for further details. The Movie box ("moov") of a 3GP
file contains all media tracks and possible scene description update tracks.
The scene description (primary item) of a 3GP file addresses other resources by using relative URLs. In particular it
addresses-

media files (items) by referring to their filenames;-

media tracks by referring to the Movie box with the relative URL "#box=moov".

The default is to address all tracks of the Movie box. However, it is possible to address individual media tracks in theMovie box by referring to their track IDs. The relative URL of a track is defined in terms of ABNF [31] as follows:
relative-track-URL = "#box=moov;track_ID=" track-number* ("," track-number)track-number= 1*digit

Hence, individual tracks are referenced by listing their numbers, e.g. "#box=moov;track_ID=1,3".
A DIMS (SVG) scene description (primary item) can also address scene updates in a track using the above URL forms.
For instance, applying updates to the scene description stored in track 1 after 10 seconds is done as follows:<updates xlink:href="#box=moov;track_ID=1" begin="10"/>Note:

It is possible to include a 3GP file with tracks as a media file (addressed by filename) rather than using a
top-level Movie box for tracks. However, this way the included 3GP file will be 'hidden' one layer andinterleaving between individual tracks and items less transparent.

11.4

Examples11.4.1SMIL presentation

The following example consists of a slide show in SMIL consisting of three images shown with the duration of 3
seconds each and an AMR clip that is played in parallel. The presentation is built from a number of separate files:ETSI

3GPP TS 26.244 version 10.0.0 Release 10-

SMIL file: "scene.smil";-

3GP file with AMR: "audioclip.3gp";-

Image files: "pic1.jpg", "pic2.jpg" and "pic3.jpg".

45

ETSI TS 126 244 V10.0.0 (2011-04)

These files can be packaged into a single 3GP file "presentation.3gp" as an extended presentation. The overall
presentation is governed by the SMIL file located as the primary item of "presentation.3gp":<smil xmlns="http://www.w3.org/2001/SMIL20/Language"><head><layout><root-layout width="176" height="144"/><region id="pics" left="0" width="176" height="144"/></layout></head><body><par><audio src="#box=moov" dur="9s"/><seq><img region="pics" src="pic1.jpg" dur="3s"/><img region="pics" src="pic2.jpg" dur="3s"/><img region="pics" src="pic3.jpg" dur="3s"/></seq></par></body></smil>The audio track resides in the Movie box and is referred to as "#box=moov", whereas the images are included as media
files in the Meta box.

11.4.2

DIMS presentation

The following example consists of a DIMS presentation that refers to images, an AMR clip and scene updates. The
presentation is contained in a single Extended-presentation profile 3GP file containing:-

DIMS scene description (SVG scene) stored as item 1 identified by a Primary item box;-

DIMS updates stored as a DIMS track (track ID 1);-

AMR clip stored as an AMR track (track ID 2);-

Image files: "pic1.jpg", "pic2.jpg" and "pic3.jpg" stored as items 2, 3 and 4.

All references to the DIMS and AMR tracks and the images are made by relative URLs from the DIMS Unit in the
primary item:<svg xmlns="http://www.w3.org/2000/svg" version="1.2" baseProfile="tiny"
xmlns:xlink=http://www.w3.org/1999/xlink
width="320" height="240" viewBox="0 0 320 240"><desc>DIMS example</desc><updates xlink:href="#box=moov;track_ID=1" begin="10"/><audio xlink:href="#box=moov;track_ID=2" audio-level="0.7"
type="audio/AMR" begin="10"/><image x="0" y="0" width="100" height="100" xlink:href="pic1.jpg"><image x="0" y="100" width="100" height="100" xlink:href="pic2.jpg"><image x="100" y="0" width="100" height="100" xlink:href="pic3.jpg"></svg>An Item information box specifies the MIME type of the scene description (SVG scene) and the filenames and MIME
types of the image files. An Item location box specifies the locations of all items.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

46

ETSI TS 126 244 V10.0.0 (2011-04)

12

Media Stream Recording

12.1

Unprotected Stream Recording

Received RTP media streams may be stored in 3GP files conforming to the Media Stream Recording profile. RTP
packets may be stored in RTP reception hint tracks. RTCP packets may be stored in RTCP reception hint tracks.

12.2

Protected Stream recording

SRTP protected media may be stored in 3GP files conforming to the 3GP Media Stream Recording Profile. SRTP andcorresponding SRTCP packets are stored in SRTP reception hint tracks and SRTCP reception hint tracks, respectively,
as described in [38]. Corresponding MIKEY MBMS Traffic Key messages are stored in OMA BCAST STKM tracks as
described in clause 12.2.1. Additionally, SDP and Protection Description information is stored as described in clauses
12.3 and 12.2.2.

12.2.1

Key message tracks

MIKEY MBMS Traffic Key messages as defined in [39] shall be stored in OMA BCAST STKM tracks "oksd" as
defined in [37]. A 3GP file with SRTP recording extensions shall contain at least one STKM track. Furthermore, all key
messages related a specific SRTP reception hint track shall be recorded in the same STKM track. Track references oftype "cdsc" shall be used to link STKM tracks to SRTP reception hint tracks as described in [37].
In the Sample Description Entry of the STKM track, the filed sample_version shall be set to 0x00 and the fieldsample_type shall be set to 0xf7. The value 0xf7 indicates MIKEY MBMS Traffic Key messages.
Each Sample Entry of a STKM track shall contain exactly one MIKEY MBMS Traffic Key messages in the STKM
field. That is, the STKM field shall contain the payload of the received MIKEY package (without IP and UDP headers)
including all MIKEY headers and all MIKEY payloads and the MIKEY MAC/Signature field.

12.2.2

Protection Description

The ServiceProtectionDescription box shall be defined as stated in table 12.1. The ServiceProtectionDescription box
shall be included for each Sample Description Entry of a SRTP reception hint track as a sub box of theSchmeInformationBox "schi" in the SRTPProcessBox box "srpp" as defined in [7].
Table 12.1: ServiceProtectionDescription box
Field
BoxHeader.Size
BoxHeader.Type
BoxHeader.Version
SecurityDescription

Type
Unsigned int(32)Unsigned int(32)Unsigned int(8)Unsigned int(8)[]Details

Value"spdb"0Service Protection Description
Metadata Fragment

BoxHeader Size, Type, Version: indicate the size, type and version of the ServiceProtectionDescription box. The typeshall be "spdb" and the version shall be 0.
SecurityDescription:. This field shall contain the XML encoded Service Protection Description Metadata Fragment as
specified in [40] with the restriction that only the mediaFlow element referring to the SRTP stream from which thisSRTP reception hint track was recorded is contained. That is, the SecurityDescription shall contain exactly one
mediaFlow element and this element shall correspond to the stored SRTP packets described by the Sample Description
which also contains this SecurityDescription.

12.3

SDP

Fragments that together constitute an SDP description shall be contained in a 3GP file with Media Stream recording
extensions. Session-level SDP, i.e. all lines before the first media-specific line ('m=' line), shall be stored as Movie SDP
information within the User Data box, as specified in [7]. Media-level SDP, i.e. an 'm=' line and the lines before theETSI

3GPP TS 26.244 version 10.0.0 Release 10

47

ETSI TS 126 244 V10.0.0 (2011-04)

next 'm=' line (or end of SDP) shall be stored as Track SDP information within the User data box of the corresponding
track. Media-level SDP shall be contained in each corresponding reception hint track or media track.

13

HTTP streaming extensions

13.1

Introduction

This clause describes extensions to the 3GP file format related to Adaptive HTTP Streaming as specified in TS 26.234[3], clause 12 using HTTP [48] as delivery protocol for segments.

13.2

Segment types

It is possible in HTTP streaming to form files from segments - or concatenated segments - which would not necessarily
form 3GP compliant files (e.g. they do not contain a movie box). If such segments are stored in separate files (e.g. on astandard HTTP server) it is recommended that these "segment files" start with a segment-type box, to enable
identification of those files, and declaration of the specifications with which they are compliant.
A segment type has the same format as an 'ftyp' box [7], except that it takes the box type 'styp'. The brands within it
should include the same brands that were included in the 'ftyp' box that preceded the "moov" box, and may also include
additional brands to indicate the compatibility of this segment with various specification(s) such as the 3GP Media
Segment Profile defined in clause 5.4.10 of this specification.
Valid segment type boxes shall be the first box in a segment. Segment type boxes may be removed if segments areconcatenated (e.g. to form a full 3GP file), but this is not required. Segment type boxes that are not first in their files
may be ignored.

13.3

Track Fragment Adjustment Box

Track Fragment Adjustment Boxes describe the relative time difference of the first samples of tracks within a movie
fragment. When randomly accessing a 3GP file or a Media Segment at a movie fragment that contains a Track
Fragment Adjustment Box, the Track Fragment Adjustment Box provides instructions on how the timeline of one ormore of the tracks may be modified to generate synchronization between the tracks. For example, if, in the previous
fragment, one track ended later than another, the first sample of that track in this fragment will need to be presented
later also; an edit-list in the track fragment adjustment box containing an empty edit, and then a media edit, achieves
that effect.
The syntax of a Track Fragment Adjustment Box as described below is identical to that of edit-lists. However, unlike
edit-lists, which must always be applied, when present, to adjust the timelines of the containing tracks, a Track
Fragment Adjustment Box may only be applied when randomly accessing a 3GP file or a Media Segment at a movie
fragment containing the Track Fragment Adjustment Box. In continuous playback, wherein the track alignment is
known (e.g. from decoding the previous segment) and sync between tracks has been achieved, Track Fragment
Adjustment Box shall not be applied.
The container of the Track Fragment Adjustment Box is the Track Fragment Box. If present, the Track Fragment
Adjustment Box should be positioned after the Track Fragment Header Box and before the first Track Fragment Run
box. The Track Fragment Adjustment Box is a container for the Track Fragment Media Adjustment Boxes.
aligned(8) class TrackFragmentAdjustmentBox extends Box("tfad") {}The Track Fragment Media Adjustment Box provides explicit time line offsets. By indicating "empty" time, or bydefining a "dwell", the offset can advantageously delay the playback time of the media in the track so that media indifferent tracks can be synchronized. Alternatively, the media_time value may be used to discard part of the 'earlier'tracks.
aligned(8) class TrackFragmentMediaAdjustmentBox extends FullBox("tfma", version, 0) {unsigned int(32) entry_count;for (i=1; i <= entry_count; i++) {if (version==1) {unsigned int(64) segment_duration;ETSI

3GPP TS 26.244 version 10.0.0 Release 10

48

ETSI TS 126 244 V10.0.0 (2011-04)

int(64) media_time;} else { // version==0
unsigned int(32) segment_duration;
int(32) media_time;}int(16) media_rate_integer;
int(16) media_rate_fraction = 0;}}

version is an integer that specifies the version of this box (0 or 1).
entry_count is an integer that gives the number of entries in the following table.
segment_duration is an integer that specifies the duration of this adjustment segment in units of the timescale in theMovie Header Box. 'Adjustment segment' in this context does not refer to the 'Media Segment' that contains the "tfma"
but refers to the operation that is performed to place the track at appropriate composition time.
media_time is an integer containing the starting time within the media of this adjustment segment (in media time scale
units, in composition time). If this field is set to -1, it is an empty edit. The last adjustment in a track shall never be an
empty edit.
media_rate_integer specifies the relative rate at which to play the media corresponding to this adjustment segment. If
this value is 0, then the adjustment is specifying a "dwell": the media at media-time is presented for the segmentduration. Otherwise this field shall contain the value 1.

13.4

Segment Index Box

The Segment Index Box ('sidx') provides a compact index of the movie fragments and other Segment Index Boxes in asegment. Each Segment Index Box documents a subsegment, which is defined as being a self-contained set of one ormore consecutive movie fragments, ending either at the end of the containing segment, or at the beginning of asubsegment documented by another Segment Index Box. A self-contained set contains one or more movie fragment
boxes with the corresponding media data box(es), and each movie fragment box immediately precedes its
corresponding media data box.
The indexing may refer directly to movie fragments, or to segment indexes which (directly or indirectly) refer to movie
fragments; the segment index may be specified in a "hierarchical" or "daisy-chain" or other form by documenting timeand byte offset information for other Segment Index Boxes within the same segment or subsegment.
In Media Segments as specified in clause 5.4.10, that is, segments not containing a Movie Box ("moov") but containing
Movie Fragment Boxes ("moof"), if any Segment Index Boxes are supplied then a Segment Index Box shall be placed
before any Movie Fragment ("moof") box, and the subsegment documented by that first Segment Index box shall be theentire segment.
One track (normally a track in which not every sample is a random access point, such as video) is selected as areference track. The earliest composition time of the reference track is documented in the Segment Index.
The reference type defines whether the reference is to a Movie Fragment ("moof") Box or Segment Index ("sidx") Box.
The offset gives the distance, in bytes, from the first byte following the enclosing Segment Index Box, to the first byteof the referenced box. (i.e. if the referenced box immediately follows the "sidx", this byte offset value is 0).
The earliest composition time (for the reference track) of the first subsegment is explicitly provided. The Segment Index
then provides one entry for each subsegment documented by the index. For each subsegment, a subsegment duration isprovided. The earliest composition time of a subsegment is calculated by summing the subsegment durations of thepreceding subsegments and the earliest composition time of the first subsegment. The earliest composition time of asubsegment is the earliest composition time of any sample in the reference track of the subsegment.
A Segment Index Box contains a random access point (RAP) if any entry in their second loop contains a random accesspoint.
The container for 'sidx' box is the file or segment directly.
aligned(8) class SegmentIndexBox extends FullBox("sidx", version, 0) {unsigned int(32) reference_ID;
unsigned int(32) timescale;if (version==0)ETSI

3GPP TS 26.244 version 10.0.0 Release 10

49

ETSI TS 126 244 V10.0.0 (2011-04){
unsigned int(32) earliest_presentation_time;
unsigned int(32) first_offset;}
else{
unsigned int(64) earliest_presentation_time;
unsigned int(64) first_offset;}
unsigned int(16) reserved = 0;
unsigned int(16) reference_count;for(i=1; i <= reference_count; i++){bit (1)
reference_type;unsigned int(31)subsegment_size;
unsigned int(32)subsegment_duration;
bit(1)
contains_RAP;
unsigned int(31)RAP_delta_time;}}reference_track_ID provides the track_ID for the reference track.
timescale provides the timescale, in ticks per second, for the time and duration fields within this box; it is recommended
that this match the timescale of the reference track, i.e. the timescale field of the Media Header Box of the track.
earliest_presentation_time is the earliest composition time of any sample in the reference track in the first
subsegment, expressed in the timescale of the reference track (as documented in the timescale field of the Media Header
Box of the track).
first_offset is the distance in bytes from the first byte following the containing Segment Indexing Box, to the first byteof the first referenced box.
reference_count: the number of elements indexed by second loop; reference_count shall be 1 or greater.
reference_type: when set to 0 indicates that the reference is to a movie fragment ("moof") box; when set to 1 indicatesthat the reference is to a segment index ("sidx") box.
subsegment_size: the distance in bytes from the first byte of the referenced box to the first byte of the next referenced
box or in the case of the last entry, the first byte not indexed by this Segment Index Box.
subsegment_duration: when the reference is to Segment Index Box, this field carries the sum of thesubsegment_duration fields in that box; when the reference is to a movie fragment, this field carries the difference
between the earliest composition time of any sample of the reference track in the next subsegment (or the first
subsegment of the next segment, if this is the last subsegment of the segment or the end composition time of thereference track if this is the last subsegment of the representation) and the earliest composition time of any sample of
the reference track in the referenced subsegment; the duration is expressed in the timescale value in this box.
contains_RAP: when the reference is to a movie fragment, then this bit may be 1 if the track fragment within thatmovie fragment for the track with track_ID equal to reference_track_ID contains at least one random access point,
otherwise this bit is set to 0; when the reference is to a segment index, then this bit shall be set to 1 only if any of thereferences in that segment index have this bit set to 1, and 0 otherwise.
RAP_delta_time: if contains_RAP is 1, provides the presentation (composition) time of a random access point (RAP);
reserved with the value 0 if contains_RAP is 0. The time is expressed as the difference between the decoding time of
the first sample of the subsegment documented by this entry and the presentation (composition) time of the random
access point, in the track with track_ID equal to reference_track_ID.

13.5

Track Fragment Decode Time Box

The Track Fragment Base Media Decode Time ("tfdt") Box provides the decode time of the first sample in the trackfragment. This can be useful, for example, when performing random access in a file; it is not necessary to sum thesample durations of all preceding samples in previous fragments to find this value (where the sample durations are thedeltas in the Decoding Time to Sample Box and the sample_durations in the preceding track runs).
The Track Fragment Base Media Decode Time Box, if present, shall be positioned after the Track Fragment Header
Box and before the first Track Fragment Run box.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

50

ETSI TS 126 244 V10.0.0 (2011-04)

Note: the decode timeline is a media timeline, established before any explicit or implied mapping of media time topresentation time, for example by an edit list or similar structure.
aligned(8) class TrackFragmentBaseMediaDecodeTimeBox
extends FullBox("tfdt", version, 0) {if (version==1) {unsigned int(64) baseMediaDecodeTime;} else { // version==0
unsigned int(32) baseMediaDecodeTime;}}version is an integer that specifies the version of this box (0 or 1 in this specification).
baseMediaDecodeTime is an integer equal to the sum of the decode durations of all earlier samples in the media,
expressed in the media's timescale. It does not include the samples added in the enclosing track fragment.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

51

ETSI TS 126 244 V10.0.0 (2011-04)

Annex A (normative):
MIME Type Registrations for 3GP files
A.1

MIME Types

A.1.1

GeneralThis registration is an update and replacement of RFC 3839. It applies to all files defined as using the '3GP' file format
and identified with a suitable brand in a 3GPP specification. The usual file suffix for all these files is ".3gp". The
difference between the current registration and RFC 3839 is the inclusion of two optional parameters.

A.1.2

Files with audio but no visual content

The type "audio/3gpp" may be used for files containing audio but no visual presentation (neither video nor timed text,
for example).
Type name: audio
Subtype name: 3gpp
Required parameters: none
Optional parameters:
codecs:is a single value or a comma-separated list that identifies the codec(s) needed for rendering thecontent contained (in tracks) of a file. The codecs parameter is defined in RFC 4281 [32]. The ISO
file format name space and ISO syntax in clauses 3.2 and 3.3 of RFC 4281, respectively, shall be
used together with additions defined in clause A.2.2 of the present document.

types:

is a single value or a comma-separated list that identifies the MIME media types of the content
contained (in items) in a file. It is defined in clause A.2.3 of the present document.

Encoding considerations: files are binary and should be transmitted in a suitable encoding without CR/LF conversion,
7-bit stripping etc.; base64 (RFC 4648 [35]) is a suitable encoding.
Security considerations: see the security considerations section in A.3 of the present document.
Interoperability considerations: The 3GPP organization has defined the specification, interoperability, and conformance.
IMTC conducts interoperability testing.
Published specification: 3GPP TS 26.234, Release 5; 3GPP TS 26.244, Release 6 or later. 3GPP specifications are
publicly accessible at the 3GPP web site, www.3gpp.org.
Applications which use this media type: Multi-media
Additional information: The type "audio/3gpp" may be used for files containing audio but no visual presentation. Files
served under this type must not contain any visual material. (Note that timed text is visuallypresented and is considered to be visual material).
Magic number(s):None. However, the file-type box must occur first in the file, and must contain a 3GPP brand in its
compatible brands list.

File extension(s):'3gp' and '3gpp' are both declared at http://www.nist.gov/nics/; 3gp is preferred

Macintosh File Type Code(s): '3gpp'
Intended usage: COMMONETSI3GPP TS 26.244 version 10.0.0 Release 10

52

ETSI TS 126 244 V10.0.0 (2011-04)

Restrictions on usage: Note that this MIME type is used only for files; separate types are used for real-time transfer,
such as for the RTP payload format for AMR audio (RFC 4867 [15]).
Author:
3GPP TSG SA WG4Change controller: 3GPP TSG SA

A.1.3

Any files

The type "video/3gpp" is valid for all files. It is valid to serve an audio-only file as "video/3gpp".
MIME media type name: video
MIME subtype name: 3gpp
Required parameters: none
Optional parameters:
codecs:is a single value or a comma-separated list that identifies the codec(s) needed for rendering thecontent contained (in tracks) of a file. The codecs parameter is defined in RFC 4281 [32]. The ISO
file format name space and ISO syntax in clauses 3.2 and 3.3 of RFC 4281, respectively, shall be
used together with additions defined in clause A.2.2 of the present document.

types:

is a single value or a comma-separated list that identifies the MIME media types of the content
contained (in items) in a file. It is defined in clause A.2.3 of the present document.

Encoding considerations: files are binary and should be transmitted in a suitable encoding without CR/LF conversion,
7-bit stripping etc.; base64 (RFC 4648 [35]) is a suitable encoding.
Security considerations: see the security considerations section in A.3 of the present document.
Interoperability considerations: The 3GPP organization has defined the specification, interoperability, and conformance.
IMTC conducts interoperability testing.
Published specification: 3GPP TS 26.234, Release 5; 3GPP TS 26.244, Release 6 or later. 3GPP specifications are
publicly accessible at the 3GPP web site, www.3gpp.org.
Applications which use this media type: Multi-media
Additional information:
Magic number(s):None. However, the file-type box must occur first in the file, and must contain a 3GPP brand in its
compatible brands list.

File extension(s):'3gp' and '3gpp' are both declared at http://www.nist.gov/nics/; 3gp is preferred

Macintosh File Type Code(s): '3gpp'
Intended usage: COMMON
Restrictions on usage: Note that this MIME type is used only for files; separate types are used for real-time transfer,
such as for the RTP payload format for AMR audio (RFC 4867 [15]).
Author:
3GPP TSG SA WG4Change controller: 3GPP TSG SA

A.1.4

video/vnd.3gpp.segment

Type name: videoETSI

3GPP TS 26.244 version 10.0.0 Release 10

53

ETSI TS 126 244 V10.0.0 (2011-04)

Subtype name: vnd.3gpp.segment
Required parameters:
None.
Optional parameters:
None.
Encoding considerations:
Files are binary and should be transmitted in a suitable encoding without CR/LF conversion, 7-bit stripping etc.;base64 (RFC 4648 [35]) is a suitable encoding.
Security considerations:
See the security considerations section in A.3 of the present document.
Interoperability considerations:
None.
Published specification:
3GPP TS 26.244, Release 9.
Applications which use this media type:
Third Generation Partnership Project (3GPP) Adaptive HTTP Streaming.
Additional information:
Magic number(s):NoneFile extension(s):3gsPerson & email address to contact for further information:
John Meredith (john.meredith@etsi.org)
Intended usage:
CommonRestrictions on usage:
Author:
3GPP TSG SA WG4Change controller:
3GPP TSG SAETSI

3GPP TS 26.244 version 10.0.0 Release 10

A.2

Optional parameters

A.2.1

General54

ETSI TS 126 244 V10.0.0 (2011-04)

Two optional parameters are defined here for the "audio/3gpp" and "video/3gpp" media types. Additional parameters
may be specified by updating the media type registrations. Any unknown parameter shall be ignored.

A.2.2

Codecs parameter

The codecs parameter is defined in RFC 4281. The ISO file format name space and ISO syntax in clauses 3.2 and 3.3 of
RFC 4281 [32] shall be used together with extensions to the ISO syntax specified here.
The syntax in clause 3.3 of RFC 4281 defines the usage of the codecs parameter for files based on the ISO base media
file format and specifies that the first element of a parameter value is a sample description entry four-character code. It
also includes specific definitions for MPEG audio ('mp4a') and MPEG video ('mp4v') where each value in addition to
the four-character code includes two elements signalling Object Type Indications and Profile Level Indications (videoonly). These definitions apply to the MPEG codecs used by the 3GP file format, such as MPEG-4 Visual [10], MPEG-4
AAC [13] and Enhanced aacPlus [23, 24, 25]. Values for other codecs used by the 3GP file format are specified below.
When the first element of a value is 's263', indicating H.263 video [9], the second element is the decimal representationof the profile, e.g., 0 or 3, and the third element is the decimal representation of the level, e.g. 10 or 45.
When the first element of a value is 'avc1', indicating H.264 (AVC) video [29], the second element is the hexadecimal
representation of the following three bytes in the sequence parameter set NAL unit specified in [29]: 1) profile_idc, 2) abyte composed of the values of constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag,and reserved_zero_4bits in bit-significance order, starting from the most significant bit, and 3) level_idc. Note that
reserved_zero_4bits is required to be equal to 0 in [29], but other values for it may be specified in the future by ITU-T
or ISO/IEC.
When the first element of a value is one of the following elements, no other elements are defined for that value:-'samr', indicating AMR narrow-band speech [11];-'sawb', indicating AMR wide-band speech [12];-'sawp', indicating Extended AMR wide-band audio [21];-'tx3g', indicating timed text [4].

The following syntax defines all values above in ABNF (RFC 4234 [31]) by extending the definition in clause 3.3 of
RFC 4281:
id-iso= iso-gen / iso-mpega / iso-mpegv / iso-amr / iso-amr-wb / iso-amr-wbp / iso-tt / iso-h263 /iso-h264; iso-gen, iso-mepga, iso-mpegv as defined in RFC 4281

iso-amr= %x73.61.6d.72; 'samr'

iso-amr-wb= %x73.61.77.62; 'sawb'

iso-amr-wbp= %x73.61.6d.74; 'sawp'

iso-tt= %x74.78.33.67; 'tx3g'

iso-h263= s263 "." h263-profile "." h263-leveliso-h264= avc1 "." h264-plids263= %x73.32.36.33; 's263'avc1= %x61.76.63.31; 'avc1'ETSI

3GPP TS 26.244 version 10.0.0 Release 10

55

ETSI TS 126 244 V10.0.0 (2011-04)

h263-profile= 1*DIGIT

h263-level= 1*DIGIT

h264-plid= 6(DIGIT / "a"/ "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F"); leading "0x" omitted

A.2.3

Types parameter

The types parameter is a single value or a comma-separated list that identifies the MIME media types of the content
contained (in items) of a 3GP file. Each value consists of a type-subtype pair and corresponds to a value of thecontent_type field provided for an item in the item information box.
If the types parameter is present, then it shall include all MIME types needed for rendering the content contained (initems) of a file.
The types parameter is defined in ABNF (RFC 5234 [44]) below:
types= "types" "=" type-list

type-entry= type-name "/" subtype-name *( *WSP";" *WSP parameter )parameter= attribute *WSP "=" *WSP value

attribute= tokenvalue= token / quoted-stringtoken= 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39/ %x41-5A / %x5E-7E); 1*<any CHAR except SP, CTLs or tspecials>

type-list= DQUOTE type-entry *( "," type-entry ) DQUOTE'type-name' and 'subtype-name' are defined in RFC4288[42].
"tspecials" is defined in RFC2045[45]'quoted-string' is defined in RFC5322[43].
"CHAR", "CTL", "SP", 'WSP' and 'DQUOTE' are defined in RFC 5234 [31].
NOTE: any <"> character in "type-entry" needs to be escaped with "\". This is not shown in the above grammar.

A.3

Security considerations

The 3GPP file format may contain audio, video, displayable text data, images, graphics, scene descriptions, etc. Clearly
it is possible to author malicious files which attempt to call for an excessively large picture size, high sampling-rate
audio etc. However, clients can and usually do protect themselves against this kind of attack. It should be noted that
selected metadata fields may encompass information partly intended to protect the media against unauthorized use or
distribution. In this case, the intention is that alteration or removal of the data in the field would be treated as an offense
under national agreements based on World Intellectual Property Organization (WIPO) treaties.
There is no current provision in the standards for signing or authentication of these file formats.

ETSI

3GPP TS 26.244 version 10.0.0 Release 10

56

ETSI TS 126 244 V10.0.0 (2011-04)

Annex B (informative):
Change history
Change history
Date

TSG # TSG Doc.

CR

Rev Subject/Comment

2004-03
2004-09
2004-09
2004-09
2004-09
2004-12

23
25
25
25
25
26

SP-040065
SP-040643
SP-040654
SP-040657
SP-040643
SP-040839

002
003
004
005
006

2004-1226

SP-040839

007

2005-03
2005-09
2005-09
2005-09
2006-06
2006-06
2007-03
2007-03
2007-06
2007-06
2007-12
2008-12
2008-12
2009-06

27
29
29
29
32
32
35
35
36
36
38
42
42
44

SP-050094
SP-050427
SP-050427
SP-050427
SP-060355
SP-060359
SP-070025
SP-070025
SP-070314
SP-070319
SP-070761
SP-080681
SP-080681
SP-090256

008
0009
0010
0011
0012
0013
0015
0017
0019
0020
0021
0023
0024
0025

2009-06
2009-09
2009-12

44
45
46

SP-090248
SP-090567
SP-090710

0027
0028
0029

2

2009-122010-032010-06

46
47
48

SP-090710
SP-100024
SP-100301

0030
0031
0032

2
2
1

2010-0949

SP-100465

0033

2

2011-03
2011-03

51
51

SP-110039

0036

2

1
1
1
1

1
1

1
2
1
1
1
1
1

Approved at TSG#23
Storage of AMR-WB+ audio in 3GP files
Additional Release 6 update to 3GP file format
Storage of H.264 (AVC) video in 3GP files
Storage of Enhanced aacPlus audio in 3GP files
Correction of syntax of encryption boxes and outdated
references
Correction of sample structure for AMR-WB+ in 3GP
files
Extended presentations in 3GP files for MBMS
New UDTA sub-box "albm" – album for the media
Correction of SDP bandwidth modifiers
Correction regarding sample groups in 3GP file format
Correction of references in the 3GP file format
Support for ID3v2 in 3GP files
MIME Type Registrations for 3GP files
Correction of sampling rate information
Correction of references in the 3GP file format
Inclusion of DIMS in the 3GP file format
Correction of reference in the 3GP file format
Addition of file delivery support
Recording of Media Stream Data
Correction of signaling of sample_type in key message
tracksCorrection to ABNF syntax
Clean-up corrections
New Profile to support Adaptive HTTP-based
Streaming in 3GP File Format
File format video and branding updates
File Format updates for HTTP Streaming
Essential Corrections for 3GP File Format to support
Adaptive Streaming
Corrections for 3GP File Format to support Adaptive
Streaming
AHS Fixes for MPEG Alignment (Segment Indexing)
Version for Release 10

ETSI

Old

New

6.0.0
6.0.0
6.0.0
6.0.0
6.1.0

6.0.0
6.1.0
6.1.0
6.1.0
6.1.0
6.2.0

6.1.0 6.2.0
6.2.0
6.3.0
6.3.0
6.3.0
6.4.0
6.5.0
7.0.0
7.0.0
7.1.0
7.1.0
7.2.0
7.3.0
7.3.0
8.0.0

6.3.0
6.4.0
6.4.0
6.4.0
6.5.0
7.0.0
7.1.0
7.1.0
7.2.0
7.2.0
7.3.0
8.0.0
8.0.0
8.1.0

8.0.0 8.1.0
8.1.0 8.2.0
8.2.0 9.0.0
8.2.0 9.0.0
9.0.0 9.1.0
9.1.0 9.2.0
9.2.0 9.3.0
9.3.0 9.4.0
9.4.0 10.0.0

3GPP TS 26.244 version 10.0.0 Release 10

57

History
Document history
V10.0.0

April 2011

PublicationETSIETSI TS 126 244 V10.0.0 (2011-04)