-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Seek in millisecond #4552
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Are you referring to seeking using the |
Hello I should have been more specific. I tried seek .5 and seek -.5 but that results in a +/- 10 second seek. Am I doing something wrong or is there any way to achieve slower than 1second seek? |
I'm still unsure as to how you are seeking. Are you using Anyway, the +/- 10 seconds behavior has to do with how videos are normally encoded. A primary goal of most of the various video coding formats is to reduce the size of the resulting digital video file. Priority is given to playback in the forward direction. Imagine 4 frames from a film based movie. Each frame is a picture of a ballpark. Nothing is moving except an airborne baseball moving in the sky. With a film based movie each frame is a complete separate picture. This could be converted to digital by encoding each frame separately as an individual picture. Trouble is the resulting digital version of the movie would be massive. One of the techniques to reduce the size is to use keyframes and delta frames. Imagine we include a full picture for the first frame and instead of a full picture for the second frame we include instructions to erase the baseball in the first frame picture and draw sky there instead and then draw the baseball in a different position. And we do the same for the next two frames. Our digital version now consists of one full picture and 3 sets of changes to that picture in order to recreate each of the 3 following frames. We have greatly reduced the amount of space required for the digital version of this movie. This is all fine for normal playback, but what if you tell the player to seek to a particular time and restart playback there? What does the player do if that time lands on a frame represented only by instructions on how to change the displayed picture? You would not want it to just display a baseball and a baseball sized bit of blue sky against a blank background. But that is all that is in the file for this point in time. To display a full picture you must find a frame that has a full picture and then apply changes until you have generated the picture for this frame. Depending upon where the seek position lands and how the digital video was encoded seeking might be delayed while the player decodes many frames to display the frame at the specified point in time. A way to speed up seeking wo 8857 uld be to find the nearest full picture (keyframe) and start playback from there. When you try and seek forward 5 seconds, or in this case .5 seconds and you notice playback actually jumped forward 10 seconds, this is what is happening. The IBM tutorial Keyframes, InterFrame & Video Compression is a good introduction to video compression. When you seek IINA sends a seek command to mpv. To speed up seeking that command defaults to restarting playback at a full frame (keyframe) near the time specified. The time interval between keyframes is up to the person who encoded the video. Shorter intervals increase the size of the resulting file. The mpv I've never looked into |
Thank you for this detailed response into the inner workings. I really appreciate it. Haven't had time to read it thoroughly just yet but starting to right now. |
Hi,
Was wondering if there was a way to seek less than 1 second. I tried to use decimal points but it won't work. Am i doing something wrong?
The text was updated successfully, but these errors were encountered: