TechyInAZ :
I record gameplay via Open Broadcaster Software (OBS). However, when I go to play those files via VLC or Windows media player, it plays fine but if I want to forward to another part of the video it takes 10-20 sec to get their with 100 CPU load (i5 4690K).
Why is it doing that?
I'm going to oversimplify to avoid a really, really long explanation. The way you compress video is basically to record an entire picture (frame), then record differences between that frame and the next frame. So if your first frame is:
12
34
and your second frame is
22
34
you don't record the entire second frame, you only record
10
00
The first pixel has increased by 1, and the other pixels are unchanged. Those zeros compress really well, helping make the video file size smaller. This continues with each frame, recording only the differences between it and the immediate previous frame.
Every x seconds or sometimes when the compression algorithm detects a large change (i.e. a scene change), you record a new complete picture and start the process all over again. These recorded complete pictures are called keyframes.
Because you're recording changes between frames, there's no way to immediately skip ahead to an arbitrary point. When you skip ahead to an arbitrary point in the video that's not a keyframe, the player has to find the previous keyframe, then
internally render every frame between that keyframe and the point you've skipped ahead to in order to correctly render the frame you've skipped ahead to. That internal rendering is why your CPU is going to 100%. If it's taking 10-20 sec, my initial guess would be that your recording software isn't saving very many keyframes, meaning the player has to render an unnecessarily large number of frames after the keyframe in order to get to your skip-to frame. If there's an option in your software to record keyframes more frequently (makes the file size bigger), then try using it.
Sometimes the player "gives up" and just renders the changes using the wrong initial or previous frame. That's what's going on when you see VLC render with wrong colors and smeared motion. It's applying differences to each frame, but it started with the wrong initial image (since it didn't render everything between the previous keyframe and your skipped-to frame), so the colors are all wrong. The picture corrects itself when VLC gets to the next keyframe.