rtmp延时低，但是累计延时就不一定低。随着播放时间的久远以及网络状况的变化。rtmp延时会比较严重，甚至达到几十秒的延时。这个时候，直播的体验会很差很差。这就是rtmp的一个缺点。rtmp是基于tcp，不会丢包。所以当网络状态差时，服务器会将包缓存起来。待网络状况好了，就一起发给客户端。

对于NetStream，有一个属性叫bufferTimeMax。指定实时流内容的最大缓冲区长度（以秒为单位）。默认值为 0。由于网络和设备问题（如发送方和接收方之间存在时钟偏移），缓冲区长度可随时间不断增加。设置此属性可使实时应用（如会议和监视）的缓冲区长度最大化。当 bufferTimeMax > 0，并且 bufferLength >= bufferTimeMax 时，将加快音频的播放速度，直到 bufferLength 达到 bufferTime。如果实时流仅包含视频，则视频播放较快，直到 bufferLength 达到 bufferTime。Flash Player 将捕捉速率控制在 1.5% 和 6.25% 之间，具体取决于播放延迟量（bufferLength 和 bufferTime 差异）。如果流中包含音频，通过缩减频率域采样，使音频失真最小化，可以加快播放。设置 bufferTimeMax 属性可在以下情况下启用实时缓冲流追赶：
1，以数据流的方式从 Flash Media Server 传输实时介质。
2，以数据流的方式在数据生成模式 (NetStream.appendBytes()) 下传输实时介质。

本来以为只要设置下bufferTimeMax就可以了。使用方式（上边两点）限制了bufferTimeMax的作用。

那么，遇到问题，总要解决问题的。可以手动加一个定时器，间隔可以根据需要来做。每个这个间隔，就去检查bufferLentgh的大小。bufferLength的值越大，表示离真实的实时时间越远。实时性约差。当bufferLength的大小超过了预期的值，就对NetStream做pause和resume处理。用来释放数据。来达到及时同步的目的。当然，你也可以初始化重连，但这样容易引起黑屏。

这个方法，也是迫于无奈。公司项目用推流工具推流，客户端通过rtmp连接观看。两者之间，没加入其他的沟通环节。不知道客户端此时的流与真实流的状况。