文章的由來：當用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）。