YD/T 6741.1-2026

直播场景：电商直播、秀场直播、游戏直播、体育直播、活动直播等，包含上行推流和下行拉流两个子场景； b) 点播场景：短视频、家庭影院、网络综艺、网络剧等，包含上传和下载两个子场景； c) 实时通信场景：视频会议、远程监控、在线教育、即时通讯等，包含终端与终端、终端与服务端以及服务端和服务端连接三个子场景。 本文件规定的面向多场景流媒体服务协议用于两个网络节点的相互通信的环节。特别地，服务端和客户端在本协议中为逻辑概念，并不代表特定物理机器，客户端代表承担客户端逻辑的网络节点，服务端代表承担服务端逻辑的网络节点。例如，两个网络节点均可代表终端、边缘服务器和中继服务器，两个网络节点互相对等，均可承担服务端或客户端的作用，如图1 所示。 std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 3 图1 面向多场景的流媒体服务协议作用范围示意图当客户端与服务端通信时，面向多场景流媒体服务协议都先由客户端发起连接建立请求，与服务端建立协议通信，并基于本协议传输应用层所需的信令、媒体数据、自定义信息等内容。 当任意两台服务端或终端之间直连通信时，其中一台主动发起连接建立请求、建立协议通信，并基于本协议传输必要的信息。

6 面向多场景的流媒体服务协议概览 6。

1 协议总体框架如图2 所示，面向多场景的流媒体服务协议分为流媒体应用控制和流媒体传输控制两部分。流媒体应用控制为使用者提供统一的流媒体应用控制会话和差异化的流媒体应用控制算法。 流媒体传输控制则为流媒体应用控制提供通用且可靠的传输能力。不同应用场景的使用者均通过统一的流媒体应用控制会话接入本协议。 std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 4 图2 面向多场景的流媒体服务协议总体框架 6。

2 流媒体应用控制流媒体应用控制包含流媒体应用控制会话和流媒体应用控制算法。 流媒体应用控制会话为不同应用场景的使用者提供了统一的接入方式。使用者在不同应用场景中， 均需遵循创建流媒体应用控制会话、传输流媒体数据和关闭流媒体应用控制会话的流程来使用本协议。 流媒体应用控制算法则为不同应用场景提供了差异化的体验优化算法。流媒体应用控制会话根据传入的应用场景类型，创建对应的流媒体应用控制算法。本协议针对直播场景、点播场景和实时通信场景分别设计了对应的流媒体应用控制算法。 在直播场景，流媒体应用控制算法包含丢帧、流控、多码率和智能启播等体验优化算法。直播场景下的流媒体应用控制算法详见YD/T BBBB-BBBB。 在点播场景，流媒体应用控制算法包含优先级控制、缓存管理、多码率和自适应编码等体验优化算法。点播场景下的流媒体应用控制算法详见YD/T CCCC-CCCC。 在实时通信场景，流媒体应用控制算法包含丢帧、带宽分配、流控和多码率等体验优化算法，实时通信场景下的流媒体应用控制算法详见YD/T AAAA-AAAA。

3 流媒体传输控制流媒体传输控制包含流媒体传输控制会话和流媒体传输控制算法。 流媒体传输控制会话为流媒体应用控制会话在不同场景中提供了统一的接入方式，以实现流媒体传输控制，并具备流媒体封装与解封装能力，从而降低传输负载。 std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 5 此外，流媒体传输控制会话还规定了流媒体传输时数据帧的标准格式，以支持流媒体数据帧的发送、 定界与恢复。同时，流媒体传输控制会话提供了音频、视频和数据流的多路复用机制，有效避免队头阻塞问题。最后，考虑到本协议底层依赖于计算机内核的TCP协议或UDP协议，流媒体传输控制会话还包含传输层协议优选模块，以实时决策流媒体服务的传输层协议，从而最大化传输质量。 流媒体传输控制算法根据传输层的TCP或UDP协议提供差异化的传输质量优化算法。 针对TCP协议，本协议支持了TLS1.3加密/解密技术与连接复用技术以提升安全性与传输效率。 针对UDP协议，本协议在TLS1.3加密/解密技术与连接复用技术基础上，还提供了0-RTT握手模块以减少启播延迟，提供了ACK/NACK，ARQ，FEC，CC及流量整形等算法以提升传输质量。 流媒体传输控制机制及流媒体传输控制算法详见YD/T AAAA-AAAA。

7 面向多场景的流媒体服务协议接入方式 7。

1 基本流程不同的应用场景都通过统一的流媒体应用控制会话接入本协议，其流程分为创建流媒体应用控制会话、传输流媒体数据和关闭流媒体应用控制会话三个阶段。特别地，流媒体应用控制会话会自动创建相应的流媒体传输控制会话，流媒体传输控制会话对用户透明，用户在接入本协议时无需管理流媒体传输控制会话。 用户首先通过创建流媒体应用控制会话与服务端建立连接，并协商所需的配置和参数。连接建立后， 用户利用该会话传输流媒体数据，流媒体应用控制会话中的应用控制算法根据网络状况和应用需求进行动态调整，以优化流媒体的传输质量和延迟。流媒体服务结束后，用户通过关闭流媒体应用控制会话来完成整个流程。

2 创建流媒体应用控制会话 7。

1 概述创建流媒体应用控制会话主要包括客户端创建和服务端创建两种方式。 在客户端创建方式中，客户端主动创建流媒体应用控制会话。在服务端创建方式中，服务端创建流媒体服务协议侦听器，当收到来自客户端的连接建立请求时，服务端被动创建流媒体应用控制会话。在两台服务器直连的场景，主动发起连接的一端使用客户端创建方式，另一端使用服务端创建方式。

2 客户端创建方式客户端流媒体应用控制会话由客户端主动创建。创建客户端流媒体应用控制会话时需要提供表1所示信息。 表1 流媒体应用控制会话输入信息概览项目解释服务端IP 与端口用于标识目标服务端的地址主机名称用于TLS 协议识别主机证书，详见SNI 协议流媒体服务协议元信息描述了流媒体应用控制会话的基本属性，包含应用场景、媒体格式、 传输模式等。不同应用场景所需要的元信息格式各不相同，具体的格式规范详见《面向多场景的流媒体服务协议第3 部分：直播场景》、《面向多场景的流媒体服务协议第4 部分：点播场景》、 《面向多场景的流媒体服务协议第5 部分：实时通信场景》 std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 6 流媒体服务协议接入配置用于配置流媒体应用控制会话的传输能力，比如指定拥塞控制算法的类型等，具体的格式规范详见7。

4 章节客户端流媒体应用控制会话有5 种工作状态，分别为： a) Initial 状态，客户端流媒体应用控制会话的初始状态； b) Connecting 状态，表示客户端流媒体应用控制会话正在和服务端建立网络连接； c) Ready 状态，表示TLS 协议使用了0-RTT 握手，此时客户端流媒体应用控制会话可以发送流媒体数据； d) Connected 状态，表示客户端流媒体应用控制会话与服务端成功建立连接，可以发送和接收流媒体数据； e) Closed 状态，表示客户端流媒体应用控制会话已关闭，详见7。

4 章节。 本协议使用TLS1。

3 提供的1-RTT 握手和0-RTT 握手两种握手机制。 使用1-RTT 握手时，客户端流媒体应用控制会话的初始状态为Initial 状态。开始建立连接后， 客户端流媒体应用控制会话切换至Connecting 状态。当TLS 握手完成后，客户端流媒体应用控制会话切换至Connected 状态。 当客户端与服务端非首次建立连接且存有对应的TLS PSK 信息时，可以使用0-RTT 握手。开始建立连接后，客户端流媒体应用控制会话先从Initial 状态切换至Connecting 状态。开始TLS 握手时， 客户端流媒体应用控制会话把TLS PSK 信息输入至TLS，获得用于加密的密钥并切换至Ready 状态。TLS 握手完成后，客户端流媒体应用控制会话切换至Connected 状态。 当客户端流媒体应用控制会话处于Ready 或Connected 状态后，即可传输流媒体数据，详见7。

3 章节。 客户端流媒体应用控制会话的状态流转如图3 所示，其中实线代表正常的创建流程，虚线代表主动关闭或异常引发的关闭流程。 图3 客户端流媒体应用控制会话状态流转图 7。

3 服务端创建方式服务端流媒体应用控制会话由流媒体服务协议侦听器创建。流媒体服务协议侦听器负责监听指定IP 和端口上的网络数据，当检测到有新的连接建立请求时则创建服务端流媒体应用控制会话。 std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 7 创建服务端流媒体应用控制会话需要提供流媒体服务协议元信息和接入配置，由客户端流媒体应用控制会话通过连接建立请求携带。服务端流媒体应用控制会话的创建具体流程详见YD/T BBBB-BBBB、 YD/T CCCC-CCCC、YD/T DDDD-DDDD。 服务端流媒体应用控制会话有2 种工作状态，分别为： a) Connected 状态，服务端流媒体应用控制会话的初始状态，此时可以发送和接收流媒体数据； b) Closed 状态，表示服务端流媒体应用控制会话已关闭，详见7。

4 章节。 创建服务端流媒体应用控制会话需要收到客户端流媒体应用控制会话的连接建立请求，此时TLS 握手已完成，因此服务端流媒体应用控制会话的初始状态为Connected。

4 流媒体服务协议接入配置流媒体服务协议接入配置是一个用于给各个算法模块设置参数的JSON文档，包括流媒体服务协议应用控制算法和传输控制算法，语义如表2所示。流媒体服务协议接入配置的示例见附录A。 表2 流媒体服务协议接入配置语义表元素或属性名称用法描述 @client_config 可选应用于客户端流媒体应用控制会话的流媒体服务协议算法配置。 @server_config 可选应用于服务端流媒体应用控制会话的流媒体服务协议算法配置。 client_config 和server_config 的取值都为流媒体服务协议算法配置，它是一个三层的JSON 结构，其语义如表3 所示。第一层为控制模块名称，第二层为算法模块名称，第三层为具体的算法配置名称，对于每一项基本配置，本协议支持数字、字符串、数组、布尔值四种基本数据类型，以指明具体配置内容。本系列标准定义了部分控制模块、算法模块及配置项的名称，具体的定义详见标准的第2、3、 4、5 部分。除了本系列标准已经定义的名称，使用者可以自定义配置名称进行扩展。 表3 流媒体服务协议算法配置语义 7。

3 传输流媒体数据 7。

1 基本流程当流媒体应用控制会话处于Ready或Connected状态后，即可传输流媒体数据。使用者可以通过该会话发布或订阅媒体流，并利用媒体流进行数据传输。 媒体流对应了一条可以实时生产和消费的数据流。特别地，本协议将发布媒体流的一方称为生产端，将订阅媒体流的一方称为消费端。外部使用者通过流媒体应用控制会话发布或订阅媒体流来进行数据的发送与接收，媒体流由唯一的URL 标识。不同的应用场景对媒体流的使用方式各不相同，比如在直 { "控制模块名称": { "算法模块名称": { "配置项名称": 数字类型｜字符串类型｜数组类型｜布尔类型 } } } std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 8 播拉流场景，客户端通过客户端流媒体应用控制会话主动订阅音视频媒体流，服务端流媒体应用控制会话收到订阅请求后通知服务端提供对应URL 的媒体流数据。 针对不同的流媒体应用场景，流媒体应用控制会话提供订阅、发布音频/视频/音视频/数据四种类型的媒体流进行数据发送与接收。在一个流媒体应用控制会话中，可以同时订阅或发布多条不同的媒体流，同一个流媒体应用控制会话中不同媒体流的读写过程彼此独立。

2 发布媒体流对于生产媒体数据的应用场景，例如直播推流以及点播上传等，生产端需要通过主动发布媒体流来上传数据，具体流程如下： a) 生产端通过本端流媒体应用控制会话发布媒体流，并指定以下信息： 1) 媒体流类型，有音频、视频、音视频和数据四种类型； 2) 媒体流URL，用于唯一标识该媒体流的资源定位符； 3) 可选的自定义数据，用于透传一些应用自定义数据。 b) 本端流媒体应用控制会话把媒体流发布请求传输至对端流媒体应用控制会话，对端流媒体应用控制会话通知外部使用者媒体流发布的事件，以及对应的URL、媒体流类型、自定义数据等； c) 媒体流发布后，生产端通过流媒体应用控制会话发送有序的流媒体二进制数据，流媒体应用控制会话根据流媒体服务协议元信息指定的媒体封装格式对内容进行解封装、处理并传输至对端流媒体应用控制会话，对端流媒体应用控制会话对内容进行封装并通知外部使用者该媒体流收到的新数据； d) 媒体流生产完成后，生产端需要主动关闭媒体流的发布，本端流媒体应用控制会话把关闭请求传输至对端流媒体应用控制会话，对端流媒体应用控制会话通知外部使用者媒体流被关闭的事件。 对端流媒体应用控制会话可以主动拒绝或关闭本端流媒体应用控制会话发布的媒体流，该关闭请求会被传输至本端流媒体应用控制会话并通知外部使用者媒体流发布被关闭的事件。 当生产端需要根据网络状况对媒体流进行自适应调整时，本端流媒体应用控制会话能够通过事件通知生产端预期的流控结果，包含期望码率、期望帧率等信息。

3 订阅媒体流对于消费媒体数据的应用场景，例如直播拉流和点播下载等，消费端需要通过主动订阅媒体流来接收数据，具体流程如下： a) 消费端通过本端流媒体应用控制会话订阅媒体流，并指定媒体流类型、媒体流URL 以及可选的自定义数据等信息； b) 本端流媒体应用控制会话把媒体流订阅请求传输至对端流媒体应用控制会话，对端流媒体应用控制会话通知外部使用者媒体流订阅的事件，以及对应的URL、媒体流类型、自定义数据等； c) 对端收到订阅事件后，根据URL 查找对应的媒体流，通过对端流媒体应用控制会话发送流媒体数据，本端流媒体应用控制会话对收到的数据进行封装并通知消费端该媒体流收到的新数据； d) 消费端完成媒体流的接收后，需要主动关闭媒体流的订阅，本端流媒体应用控制会话把关闭请求传输至对端流媒体应用控制会话，对端流媒体应用控制会话通知外部使用者媒体流结束订阅的事件。 对端流媒体应用控制会话可以主动拒绝或关闭本端流媒体应用控制会话订阅的媒体流，该关闭请求会被传输至本端流媒体应用控制会话并通知外部使用者媒体流订阅被关闭的事件。 std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 9 部分流媒体应用控制算法依赖消费端提供播放器的缓存信息来更好决策，例如智能丢帧、自适应流控等，消费端可以通过本端流媒体应用控制会话实时更新该媒体流对应的播放器状态信息，包含音频缓存时长、音频缓存字节数、视频缓存时长、视频缓存字节数、卡顿次数、卡顿时长等。

4 订阅自适应媒体流集合消费端可以通过订阅一组动态自适应的媒体流集合来启用自适应多码率算法。区别于单条媒体流的订阅，流媒体应用控制会话可能同时向外部使用者发送多条媒体流订阅事件，但同一时刻只会选择其中一条进行传输。其具体流程如下： a) 消费端通过本端流媒体应用控制会话订阅自适应媒体流集合，并指定媒体流类型、manifest 以及可选的自定义数据等信息。manifest 包含了多条媒体流的URL、码率以及分辨率等信息， 其格式取决于具体的自适应标准，详见DASH、LAS 等标准规范； b) 自适应多码率算法对manifest 进行解析，根据当前网络状态、播放器缓存等信息决策合适的媒体流并通知对端流媒体应用控制会话，对端流媒体应用控制会话通知外部使用者媒体流订阅的事件，以及对应的URL、媒体流类型、自定义数据等； c) 对端收到订阅事件后，根据URL 查找对应的媒体流，通过对端流媒体应用控制会话输入流媒体数据。对端流媒体应用控制会话可能会向外部使用者同时发送多条媒体流的订阅事件，但同一时刻只会选择其中一条进行传输，本端流媒体应用控制会话对收到的数据进行封装并通知消费端该自适应媒体流集合收到的新数据； d) 当媒体流发生切换时，本端流媒体应用控制会话需要通知消费者媒体流发生了切换的事件， 包含媒体流URL、PTS 时间戳等信息； e) 消费端完成媒体流的接收后，需要主动关闭自适应媒体流集合的订阅，本端流媒体应用控制会话把关闭请求传输至对端流媒体应用控制会话，对端流媒体应用控制会话通知外部使用者媒体流结束订阅的事件。 自适应多码率算法依赖消费端提供播放器的缓存信息来更好决策，消费端可以通过本端流媒体应用控制会话实时更新播放器状态信息，包含音频缓存时长、音频缓存字节数、视频缓存时长、视频缓存字节数、卡顿次数、卡顿时长等。

4 关闭流媒体应用控制会话流媒体服务结束后，使用者可以主动关闭本端流媒体应用控制会话，使其切换至Closed状态，本端流媒体应用控制会话同时会通过网络通知对端流媒体应用控制会话，使其切换至Closed状态。 流媒体应用控制会话发生错误时，会切换至Closed状态，并通过网络通知对端流媒体应用控制会话， 使其切换至Closed状态。 std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 10 附录 A (资料性) 面向多场景的流媒体服务协议接入配置示例 A。

1 面向多场景的流媒体服务协议接入配置示例以下是一个流媒体服务协议接入配置示例。 对于客户端流媒体应用控制会话，设置以下参数：在控制模块1 中，算法模块1 的数字参数1 设置为1.0，算法模块2 的字符串参数2 设置为“abc”；在控制模块2 中，算法模块3 的数组参数3 设置为[0, 1, 2, 3]。 对于服务端流媒体应用的控制会话，设置以下参数：在控制模块1 中，算法模块1 的数字参数1 设置为2.0；在控制模块2 中，算法模块3 的布尔参数3 设置为True。 表A。

1 流媒体服务协议接入配置示例 { "client_config": { "控制模块1": { "算法模块1": { "数字参数1": 1。

0 }, "算法模块2": { "字符串参数2": "abc" } }, "控制模块2": { "算法模块3": { "数组参数3": [0, 1, 2, 3] } } }, "server_config": { "控制模块1": { "算法模块1": { "数字参数1": 2.0 } }, "控制模块2": { "算法模块3": { "布尔参数3": True } } std.miit.go std.miit.go std.miit.go YD/T XXXX—XXXX 11 } } std.miit.go std.miit.go std.miit.go