AS3.0中netstream的一些不足之處！！！

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