View Full Version : DivX 5.0.1 increase in quality?????
chipzoller
15th April 2002, 20:57
I just got done encoding a bond movie that some of ya'll might know. "The Spy Who Loved Me." I did it with Xmpeg 4.5 and with DivX 5.0.1 and I remember seeing on the DivX.com website that they boast a reduction in time for the encoding and an increase in quality with the same bitrate settings. I'm not seeing this people. "The Spy Who Love Me" is about 2:05:21 (Hrs:Mins:Secs) and usualy to put it on one CD I would have to use a bitrate of about 680-685. Well I have been using DivX 4.12 and I switched to DivX 5.0.1...I mean don't get me wrong, its great and everything, but the filesize isn't any smaller. They advertise a 20-30% reduction in filesize but I don't see that. The 2 pass encoding took about 16 hrs.!!!! The video looked and played perfectly but the time is just too much of an issue. I don't mind 10-12 hrs. but thats too much.
What does someone else have to say about this???
chip
Selur
16th April 2002, 06:46
The average bitrate of a 2pass encode shoudn't chance or 2pass wouldn't be as useful as it is. (but the quality should be a bit better in with DivX5)
About the encoding time,.. ist allways dependend on the resolution the iDCT, the colorspace, the filters and the codec settigns used,...
Cu Selur
Ps.: and I think this thread should be moved to the DivX section ;)
chipzoller
16th April 2002, 15:02
Optimized MMX
Pseudo BiCubic (like you suggested)
1:1 DivX
YUV12
no other codec settings (i.e. mpg4 tools)
thats my settings, but 16 hrs. doesn't seem right.
chip
Selur
16th April 2002, 18:04
hmm,.. forgot was you cpu was, but for 400-600Mhz this would be normal,..
Cu Selur
Ps.: It'll get faster if u use Bressenham instead of pseudo bicubic or lower the resolution,...
chipzoller
16th April 2002, 18:18
My CPU is Pentium 3 @ 750 mHz
I used to use the bressingham filter. I suppose it does an ok job.
I am doubleing the VCD resoltuion I told you I used to use.
Oh and I found out this about "Compile whole file"
If you don't check compile whole file and enter the seconds then your time measurement will be pretty accurate.
If you check it, then the time measurement is WAY off.
chip
Selur
16th April 2002, 20:16
*gig* never even looked at the measurement ;)
(but it's nice to know)
Cu Selur
nomad32
17th April 2002, 08:46
Originally posted by chipzoller
Optimized MMX
Pseudo BiCubic (like you suggested)
1:1 DivX
YUV12
no other codec settings (i.e. mpg4 tools)
chip
To get most of the gain out of DivX 5 you should enable the MPEG4-Tools.
You should tick "Use GMC and Use Bidirectional Encoding" but not "Use quarter pixel" because that is still buggy.
Cheers
Selur
17th April 2002, 15:57
ehm, but that wouldn't speed up the process,.. as far as my experience serves me right it'll get slower with gmc,.. and at least my lattest tests didn't show a visible difference with or without gmc enabled (except the speed).
Cu Selur
chipzoller
17th April 2002, 15:59
What about bidirectional encoding?
what does that noticably produce??
chip
Selur
17th April 2002, 17:42
At least for me it produces (visible) better quality for 1 CD Rips,...
Cu Selur
chipzoller
17th April 2002, 20:40
Well I'll give it a shot then...
chip
dragoman
18th April 2002, 00:31
Hi,
Have to understand that the "smaller filesize" claims by DivX 5 are true, but your method hasn't changed. You are still putting the same avg bitrate into your two-pass settings, so of course the filesize will be the same. This is good, filesize predictability, right?
The difference is that DivX 5 uses the bits more efficiently, which means that your encode of the same size should be better quality.
If you want to test the "better filesize" claim, encode both movies at 100% quality 1-pass setting. I'll bet the DivX 5 encode is smaller, especially with B-frames enabled....that's the difference.
Also, your choice of encoder might have something to do with it. Flask encodes both audio and video at the same time, which can cause it to be very slow. Try using Vdub and encoding audio seperate. YOu might see a speed boost.
dragoman
atracus
19th April 2002, 21:46
hi,
since my first experiments with DivX5, anytime I've been keeping B-frames enabled and I encoded in 2-passes at the bitrate suggested in G-Knot, I regularly got a smaller filesize; what I normally do is to reencode (just 2nd pass) with a linear interpolation of the "right" bitrate.
When aiming to a first-bood pass, a good "rule of thumb" is to add approx. 20-30Kbps when in the range of 680 to 750Kbps. If I range too high (maybe 710 or 720Megs final filesize), I cut some endtitles off.
hope this helps
regards.
atracus
dragoman
19th April 2002, 23:52
Hi,
I have noticed this as well, the fact that the filesize is a few MB's shorter.
The reason (I think) is that when doing the first pass, DivX 5 predicts the size of each frame in accordance to the set bitrate...that is, it tries to allocate enough bits to each frame so that it sticks to your average bitrate but still gives optimum quality.
If you read the log file, each frame has a line something like this:
"Frame 26: PRESENT (P), complexity 0, quant multiplier 0.500000, texture 0, total 752
Progress: expected 537072, achieved 25916, dq 0.600000, new quant 2"
If you notice, the codec assigns a quanitzer during the first pass, which is shown by the expected size of 537072. After compressing the frame in actuality, the codec discovers that the achieved filesize is much lower, 25916, and therefore assigns a new quantizer to attempt to boost the quality of that frame, since it is so compressible.
This particular example the new quanitzer is 2, presumably because the filesize of the frame is so much lower than the predicted filesize.
This happens in almost every frame I can see while using divx 5....that means that although the codec tries it's best to use all the bits available, sometimes (like in this case) the frame is so compressible it applies a 2 quantizer and dicards the rest. This is why the file is a bit smaller than predicted.
A fix I've found is to add 20-30kps to the divx4 prediction given by Gknot....that seems to fix it.
dragoman
Selur
20th April 2002, 08:10
strange, for me GKnot works fine as calculator,... (u didn't forget to let Gknot calculate the audio overhead&Co, did you?)
Cu Selur
dragoman
20th April 2002, 16:03
Hi,
No, I didn't forget.
I even encode the audio and the credits first, then use the audio file and file add buttons to make sure I get the exact right bitrate.
For instance, I just finished encoding Gone in 60 Seconds to a 1-cd size rip. Final size came out to 701 MB. The calculated bitrate that Gknot gave me was 734 kb/sec, I used 750.
dragoman
Selur
21st April 2002, 07:34
cool,.. I personally go for two 2CD Rips and calculate with 695MB per CD so that my normal filesize I get per CD is 690-703 MB ;)
Cu Selur
dragoman
21st April 2002, 16:08
Hi,
Just an update....did the Shining last night while I was at work.
It's 2hr, 24 min and I decided to do it as a 1cd rip. The audio isn't that great (it's 1ch ac3 for some odd reason) so encoding to mp3 doesn't hurt it a bit.
The audio came out to 81 MB, with the credits at right around 1MB.
Total, muxed, the movie is 701 MB.
Bitrate I used was 600 kps, with q-pel, gmc, and b-frames enabled. ALso, I used Strong Psychovisual setting, with light post-processing.
The quality is surprisingly good. I encoded at 576x240 (little smaller than usual).
I was surprised....I guess DivX 5.01 Pro does work pretty well at low bitrates....I am satisfied with it in this case.
dragoman
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.