DivX 5.2 takes too many keyframes!

[aketon]

I've just made a small test with the latest DivX codec and the Xvid 1.0.1! The source was a DVD-PAL movie, from which I took only 1500 frames to make the test! The image size was 640x256! My settings:

DIVX
----
Encode Performance: Slow
Bitrate: 880
Psychovisual Enchancements: Fast
Quantization Type: H.263
Max Keyframe interval: 300 frames
NO Profile
Bidirectional encoding: Adaptive Multiple Consecutive
I made 3 passes!

XVID
----
Default
2-pass
Bitrate: 880
Trellis: ON


And here are the strange results:


DIVX
----
Quality was very bad! It wasn't as much detailed as XviD was! And it had too many blocks here and there!
NUMBER OF KEYFRAMES: 117


XVID
----
Quality was very good! It was sharper than DivX and I didn't saw not even one block!
NUMBER OF KEYFRAMES: 22 !!!!!!!


The clip had some fast scenes, but what I really can't understand is, why divx used so many keyframes and the quality was still worse than XviD which used only 22!

(Sorry for my bad english)

BYE!!!

[bond]

more keyframes doesnt automatically mean that the quality should be better, otherwise why should anyone mess around with p- or even b-frames ;)
i contrary, using keyframes-only for example, compared to using p/b-frames too, will show less quality than the later

[Sagittaire]

the problem is to find a good compromise: with DivX you can regulate the senssibility for IFrames Threshold

[AsTimeGoesBy]

I have found a very strange keyframe behaviour (http://forum.doom9.org/showthread.php?s=&postid=566302&highlight=absorbs+35+keyframes+within+2+seconds#post566302) for DivX v5.21 too.
I never have experienced anbything similar on older DivX versions so i don't trust it...

But tell me please, i haven't found here something with the expression 'keyframe distance'.
Is a keyframe distance of max. 750 frames too much? - I know the effects for cutting and seeking,
but will such a big keyframe interval also have a negative influence on quality in any kind?
Will this perhaps be the reason why DivX 5.21 gets into trouble?

[manono]

Yes, during a long scene, without a scene change, if the max keyframe distance is too large, the video quality can deteriorate. It's generally recommended to set the max keyframe distance to 10x the framerate. 250 for PAL, 240 for film, and 300 for video material.

[stephanV]

no it cant hurt... the maximum key frame interval is only there for seeking...
of course... the codec will always insert a key frame when it thinks its necessary regardless of the maximum interval... in this case it even puts in far too many

ideally a movie contains as few key frames as possible...

that 10*frame rate rule doesnt make any sense i think though... but i still have to think some more about that.

[akupenguin]

Very large keyframes intervals can degrade not just seeking, but also quality.
The MPEG-4 spec defines the mathematical operation of DCT, but all real codecs have to use finite precision integer math, so they introduce some rounding errors. Different codecs round differently, so that introduces small errors into the video. With lots of P-frames in a row, these errors accumulate. (B-frames do not add to the accumulation, since they aren't used for prediction of other frames.) As long as you use the same version of the same codec for decoding, there will be no problems. But if you want your video to look good in just any MPEG4 decoder, or maybe even other versions of DivX, 10 seconds is a sane limit on I-frame interval.

Sidenote: Newer codecs (like H.264) specify an exact integer transform, so don't suffer from this accumulation of error.

Back to the issue of DivX using too many I-frames: There are some video sequences (particularly fades) that are best coded as IBIBIB..., but while that is valid MPEG-4, DivX doesn't support it and switches to all I-frames. I think XviD uses a smarter frame-type decision, and may encode those as PBPBPB instead.

[AsTimeGoesBy]

Thanks, interessting aspects...

Originally posted by akupenguin
...
The MPEG-4 spec defines the mathematical operation of DCT, but all real codecs have to use finite precision integer math, so they introduce some rounding errors. Different codecs round differently, so that introduces small errors into the video. With lots of P-frames in a row, these errors accumulate.
...

Any idea how such errors will look like? - Will the video 'lose the optical contact' to the next keyframe?


Actually i'm encoding a video with DivX 5.11 (5.21 seemed too riskful to me). The choosen max. keyframe distance is 750 frames, or max. every 30 seconds at 25fps. I will see (in many hours ...;)) where and how often these 30 seconds are really used.

[akupenguin]

Note: this is about the most extreme example I could find. Most of the time you won't even notice, what with better iDCT, B-frames, and the occasional intra-blocks.

The good:
http://img115.exs.cx/img115/9605/idct_good.png
The ugly (after 300 consecutive P-frames with a fast iDCT algo):
http://img128.exs.cx/img128/8743/idct_bad.png

[AsTimeGoesBy]

Thanks for the examples, i have checked them out with IrfanView switching form good to bad (and back again).
I hope i won't to see such image effects on my 750-keyframe-interval divx when playing it on Sunday on a stand-alone 'living-room' DVD/DivX device.

Maybe it would be a good idea to shorten my keyframe interval the next time in order to reduce the probability of such long consecutive P-frames intervals.

[AsTimeGoesBy]

Originally posted by akupenguin
...
There are some video sequences (particularly fades) that are best coded as IBIBIB..., but while that is valid MPEG-4, DivX doesn't support it and switches to all I-frames. I think XviD uses a smarter frame-type decision, and may encode those as PBPBPB instead.
...
Indeed i have had (again) such a movie with lots of such long fading scences or scences where the camera is moving (related to the target/content).
Can it be said how much more such fade scenes would need a higher bitrate (only approximately)? - 30% more or even 2x, 3x, ... ?
I ask this because i have increased the bitrate (for my hole encoding job) form 1700 to 2Mbit and my DivX still don't look bad at some places.

Would Xvid be an alterative? - I have no experience with it but belong this comparison (http://www.doom9.org/codec-comparisons.htm) it gets respectable results...

[akupenguin]

Camera motion is no problem. That's no different from any other motion that MPEG4 is designed to compensate for.

(Note: the following paragraph only applies to scenes where DivX actually uses excessive I-frames. I don't know whether all fades trigger that.)
In a pure fade (that is, just changing brightness and camera panning allowed, but no motion within the scene), DivX will use exactly 2x the bitrate of the ideal encode, due to its lack of support for IBI frame sequences. I think XviD does better, but its adaptive B-frames may still be suboptimal, and you may have to turn off its "closed GOP" or "divx5bvop" option (I don't remember which is the current name). I know libavcodec will do the right thing. In practice, of course, there are extra little inefficiencies (uneven fading, motion), so it's not quite a factor of 2x, but close.

Yes, XviD is a valid alternative. Even aside from this issue, I prefer XviD over DivX in most cases.

Side note: H.264 (the successor to MPEG4) supports fade-compensation, so there a pure fade-in is only a little bigger than a single I-frame, and a fade-out ideally takes no bits at all (other than the frame headers). But you'll have to wait for a mature implementation, because it's not there yet.

[AsTimeGoesBy]

Originally posted by akupenguin
...
I think XviD does better, but its adaptive B-frames may still be suboptimal, and you may have to turn off its "closed GOP" or "divx5bvop" option (I don't remember which is the current name). I know libavcodec will do the right thing.
...
Yes, XviD is a valid alternative. Even aside from this issue, I prefer XviD over DivX in most cases.
...

Thanks i will try to encode 'Moulin Rouge' with it XviD the next days. I have encoded it now twice with DivX 5.21 and still it is not satisfiying me.
But XviD with its "closed GOP" and "divx5bvop" doesn't seem it would be easy to set up!? - I guess i must look for a help guide first... ;)


Originally posted by akupenguin
Side note: H.264 (the successor to MPEG4) supports fade-compensation [...] But you'll have to wait for a mature implementation, because it's not there yet.
So when will it be available? - Will this be a high-professional codec and cost a lot of money?


______
Edit:
I have removed again my DivX-5.21-keyframe-placement samples.
The quality of these samples was so bad that after some lecture
i guess the encoding was negatively influenced in any other way.

[akupenguin]

Originally posted by AsTimeGoesBy
So when will it be available? - Will this be a high-professional codec and cost a lot of money?
See the new codecs forum (http://forum.doom9.org/forumdisplay.php?forumid=54) for details. The short version is:
Nero/Ateme's implementation has passed beta and will be commercially available sometime soon (officially: "2004").
X264 is already available and free, but hasn't yet implemented all of the possible features. (In particular, it doesn't yet have fade compensation.) It will improve whenever I have time to work on it.

[AsTimeGoesBy]

So if i understand right, You are yourself developping on this codec!? - Wow, that's great!
I must check it out as soon as my DivX jobs are over.
In meantime i will switch over to the H.264-threads,
reading about performance, hardware support and so on... ;)

[akupenguin]

I'm not the original author (he was hired by Ateme ;)), but it would be a shame for Free Software to be beaten by a proprietary solution, so I joined the project.

[LordRPI]

ATGB,

Saw your post on forums.divx.com too.

[AsTimeGoesBy]

Yes doulbe-posted. Sometimes i quickly need answers because my job list is very impatient. ;)
However, thanks for your attention!

And thanks too for your contibution! Although i have found scenes where v5.21 didn't reach the expected results i must say it's a nice version, specially then looking at the speed of the slow mode. :)

Ok, the keytrame 'story' remains but i'm not sure how far or if it really damages the quality/bandwidth ratio.
If you have some minutes left, please check out maybe my little keyframe note (http://forums.divx.com/viewtopic.php?forum=5&topic=60986).

[akupenguin]

Originally posted by AsTimeGoesBy on forums.divx.com
There should exist the possibility to allow exceptions like: Set 300 frames for the max. keyframes distance, but if there follows up a strong scene-change within 60 frames after the forced/considered keyframe postion, extend the max. keyframe distance till there. replying here because I don't want to register for yet another forum

That is possible, and a good idea. But only in multi-pass mode, and it requires extra approximations and thus slightly worse rate prediction unless you're using 3-pass (which is recommended anyway, but not everyone likes the extra time).
See, when the codec gets to frame #300, it has to decide immediately whether to encode it as intra or predicted. It doesn't get to look ahead, because the encoding program hasn't passed it those frames yet. Now, you can record the scene-change metrics in the multi-pass log file, and the 2nd pass can then decide on a better placement of I-frames. But that introduces uncertaintly about the size/complexity of the frames involved in the switch, and to a lesser extent the ones just after the new or former I-frame.

[AsTimeGoesBy]

Originally posted by akupenguin
That is possible..., and a good idea. But only in multi-pass mode, and it requires extra approximations and thus slightly worse rate prediction unless you're using 3-pass (which is recommended anyway, but not everyone likes the extra time).
Possible (only)? - Well, i never have serached for it really, but i never have noted in any of my DivX files a scene there the codec would have extended my manually set keyframe limit.


Originally posted by akupenguin
See, when the codec gets to frame #300, it has to decide immediately whether to encode it as intra or predicted. It doesn't get to look ahead, because the encoding program hasn't passed it those frames yet.

That's exaclty the point. The codec should look ahead and analyze the se 'tolerance' frames (and store these data temporarly for further use).
I other words the real encoding process should be delayed to know what's comming up. - Wouldn't that be logic? I mean nobody drives car by night without lights on.
So a codec should too and not wait until the hole 2nd/next encoding pass.


Originally posted by akupenguin
Now, you can record the scene-change metrics in the multi-pass log file, and the 2nd pass can then decide on a better placement of I-frames. But that introduces uncertaintly about the size/complexity of the frames involved in the switch, and to a lesser extent the ones just after the new or former I-frame.
I guess i see what you mean. But tell me please, in reality is there really a REplacement of i-Frames between 2nd and 3rd multi-pass?

[akupenguin]

Originally posted by AsTimeGoesBy
The codec should look ahead and analyze the se 'tolerance' frames (and store these data temporarly for further use).
I other words the real encoding process should be delayed to know what's comming up. - Wouldn't that be logic? I mean nobody drives car by night without lights on. Yes, it should. But that's not possible in VfW. Someday I'll add it to mencoder, or maybe Gstreamer will become usable.
It would be nice to see a random-access encoder API, and do away with the whole `pass` thing entirely: Just let the codec do any analysis it wants in any order, and no need for the user to run multiple passes separately. Hmm... an Avisynth-based codec?

So a codec should too and not wait until the hole 2nd/next encoding pass. Actually, I think best solution (aside from my musings above) is a 3pass encode with frame types finalized on the 2nd pass. Unless you want to set 'tolerance' > 'keyint', which would consume a huge amount of RAM for the uncompressed frames.

I guess i see what you mean. But tell me please, in reality is there really a REplacement of i-Frames between 2nd and 3rd multi-pass? Not yet, but it will be included in x264, along with other H.264 features which require such a delay. (long-term reference frames, adaptive short-term references, I vs IDR decision)

[AsTimeGoesBy]

That sounds very promising...! - Thanks for all your work on it!

I'm looking forward to check out once such a highly tuned H.264 codec!