Content for TS 26.143 Word version: 19.0.0
A Registration Information
A.1 3GPP Registered URIs
B Examples
B.1 MMBP message with a 3D asset
B.2 Single Media Type
B.3 3GP File with multiple media types
C Transcoding Guidelines
C.1 Transcoding 3D scenes and assets
D API Definitions
D.1 Introduction
D.2 MMBP-GEN-API
D.3 MMBP-PLAY-API
$ Change history
A Registration Information p. 32
A.1 3GPP Registered URIs p. 32
The clause documents the registered URIs in this specification following the process in https://www.3gpp.org/3gpp-groups/core-network-terminals-ct/ct-wg1/uniform-resource-identifier-uri-list ,
Table A-1 lists all registered URN values as well as
- a brief description of its functionality;
- a reference to the specification or other publicly available document (if any) containing the definition;
- the name and email address of the person making the application; and
- any supplementary information considered necessary to support the application.
| URN | Description | Reference | Contact | Remarks |
|---|---|---|---|---|
| urn:3GPP:26143:18:baseline-mmbp-player | Media Messaging Baseline MMBP Player Profile | TS 26.143, clause 6.2.1 | Thomas Stockhammer
tsto@qti.qualcomm.com | none |
| urn:3GPP:26143:18:baseline-mmbp-generator | Media Messaging Baseline MMBP Generator Profile | TS 26.143, clause 6.3.1 | Thomas Stockhammer
tsto@qti.qualcomm.com | none |
B Examples p. 32
B.1 MMBP message with a 3D asset p. 32
In this example we show an excerpt of a message that contains a 3D asset. The root entry is a glTF 2.0 file. The message has two additional parts: a binary file that contains the geometry of the 3D asset and an image that provides the texture of the 3D asset.
B.2 Single Media Type |R19| p. 33
B.2.1 Introduction p. 33
This clause provides examples for MMBP message with a single media type according to 26143_CONTAINER_RFC2046_SINGLE.
B.2.2 Audio p. 33
The following example provides an MMBP that includes a single media in an 3gp file encoded with EVS.
B.2.3 Images p. 34
The following example provides an MMBP that includes a single png image containing the 3GPP logo.
B.3 3GP File with multiple media types |R19| p. 34
B.3.1 Introduction p. 34
This clause provides examples for MMBP message with conforming to 26143_CONTAINER_MP4_3GP9.
B.3.2 Audio and Video in single file p. 35
The following example provides an MMBP that includes an EVS audio track and an HEVC video track in a single media in an 3gp file.
B.3.3 Audio and Video in Container p. 35
The following example provides an MMBP that includes an EVS audio file and an HEVC video file in a single container.
C Transcoding Guidelines p. 35
C.1 Transcoding 3D scenes and assets p. 35
Transcoding may need to be performed to support UEs that lack the capabilities to render 3D scenes and assets as defined in clause 5.8. The transcoding operation for 3D scenes and assets is effectively a rendering operation, where the 3D scene or asset is rendered into an image, image sequence, or video. The Messaging Server (e.g. MMS Server/Relay) may select an appropriate pose or set of poses (e.g. along a pre-defined path) that it uses to render the 3D scene or asset.
D (Normative) API Definitions |R19| p. 35
D.1 Introduction p. 35
This Annex collects the stage-2 API definition supported with Interface Definition Language (IDL) description MMBP-GEN-API and MMBP-PLAY-API. Note that this does not form a full implementation but can be used as a reference for implementations in different environments.
D.2 MMBP-GEN-API p. 36
D.2.1 Introduction p. 36
The MMBP-GEN-API is typically used by a Message Service Sender to generate an MMBP according to this specification.
D.2.2 Filter Concept p. 36
D.2.2.1 General p. 36
The general methods defined in this clause allows packaging media resources into a conforming MMBP with focus on the baseline MMBP Generator Profile as defined in clause 6.3.
The encoding API is described by filters as for example defined here: https://wiki.gpac.io/Filters/filters_general .
Encoding architectures can be built by using filters. Filters are configurable processing units consuming and producing data packets. These packets are carried between filters through a data channel called PID. A PID is in charge of allocating/tracking data packets and passing the packets to the destination filter(s). Each output PID carries a set of properties describing the data it delivers (e.g. width, height, codec, ...).
Each filter exposes a set of argument to configure itself, using property types and values described as strings formatted with separators.
Each filter is declared by its name, with optional filter arguments appended as a list of colon-separated name=value pairs. For encoding, typical parameters are:
For typical generation processes in the context of this specification, the following is applied
- c=NAME: identifies the desired encoding codec capability as defined in clause 5.
- b=UINT: indicates the bitrate in bits per second
generate [options] FILTER [LINK] FILTER [...]
generate [options] INPUT_FILTER + ENCODE_FILTER + PACKAGE_FILTER + MULTIPLEX_FILTER
D.2.2.2 Specific Filters p. 36
Specific filters are for further study.
D.3 MMBP-PLAY-API p. 36
D.3.1 Introduction p. 36
The MMBP-PLAY-API is typically used by a messaging service client to playback an MMBP according to this specification.
D.3.2 Filter Conpcept p. 37
D.3.2.1 Overview p. 37
The general methods defined in this clause allow playing back media resources for conforming MMBP with focus on the baseline MMBP Player Profile as defined in clause 6.2.
D.3.2.2 Specific Filters p. 37
Specific filters are for further study.
$ Change history p. 37
