Rewinding a video takes more time to buffer than forwarding it!


I have always noticed that rewinding a video even for 15 seconds takes a lot more time to buffer in any app than forwarding it even by 1 minute, why is it so?

Isn’t the previous one already loaded and so should appear instantaneously?

In: Technology

It was already loaded but will be deleted from your memory once it isn’t needed anymore.

Forward takes the same time unless it was already preloaded partially as your computer works in advance to prevent stuttering.

Because network speed can fluctuate you like to have a buffer of data you will be using in the future so you can have smooth playback. The result is that you download the data before it is needed. So a jump forward is just using the downloaded data earlier.

Because memory is a limited resource you limit the buffers sizes in some way. Because normally you are just moving forward the data you have used is normally worthless and the design of the software has likely just decided to not keep any data of video you have watched.

It might not be the best design option but it looks like what is done.

Depending on how the app’s playback the video the code that handles that might be a part of the operating system or some common library and then the design desition is by the one the make those. So app developers might have limited options of how video playback works if they do not like to do a lot of extra work. So if it works the same in many apps that are like the explanation.

It is not always that it works like that. If I play youtube video in the browser of my computer jumping back the amount of time work perfectly with so it likey keeps the data in a buffer even if used.

Raw video files are suuuper large! About 0.2gb/second at 1080p

so instead of sending the whole image every frame you only send whatever has changed and your device updates just those things instead of everything. As a side effect it’s really easy to jump forward but absurdly hard to jump backwards.
To jump forward your device just has to ask for more changes and apply them.
To jump backwards your device has to ask for the relevant key-frame and everything it needs to apply to it

Rewinding is not considered a common action and in designing (consumer) video streaming software. Rewind performance is often sacrificed for making everything else faster and more efficient.

A common example of such trade of involves prefetching video from the servers (slow) storage(HDD) into its (fast) RAM, before it’s transmitted. After transmission, the cached bit of video in RAM is freed.

Well that is a gross simplification. There is on top of that a few more wrinkles to do with multiple video streams on the server and different layers of caching. These effect add up to make the hit to your playback fairly significant.

There do exist video systems meant for interactively jumping around a video stored remotely.They are typically used by production or security companies. They are not as efficient at serving many videos to a large user base.

When you fast forward, the service is already pre-preparing that data for you, because it knows you’re going to request it in next 30 second or so

But with reverse, not only has your player tossed out the data, the server has too. So it has to go into back archives and retrieve the data once again.

This can have something to do with how video compression works. You don’t get every frame streamed to you that you see. You get a handful of keyframes, and then a bunch of instructions on how to change that keyframe to make it look like the next frame. (This is why when a video gets corrupted everything will go really messy and sometimes green, for a few seconds and then back to normal when it loads in the next keyframe).

Going forward, the system just runs the instructions quickly, which is a client side activity.

Going backward, the system needs to find the closest keyframe to where you want to skip to, download that, and then download all the instructions after that to get you to the point you want to view, and then apply the instructions to the keyframe so that you can view there.

Shouldn’t they keep a portion of the stream in the device memory for such occasions? Like a minute or so? Since people are using streaming more and more, that would be a nice feature