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连接观看。两者之间,没加入其他的沟通环节。不知道客户端此时的流与真实流的状况。