>I have implemented this. The best approach to performance depends on codec. >But if we are talking about something like avc with reasonable keyframe >interval (order of 100), I came up with this:
>1) If I can reach desired frame by decoding forward less than ~100 frames, >I just decode all these frames (even if most of them are already cached). >2) Every decoded frame is cached within window of 2*keyframe interval frames >3) If I need to go backward, I seek to previous keyframe and decode everything >forward until desired frame (and cache all decoded frames) >4) If I can go backward and all frames until previous key are already cached, >I speculatively decode frames which are further away. >This way if I move sequentially (backward or forward), for each frame step >there > is exactly one frame decode. The frame cache allows to hide the fact that >frames are always decoded forward while you request them backward. >Then there are other tiny details with seeking. To perform it realistically >you best deal >with single stream at a time (multistream seeking is really not designed for >scrubbing). For my use case I will have to have both audio and video scrubing with the audio also playing backward or forward and speeding up or slowing down. This is to accomodate DJs who do this in front of a live audience. The target machines are normally i7 or better but if one has to suffer a bit it should be the video and not the audio. >And you have to have proper keyframe index to know how to seek to keyframes >and measure distances.
_______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
