跨房 PK 连麦方案

直播间里,为了增进直播气氛、快速吸粉,主播可以邀请其他直播间的主播进行连麦互动或在线 PK。连麦直播间内的观众可以同时收听或观看多个主播互动,能够增强互动直播的趣味性,激发观众刷榜送礼物的欲望。下面介绍三种不同跨房 PK 连麦方案的具体实现。




常规跨房 PK 连麦方案

适用场景

两个或多个房间 PK,房间主播数量较少的简单跨房连麦场景。

方案原理

默认情况下,只有同一个房间内的用户之间音视频可以互通,不同的房间之间的音视频流是相互隔离的。通过跨房连麦,可以将另一个房间中某个主播音视频流发布到自己所在的房间中,与此同时也会将自己的音视频流发布到目标主播的房间中。让身处两个不同房间中的主播进行跨房间的音视频流分享,从而让每个房间中的观众都能观看到这两个主播的音视频。




实现流程

当房间“101”中的主播 A 通过 ConnectOtherRoom 跟房间“102”中的主播 B 建立跨房通话后:
房间“101”中的用户都会收到主播 B 的 onRemoteUserEnterRoom(B)onUserVideoAvailable(B,true) 这两个事件回调,即房间“101”中的用户都可以订阅主播 B 的音视频。
房间“102”中的用户都会收到主播 A 的 onRemoteUserEnterRoom(A)onUserVideoAvailable(A,true) 这两个事件回调,即房间“102”中的用户都可以订阅主播 A 的音视频。
注意:
两个房间单主播跨房 PK,只需要其中一个房间的主播调用 ConnectOtherRoom 建立跨房连麦即可,请勿双向调用。
主播可通过多次调用 ConnectOtherRoom 与多个房间的主播建立跨房连麦,目前限制单个主播最多和其他房间的 9 个主播进行跨房连麦。

实时互动跨房连麦

RTC 场景下的跨房连麦 PK 流程整体简单,主播和跨房连麦主播互相拉取 RTC 单流,观众同时拉取主播和跨房连麦主播的 RTC 单流,观众可独立控制主播和跨房连麦主播媒体流订阅逻辑。实时互动场景跨房连麦流程如下图所示。



注意:
实时互动跨房连麦场景下,房间内观众可独立控制跨房连麦主播媒体流的订阅逻辑,也可由主播 更改跨房主播在本房间的上行能力

示例代码

1. 任意一方发起跨房 PK 连麦。
Android
iOS
public void connectOtherRoom(String roomId, String userId) {
try {
JSONObject jsonObj = new JSONObject();
// 以字符串房间号为例,数字房间号 key:roomId
jsonObj.put("strRoomId", roomId);
jsonObj.put("userId", userId);
mTRTCCloud.ConnectOtherRoom(jsonObj.toString());
} catch (JSONException e) {
e.printStackTrace();
}
}

// 请求跨房连麦的结果回调
@Override
public void onConnectOtherRoom(String userId, int errCode, String errMsg) {
// userId: 要跨房连麦的另一个房间中的主播的用户 ID
// errCode: 错误码,ERR_NULL 代表请求成功
// errMsg: 错误信息
}
- (void)connectOtherRoom:(NSString *)roomId {
NSMutableDictionary *jsonDict = [[NSMutableDictionary alloc] init];
// 以字符串房间号为例,数字房间号 key:roomId
[jsonDict setObject:roomId forKey:@"strRoomId"];
[jsonDict setObject:self.userId forKey:@"userId"];
NSData *jsonData = [NSJSONSerialization dataWithJSONObject:jsonDict options:NSJSONWritingPrettyPrinted error:nil];
NSString *jsonString = [[NSString alloc] initWithData:jsonData encoding:NSUTF8StringEncoding];
[self.trtcCloud connectOtherRoom:jsonString];
}

// 请求跨房连麦的结果回调
- (void)onConnectOtherRoom:(NSString *)userId errCode:(TXLiteAVError)errCode errMsg:(NSString *)errMsg {
// userId: 要跨房连麦的另一个房间中的主播的用户 ID
// errCode: 错误码,ERR_NULL 代表请求成功
// errMsg: 错误信息
}
注意:
跨房 PK 连麦的本地用户和对端用户必须都为主播角色,且必须都有音频或视频上行。
两个房间单主播跨房 PK,只需要其中一个房间的主播调用 ConnectOtherRoom 建立跨房连麦即可,请勿双向调用。
2. 两个房间中的所有用户都会收到来自另一个房间中的 PK 主播的音视频流可用回调。
Android
iOS
@Override
public void onUserAudioAvailable(String userId, boolean available) {
// 某远端用户发布/取消了自己的音频
// 在自动订阅模式下,您无需做任何操作,SDK 会自动播放远端用户音频
}

@Override
public void onUserVideoAvailable(String userId, boolean available) {
// 某远端用户发布/取消了主路视频画面
if (available) {
// 订阅远端用户的视频流,并绑定视频渲染控件
mTRTCCloud.startRemoteView(userId, TRTCCloudDef.TRTC_VIDEO_STREAM_TYPE_BIG, view);
} else {
// 停止订阅远端用户的视频流,并释放渲染控件
mTRTCCloud.stopRemoteView(userId, TRTCCloudDef.TRTC_VIDEO_STREAM_TYPE_BIG);
}
}
- (void)onUserAudioAvailable:(NSString *)userId available:(BOOL)available {
// 某远端用户发布/取消了自己的音频
// 在自动订阅模式下,您无需做任何操作,SDK 会自动播放远端用户音频
}

- (void)onUserVideoAvailable:(NSString *)userId available:(BOOL)available {
// 某远端用户发布/取消了主路视频画面
if (available) {
// 订阅远端用户的视频流,并绑定视频渲染控件
[self.trtcCloud startRemoteView:userId streamType:TRTCVideoStreamTypeBig view:self.remoteView];
} else {
// 停止订阅远端用户的视频流,并释放渲染控件
[self.trtcCloud stopRemoteView:userId streamType:TRTCVideoStreamTypeBig];
}
}
3. 任意一方退出跨房 PK 连麦。
Android
iOS
// 退出跨房连麦
mTRTCCloud.DisconnectOtherRoom();

// 退出跨房连麦的结果回调
@Override
public void onDisConnectOtherRoom(int errCode, String errMsg) {
super.onDisConnectOtherRoom(errCode, errMsg);
}
// 退出跨房连麦
[self.trtcCloud disconnectOtherRoom];

// 退出跨房连麦的结果回调
- (void)onDisconnectOtherRoom:(TXLiteAVError)errCode errMsg:(NSString *)errMsg {
}
注意:
跨房 PK 连麦的发起端和接收端任意一端均可调用 DisconnectOtherRoom 结束跨房 PK 连麦。

服务端跨房 PK 连麦方案

适用场景

多个房间 PK,每个房间有多个主播的纯服务端跨房连麦场景。

方案原理

服务端启动多个混流转推任务,每个转推任务都会拉起一个 Agent 机器人用户进入己方 RTC Engine 房间进行拉流,同时会拉起一个或多个 Feed 机器人用户将混合的音视频流回推到其他参与跨房 PK 连麦的 RTC Engine 房间。这样不同房间里的用户就可以通过订阅其他房间混流回推的音视频流,从而实现跨房 PK 连麦。




实现流程

实时互动跨房连麦

1. 房间 A 主播向房间 B 主播和房间 N 主播发起跨房 PK 请求(业务信令)。
2. 房间 B 主播和房间 N 主播同意跨房 PK 请求(业务信令)。
3. 业务后台同时启动 N 个混流回推房间任务 StartPublishCdnStream
任务一:A_Agent 机器人接收 A 房间主播媒体流,经 RTC Engine 后台混流后由 A_Feed 机器人回推到 B 房间和 N 房间。
任务二:B_Agent 机器人接收 B 房间主播媒体流,经 RTC Engine 后台混流后由 B_Feed 机器人回推到 A 房间和 N 房间。
任务 N:N_Agent 机器人接收 N 房间主播媒体流,经 RTC Engine 后台混流后由 N_Feed 机器人回推到 A 房间和 B 房间。
4. 房间 A、房间 B、房间 N 的用户互相拉取房间中混流回推的音视频流,开始进行跨房 PK。
5. 跨房 PK 结束,业务后台通过 TaskId 停止 N 个混流回推房间任务 StopPublishCdnStream
注意:
本方案最多支持 11 个房间同时进行跨房 PK 连麦,每个房间最多支持 16 个主播同时参与连麦。
机器人 ID 不能与房间内的普通用户 ID 冲突,否则会导致转推任务由于机器人用户被踢出 RTC Engine 房间而异常结束。

示例代码

下面以纯音频场景为例,展示跨房 PK 混流回推房间任务的参数体示例。
任务一
任务二
任务 N
{
"SdkAppId": 1400000000,
"RoomId": "A",
"RoomIdType": 1,
"AgentParams": {
"UserId": "A_Agent",
"UserSig": "eJwtjMEKgkAUAP9lz2Hv6b40oU...",
"MaxIdleTime": 50
},
"WithTranscoding": 1,
"AudioParams": {
"AudioEncode": {
"Codec": 0,
"SampleRate": 48000,
"Channel": 2,
"BitRate": 64
}
},
"FeedBackRoomParams": [
{
"RoomId": "B",
"RoomIdType": 1,
"UserId": "A_Feed",
"UserSig": "eJwtzEELgkAUBOD-sldD3745..."
},
{
"RoomId": "N",
"RoomIdType": 1,
"UserId": "A_Feed",
"UserSig": "eJwtzEELgkAUBOD-sldD3745..."
}
]
}
{
"SdkAppId": 1400000000,
"RoomId": "B",
"RoomIdType": 1,
"AgentParams": {
"UserId": "B_Agent",
"UserSig": "eJwtjMEKgkAUAP9lz2Hv6b40oU...",
"MaxIdleTime": 50
},
"WithTranscoding": 1,
"AudioParams": {
"AudioEncode": {
"Codec": 0,
"SampleRate": 48000,
"Channel": 2,
"BitRate": 64
}
},
"FeedBackRoomParams": [
{
"RoomId": "A",
"RoomIdType": 1,
"UserId": "B_Feed",
"UserSig": "eJwtzEELgkAUBOD-sldD3745..."
},
{
"RoomId": "N",
"RoomIdType": 1,
"UserId": "B_Feed",
"UserSig": "eJwtzEELgkAUBOD-sldD3745..."
}
]
}
{
"SdkAppId": 1400000000,
"RoomId": "N",
"RoomIdType": 1,
"AgentParams": {
"UserId": "N_Agent",
"UserSig": "eJwtjMEKgkAUAP9lz2Hv6b40oU...",
"MaxIdleTime": 50
},
"WithTranscoding": 1,
"AudioParams": {
"AudioEncode": {
"Codec": 0,
"SampleRate": 48000,
"Channel": 2,
"BitRate": 64
}
},
"FeedBackRoomParams": [
{
"RoomId": "A",
"RoomIdType": 1,
"UserId": "N_Feed",
"UserSig": "eJwtzEELgkAUBOD-sldD3745..."
},
{
"RoomId": "B",
"RoomIdType": 1,
"UserId": "N_Feed",
"UserSig": "eJwtzEELgkAUBOD-sldD3745..."
}
]
}
注意:
纯音频场景下,RTC Engine 后台会默认混合房间内所有主播音频流,亦可通过音频参数 McuAudioParams 指定音频混流黑白名单。

跨房 PK 连麦方案对比分析

上面介绍了三种不同的跨房 PK 连麦实现方案,它们各自有不同的适用场景。下面分四个维度对不同的跨房连麦方案进行对比分析。
方案类型
方案优势
方案劣势
房间及人数限制
推荐的使用场景
两人 PK 调用逻辑简单
多人 PK 调用逻辑复杂
单个主播最多和其他房间的 9 个主播跨房 PK
两个房间,单主播(双人)跨房 PK
纯服务端方案,客户端无需额外处理
存在额外的机器人推拉流及混流费用
最多支持 11 个房间同时进行跨房 PK,每个房间最多支持 16 个主播同时参与跨房 PK
多个房间,多主播(多人)跨房 PK,纯服务端管理