<p>摘要：视频直播是现在互联网领域的一大热点，腾讯、百度、阿里等国内的几家互联网领军公司都在该领域投入了大量的人力、物力和财力，而移动视频直播相对于互联网直播而言难度更大，了解大公司在这上面所选择的技术路线，填坑的方案对于志在直播领域有所作为的公司而言是非常重要的。本文根据 360 高级技术经理殷宇辉在见云沙龙上的演讲整理而成。</p>    <p>大家好，我是来自 360的 殷宇辉，我讲的内容大概包括以下几部分：</p>    <p>1.     移动直播的背景现状</p>    <p>2.     移动直播的基础架构</p>    <p>  3.    360直播云发展历程</p>    <p>2016年是直播发展元年，最早的时候Meerkat和Periscope这两款应用引爆了市场。目前国内直播市场几乎是一片红海，大概有两百多个直播APP，在这里面我大概会把它分成四个象限。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/a284dc1828aefe7be31383b00dba58b6.jpg"></p>    <p>直播需求分类</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/e1eecc5883e4942b9a26daedd224ad3c.jpg"></p>    <p>1. 资讯类 。资讯类主要是像传统的演唱会或者体育赛事直播，它的特点是所有的信号都需要经过审核，所以它是一个先审后发、技术上主动加延迟的方式，就是你看到的画面可能是加了大概30秒，或者40秒的延迟。</p>    <p>2. 游戏直播 。大家知道特别火的斗鱼、熊猫等平台，它们的特点第一是信号来源相对单一，主要是OBS录屏。第二是帧率都比较高，大概在30帧以上，对于游戏直播，如果帧率较低会导致画面迟滞。</p>    <p>3. IoT领域 。IoT领域主要以监控为主，大家比较熟悉的有360小水滴、小蚁、萤石，这块它主要的要求是加密传输和低延迟，基本不会走RTMP协议。</p>    <p>4. 泛娱乐 。这是目前兵家的必争之地，已经有大量的APP杀进来了，领头的是映客、YY和花椒这几个，这块机型比较复杂，也强调实时互动性。</p>    <p>基本直播流程</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/9fb26b47032d6d5deb32e4bae45d9154.jpg"></p>    <p>这是一个最简单的直播流程，首先它会通过采集端的采集处理，经过编码封包，编码封包主要使用H264/AAC格式，H265现在还没到大规模商用阶段，编码封包之后就是推流，这块大家可能比较熟悉，如使用开源的libRtmp，然后会推到CDN，CDN里面可能会做一些流分发和流处理，流处理主要是回放和截图的处理以及一些状态回调，在看播端主要是从CDN上拉流，然后进行解码播放。</p>    <p>移动直播基础组件</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/bd460956a45e4597a13f5e62257b4cc9.jpg"></p>    <p>刚才有同学提到了，如果我们做个创业APP，那应该怎么做合适呢？就目前来说，找一个成熟的云平台就够了。我们专心做业务就好，也就是上图中业务层的事情。  其余的服务组件和直播流的部分都可以包给第三方服务商。</p>    <p>360直播历程</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/f14b64e7ebc8e27397f0d40f048aa357.jpg"></p>    <p>下面是360直播的历程，大家可以从图上看到，我们做直播是比较早的，我们最早进入该领域是在智能硬件特别火的时候，我们做了水滴直播，然后从2015年3月开始决定做花椒直播，做花椒直播到现在，业务方和平台方差不多已经处于相对稳定的状态，所以我们逐渐开始在内部成立一个私有云平台，以支持所有的音视频业务。</p>    <p>目前的现状是，像水滴的并发峰值大概有四万路，属于直播行业相对较高的一个量级。对我们而言，也是一个巨大挑战。当业务量没上去的时候可能没什么问题，但是业务量上去以后一切都是问题。比如存储，我们每天大概有近百T的存储，我们怎么处理这些海量的数据，以及高并发的直播流呢？</p>    <p>水滴直播-业务场景</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/bb2c9ae9e4800eea63a02501b056b920.jpg"></p>    <p>上面这个图是水滴的一个典型使用场景，它主要是用来看家看店的，最近有不少新闻说用户家进贼了，最后是小水滴自动触发报警，把对应的图像等等信息都存下来，最后公安根据这些信息找到了犯罪嫌疑人。它对底层技术要求比较多：</p>    <p>1.低延时 <strong> 。 </strong></p>    <p>2. 全双工。 全双工的意思是什么呢？就是家里可能进贼了，然后你拿着你的手机，你喊句话摄像头马上就能把你的声音给传出来。就是你在摄像头端，我在APP端，咱俩是可以相互交互的。</p>    <p>3. 数据加密传输。 因为它涉及一些隐私，所以一般不会用RTMP这种协议。</p>    <p>4. 实时云存。 家里 如果发生什么事件，这些事件是能及时在云端存下来的。</p>    <p>5. 能分享。 像一些房地产商，他用水滴实时拍摄样板间的室内全景，然后可以通过H5分享给目标客户，这块我们会进行私有流到公有流的转化。</p>    <p>下面这个图是水滴服务大概的调度流程，大家可以简单看一下，之后我会分模块拆解。</p>    <p>服务流程</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/7415ba9fffdd3d4eed19019bdb09bcdd.jpg"></p>    <p>首先水滴和花椒这种直播形式不太一样，其他的直播属于主播已经开流了，我只要调度观众端，而水滴的模式是APP端想去看某个摄像头的时候才去调动这个摄像头往上推流，它有一个实时调度这个摄像头去推流的过程。</p>    <p>大家可以看到，当我在APP端请求观看的时候，业务服务器会通过调度中心拿到两个地址，一个是摄像头的推流地址，一个是APP端的看流地址，摄像头会把私有流分发到我们的一个私有网络，APP端拿到这个私有流就可以开播、看播。最下面画的主要是实现H5分享的功能，我们会把私有流在需要的时候经过流转换器，转换成RTMP流之后推到直播源站，让第三方CDN进来回源，这样PC、H5端都可以去看。</p>    <p>后面是我们的云存服务，就是我们有直播，也要有录像，这个录像对手机来说也不能24小时全录，因为成本太高了，它会在流里面去找一些标识，然后把对应的内容存下来，需要观看的时候，如果访问量大的话走CDN，量不大的时候直接走我们的源站。</p>    <p>底层部署</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/f71f8d6202adaa28c4bd6c13c63eb0a1.jpg"></p>    <p>在整体架构底层部署方面，我们是有光纤的，我们在国内重点地区以及海外都有光纤或者专线的互联节点，核心的互联光纤节点主要是负责一些大区域及运营商，南北联通电信这些比较大的区，主要是做一些流转发以及数据处理之类的工作，每个节点之间，都是双向光纤互联。</p>    <p>第二块是二级的区域中心节点，主要负责一些地方大区，像北京联通或北京电信，它会有三通落地，也就是出口可能有电信、联通以及移动，它和我们内部的一级节点是光纤打通的，然后下面和我们边缘的二级节点之间可以走对应的ISP网络，避免跨运营商。</p>    <p>传输协议</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/1b911a9d88367ef8244b29a242552b9e.jpg"></p>    <p>大家知道TCP有一些问题，比如拥塞控制等；然后TCP如果加上TLS之后，流程更多，带来的延迟也更大。因为手机直播对延迟要求比较高，传统UDP不可靠，如果用来传音视频，丢包会产生黑屏、花屏这些现象，所以我们自己封装了一个底层传输框架，它提供像TCP、可靠UDP以及不可靠UDP这些传输协议，使用可靠 UDP的时候，能实时控制滑动窗口、吞吐量等方面。经过我们的线上实测，主播上行的UDP连通率在95%以上。弱网等情况下，可靠UDP的表现也远超TCP。</p>    <p>调度系统</p>    <p>我们调度是HTTP服务，它会响应开流、看流的这些请求，返回对应的节点列表，这里我们也是返回多个IP，让客户端去测试，选择最优节点。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/9553c140ddcbb2ce0271d1a0478f442d.jpg"></p>    <p>大家可以看到，我们的私有网络跟传统CDN不太一样。</p>    <p>1. 它会把自己的一些管理信息，以及节点的负载等信息同步调度给服务器。</p>    <p>2. 我们的运维系统，比如说今天华北或者广州某个节点有网络割接，要把这个节点下掉，那么通过我们的应用系统实时就能下掉，这些信息都会同步给调度服务器，调度服务器本身是无状态的，它挂了之后，重启就可以，它没有持久化的工作。</p>    <p>除了这两块，我们后续还会有些信息返回到调度服务器，比如说根据区域算的实时卡顿率等，具体怎么算待会会讲。这是调度系统的一个基本情况。</p>    <p>分发系统</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/9553c140ddcbb2ce0271d1a0478f442d.jpg"></p>    <p>我们的分发网络，主要是为了水滴的实时流服务，它跟传统的CDN有本质的区别。传统CDN是层次状，金字塔形的，所有的流推上来必须要到最高的顶点再往下分发。就是说：</p>    <p>1. 它的传输链条比较长；</p>    <p>2. 它是一个完全单向的连接，如果要在这个网络上实现我刚才提到的“从APP端说句话，摄像端实时播出来”是不可能的。</p>    <p>基于CDN去改造也是比较困难的事情，所以我们自己在下面做了一个私有的分发网络，它的特点是：</p>    <p>1. 我们所有的连接都是双向的，就是保证能下去，也能反向回来；</p>    <p>2. 我们有一个节点管理的Manager。管理拓扑层次是分层的，原因是因为有些地方的网络节点之间不互通，这时我们会找就近的，所以管理是分层考虑的，但是实时推拉流不是这样做的 ，因为我们有中心节点，记录了实时流的所有信息，以及拓扑情况，所以在进行推拉流的时候，会去内部查询一下。这样的话，你可以实现完全图状的一个网络，就是几乎你可以找到离你最近的一个节点进行拉流，或者推流。</p>    <p>回放服务</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/0292fd796cdecd9c19ab797695e0cec1.jpg"></p>    <p>回放这个事情我们是通过摄像头端做实时触发，当服务端收到这个录制信号之后去决定要不要进行切片存储，当摄像头端的事件结束之后，它告诉我结束录制，我就生成对应的回放地址，并把这个地址回调给业务，这时候业务实时拿来就能看了。这里我们依托了360最大的Cassandra集群去做这个事情，所有的切片都是按照HLS协议去切的，这样做，一是相对简单，二是HLS协议的平台兼容性比较好。</p>    <p>经验总结</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/700355532ad4f9373940f33fc5a30bd3.jpg"></p>    <p>1. 成本。 现在去看下水滴，每个摄像头就一百多元，成本可能占大部分，如果算上返修率、坏件率，几乎不挣钱。但是你还要卖云服务，云服务这块就比较麻烦了，像我们的存储，如果一直录的话，成本是非常高的，用户是接受不了的。我们是用触发的方式，就是刚才提到的，摄像头端把控制信息带在流里面，然后它告诉我这个要存几天，存7天，还是15天，还是半年。每个套餐我们有不同的价格，我们是这样做的，目前的话，像水滴里面用这种付费云存的用户大概占到10%，这也是互联网硬件逐渐走向盈利的一个模式。</p>    <p>2.联通性 。因为硬件和软件不一样，像花椒，你打不开了可以用陌陌，或者用映客，但是摄像头如果打不开的话，用户会选择退货、赔偿。所以我们在前期做了很多工作，第一是调度返回多个IP，然后摄像头和播放端进行测速；第二是传输层同时支持UDP和TCP，当UDP走不通的时候走TCP，好歹能让用户能连通。第三是同网情况优先使用P2P直连，在前面这张PPT里面，我画了一条虚线，P2P直连的方案，它会通过我们的分发系统，拿到对应的信息，相当于做了一个隧道，之后的话，直接走P2P网络。</p>    <p>3. 策略。</p>    <p>（1） 我们如何保持、保证这种比较低延迟的效果，我们要替用户跨省、跨运营商，这也是根据我们公司的一些特点，我北京的一个用户，北京电信的开播，然后我是一个湖北联通的，那可以通过我的光纤去帮他跨一下，两端都找到同运营商去接入，中间一段有我们光纤的穿透，效果会比较好。</p>    <p>（2 ）加解密，不用对整个数据段进行加密，只加密帧数据就行，这样的话，再做云存比较方便。我们第一版的时候，没有仔细考虑这一块，后来踩了一些坑，只能在服务端进行加解密，后来压力上来就扛不住了。采用新方案之后当只对帧数据加密的时候，在服务端进行容器格式转化，不需要解密就可以把直播流封装成HLS文件，当业务播放时才去解密。</p>    <p>4. 存储和流分发。 这一块最早的时候我们的量比较小，对我们影响不大，但是后来水滴云存每天大概上百个T，流量实在是太大了，我们就选择把存储服务和流服务部署在相近机房，这样节省了内网的传输带宽，数据写入延迟大幅降低，这是做水滴的一些经验。</p>    <p>花椒直播-新的挑战</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/5a678dfa57dea7a62f47e3ad55c3d65c.jpg"></p>    <p>当我们开始做花椒之后，我们早期是把水滴那套方案快速上线，直接先挪过去，最后发现很多问题，大家可以看看我列出来的一些情况。</p>    <p>1. 推流场景复杂。 用水滴的时候，我只有一个摄像头可用，没有其他的东西，它的帧率码率都是硬件厂商那边调优很久之后确定的。但是花椒有安卓、iOS、OBS各种平台，像安卓碎片化，在每个手机上是否支持硬编硬解，支持的好不好等，像我们经常遇到开了硬编的机器它的码率、帧率会跳动。另外是编码格式，做水滴时候我们主要用I帧和P帧，就是BaseLine的Profile，也不会提供High和Main这种profile的支持，因为B帧有可能带来部分解码延迟，但是做花椒的时候，各种格式都要支持。</p>    <p>2. 需求爆炸。 端上面的功能越来越多，像美颜、face++、礼物特效，以及像我们也推出过VR直播还有多路连麦的功能。这里面有几个问题，一是CPU会争抢，二是底层各种SDK可能冲突，比如像连麦的SDK；播放器的SDK可能会有冲突，以及对音视频设备抢占的处理问题。</p>    <p>3. 运营事件复杂。 像刚才也提到过，现场网络不可控，我怎么去拨测，流量也不能预估，有时候可能哪个明星突然某天心情好了，他偷偷上来，这种我们最害怕。再就是主播的网络，他开车，就是边移动边播放，然后动不动开WiFi切4G，像这种也是比较麻烦的。</p>    <p>4.海外用户增多。 有些主播他在法国或者北欧，还每天播，我们有个法国某小镇的小伙子，每天直播打太极，逛街，像这种情况的推流质量难以保障。</p>    <p>解决方案</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/39b4343a7618f2c4fd6654f500cea336.jpg"></p>    <p>我们遇到这些问题之后，逐渐采取了一些解决方法，因为我们开始得比较早，还没有人能提供全平台的运营商，但我们的思路比较好，第一把业务底下的流都拆开，端上面统一SDK，然后云端统一流分发以及处理服务；业务的话，只专注自己的APP以及服务端，这里面有两个关键的技术。</p>    <p>1. 多家CDN融合。 我们会让其他每家CDN去做一个汇聚转推，就是他在自己的节点内进行汇聚，汇聚完之后转推到我的直播源站，相当于到直播源站之后，后面的存储以及截图等事情还是由我统一来提供，用户观看回放的时候也会走多家CDN，这时他统一都要来我这边回源。我们不希望跟CDN绑太紧，目前有些直播会把录像这件事情交给某家CDN，回头你想迁数据，或者说你想把这家CDN迁走的时候，你的数据是比较难迁移的，在这里面，我们用多家CDN会有几个策略：</p>    <p>（1） 在正常情况下，我们倾向于自洽，就是开流开到那家，那我观看就会调到哪家，这个第一是为了对比多家CDN的质量，第二个是为了避免复杂性。</p>    <p>（2） 溢出机制，比如说像张继科、范冰冰，他们一开播，那流量一下就跑上去了，可能像我们用的网宿一家抗不住，那我们就会把它下行，放到其他家的CDN，这样其他CDN就过来进行回源。</p>    <p>2. 客户端实时反馈 ，在客户端会有实时的统计，这里面大概有些维度，我大概给大家介绍一下。</p>    <p>（1） 推流，帧率，码率，宽高，丢帧率。这一块我们做得策略比较多，比方说像动态支持率码率和分辨率，这些都是可调的。</p>    <p>（2） 播放。我们主要关心的是在线，卡顿，首屏，延迟。</p>    <p>3. 业务层面。 比如说用户的直播ID，一个ID可以贯穿全流程，可以通过这一个ID去追溯；还有会话ID，我在一次直播里只有一个会话ID，通过这个Session可以贯穿从业务端到底下云端，以及数据分析的全流程。</p>    <p>4. 传输。 我们传输第一是用了多协议，第二个是用了多CDN，这些标志我们都要标注出来。第三是用了测速，最后客户端实际连了哪个IP，以及它的一些连接状态，有没有中途切换网络等。</p>    <p>5. 物理信息， 像设备类型，网络类型，以及iOS，安卓的一些系统版本，以及CPU、GPU占用，有些礼物特效对CPU、GPU的耗用特别大，有时候如果到90%的CPU，那观众端看流都会卡。</p>    <p>6. 流程。 无论在调度阶段，还是在数据获取阶段，还是在业务交互阶段，失败，那这个失败率，我们也都会通过这个实时反馈。</p>    <p>评判体系</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/361837ece0c7ec432ca9674b86b7664c.jpg"></p>    <p>我们大概关心三块，稳定性、成本和效果。稳定性、成本这块就不多讲了，这里主要讲下效果。我们会有一些指标，比如像首屏时延、平均时延、推流看流卡率以及请求失败率。</p>    <p>那么怎么不在实验室环境计算这个延迟，很多CDN厂商号称自己是秒级延迟，一到三秒，其实他是只测传输网络，不会测端对端，如果端对端的话，加上端的buffer，加上GoP的cache的buffer会很大。我们是通过在推流端加了一个时间戳，在看流端解除这个时间戳去做对比，当然了，每个主播端的时间戳都不一样，我们通过一个标准服务器去做了校正，校正完之后，只选可信的，不可信的扔掉，这是我们实际得到的一个图。</p>    <p>大家看这个卡顿率，是相对偏高的，像电商类、或者游戏类的直播，它的卡顿率一般会在3%到5%之间，原因是他们OBS推的比较稳 定。第二，他们的延迟比较高，他们不在乎延迟，他们延迟可能比移动互动直播更高一些，像我们展示这些图，会有不同的维度，比如时间、业务、CDN厂商、版本、运营商、地域等，这些维度，也会有实时、离线两个大的维度。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/d4a85121664e7474c9c1e9116bd66dbb.jpg"></p>    <p>这一章是刚才说的几个指标里面， CDN的一个对比，大家可以看一下。延迟计算方式是我们最近才摸索出来的，这也是最近才上线的一个功能，所以数据不是特别稳。大家可以看到，移动直播推流端的卡顿率非常重要，几乎有时候能到10%左右。观看端的话，大家也能看到大概的一个情况。首屏时间，看这张图有很大差异，蓝色这 条线呢，是我们私有的传输，可以大致看到相比RTMP协议，还是有优势的。</p>    <p>经验总结</p>    <p>花椒这一块经验的话，大概有这么几类，大家可以看一下。</p>    <p>1.体验类。 滑屏卡顿一方面通过调度预加载、本地结果缓存来减少流程，另一方面还有一些SDK冲突的，因为现在在端上有很多SDK，美颜滤镜的、多路连麦的，以及自己的播放SDK，这些SDK之间相处并不太平。录制卡顿这块，我们目前大概会在上行端去做自适应码率，就是通过主播端的网络去自适应，主动地降码率，帧率，也可以通过服务端发指令，把码率降下去。覆盖的话，我们会根据优势区域去分配CDN，比如说海外可能网宿覆盖比较好，我们优先把海外的主播调到网宿。</p>    <p>2.效果类方面 ，大家比较关心的像首屏秒开目前几乎是没什么秘密，首先是服务端的一个GoP cache设置，再就是推流端的GoP间隔。比方说你是15，你每个GoP大概是几秒，目前我们大概是两秒一个GoP。还有客户端的Buffer策略，等到第一个关键帧，还是把Buffer堆满再播放。</p>    <p>保障效果的第二块是延迟，目前看，对移动直播会比较重要一些，它会涉及到流的特效展示，比如说我有一个大土豪可能给某个主播送了一个效果特别赞的礼物，但是隔了一分钟还没看到，这就不行了，所以这里面有追帧的逻辑，我们可能会根据流里面的时间戳，发现差异过大，就把前面的快进，两倍速度、三倍速度播放掉。</p>    <p>3.监控类。 监控类我们目前会有一个实时流反馈，主要采集的维度刚才也讲过了。我们会做一些底层的自动化应用。</p>    <p>（1）后 <strong>台监控</strong> ，在后台有一个图片墙，图片墙上会展示每个流的状态、当前的帧率、码率，以及主播是否切后台等信息。</p>    <p>（2）热榜切换 ，比方说主播已经切后台了，那我立马就把你从热榜上切下去，不要让你继续占着热榜，因为所有人点进来之后都是黑的。</p>    <p>（3）多CDN监控 ，我们会进行链条式的监控，在主播的推流段，在上行的第一个推流点，再转推点，我们都要求CDN做了实时监控，这样能实时具体定位到哪一段出了问题。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/acaa06e09c484ee80c0fb07339c180af.jpg"></p>    <p>做完前面两个产品之后，我们也在同步做一些事情，因为我们发现我们提供的越来越底层，所以我们希望把一些基础的技术汇集起来，在这里，我们主要是依托360的一些基础技术，因为360有一个比较成熟的基础网络架构，像刚才说的多点多层互联，再就是它有比较好的运维体系，目前的话，我们申请机器、申请服务、Redis、MySQL这些全都是线上自动完成。</p>    <p>然后融合的话：</p>    <p>（1）我们对CDN开放，我们选择多家CDN接入；</p>    <p>（2） 连麦技术也在做融合，因为让每个APP厂商去接入难度还是相当大的。</p>    <p>（3） 大数据的一些分析处理能力，比如像截图鉴黄，以及其他的分析，外面有些厂商做的比较好，我们也会积极地把它拉进来。</p>    <p>（4） 人工智能处理，这块比较典型的一个应用场景是，你家里如果装了小水滴，它可能过一段时间就会认识你，你回家，它大概就知道你回来了，如果是陌生人它就会报警，这是有人工智能学习在里面的。</p>    <p>依托主要是依托360基础服务，融合是融合外部厂家各自擅长的技术。我们自己则主要是专注直播这个领域：</p>    <p>（1） 我们提供一个高可用，易接入的SDK；</p>    <p>（2） 针对低延迟高互动的直播场景，我们不太想做传统的那种演唱会的直播，它的技术含量相对较低。</p>    <p>（3） 提供比较丰富的直播相关的组件服务，像云点播、一站式直播，以及云存储、融合CDN加速等服务。</p>    <p>发展方向讨论</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/51c59de99a0e0fb4b6b60014910bb2fb.jpg"></p>    <p>接下来再跟大家分享一下一些发展方向方面的东西。</p>    <p>1. 一些建议，针对目前有意做直播的创业者、创业团队，要以精细化和垂直化的直播场景为主，因为大家现在建一个直播APP非常快，可能花半天，如果用现成的云服务商SDK，基本推流看流能跑通了，然后再把其他的长连接等等整进来，花一周可能我的Demo就出来了，然后发现业务场景完全起不来，因为现在做直播的太多了，必须得去做垂直化，场景化。</p>    <p>2. 我觉得目前从我们的经验看，常态下是多房间少量观众为主，不排除偶尔有个大主播，比如说像几十万的在线用户。第三块是互动会越来越丰富，因为现在美颜滤镜都属于比较低级的了，大一点的像面部特效，以及像多人连麦互动这种都加了。</p>    <p>云服务提供商方面，你一定要去判断，它具不具备多端统一SDK的能力，是否开放一些数据分析的能力。现在有些云服务商，他实际上是可以把端上面的采点数据都报给你，这样你查问题会更方便一些，就不至于说我接了一个黑盒什么都干不了。再就是他的CDN覆盖网络是否优质，是否能让你自己去选择CDN。在底层技术这块，我觉得未来的话，低延迟互动一定是重要的方向，低延迟五百毫秒都偏高了，正常应该是三百到四百毫秒左右。</p>    <p>Q： 刚才您PPT里面看到了连麦，目前我们也在做连麦，你们用的是服务端的方式，我们目前正在用的客户端的方式，你为什么没有选择客户端的方式？</p>    <p>A： 是这样的，客户端和服务端两种方式各有优劣，应用场景也不太一样，你们是基于WebRTC？还是自研？客户端合成,它对主播端手机有消耗，你如果在做一对一的还比较好做，你如果做多人与你聊天，那全放在客户端是不太合适的，我们目前的方式有两点考虑：</p>    <p>(1)我们私有网络已经搭建好了，可以去做这种基于私有网络的多入流的转发；</p>    <p>(2)我们觉得在客户端合流满足一对一的应用是没问题的，但是我觉得最终的话多人连麦互动可 能是未 来的方向，在服务端会相对轻松一些。</p>    <p>Q： 对音视频怎么同步？</p>    <p>A： 我们主要还是基于流里面的时间戳为准，视频参考音频。</p>    <p>Q： 直播流如何能够快速的实现串网，主动推流到根节点吗？</p>    <p>A： 其实刚才我少讲了一点，就是我们其实不是主动推，我们有多种策略，你比方说像摄像头的策略，它其实是要求中间的环节越少越好，我们大概是三跳。像一个人播，多人看的这种场景，我们会根据这种热门列表有一个互推，预热大区节点。我们会根据不同的业务场景做不同的一些尝试，也有不同策略。</p>    <p>Q： 我刚才看陌陌，还有咱们360都是采用RTMP的方式，其实传统的运营商他们都是采用RTSP的方式，那么你们对于选型是出于什么考虑？</p>    <p>A： 我们最早也看过这些东西，像传统的摄像头主要是采用 RTSP协议。而像花椒里面主要是RTMP，原因是因为，这也要看CDN厂商支持啥，玩法是啥，我们是一个互联网公司，都是偏互联网化的，如果做传统的视频监控的话，倾向于使用RTSP。</p>    <p> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s/hs6UxNoRofyUJ0Ny6Vm3Qw</p>    <p> </p>