CDN转推

服务端合流转推的过程

以 N 人音视频互动同时旁路直播的场景为例：

（1）互动阶段：每个互动参与者都会将自己的 1 路流发布至互动服务器（RTC Server）同时订阅远端的 N-1 路流，实现多人的实时音视频会话。

（2）合流阶段：服务端根据预先设置的合流后的画面配置（分辨率、帧率、码率），以及客户端发送的画面排布的信令，将 N 路流合成为 1 路流。

（3）直播阶段：媒体服务器（Media Streaming Server）将合流后的 1 路流以 RTMP／HLS 协议分发至普通观众端。

服务端：设置合流后的音视频参数

合流后的推流画面尺寸、码率、帧率等参数是 APP 层全局设置，一个 APP 共享一套配置。七牛提供服务端 API 接口设置或用户管理界面两种配置方法。

通过用户管理界面配置

在实时音视频云的 Portal 用户后台，左侧列表可以看到所有新建好的应用，点击具体某个应用 ID 可以查看详细的应用信息，点击编辑，即可设置合流参数。下面对关键配置进行说明：

（1）关联直播空间：如果需要进行旁路直播或落存储，则必须配置对应使用的直播空间；若没有直播空间，需要进行创建。这里选择我们已经创建好的 sdk-live 直播空间。

（2）连麦合流转推：

• 是否启用：如果需要进行旁路转推，则必须开启该服务。
• 只合成音频：如果合流后希望只保留纯音频而没有任何视频帧，则需要选中该项；否则，即使所有的输入流的视频都设置不可见，合流仍然会输入黑色画面。
• 合流输出尺寸：合流画面的分辨率。
• 合流输出帧码率：合流画面的帧率、码率。
• StreamTitle：是转推至七牛直播空间的流名，支持设置魔法变量，魔法变量以$(XX)表示，目前魔法变量有四个：

魔法变量名	代表含义
$(app)	表示连麦应用的 ID
$(hub)	表示连麦应用关联的直播空间名称
$(roomName)	表示连麦房间号
$(timestamp)	表示时间戳

支持多个魔法变量拼接，例如:$(app)$(roomName) 表示 '应用ID房间号'。 下图中， 流名称 StreamTitle 填写** $(roomName) **，表示在对应的直播空间中，连麦互动的房间名称与对应旁路直播的流名称一致。

通过服务端API配置

若希望通过 API 设置合流参数，可参考服务端 UpdateApp 的接口说明，设置合流参数

Host rtc.qiniuapi.com
Post /v3/apps/<AppID> 
Authorization: qiniu mac
{
    "hub": "<Hub>",
    "title": "<Title>",
    "maxUsers": <MaxUsers>,
    "noAutoKickUser": <NoAutoKickUser>,
    "mergePublishRtmp": {
        "enable": <Enable>,
        "audioOnly": <AudioOnly>,
        "height": <OutputHeight>,
        "width": <OutputHeight>,
        "fps": <OutputFps>,
        "kbps": <OutputKbps>,
        "url": "<URL>",
        "streamTitle": "<StreamTitle>"
    }
}

MergePublishRtmp: 连麦合流转推 RTMP 的配置，可选择。其详细配置包括如下

参数	说明
Enable	布尔类型，用于开启和关闭所有房间的合流功能。
AudioOnly:	布尔类型，可选，指定是否只合成音频。
Height, Width	int64，可选，指定合流输出的高和宽，默认为 640 x 480。
OutputFps	int64，可选，指定合流输出的帧率，默认为 25 fps 。
OutputKbps	int64，可选，指定合流输出的码率，默认为 1000 。
URL	合流后转推旁路直播的地址，可选，支持魔法变量配置按照连麦房间号生成不同的推流地址。如果是转推到七牛直播云，不建议配置。
StreamTitle	转推七牛直播云的流名，可选，支持魔法变量配置按照连麦房间号生成不同的流名。例如，配置 Hub 为 qn-zhibo ，配置 StreamTitle 为 $(roomName) ，则房间 meeting-001 的合流将会被转推到 rtmp://pili-publish.qn-zhibo.***.com/qn-zhibo/meeting-001 地址。详细配置细则，请参考上文截图配置页面，或咨询七牛技术支持。

备注：以上关于合流画面的配置项仅用于配置合流的输出效果，对某一个特定输入的画面的配置（例如位置、大小、层级等），需参考相关客户端 sdk 说明文档。

具体服务端API可参考: 服务端API

客户端：多用户的画面布局

在客户端 SDK 提供了接口，可以设置各个互动用户的画面布局的的位置、尺寸、以及层次（允许重叠）。

各个端接口均有以下关键参数，具体参数名称及类型以各端文档为准。可参考 [CDN 转推](https://developer.qiniu.com/rtc/8730/cdn-streaming-android)

参数含义	参数名	备注
待合流的用户 Id	userId	本次设置所对应的 userId
在合流画面中的 x 轴坐标	x	左上角为合流画面坐标原点
在合流画面中的 y 轴坐标	y	左上角为合流画面坐标原点
合流画面中的层次	z	0 在最底层，层次越往上数字越大
在合流画面中的宽度	width	0 表示停止合并当前流到合流画面
在合流画面中的高度	height	0 表示停止合并当前流到

举个例子，假设 A 、B 两个用户分别输入两个流，初始分辨率均为 1280 × 720 。合流后希望得到画面分辨率同样为 1280 × 720 的合流画面。若想实现下图 A 的画面全部铺满合流画面、B 的画面的分辨率重置为 350 × 350 并占右下角的画面布局。

• A 的参数设置：userId = A , x = 0 , y = 0 , z = 0 , width = 1280 , height = 720
• B 的参数设置：userId = B , x = 930 , y = 370 , z = 1 , width = 350 , height =350

由于 B 的画面在合流后的分辨率和比例均与原始流不同，服务端会根据实际设置的比例和大小进行自适应调整再与 A 的画面进行合流。

合流权限配置建议

从最大的灵活性上考虑，在 SDK 的接口设计上，房间里的每一个用户都被允许配置合流布局，但实际的业务场景中对于合流布局的权限应该有所区分：

主播观众一对一连麦

在这种场景下，房间中固定只有 2 个用户，一个为主播一个为观众。一般来说这种情况下布局已经是固定的了，主播占据画面主部分，观众占据画面附部分。所以完全可以在端上通过判断当前用户角色直接调用自己角色相应的合流配置。即每个用户自己通过角色来控制自己的合流配置。

if (当前用户是主播) {
    myRTC.setMergeStreamLayout({...主播的合流配置...})
} else {
  myRTC.setMergeStreamLayout({...观众的合流配置...})
}

多人连麦

在多人连麦的场景下整个合流过程就显得比较复杂了。如果类似于一对一连麦的方案，让各个用户控制自己的合流配置，面对房间中随时会出现的用户离开/用户加入等情况，整个的合流布局就可能会因此发生变动。也就是说，一个用户的 加入/离开 可能会导致多个用户的合流配置需要更新，在这种情况下，我们不推荐单个用户控制自己的合流配置，转而让一个用户去控制房间中所有用户的合流配置可能是更好的方案。

我们的合流模版使用的也是这种方案，所以调用合流模版时需要确保房间中只有一个人调用。在这种设计下，让一个用户去监听房间所有的流状态事件，统一控制布局来控制这个房间所有用户的合流画面。

大家可能会发现，负责合流的用户在这个设计中扮演重要的角色，如果负责合流的用户退出，如何继续连麦？在这里，我们也分为 2 种情况讨论

（1）有房主概念的多人连麦 在这种场景前提下，房间会有一个房主的概念，房主退出房间关闭。所以在这种场景下，直接使用上文中多人连麦的逻辑就可以了，即将房主设置成负责合流的用户，当房主退出，就直接关闭房间就好。

（2）无房主概念的多人连麦（视频会议等） 在这种场景下，就会面临着负责合流的用户可能会退出的问题。事实上，就算负责合流的用户退出，合流也不会停止（除非调用 stopMergeStream）。所以，我们只需要重新选择一个房间内的用户来掌管合流权限就能无缝的继续控制合流画面更新。

在这里，重新选择房间内用户来控制合流权限就需要业务服务器的配合了，在合流权限交接的过程中，必须要保证 2 点。

• 交接前后房间中只能有一人控制合流
• 交接过程同时需要提供一定的信息，使得新合流用户可以复现当前的合流布局

需要注意的是，因为 SDK 合流控制本身并没有太多的限制和要求，所以上述 2 种方案仅仅是其中一种解决方案，在有业务服务器的配合下，完全可以根据自己的实际业务需求定制自己的合流逻辑。