前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >手机直播连麦技术分析

手机直播连麦技术分析

作者头像
xiangzhihong
发布于 2018-02-05 07:09:46
发布于 2018-02-05 07:09:46
6.8K0
举报
文章被收录于专栏:向治洪向治洪

直播火了,连麦直播也火了,那么说明是直播,连麦直播是什么。

手机直播连麦功能的特点,我们按下面三部分来聊一聊手机直播和直播连麦

  • 手机直播连麦功能的特点
  • 人物画像和设计思维
  • 一个有趣的连麦功能交互建议

手机直播连麦功能的特点

体验了斗鱼、NOW直播、美拍直播、淘宝直播、新浪直播、映客、me直播等直播平台、发现只有映客和me直播推出了手机直播的连麦功能。

我们从以下三点来展开分析直播连麦的特点:

  1. 连麦功能的权限
  2. 连麦人数和显示位置
  3. 连麦交互流程

连麦权限

ME直播的连麦功能是没有权限设定的,所有的主播和观众都可以进行连麦,连麦的icon在直播页面的明显位置,很容易被发现,因此在ME直播的很多房间里,都可以看到主播与粉丝连线的画面。但看多了你会发现,能跟主播连线互动的要么是其他主播,要么是送礼物多的粉丝。

而映客的连麦功能是有权限设定的,并且门槛比较高,要求百万映票、等级80以上以及紫V认证的用户才能进行连线互动。这从某个方便来说对于质量上有了提高。

连麦人数和显示位置

ME直播只能单人连线,位置在屏幕右下方,相对不怎么遮挡视线。映客可以单人连线,也可以同时连线2个人。至于这个技术怎么实现的,后面会详细聊到。

连麦交互流程

ME直播的交互流程是每个人都可以体验到的,分为三个视角:发起连线人视角、主播视角、普通观众视角。通过不同的分级和角色实现不同的角色连接。

说了这么多,那这种技术具体怎么做的呢,这是我们做技术的需要关注的。首先来看一下直播的原理图:

正如上图所示,整个直播流程分为以下几个关键步骤: 1、主播客户端,将本地采集的视频推送到CDN; 2、CDN对视频流进行缓存以及转发; 3、观众客户端,拉取CDN中缓存视频流进行播放;

这其中最核心的就是CDN了,那神马事CDN呢?

CDN技术原理

CDN的全称为Content Delivery Network,即内容分发网络,是一个策略性部署的整体系统,主要用来解决由于网络带宽小、用户访问量大、网点分布不均匀等导致用户访问网站速度慢的问题。这中间就有了很多的CDN节点,简单一点理解就相当于我们开始学习计算机选择网络。具体实现是通过在现有的网络中,增加一层新的网络架构,将网站的内容发布到离用户最近的网络节点上,这样用户可以就近获取所需的内容,解决之前网络拥塞、访问延迟高的问题,提高用户体验。

上图中,不同的流媒体走的节点和协议做了区分,网络拥塞减少,访问延迟降低,带宽得到良好的控制等等。 CDN直播中常用的流媒体协议包括RTMP,HLS,HTTP FLV等。

RTMP(Real Time Messaging Protocol)是基于TCP的,由Adobe公司为Flash播放器和服务器之间音频、视频传输开发的开放协议。 HLS(HTTP Live Streaming)是基于HTTP的,是Apple公司开放的音视频传输协议。 HTTP FLV则是将RTMP封装在HTTP协议之上的,可以更好的穿透防火墙等。

CDN的常用架构

CDN架构设计比较复杂。不同的CDN厂商,也在对其架构进行不断的优化,所以架构不能统一而论。这里只是对一些基本的架构进行简单的剖析。

CDN主要包含:源站、缓存服务器、智能DNS、客户端等几个主要组成部分。

源站:是指发布内容的原始站点。添加、删除和更改网站的文件,都是在源站上进行的;另外缓存服务器所抓取的对象也全部来自于源站。对于直播来说,源站为主播客户端。

缓存服务器:是直接提供给用户访问的站点资源,由一台或数台服务器组成;当用户发起访问时,他的访问请求被智能DNS定位到离他较近的缓存服务器。如果用户所请求的内容刚好在缓存里面,则直接把内容返还给用户;如果访问所需的内容没有被缓存,则缓存服务器向邻近的缓存服务器或直接向源站抓取内容,然后再返还给用户。

智能DNS:是整个CDN技术的核心,它主要根据用户的来源,以及当前缓存服务器的负载情况等,将其访问请求指向离用户比较近且负载较小的缓存服务器。通过智能DNS解析,让用户访问同服务商下、负载较小的服务器,可以消除网络访问慢的问题,达到加速作用。

客户端:即发起访问的普通用户。对于直播来说,就是观众客户端,例如手机客户端,PC客户端。

用图表示如下:

整个流程描述如下:

主播开始进行直播,向智能DNS发送解析请求; 智能DNS返回最优CDN节点IP地址; 主播端采集音视频数据,发送给CDN节点,CDN节点进行缓存等处理; 观众端要观看此主播的视频,向智能DNS发送解析请求; 智能DNS返回最优CDN节点IP地址; 观众端向CDN节点请求音视频数据; CDN节点同步其他节点的音视频数据; CDN节点将音视频数据发送给观众端;

采用CDN的缺点

大概了解了CDN的技术原理后,我们在做直播选型时,还需要了解一个方案优缺点。接下来,我们来分析一下CDN的短板。

总结一下主要有如下短板:

播放延时(网络延时)

网络延时这里指的是从主播端采集,到观众端播放,这之间的时间差。这里不考虑主播段采集对视频进行编码的时间,以及观众端观看对视频进行解码的时间,仅考虑网络传输中的延时。例如说下图中的网络延时:

网络抖动

网络抖动,是指数据包的到达顺序、间隔和发出时不一致。比如说,发送100个数据包,每个包间隔1s发出。结果第27个包在传输过程中遇到网络拥塞,造成包27不是紧跟着26到达的,而是延迟到87后面才达。在直播中,这种抖动的效果实际上跟丢包是一样的。因为你不能依照接收顺序把内容播放出来,否则会造成失真。网络抖动,会造成播放延时对应增大。如果网络中抖动较大,会造成播放卡顿等现象。这个之前在云计算上都不是什么难事。

网络丢包

CDN直播中用到的RTMP、HLS、HTTP FLV等协议都是在TCP的基础之上。TCP一个很重要的特性是可靠性,即不会发生数据丢失的问题。为了保证可靠性,TCP在传输过程中有3次握手,见下图。首先客户端会向服务端发送连接请求,服务端同意后,客户端会确认这次连接。这就是3次握手。接着,客户端就开始发送数据,每次发送一批数据,得到服务端的“收到“确认后,继续发送下一批。TCP为了保证传到,会有自动重传机制。如果传输中发生了丢包,没有收到对端发出的“收到”信号,那么就会自动重传丢失的包,一直到超时。

由于互联网的网络状况是变化的,以及主播端的网络状况是无法控制的。所以当网络中丢包率开始升高时,重传会导致延时会不断增大,甚至导致不断尝试重连等情况,这样不能有效的缓存,严重情况下会导致观众端视频无法观看。

连麦

直播中,主播如果要与用户交互,常见有两种方式: 第一种方式:文字,这种比较常见,实现也比较简单,这里不再进行分析;这种比较简单 第二种方式:连麦,这样主播可以面对面与观众进行交互,增加了互动性;这种最网络的要求更高。

所以为了解决上面的问题,出现了RTMP协议。

RTMP是目前主播中最常用的协议,使用RTMP协议,可以实现最简单的一种连麦方式,当有连麦者时,则主播端和连麦者端,都分别推一路RTMP流到CDN,CDN再将这两路RTMP流发送给观众端,观众端将两路RTMP流合成为一个画面。

解决连麦的第二种方式是:

主播端与连麦者之间使用P2P方式进行交互,然后主播端将自己和连麦者的视频进行合并,再推到CDN上,CDN再发送给观众端。

不过P2P在某些网络下无法穿透,有些观众根本无法与主播端进行交互; 主播端需要上传两路视频:一路P2P与连麦者进行交互,一路使用RTMP推到CDN。还要下载一路视频:连麦者P2P发送过来的交互数据。所以主播端要求带宽需要较高,网络较差时无法进行主播 主播端要进行多路视频的编码、解码,要求主播端设备配置比较高,较差的设备也无法进行主播; 只能支持一个连麦者,不能支持多个连麦者; 由于主播端和连麦者经过CDN合并成一路,因此,不能实现主播端和连麦者视频大小窗口切换。

还有一种方式就是通过CDn中转:

是主播和连麦者都将视频推送到CDN中,然后CDN内部对这几路视频进行合图,再将其发送给观众端。

主播和连麦者各路视频都使用RTMP推送到CDN,可以保证延时较小; 由于CDN进行视频合图和发送,所以主播不需要很高的带宽; 由于CDN进行视频合图,所以主播的设备不需要配置非常高; 没有声音干扰问题; 可以支持多个连麦者连麦;

不过,CDN需要进行视频的合图,需要额外开发工作,并且逻辑比较复杂; CDN需要进行视频的合图,需要消耗较高服务器资源; CDN合图后的布局难控制; 所以对CDN要求奇高;

在实际的网络直播中,我们常常会加入直播质量的监控,这里做了完备的数据上报及分析系统,基本上涵盖了各种关键性指标,既能反应直播的各种性能方便优化,同时也能辅助定位各种问题;这个是播放端的整体统计数据,下行带宽、卡顿率、缓冲大小、CPU占用率,这是一个宏观统计数据,反应了当前直播观看端的一个质量。有了直播质量监控,更精细一些我们可以做一些运营分析

基于上面的问题,有人提出了基于SD-RTN的解决方案,有兴趣的可以去搜一下。

客户端均通过UDP连接SD-RTN(Agora Global Network),通过SD-RTN的就近接入策略,让使用者就近接入质量最好的数据节点,通过Agora Global Network的软件定义优化路由,经过传输延迟和质量优化的最优路径,自动避免网络拥塞,并规避骨干网络故障的影响。

采用SD-RTN做直播有如下特点:

1、可以支持更多的主播交互,目前支持7人视频交互,100人语音交互。 2、当有观众连麦时,其他观众端收到的多路视频,观众端可以动态选择布局; 3、声网Agora.io会将直播视频推送到CDN,其他观众(网页端等)可以直接观看; 4、当有观众连麦时,声网Agora.io会将视频合图后推送到CDN,其他观众(网页端等)可以观看到连麦者与主播的互动; 5、在经过RTMP推流前的观众端,可以进行大小流切换,自主选择视频大小窗口的切换。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2016-11-02 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

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

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
面霸篇:秒杀系统如何设计
高并发下如何设计秒杀系统?这是一个高频面试题。这个问题看似简单,但是里面的水很深,它考查的是高并发场景下,从前端到后端多方面的知识。
码哥字节
2021/08/23
1.2K1
面霸篇:秒杀系统如何设计
面试必考:秒杀系统如何设计?
高并发下如何设计秒杀系统?这是一个高频面试题。这个问题看似简单,但是里面的水很深,它考查的是高并发场景下,从前端到后端多方面的知识。
苏三说技术
2021/08/17
18.1K6
秒杀系统设计
构建一个高并发、高可用的分布式微服务秒杀系统需要从架构设计、流量控制、数据一致性、缓存策略、数据库优化等多个方面综合考虑。以下是核心设计思路和关键技术点:
jack.yang
2025/04/05
3540
秒杀系统设计
秒杀技术瓶颈与解决之道
秒杀(Spike)是电子商务领域的一项重要业务,指的是在短时间内,大量用户竞相购买某一特定商品或服务。秒杀活动常常伴随着高并发、高延迟故障、商品售罄等挑战。本文将深入讨论秒杀技术瓶颈的原因,并提出一些解决之道,帮助您更好地应对秒杀活动中的挑战。
疯狂的KK
2023/09/25
4880
秒杀技术瓶颈与解决之道
如何设计一个秒杀系统,(高并发高可用分布式集群)
设计一个高并发、高可用的分布式秒杀系统是一个非常具有挑战性的任务,需要从架构、数据库、缓存、并发控制、降级限流等多个维度进行考虑。以下是一个典型的秒杀系统设计思路:
小马哥学JAVA
2024/07/04
3390
redis与mysql的数据一致性问题(事务一致性)
案例:考虑一个在线购物应用,其中有一个购物车服务,购物车信息存储在MySQL中,同时为了提高性能,购物车中的商品数量也被缓存到了Redis。用户在购物车中添加商品时,需要保证购物车数量在MySQL和Redis中的更新是原子性的,以避免不一致的情况。
GeekLiHua
2025/01/21
1420
redis与mysql的数据一致性问题(并发更新)
案例场景: 考虑一个在线购物系统,其中商品库存信息存储在MySQL数据库中,同时使用Redis缓存了商品库存以提高读取速度。多个用户同时购买同一商品,导致MySQL和Redis同时发生库存更新操作。
GeekLiHua
2025/01/21
940
基于代码实操SpringBoot、Redis、LUA秒杀系统!
本文主要目的还是用代码实现一下防止商品超卖的功能,所以像制定秒杀计划,展示商品等功能就不着重写了。
Java程序猿
2021/02/20
9870
在秒杀系统中redis的数据和mysql不一致了,要怎么检查出来了(概述)
在秒杀系统中,商品库存的管理通常会使用Redis进行缓存,以提高读取速度。但是,由于秒杀活动可能导致大量的并发请求,Redis中的库存数据与MySQL中的实际库存可能存在延迟,甚至不一致的情况。
GeekLiHua
2025/01/21
910
秒杀优化-基于阻塞队列实现秒杀优化
修改下单动作,现在我们去下单时,是通过lua表达式去原子执行判断逻辑,如果判断我出来不为0 ,则要么是库存不足,要么是重复下单,返回错误信息,如果是0,则把下单的逻辑保存到队列中去,然后异步执行
捞月亮的小北
2024/07/28
4130
秒杀系统之一致性
秒杀系统中,库存是个关键数据,卖不出去是个问题,超卖更是个问题。秒杀场景下的一致性问题,主要就是库存扣减的准确性问题。
终有链响
2024/07/29
2090
SpringCloud(十一)- 秒杀 抢购
Redis Incr 命令将 key 中储存的数字值增一。 如果 key 不存在,那么 key 的值会先被初始化为 0 ,然后再执行 INCR 操作。且将key的有效时间设置为长期有效 。
化羽羽
2022/12/01
1.2K0
SpringCloud(十一)- 秒杀 抢购
秒杀系统架构解析:应对高并发的艺术
对于各大电商平台而言,爆款运营和促销活动的日常化已成为常态,而支撑这些的秒杀系统自然是不可或缺的一环。同时,秒杀活动的巨大流量就像一头洪荒之兽,若控制不当,可能会冲击整个交易体系。因此,秒杀系统在交易体系中便扮演着至关重要的角色。
ThoughtWorks
2024/07/04
8860
秒杀系统架构解析:应对高并发的艺术
2025春招,高级程序员回答数据库问题
以下是V 哥对2025年数据库相关高频面试题的汇总整理,结合了MySQL的核心知识点和大厂实际考察方向,涵盖索引、事务、存储引擎、锁机制、优化策略等关键内容。
威哥爱编程
2025/02/10
2360
工作中这样用MQ,很香!
对很多小伙伴来说,刚接触MQ时,可能觉得它只是个“传话工具”,但用着用着,你会发现它简直是系统的“润滑剂”。
苏三说技术
2024/12/19
1670
工作中这样用MQ,很香!
数据库的事务
原子性(Atomicity):事务中的所有操作要么全部完成,要么全部不完成,不会结束在中间某个环节。
GeekLiHua
2024/08/30
1190
捣鼓一个电商功能设计
谷歌系统设计面试有一道题是关于如何设计秒杀架构,国外一位老哥给出了5种方法,下图是其中一种。
JavaSouth南哥
2024/10/16
1870
捣鼓一个电商功能设计
【高并发】高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!
作者个人研发的在高并发场景下,提供的简单、稳定、可扩展的延迟消息队列框架,具有精准的定时任务和延迟队列处理功能。自开源半年多以来,已成功为十几家中小型企业提供了精准定时调度方案,经受住了生产环境的考验。为使更多童鞋受益,现给出开源框架地址:
冰河
2020/10/29
2K0
【高并发】高并发秒杀系统架构解密,不是所有的秒杀都是秒杀!
MQ的数据一致性,如何保证?
上个月,我们有个电商系统出了个灵异事件:用户支付成功了,但订单状态死活不改成“已发货”。
苏三说技术
2025/03/28
2190
MQ的数据一致性,如何保证?
秒杀系统实战(五)| 如何优雅的实现订单异步处理
我回来啦,前段时间忙得不可开交。这段时间终于能喘口气了,继续把之前挖的坑填起来。写完上一篇秒杀系统(四):数据库与缓存双写一致性深入分析后,感觉文章深度一下子被我抬高了一些,现在构思新文章的时候,反而畏手畏脚,不敢随便写了。对于未来文章内容的想法,我写在了本文的末尾。
Rude3Knife的公众号
2020/07/14
3.9K0
秒杀系统实战(五)|  如何优雅的实现订单异步处理
相关推荐
面霸篇:秒杀系统如何设计
更多 >
目录
  • 手机直播连麦功能的特点
    • 连麦人数和显示位置
    • 连麦交互流程
  • CDN技术原理
    • CDN的常用架构
    • 采用CDN的缺点
      • 播放延时(网络延时)
      • 网络抖动
      • 网络丢包
      • 连麦
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档