首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >蒋磊:移动直播连麦技术实践

蒋磊:移动直播连麦技术实践

原创
作者头像
腾讯云开发者社区技术沙龙
发布于 2019-07-02 14:22:20
发布于 2019-07-02 14:22:20
7.8K1
举报

6月29日,音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题,针对腾讯云音视频及融合通信产品的技术全面剖析,为大家带来纯干货的技术分享。下面是蒋磊老师关于直播的一些分类以及连麦直播需要解决的四类问题进行了总结与分享。

讲师介绍:蒋磊,腾讯云高级工程师,现任职于腾讯云终端研发中心,负责腾讯云视频服务客户端SDK的技术服务工作,曾先后就职于网易、阿里云,负责实时音视频、直播、点播、CDN、即时通信等业务相关技术工作,在音视频及IM业务的实际应用上经验丰富。

首先,来看直播这块相关的一些概念。直播一般是两种场景:一种是普通的直播,有一个主播和很多观众,这种大部分使用RTMP协议,然后通过CDN的方式去做分发,从而实现大规模高并发的数据分发;另一种是连麦直播,它跟普通直播的区别在于普通直播类似于单口相声,连麦直播则像是对口相声和群口相声,有两个或多个主播,这些主播里面我们通常会分为大主播和小主播,普通观众同时观看大主播和小主播的画面。这是通常所见的移动直播的形式。

再来看看连麦直播的常见的应用场景:第一种是娱乐类场景,像是娱乐秀场和活动直播里面主播与主播之间的连麦;第二种是教育场景,常见的是老师和学生之间的问答;第三种是电商场景,卖家跟买家之间的相互沟通咨询可以极大地提升卖货量。当然连麦使用的场景不只是这三种,连麦之所以在最近几年非常火,是因为可以极大地提高用户的参与度、黏度以及信任感。像陌陌、映客都是通过连麦使得用户活跃度提升非常多。在过去的几年里,连麦开始成为了直播的一种标配功能。

我们来了解一下连麦的基本原理,大主播将自己的数据发给小主播,同时小主播将自己的数据发给大主播,两者之间相互可以看到对方,进行音视频沟通。然后再把大主播和小主播的数据分发合并,分发给普通观众观看,这样就实现了连麦直播。原理大家都懂,那么我们怎么做呢?会有哪些问题?

那么接下来我们来逐个看看要处理的问题,连麦直播里主要的问题有四个方面:

第一个问题是延时问题,为什么会产生延时,延时会带来什么影响,试想一下,如果连麦过程中大主播说一句话,对方等三四秒才能听到,那连麦的体验会非常差;

第二个问题是回声问题,普通直播里面回声基本上不会存在,因为它是单向的,但是在连麦里面回声是必须要解决的;

第三个问题是混流问题,在连麦直播里有多个主播的数据流,我们必须要对它进行混流,不然普通观众去播放每个主播的数据,由此引起的带宽以及网络适配的问题会非常麻烦;

第四个问题是房间管理问题,这个相对简单一点,但是房间管理会涉及到一些业务层面的逻辑,比如说房间的状态、房间里有多少人、大小主播之间怎么沟通,这些都需要通过房间管理来做好的。

这些是我们在连麦过程中需要解决的问题,接下来就一个个来看。

普通直播延时

普通直播使用CDN的方式做传输分发,主播通过RTMP方式把数据推到云端,观众通过云端流拉下来播放。这里我们把整个过程细分一层,首先从主播端把数据推到upload上,也就是接流节点;然后再把数据做一次转码,这里做转码主要是为了在web端播放或者有的不支持RTMP的情况,还有如果是推高清流,而让观众自主选择清晰度也会需要转码;转码之后,再通过CDN把数据进行分发。这是普通直播的过程。

那么延时来自于哪里?第一个地方是是转码,这里的处理过程中会有百毫秒级别的延时增加。

接着就是CDN引入的延时,因为CDN回源的工作机制,在H.264的GOP编码方式下,CDN回源时必须拿到I桢才行,GOP时间越长,在CDN引入的延时会越大。通常情况下, GOP的时长在1-3秒,意味着在CDN引入的延时至少有1-3秒。平时我们看直播的时候,主播那边动了一下,但是观众看到大概要等到2-5秒,主要就是因为CDN的缓存引起。这种情况下延时太大了,我们根本没有办法做到很好的连麦效果。

那么怎么来解决普通直播引入的延时呢?最好办法就是不走CDN,不走CDN的方式有很多种,我们使用的方式是引入加速节点。

首先大主播推流到upload后,我们直接从upload拉流到RTMP-ACC节点,然后小主播再从RTMP-ACC的节点获取数据。同样的,小主播也把流线推到upload后让大主播再从RTMP-ACC节点拉流。在各节点内部,我们都是走的高速专线,并通过UDP加速,可以实现大主播到小主播之间500毫秒以内延时。这样虽然推的是RTMP的流,但是几乎相当于是实时的通话了。

除了由CDN引入的延时以外,另一个延时来自己于播放器的缓冲。根本的原因是网络,在理想情况下的网络,我们认为传输是从来不会丢包,从来不会有延时,带宽永远是稳定不变的。但是现实情况是:传输过程或多或少会有丢包,传输延时不可控,带宽也是波动的。为了保证比较好的播放体验,通常我们会采用一种方式,在播放器里设置一段缓冲的区间,就像蓄水池一样,把来自于网络的数据包在这个地方先缓冲一下,然后再交给解码器解码,这个蓄水池的地方我们称之为jitterbuffer。在普通的直播场景下jitterbuffer通常会设置在500毫秒到1000毫秒之间,也就是从网络拿到了数据要等到500到1000毫秒才会让观众去看。在连麦直播里,为了降低延时,我们要把jitterbuffer的水位降低,一般会设置到200毫秒左右,但是调到200毫秒又会引入另一个问题就是jitterbuffer的累积延时。

虽然我们通过jitterbuffer做缓冲,但是客观上网络还是抖动的,而jitterbuffer要满了才会往解码器送数据,这里就会出现累积延时的情况。比如说我这边是200毫秒的jitterbuffer,但是网络传输这些数据用了800毫秒才填满,这里就多出了600毫秒的延时,网络如果一直抖动,那这个延时就会不断增加。为了解决这个问题,我们在降低水位的同时,还要修正累积的延时,在我们的LiteAVSDK里面,这部分累积延时的修正工作在底层做好了,不需要开发者再去额外处理。大家如果有接触过一些开源方案,就会发现通常他们不会做累计延时的修正。这就是看直播的时候发现通过会像VLC、ffmpeg等播放直播的时候,播放时间长了延时会越来越大,主要就是累积延时没有修正。

回音

接下来我们看一下回声问题。

大主播说的话通过麦克风采集,经通信线路传给小主播,通过小主播的扬声器播放出来,小主播说的话通过麦克风采集到大主播这边扬声器播放,这样双方就进行了音频的交换。这是理想的情况下,实际情况中遇到回声问题,回声一般分成两类:一类是线路回声,具体的细节就不多讲了,一般是由硬件厂商自己解决掉,我们通常关注的是第二类回声,也就是是声学回声。大主播的原声在传到对方的扬声器播放之后,如果被对方的麦克风再采集一次(回授),然后再通过通信线路传回来,经扬声器播放出来,这时大主播就会听到自己的声音,也就是回声。而如果大主播的麦克风又采集并传输输出去,形成的循环的回授,就容易引起啸叫。

回声还有一个需要注意的点就是,人的耳朵特别灵敏,超过10毫秒以上的回声就能够分辨出来,而通信线路往往是延时50毫秒以上,这样导致在连麦场景中回声几乎无法避免,所以我们必须要解决回声问题。

怎么解决回声?回声的产生原理我们已经知道了,那么我们将通过播放器播放的声音,与麦克风采集的声音进行波形比对,把回声做反向抵消,这个就叫AEC。回声消除算法比较复杂,所以我们把AEC的模块直接做到LiteAVSDK里面,这样开发者不需要通过额外的编程,直接启用一个参数就可以实现回声消除功能。

画面混合

画面混合第一部分是客户端,大主播和小主播之间都要看到对方的画面,需要在本地进行处理,一个是自己本地的预览,另一个是远端的数据渲染,这需要播放器支持多实例,这个过程相对来说比较简单,只要播放器支持多例,做好性能优化就可以搞定了。

云端的部分,我们通过upload拿到数据,在转码服务上有一个附加的混流模块,从 upload拿到数据之后,按照设定的参数分层叠加,再通过CDN进行分发,这就是云端混流。云端混流可以极大地减轻客户端的压力。

腾讯云的云端混流支持同时16路输入流混合,输入源可以是纯音频、音视频、画布和图片等。一般连麦的时候我们不建议同时超过4路声音,不是因为技术问题,而是因为同时4个人说话的时候,观众一般顾不过来主播们是在说话还是吵架,体验不是很好。

除了这些以外还有哪些是需要我们处理的问题呢?从采集到预处理,我们要对各类机型进行兼容性的适配、性能优化,然后是编解码器的调优,之后还有网络的QoS优化,发出去之后我们还要做播放器的优化,主播上下麦,地址的管理,直播间的消息,混流的延时的控制,娱乐场景下还要用到耳返,等等。这些都是技术上需要解决的问题,而除此之外最重要的一点,是效果与成本之间能不能达到平衡。我们如果不计代价进行投入,可不可以做好?可以。但以这样的方式去实现的话投入产出比太低,我们想要的是在足够低的成本下,实现满足业务所需效果的方案,这样的方案才是商业化的可行的成熟的方案。

在过去的几年里面,为了解决这些问题我们使用了许多技术方案,并且把这些技术方案打磨之后,先实现在MLVBLiveRoom方案。

MLVBLiveRoom是怎么做的呢?首先是某一个用户A通过RTMP推一个加速流到云加速的节点上,与A进行连麦的用户B也是通过RTMP推流到云加速的节点,然后A拉B的流,B拉A的流。标准的RTMP底层是走的TCP,在云加速服务中,我们将其底层替换成了UDP,即RTMP over UDP,这样就可以实现A和B之间的延时低到500毫秒以下。

经过云加速之后,再将多个用户的数据推给云端混流服务,在云端混流的节点上将用户画面进行混流,混流之后再把他们的画面推到CDN,普通的观众再通过CDN拉流进行播放。这一部分使用的是标准的RTMP,复用了标准的直播流程,在这一部分引入的延时不会影响到连麦用户。

可以看出,相比普通直播方案引入最大的成本在于UDP加速改造,这个地方需要我们部署相应的RTMP-ACC节点,以及修改RTMP底层的协议网络栈,相较而言,成本增加不大。我们可以通过这种方式实现高质量、低成本的连麦方案,这就是我们所做的MLVBLiveRoom,它基于LiteAVSDK+IMSDK,结合云直播及云通信PaaS服务,从普通的连麦、跨房PK、直播间互动都在一个组件里直接搞定。

房间的管理

我们在腾讯云的云端部署了房间管理服务,对于开发者来说在接入过程不需要再考虑过多的房间管理逻辑,像用户什么时候进退房间,小主播什么时候上下麦,这些都已经直接封装好了;而且我们基于优图实验室提供人脸识别技术,提供了付费使用的高级人脸AI特效,可以实现丰富的人脸动效,满足业务需要;另外,对于开发者而言,在功能接入上必须要做得足够简单,如果我们实现一个直播方案需要花费两三个月才能实现连麦,这时候很容易错过最佳的业务发展期,我们把MLVBLiveRoom设计成一个组件,开发者仅需半天时间就可以跑通流程。

为了帮助开发者节省工作量,我们还做了一个开放源码的Demo APP,叫小直播,在AppStore和应用宝上都可以直接安装体验。小直播APP的源码可以在官网上下载,我们将其工程按照组件的方式都列好了,大家可以直接基于小直播源码进行业务功能修改。

我们实现了MLVBLiveRoom方案,开发者可以方便地集成开发,但是仅仅做这一步就够了吗?还不是,我们还要做很多的东西,比如说应用上线了后的质量还需要管理。

在MLVBLiveRoom里,我们把底层最核心的仪表盘数据都通过回调开放给开发者,开发者可以通过onNetStatus拿到直播底层最直接的数据,比如说网络是否有抖动、线上的情况到底是怎么样,开发者可以自己去收集这些数据进行统计处理。

在应用上线前期,开发者对于这些数据十分关注,如果觉得自己搭一套后台去监控这些信息比较麻烦,在我们的控制台上,也对onNetStatus的数据做了上报统计展示,并基于我们十余年的音视频经验,建立了一套评分机制,卡顿次数多少、网络质量好不好、码率是否健康,我们会对每一路直播流的数据进行评分,供开发者进行参考。

MLVBLiveRoom解决了连麦直播很多的问题,但是同时还有一个小的问题是解决不了的,那就是在不同的通道之间切换的时候引入的延时时间差。这个时间差的原因,在于主播和主播走的UDP的通道,他们之间的延时是百毫秒级别,而普通观众则是通过CDN的通道进行播放,通常延时到了秒级。如果一个普通观众想上麦,与主播互动的话,他要就必须从CDN的通道切换到UDP的通道,也就是从秒级的通道切换到百毫秒级的通道,这就会存在延时时间差。

为了实现普通观众上麦的平滑过度,需要通过业务层面做动画、加提示等方式,不然就会黑屏一下,这样用户体验上会有一些损失。下麦的时候也是如此。

为了解决观众平滑的上下麦,我们还做了一个方案,这个方案是纯UDP的方案,让所有的用户都加入到一个TRTC低延时大房间里。当有说普通观众想与主播实现连麦时,可以实现平滑的上下麦过程,我想跟主播说话我就直接说话,我不想说话我就直接下,每一个用户都是通过UDP的方式去播放、推流。TRTC低延时大房间可以支持10万用户同时在一个房间,主播间连麦互动最低可到100毫秒,普通观众的延时可以控制在1000毫秒以内。普通观众上下麦是平滑无感知的。

在TRTC的方式下我们也做了一个Demo APP,名字叫腾讯实时通话,大家可以在应用宝或AppStore上安装体验低延时下主播和观众之间无缝的切换的上下麦过程。

最后给大家讲一下关于我们最近这几年在音视频SDK这块做的一些工作,前面我所讲的内容都是基于我们的LiteAVSDK实现的,LiteAVSDK是由腾讯云终端研发中心持续打磨了5年的一个产品,使用的是LiteAV引擎,它包含了底层的音视频编解码、QoS、音视频处理等基础引擎部件。在LiteAV引擎之上,我们对不同的业务场景封装了不同的产品,比如针对直播场景的LiteAV_Smart,针对最近这一两年特别火的短视频场景的LiteAV_UGC,针对在线直播点播播放的LiteAV_Player,结合腾讯云可以实现无缝清晰度切换,还有针对音视频通话场景的LiteAV_TRTC。LiteAV架构稳定而且扩展性强,对于开发者而言,一套SDK就可以搞定各种音视频业务需求。

在过去几年,LiteAVSDK也吸引了不少的客户,我今天列了一小部分,也欢迎大家体验一下我们的LiteAVSDK。

Q:您好,我想知道TRTC他的技术指标可以支撑到多少的用户在里面互动。

A:我们在看这个的时候分两块,一块是上行,一块是下行:上行部分我们目前默认限制是10人,有更多需要的可以提工单申请,审核评估后可以调整;下行我们推荐在1万人以内,不过我们并没有做强制限制。

Q:我想问一下RTMP底层改成UDP的可靠性怎么样,还有QoS策略怎么样?

A:我们的QoS策略是业内领先的,这是腾讯在音视频传输优化上十几年来的经验积累,并且一直在改进。而至于UDP改造的可靠性,我们是基于QUIC协议实现的,QUIC里面本身就有类似于TCP里面的可靠性保证,我们目前在线上已经跑了两三年了,从线上情况来看效果很好,可靠性不用担心。UDP加速方式的连麦方案,可以帮助使用CDN方式进行直播业务的客户,用低成本的方式加入连麦功能。这对大部分直播客户来说非常高效,可以节省很多费用。而且,如果客户想实现更高质量的连麦,我们也有TRTC低延时大房间方案,在LiteAVSDK中可以直接方便的使用。

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

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

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

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

评论
登录后参与评论
1 条评论
热度
最新
666
666
回复回复点赞举报
推荐阅读
编辑精选文章
换一批
蒋磊:移动直播连麦技术实践(附视频回放)
6月29日,音视频及融合通信技术技术沙龙圆满落幕。本期沙龙特邀请腾讯云技术专家分享关于最新的低延迟技术、全新的商业直播方案等话题,针对腾讯云音视频及融合通信产品的技术全面剖析,为大家带来纯干货的技术分享。下面是蒋磊老师关于直播的一些分类以及连麦直播需要解决的四类问题进行了总结与分享。 讲师介绍: 蒋磊,腾讯云高级工程师,现任职于腾讯云终端研发中心,负责腾讯云视频服务客户端SDK的技术服务工作,曾先后就职于网易、阿里云,负责实时音视频、直播、点播、CDN、即时通信等业务相关技术工作,在音视频及IM业务的实际
腾讯云音视频
2019/07/05
4.6K0
蒋磊:移动直播连麦技术实践(附视频回放)
MLVBLiveRoom 方案 - 客户端部分
本文用于介绍移动直播 MLVBLiveRoom 方案的客户端部分,MLVBLiveRoom 方案包含了两部分内容:客户端 MLVBLiveRoom 组件 + 房间管理服务 RoomService。RoomService 说明见 https://cloud.tencent.com/developer/article/1488765
腾讯云-chaoli
2019/08/16
11.2K2
MLVBLiveRoom 方案 - 客户端部分
【实战分享】直播连麦解决方案分析
直播带货最近一年来最火的业务了,但是长期以来,在直播间里都是以主播主动推流,观众被动拉流观看的方式维系一场直播。为了调动直播气氛,很多直播间也逐步开通了用户弹幕、点赞和行为提示等三大宝剑,从而达到主播和观众之间的互动反馈。的确这些功能都可以起到氛围烘托的作用,但是说到底仍然还是单向的数据交互。为了本质上提升互动性,还有这样的两个利器存在:
netkiddy
2020/10/28
6.8K0
【实战分享】直播连麦解决方案分析
实时音视频 TRTC 常见问题汇总---咨询问题篇
支持的平台包括 iOS、Android、Windows(C++)、Windows(C#)、Mac、Web、Electron、微信小程序、Flutter,更多详情请参见 平台支持。
腾讯视频云-Zachary
2019/11/01
13.5K0
实时音视频 TRTC 常见问题汇总---咨询问题篇
视频直播连麦技术详解「建议收藏」
云帆加速自成立以来就一直致力于流媒体领域企业服务,尤其对于直播,目前已经推出了针对于不同场景的直播云解决方案,在保证广大用户使用体验的前提下,为客户节省更多的研发成本。无论是传统企业转型,或者是创业企业,云帆加速都将为其直播化提供针对性的解决方案。目前云帆加速已经与流媒体领域50+行业top级客户建立合作关系,并提供服务。
全栈程序员站长
2022/09/15
5.7K0
视频直播连麦技术详解「建议收藏」
移动直播连麦PK快速调试
低延时流,也叫acc流,相比普通观众流(也叫cdn流)而言,它只有400ms的延时,是主播们连麦、PK时需要低延时场景时拉取的流,通话效果更好。
腾讯云-chaoli
2020/07/30
3.2K0
移动直播连麦PK快速调试
MLVBLiveRoom 方案 - 管理后台RoomService接口文档
本文用于介绍移动直播 MLVBLiveRoom 方案的管理后台部分,MLVBLiveRoom 方案包含了两部分内容:客户端 MLVBLiveRoom 组件 + 房间管理服务 RoomService。MLVBLiveRoom 组件说明见 https://cloud.tencent.com/developer/article/1488540
腾讯云-chaoli
2019/08/16
21.7K31
MLVBLiveRoom 方案 - 管理后台RoomService接口文档
移动直播MLVB常见问题(FAQ)
快速入门:https://cloud.tencent.com/document/product/454/7876
腾讯视频云-Zachary
2020/04/04
9.1K0
移动直播MLVB常见问题(FAQ)
移动直播连麦PK快速调试
低延时流,也叫acc流,相比普通观众流(也叫cdn流)而言,它只有400ms的延时,是主播们连麦、PK时需要低延时场景时拉取的流,通话效果更好。
ppchao
2020/12/14
1.8K0
移动直播连麦PK快速调试
腾讯云实时音视频技术发展简史 — 从编解码器容错优化到云端决策系统
大家好,我是腾讯视频云终端研发负责人常青,本次分享的主题和内容是关于腾讯音视频终端这些年来的进化演化以及在客户方面的实践应用,所以“进化”也是本次分享的主题词,说到进化大家可能首先联想到的是达尔文的进化论,因此我会先以一段故事来引出之后的内容。
LiveVideoStack
2019/09/04
1.6K0
腾讯云实时音视频技术发展简史 — 从编解码器容错优化到云端决策系统
TRTC Android端开发接入学习之常见问题(十一)
V1和V2主要区别在于IM的SDK是否内嵌于TRTC中,V1线路是内嵌,而V2则可选,默认不打包IM的SDK包。V2在通话质量、线路规格、接入难度以及功能扩展上均比V1更有优势。
腾讯云-hongyang
2020/09/27
3.3K0
iOS音视频接入 - TRTC常见问题
在 TRTC SDK 的示例代码中提供了一个叫做GenerateTestUserSig的开源模块,您只需要将其中的 SDKAPPID、EXPIRETIME 和 SECRETKEY 三个成员变量修改成您自己的配置,就可以调用genTestUserSig()函数获取计算好的 UserSig。
小明同学接音视频
2020/10/21
3K0
iOS音视频接入 - TRTC常见问题
移动直播自由开播方案
主播自由开播(UGC + OGC)解决方案,是指主播可以随时拿起手机开始直播,映客、花椒、斗鱼、Now 等直播平台都是采用这种直播解决方案。由于LiteAVSDK的高解耦性,终端sdk只提供了TXLivePusher、TXLivePlayer的上行推流组件和下行拉流组件,自由开播方案需要您关注 房间管理 相关的逻辑,也就是维护一个所有用户可见的“直播间列表”。
腾讯云-chaoli
2019/09/08
2.7K0
移动直播自由开播方案
视频直播技术干货(十三):B站实时视频直播技术实践和音视频知识入门
直播行业从传统的娱乐直播发展到教育直播、电商直播等形式,产生了很多新的玩法。传统的直播是一位主播展示才艺,观众通过弹幕、送礼物等方式进行互动。随着网络质量不断地提高,用户也对直播平台产生的新的要求,实时互动直播的场景就出现了,观众可以同时观看多位主播之间互动的画面,让直播间的气氛更好。B站直播的连麦PK、视频连线业务就提供了这个能力。主播看到的是对方主播实时的流(延迟400ms以内),而观众看到的是“准实时”的流(延迟2~5s左右)。
JackJiang
2025/03/06
7140
视频直播技术干货(十三):B站实时视频直播技术实践和音视频知识入门
视频直播APP SDK选型
即构科技由腾讯QQ团队创业,是市面暂时较好的推流SDK,但是费用太高,可以先做个对比。但美颜效果,连麦功能,狼人杀模式等确实相较其他SDK有很大的优势。
走在河边的小鹿
2020/03/05
5.2K0
视频直播APP SDK选型
视频互动直播软件开发中的连麦问题分析
直播行业发展至今,我们经常会听到很多朋友谈论“互动直播”。那么何谓互动直播呢?其实互动直播的核心在于通过连麦技术,让视频直播有一个超过文字的更深层次的互动交流。
q3557873521
2019/04/10
2.5K0
手机直播连麦技术分析
直播火了,连麦直播也火了,那么说明是直播,连麦直播是什么。 手机直播连麦功能的特点,我们按下面三部分来聊一聊手机直播和直播连麦: 手机直播连麦功能的特点 人物画像和设计思维 一个有趣的连麦功能交互建议 手机直播连麦功能的特点 体验了斗鱼、NOW直播、美拍直播、淘宝直播、新浪直播、映客、me直播等直播平台、发现只有映客和me直播推出了手机直播的连麦功能。 我们从以下三点来展开分析直播连麦的特点: 连麦功能的权限 连麦人数和显示位置 连麦交互流程 连麦权限 ME直播的连麦功能是没有权限设定的,所有的主播和
xiangzhihong
2018/02/05
7.1K0
手机直播连麦技术分析
行业发展,技术先行 腾讯云为音视频及融合通信发展助力
近年来,音视频娱乐增长“爆发”,从直播到短视频再到各大视频网站的高速发展,都在强调着这一产业的生命力。行业的爆发离不开背后的技术升级。从云计算、AI到5G,音视频的观看体验和内容制作效率都在得到提升。 日前,在腾讯云+“音视频及融合通信技术”主题沙龙上,来自腾讯云的5位技术专家为大家带来了音视频领域热点话题的分享,用技术的语言传达着腾讯云“产业智变,云启未来”的理念。 腾讯云解决移动直播连麦4大技术问题 什么是普通直播?什么是连麦直播?腾讯高级工程师蒋磊用单口相声和对口/群口相声来生动讲解普通
腾讯云音视频
2019/07/05
1.8K0
行业发展,技术先行 腾讯云为音视频及融合通信发展助力
基于WebRTC的互动直播实践
大家好,我是叶峰峰,来自映客直播,从事实时音视频的开发工作大概有七八年时间了,在加入映客后,也参与了映客实时互动直播的开发过程。本次分享主要介绍映客互动直播开发过程中遇到的一些问题,以及对直播场景下互动直播的一些优化。
LiveVideoStack
2021/09/01
3K0
腾讯云低延时直播系统架构设计与弱网优化实践
http://scrmtech.gensee.com/webcast/site/vod/play-6ced83f94af24094b6d8329948addb09
LiveVideoStack
2020/06/11
3.9K0
腾讯云低延时直播系统架构设计与弱网优化实践
推荐阅读
相关推荐
蒋磊:移动直播连麦技术实践(附视频回放)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档