对方微信视频无应答是什么原因(微信视频对方无应答是怎么回事)

随着互联网视频化的发展，各类网络直播产品层出不穷，比如秀场直播、游戏直播、教育直播、演唱会直播和监控直播等多个直播生态圈。这些生态圈形成的背后，是视频直播相关技术的不断发展，例如互联网带宽的日益增加，视频压缩标准的日渐完善，视频云技术的出现等。

直播涉及到的技术比较多，主要大类有：采集、前处理、音视频编解码、流媒体协议、系统架构、CDN、播放控制、交互技术等。

小编也经常游历于各个直播的讨论交流群，讨论中推流、拉流、延时等等，其中也不乏一些伪专家的高谈阔论，把互联网直播搞成了单纯的点对点视频聊天，你可以不懂，没有必要去操作，但是最基本的理论要知道！这篇文章并非小编原创，只是转载整理了一些基本理论知识，如果对你产生了不良反应，请谅解！

HLS 协议本质还是一个个的 HTTP 请求 / 响应快，所以适应性很好，不会受到防火墙的影响。但它也有一个致命的弱点：延迟现象非常明显。如果每个 ts 按照 5 秒来切分，一个 m3u8 放 6 个 ts 索引，那么至少就会带来 30 秒的延迟。如果减少每个 ts 的长度，减少 m3u8 中的索引数，延时确实会减少，但会带来更频繁的缓冲，对服务端的请求压力也会成倍增加。所以只能根据实际情况找到一个折中的点。

注意：HLS 在 PC 端仅支持safari浏览器，类似chrome浏览器使用HTML5 video标签无法播放 m3u8 格式，可直接采用网上一些比较成熟的方案，如：sewise-player、MediaElement、videojs-contrib-hls、jwplayer。

和HTTP一样。

和HTTP一样。

IOS、Android、HTML5原生支持。

基本上HLS的延迟在10秒以上。

若分发HLS，码流低，切片较小时，小文件分发不是很友好。特别是一些对存储比较敏感的情况，譬如源站的存储，嵌入式的SD卡。

RTMP 基于 flash 无法在 iOS 浏览器里播放，但是实时性比 HLS 要好。所以一般使用这种协议来上传视频流，也就是将视频流推送到服务器上。

RTMP的实时性在3秒之内，经过多层CDN节点分发后，实时性也在3秒左右。在一些实时性有要求的应用中以RTMP为主。比起YY的那种UDP私有协议，RTMP算延迟大的，比起HTTP流的延时（一般在10秒以上）RTMP算低延时。一般的直播应用，只要不是电话类对话的那种要求，RTMP延迟是可以接受的。在一般的视频会议应用中，RTMP延时也能接受，原因是别人在说话的时候我们一般在听，实际上1秒延时没有关系，我们也要思考（话说有些人的CPU处理速度还没有这么快）。

经过测量发现，在网络状况良好时：
. RTMP延时可以做到0.8秒左右。
. 多级边缘节点不会影响延迟（和SRS同源的某CDN的边缘服务器可以做到）
. Nginx-Rtmp延迟有点大，估计是缓存的处理，多进程通信导致？
. GOP是个硬指标，不过SRS可以关闭GOP的cache来避免这个影响.
. 服务器性能太低，也会导致延迟变大，服务器来不及发送数据。
. 客户端的缓冲区长度也影响延迟。譬如flash客户端的NetStream.bufferTime设置为10秒，那么延迟至少10秒以上。

RTMP实际上是现在编码器输出的工业标准协议，基本上所有的编码器（摄像头之类）都支持RTMP输出。原因在于PC市场巨大，PC主要是Windows，Windows的浏览器基本上都支持Flash，Flash又支持RTMP支持得非常好。

RTMPE和RTMPS为加密协议。虽然HLS也有加密，但在PC平台上flash对RTMPE/RTMPS支持应该比较不错。

在PC平台上flash播放的最稳定方式是RTMP，如果做CDN或者大中型集群分发，选择稳定性高的协议一定是必要的。HTTP也很稳定，但HTTP是在协议上稳定；稳定性不只是服务端的事情，在集群分发，服务器管理，主备切换，客户端的支持上，RTMP在PC分发这种方式上还是很有优势。

因为RTMP支持的很完善，所以能做到flash播放RTMP流长时间不断流，当时测试是100万秒，即10天多可以连续播放。对于商用流媒体应用，客户端的稳定性当然也是必须的，否则最终用户看不了还怎么玩？我就知道有个教育客户，最初使用播放器播放http流量，需要播放不同的文件，结果就总出问题，如果换成服务器端将不同的文件转换成RTMP流，客户端就可以一直播放；该客户走RTMP方案后，经过CDN分发，没听说客户端出问题了。

编码器输出到互联网（还可以输出为udp组播之类**应用），主要是RTMP。譬如专业编码器，或者flash网页编码器，或者FMLE，或者ffmpeg，或者安防摄像头，都支持RTMP输出。若需要接入多种设备，比如提供云服务；或者希望网页直接采集摄像头；或者能在不同编码器之间切换，那么RTMP作为服务器的输入协议会是最好的选择。

容错有很多种级别，RTMP的集群实现时可以指定N上层，在错误时切换不会影响到下层或者客户端，另外RTMP的流没有标识，切到其他的服务器的流也可以继续播放。HLS的流热备切换没有这么容易。若对于直播的容错要求高，譬如降低出问题的概率，选择RTMP会是很好的选择。

在监控系统或者运维系统的角度看，流协议应该比较合适监控。HTTP的流监控感觉没有那么完善。这个不算绝对优势，但比较有利。

RTMP最大软肋，因为是Adobe的私有协议，很多设备都无法直接播放，比如iOS，需要外挂第三方解码器，由此会带来发热、耗电等问题。HTML5也是无法直接播放RTMP，因此你看到的很多手机网页上的直播，是由下面HLS来推流的。

RTMP协议比起HTTP复杂很多，导致性能低下。

测试发现两台服务器直连100Gbps网络中，HTTP能跑到60Gbps，但是RTMP只能跑到10Gbps，CPU占用率RTMP要高很多。复杂协议导致在研发，扩展，维护软件系统时都没有HTTP那么方便，所以HTTP服务器现在大行其道，apache/nginx/tomcat，N多HTTP服务器；而RTMP协议虽然早就公开，但是真正在大规模中分发表现良好的没有，adobe自己的FMS在CDN中都经常出问题。

流氓协议做缓存不方便。譬如点播，若做RTMP流协议，边缘缓存RTMP会很麻烦。如果是HTTP，缓存其实也很麻烦，但是HTTP服务器的缓存已经做了很久，所以只需要使用就好。这是为何点播都走HTTP的原因。

技术一定要知道弱点，RTMP有个弱点就是累积误差，原因是RTMP基于TCP不会丢包。所以当网络状态差时，服务器会将包缓存起来，导致累积的延迟；待网络状况好了，就一起发给客户端。这个的对策就是，当客户端的缓冲区很大，就断开重连。

HTTP-FLV 和 RTMP 类似，都是针对于 FLV 视频格式做的直播分发流。但，两者有着很大的区别。

现在市面上，比较常用的就是 HTTP-FLV 进行播放。但，由于手机端上不支持，所以，H5 的 HTTP-FLV 也是一个痛点。不过，现在 flv.js 可以帮助高版本的浏览器，通过 mediaSource 来进行解析。HTTP-FLV 的使用方式也很简单。和 HLS 一样，只需要添加一个连接即可：

<object type="application/x-shockwave-flash" src="xxx.flv"></object>

PC端
1、优先使用 HTTP-FLV，因为它延迟小，性能也不差1080P都很流畅。
2、不支持 flv.js 就使用 Flash播放器播 RTMP 流。Flash兼容性很好，但是性能差默认被很多浏览器禁用。
3、不想用Flash兼容也可以用HLS，但是PC端只有Safari支持HLS

移动端
1、优先使用 HTTP-FLV，因为它延迟小，支持HTTP-FLV的设备性能运行 flv.js 足够了。
2、不支持 flv.js 就使用 HLS，但是 HLS延迟非常大。
3、HLS 也不支持就没法直播了，因为移动端都不支持Flash。

下面简单说一下这几种协议的优劣：

看了以上这些协议，想必各位都注意到了一个问题，那就是“延迟”。所有的协议里都有延迟，延迟最低的也有500ms。那么为什么会出现这样的情况呢？接下来，简单和大家说一说“延迟”。

简说延迟

在这里简单说一下rtmp和rtsp的延迟，我们先谈rtmp的延迟。圈内有人整理了一张直播延迟（rtmp的）的图片，我直接上个真相。

看完上图你大概就能明白了，rtmp的延迟是和gop挂钩的。

那么，为什么rtsp延迟会比rtmp低呢？因为，它是精确控制的，可以跳出这个以gop组为单位的控制。

rtsp延迟已经是上述四个协议里最低的了，那么延迟还有降低的空间吗？

如何降低延迟时间

我们公司经过多次测试，发现udp直接发裸流，可以将延迟控制在80ms到170ms的范围内。

既然udp直接发裸流延迟那么低，为啥不流行？

原因很简单， udp是个不可靠传输、丢包、乱序。而且直接裸流稳定性也差，兼容性更不用谈，没有编码器跟你对接。这就是一个钢丝上骑自行车的活，高难度动作，能干这行的，必须得是艺高人胆大。

直播涉及到的技术非常多，本文主要简单介绍了直播中用得比较多的几种协议。而对于流媒体的传输，现在出现了越来越多的私有协议，这些私有协议一般延迟都比较低，比如大家平时用的微信视频，就不属于流媒体。延迟的话，相信大家也都用过，比rtsp的500ms显然低很多。但通常来说，这些私有协议都只支持端，不能用于web开发，因为一般协议，都是用c/c++写的socket通信。

附流媒体技术图