Take the 2-minute tour ×
Video Production Stack Exchange is a question and answer site for engineers, producers, editors, and enthusiasts spanning the fields of video, and media creation. It's 100% free, no registration required.

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?

share|improve this question
add comment

1 Answer 1

up vote 2 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.