请问盖楼机里的目标贴号什么意思 还有最低延迟和最高延迟什么意思_百度知道
请问盖楼机里的目标贴号什么意思 还有最低延迟和最高延迟什么意思
我有更好的答案
我是开发的 请问盖楼
为您推荐：
其他类似问题
您可能关注的内容
盖楼的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。探讨直播低延迟低流量的粉丝连麦技术
互动是视频直播中用户使用最好的体验。目前上市场视频直播互动依靠打赏和文字互动，而对于粉丝来说，连麦上镜才是最好的用户体验。本次亲加通讯云郝飞受邀参加ArchSummit微课堂，探讨直播低延迟低流量的粉丝连麦技术。
到目前为止，直播行业继续如预期的那样如火如荼的发展着，在先后竞争完延迟，高清，美颜，秒开等功能后，最近各大直播平台比拼的一个热点就是连麦。什么是连麦？
简单描述就是当主播直播期间，可以与其中某一个粉丝进行互动，并且其他粉丝能够观看到这个互动过程。
这个连麦的操作把主播和粉丝的交互从文字聊天一下升级为音视频互动，这个功能瞬间就提升了粉丝们的参与感；同时，这个互动过程其他粉丝都可以看到，极大满足了连麦粉丝的幸福感，连麦的流程图如下：
在主播直播过程中，主播提示进入互动环节，此时用户可以参与互动
用户请求参与互动，主持人同意某一个用户的请求；
用户参与直播，用户与主播的互动过程直播给其他所有粉丝；
那如何实现连麦这样的功能呢？ 今天就向大家介绍几种实现方法；
第一种方式就是通过两路RTMP 流实现
目前直播的协议普遍采用的是RTMP协议，RTMP 是Adobe
公司实现的一套为Flash播放器和服务端之间音视频和数据传输的私有协议。
此协议基于TCP实现，采用多路服用，信令和媒体都通过一个通道进行传输。
目前国内的直播CDN 基本上都使用此协议，其延迟大概在3秒左右；
由于此协议的数据是单向流动的，因此如果连麦功能使用此协议实现的话，就需要两路视频流的发布订阅；其原理图如下：
主播首先发布视频到流媒体服务器，用户从流媒体服务器拉取视频信息 ；
其中某个用户希望与主播连麦，他通过信令服务器向主播请求连麦，主播同意连麦请求；
连麦者发布视频到流媒体服务器；
主播端和其他用户获取连麦者发布的视频，在手机端采用画中画形式显示；
在这个方案中，主播和参与连麦的粉丝分别发布了一路视频流，观看的粉丝同时拉取两路视频流。这种连麦方式从技术实现上非常简单，但其体验上也存在很多问题：
首先，主播和参与连麦的粉丝之间的交互延迟太大。大家了解，一路rtmp
的延迟大概在3秒左右。如果主播与参与连麦的用户需要进行对话，那么主播从提问到听到对方的答复原则上差不多要6秒左右时间了，这个对于实时交互来说完全没有办法接受。
其次， 声音效果不好，会产生回波。
一般的直播的音频处理模块都没有进行回波抵消处理，因此主播端在观看到连麦者视频的同时，不能打开连麦者的音频听，否则会通过音频采集设备重新采集，形成回波。
最后，客户端接收两路视频，流量消耗高。一般的用户端需要接收两路视频才能分别看到主播和连麦者，两路视频导致流量消耗比较高，同时两路解码也比较消耗CPU
从上面的分析大家可以看出，上述方案并不是一套可接受的连麦方案；
连麦的场景对于延迟要求很高，RTMP协议明显无法满足要求。比较好的方案需要确保连麦者（2个或者多个）
之间的交互满足视频会议的标准，也就是延迟在600ms 以内，整体的交互过程再进行视频混合，以RTMP
的方式进行输出。也就是说，这个方案中其实涉及了两套系统，一套是保证低延迟的多人音视频交互系统，另外一套是标准的CDN 直播系统；
直播系统大家已经很了解了，下面重点介绍下低延迟的交互系统的特点：
直播系统是一个单向的数据通道，而低延迟的视频会议系统是一套双向的通道。这使得这类系统在支持大并发方面没有直播系统那么容易扩展，其网络拓扑结构更加复杂；
低延迟系统传输层一般都使用UDP，应用层使用RTP／RTCP协议，从而保证包的即时性；为了保证安全性，更多的系统在使用SRTP协议，它是在RTP基础上多了一层安全和认证措施；客户端的连接建立常使用ICE协议，它结合私有网络中主机所处的环境，通信双方首先从STUN，TURN收集尽可能多的连接地址，然后对地址进行优先级排序，选择最优的方式进行连接；这种方式对于不使用NAT穿透的场景也有好处；
它可以保证不同网络客户的联通率，例如有些境外的客户直连境内服务器效果不够好，可以考虑通过TURN服务进行中转，从而保证服务质量；
使用UDP就会涉及网络延迟，丢包，因此要考虑QoS，主要策略包括：
使用抖动缓存(jitter
buffer)来消除网络包的抖动特性，以一个稳定的速率将数据包交给后续模块处理；音频和视频需要有各自的抖动缓存，然后再实现同步；
在音频方面，需要实现丢包隐藏算法； GIPS公司的NETEQ
算法应该是业界公认最好的VOIP防抖动算法，目前已经在WebRTC项目中开源；
视频方面，需要实现一个自适应反馈模型，能够根据网络拥塞情况调整丢包保护策略；
当RTT较大时，可以使用FEC进行数据保护；当RTT较小的时候，选择采用NACK机制；
接下来将基于以上讨论的这种模型，介绍两种连麦实现方式；这两种方式都可以保证连麦效果，他们的主要区别是一种使用P2P技术进行连麦，另外一种使用多人视频会议系统支持连麦，具体如下。
第二种方式是P2P ＋ 直播的连麦方式，其原理图如下
主播首先发布视频到流媒体服务器，用户从流媒体服务器拉取视频信息；
连麦者请求连麦，此时主播端会弹出连麦请求，主播选择连麦用户，连麦者和主播建立P2P 连接；
主播端和连麦者之间建立了P2P 通道，通过此通道进行音视频数据的交互；
主播端从摄像头中采集主播视频，从P2P 通道获得连麦者的视频，然后把两张图片进行混合，再发布给主播模块，直播出去；
这种实现方式的优势在于：
主播和连麦者之间的交互延迟小，由于这两者之间是P2P
连接，因此网络延迟非常小，一般都在几百毫秒的量级。主播与连麦者之间的交互非常顺畅；
声音效果好； 主播端使用回波抵消模块，连麦者的回声会被消除；同时，主播与连麦者的语音交流也会整体直播出去；
这种方式存在的问题在于：
主播端相当于有两路视频上传（直播视频＋连麦者的视频交互），一路视频下载（连麦者的视频），对网络要求会比较高。
我们团队在正常的电信，联通等wifi 及4G 网络下进行测试，主播端带宽完全能够满足要求；
不支持多路连麦者同时交流；
第三种方式通过视频会议＋直播的方式实现
为了能够实现多个粉丝同时连麦，可以考虑主播与连麦者之间使用视频会议系统，用一个MCU（Multi Control
Unit）来实现媒体数据转发。然后通过MCU对多路数据进行混合，再把混合流发送给CDN，其原理图如下：
主播端加入视频会议系统；此处注意，主播端不再直接推视频给CDN；
视频会议系统把主播的视频流推向CDN，观众通过CDN 观看主播视频；
参与连麦的观众登录到与主播端同一个视频会议频道中，此时主播端和连麦者通过实时的视频会议进行交互；主播与连麦者的视频，经过服务端混合后输出给CDN；
其他用户通过CDN 观看主播与连麦者的交互；
这种方式的优势在于：
主播和连麦者交互延迟很小； 由于使用视频会议系统，通过服务端做了一次转发，基本延迟都在一秒以下；
主播端只承担视频会议交互的流量，而不需要再承担直播的上传流量，对网路要求比P2P 方式要低；
支持多人交互；
缺点在于：
服务端相比于一般的直播系统，还多增加了视频会议系统，开发复杂性高；
音视频混合在服务端完成，对服务器性能要求高；
以上就是对连麦实现方式的简单介绍，这三种方式在实际项目中都有被使用到，原则上后两种方法的体验会更好些；特别是第三种方案，他可以支持小范围的多人实时交互，但这种方案的开发量大，同时熟悉视频会议和直播的团队比较缺少，对研发团队要求高；
第二种方案可以在webrtc 和直播技术基础上可以实现，对这方面比较熟悉的团队可以尝试整合一下。
以下是7月5日现场问答：
问题1:连麦技术是在客户端实现还是服务器端实现? 两种实现方式各有什么优缺点?
郝飞：刚才介绍的第二种方案就是在客户端实现的，当然服务端也需要做一些工作； 而第三种方案主要是在服务端的实现；
相关的优缺点上面也做过解答，大家可以参考下；
问题2:连麦技术有开源基础版吗？
郝飞：P2P 的方案可以考虑在webrtc
基础上实现；而视频会议＋直播的方案目前还没有看到开源项目，可以考虑在视频会议系统上进行改造，使其输出RTMP 直播；
问题3: 直播和用户宽带至少需要多少才能流畅连麦？
郝飞：如果是P2P 方案，对主播端带宽要求会高一些；
如果是第三种会议模式，要求就不高了，基本上就是一路上传，一路下载； 第二种P2P 方案，我们在4G，10M
的联通，电信等网络下实验都是OK的；
问题4:你们P2P 是自己研发的还是基于其他的？
郝飞：我们是在webrtc 基础上改造的，webrtc
的视频图像要和摄像头的视频图像合成；并且在带耳机的情况下，音频也需要程序合成；
问题5:你们对防火墙或NAT有没有运用STUN 或ICE 之类的技术？
郝飞：ICE 是一定要使用的； 对于P2P 网络，有很多网路不能直连，肯定要使用TURN服务做中转；
对于会议模式，也可以通过TURN做中转，从而解决异地网络连接不稳定的情况；
问题6: 各方案中如果用户端断线，此时用户重新连麦要重新走连麦流程吗？还是说可以挂着视频系统自动重连？
郝飞：是可以重新连接的，不需要再走连麦流程；
问题7:第二种方案为什么不支持多路连麦者同时交流？
郝飞：P2P 其实也可以支持多人交互，但多个人同时交流，对于主播端来说CPU 压力和网络压力都很大；
问题8:你们的视频和音频分别采用的是什么编码？
郝飞：通用的编码方案是：视频采用H264，音频采用AAC；
如果端到端都可控情况下，建议使用H265，压缩率更高；
问题9: 第三种方案中，有什么推荐的视频会议系统 ？
郝飞：大家有兴趣的话可以看看 licode
问题10: 第三种方案的开发团队要多少人，开发周期一般多长
郝飞：这个不在于人多，主要还是对视频会议系统要比较了解； 如果使用licode
改造的话，需要服务端实现RTMP推流的改造，如果对ffmpeg
等比较熟悉的话，一个月左右能够出来一个基础版本，但真正稳定下来还有很多工作需要完善；
郝飞，亲加通讯云CTO，2011年加入亲加团队，带领技术团队创建了国内首个通讯云服务平台，并以此为基础，以技术驱动业务，不断提高服务质量和功能，现已把此平台升级为包括实时语音，视频的移动端完整沟通解决方案；并在研发部实行有效的人才引入管理制度，两年内组建了一支40多人规模的具备快速迭代，交付高质量技术产品能力的团队，从而支持公司业务的快速发展。在音视频编解码、VOIP、流媒体等方面有丰富的研发和管理经验。
亲加通讯云介绍
上海爱聊信息科技有限公司（简称：亲加通讯云）成立于2011年，是国内专业的移动通讯云服务商，嵌入式互动视频直播领导者。
亲加以独有的SaaS/PaaS一体化服务模式，专注为企业级客户和移动应用开发者提供全面的通讯云基础能力和云端服务：包括视频直播、H5微直播、全民直播、即时通讯（IM）、实时语音等。
亲加在游戏市场覆盖率第一，并已在金融、教育、电商、医疗等领域积累了大量的成功案例，并根据各行业特点提供视频直播多场景解决方案。
加入亲加视频直播交流群： 。一个致力于帮助微信自媒体爱好者增粉和变现的直播服务。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。视频直播技术（三）：低延时直播经验总结 - 灰色飘零 - 博客园
随笔 - 131, 文章 - 0, 评论 - 33, 引用 - 0
解决低延迟问题的核心思想：NO BUFFER
低延迟：顾名思义，就是让播放端和推流端的时间差越小越好，那么如何做到低延迟呢，一个词概括：no buffer
首先说明一下视频流的流向：推流端---&CDN服务器---&拉流端
1. 推流端 nobuffer，也就是保证推流端缓存的buffer最小。这样基本上保证在推流端出现网络抖动或者突然变差的情况下，能够舍弃已经缓存的buffer，继续推新生成好的视频帧。这样保证了，在网络端开始传输的时候的视频内容是最新的。
2. CDN nobuffer，针对性的调整CDN的配置，让CDN服务器缓存的GOP尽可能的少，这样保证拉流端获取到的是最新的内容。
3. 拉流端 nobuffer，既然推流和中转的CDN都设置了nobuffer，那么拉流端设置nobuffer的意义，应该不需要做过多的解释了吧。
记住一点：低延迟问题的解决不是一端的事情，三端的配置都会对延迟的效果产生影响。
拉流端（基于IjkPlayer）低延时直播的经验：
在直播的过程中，有首开延时和内容延时。首开延时，基本可以控制在100ms左右；基于RTMP播放的内容延迟根据CDN的情况，基本上会在2~5秒左右。而因为RTMP是基于TCP协议的，所以在播放的过程中会受到网络条件的影响，造成延迟增加的情况。通过了解直播流的推流和拉流相关的知识，可以知道，根据推流端（推流策略）与服务器（缓存策略）不同的控制的设定，我们很可能拿到几秒之前的内容（甚至十几秒），可以通过对比拉流端与推流端的内容即可得知。而这些内容，在拉流端会把CDN服务器缓存的数据拉取过来，这时buffer queue变大。那么，buffer queue越大，拉流端与推流端的延时越大。
拉流端影响延时的核心原因： buffer queue 变大，拉流端播放的内容和推流端相差时延增加。
解决办法：
1. 控制max_buffer_size，合理设置max_buffer_size，使得拉流端不会缓存太长时间的内容（经过测试，发现不是很实用，因为内容延时只有追赶或者丢弃当前播放的内容，快速跳播到最新数据才能达到低延时播放）
2. 使用倍速播放，快速消耗Buffer Queue，在消耗到合理的区间后，进行正常播放（监听并动态控制buffer queue，此方案要求设备的解码性能能够支撑）。
3. 使用丢包（丢帧）策略。策略说明：
1?.&有音频流和视频流，或者只有音频流情况下，当audioq达到一定的duration，就丢掉前面一部分数据包，因为默认是AV_SYNC_AUDIO_MASTER，视频会追上来。
2?.&只有视频流情况，当videoq达到一定的duration，就丢掉前面一部分数据包。
下面是我在解决低延迟问题的时候，参考的丢包（丢帧）策略相关文章：&、。}