文章的由来：当用seek()擦洗视频的时候，发现每当跳转到flv视频接近结尾的时候的时候（flv视频用的外部载入的方式，而不是流媒体的方式），大概相差几帧到几十帧的样子，就会接受到NetStream.Seek.InvalidTime，然后奇怪的事情发生了，视频不会再往下播放了，而是卡在了这帧视频。百思不得其解下上网查找，通过看了一老外的博客，才发现NetStream原来大有文章。
问题的产生原因：开始想到是flv视频的元数据（通过onMetaData取得）里有一个canSeekToEnd（一个布尔值，如果 FLV 文件是用最后一帧（它允许定位到渐进式下载
影片剪辑的末尾）上的关键帧编码的，则该值为 true。如果 FLV 文件不是用最后一帧上的关键帧编码的，则该值为 false。），难道是它作怪？赶紧打印之，发现此只是true。排除这个可能。最后看到一老外的博文（http://www.brooksandrus.com/blog/2008/11/05/3-years-later-netstream-still-sucks/），才知道NetStream坑了多少兄弟（还学了英文，知道了suck有烂的意思~）。下面就仔细分析下。
1.大家都知道，外部载入的视频不能精确seek（）,当你seek到T时，它会寻找离T最近的关键帧，从这个关键帧开始继续播放。但是不是每一帧都是关键帧，也就是说不是每一帧都可以seek()到的。所以当seek（T）的这个T已经越过了最后一个可以跳转的帧（其实是时间点，因为NetStream使用time属性来代表播放位置的），就会发生本文开始时的悲剧。所以当我们跳到快到结尾的时候，应该seek（）到最后的可跳转帧，这样才不会出问题。
2.那又有人要问了，我怎么知道最后一个可跳转帧在哪里。别急，当你跳到不该跳的地方会收到NetStream.Seek.InvalidTime，所以这样写：
if (e.info.code == "NetStream.Seek.InvalidTime") {
_stm.seek(e.info.details);
}这个e.info.details就是用户可以搜寻的最后一个有效位置。
3.还有一个最坑爹的问题，当seek()成功之后，你会发现NetStream.time属性还是seek前得值，这是怎么回事呢？没错，这个time的值竟然不是及时刷新的，够坑爹吧？那么怎么才能得到它刷新的值呢？在上面说道的老外的博客里有说明，以后有时间我也会在整理下，好了，时间到了，下班（再次鄙视下NetStream）。