A Quick Question

[xox]

Hi all,

Somebody posted a message about Divx in other forum and it basically reads (copy and paste):

"DivX style codecs are not designed to seek backwards well and if you have a few layers of video it can make an older pc churn a bit during editing"

Is this statement true? Especially with the 'seek backwards' thing?

[dimitrius]

not really.

the structure of the video stream is such that some frames can only be shown after other frames have been shown already.

the simplest stream description is like this:

take one frame, compress it and call it keyframe, take the next frame, find the differences between this and previous frame, then compress the differences only and call it predicted frame.

this means that to seek backwards (and let's say you seek right in the middle of alot of these predicted frames) the codec has to go back to a preceding key frame, then apply the differences that are stored in the following predicted frames until the frame you are seeking to.

the codec (or the player) keeps some of the frames that have been just displayed in memory (buffer) so that seeking alittle bit backward is instant.

seeking alot forward or backward should take about the same amount of time since in both cases the likelihood is that the codec will have to decode alot of frames.

if you are seeking to keyframes only then seeking both ways is exactly the same.

seeking can be hampered by the container (avi, ogm, mkv).

[esby]

mmm actually what wrote dimitrius is not exactly true.

The simple example possible should be:

Let's have a keyframe (or IFrame), that you are able to decode by itself.
If you want to add another frame, supposing you want to save space, and calculate only the difference, you'll end adding a deltaframe (or PFrame)

Thus you can have: I P P P P P I P P I

Now to where it might be not exactly true:

if you are Pframe before the second IFrame,
if you want to reverse, it might work (supposing the operation is possible)

But if you are at the following IFrame, to get the precedding Pframe,
you need to go back to the first Iframe, and decode all the next frames till you end to the frame you asked.
Because you cannot calculate it directly in the reverse way.
To illustrate the problem:
I P P P P P I P P I
0 1 2 3 4 5 6 7 8 9

If you are at 7(I), you can get to 6 directly since it is containing itself.
or you may be able to calculate it from P6, (supposing the operation is possible, which I honestly don't know), but it will be a lack of time.

now if you are at 6(P) to get 5 you need to do:
6 -> 0 1 2 3 4 5
since 6 & 5 are not 'linked' together, or you would not need to add a keyframe...

So each time you'll have a Keyframe, with backward, you'll have to fall back to the previously Keyframe, then decode all the frame to the end of the segment...
and there if your computer is old, and if you are very spaced kf,
you'll have a playback problem.

esby

[xox]

Originally posted by esby
mmm actually what wrote dimitrius is not exactly true.

...[snipped]

So each time you'll have a Keyframe, with backward, you'll have to fall back to the previously Keyframe, then decode all the frame to the end of the segment...
and there if your computer is old, and if you are very spaced kf,
you'll have a playback problem.

esby
I know the bit about very spaced kf that might create playback problem, and requires more of your pc processing power. But what about this part of the statement: "divx is not designed to seek backward well"? Is this just divx? My guess is a very spaced kf can create seeking problem on any codec, not just divx?

[esby]

it is not linked to divx,

but to any codec using keyframe and deltaframes

anytime you are on a keyframe and want to access the previous frame,
you need to decode the previous keyframe and decode all the following delta frames to the one you want...

That's one explanation of the delay.

Another one, is that everytime you seek with some application,
they might decode from the previous kf directly (and not do a reverse playaback from the current position)

esby

[xox]

Originally posted by esby
it is not linked to divx,

but to any codec using keyframe and deltaframes

anytime you are on a keyframe and want to access the previous frame,
you need to decode the previous keyframe and decode all the following delta frames to the one you want...

That's one explanation of the delay.

Another one, is that everytime you seek with some application,
they might decode from the previous kf directly (and not do a reverse playaback from the current position)

esby
That's what I thought - it's not just MPEG4 or Divx, but any MPEG file, as described here (http://nickyguides.digital-digest.com/keyframes.htm).