Answers.Body: <p>Let me describe what the bottleneck in seeking is.</p>
  
  <p>You didn't say what format are your videos encoded in, but I'm guessing you are using H.264 or maybe MPEG-2. Am I correct?</p>
  
  <p>To maximize quality, these codecs have different compression formats, and each frame gets encoded differently. This is a brief summary of the compression types:</p>
  
  <ul>
  <li>I-frames (I stands for intracoded) are frames that can be decoded easily, as they don't depend on any other frames.</li>
  <li>P-frames (P stands for predictive) are frames that encode only the differences from one or more previous I or P-frames. To decode a P-frame you need to first decode all the I and P-frames that this frame depends on.</li>
  <li>B-frames (B stands for bi-directional) are frames that encode differences like P-frames, but unlike P-frames, these differences can refer to previous or future I or P-frames. As with P-frames, To decode a B-frame you first need to decode all the past and future frames that are dependencies.</li>
  </ul>
  
  <p>So now I hope the performance problem with seeking is clear. You jump to the middle of the movie clip, and chances are, you are going to land on a B or a P-frame. So the decoder now needs to find all the references required by that frame, decode them in the correct order and only then it can finally decode the target frame.</p>
  
  <p>To achieve better compression and higher quality, encoders create a lot less I-frames than P or B-frames. The idea is that the compressed stream starts with a really high quality I-frame, and then for a number of frames that follow, smaller P and B frames encode just the differences. Of course if you go for a long time like this quality starts to degrade, so at some point the movie will include another big and nice I-frame and the cycle starts again.</p>
  
  <p>When a movie clip is played from start to end, the different frame types appear sorted in the file so that when playback reaches a given frame, all its references have already been seen by the decoder. This allows for very efficient playback at 1x speed. Unfortunately when you play at other rates or when you seek the amount of work the decoder needs to do to find referenced frames is much larger because frames are read out of sequence.</p>
  
  <p>So going back to your question, the problem isn't really in the decoder. If you need to improve seek time you need to use videos that are encoded to minimize seek time. In essence this means videos that have more frequent I-frames, also called keyframes sometimes. The more I-frames you have, the less references will be required to decode P and B-frames so the decoder will have less work to seek.</p>
  
  <p>I hope this helped understand the problem.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-02-03T23:11:17.400Z
Answers.Text: Well explained! One doubt - how does the container affect seeking speed? When I encode an H.264 / H.265 video, seeking time is much faster on VLC on ios (iPad) when I use MP4 container, and really bad when I use the same video in MKV container.
Answers.UserDisplayName: sfxedit
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2012-02-01T06:07:33.703Z
Answers.LastActivityDate: 2012-02-01T06:07:33.703Z
Answers.UserDisplayName: Miguel
Body: <p>I am using mostly Haaly Media Splitter for input and ffdshow for decoding (libavcodec).
  Actually I am ok with the default profile 7 installation of k-lite codec pack.</p>
  
  <p>At the moment I have the default options in the ffdshow decoder configuration and in the Haali media splitter filter.</p>
  
  <p>What I want is to make seeking as fast as possible. Any suggestions on how to detect the bottleneck or how to reduce seeking time?</p>
  
Tags: <video><codec>
Title: Which decoder allows for fast seeking or how to configure k-lite codec pack?
UserDisplayName: Odys
ThreadText: # Which decoder allows for fast seeking or how to configure k-lite codec pack?
  
  (Asked by: username_0 on 2012-01-29)
  
  I am using mostly Haaly Media Splitter for input and ffdshow for decoding (libavcodec).
  Actually I am ok with the default profile 7 installation of k-lite codec pack.
  
  At the moment I have the default options in the ffdshow decoder configuration and in the Haali media splitter filter.
  
  What I want is to make seeking as fast as possible. Any suggestions on how to detect the bottleneck or how to reduce seeking time?
  
  **Tags:** video, codec
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2012-02-01. Score: 8 | Accepted answer
  
  Let me describe what the bottleneck in seeking is.
  
  You didn't say what format are your videos encoded in, but I'm guessing you are using H.264 or maybe MPEG-2. Am I correct?
  
  To maximize quality, these codecs have different compression formats, and each frame gets encoded differently. This is a brief summary of the compression types:
  
  * I-frames (I stands for intracoded) are frames that can be decoded easily, as they don't depend on any other frames.
  * P-frames (P stands for predictive) are frames that encode only the differences from one or more previous I or P-frames. To decode a P-frame you need to first decode all the I and P-frames that this frame depends on.
  * B-frames (B stands for bi-directional) are frames that encode differences like P-frames, but unlike P-frames, these differences can refer to previous or future I or P-frames. As with P-frames, To decode a B-frame you first need to decode all the past and future frames that are dependencies.
  
  So now I hope the performance problem with seeking is clear. You jump to the middle of the movie clip, and chances are, you are going to land on a B or a P-frame. So the decoder now needs to find all the references required by that frame, decode them in the correct order and only then it can finally decode the target frame.
  
  To achieve better compression and higher quality, encoders create a lot less I-frames than P or B-frames. The idea is that the compressed stream starts with a really high quality I-frame, and then for a number of frames that follow, smaller P and B frames encode just the differences. Of course if you go for a long time like this quality starts to degrade, so at some point the movie will include another big and nice I-frame and the cycle starts again.
  
  When a movie clip is played from start to end, the different frame types appear sorted in the file so that when playback reaches a given frame, all its references have already been seen by the decoder. This allows for very efficient playback at 1x speed. Unfortunately when you play at other rates or when you seek the amount of work the decoder needs to do to find referenced frames is much larger because frames are read out of sequence.
  
  So going back to your question, the problem isn't really in the decoder. If you need to improve seek time you need to use videos that are encoded to minimize seek time. In essence this means videos that have more frequent I-frames, also called keyframes sometimes. The more I-frames you have, the less references will be required to decode P and B-frames so the decoder will have less work to seek.
  
  I hope this helped understand the problem.
  
  > **Comments:**
  > **username_2**: Well explained! One doubt - how does the container affect seeking speed? When I encode an H.264 / H.265 video, seeking time is much faster on VLC on ios (iPad) when I use MP4 container, and really bad when I use the same video in MKV container.  
  
  ---
  
  