如何实现无缝切换的主播pk方案

本文作者,rexchang(常青),腾讯视频云终端技术总监,2008 年毕业加入腾讯,一直从事客户端研发相关工作,先后参与过 PC QQ、手机QQ、QQ物联 等产品项目,目前在腾讯视频云团队负责音视频终端解决方案的优化和落地工作,帮助客户在可控的研发成本投入之下,获得业内一流的音视频解决方案,目前我们的产品线包括:互动直播、点播、短视频、实时视频通话,图像处理,AI 等等。

最近腾讯云移动直播团队一直在“不务正业”的打造小程序音视频解决方案,我们一直以来的主营业务之一——秀场直播,在过去几个月的时间里则有点“不思进取”。不过随着近期人力的补充,以及微信版本的逐步稳定,我们在直播方案里的步伐也会进一步加快,盼大家能够继续保持对我们的认可。

今天要介绍的就是主播连麦PK方案,通过这篇文章,我们将一起来了解什么是主播连麦PK?以及怎么快速实现主播间的连麦PK?

什么是连麦PK?

连麦PK就是正在直播中的两个主播,通过相互协商或者后台匹配的方式进入PK状态。一旦进入PK状态,原本独自直播的两个主播,就可以相互视频通话。与此同时,观众端能看到的画面也一分为二,从原来的一个主播变成左右两个主播。这种直播模式可以增加直播间的活跃气氛,为平台带来更多的互动性。

  • 进入 PK 前:两个主播各自独立推流,每个主播都有自己的观众,每个观众看到的画面中都只有自己当前直播间的一个主播。
  • 进入 PK 后:两个主播之间可以视频通话,原本观众只能看到一个主播,现在可以看到两个主播在相互PK(视频通话)。

如何实现连麦PK

我们先从最初的需求入手,看看最简单的实现方案是什么。从前面一张图我们就可以看出,要想实现连麦PK,最简答的办法就是两个主播各自把两路画面混在一起,如下图所示:

主播 A 把自己手机摄像头的画面 local(A) 和来自网络上的主播 B 的画面 remote(B) 混合在一起,再次进行编码和压缩并推送到云端。这样一来,原本主播 A 的观众就可以看到画面中多出了主播 B 的画面。与此同时,如果主播 B 也进行类似的操作,就可以把自己摄像头的画面 local(B) 和 来自于网路的主播 A 的画面 remote(A) 混合在一起。这样,主播 B 的观众也就能同时看到 A 和 B 的画面了。

但是这种方法有个小问题 —— 主播的手机要做的事情太多

  • 工作一:主播的手机要编码和压缩一路本地摄像头的画面,这一路画面是传给另一个主播的;
  • 工作二:主播的手机要解码和渲染一路来自网络的对端画面,这一路画面是来自另一个主播的;
  • 工作三:上述的两路画面要叠加在一起,进行画面的拼接。
  • 工作四:拼接好的画面还要再编码一次,推给观众,这样观众才能看到两路画面。

如何解决性能问题?

为了解决性能问题,我们需要做的是给主播减负。

那要怎么减负呢?是不是可以把工作一工作二,这两项工作去掉?

不行不行,这两项工作是用来做视频通话的,如果减掉了,那主播的 PK 就无从谈起。

工作三工作四是不是可以减掉?

其实也是减不掉的,不过我们可以把它搬到云端,在服务器上完成画面的拼接和计算,而不是在终端完成这些工作。

如上图:当主播 A 和主播 B 开始 PK 后,两边的观众就不再继续从原来的线路上拉流观看了,而是从新的实时音视频云端拉流观看(上图中橙色箭头所示的部分)。这样一来,我们就可以把画面的混合和再次编码的任务放在云端进行。

但是这种方案也不是最完美的,因为从普通直播进入到 PK 状态的过程中,观众端的画面会由于线路切换的原因,出现一段时间的卡顿。

腾讯云连麦PK方案

腾讯云的连麦PK方案则很好的解决了线路切换问题:

由于腾讯云本身既有支撑斗鱼、虎牙的常规直播解决方案,又有多年的QQ视频通话技术积累,所以腾讯的视频云本身就是一个混合云,本身既可以实现常规的直播CDN分发,又能支持高质量低延时的实时音视频线路。因此,我们的方案非常清晰简单:直接在原来的直播线路上叠加一路PK画面:

这样一来,原本在观看主播 A 和 主播 B 的观众,不会遭遇任何的画面二次加载和卡顿等待,只是会看到原本一个画面一分为二,自然而然的进入到 PK 状态。

方案背后的支撑技术

腾讯云采用了两套音视频通道实现主播连麦PK功能,一套是标准直播采用的 CDN 线路,带宽成本低廉且没有并发限制。主播间 PK 所依赖的视频通话,则采用私有的 UDP 传输协议,走专门为降低通讯时延而准备的专线线路。

通道

直播通道

主播PK通道

通讯延迟

=2s

<=500ms

底层协议

RTMP/HTTP-FLV

私有UDP协议

价格/费用

单路费用高于普通直播

最高并发

无上限

<=10人

TXLivePusher

setVideoQuality 为 SD、HD、FHD

setVideoQuality 为 MAIN_PUBLISHER

TXLivePlayer

PLAY_TYPE_LIVE_FLV

PLAY_TYPE_LIVE_RTMP_ACC

播放URL

普通 FLV 地址

带防盗链签名的 RTMP 地址

快速接入直播PK功能

如果您希望使用腾讯云的直播PK功能,可以参考我们的接入文档 LiveRoom(PK)。需要特别说明的是,这套方案还支持观众与主播的连麦,并且终端和后台代码均是开源的,支持自行部署,能够让您拥有非常充分的定制空间。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云计算D1net

九大曾轰动一时的云计算故障事件

对一些人来说,本文列举的云计算故障可能仅仅表明了云服务提供商在哪些方面需要加强或改进,以便更好地服务于客户。对另一些人来说,这几个例子可能更事关个人,因为你的数...

5478
来自专栏Hadoop实操

周年庆

所以我现在编写这第366篇文章也是为了纪念这一年的时光,纪念这每天的一篇文章,纪念风里雨里从未间断过的自己,也是为了激励自己既然选择了这条路,就会义无反顾的坚持...

1524
来自专栏大数据文摘

发改委:《关于组织实施促进大数据发展重大工程的通知》(下载)

2462
来自专栏小程序

App行业发展趋势如何?小程序是否正在“控制”我们的生活?

正如张小龙所言,小程序要成为一种新的形状。尽管他也不确定究竟应该是什么样,只能探索。不过从小程序近期的更新以及实践案例,它的价值越来越大了。

1112
来自专栏CSDN技术头条

大神自动化抓取400亿条秀恩爱和吐槽

能利用爬虫技术做到哪些很酷很有趣很有用的事情? 2011 年夏天我在 Google 实习的时候做了一些 Twitter 数据相关的开发,之后我看到了一篇关于利用...

2376
来自专栏知晓程序

小米 6 明日开抢,组队去「小米商城」小程序围观吧!

被视为「7 年探索的梦幻之作」的小米 6 将在明天上午 10 点正式开售。米粉们估计都摩拳擦掌翘首以盼。

792
来自专栏FreeBuf

以安全产品经理的视角设计应用的登陆功能SDK(BRD篇)

0x00、BRD商业需求文档 Business Requirements Document:用途用于产品在投入研发之前,由企业高层作为决策评估的重要依据,通过本...

2076
来自专栏数据猿

12306,要我位置也就罢了,但你看我相册干啥

【数据猿导读】 然而就是在这样一个人们对信息安全如此敏感的风口上,我们的铁总,12306,竟然顶风作案,重蹈过度获取用户信息的覆辙。勇敢地宛如一个勇士。而且,获...

3507
来自专栏ThoughtWorks

我和思沃学院(一)

今日洞见 文章作者/配图来自ThoughtWorks:胡皓。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站...

3988
来自专栏数据和云

岁末警示:当你手抖删了线上数据库..

作者简介: ? 一乐,aka 梁宇鹏 现任环信首席架构师兼IM技术总监,负责即时通讯云平台的整体研发和管理。曾任新浪微博通讯技术专家,负责微博通讯系统的设计与研...

44710

扫码关注云+社区