Some shortcomings of netstream in as3.0 !!!

 ArticleWhy: When scrubbed videos with seek (), we found that every time we jump to the end of the FLV video (the FLV video uses external loading instead of streaming media ), netstream will be accepted when there are several to dozens of frames different. seek. invalidtime, and then the strange thing happened. The video will not be played any more, but will be stuck in the video. Bai Si couldn't explain his online search. After reading a foreigner's blog, he found a lot of articles about netstream.

Cause of the problem: I first thought that the metadata of the FLV video (obtained through onmetadata) contains a canseektoend (a Boolean value, if the FLV file uses the last frame (it allows positioning to progressive download)
Specifies the key frame encoding at the end of a video clip. The value is true. If the FLV file is not encoded using the key frame on the last frame, the value is false .), Is it a strange thing? Print it and find that this is only true. Exclude this possibility. Finally saw a foreigner's blog (http://www.brooksandrus.com/blog/2008/11/05/3-years-later-netstream-still-sucks/), only to know how many brothers netstream pit (also learned English, know suck has bad meaning ~). The following is a detailed analysis.

1. As we all know, videos loaded externally cannot be precise to seek (). When you use seek to T, it searches for the key frame closest to T and continues playing from this key frame. But not every frame is a key frame, that is, not every frame can be seek. So when the T of seek (t) has crossed the last jump frame (in fact, it is a time point, because netstream uses the time attribute to represent the playing position ), the tragedy at the beginning of this article will happen. So when we jump to the end, we should set the seek () to the final jump frame to avoid any problems.

2. Someone asked me again, how do I know where the last jump frame is. Don't worry. When you jump to a place that shouldn't jump, you will receive netstream. Seek. invalidtime, so write as follows:

If (e.info. Code = "netstream. Seek. invalidtime") {_ STM. Seek (e.info. Details );}
 

This e.info. Details is the last valid location that the user can search.

3. Another problem is that after seek () is successful, you will find that the netstream. time attribute is the value before seek. What is the problem? That's right. The value of this time is not refreshed in time. Is it enough? So how can we get the refresh value? I have explained in the foreigner's blog above that I will sort it out later. Well, it's time to get off work (despise netstream again ).