How to do a reliable comptest for DivX Pro 5.0??

[JimmyBarnes]

Similar to the one that NanDub does for DivX 3 or 4 using SelectRangeEvery (260,13)

GKnot using the DivX4 calculator gets filesize/bitrate very precisely (within 1 %) but how to get to a suitable resolution for good quality video, quickly?

Jonny made a valiant effort but his CompTest gives high results (on the 3 movies I've done so far, 5-14 % high - I did a 1-pass 100 % quality run on each movie to find the actual 1st Pass %)

JB

[theReal]

I don't think the divx4 and divx5 comp. test ever were exactly the same as the divx 3.11 comp. test (which compares the size of the best possible quality to the size of the bitrate you chose).

However, as long as the values are consistent (and they seem to be), you can use the comp. test for divx5, only you need to get a little experience in what percentage results in what quality. I think 60% is excellent, 50% is good quality, down to 40% is still ok. Other people have reported that from 80% and up, divx5 (at least when using b-frames) seems to result in undersized files.

[theReal]

btw I just had an idea how to get the filesize of the 100% quality based encoding much quicker:

Encode the avs whith selectevery(260,13) using 100% quality-based encoding, and divide the resulting filesize by 0.05.

This should give you the filesize for a quant 2 encode as exactly as does the divx 3.11 comp. test.

Please correct me if I'm wrong, but it seems this method is even better than to use a first pass with quant 2 settings and change the divx.log afterwards.
You don't even need Gknot for it :)

[JimmyBarnes]

Originally posted by theReal
btw I just had an idea how to get the filesize of the 100% quality based encoding much quicker:

Encode the avs whith selectevery(260,13) using 100% quality-based encoding, and divide the resulting filesize by 0.05.

This should give you the filesize for a quant 2 encode as exactly as does the divx 3.11 comp. test.

Please correct me if I'm wrong, but it seems this method is even better than to use a first pass with quant 2 settings and change the divx.log afterwards.
You don't even need Gknot for it :)

Never had any success predicting filesize from a sample. Samples seem to be good only for predicting 1st Pass %.

Unless... does 1-pass 100 % not use delta frames? If it doesn't, then a 5 % sample might reliably predict the whole movie.

JB

[JimmyBarnes]

Originally posted by theReal
I don't think the divx4 and divx5 comp. test ever were exactly the same as the divx 3.11 comp. test (which compares the size of the best possible quality to the size of the bitrate you chose).

How do you do a comptest for DivX4?

The only comptest I know about is the one for DivX3.11a, using NanDub and GKnot.

thanx
JB

[tripnotik]

@theReal

Your idea would probably give a prediction that is oversized. You see, because you use SelectRangeEvery the encoder will detect a scene change every 13 frames and will probably put a keyframe there. Since keyframes are much bigger than delta frames and that there is an anormaly high amount of them, your result would be a bit too high. But it would be possible to correct it by finding what is the average interval between keyframes in a real movie, and the size difference between a keyframe and a delta frame so we could find a scaling factor that would give an appropriate result.

[theReal]

But, you do have this keyframe problem in all the other comp. tests (for divx3.11 and divx4) as well - does Gknot compensate for this somehow? Or is it just negligible?

How do you do a comptest for DivX4?In Gknot, you can make a comp. test with Divx 4 - it's almost the same as the comp. test with divx5, only it is totally automated by Gknot.
It's also using selectevery(260,13) and takes the 1st pass log from a quant 2 first pass.

[JimmyBarnes]

Originally posted by tripnotik
@theReal
Your idea would probably give a prediction that is oversized. You see, because you use SelectRangeEvery the encoder will detect a scene change every 13 frames and will probably put a keyframe there. Since keyframes are much bigger than delta frames and that there is an anormaly high amount of them, your result would be a bit too high.


Yes, I did a SRE(260,13) run on Proof of Life (TV scale) which yielded 1686 MB as the extrapolated 1-pass 100 % quality size
whereas the true value should have been 1465 MB.


But it would be possible to correct it by finding what is the average interval between keyframes in a real movie, and the size difference between a keyframe and a delta frame so we could find a scaling factor that would give an appropriate result.

Interesting if this could be worked out.

For the moment I am content to do 3-pass ripping, 1-pass 100 % quality then 2-pass, 1st and 2nd pass so I get a true 1st Pass % result.

JB

[JimmyBarnes]

Originally posted by JimmyBarnes
Similar to the one that NanDub does for DivX 3 or 4 using SelectRangeEvery (260,13)

GKnot using the DivX4 calculator gets filesize/bitrate very precisely (within 1 %) but how to get to a suitable resolution for good quality video, quickly?


I may have found my own answer. For 2 movies, the NanDub SRE(260,13)/GKnot comptest (DivX3.11a) gave a result similar to but slightly higher than the actual 1st Pass % using DivX Pro 5.0.


Movie Scale 1st Pass % NanDub 1st pass %
(true) (SRE 260,13 estimate)
================================================
POL TV 41.2 41.7
TRD PC 37.9 40.3
TRD TV 46.4 48.3


In practice, the above suggests to use a slightly smaller resolution than the one indicated by the NanDub test.

Limited data I know, but worth checking this trend on further rips.

JB

[theReal]

I think I will just use the Gknot comp. test for Divx 5 because I don't think I need exact values.

What difference does it make if I know that the 50% means the first pass size was exactly 200% in size of what I'm aiming for. All I'm looking for is a hint about if the resolution and settings I chose will result in a good divx. If the number is 52.4% or 55.6%, I will keep this resolution anyways, so a few % +/- doesn't make a real difference for me.

[Mac Sidewinder]

@theReal

If the number is 52.4% or 55.6%, I will keep this resolution anyways, so a few % +/- doesn't make a real difference for me.

How low in percentage have you found that you can go and still get a good encode (no blocks, etc)? Do you make your final decision based on this percentage or on the final bit/pixel rating? I ran into an interesting situation last night, here is the basic info:

Divx 5.01
1 cd encode (700mb)
length: 118 mins
audio: 128 mp3
bitrate: 725
ph/visuals: light
gmc checked
b-frame checked

When I ran the first comptest @ around 480x res it came back with 128% with .275 bit/pixel. That kind of amazed me since the movie was so long (even though it is a pretty dark movie which will compress better) What I finally ended up with (I ran another comptest with this res) was a res of 704x with a 71% BUT the bit/pixel dropped to .165 and the indicator turned yellow.

I ran the encode overnight and I haven't had time to check it out extensively but just skipping through it this morning it looked great.

I guess my final question (to anybody) is this:

1. How low of a percentage have you been able to go for a good encode.
2. How low has that made the bit/pixel rating?
3. Which do you go by, the percentage or bit/pixel?

I will let you know how the final encode looks.

Mac

[theReal]

I only look for the percentage, it has always given me good results so far and it seems this is your experience with this movie, too: even the bits/pixel seems too low, the movie looks great, you say.

btw. have you turned on all the features (gmc, b-frames, psy) for the comp. test as well?

This is what I've been doing up to now: when I use b-frames for the encode, I also use b-frames for the comp.test (this is important when comparing % values, because these are higher with b-frames on during compress test).

I have done only one DVD but several different avi's with Divx5 - the DVD had 59% and it looks great. I think I wouldn't go below 50% for a DVD, but for some TV-captures 40% might still be acceptable. I try to reach 50% and above, though.

[JimmyBarnes]

Originally posted by Mac Sidewinder
I guess my final question (to anybody) is this:

1. How low of a percentage have you been able to go for a good encode.
2. How low has that made the bit/pixel rating?
3. Which do you go by, the percentage or bit/pixel?

I will let you know how the final encode looks.

Mac

Re Q1. So far as low as 40 %. The figures in my previous post in this thread all gave good video. I have done 35+ DivX3.11a rips and a few DivX5.0 rips. Note that I watch DivX rips mainly on 68 cm TV rather than PC so I am less experienced at judging PC monitor quality (but still I believe, fairly experienced - bottom line: I can compare with the way the original DVD looks on the PC)

Re Q2. BPP for the DivX5.0 rips varied from 0.16 to 0.32, however I don't take much notice of the BPP figure. See The Wef's Gordian Knot help PLEASE READ THIS ALSO section for an excellent explanation of why not.

Re Q3. I go on the percentage figure (1st Pass %). It's the one factor that one can look at between movies to get a common indication of quality.

With DivX3.11a, I would usually aim for 65+ % 1st Pass %, though on a couple occasions I tolerated in the high 50 % (I hate doing 2 CD rips unless the movie is exceptional). I don't have a lot of experience of seeing DivX3.11a rips at 50 % or lower, but the one or two I have seen show easily discernible degradation of quality from the norm. With the few DivX5.0 rips I have done OTOH, even at 40 % or even lower levels, video quality has looked good (on TV or PC).

Still evaluating DivX5.0 but so far very impressed. It allows longer movies to fit on 1 CD with good quality (or higher res where the movies fits easily on 1 CD anyway), which showing less "blockyness" on plain large areas (not macroblocks) than DivX3.11a.

JB

[JimmyBarnes]

Originally posted by theReal
But, you do have this keyframe problem in all the other comp. tests (for divx3.11 and divx4) as well - does Gknot compensate for this somehow? Or is it just negligible?

As I mentioned before, when I try to extrapolate the SRE(260,13) AVI size to 100 %, the size is too big, even for the NanDub/DivX3.11a/Gknot comptest. However the 1st Pass % resulting from this is almost always very close to that which results from the full movie 1st pass Stats run. Never really looked into why the apparent disparity.


In Gknot, you can make a comp. test with Divx 4 - it's almost the same as the comp. test with divx5, only it is totally automated by Gknot.
It's also using selectevery(260,13) and takes the 1st pass log from a quant 2 first pass.

Do you mean 1-pass, 100 % quality, or 2-pass, 1st pass?

JB