Why delta > key frame size ?

[BxWrapper]

I just checked some my Divx rips and a little bit suprised to see typical stats below, taken from Vdub file information menu:


Min/avg/max/total key frame size: 2342/19438/85402 (24356K)
Min/avg/max/total delta frame size: 8/4719/168853 (936084K)


I use DivxPro default setting where scene detection threshold is 50% and known to be the middle ground.

But why the max. delta frame size is much higher (almost double) then max. key frame size ? This pattern is consistent in all my rips.

I can do trial and error lowering the scene detection threshold but appreciate any advise.

[N_F]

I was under the impression delta frame = key frame :confused:

[hakko504]

Originally posted by N_F
I was under the impression delta frame = key frame :confused: No, no, no. Delta is a mathemathical term for difference, in this case a frame encoded as a difference between the frame and the previous one, also called P-frame. B-frames are also a form of delta frames but in that case you use both the last I/P frame and the next I/P-frame to decide the difference.
Key frames are frames that do not rely on other frames when encoded.

Warning: very theoretical
If f(x) = the original frames, and I/P/B(x)= a frame encoded as a I/P/B frame, and g is a quantization function, and i,p are constants that minimizes the input to g, and we have I frames every 4th frame and B-frames every 2 frames then:
I(4*n)=g(f(4*n))
P(4*n+2)=g(f(4*n+2)-i*I(4*n))
B(4*n+1)=g(f(4*n+1)-p*P(4*n+2)-i*I(4*n))
B(4*n+3)=g(f(4*n+3)-p*p(4*n+2)-i*I(4*n+4))

[N_F]

Originally posted by hakko504
No, no, no. Delta is a mathemathical term for difference, in this case a frame encoded as a difference between the frame and the previous one, also called P-frame. B-frames are also a form of delta frames but in that case you use both the last I/P frame and the next I/P-frame to decide the difference.
Key frames are frames that do not rely on other frames when encoded.
Thanks for the info. I remember some time ago when I read a guide written by doom9 about xvid. Somewhere in there he made a comment that the xvid configuration box used both key-frame and [??????] to refer to the same thing. I thought the [???????] was delta frame, but I guess I remember wrong. The guide is quite outdated and I don't know if it still exists.


[Warning: very theoretical
If f(x) = the original frames, and I/P/B(x)= a frame encoded as a I/P/B frame, and g is a quantization function, and i,p are constants that minimizes the input to g, and we have I frames every 4th frame and B-frames every 2 frames then:
I(4*n)=g(f(4*n))
P(4*n+2)=g(f(4*n+2)-i*I(4*n))
B(4*n+1)=g(f(4*n+1)-p*P(4*n+2)-i*I(4*n))
B(4*n+3)=g(f(4*n+3)-p*p(4*n+2)-i*I(4*n+4)) [/B]

I'll have to take a closer look at this... :)

[hakko504]

From Doom9's XviD guide:Min keyframe interval is how often a keyframe (aka I-frame, did you notice that the GUI uses the two terms interchangeably?) is inserted at the maximum.

[N_F]

So basically:

I-frame = keyframe --> Stores complete picture
P-frame = delta frame --> Only stores the difference from the last I/P/B-frame
B-frame = delta frame --> Only stores the difference between the last and next I/P-frame (B-frame? Can two B-frames be next to each other?)


On a little different note: B-frames are used in MPEG-1 (unless I've misunderstood something) which is an old technique. How come B-frames are something relatively new when it comes to DivX and XviD?


Thanks for educating me :D

[hakko504]

You can put as many B-frames as you want next to each other, they still can only get their 'base data' from the next and previous I/P frame, never from another B-frame.

There is a number of reasons why B-frames haven't been used until now in DivX/XviD. Requires a lot of calculating power, both for encoding and decoding. AVI doesn't really support B-frames, only I/P is a valid part of AVI's. The techniques used in MPEG-4 for separating and encoding objects makes B-frame interpolation very difficult. The developers of XviD/Divx has probably decided that it was MUCH more important to get I/P support stable and efficient before adding B-frames. The relative gain (bitrate/quality) compared to the time needed to code and test b-frame support isn't overwhelming, but merely an added bonus.So why was it available already in MPEG-1 back in 1990? Because a basic support of B-frames isn't very hard to code, but MPEG-4 requires a lot more than just basic support to work at all. Still, a film could take days to encode in MPEG-1. Realtime support wasn't even heard of then. My first SW based MPEG player actually had an option to turn off B-frame decoding if the computer wasn't fast enough to decode them - and it was necessary to do so on my P-90 (in 1995), but my second PC, a P-200 non MMX, was able to play them back in a window correctly.

Edit: Spelling corrected. 'Flim', I must be thinking faster than I write.

[BxWrapper]

When delta frame size > key frame size, an indication of poor scene detection, the idea of using B and P frame for less file size with the same quality is no longer optimum.

I wonder why default setting of DivX5Pro creates this kind of mesh.

[hakko504]

@BxWrapper

I'm sorry we strayed a little OT there, but back to your original question: It is very possible to have P-frames larger than the I-frames, if they are very close in order. Say frame n is an I-frame. Then if frame n+2 is a scene change then it is quite possible that both DivX and Xvid decides that it is too early to have a new I-frame there and leaves it as a P-frame.

[N_F]

Originally posted by hakko504
You can put as many B-frames as you want next to each other, they still can only get their 'base data' from the next and previous I/P frame, never from another B-frame.


I assume a P-frame can't get data from a B-frame either?

[hakko504]

Nope, P-frames can only get their data from a previous I/P-frame

[BxWrapper]

It is very possible to have P-frames larger than the I-frames, if they are very close in order. Say frame n is an I-frame. Then if frame n+2 is a scene change then it is quite possible that both DivX and Xvid decides that it is too early to have a new I-frame there and leaves it as a P-frame

I expect DivX and Xvid employ advance scene change detection algorithm to avoid that kind of situation by enforcing I frame :(

[?¿öM¿?]

You might want to take a look at this thread - http://forum.doom9.org/showthread.php?threadid=19436&pagenumber=1
it explains (and debates) this topic rather well.;)

[BxWrapper]

@?¿öM¿?

Your nick name hard to spell but quite easy to copy and paste. :)

Thank you for the link. But it still does not explain why should delta frame > key frame size happened.

When motion prediction algortihm finds that motion compensation errors are too big for a Predictive frame, it should intruct the coder to use intra frame instead.

[hakko504]

Maybe the simple, but overlooked, answer is that if it hadn't used a p-frame, for that particular frame, the I-frame size would have been much larger.