T/AI 114-2024 信息技术 高效多媒体编码 第6部分：智能媒体传输

ICS 35.040
CCS L71
团体标准
T/AI 114—2024
信息技术 高效多媒体编码 第6部分：智能媒体传输
Information technology—High efficiency multimedia coding— Part 6: Smart Media Transport
2024 - 10 - 14发布2024 - 10 - 14实施
中关村视听产业技术创新联盟 发布

目 次
前言 ............................................................................. III
引言 .............................................................................. IV
1 范围 ............................................................................. 1
2 规范性引用文件 ................................................................... 1
3 术语和定义 ....................................................................... 1
4 缩略语 ........................................................................... 3
5 约定 ............................................................................. 4
6 协议架构 ......................................................................... 4
7 数据模型 ......................................................................... 5
7.1 概述 ....................................................................... 5
7.2 数据包 ..................................................................... 5
7.3 媒体资源 ................................................................... 6
7.4 CEU ........................................................................ 6
8 数据传输 ........................................................................ 10
8.1 概述 ...................................................................... 10
8.2 传输模型 .................................................................. 11
8.3 传输协议 .................................................................. 12
8.4 传输负载结构 .............................................................. 16
8.5 基于负载结构的传输操作 .................................................... 19
9 信令 ............................................................................ 21
9.1 概述 ...................................................................... 21
9.2 信令消息格式 .............................................................. 21
9.3 媒体数据包消费信令消息 .................................................... 22
9.4 媒体资源描述符 ............................................................ 29
9.5 语法元素组 ................................................................ 33
9.6 ID值 ...................................................................... 39
9.7 资源请求响应消息 .......................................................... 40
9.8 交互反馈消息 .............................................................. 42
9.9 会话控制信令 .............................................................. 43
9.10 DCI ...................................................................... 44
9.11 时钟关系信息 ............................................................. 46
9.12 同步请求消息 ............................................................. 48
9.13 同步响应消息 ............................................................. 49
9.14 媒体资源传输特性消息 ..................................................... 50
10 媒体呈现 ....................................................................... 53
10.1 概述 ..................................................................... 53
10.2 呈现模型 ................................................................. 53
T/AI 114—2024
II
10.3 媒体呈现信令 ............................................................. 53
11 HTTP/2直播 ..................................................................... 58
11.1 概述 ..................................................................... 58
11.2 系统架构 ................................................................. 59
11.3 数据类型 ................................................................. 60
11.4 推送策略 ................................................................. 62
11.5 HTTP/2协议绑定 ........................................................... 63
11.6 消息定义 ................................................................. 63
12 自适应前向纠错编码 ............................................................. 66
12.1 概述 ..................................................................... 66
12.2 自适应前向纠错编码机制 ................................................... 67
12.3 编码符号块格式 ........................................................... 71
12.4 FEC的源数据包和恢复数据包格式 ............................................ 73
附录A （规范性） 假设接收机缓存模型 ............................................... 76
A.1 概述 ...................................................................... 76
A.2 FEC解码缓存 ............................................................... 76
A.3 去抖动缓存 ................................................................ 77
A.4 数据包解封装缓存 .......................................................... 77
A.5 假设接收缓存模型的使用 .................................................... 77
A.6 端到端时延和缓存要求的估计 ................................................ 77
A.7 语法 ...................................................................... 78
A.8 语义 ...................................................................... 78
附录B （规范性） 前向纠错编码码字 ................................................. 79
B.1 FEC编码算法 ............................................................... 79
B.2 自适应前向纠错编码码字 .................................................... 79
附录C （规范性） 支持多种音视频编码的SMT传输技术要求 ............................. 84
C.1 AVS2、AVS3音频SMT传输要求 ................................................ 84
C.2 AVS3视频SMT传输技术要求 .................................................. 87
T/AI 114—2024
III
前 言
本标准按照GB/T 1.1—2020《标准化工作导则 第1部分：标准化文件的结构和起草规则》的规定起草。
本标准代替《信息技术 高效多媒体编码》的第6部分T/AI 114-2021。《信息技术 高效多媒体编码》已经发布了以下部分：
——第1部分：系统；
——第2部分：视频；
——第3部分：音频；
——第4部分：符合性测试;
——第5部分：参考软件
——第6部分：智能媒体传输；
——第7部分：图片文件格式。
与T/AI 114-2021相比，除结构调整和编辑性改动外，主要技术变化如下：
a) 增加第5章“约定”。指明本标准字节序表示方案，规范算法和软件要求;
b) 修改部分消息ID，表ID，描述符ID。与国际上相关技术和标准对齐，解决索引冲突问题;
c) 增加“支持多种音视频编码的SMT传输技术要求”。规定支持多种音视频编码通过智能媒体传输协议（SMTP）进行传输时的信令规范，以提高传输效率和兼容性;
本标准由数字音视频编解码技术标准工作组提出。
本标准由中关村视听产业技术创新联盟归口。
本标准起草单位：上海交通大学、北京三星通信技术研究有限公司、中兴通讯股份有限公司、腾讯科技（深圳）有限公司、OPPO广东移动通信有限公司、广东博华超高清创新中心、咪咕文化科技有限
本标准公司、中央广播电视总台、北京大学、北京工业大学、上海工程技术大学、深圳龙岗智能视听研究院有限公司、鹏城实验室。
主要起草人：徐异凌、吴越、黄成、张行功、牟伦田、张文军、胡颖、陈浩、姜志乾、谢绍伟、许健伟、常勇健、黄巍、朱文婕、李秋婷、王一帆、杨开发、侯朴玥、许晓中、刘杉、杨智尧、张伟民、龙仕强、李琳、贝悦、王琦、徐嵩、王振中、郑建铧、黄铁军、赵海英、冯亚楠、陈丽丽、金晶、郭宗明、赵海武、陈杲、刘利、高文。
本标准及其所代替文件的历次版本发布情况为：
——本标准于2021年首次发布。
——本次为第一次修订。
T/AI 114—2024
IV
引 言
本文件为异构网络下的媒体数据传输与分发提供技术规范，旨在为异构网络中的媒体数据提供传输服务。
《信息技术 高效多媒体编码》拟由以下7个部分构成：
——第1部分：系统。目的在于规定高效多媒体编码的系统层约定、架构、媒体呈现描述、片段、内容安全等方面的内容。
——第2部分：视频。目的在于规定适应多种比特率、分辨率和质量要求的高效视频压缩方法的解码过程。
——第3部分：音频。目的在于描述高质量音频信号的通用音频编码、无损音频编码和三维音频对象编码的表示方法及通用音频解码、无损音频解码和三维音频对象解码的方法。
——第4部分：符合性测试。目的在于规定对GB/T33475.2-2024的视频位流和GB/T33475.3-2018的音频位流进行符合性测试的要求和方法。
——第5部分：参考软件。目的在于定义满足GB/T33475.2-2024和GB/T33475.3-2018规定要求的参考软件。
——第6部分：智能媒体传输。目的在于规定异构包交换网络下多媒体数据传输的智能媒体传输方法。
——第7部分：图片文件格式。目的在于规定高效多媒体编码图片文件格式的语法描述、语义描述、封装定义。
本标准的发布机构提请注意，声明符合本标准时，可能涉及7.3、7.4、8.3、8.4、9.3、9.4、9.7、9.8、9.9、9.12、9.13、10.3、11.3、11.4、11.5、11.6、12.1、12.2、12.4、附录A、附录B中如下26项与数字视频编解码技术相关的专利的使用。专利申请号、名称及对应章条如下：
序号
专利申请号
专利名称
对应章条
1
201510401550.9
一种多媒体内容分级技术的实现方法
7.3，9.4
2
201510064427.2
一种异构网络传输下的动态时间窗口及缓存机制
9.4.3
3
201510698388.1
一种异构媒体网络传输下动态提供资源可获取时间的方法
9.4.3
4
201710561850.2
基于媒体内容的自适应系统码FEC编译码方法
B.1，B.2
5
201610107748.0
一种多媒体系统中信息交互系统及网络传输方法
9.7
6
201510673115.1
一种基于媒体内容的FEC方法
12.1，12.2.1
7
201510673091.X
一种基于媒体内容的自适应FEC方法
12.1，12.2.2，12.2.3
8
201610060847.8
多媒体服务中内容组件关系的描述及个性化显示方法
9.4.4
9
201610056411.1
一种基于媒体自身属性以支持空间分块的存储与传输方法
9.3.5
10
201610674633.X
一种面向多媒体内容组件个性化呈现的方法及系统
10.3
11
201510955611.6
一种关联多媒体内容个性化呈现信息的描述方法
9.4
12
201610915990.0
基于广播系统的媒体点播模式控制方法
9.9
13
201710027492.7
一种基于广播系统的媒体点播服务控制方法
9.9
T/AI 114—2024
V
序号
专利申请号
专利名称
对应章条
14
201611141843.9
媒体信息的处理方法、装置及系统
9.8
15
201610757375.1
异构网络下基于网络状况的多媒体资源自适应同步方法
9.12，9.13
16
201710973473.3
基于媒体内容的自适应系统码FEC方法、装置及系统
12.2.2, 12.4.3
17
201610081443.7
媒体数据传输方法及装置
11.3，11.4，
11.5，11.6
18
201280029677.7
用于在多媒体系统中发送/接收媒体内容的方法和装置
7.4.4
19
201480042072.0
用于支持下载和流传送的分组传输的方法和设备
8.3
20
201380025465.6
用于多媒体传输系统的收发数据的方法和装置
8.3
21
201380053506.2
用于在混合网络中传送和接收多媒体数据的装置和方法
8.4
22
201280061956.1
用于在广播系统中配置控制消息的装置和方法
9.3.2
23
201280014043.4
用于在广播系统中配置控制消息的装置和方法
9.3.2
24
201380035064.9
提供多媒体内容的方法
9.3.6
25
201380053098.0
用于媒体数据递送控制的方法和装置
附录A
26
201480022346.X
用于在多媒体传输系统中发送媒体数据的方法
8.3
本标准的发布机构对上述专利的真实性、有效性和范围无任何立场。
上述专利持有人已向本标准的发布机构保证，愿意同任何申请人在合理且无歧视的条款和条件下，就专利授权许可进行谈判。上述专利持有人的声明已在本标准的发布机构备案，相关信息可以通过以下联系方式获得：
专利持有人：上海交通大学
地址：上海市闵行区东川路800号，邮编200240
专利持有人：中兴通讯股份有限公司
地址：深圳市南山区高新技术产业园科技南路中兴通讯大厦，邮编518057
专利持有人：三星电子株式会社
地址：北京市朝阳区东环南路2号航华科贸中心招商局大厦，邮编100022
联 系 人：黄铁军（数字音视频编解码技术标准工作组秘书长）
通讯地址：北京大学理科2号楼2641室
邮政编码：100871
电子邮件：tjhuang@pku.edu.cn
电话：+8610-62756172
传真：+8610-62751638
网址：http://www.avs.org.cn
请注意除上述专利外，本标准的某些内容仍可能涉及专利。本标准的发布机构不承担识别专利的责任。

T/AI 114—2024
1
信息技术 高效多媒体编码 第6部分：智能媒体传输
1 范围
本标准适用于异构包交换网络下多媒体数据传输的智能媒体传输方法，涵盖数据模型、数据传输、信令、媒体呈现、HTTP/2直播以及自适应前向纠错编码等内容。
本标准适用于网络流媒体、网络电视和视频点播等应用。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本标准必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本标准；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本标准。
GB 18030-2022 信息技术 中文编码字符集
GB/T 18793-2002 信息技术 可扩展置标语言(XML)1.0
ISO/IEC 14496-12 信息技术 音视频对象的编码 第12部分：ISO基本媒体文件格式（Information technology – Coding of audio-visual objects – Part 12: ISO base media file format）
ISO/IEC 23009-1 信息技术 基于HTTP的动态自适应流媒体 第1部分：媒体呈现描述和分段格式（Information technology — Dynamic adaptive streaming over HTTP （DASH） — Part 1: Media presentation description and segment formats）
IEEE 1003.1-2008 信息技术 便携操作系统接口 （Information technology - Portable Operating System Interface (POSIX（TM）））
IETF RFC 1738 统一资源定位符（Uniform Resource Locators (URL)）
IETF RFC 2141 统一资源名称语法（URN Syntax）
IETF RFC 3406 统一资源名称（URN）命名空间定义机制 （Uniform Resource Names (URN) Namespace Definition Mechanisms）
IETF RFC 3986 统一资源标识符（URI）：通用语法（Uniform Resource Identifier (URI): Generic Syntax）
IETF RFC 4122通用唯一标识符（UUID）URN命名空间 （A Universally Unique IDentifier (UUID) URN Namespace）
IETF RFC 6570 统一资源标识符模板 （URI Template）
IETF RFC 7230 超文本传输协议(HTTP/1.1)：消息语法和路由（Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing）
IETF RFC 7231 超文本传输协议(HTTP/1.1)：语义和内容 （Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content）
3 术语和定义
T/AI 114—2024
2
下列术语和定义适用于本标准。
3.1
访问单元 access unit
含时间信息的最小媒体数据实体。
3.2
媒体资源 asset
任何与唯一标识符相关的用作构建一个多媒体呈现的多媒体数据实体。
3.3
通用封装单元 common encapsulation unit
与媒体编解码器无关的可独立解码的时序或非时序数据的通用容器。
3.4
媒体内容 media content
媒体数据中包含的具有相同时间基准的音频、视频、字幕等信息。
3.5
非时序数据 non-timed data
在解码和/或呈现媒体内容时不存在内在时间轴的媒体数据。
3.6
数据包 package
使用本标准协议传送的媒体数据逻辑单元。
3.7
包 packet
使用本标准协议传送的媒体数据的格式化单元。
3.8
包流 packet flow
有相同发送和接受实体的数据包序列。
3.9
负载 payload
使用本标准协议或者一个网络应用层传送协议携带数据包或者信令消息的媒体数据的格式化单元。
T/AI 114—2024
3
3.10
接收实体 receiving entity
用于接收和消费媒体数据的实体。
3.11
发送实体 sending entity
将媒体数据发送给一个或多个接收实体的实体。
3.12
智能媒体传输协议 smart media transport protocol
用于在互联网传输有效载荷的应用层传输协议。
3.13
时序数据 timed data
在解码和/或呈现媒体内容时存在内在时间轴的媒体数据。
4 缩略语
下列缩略语适用于本标准。
AL-FEC：
ADC
AT
AU：
AVS
CEU：
CRI：
DCI：
HRBM：
HTTP：
IP
ISO BMFF：
MIME：
MP：
MPT
MPEG
MTU：
MUR
NTP：
应用层前向纠错
媒体资源传输特性
可获取时间
访问单元
数字音视频编解码技术标准工作组
通用封装单元
时钟相关信息
设备性能信息
假设接收机缓冲模型
超文本传送协议
互联网协议
ISO基媒体文件格式
多用途互联网邮件扩展类型
SMT包
媒体包表
动态影像专家组
最大传输单元
媒体单元关系符
网络时间协议
（application layer forward error correction）
（asset delivery characteristic）
（available time）
（access unit）
（audio video coding standard workgroup of China）
（common encapsulation unit）
（clock relation information）
（device capability information）
（hypothetical receiver buffer model）
（hypertext transfer protocol）
（internet protocol）
（iso base media file format）
（multipurpose internet mail extensions）
（SMT package）
（media package table）
（moving picture experts group）
（maximum transmission unit）
（media unit relationship）
（network time protocol）
T/AI 114—2024
4
PA
PID：
PTS
QoS
RAP：
RTP：
SMT：
SMTP：
TCP：
TS：
UDP：
URI：
URL：
URN：
UTC：
UUID：
包访问
包标识符
呈现时间戳
服务质量
随机访问点
实时传输协议
智能媒体传输
智能媒体传输协议
传输控制协议
传输流
用户数据报协议
统一资源标识符
统一资源定位器
统一资源名称
协调世界时
通用唯一标识符
（package access）
（packet identifier）
（presentation time stamp）
（quality of service）
（random access point）
（real-time transport protocol）
（smart media transport）
（SMT protocol）
（transmission control protocol）
（transport stream）
（user datagram protocol）
（uniform resource identifier）
（uniform resource locator）
（uniform resource name）
（coordinated universal time）
（universally unique identifier）
5 约定 本标准使用了大端模式的字节序表示方案。当存储或传输多字节数据时，数据的高位字节被存储于内存的较低地址处，而低位字节则存储于较高的地址。
6 协议架构
SMT协议为面向包交换的应用层协议，旨在为异构网络中的媒体数据提供传输服务。异构网络即单向物理网络（如数字广播网络）和双向物理网络（如互联网）组成的混合网络。媒体数据包括时序媒体数据（如视频，音频）、非时序媒体数据（如文本、图片）、以及用户反馈数据（如实时指令）。SMT协议基于IP，能动态地自适应于异构网络中的不同网络条件。
SMT协议从逻辑上可以分为三个逻辑功能区，分别为封装功能区、传送功能区和信令功能区，见图1。
封装功能区定义内容和服务的逻辑组织结构，实现了数据内容和数据描述的分离以及数据碎片化（详见7.4）。以此形成了媒体内容的分布式布置，能够依靠数据描述形成的内容关联，完成服务的灵活组织和动态配置。
传送功能区定义异构网络下多媒体内容的传输，包括对多媒体数据包的封装与流式传送（详见8.4）。传送功能区支持媒体数据的重要性分级、数据存储格式与传输格式的快速转换、数据内容的摘要和检索（如音视频指纹，检索特征向量等），同时加入应用层纠错保护机制，建立用于处理时延和抖动的接收端缓冲模型，以自适应于网络状态的变化。
T/AI 114—2024
5
传输层协议
网络层协议（IP）
媒体编码层
应用层协议（SMT）
呈现引擎
信令功能区
1.媒体传输信令
2.媒体消费信令
封装功能区
1.基于ISO BMFF
2.内容碎片化
传送功能区
1.媒体已知的封包格式
2.纠错保护机制
3.异构缓冲模型
图1 SMT 协议架构
信令功能区定义用于控制媒体内容消费和传送两方面的信息格式（详见9.2），能根据需求定制信
令消息以实现动态配置服务、多种QoS类型、网络时钟的同步以及多屏设备之间的交互等，同时能够保
证客户端实时反馈和超低延时控制。
7 数据模型
7.1 概述
SMT 协议提供了媒体数据的流式传输和存储式传输。在传输过程中，SMT 协议用信令消息保护数
据模型。为满足SMT 内容灵活组织的技术需求，SMT 服务中内容的关联关系由描述文件指定，服务的
改变不需要在数据流层级进行更改，只需要更新描述文件。同时为适配不同的网络环境，需要有单独的
媒体传输控制信息。在异构网络中，传输控制信息能够根据网络环境的变化动态更新。分离信令消息与
媒体数据，保证了内容自组织的动态灵活性，提供了更好的跨层优化。
媒体数据
媒体资源1 媒体资源2
通用封装单元
（非时序）
信
令
信
息
传输信令
传输控制信息2
传输信令
传输控制信息1
消费信令
服务描述信息
SMT
数据包
通用封装单元
N
（时序）
通用封装单元2
（时序）
通用封装单元1
（时序）
...
图2 数据模型
7.2 数据包
数据模型见图2。SMT 数据包是一个逻辑实体，可以看作一种服务，它主要由信令描述文件（详
见第9 章）和媒体资源组成。信令文件包括前向信令和反馈信令，可以分为两种类型：一种是消费信令，
T/AI 114—2024
6
一种是传输信令。消费信令主要包含该服务的描述信息，如媒体资源的构成、存放位置、类型、呈现策
略等；传输信令主要包含传输过程中的控制信息，如QoS 参数、缓冲区设置信息等。媒体资源也可分
为两种类型：一种是时序的媒体，如视音频内容；另一种是非时序的媒体，如文本、图片信息。为支持
异构网络条件下媒体资源的有效传输，以及传输过程中内容动态的配置，设计了SMT 媒体资源的CEU，
该单元应具有碎片化、自包含性、统一性等特点，从而支持内容动态组织和传输动态适配的需求。
7.3 媒体资源
一个媒体资源指的是建立多媒体呈现所用到的任意多媒体数据，是封装了编码媒体数据（如附录C
中的媒体类型）且具有相同媒体资源标识符的内容碎片的逻辑集合，其数据结构见图3。内容碎片命名
为通用封装单元（CEU），其包含的编码媒体数据可以是时序的，也可以是非时序的。时序数据是指有
内在时间轴的编码媒体数据，要求数据单元在指定时间同步解码并呈现。相对的，非时序数据指的是在
解码并呈现媒体内容时，没有内在时间轴的数据类型。也就是说，非时序数据中每个数据单元的解码及
呈现不必和该数据中的其他数据单元相互依赖。
同一媒体资源中，包含时序数据的CEU 之间在呈现时间上不能有任何重叠。
一个独立媒体资源的媒体数据类型可以是音频、视频或者网页等。Edit_list 定义描述多媒体文件与
不同版本的关联内容的映射关系，并标注出该Edit_list 包含的媒体数据单元的标识号。属于同一媒体资
源的不同Edit_list 层级可以包含完全不同的媒体数据单元，也可含有相同的媒体数据单元。Edit_list 需
要信令的支持，相关信令见MP 表的MUR_descriptor。
媒体资源
CEU #1 CEU #2 CEU #3 CEU #4 CEU #N-2 CEU #N-1 CEU #N
CEU #1 CEU #3 CEU #4 CEU #N-2 CEU #N
CEU #2 CEU #4 CEU #N-1
Edit_list 1
Edit_list 2
图3 媒体资源的数据构成
7.4 CEU
7.4.1 概述
CEU 是一个根据7.4.2 规则产生的符合ISO BMFF 的文件。Asset 标识、CEU 序列号以及相关信息
由‘cceu’ 盒子提供，以明确地标识出封装进CEU 文件中的媒体数据。‘moov’盒子包含所有编码器配置
信息，以解码和呈现媒体数据。
时序媒体数据作为ISO BMFF 的轨道存储，CEU 中允许单媒体轨道。非时序媒体用于ISO BMFF
的元数据的部分存储。图4 描绘了两个SMT 封装的例子，一个是时序媒体，另一个是非时序媒体。对
于封包化的CEU 传送，SMT 提示轨道提供将封装的CEU 转化成SMTP 负载和SMTP 包的信息。
T/AI 114—2024
7
图
4 CEU封装结构
7.4.2 CEU标签定义
本条定义的标签‘ceuf’(CEU file)确定了遵从CEU封装规则的文件。‘ceuf’标签需要‘isom’标签的支持。对其他如 ‘dash’标签（参见ISO/IEC 23009-1）的支持也可以另外说明。
一个CEU文件由一组使CEU自包含的元数据盒子组成。一个CEU文件应包含一个‘ftyp’，‘cceu’， ‘moov’盒子，一个可选‘sidx’盒子，以上所有都是CEU的元数据一部分。其他盒子也被允许，但如果分析程序不识别它们则会被忽略掉。
‘moov’盒子应最多包含一条媒体轨道，且可以包含用于标识传输格式中媒体最小分割单元的SMT提示轨道。‘moov’盒子中的轨道应不包含媒体帧以保证开销较小（就是说‘stts’，‘stsc’和‘stco’盒子中的entry_count应被设成0）。存储时序媒体数据CEU的文件中，‘moov’盒子应包含‘mvex’盒子，以指示使用了moof盒子结构。‘mvex’盒子也设定了以后moof盒子的轨道和样本的默认值。
此外，一个‘cceu’盒子应出现于文件级别，且应用如下规则，决定多个盒子的顺序：
a)
如果出现，‘cceu’盒子应紧跟‘ftyp’盒子放置其后；
b)
对于时序媒体数据，零个或更多‘sidx’盒子可以在文件中出现。如果出现，它们应索引构成当前CEU的moof盒子。
除了盒子顺序，如下限制也应用于‘ceuf’标签：
c)
文件中独立媒体轨道的最大数量为1（如，空的‘tref’盒子）。并且，非空‘tref’盒子的轨道（如提示轨道）也可用；
d)
对时序媒体数据，文件应至少包含一个moof盒子;
e)
对非时序媒体数据，‘meta’盒子应出现于文件级别且应包含CEU的非时序媒体元；
f)
如果出现，编辑列表盒子（‘elst’）应仅提供初始偏移；
g)
样本数据序列应以解码顺序放置于‘mdat’盒子，并且两者间无任何其他数据；
T/AI 114—2024
8
h)
任何样本辅助数据，如‘saio’和‘saiz’描述，应放置在‘mdat’盒子开始，所有样本数据之前；
i)
任何提示数据应放置于‘mdat’样本数据之后（或者样本数据之后的另一个mdat），以使传输前后不改变样本偏移。
‘tfdt’盒子应在每个moof盒子的‘traf’盒子内部，以提供该片段按照解码顺序第一个样本的解码时间。
如果任何‘elst’盒子可用，则它指示的偏移应适用于该CEU中依照呈现顺序的第一个样本的合成时间，以及任何呈现信息提供的呈现时间。
时序媒体数据作为ISO BMFF的一条轨道存储，被‘moov’和‘moof’盒子索引，支持反相兼容。SMT提示轨道指导SMT发送实体将封装的CEU转化成封包化的媒体流以采用诸如SMT的传输协议来传送。
非时序媒体数据作为元数据项目存储在‘meta’盒子里面。‘meta’盒子应出现在文件层级。每个非时序媒体数据文件应作为单独项目分别存储在‘meta’盒子里。非时序媒体的进入点应被标记为‘meta’盒子的主要项目。（参见14496-12）
7.4.3 CEU盒子
7.4.3.1 概述
通用封装单元(‘cceu’)盒子包含下列属性：
——盒子类型：‘cceu’
——容器：文件
——强制性：是
——数量：一或多个
通用封装单元(‘cceu’)盒子包含了当前CEU所属Asset的Asset标识和当前CEU的其他属性信息。Asset标识可全局性无歧义地标识Asset。CEU信息包含该CEU在Asset中的序号以及相关属性信息。
7.4.3.2 语法
aligned(8) class CEUBox
extends FullBox(‘cceu’, version, 0){
unsigned int(1) is_complete;
unsigned int(7) reserved;
unsigned int(32) ceu_sequence_number;
AssetIdentifierBox();
}
aligned(8) class AssetIdentifierBox {
unsigned int(32) asset_id_scheme;
unsigned int(32) asset_id_length;
unsigned int(8) asset_id_value[asset_id_length];
}
7.4.3.3 语义
is_complete：指示该CEU是否包含了MFU结构中描述的所有MFU。
ceu_sequence_number：当前CEU的序列号。Asset中的第一个CEU序列号为0，之后的CEU序列
T/AI 114—2024
9
号依次递增。此序列号在一个媒体资源中是唯一的。
asset_id_scheme：区分用来表示Asset ID的策略，决定了asset_id_value的类型。有效的策略见表1。
表
1 asset_id_scheme取值列表
取值
描述
“UUID”
UUID (IETF RFC 4122中定义的通用唯一标识符)
“URI”
URI (统一资源标识符)
asset_id_length：asset_id_value的长度。
asset_id_value：即媒体资源的标识符。其取值格式依赖于asset_id_scheme的类型。
7.4.4 SMT提示轨道
7.4.4.1 概述
出于传送的目的，SMT提示轨道为SMT发送实体提供将CEU分解(或分割)为传输格式中媒体最小分割单元的信息。该最小分割单元是媒体已知的，且被用来搭建SMTP的负载，即CEU中的媒体数据在传送时被SMT发送实体提取进SMTP负载。
SMT提示轨道也提供了从SMTP负载中提取和重建CEU的信息。SMTP负载可以包含CEU元数据、分片元数据、或是一个或多个传输格式中的最小分割单元。CEU元数据可以包含‘ftyp’, ‘sidx’, ‘cceu’, 和‘moov’盒子。
7.4.4.2 提示轨道样本属性
7.4.4.2.1 语法
aligned(8) class SMTHintSampleEntry() extends SampleEntry(‘smth’) {
unsigned int(16) hinttrackversion = 1;
unsigned int(16) highestcompatibleversion = 1;
unsigned int(16) packet_id;
unsigned int(1) is_fragment;
unsigned int(1) is_timed;
unsigned int(6) reserved;
}
7.4.4.2.2 语义
packet_id：指示该提示轨道应用于哪一个Asset的唯一标识符。
is_fragment：指示CEU是否切分为MFU的标识。若该标识位置‘0’，该提示轨道应用于完整的CEU，即每个轨道片段（track fragment）对应于一个媒体片段；否则，每个提示样本应用于单个MFU。
is_timed：指示该轨道提示的媒体数据是否是时序的。
7.4.4.3 提示轨道样本格式
7.4.4.3.1 定义
T/AI 114—2024
10
每个媒体样本被划分为一个或多个MFU。每个SMT提示轨道样本对应一个或多个MFU。
7.4.4.3.2 概述
aligned(8) class SMTHSample {
unsigned int(32) sequence_number;
if (is_timed) {
signed int(8) trackrefindex;
unsigned int(32) movie_fragment_sequence_number;
unsigned int(32) samplenumber;
unsigned int(8) priority;
unsigned int(8) dependency_counter;
unsigned int(32) offset;
unsigned int(32) length;
}
else {
unsigned int(16) item_ID;
}
}
7.4.4.3.3 语义
sequence_number：指示该MFU在CEU中序列号的整数值。CEU中序列号的断续是允许的，用于指示特定MFUs（其序列号在序列中缺失）在CEU组包后未被处理。由下层网络实体完成传送和缓冲是处理MFU的一个例子。
trackrefindex：指示所描述的媒体对应的trackID。
movie_fragment_sequence_numbe：指示该MFU中媒体数据所属媒体片段的序列号。
samplenumber：指示该MFU提取自媒体样本的编号。样本编号n指向当前媒体片段累计媒体样本中的第n个。媒体样本中第一个样本的样本编号置为‘1’。
priority：指示CEU中该MFU相对于其它MFU的优先级。
dependency_counter：指示依赖于该MFU解码的MFU的个数。该字段的值等于按sequence_number排列的可能无法正确解码的后续MFU的个数。例如，该字段的值为n，则代表若无此MFU，后续有n个MFU可能无法正确解码。
offset：指示该MFU中媒体数据的偏移。偏移基准为包含‘mdat’盒的开始。MFU应放置在偏移指示的位置。
length：指示该MFU中数据的长度，以字节为单位。
item_ID：指示对于非时序媒体数据，这是该MFU包含该项目的标识。
8 数据传输
8.1 概述
SMT负载格式被定义为对包内容封包的通用负载格式。SMT负载格式对用于编码媒体数据的特定编解码器不可知，因此任何封装成CEU的媒体数据可被封包为SMTP负载，其支持媒体数据流传输的应
T/AI 114—2024
11
用层传输协议。SMT负载可用于RTP协议、SMT协议以及其它传输协议。SMT负载亦可用于封包信令消息。
SMT协议定义应用层传输协议，支持基于数据包异构网络（包括互联网环境）中数据包流传输。SMT协议提供包传输的必要特性，例如使不同媒体资源通过一个MP传输的协议级复用，以及独立于呈现时间的传输时间模型以适应大范围网络抖动。
8.2 传输模型
SMT传输模型能够解决多方面问题，如不同网络通道QoS参数各异情况下如何保证数据的可靠传输，异构网络条件下如何设计终端缓存模型使多源媒体数据同步呈现，以及当网络条件不佳时提供基于数据重要等级的保护机制差异化等。
为支持SMT传输需求，提出图5的传输模型。SMT信令文件和传输包均根据媒体服务逻辑包进行组织，媒体组织和传输都与媒体服务相关，有利于根据不同服务类型差异化实现媒体内容组织和传输的自适应性。此外，SMT设计假设接收缓存模型（见附录A），用于在固定的端到端时延和有限内存缓冲需求的情况下进行智能媒体高效传输。
SMT逻辑包可以序列化为SMT文件，支持媒体文件式的存储、传输和下载；也可以打包为SMT传输包，以支持媒体的流化传输。由于文件格式和传输包格式内容上的高相关性，SMT支持两者的便捷转换，便于中继转发，同时传输模型也可以高效响应服务内容的动态配置。传输过程中服务描述和传输控制等信令文件可以采用与媒体内容不同的传输模式，既能满足带外传输需求，又能对信令文件加以更高等级的保护措施。
媒体CEU的碎片化、自包含性也决定了SMT传输模型能够应对传输过程中的包错误问题，实现弹性容错和错误隐藏，支持接收端快速恢复错误。每个CEU及其切片单元都被唯一标识，头部信息与信令消息相结合，指定数据范围、优先级、QoS要求、保护方式、呈现时间等不同层级的参数设置，对于媒体内容的分级、异构、多通道、可靠性传输有重要参考意义。
T/AI 114—2024
12
SMT
媒体
数据
资源1 资源2
通用封装单元
（非时序）
信令
信息
传输信令
传输控制信息2
传输信令
传输控制信息1
消费信令
服务描述信息
SMT
逻辑
包
序列化
服务描述传输控制1 通用封装单元1 通用封装单元2 ... 通用封装单元N 传输控制2 通用封装单元
SMT文件
打包化
包
头部
负载
头部
服务
描述
SMT传输包
包
头部
负载
头部
传输控
制1
包
头部
负载
头部
切片单
元1
切片单
元2
...
切片
单元M
完整或部分通用封装单元
......
通用封装单元N
（时序）
通用封装单元2
（时序）
通用封装单元1
（时序）
...
图5 传输模型
8.3 传输协议
8.3.1 基于封装结构的最小分割单元
MFU与CEU的结构关系见图6和图7。包含时序媒体的一个媒体最小分割单元是媒体样本或子样本，
而由一个‘moof’盒子和一个‘mdat’盒子构成的每个媒体片段（movie fragment）可以包含一个或多个媒体
样本（media sample）。包含非时序媒体的一个MFU是一个项（item）。
每个MFU由一个头文件和相关联的媒体数据组成。MFU头应是MFU提示样本的一个拷贝，媒体数
据应是该MFU提示样本索引的媒体数据的拷贝。MFU的提取与重建由SMT提示轨道负责，见7.4.4。
MFU在SMTP包内的SMTP负载中传送。
T/AI 114—2024
13
ftyp cceu moov moof
movie fragment
CEU
metadata
fragment
metadata
MFU MFU ... MFU ... MFU MFU ... MFU
Sample Sample ... Sample
mdat moof
movie fragment
fragment
metadata
MFU MFU ... MFU ... MFU MFU ... MFU
Sample Sample ... Sample
mdat
图6 时序媒体中CEU 与MFU 关系
SMTP包头CEU包头DU包头DU负载DU包头DU负载...
图7 非时序媒体中CEU 与MFU 关系
8.3.2 SMTP 包
8.3.2.1 概述
SMT 协议为高效、可靠包传输的应用层协议，适用于时序与非时序媒体数据的传输。该协议支持
若干增强特性，例如媒体多路复用与网络抖动计算。设计这些特性是为了更高效地传送不同编码类型的
媒体数据内容。SMT 协议可运行于现行的网络协议之上，如UDP 和IP。
SMT 协议支持不同媒体数据的复用，例如，来自不同媒体资源的多个CEU 复用到一个SMTP 流上。
在不引入长延迟和大缓存的情况下，SMT 协议按照接收实体媒体数据的消费顺序传送多种类型的数据
以实现不同类型媒体数据之间同步。SMT 协议也支持在单一数据流内，媒体数据和信令消息的复用。
一个SMTP 包内仅能包含一个SMTP 负载。SMTP 包格式不支持多SMTP 负载的聚合和单SMTP 负载
的切分。
SMT协议也提供了计算和消除底层传输网络所引入抖动的方法，以实现数据流的恒定延迟。通过
使用包头的时间戳字段，可以在不获取额外信息的情况下精确地计算抖动。
8.3.2.2 SMTP 包结构
图8 描述了V=0 时SMTP 包的结构。
T/AI 114—2024
14
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| V=0 | C | FEC | r | X | R | RES | type | packet_id |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| timestamp |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| packet_sequence_number |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| packet_counter |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| header_extension
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| payload data
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| source_FEC_payload_ID |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
图8 SMTP 包结构（V=0）
图9 描述了V=1 时SMTP 包的结构，该版本定义了简化的SMTP 数据包结构，以实现灵活多样的
信息交互。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| V=1 | C | FEC | T | X | R | P | F | type | packet_id |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| timestamp |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| packet_sequence_number |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| packet_counter |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| header_extension
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| payload data
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| source_FEC_payload_ID |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
图9 SMTP 包结构（V=1）
8.3.2.3 语义
version（V：2 bits）：标识SMT 协议版本号。
packet_counter_flag（C：1 bit）：该字段置‘1’则使用packet_counter 字段。
FEC_type（FEC：2 bits）：标识用于纠错保护SMTP 包的FEC 方案。该字段有效值见表2。
T/AI 114—2024
15
表
2 FEC_type
值
描述
0
无AL-FEC保护的SMTP包
1
有AL-FEC保护（FEC数据包）的SMTP包
2
带修复符号的SMTP包（FEC修复包）
3
保留以后使用
reserved（v=0，r：1 bit）：保留字段。
timestamp_flag（v=1，T：1 bit）：该字段置‘1’则使用timestamp字段。
extension_flag（X：1 bit）：该字段置‘1’则使用header_extension字段。
RAP_flag（R：1 bit）：该字段置‘1’时，表示该SMTP包负载包含一个该数据类型数据流的随机访问点（RAP）。此标志位的准确含义由数据类型本身定义。当数据单元类型为CEU元数据或媒体片段元数据时，RAP_flag字段需置‘1’。当数据单元类型为时序CEU中包含同步信息的MFU，或非时序CEU中包含同步信息的主要项时，RAP_flag字段需置‘1’。
reserved（v=0，RES:2 bit）：保留字段。
packet_id_flag（v=1，P:1 bit）：该字段置‘1’则使用packet_id字段。
fragmentation_flag（v=1，F:1 bit）：该字段置‘1’则使用packet_sequence_number字段。
type（6bits）：标识负载数据类型。负载类型值见表3。
表
3 数据类型与数据单元定义
值
数据类型
数据单元定义
0x00
CEU
媒体感知的CEU片段
0x01
信令消息
一条或多条信令消息或信令消息的片段
0x02~0x03
为其它数据类型保留
0x04 ~ 0x3F
私有用途保留
packet_id（16bits）：该字段为整数值，用于区分不同媒体资源。该字段数值源自该包所属媒体资源的asset_id字段。packet_id与asset_id间的映射由信令消息中的MP表标识。信令消息与FEC修复流分配不同的值。整个传输会话周期同一SMT发送实体所有SMT流的packet_id值是唯一的。对AL-FEC，packet_id与FEC修复流间的映射由AL-FEC信息提供。
timestamp（32bits）：基于UTC时间标识SMTP包传输瞬时时间。此格式定义于IETF RFC5905条款6，NTP第四版的‘短格式’。该时间戳表示SMTP包第一个字节的发送时间。SMT发送实体要求能够提供与UTC同步的准确时间信息。
packet_sequence_number（32bits）：该字段为整数值，用于区分包含相同packet_id的不同包。该字段初始为任意值，每收到一个SMTP包该字段的值加1，超出最大值后返回0。
packet_counter（32bits）：该字段为整数值，用于计数SMTP包。每发送一个SMTP包该字段的值加1，不考虑packet_id值。该字段初始为任意值，超出最大值后返回0。
header_extension：包头扩展机制允许对负载格式进行适当的扩展，这使得要求负载格式头携带额外信息的应用和媒体类型成为可能。包头扩展机制被设计成可在不影响SMTP负载正确处理的情况下丢弃。包头扩展格式见图10。该协议不定义任何具体的包头扩展。
T/AI 114—2024
16
Source_FEC_payload_ID（32bits）：仅当‘FEC_type’字段置‘1’时使用该字段。‘FEC_type’字段置‘1’
时SMTP 包使用AL-FEC 保护，使用AL-FEC 保护后该字段应增加至SMTP。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| type | length |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| header__extension__value
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
图10 头部扩展结构
type（16bits）：后续头部扩展的唯一标识。
length（16 bits）：表示header_extension_value 字段长度（字节为单位）。
header_extension_value ：提供扩展信息。该协议不定义该字段格式。
8.3.3 SMTP 会话描述信息
SMTP 会话描述信息可通过不同方式传输至接收实体，以适应不同的配置环境。在加入SMTP 会话
前接收实体需要获知以下信息。
a) 目的地信息，在互联网环境中，目的地信息为网络地址与端口号；
b) 指示该会话为SMTP 会话；
c) 指示该会话为SMTP 会话；
d) SMTP 会话的开始与结束时间。
8.4 传输负载结构
8.4.1 概述
SMTP包负载是一种通用负载，使用SMT协议封包并携带SMT媒体数据。SMTP包负载可以是一个
或多个完整CEU或CEU片段，或者信令消息等。每一种负载类型都有着独立的传输数据单元以及针对该
类型负载的负载头。例如，SMTP负载携带CEU片段时CEU片段被视为一个数据单元。SMT协议能够整
合多个同类型数据单元到一个SMTP负载中，也能够将数据单元分割至多个SMTP包中。
8.4.2 CEU 模式
8.4.2.1 概述
通过SMT协议传输CEU，要求在SMT发送与接收实体分别配置封包与解包程序。封包程序将CEU
封包成一组被SMTP包携带的SMTP负载。SMTP负载格式支持SMTP负载分段传输，以使大容量负载可
以传输。SMTP负载格式也支持将多个SMTP负载的数据单元整合到一个SMTP负载中，以便于小容量数
据单元聚合传输。接收实体解包以恢复原始CEU数据。
8.4.2.2 CEU 模式下SMTP 负载头
CEU 模式下SMTP 负载头部结构见图11。
T/AI 114—2024
17
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| length | FT | T | f_i | A | frag__counter |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| CEU_sequence_number |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| DU_length | DU_Header
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| DU_ payload
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
图11 CEU 模式下SMTP 负载头部结构
对携带MFU 的负载，数据单元头部由字段“T”指示其为时序媒体或非时序媒体。时序媒体数据单
元头部结构见图12，非时序媒体数据单元头部结构见图13。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| movie_fragment_sequence_number |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| sample_number |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| offset |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| priority | dep_counter |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
图12 时序媒体数据单元头部
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| item_ID |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
图13 非时序媒体数据单元头部
8.4.2.3 语义
length（16bits）：除此字段外负载长度（单位为字节）。
CEU Fragment Type（FT：4bits）：该字段指示片段类型，有效值见表4。
表4 数据类型及数据单元定义
FT 描述 内容
0 CEU metadata 包含ftyp，mceu，moov 和其它出现在这之间的元数据盒子。
1 Movie fragment metadata 包含moof 和除去所有媒体数据的mdat 盒子。
2 MFU 包含时序媒体数据的样本或子样本，或非时序媒体数据的一个item。
3 ~ 15 私有用途保留 保留。
T/AI 114—2024
18
Timed_Flag（T：1bit）：指示数据单元是时序（该字段置‘1’）媒体或非时序（该字段置‘0’）媒体。
Fragmentation_Indicator（f_i：2bits）：指示负载中数据单元的分片信息。有效值见表5。当此字段置‘00’时有可能设置aggregation_flag字段。
表
5 数据单元指示值
值
描述
00
负载包含一或多个完整数据单元。
01
负载包含数据单元的第一个片段。
10
负载包含数据单元的中间片段。
11
负载包含数据单元的最后一个片段。
aggregation_flag（A：1bit）：该字段置‘1’表示负载中包含2个或以上数据单元。
fragment_counter（frag_count：8bits）：该字段指示此SMTP负载后包含同一数据单元片段的SMTP负载个数。当aggregation_flag字段置‘1’时该字段置‘0’。
CEU_sequnece_number（32bits）：CEU片段所属CEU的序号。
DU_length（16bits）：指示该字段后续数据长度。当aggregation_flag置‘0’时，该字段不呈现。当aggregation_flag置‘1’时，该字段呈现次数与整合进负载中的数据单元个数相同，并出现在每个数据单元前面。
DU_header：数据单元头部，仅当FT为2，也即MFU有效时存在，且时序媒体与非时序媒体对应的语义也不同。
DU_payload：数据单元负载。
moive_fragment_sequence_number（32bits）：该MFU媒体数据所属媒体片段的顺序编号。
sample_number（32bits）：该MFU媒体数据所属媒体样本的顺序编号。
offset（32bits）：MFU媒体数据在所属媒体样本内的偏移。
priority（priority：8bits）：相同CEU中MFU媒体数据间的优先级。Priority的值域为‘0’到‘255’，数值越大优先级越高。
dependency_counter（dep_counter：8bits）：指示依赖该MFU媒体数据来进行媒体处理的数据单元个数。
Item_ID（32bits）：作为MFU一部分的item标识符。
8.4.3 信令消息模式
8.4.3.1 概述
SMTP信令消息模式用于定义信令消息的传输。信令消息可用其它格式编码，如二进制格式或XML格式。因此在传输层能够快速访问与过滤信令消息很重要，且在过滤时希望尽量避免解析信令消息。
信令消息负载格式提供分块与整合功能以支持高效封包。
8.4.3.2 信令消息模式下SMTP负载头
信令消息模式下SMTP负载头部结构见图14。
T/AI 114—2024
19
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| f_i | res | H | A | frag__counter | MSG__length (16+16*H) |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
| MSG_ payload |
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
图14 信令消息模式下SMTP 负载头部结构
8.4.3.3 语义
Fragmentation_Indicator（f_i：2 bits）：指示SMTP负载中信令消息的分片信息。有效值见表6。
表6 片段指示值
值 描述
00 负载包含一或多个完整信令消息。
01 负载包含信令消息的第一个片段。
10 负载包含非第一个，也非最后一个部分的信令消息片段。
11 负载包含信令消息的最后一个片段。
RES（res：4bits）：该字段所有位需置‘0’，保留供以后使用。
H（1bits）：表示指示信令消息长度的附加16位是否使用。
aggregation_flag（A：1bit）：该字段置‘1’表示负载中包含2个或以上信令消息。
fragmentation_counter（frag_counter：8bits）：该字段表示此信令消息片段后包含同一信令消息片
段的SMTP负载个数。当aggregation_flag字段置‘1’时该字段置‘0’。
MSG_length（16+16*Hbits）：该字段表示此字段后信令消息长度。当aggregation_flag置‘1’时，该
字段出现次数与整合进负载中的信令消息个数相同，并出现在每个信令消息前面。
MSG_playload：信令消息负载。
8.5 基于负载结构的传输操作
8.5.1 一般操作
一个SMTP会话由一个SMTP传送流组成。SMTP传送流的定义是：来自于一个或多个SMT发送实体，
被传送到同一个目的地的包流。在IP情况下，包流的目的地是网络地址和端口。
一个单独的数据包可能需要一个或多个SMTP包流进行传输。
一个单独的SMTP传送流中的数据可来自多个数据包。
一个SMTP传送流可携带多个媒体资源，在SMTP会话中每一个媒体资源都与一个唯一的PID对应。
SMTP提供一个最优化的流格式（CEU格式）。媒体资源作为一系列相关媒体数据被定义为媒体数据流
进行传输。媒体数据可能是一个CEU，文件或者信令消息。
SMTP 包子流是一个SMTP包流的包的子集，这些子流共享同一个PID。
该媒体数据流作为SMTP子流进行传输。
CEU模式支持CEU的封包流化传输。
SMTP适用于单播和多播。为了保证多播/广播环境的可靠性，SMTP主要依靠FEC而不是将数据包
重发。
T/AI 114—2024
20
在加入SMTP会话前，SMT接收实体需获得足够信息以确保被传送数据的接收。最少需要信息见
7.3.3。
SMTP需要SMT接收实体能够识别并解复用属于特定媒体数据流的SMTP包。
8.5.2 传输CEU
8.5.2.1 概述
CEU模式在发送实体和接收实体间传送CEU。
8.5.2.2 SMT 发送实体操作
8.5.2.2.1 时序媒体数据
CEU分包后应携带CEU元数据，或媒体片段元数据，或MFU。产生的包不能够携带超过两种不同
类型的数据单元。CEU元数据由‘ftyp’盒子，‘cceu’盒子，‘moov’盒子以及其他适用于CEU的盒子组成。
媒体片段元数据由‘moof’盒子和‘mdat’盒子头部组成（除了媒体数据）。携带媒体片段元数据的SMTP
负载的FT字段置0x01。‘mdat’盒子中的媒体数据分成一个或多个MFU。携带MFU的SMTP负载的FT字段
置0x02。
图15描述了CEU与时序媒体负载的关系。
ftyp cceu moov moof moov moof moov
CEU metadata
Fragment
metadata
MFU MFU MFU
Fragment
metadata
MFU MFU MFU
图15 时序媒体的有效负载产生
8.5.2.2.2 非时序媒体数据
CEU分包后应携带CEU元数据或MFU。CEU元数据由‘ftyp’盒子，‘moov’盒子，‘meta’盒子以及其他
适用于CEU的盒子组成。携带CEU元数据的SMTP负载的FT字段置0x01。每一个MFU数据单元包括一个
非时序媒体的item。携带MFU的SMTP负载的FT字段置0x02。
图16描述了CEU与非时序媒体负载的关系。
ftyp cceu moov
CEU metadata
moof
MFU
item2
MFU
item1
图16 非时序媒体有效负载的产生
T/AI 114—2024
21
8.5.2.3 SMT接收实体操作
在SMT接收实体上执行解包，重组CEU。根据不同应用场景，可选择但不限于如下几种解包模式：
——CEU模式：在CEU模式下，接收实体重组完整的CEU后再传输给应用程序。该模式适用于时间要求不严格的应用场景，例如CEU呈现时间充分滞后于接收时间；
——媒体片段模式：在媒体片段模式下，接收实体重组完整的媒体片段后再传输给应用程序。该模式适用于延时敏感的应用场景，其中延时时间受限但足够恢复一个完整的媒体片段；
——数据单元模式：在数据单元模式中，接收实体解包后立即传输给应用程序。该模式适用于延时非常低的应用场景。该模式支持数据单元的乱序传输。
9 信令
9.1 概述
信令功能区中包含了一整套消息格式，传达用于传输和消费SMT数据包的必要信令消息，分别称为传输信令和消费信令。本规范详细介绍了承载信令表、描述符或者传输相关信息的消息格式。信令表包含特定信令消息的元素与属性集，也可以包含描述符来携带更多细节信息。
9.2 信令消息格式
9.2.1 概述
SMT信令消息的一般格式包含三个通用字段、一个特殊字段以及一个消息负载。消息负载用来承载信令消息。
一般信令消息格式的语法和语义分别在9.2.2和9.2.3中定义。
9.2.2 语法
表7列出了SMTP信令消息的一般格式的语法。
表
7 信令消息一般格式的语法
语法
值
位数
signalling_message () {
message_id
version
if(message_id!=PA_message){
length
}
else{
length
}
extension
message_payload {
}
}
16
8
16
32
9.2.3 语义
message_id：指示信令消息的标识符。
T/AI 114—2024
22
version：指示信令消息的版本。SMTP发送和接收实体能够验证一个接收到的消息是否有新版本。
新消息版本号值较大，SMT实体可以检查接收到的消息的版本号，确定收到的消息是否为最新版本。
length：指示信令消息的长度，PA消息占4字节，MPT message占2字节。
extension：指示信令消息中需要扩展的信息。该字段的内容和长度由信令消息规定。
message_payload：指示信令消息的有效负载。该字段的格式能够被message_id字段的值识别。
9.3 媒体数据包消费信令消息
9.3.1 概述
用于媒体数据包消费的信令消息可能包含信令表，其包含一组特定信令消息的元素和属性。各个信
令表携带着媒体数据包的相关信息，比如服务接入、内部媒体资源属性、呈现信息描述等。信令消息与
信令表之间的关系见图17。
PA消息
PA表
媒体呈现层信息表
MP表
图17 信令消息与信令表之间的关系
由此可知，一个PA消息应当包含一个PA表、一个MP表和一个媒体呈现层信息表。
9.3.2 PA 消息
9.3.2.1 概述
一条PA消息包含一个PA表，该PA表包含所有其他包的信令表。一条PA消息也包含一个MP表，用
来传输处理媒体数据包的其他消息。
SMTP 接收实体应当在处理其他信令消息之前处理PA消息。
9.3.2.2 语法
表8定义了PA消息的语法。
表8 PA 消息语法
语法 值 位数
PA_message () {
message_id
version
length
extension