This content has been marked as final. Show 8 replies
I don't know if I can help...
Is it a very large flv file?
A) For 'progressive streaming' flvs you can't seek forward beyond the point where the file has downloaded (without some server side support and additional metadata about the keyframes). I'm not sure if that is the case here, but its seems like it might be based on your description.
B) Also, I have read that if you're working off a cd-rom you will have slow seek times as well.
C) The only other thing I can think of (and I don't know if this would be relevant or not) is if the flv encoded was encoded with very sparse keyframes or with variabe bit rate encoding where some parts might have sparse keyframes. That might be a cause as well, because you can only seek to keyframes. But this is only a guess and may in fact have very little impact on seek times... I don't know. I think it might be the first thing I said i.e. (A) above.
Is it a very large flv file with lots of keyframes and I'm working off line (gone be a cd-rom).
The file is loaded completely.
If I jump (seek) to a time where I have not been before it seams to me like flash jumps to all 'keyframes' between NetStream.time and NetStream.seek(newTime). After been on each keyframe flash remembers is by seek again (just a guess).
But if I load this file in a 'FLVPlayback' there is no problem by sliding it or jumping to a time where I have not been before!!!!
Why don't you use FLVPlayback then? If its for off-line use, then the size is not really an issue.
I read somewhere that the code in the FLVPlayback does an enormous amount of checking and flag setting to accomplish all of what it does. Chances are its related to something related to the order or timing of the seek and its response in NetStream. I don't really know but if FLVPlayback is obviously able to work around that then why not use it?
I have also heard that cd-rom playing/seeking may not be as good as off the hard drive. I've never tried it so can't say from exerience... so for your sake I hope I'm wrong.
It's a long story ... anyway, I cannot use the FLVPlayback.
Playing/seeking from cd-rom is not as good as off the hard drive but no problem.
I still hope there is a way to seek a flv without splutter :[-
Well there is, because FLVPlayback does it. If you can't find an answer with explanation from someone, then all I can suggest is looking in the class files for the FLVPlayback, to see how its done there.
But unless you need something extra that FLVPlayback doesn't provide access too, then I really can't understand why you can't use it - however long the story is ;-). Any limitations it has are probably easier to work around than to try to rebuild the core functionality - especially if there is no concern with 'download size' because you're targeting offline use.
I had a situation where there was a property of NetStream that wasn't available via FLVPlayback... so I just made a "second version" with the extra property with minimal effort.
Thanks a lot for your answers.
I have taken a look in the FLVPlayback.as but I didn't really understood how they have managed this probleme :|-
But maybe there is a way to use the FLVPlayback.
But I really would like to know what's going on by NetStream.seek and how to manage this!
I think if you can use it you're much better off. Presumably the solution is encapsulated in the FLVPlayback code... like I said I'd read somewhere that it was quite complex.
The only reference I can find online is to the problem, not the solution.