跨频道流媒体转发中的主播和转发机器人在频道中的关联机制

背景:

在生产线环境中,会有用户报说,PK场景下听不到对面频道主播的声音,我们就此展开了分析.

分析有几种原因:

PK听不到对面主播的声音初步判断,可能有几种情况:

1.用户(拉流端)自己网络断开重连,ip变更,丢包率高了,cup算力不足声音缓存绘制过程中出现了问题.等一大堆可能

2.PK对面的主播本(推流身份)本来就卡,比如他的网络卡,丢包率高,或者他的算力给到声音采集模块和声音处理模块不够等也有这种可能.

3.PK对面的主播,转发到观众的声音卡,或者是断掉了.

问题排查:

接下来我们去收集问题信息的时候发现:

1.用户是可以听到频道内其他主播的声音的.(说明观众(拉流端)网络没问题,声音渲染也没问题)

2.PK对面的主播,在其对应的频道内的观众听他的声音也是没有问题的.(说明PK对面的主播(推流端)音频采集,网络上行也是没有问题的)

那么问题走到这里,从现象反馈能推出,推流端和拉流端都没有问题,那问题就可能出现在转发这个模块出现了问题.

原理分析:

既然是转发模块出现了问题,那么给大家讲解下转发模块的逻辑原理.

主播在发起跨频道连麦请求后，会同时安插两个机器人.一个安插在当前频道,负责接收A主播的声音(拉流身份).一个安插在目标频道,负责把A主播的声音推到目标频道(推流身份).主播和收流机器人之间的状态同步，依赖的是主播和机器人之间的一条TCP的心跳连接。

问题定位:

把这个信息汇总给声网技术支持,一查看他们后台数据,发现:就是转发机器人和主播断线了.导致这个问题.

QA:

问:弄懂这个原因就知道了转发原理,那为什么频道内的主播没有掉,而主播和机器人却掉线了呢?

主播进频道是通过udp来加频道，发流这类动作,主播和机器人是TCP连接.

当网络较差的时候，主播和机器人之间心跳容易断，而不太容易掉出频道，而且主播掉出频道sdk也会有主动的重连逻辑。