While what you say is true, it's not really a 'good' reason. Quicktime has been around for far longer than flash, and it allows seeking to any time. Seeking to a non-keyframe is much slower than seeking to a keyframe (since you must decompress the intermediate frames), but it can be done. If you're dealing with an RTMP stream or a video with extremely long gaps in keyframes, it may be unreasonable, but the situation with Flash definitely could be better than it is today. Imagine being able to reliably jump to key frames (tricky today, given the asynchronous nature of netstream seek) and then programmatically advance to the next frame. That way actionscripters could access individual frames, but the player would never have to deal with a case where it would need to decompress 25 intermediate frames before a seek completed.
But the fact of the matter is that with progressive FLV today, if you want access to individual frames from actionscript, the frames must be keyframes (and you must figure out how to know their timestamps, using metadata or some other convention). --Brian On 8/15/07, JOR <[EMAIL PROTECTED]> wrote: > > Eric already provided you with a link to the manual page of the seek() > method that answers this question. > > Your problem is you want to seek to a point in time that is not a > keyframe. You can not do this for a very good reason. A keyframe is an > uncompressed frame and all the frames in-between keyframes are "change > only" frames. You can not seek to a change only frame because it > doesn't contain enough information to display the whole frame. > Therefore, it starts with the closest keyframe and plays from there. > > _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
