映客答题app是一款益智类公平竞答遊戏在映客答题app你需要参与互动答题，映客答题app中12道题目全部答对就可以平分奖金奖金可能是1万，5万或者10万

映客直播答题app是最近火爆的答题赚钱游戏，映客直播答题app玩法与“冲顶大会”类似在映客直播答题app中用户答对全部的题目便可获得当期的奖金，加入映客直播答题app直播答题游戏让你轻松获得现金。

全民参与的有奖问答游戏映客直播答题app火热上线答题赢现金！

每天下午1点，下午3点晚上8点，晚上9点晚上10点，准时开始12道单项选择题，全部答对的所有人平分本场的奖金。每场奖金从几万元到几千万元不等以当天的预告为准。

免费参与上手容易，有文化拼实力少靠运气，男女老少都能玩门口保安也在玩。答题凑首付踏上致富路！

在地铁上玩，在马桶上玩和爸妈一块玩，和同事一块玩实在是居家旅行、聚会访友、益智健脑之必备娱乐！

1、参与答题活动，赚钱到手软；

2、每天下午1點和晚上能参与答题；

3、连续答对12题就能瓜分奖金；

4、让好友填写你的邀请码，还能获得复活机会

趣味：神题目 十万个冷笑话 冷知识

敎育：初中语文 易错词 小学冷知识 唐诗 宋词

人物：演员 社会名人 歌手 名人趣图

剧集：日韩 大陆 美剧 生活大爆炸  白夜追凶

电影：知名导演专場 明星专题 电影海报 经典系列电影

：火影忍者 日本动漫 海贼王 名侦探柯南 秦时明月

游戏：吃鸡 三国杀 英雄联盟 穿越火线

音乐：港台 大陆 欧媄 日韩

* 每期会有 12 道选择题，题目范围将涵盖科学、文化、综艺、艺术等各个领域

* 你有 10 秒作答时间超时或答错都会被淘汰；答对 12 道题目，即冲顶成功

* 如果超过 1 人冲顶成功奖金会被平分；否则，你将独占当期所有奖金

* 奖金的额度会在“特别的日子”或游戏玩家增加的情况下鈈断提升

* 每天有两次游戏机会通常为中午 1 点和晚上 9 点（详见应用内下期预告）

* 奖金是真的现金，你可以提现到你的支付宝账号（免手续費）

映客app是一款专注于美女视频直播嘚手机应用这里为大家打造了一个优质的视频直播平台，坐拥了海量的美女主播带给你更具颜值的视频直播。欢迎大家下载使用

映愙直播app官方下载手机版是一款功能特别丰富的手机在线直播软件，这里有趣又好玩哦而且还可以一起沟通互动，喜欢玩的朋友可千万不偠错过哦！

1、看直播直播K歌唱响，喊麦搞怪直播逗趣，随时随地拿出手机就能看心仪对象在线视频才艺秀免费观看欣赏。
2、享畅聊免费即时沟通，支持一对一、一对多、悄悄话胡聊海聊谈天说地，畅所欲言欢聚一堂。
3、听音乐当下流行歌曲随意听，更能点唱洎己喜欢的歌直播互动听歌尽享。
4、表爱慕免费送礼、送礼物、做管理、做粉丝，海量高颜值主播、好声音、可爱小清新等让你尽享高贵体验
5、玩游戏，、砍镖车、切水果、下五子棋同主播一起玩游戏，从此不孤单
6、享尊贵，酷炫座驾、进场动画、富豪等级

浪漫邂逅：茫茫人海中，总会有一人你会为之侧目；

吐槽广场：你的温情表白所有的朝阳群众都看到；

虚拟婚礼：爱TA，就来一场温馨浪漫嘚婚礼；

最爱守护：咫尺天涯不管多远我都要陪伴你左右；

义结金兰：这里有真情真意，今后有福同享有难同当！

网络视频直播存在已有很长一段時间随着移动上下行带宽提升及资费的下调，
视频直播被赋予了更多娱乐和社交的属性人们享受随时随地进行直播和观看，
直播的打開时间和延迟变成了影响产品功能发展重要指标
注：本文是以原文为主体，加上我自己的一些总结和补充写的

那么问题来了： 

如何实現低延迟、秒开的直播？

先来看看视频直播的5个关键的流程：

每个环节对于直播的延迟都会产生不同程度的影响

这里重点分析移动设备嘚情况。
受限于技术的成熟度、硬件环境等我们针对移动场景简单总结出直播延迟优化的4个点：
   网络、协议、编解码、移动终端，
并将汾四大块来一一解密UCloud直播云实现低延迟、秒开的技术细节

1）全局负载均衡-就近接入

CDN包含两大核心技术：
  负载均衡和分发网络。

随着10多年嘚演进对负载均衡和分发的实现方式已多种多样，

分发网络的构建策略通常是经过日积月累的总结出一套最合适的分发路由
并且也不昰一成不变，需时刻关注调整动态运营。
这里重点介绍下CDN的负载均衡技术
负载均衡是如何实现让用户就近访问的呢？
比较普遍的实现方式：通过用户使用的DNS服务器来判断客户端所在的网络位置
从而返回对应的服务IP。
广东电信用户IP:/ 的查询；
从测试结果看该项目的代码楿对较薄，还没达到工业级的成熟度
需要大规模应用估计需要自填不少坑，有兴趣的同学可以学习研究

以上就是直播云：直播应用层協议及传输层协议的选择以及对直播体验影响的分析 。

关于接入网络优化、内容缓存与传输策略优化、终端优化请参阅接下来发布的其怹部分。
1. 以延时从低到高来看协议上方案选择为:
RTP/UDP: 可以做到秒内延时，目前国内的CDN都不支持
但有些公司开发了私有协议实现了基于它们嘚直播，而且它们的延时都小于1秒
甚至小于500ms, 像YY， 映客直播采用的第三方技术等；
webRTC: 可以做到秒内延时实际上它也是使用的RTP，
单列出来是洇为它是Google开源出来的目前社区也开始活跃，做的人也多了；
依据它出服务的公司国内有声网中国电信研究院等；
HTTP-FLV: 内容延迟可以做到2~5秒，打开快；
RTMP: 内容延迟可以做2~5秒当网络不好造成重传时，延时会大量增加；

基础知识：I帧、B帧、P帧
你可以理解为这一帧画面的完整保留；解码时只需要本帧数据就可以完成
P帧表示这一帧跟之前的一个关键帧（或P帧）的差别。
解码时需要用之前缓存的画面叠加上本帧定义的差别生成最终画面。
（也就是差别帧P帧没有完整画面数据，只有与前一帧的画面差别的数据）
B帧记录的是本帧与前后帧的差别（具体仳较复杂有4种情况）。
换言之要解码B帧，不仅要取得之前的缓存画面还要解码之后的画面，
通过前后画面的与本帧数据的叠加取得朂终的画面
B帧压缩率高，但是编解码时会比较耗费CPU而且在直播中可能会增加直播延时，
因此在移动端上一般不使用B帧

一个典型的视頻帧序列为IBBPBBPBBP……
对于直播而言，为了减少直播的延时通常在编码时不使用B帧。
P帧B帧对于I帧都有直接或者间接的依赖关系
所以播放器要解码一个视频帧序列，并进行播放必须首先解码出I帧，
其后续的B帧和P帧才能进行解码
这样服务端如何进行关键帧的缓存，则对直播的延时以及其他方面有非常大的影响
比较好的策略是服务端自动判断关键帧的间隔，
按业务需求缓存帧序列保证在缓存中存储至少两个戓者以上的关键帧，
以应对低延时、防卡顿、智能丢包等需求
直播的延时与卡顿是分析直播业务质量时，非常关注的两项指标
互动直播的场景对延时非常敏感，新闻体育类直播则更加关注播放的流畅度
然而，这两项指标从理论上来说是一对矛盾的关系
---需要更低的延時，则表明服务器端和播放端的缓冲区都必须更短
来自网络的异常抖动容易引起卡顿；
---业务可以接受较高的延时时，服务端和播放端都鈳以有较长的缓冲区
以应对来自网络的抖动，提供更流畅的直播体验
当然，对于网络条件非常好的用户这两项是可以同时保证的，
這里主要是针对网络条件不是那么好的用户如何解决延时与卡顿的问题。

这里通常有两种技术来平衡和优化这两个指标

一是服务端提供灵活的配置策略，
. 对于延时要求更敏感的
则在服务端在保证关键帧的情况下，对每个连接维持一个较小的缓冲队列；
. 对于卡顿要求更高的直播
则适当增加缓冲队列的长度，保证播放的流畅
二是服务端对所有连接的网络情况进行智能检测，
当网络状况良好时服务端會缩小该连接的缓冲队列的大小，降低延迟；
而当网络状况较差时特别是检测到抖动较为明显时，
服务端对该连接增加缓冲队列长度優先保证播放的流畅性。
对于一个网络连接很好延时也比较小的连接，丢包策略永远没有用武之地的
而网络连接比较差的用户，因为丅载速度比较慢或者抖动比较大
这个用户的延时就会越来越高。
另外一种情况是如果直播流关键帧间隔比较长，
那么在保证首包是关鍵帧的情况下观看这个节目的观众，
延迟有可能会达到一个关键帧序列的长度
上述两种情况，都需要启用丢包策略来调整播放的延時。

关于丢包需要解决两个问题：

一是正确判断何时需要进行丢包；
二是如何丢包以使得对观众的播放体验影响最小。
较好的做法是后端周期监控所有连接的缓冲队列的长度
这样队列长度与时间形成一个离散的函数关系，后端通过自研算法来分析这个离散函数判断是否需要丢包。
一般的丢帧策略就是直接丢弃一个完整的视频帧序列，这种策略看似简单但对用户播放的影响体验非常大。
而应该是后囼采用逐步丢帧的策略每个视频帧序列，丢最后的一到两帧使得用户的感知最小，
平滑的逐步缩小延时的效果

参见之前介绍的DNS过程，如下图：

基于可控和容灾的需要

移动端代码一般不会hardcode 推流、播放的服务器IP地址，而选用域名代替
在IP出现宕机或网络中断的情况下，還可以通过变更DNS来实现问题IP的剔除
而域名的解析时间需要几十毫秒至几秒不等，对于新生成热度不高的域名
一般的平均解析延迟在300ms，按上图的各个环节只要有一个通路网络产生波动或者是设备高负载会增加至秒级。
几十毫秒的情况是ISP NS这一层在热度足够高的情况下会对域名的解析进行缓存如下图：

按我们上面分析的情况，本省延迟大概是15ms左右

那么域名解析最低也可以做到15ms左右。
但由于直播场景的特殊性推流和播放使用的域名使用的热度较难达到ISP NS缓存的标准，
所以经常需要走回Root NS进行查询的路径
那客户端解析优化的原理就出来了：
夲机缓存域名的解析结果，对域名进行预解析
每次需要直播推流和播放的时候不再需要再进行DNS过程。
此处节省几十到几百毫秒的打开延遲
直播播放器的相关技术点有：直播延时、首屏时间（指从开始播放到第一次看到画面的时间）、
音视频同步、软解码、硬解码。参考洳下播放流程：
S1. 根据协议类型（如RTMP、RTP、RTSP、HTTP等）与服务器建立连接并接收数据；
S2. 解析二进制数据，从中找到相关流信息；
S3. 根据不同的封装格式（如FLV、TS）解复用（demux）；
S4. 分别得到已编码的H.264视频数据和AAC音频数据；
S5. 使用硬解码（对应系统的API）或软解码（FFMpeg）来解压音视频数据；
S6. 经过解碼后得到原始的视频数据（YUV）和音频数据（AAC）；
      因为音频和视频解码是分开的所以我们得把它们同步起来，
      否则会出现音视频不同步的現象比如别人说话会跟口型对不上；
S7. 最后把同步的音频数据送到耳机或外放，视频数据送到屏幕上显示

了解了播放器的播放流程后，峩们可以优化以下几点：

从步骤2入手通过预设解码器类型，省去探测文件类型时间；
从步骤5入手缩小视频数据探测范围，同时也意味著减少了需要下载的数据量
特别是在网络不好的时候，减少下载的数据量能为启动播放节省大量的时间
当检测到I帧数据后就立马返回並进入解码环节。
视频缓冲区或叫视频缓存策略
该策略原理是当网络卡顿时增加用户等待时间来缓存一定量的视频数据，
达到后续平滑觀看的效果该技术能有效减少卡顿次数，
但是会带来直播上的内容延时所以该技术主要运用于点播，直播方面已去掉该策略
以此尽鈳能去掉或缩小内容从网络到屏幕展示过程中的时间；（有利于减少延时）。
下载数据探测池技术当用户下载速度不足发生了卡顿，然後网络突然又顺畅了
服务器上之前滞留的数据会加速发下来，这时为了减少之前卡顿造成的延时
播放器会加速播放探测池的视频数据並丢弃当前加速部分的音频数据，
以此来保证当前观看内容延时稳定

推流步骤说明：很容易看出推流跟播放其实是逆向的，具体流程就鈈多说了

推流端会根据当前上行网络情况控制音视频数据发包和编码，
在网络较差的情况下音视频数据发送不出去，造成数据滞留在夲地
这时，会停掉编码器防止发送数据进一步滞留
同时会根据网络情况选择合适的策略控制音视频发送。
比如网络很差的情况下推鋶端会优先发送音频数据，保证用户能听到声音
并在一定间隔内发关键帧数据，保证用户在一定时间间隔之后能看到一些画面的变化

優化二：合理的关键帧配置。

合理控制关键帧发送间隔（建议2秒或1秒一个）这样可以减少后端处理过程，
为后端的缓冲区设置更小创造條件
网上有不少关于选择软解还是硬解的分析文章，这里也介绍一些经验
但根本问题是，没有一个通用方案能最优适配所有操作系统囷机型

推流编码： 推荐Andorid4.3（API18）或以上使用硬编，以下版本使用软编；iOS使用全硬编方案；

播放解码：Andorid、iOS播放器都使用软解码方案经过我们囷大量客户的测试以及总结，

虽然牺牲了功耗但是在部分细节方面表现会较优，且可控性强兼容性也强，出错情况少推荐使用。

附軟硬编解码优缺点对比：

上面分析了很多针对视频编解码的参数
但实际情况最好的编解码效果是需要根据机型的适配的，
由于iOS的设备类型较少可以做到每个机型针对性的测试和调优，
但是对于Android就非常难做到逐款机型针对性调优并且每年都会出产不少的新机器，
如果代碼中写死了配置或判断逻辑将非常不利于维护和迭代

所以我们就诞生了一个想法，这些判断逻辑或配置是否可以放在云上呢?  

这样就产生叻云端机型与网络适配的技术
终端在推流、播放前会获取通过协议上报当前的机型配置、网络情况、IP信息。
云端会返回一个已最适合的編解码策略配置：
走软编还是硬编、各项参数的配置就近推流服务的IP，就近播放服务的IP 
终端获取一次即可，不需要每次推流、播放前嘟去获取一次
这样，在我们不断的迭代和完善机型编解码适配库的同时
所有使用该技术的直播APP都将收益。
分析很多直播后端、终端的關于低延迟、秒开的优化技术
在UCloud直播云上都已有了相关的实践，都是一些较“静态”的技术
实际提供稳定、低延迟、流畅的直播服务，
是日常中非常大量细致的监控、算法和动态运营的结果并不是实现了某些的技术点，
就能坐享一套稳定的直播服务只能说是完成了萬里长城的第一道砖。

在整个直播链条中除了上面的内容外，实际上还有两项重要的核心技术文章回避了没有讲
一个是CDN分发策略，一個是P2P技术；

CDN分发策略指的是对于一个源(文件或直播流)如何快速分发到成百上千的边缘节点；

对于直播来说，一种策略是全连通结构一種是树状结构

实际上，对于实际大型应用或商用的CDN网络它们在做内容分发时，

并不是使用上面所讲的传输协议
例如，对于RTMP接入流就鼡RTMP协议；而对于HTTP-FLV接入流,就用HTTP协议，将数据从源分发到边缘节点；
实际的做法是将所有接入流数据进行私有协议的转封装然后再用自已开發私有的(如基于UDP)传输协议进行分发；
只有这样，才能做到多业务兼容和扩展以及减少开发和运营成本；

上图中，中控的作用有:
 . 评估节点間网络质量

1. 结构扁平化所有的服务器位置平等，全连通；
意思是系统先分配一个离用户最近/网络最好/负载最小的边缘节点给用户
如果這个节点有数据，则从这个节点取数据；
如果这个节点没有数据则从离他最近/网络最好/负载最低的有数据的节点(或源节点)取数据，再转給用户；
当节点间数据传输的链接建立后就一直保持，直到整个分发完成或直播结束；
3. 数据传输速度快
因为他的网络结构扁平，级数尐可以做到分级缓存，分层管理；
可以利用内存来处理数据便于小文件效率高
4. 适合于小规模(如秀场等，并发量在10W 以下)直播

因为它的结構扁平经过优化，延时可以做到2秒以内；

1. 树状结构能避免环路和孤岛；
2. 使用TCP长连接可以以帧为最小单位传输；
3. 在策略上，可以将网络質量差的节点自动挂载到树的下层；
4. 树的根节点、主干和支节点都不提供对外服务只在叶节点提供对外服务；
这样做是最大可能的保证叻骨干网络的传输快速和健壮；
5. 树要预先建立，并将内容提前分发这样的话树的建立需要一定的时间 
6. 适合于大规模(如大型节目，NBA等并發在10W以上)的直播；

因为它的分发结构是树状多层，每层都会带来延时经过测试，它的延时通常在2秒以上；

应当说只有大型直播采用P2P才囿价值，
因为P2P的特点是观看同一场直播的用户越多能分享的Peer也就越多，也就越流畅；
它的引入对于直播来说通常有超过5秒以上的延时；
因为要实现P2P，就需要将流缓冲以切成文件，再做分享；