DivX 5.1.1: what's wrong this time?

[girotour]

Hi all,
I just tried to perform a compressibility test with the brand new version of DivX codec.
It seems to be faster then 5.0.5 version but it also seems that the compression level is really bad!
E.g.: for a certain movie I have the following compressibility test ratios:

5.0.5 -> 0.458
5.1.1 -> 0.611 ( +36% :-( )

Is it normal or I'm doing something wrong?

10x

[SeeMoreDigital]

Personally I can't see what all the fuss is about, wanting or even needing to perform a compressibility test!

Given that most movies have a duration of 120min or less. I would recommend getting out your calculator to work out the audio and video bitrates manually. And aim for the following: -

For OK quality (better than VHS) aim for 700MB (1No CD rip)
For EXCELLENT quality aim for 1400MB (2No CD rip)
For NEAR DVD quality aim for 2100MB (3No CD rip)

At the end of the day, the deciding factor is how you intend to keep/store your encodes - for all time. On your PC's hard drive, CD-R(s) or DVD R!

If it's your intension to save your encodes to CD-R, it really is a waste of CD-R space if you don't aim to use it all!

Cheers

[len0x]

Originally posted by SeeMoreDigital
Personally I can't see what all the fuss is about, wanting or even needing to perform a compressibility test!


this is soo wrong :)
hundreds of hours of many ppl's work are spent investigating comp tests, just so that other ppl can say it's not needed ? :(

OK, seriously now. I can understand general guidelines ragarding number of CDs, but you cannot choose resolution without having performed comp test. I know lots and lots of less than two hours movies which look horrible in resolution above 512x384 even on three CDs!

@girotour

which option of divx 5.1.1 did you use?
In my test turning PSY on immediately drops about 25% of comp test and doesn't look as sharp as XviD (rather more noisy), so if I were you i'd turn that option off...

[SeeMoreDigital]

Originally posted by len0x
OK, seriously now. I can understand general guidelines regarding number of CDs, but you cannot choose resolution without having performed comp test. I know lots and lots of less than two hours movies which look horrible in resolution above 512x384 even on three CDs! I realise what I said would be quite shocking to many people!

But quality, resolution, definition, detail etc, all comes down to individual tastes. So it's another one of those 'subjective' arguments.

Personally I like to generate 720x576 anamorphic encodes. Sometimes if I'm encoding from an 2.35:1 source, I might crop away the mattes and encode to an image pixel frame size of 720x432. And in doing so retain the sources original anamorphic horizontal pixel quantity and preserve the sources original vertical 'image' pixel quantity!

It would seem that many people would opt to encode a 2.35:1 source to 640x272 pixels (far less pixels than I use). Meaning each pixel can be afforded more bitrate. However this also means that each pixel has to be vertically stretched 59% before it matches the sources original pixel height (272x59% = 432). Sure, it might look good overall but definition must also be lost in the process!

EDIT: There must be many people, like me, who know in advance what image pixel frame size (resolution) they want to use. So for us, it all comes down to bitrate.

It's fair to say that the more pixels you want to encode with, will require more bitrate. But often, because you have more pixels on the screen, you can get away with it. I suppose much also depends on how you view your encodes too, ie either via a PC monitor or TV screen!

What I would really like to know more about is, just how far some codes pixels can be stretched before they crap out!

Cheers

[girotour]

@len0x

Hi, I almost use the same parameters with DivX 5.0.5 and DivX 5.1.1. For example, first pass parameters are:

5.0.5: -bvn1 780 -psy 1 -key 300 -log "c:\divx.log" -w -b -sc 50 -pq 5 -profile 3
5.1.1: -bvn1 768 -psy 1 -key 300 -log "c:\divx.log" -w -b -sc 50 -pq 5 -profile 3 -nf

As you can see nothing changes except for that "-ns" switch. Have you any idea about it?

10x

[girotour]

Ok, I understood. -nf option simply disables the feedback window.
So, now parameters are exactly the same, but compressibility test gives two very different results.
Why?

10x

[len0x]

Originally posted by girotour
Ok, I understood. -nf option simply disables the feedback window.
So, now parameters are exactly the same, but compressibility test gives two very different results.
Why?


That's easy :) (as I mentioned before)
Try removing -PSY 1 option and compare again.

PSY was changed dramatically in 5.1.x afaik. And I'm not really sure this is useful feature anymore. Consider this: PSY as it was intended is supposed to remove non-visible parts of the picture (basically sort of noise filter, but much smarter). But in fact with 5.1.x not only it doesn't smooth the picture anymore, but it introduces lots of grainy details. The amount of details seem to be more (not necessarily good looking though) that without PSY! So basically it does the reverse of what you normally expect it to do. If I were you I wouldn't use that option. If you want sharper picture then rather use XviD with mpeg matrix...

[SeeMoreDigital]

Originally posted by len0x
That's easy :) (as I mentioned before)
Try removing -PSY 1 option and compare again.

PSY was changed dramatically in 5.1.x afaik. And I'm not really sure this is useful feature anymore. Consider this: PSY as it was intended is supposed to remove non-visible parts of the picture (basically sort of noise filter, but much smarter). But in fact with 5.1.x not only it doesn't smooth the picture anymore, but it introduces lots of grainy details. The amount of details seem to be more (not necessarily good looking though) that without PSY! So basically it does the reverse of what you normally expect it to do. If I were you I wouldn't use that option. If you want sharper picture then rather use XviD with mpeg matrix... I very much agree with len0x here!

I'm not quite sure what DivX's long term goal is with PSY (GMC or BiDi for that matter) anymore!

As it would appear when these functions are used in an encode, the bi products seem to be that your PC uses both more system resource (than previous DivX codecs) and is more reliant on post-processing, to generate a watchable image - via software playback!

That said girotour, may I ask what your goals with your encode are.....
What movie are you trying to encode?
How many CD-R's (or MB's) are you wanting to back your movie up to?
What audio type/bitrate do you want to use?
Are you watching your encodes on a PC or TV (via hardware)?

I'm just interested!

Cheers

[manono]

If you want sharper picture then rather use XviD with mpeg matrix...

Hey, hey, hey, this is the DivX Forum. :) Matrix changes aren't an option with DivX 5.x.x. I'd suggest using Lanczos Resize if you're not doing so, if you want to keep the picture as sharp as possible when using DivX.

[len0x]

Originally posted by manono
Hey, hey, hey, this is the DivX Forum. :) Matrix changes aren't an option with DivX 5.x.x.

Although wouldn't it be nice if it was ? :)

[jarthel]

/me wonders if he can say "xvid rocks!!!"....

/me is experimenting with latest divx5... :)

[len0x]

Originally posted by jarthel
/me wonders if he can say "xvid rocks!!!"....


Actually, personally I use DivX (just switched from 5.0.5 to 5.1.1), coz I prefer slightly smoothed picture to a grainy one.
But PSY option is not really usable anymore. So if you like results with divx5.1 PSY then you very probably will like results of XviD much better (that was my point).

[temporance]

Originally posted by len0x
PSY was changed dramatically in 5.1.x afaik. And I'm not really sure this is useful feature anymore. Consider this: PSY as it was intended is supposed to remove non-visible parts of the picture (basically sort of noise filter, but much smarter). But in fact with 5.1.x not only it doesn't smooth the picture anymore, but it introduces lots of grainy details. The amount of details seem to be more (not necessarily good looking though) that without PSY! So basically it does the reverse of what you normally expect it to do. If I were you I wouldn't use that option. If you want sharper picture then rather use XviD with mpeg matrix... 5.1.x PSY has a lot of potential, but it is very sensitive to noise. So you either need to use a prefilter (e.g. the built-in divx preprocessing at "light" or "normal"), or you need to tweak the PV using the feedback interface. Slide PV flat down to 0 and the extra grainy details will go away. Not an ideal way of doing things, but I have done this for several encodes with a lot of film grain.

[len0x]

Originally posted by temporance
5.1.x PSY has a lot of potential, but it is very sensitive to noise.

I totally disagree that it has potential. The whole point of PSY is to _remove_ details, not introduce new ones. Noise is main problem in real world encodings, so it's beyond my understanding how developers neglected the fact that they have to handle noisy sources properly. Indeed you can find some workarounds, but this only means that this feature is kinda broken. That's all...

[temporance]

> The whole point of PSY is to _remove_ details, not introduce new ones.

Not quite right. Even without PSY, any lossy codec will remove details, we're stuck with that fact. But without PSY a codec removes details in a dumb, indiscriminate way.

The point of PSY is to enable the codec to remove less of the details that we can see and more of the details that we can't see.

DivX PSY handles noise/grain just like any other fine details - it removes it where you can't see it and tries to preserve it where you can. It's not the codec's job to remove noise from the image - if you don't like noise/grain, use a preprocessor (and of course this can help encoding).

Edit: If you haven't already, try pausing an encode using the DivX Feedback Window and then adjust the PSY parameters (pv...). This gives you some idea of the actual changes it is making to picture and bitrate.

[len0x]

what you said in the beginning is true but this:

Originally posted by temporance
DivX PSY handles noise/grain just like any other fine details - it removes it where you can't see it and tries to preserve it where you can. It's not the codec's job to remove noise from the image - if you don't like noise/grain, use a preprocessor (and of course this can help encoding).


is not quite. If it was like you said then even without PSY grainy pictire would look grainy with DivX. But, no it looks really clean comparing even to the source (no preprocessing, no psy used). But with PSY I *think* (but hope it's not really true) codec is given hints, that it should not smooth the picture unless told to do so by PSY... So basically as you said if PSY finds that noise is visible and should be preserved then codec will try its best to preserve the details and obviosly fails on noisy sources. Without PSY it seems to have its own method for preprocessing source which works quite nice for me I have to say (that is why i never use preprocessing or PSY internally).

[temporance]

[QUOTE]Originally posted by len0x
If it was like you said then even without PSY grainy pictire would look grainy with DivX. But, no it looks really clean comparing even to the source (no preprocessing, no psy used).

A codec without PSY will not be able to encode film grain at higher quantizers. That is why DivX with no PSY sometimes produces a cleaner image that the original (which is not a good thing - it has lost visible details).

With PSY, the codec can try harder to encode visible details (including film grain) by stealing some bits from details that you can't see.

Like I said, unless PSY is introducing more artifacts, then it is not doing a bad thing. If you want a clean, smooth image use a prefilter [or RV9 ;) ].

Can you describe more what you don't like about PSY? Blocking? Ringing? Smoothing? Noise? Instability?

[len0x]

Originally posted by temporance

Like I said, unless PSY is introducing more artifacts, then it is not doing a bad thing.

It really does introduce more artifacts (well it's still codec that does that but with more help of PSY than without)! That's the whole point of this dicussion. I wanna see this behaviour from PSY turned on: the same or increase of comresibility. Consider this: you have two square blocks to encode, without PSY each of them is compressed into say 10 bytes (but needed say 15 at quant 2) . now with PSY it's being detected that first block can be compressed into 6 bytes without significant loss of quality. Excellent, we have 4 bytes to spare. Now what you expect from codec to do is to put those 4 bytes into second block without changing parameters of compression (apart from quantizer probably) and therefore expected size will be reached. But nooo, this time codec goes into second block and suddenly decides that it needs 20 bytes to compress it, so even 14 bytes that we have on it now will not be enough. Now the question is how this is possible? There are two options:

- PSY introduces more artifacts
- PSY hints codec to use different encoding parameters which are far from optimal when using on a noisy source.

Both options look equally bad to me...

[girotour]

Ok, I just tried disabling PSY, but I obtained almost the same result. So, now the ratios are:

5.0.5 with PSY -> 0.458
5.1.1 with PSY -> 0.611
5.1.1 without PSY -> 0.615

BTW: these are the parameters I'm using to perform compressibility test:

-b1q 2.0 -psy 0 -key 300 -b -sc 50 -pq 5 -profile 0 -nf (-psy 0 = Disable psychovisual enhancement).

[len0x]

Originally posted by girotour

5.0.5 with PSY -> 0.458
5.1.1 with PSY -> 0.611
5.1.1 without PSY -> 0.615


Oh, actually it's the first time I've noticed that compressibility went up (I would expect it go down for 5.1.1). And on all samples I tried I got significant decrease with PSY mode on.

How do you perform comp test and what is the source ?

[SeeMoreDigital]

Originally posted by len0x
... Consider this: you have two square blocks to encode, without PSY each of them is compressed into say 10 bytes (but needed say 15 at quant 2) . now with PSY it's being detected that first block can be compressed into 6 bytes without significant loss of quality. Excellent, we have 4 bytes to spare. Now what you expect from codec to do is to put those 4 bytes into second block without changing parameters of compression (apart from quantizer probably) and therefore expected size will be reached. But nooo, this time codec goes into second block and suddenly decides that it needs 20 bytes to compress it, so even 14 bytes that we have on it now will not be enough. Now the question is how this is possible? There are two options:

- PSY introduces more artifacts
- PSY hints codec to use different encoding parameters which are far from optimal when using on a noisy source.

Both options look equally bad to me... So with this fact in mind. When PSY is used, it's likely to suggest that when less pixels are used to generate an encode, the worse looking the encode could look!

Personally, the only time I've seen PSY work for the better was when I kept the image pixel frame size the same as the sources. Or increased the quantity of horizontal pixels. However the differences were so small, in my opinion, it was not worth using! But again everything is so dependant on the bitrate anyway!

Cheers

[len0x]

Originally posted by SeeMoreDigital
So with this fact in mind. When PSY is used, it's likely to suggest that when less pixels are used to generate an encode, the worse looking the encode could look!


doh, I lost you here :)
If you meant that the less bits are used the better encode will look in some cases with divx5.1.1 (very subjective here - i prefer smooth picture to sharp one if the latter has other artifacts introduced) then yes, sounds weird but true when it comes to PSY. And only because of internal influence PSY has on other parts of the codec (but I guess we'll never know how it works there...).

Of course this all happens with the same bitrate. If you keep compressibility at equal levels (and hence increase bitrate for PSY mode) they both should look pretty decent. I have to test that though.
(but that's different goal - I'd rather increase resolution or switch Bframes off than turn PSY on if I have some spare bitrate).

[midi]

Aren't comp tests simply partial encodes done at the lowest quant allowable? So the new version of divx produces a bigger file when you tell it to compress as little as possible. Isn't that a good thing? Doesn't that mean that the maximum detail you can achieve is likely higher? If you want less detail you would use a higher quant (just as the codec will in variable mode).

Comp tests are meant to compare two different movies to see how they compress compared to each other (or some average number you keep in your mind) and if you should give more bitrate to certain ones. Using comp tests to compare different versions of a codec seems stupid to me. The only people who actually encode at quant 2 (are there any?) will be happy with more file and more detail and people who did previously and find larger files a problem will up the compression/lower the quality setting a little to adjust for the change and will most likely get the same video quality (or better) that they always did.

[SeeMoreDigital]

Originally posted by len0x
doh, I lost you here :)
If you meant that the less bits are used the better encode will look in some cases with divx5.1.1 (very subjective here - i prefer smooth picture to sharp one if the latter has other artifacts introduced) then yes, sounds weird but true when it comes to PSY. And only because of internal influence PSY has on other parts of the codec (but I guess we'll never know how it works there...). Yes, that's what I meant, when encoding with PSY.

Because I've also noticed that when you generate another encode (from the same source) at the same bitrate but at a higher resolution (image pixel frame size) with PSY the encode can often look better. This is probably down to what you mentioned before regarding left over bytes being carried (or not, as the case may be) over to it's neighbouring block!

I first noticed strange things happening when I began generating low bitrate PAL DivX encodes using an 'true 16:9' image pixel frame size of 1024x576 pixels, instead of an 'anamorphic' image pixel frame size of 720x576 pixels. As the 'true 16:9' looked much better during fast motion scenes! However, as I was only able to view 1024x576 encodes on my PC instead of my Xcard. I abandoned the idea!

But having said that, I am able to compare NTSC 'true 16:9' 848/864x480 encodes with 'anamorphic' 720x480 encodes on my Xcard, as the quantity of encoded pixels does not exceed 414,720!

Originally posted by len0x
..(but that's different goal - I'd rather increase resolution or switch Bframes off than turn PSY on if I have some spare bitrate). Well I certainly agree with you here.

But going back a bit. There must be a limit as to, how low you can go with an resolution (image pixel frame size) before it starts to look awful when viewed, on either a PC monitor, cathode TV, or plasma TV!

To clarify, I generated some DivX encodes at work (from the same 2.35:1 source) using the same bitrate. The first was at 640x272, the second was at 720x304, the third was at 720x432. Each was viewed, via Xcard on a 19" 4:3 monitor and on a 42" plasma.

The results were that the first encode looked better on the PC monitor than on the plasma. But the third encode looked better on the plasma than on the PC monitor.....

....Answers on a postcard please!

Cheers

[dTb]

I've skipped the whole discussion on the pve although I'll comment on it afterwards.

Now as to compressibility tests it really disappoints me that recently I've been seeing people bad mouth it. Imo it is the most powerful tool we have available to us when encoding video but it's purpose is very specific and thus so should it's use be.
Using the compressibility test to compare codecs is fairly pointless and often people come to the wrong conclusions from the results.
Keep compress tests simple, me I use q2, bframes and standard p/q and that's it, I never deviate from this because the idea is to make the results as standard as possible. If you use pve for one test and not another it makes it very difficult to compare and also due to the nature of pve it tends to reduce the compress test result to the surprise of many people. The reason this is is because it will increase the filesize of a q2 encode, due to the way the compress test is calculated this results in a lower result but does not mean the video has lower compressibility.
When you have standardised the compress test results you can then find a quality range that you feel happy with. Say you decide a 60% cut off is what suits you, you can then adjust many things like resolution, temporal/spatial smoothing etc. to reach that cut off within your desired filesize.

As for pve I personally find it useful, if say I want to squeeze a movie onto one disk but to do so results in a low compress test result of 50% and I'd rather not resize lower or smooth any more I will use fast pve. I find it helps improve the overall quality at low ranges like this, once I hit about %60 then I don't use it.

[temporance]

Personally I think the compressibility test is a good idea but not many people actually understand how it works. It turns out that a compressibility value is an approximate way of talking about average quantizer that will be used to encode the movie.

Typically we might get (using a size=Q^-0.5 approximation)

Compressibility Ave Q
100% 2
82% 3
71% 4
63% 5
58% 6
53% 7
50% 8
47% 9
45% 10
So when someone talks about a compressibility of 63%, he is actually saying that his encode will likely be made using a frame quantizer around Q=5. With a plain boring old MPEG-4 codec, Q=5 gives a known quality - a reasonable looking picture.

When PSY is taken into account, old assumptions about how good an encode at cetain quantizer/compressibility go out the window. It might be that a PSY encode at Q=6 looks as good as a non-PSY encode at Q=5.

For now, if you want to do comp tests, do them as you've always done them to make things consistent. When you do your encode for real, you can turn on whatever options you think will help quality, including PSY!

[len0x]

Originally posted by temporance

Compressibility Ave Q
100% 2
82% 3
71% 4
63% 5
58% 6
53% 7
50% 8
47% 9
45% 10



It seems that ppl still don't understand how translate quant into quality though :)

This is the formula:

Compressibility = 200/Average quant.


and hence quant 3 will give 66.6% of quality.

Originally posted by temporance

When PSY is taken into account, old assumptions about how good an encode at cetain quantizer/compressibility go out the window. It might be that a PSY encode at Q=6 looks as good as a non-PSY encode at Q=5.


This is not quite true. Having more details to resolve will always result in worse quality at a given bitrate. You may or may no see this on a particlar encode but in general it's true. It's only common sense that if codec requires more bits for a particular part of the picture then it has to make hard choices on how deal with that (most of the time it's blockiness or heavy artifacts for all mpeg4 based codecs).

[temporance]

Originally posted by len0x
It seems that ppl still don't understand how translate quant into quality though :)OK, point taken, I admit to not being completely familiar with 'compressibility'. My point was that compressibility and average quantiser are imtimately related:

compressibilty = f(averageQuant)

and

averageQuant= f'(compressibilty)

Having more details to resolve will always result in worse quality at a given bitrate. You may or may no see this on a particlar encode but in general it's true. It's only common sense that if codec requires more bits for a particular part of the picture then it has to make hard choices on how deal with that (most of the time it's blockiness or heavy artifacts for all mpeg4 based codecs).Agreed, PSY does not just give details, it also takes away. Think of it as moving bits around your movie. It steals bits from places with high motion / complex texture / bright colors and gives them to places with low motion, flat or fine texture and dark colors. Kind of like Robin Hood. In doing so it affects the average quantizer that is needed to encode at a given bitrate - that's what's confusing people.

[jggimi]

I haven't been able to follow this discussion very closely, as it's a little too technical. But I did note that the "quality percentage" values changed with 5.1. Q1 can be selected (100%), and Q2 is now 98%. I have not bothered checking the rest of the "%" table.

[len0x]

Originally posted by jggimi
I haven't been able to follow this discussion very closely, as it's a little too technical. But I did note that the "quality percentage" values changed with 5.1. Q1 can be selected (100%), and Q2 is now 98%.

I'm actually not sure what they mean by Q1 - if you try to perform comptest with Q1 it will almost double final size (note that in GK for instance you can select Q1 for comp test - it'll be reset to Q2 anyway). So for me it's no compression at all.

P.S. I think I tried Q1 only in 5.1, not 5.1.1...

[DigitAl56K]

Guys, some of the comments here are sort of right, some aren't so on target :)

Take a look at pages 56-58 of the guide for a full explanation of how the new PV works.

Basic summary: PV will degrade the texture complexity in heavily textured areas where you are least likely to notice the difference so that areas with finer textures recieve more bits (assuming a fixed bitspend for the frame). This way fine details are enhanced. PV will also enhance flatter areas with fine textures so that the texture is enhanced and that area of the image recieves more bits (assuming a fixed bitspend for the frame).

So in short PV both degrades the texture where you won't notice it and enhances the texture where you will notice it, both effects bias the bitspend towards areas of the image where you will notice the enhancement.

Read the guide pages, its much clearer there (plus it shows you how to test for yourself).

Also, PV does affect compressability results because it changes the texture. For the same reason, PV also changes the PSNR result. In fact, PV shows up the discrepancy between PSNR score and perceptual quality. If you encode a source with PV on its highly likely the PSNR will fall, even though people percieve the quality to be better.

[len0x]

Originally posted by DigitAl56K

Basic summary: PV will degrade the texture complexity in heavily textured areas where you are least likely to notice the difference so that areas with finer textures recieve more bits (assuming a fixed bitspend for the frame). This way fine details are enhanced. PV will also enhance flatter areas with fine textures so that the texture is enhanced and that area of the image recieves more bits (assuming a fixed bitspend for the frame).


IMHO that's very wrong way to go. Fine texture usually compresses better than noisy one. So instead of increasing the quality of those noisy bits you desrease their quality and try to put their bits into those which looked fine already! Either that or mechanism of detecting what's visible to human eye is totally broken.
No wonder that shitty bits are looking ever more shite with PV :)

[DigitAl56K]

Originally posted by len0x
IMHO that's very wrong way to go. Fine texture usually compresses better than noisy one.

Fine texture is often lost during encoding as a result of quantization. Thus to preserve fine details (particularly at low bitrates where high quantization takes place) enhancement is required. For example: Details on skin and faces might need enhancement to prevent them looking over-smoothed.

Also, noise should be removed with a pre-processing filter before encoding.

So instead of increasing the quality of those noisy bits you desrease their quality and try to put their bits into those which looked fine already!

I think you are confusing "noise" with "strong texture". For example, imagine a person standing in front of a brick wall. The brick wall has well defined strong texture where the bricks meet the mortar. It might be desirable to minimally degrade the texture of the brickwork so that you could enhance the detail on the persons face. Its unlikely you would notice the brickwork had been altered, but you would probably notice that the persons face looked more detailed. This is just one example, of course.

Either that or mechanism of detecting what's visible to human eye is totally broken.
No wonder that shitty bits are looking ever more shite with PV :)

I think your problem is that you are passing very noisy sources to the encoder without pre-processing and the PV is then enhancing the noise assuming it to be fine texture. In fact, we already include advice in the guide (see the green "usage" box on page 59) that recommends you either use pre-processing to remove strong noise prior to applying PV, or that you don't use PV with noisy sources.

Hope that helps
-Al

[Ewi]

I don't want to disturb this interesting discussion, but cause DivX 5.1x is rather new I don't have much experience with it.

Before there was a certain way to do the comp test and we had the doom9 guide line and we had to decide if we like the lower bound (lets say 60%) or the upper bound (lets say 80%). Usally I went for the middle of the recommended values (so here around 70%).

Is there already enough experience here so that one can say:
Do your comp test exactly this way (for example with q2 and b-frames; everything else off) and if your value is between a and b it's gonna be fine.

A comment about what will most likely happen if you turn on feature c or feature d would be nice. It's just that I want to have a rough idea how good my actual movie can be compressed.

At the moment if I get 40% it doesn't means anything to me. I don't know what's the actual way to interpret it correctly. OK, Doom9 has just updated the divx guide but no comment of the new comp test values...

Thank you in advance...

[SeeMoreDigital]

Originally posted by len0x
IMHO that's very wrong way to go. Fine texture usually compresses better than noisy one. So instead of increasing the quality of those noisy bits you desrease their quality and try to put their bits into those which looked fine already! Either that or mechanism of detecting what's visible to human eye is totally broken.
No wonder that shitty bits are looking ever more shite with PV :) I agree with you again!

I don't know about other users but after I installed DivX 5.1.1, I noticed that all my early DivX encodes, which played fine before with WMP9 and MPC, suddenly became very choppy. And would only run correctly when using DivX's own player.... Why is that?

So on my 800MHz HTPC I've been forced to remove the DivX application altogether and register DivXdec.ax and run DivXconfig.exe, just so I can watch my encodes properly in software. It's a good job I don't use this PC for generating encodes too (well not on this boot anyway)!

I just can't get out of my head now, that the guys at DivX are designing/pushing their codec in a direction that will eventually result in it's encodes only being able to run/work effectively in conjunction with some form of post-processing - Hence the need for certification!

Call me paranoid if you like. But if post-processing becomes the norm. It could lead to a form of encryption!

Cheers

[DigitAl56K]

... thats the most bizarre post I've read in a long time! :)

If your videos are running choppy its probably because you are using auto-pp while other apps are running or that you aren't using auto-pp and the pp level is higher than your CPU can manage.

[dTb]

Originally posted by Ewi
Is there already enough experience here so that one can say:
Do your comp test exactly this way (for example with q2 and b-frames; everything else off) and if your value is between a and b it's gonna be fine.

I basically confirmed this in my previous post, whether that's enough for you or anyone else I can't say, the values though are really up to personal preference, for me atm around 50% is ok quality wise but needs fast pve, above %60 and the quality will be quite good. One thing is for sure, it's just as valuable with the new version as it was with the old ones.
I've found that with the new versions after 5.0.2 that you can get away with lower values, this is largely because the newer versions result in a bigger filesize at q2. The basic formula for a compress test is:

(actual size at a specified bitrate)/(predicted q2 filesize)*100

so you can see that a bigger predicted q2 filesize will result in a lower compress test result.
I don't recommend using q1 for the compress test.

[SeeMoreDigital]

Originally posted by DigitAl56K
... thats the most bizarre post I've read in a long time! :)

If your videos are running choppy its probably because you are using auto-pp while other apps are running or that you aren't using auto-pp and the pp level is higher than your CPU can manage. Nope! DivX 5.1.1 was installed on a clean boot drive, with no other apps running in the background.

I've tried full PP, partial PP, no PP and just about every setting in between... but the encodes were still choppy!

OK the PC is only an 800MHz P3, but I would have thought it should have coped alright!

Yep my post is bizarre. That's me...

Cheers

[DigitAl56K]

Regarding compressability, note that with a fixed quantizer enabling PV will tend to cause the encoder to consume more bits, which might mess up compressability results.

I'd turn PV off while running the compressability test then turn it back on afterwards.

[len0x]

Originally posted by DigitAl56K
Regarding compressability, note that with a fixed quantizer enabling PV will tend to cause the encoder to consume more bits, which might mess up compressability results.


Aha, we're getting to the root of the problem here.
The question is: why it causes the encoder to consume more bits?

Originally posted by DigitAl56K
I'd turn PV off while running the compressability test then turn it back on afterwards.

Does this mean that compressibility stays he same with or without PV during actual multipass encode?

[dTb]

Originally posted by len0x
Does this mean that compressibility stays he same with or without PV during actual multipass encode?

In theory pve will make a video more compressible in that you could use a lower bitrate to maintain the same perceptual quality when it's used.
Relating this to a compress test is where things get murky and I'm not sure there's a point in doing so.