DivX Pro 5.1.1 Beta 2 is now available

[Gej]

BIG UPDATE Nov 05: DivX Pro 5.1.1 Beta 2 is now available


Hello folks,

This is the second and (hopefully) last Beta for DivX Pro 5.1.1. In this version you’ll find again some speed optimization and some bugs fixes.
Please enjoy…

http://labs.divx.com/archives/000021.html

What's new in DivX pro 5.1.1 Beta 2
-----------------------------------

Encoder fixes:
- Slow mode 5-10% faster than 5.1.1 Beta 1
- Slowest mode 5-10% faster than 5.1.1 Beta 1
- Issues with Psychovisual and DirectShow Encoder
- Resize issues with DirectShow Encoder
- Fix issues with capture applications

Decoder fixes:
- Issue with n B frames and Deblocking fixed

Changes:
- Psychovisual Disabled by default
- Feedback mode Disabled by default

NOTE: How we measure speed of the Codec ?
We want to measure the speed of the encoding, not of the Encoding application , of a MPEG2 decoder or some preprocessing tools. So we create some tests files that are already pre processed and resized and that are encoded using HuffYUV (and predict left option) and we use theses to actually measure the Codec speed using VirtualDub. This reduces the influence of the actual reading of the source file. People with SMP system or HyperThreading CPU can also create a simple AVS script that will just load and color converts the HuffYUV file before sending it to the codec, allowing the AVS script to run on a separate CPU/Thread than the codec itself.

If you already own DivX Pro, a DivX Beta release will install over your existing DivX Pro version unless you install it to a different directory. (You may want to keep a copy of your officially released DivX Pro codec in case Beta Prototype releases on a 15-day trial, making it easy for everyone to help improve the codec. If we push out yet another beta release after your 15 day trial is up , we will create an additional 15-day trial so you can continue using the prototype version.

The DivX Pro codec released on DivX Labs should be relatively stable. Remember, however, that these releases have a Beta or prototype release status so, uh….you could possibly run into a few bugs from time to time.

[SeeMoreDigital]

I did a quick test and it seems to be slower in 'standard' mode!

[Gej]

What !? Slower !?

What settings, what source ?

Tested on a P4 2.8Ghz (HuffYUV source 640x304x24fps 7973frames)

5.05 B (Slowest) 179s
5.05 noB (Slowest) 155s

5.1 B (Standard) 238s
5.1 noB (Standard) 197s

5.1.1 B (Standard) 160s
5.1.1 noB (Standard) 137s

5.1 B (Slowest) 1896s
5.1 noB (Slowest) 1430s

5.1.1 B (Slowest) 1259s
5.1.1 noB (Slowest) 937s

[Angelus]

I just had a question about Divx 5.1.1 When I do a normal 2 pass encode, usually I do standard for the first pass and write log & mv files and slow for the 2nd pass and read mv file. However in this new version 5.1.1 I can't select to read the MV file when i set speed to slow, its greyed out. When I put it to standard i can check it but I'm pretty sure that I've use standard then slow on a 2 pass encode and always been able to read to mv file. Any comments?

P.S. The encoding is a lot faster too, I just did a sample and it was about 4-5 fps faster than 5.1

Thanks

[Gej]

actually, extented tests show that selecting different performance mode for 1st pass and 2nd pass together with MV on DO NOT increase final quality (it can even lead to some artefacts). So the GUI has been updated in order to prevent this to happend

[SeeMoreDigital]

Hi Gej, nice to see you 'burning the midnight oil'!


I noticed in your first post, you said:-

Encoder fixes:
- “Fast” Psychovisual mode is 80% faster than in 5.1
- DivX 5.1.1 encoder is 50% faster than 5.1 (12% faster than 5.05)
- Slow mode 50% faster than 5.1
- Slowest mode 50% faster than 5.1
- Fastest mode 20% faster than 5.1
- The Quality produced by "Fastest" has been significantly improved

But there was no mention about 'standard mode' speed increases!

I'll do some more tests tomorrow and let you know my results.

Cheers Gej

[Gej]

I guess it's my mistake

You should read :

DivX 5.1.1 encoder is 50% faster than 5.1 (12% faster than 5.05)
- Slowest mode 50% faster than 5.1
- Slow mode 50% faster than 5.1
- Standard mode 50% faster than 5.1
- Fastest mode 20% faster than 5.1

(BTW, it's 3h30pm in california and there is a bright sun outside...)

[DigitAl56K]

My advice is to avoid the MV file entirely, unless you have a really slow PC and you're on a tight timescale.

As far as I know it was invalid to use Standard +mv followed by Slow/Slowest +mv in any case, though the 5.1 GUI didn't offer much guidance to inform you of this.

The 5.1.1 Beta 1 GUI is much improved with respect to helping you avoid major encoding no-no's, so its now harder to produce a bad encoding (though I'm sure somebody somewhere will still manage it...) ;)

[Morbo]

Great more tests.......:D

Just what I needed since cold weather has hit...

Cheers!

[jggimi]

I am making this thread "sticky."

Would all 5.1.1 Beta testers please use this thread for bug reporting, to make it easier for Gej and his team to find and track them.

Thank you.

[Gej]

thanks jggimi

The whole DARC team and myself thanks you and the users of this board for your help, I hope you'll appreciate the speed improvements, and there is more to come for the new and upcoming CPUs from both giants, plus we keep working on quality improvements as well as on some interesting new features. hehe

cya

[DigitAl56K]

Performance tips:

You can still run 1st pass Standard, nth pass Slow/Slowest for reduced encoding times. The average PSNR drop by doing this across a number of clips tends towards 0db, and should be less than 0.3db except in extraordinary circumstances.




Everyone who previously disabled the Feedback window should now try re-enabling it and using the box at the top select to update an update interval of every 100 frames.

By doing this you can still see what the encoder is doing (particularly useful if you are using VDub with Fast Recompress, or some AVISynth method), but it imposes virtually no performance hit.

There are a couple of issues:
* The settings at the top of the feedback window are not yet persistent between passes, but hopefully this will be corrected by Beta 2.

* The Graph window doesn't respect the update interval in Beta 1 and still imposes a small performance hit. Hopefully this will be corrected by Beta 2 also.




Because the MV file is now disabled for Slow/Slowest modes you should see some interesting PSNR results when DivX 5.1.1 is tested against codecs like WM9. Remember when doing any PSNR testing to make sure Psycho-visual enhancement is disabled, and that the decoder post-processing is forced-full (i.e. not on an auto-pp mode).

[PHA]

Using the MV file in the nth-Pass(in standard mode) does not change the encoding speed, it seems that the MV-file reading function does not work in DivX 5.1.1 . The nth-Pass is a little bit slower as the first pass (maybe 5%).
There is also no difference in the encoding speed if I use Psychovisual Enhancement (slow\fast), or if i disable this option (maybe PsyVis does not work anymore ?). But the encoding time with the standard settings is a lot faster then DivX 5.1 ,it is also faster then DivX 5.0x.
Does anymone recognize a difference in quality using DivX 5.1.1 (better? worster? the same?).

[colordog]

I just tried a compression test between DivX 5.1 and 5.1.1 Beta using the latest GKnot -

I choose an interlaced source, so there'd be more overhead. Test conditions: Interlaced source, TomsMoComp, "Slower" setting, PyschoVis set to "Fast". MV is disabled, because, well, it's not an option for Slower/Slowest settings anymore.

DivX 5.1
Encode time: 1178 seconds
FPS: 6.676

DivX 5.1.1 beta
Encode time: 782 seconds
FPS: 10.061

Effective speed increase seen under these exact conditions: 50.7%

So, much to my surprise, the 50% seems to be real, even when applying PV and deinterlacing. Not horrible!

------

Could someone explain why the MV is disabled for Slower/Slowest? I'm not understanding that yet. How does that affect the encoding strategy where people would do the 1st pass in "Standard" and the 2nd pass in "Slower" - is that better or worse to do now?

[Lord_KiRon]

Well I could do 5.1 50% faster too - just by disabling output window :)

[colordog]

I guess you're being sarcastic?

Disabling the output window only increased my throughput by 1.7%.

And now that you can set how often the image is updated in 5.1.1, it's kinda moot, I think (excepting perhaps not being able to disable the graph, but I'd guess more overhead went to the image).

[DigitAl56K]

Originally posted by colordog
Could someone explain why the MV is disabled for Slower/Slowest? I'm not understanding that yet. How does that affect the encoding strategy where people would do the 1st pass in "Standard" and the 2nd pass in "Slower" - is that better or worse to do now?

As the rate control strategy is refined between passes bits become allocated differently throughout the file. This causes the encoded picture to change slighlty (for example different quantizers might be used) and the motion vectors can therefore vary very slightly as a result.

Under Standard mode the PSNR drop seen from use of the MV file is fairly insignificant. Under Slow and Slowest modes quite a substantial reduction in the potential PSNR is observed, thus the MV file is no longer valid in these modes to ensure quality. Much testing went into this in the run up to 5.1.1 Beta 1.

My advice is that unless you have a really good reason to use the MV file (e.g. your CPU is an K6-2 450) its best to leave it off. With 5.1.1 Beta 1 running so much faster than 5.1 (and even faster thatn 5.0.5) there is not a good reason to use it.

[dTb]

Just done a quick test to see what sort of speed increase I'll get with my typical encoding methods and figure I may as well post it here.

I used Enc with a 5 min long avs script on an AthlonXP 2100+ (oc'd to 2700+). Numbers won't be totally accurate because I was web browsing most of the time.

B-frames and fast pve used on all passes, home theatre profile.
1st pass, standard p/q, write mv
2nd pass, standard p/q, read mv
3rd pass, slowest p/q, no read mv.

5.1

1st pass - 8mins 14 seconds 15.1fps
2nd pass - 7:25 16.9fps
3rd pass - 59:09 2.1fps
Total - 1:14:48 1.7fps

5.1.1 Beta

1st pass - 5:30 22.7fps
2nd pass - 6:02 20.7fps
3rd pass - 42:47 2.9fps
Total - 54:19 2.3fps

That's a substantial improvement and very welcome.
It's a little strange that the 2nd pass of 5.1.1 was slower than the first, will have to look into that when encoding the whole movie. Maybe with the settings I'm using I'm better off without mv.

[scrat]

hey!

I've done a liitle test on an AMD Athlon XP2000+ with the following settings:

- VirtualDub Mod (Fast Recompress) and disapled feedback window).
- 1-pass
- 1587 kbps
- slowest
- treshold: 50%
- encode as progressive
- keyframe interval: 250 frames

With DivX 5.1.1 I can't see that this codec is faster as any other, just as slow as DiVX 5.1 and a lot slower as DivX 5.05 - or would you say that 2-4fps is fast????

The input video was a avs-skript with FieldDeinterlace and an Output resolution of 640x480.


greetings,
scrat

[DigitAl56K]

scrat: The equivelent of 5.05's Slowest mode is Standard mode in 5.1.1 Beta. The new Slowest mode is completely different. Also, the SCT and keyframe interval are not respected by 5.1.1 Slow/Slowest modes.

Gej: Perhaps we could ghost these options when Slow/Slowest pq modes are selected?

[Gej]

If you want to be faster than DivX 5.0.5 you HAVE to disable the feedback windows from the codec parameters button "settings" and uncheck Disable the feedback windows. NOT from the feedback windows itself

[Jaw3000]

I have a quick question about DivX 5.1.1 Beta 1: As a newbie to encoding, what are the best settings (P4 2.53)?

With 5.1, I've been using 3 passes with 1st pass slowest, nth pass standard, and last pass standard or slow. Although this is taking a long time (about 24 hours) to encode. I don't really care how long it takes if it's the best quality possible, but if I can get equal or better quality with faster speeds with other settings? I haven't had a chance to test 5.1.1 Beta yet.

So, what are the best settings to use? Is there any point in 3 passes, or are 2 passes just as good? I've also seen a lot of people use 1st pass standard and nth pas slow or slowest? How about Psychovisual mode, quantisizer, and themes (I want the best compatability for the future)? What's best?

BTW, a feature I would like to see (I don't think this can be done now) is the ability to pause and resume encoding - even through closing the encoder and system restarts. This is probably not a codec feature but one for VirtualDub and other encoders.

Thanks!

[Gej]

my best quality

2passes only
1st and 2nd pass slow (or slowest for the extermists)
Profile on
B frames on
psychovisual fast
no MV reuse

theses will give you the best CE compatibility BUT SLOW, so stick to standard performance/quality to have better speed

[FreakNGoat]

In the new 5.1.1, it prevents you from choosing slow, slowest or even fast mode when Qpel is turned on, thus forcing you to use standard mode. Anyone have any thoughts on this?

[JensG.]

Originally posted by DigitAl56K
Gej: Perhaps we could ghost these options when Slow/Slowest pq modes are selected? Yes, please! These unknown limitations lead to much confusion.

But anyway thank you for your work on the codec!

[SeeMoreDigital]

Hi Gej,

I wish to apologise for my.... I did a quick test and it seems to be slower in 'standard' mode..... statement!

I've carried out some more tests in 'standard' mode on my 2.8 P4 PC and it is a whole lot faster. When I looked back at my old notes for DivX 5.1.0, I read the info for the 2 pass test with MV enabled and not without MV enabled. And this is where my confusion lied... sorry!

I'm very pleased overall.

However, I have noticed that creating and using MV files (in standard mode) does not now make a dramatic difference to the next (nth) passes speed. Well not like DivX 5.1.0 anyway!

Given that the speed difference, when enabling MV, is so small now. And that it's not even accessable when using 'slow' and 'slowest' modes. Am I correct in assuming that this function might disappear altogether in the 'final' release?

I'm currently generating a PAL 2pass 'standard' mode test of StarTrek Nemises ~ 112 min. (6699.28 seconds & 167482 frames) At 720x576, with a video bitrate of 898kbps and an audio bitrate of 96kbps. Im also using, no PSY, no BiDi, no GMC and no Qpel. If all goes to plan the finished file size should be no more than 800MB.

The speed of the first pass look great. I will report back later!

Cheers

[DigitAl56K]

Originally posted by FreakNGoat
In the new 5.1.1, it prevents you from choosing slow, slowest or even fast mode when Qpel is turned on, thus forcing you to use standard mode. Anyone have any thoughts on this?

QPel caused 5.1 to default to Standard mode also, the GUI just didn't reflect this under 5.1.

QPel has never been supported by the Rate Distortion algorithm (as used by Slow/Slowest modes in 5.1/5.1.1b1), and QPel is completely useless in Fastest mode because Fastest mode performs no motion estimation anyway.

[SeeMoreDigital]

Well, I have to say, I'm all in favour that the new DivX GUI is able to prohibit users from selecting settings that don't work!

It's a very worth while and sensible addition to the overall functionallity of the codec.

Nice work you guys!

Cheers

[SeeMoreDigital]

Originally posted by SeeMoreDigital
..... I'm currently generating a PAL 2pass 'standard' mode test of StarTrek Nemises ~ 112 min. (6699.28 seconds & 167482 frames) At 720x576, with a video bitrate of 898kbps and an audio bitrate of 96kbps. Im also using, no PSY, no BiDi, no GMC and no Qpel. If all goes to plan the finished file size should be no more than 800MB.

The speed of the first pass looks great. I will report back later! Fantastic mates! The new DivX Beta, in 2pass 'standard mode' works really well!

During the second pass, there was not much speed difference between using, or not using MV!

The quality is still there too (I'm not sure that there is supposed to be an advantage here) as it seemed to my eyes that my encodes appeared slightly better looking. Even the colours seemed to be more stable. Especially when viewed on a 16:9 TV screen using component video.

I'm going to try and do something really wierd tomorrow (if I have the time). I'm going to encode my NTSC version of T2 extreme to a 656x368 NTSC 16:9 frame size and a 768x432 16:9 PAL frame size. I will calculate both the encodes to not exceed 800MB in file size!

I'm doing this because I'm interested to see what happens!

Now because I like to push a codec to it's fullest I would be very interested to encode DVD's that other forum members have found difficult to encode.... your suggestions please!

Cheers

[dTb]

Originally posted by Jaw3000
I have a quick question about DivX 5.1.1 Beta 1: As a newbie to encoding, what are the best settings (P4 2.53)?

With 5.1, I've been using 3 passes with 1st pass slowest, nth pass standard, and last pass standard or slow. Although this is taking a long time (about 24 hours) to encode. I don't really care how long it takes if it's the best quality possible, but if I can get equal or better quality with faster speeds with other settings? I haven't had a chance to test 5.1.1 Beta yet.

So, what are the best settings to use? Is there any point in 3 passes, or are 2 passes just as good? I've also seen a lot of people use 1st pass standard and nth pas slow or slowest? How about Psychovisual mode, quantisizer, and themes (I want the best compatability for the future)? What's best?

BTW, a feature I would like to see (I don't think this can be done now) is the ability to pause and resume encoding - even through closing the encoder and system restarts. This is probably not a codec feature but one for VirtualDub and other encoders.

Thanks!

Gej has sort of answered your question already but I just wanted to add that atm it's considered better to do the first passes with standard and the last with slow/slowest rather than the way your doing it with the first pass as slow/slowest.
I do the first two passes in standard and the third in slowest, I'm not sure however if this is faster or slower than Gej's method of two passes, both in slow mode.
For future compatability you should probably use the home theatre profile. The other settings I'd recommend is fast pve and definately b-frames.

[Tuning]

Is there any developement to DivX decoding filters than 5.1?

And I have a problem:most of movies in my HDD are 3.11 content and most of the time I used to watch these movies with these decoders.But after the installation the actual decoders for divx5.1.1(coming with codec)they are only active sometimes.Other times the default 3.11 decoder comes up.Is this a problem?Or only to my system.

BTW,I'm using MPC and WMP9 to watch.

-Tuning

[DigitAl56K]

Re: The pq modes for various passes.

If you run a set of clips through the encoder at 1st pass Standard, nth pass Slow/Slowest, and then the same set of clips at 1st pass Slow/Slowest, nth pass Slow/Slowest you get some interesting PSNR results.

All the PSNR scores will be very close, and at most you should see a 0.3db change in PSNR between the two methods (according to testing I and others have done so far).

More interesting though is that in some cases Standard, <slow, slowest> actually gives you a slightly higher psnr score than <slow,slowest>, <slow, slowest>.

In the scheme of things, if you actually average the difference in PSNR between the two methods over a number of clips, you see the PSNR difference fall almost to 0, which suggests that neither method is implicitly better than the other for video in general. While you might get a small PSNR increase using one method over the other for one particular clip you would probably have to encode it both ways each time to find out which is going to work best.

Because of this, and the time you save by doing 1st pass Standard, I always go for Standard, <Slow,Slowest>.

I haven't tested the quality gains for 3-pass using each method yet, I'll do this either tommorow or Sat/Sun, assuming my new PSU arrives (my old one blew up yesterday, who knew I'd mistake the "Power" button for the "Fireworks display" button...).

[SeeMoreDigital]

Originally posted by DigitAl56K
..... More interesting though is that in some cases Standard, <slow, slowest> actually gives you a slightly higher psnr score than <slow,slowest>, <slow, slowest>....
.....
Because of this, and the time you save by doing 1st pass Standard, I always go for Standard, <Slow,Slowest>..... Very interesting indeed!

If it turns out that there is no real benefit, encoding the first pass in either slow or slowest modes. Maybe the encoders GUI should be altered to suit. (in much the same way you have removed the 'fastest' setting)!

Indeed, when using the WMV9 VCM encoder. The first pass takes approx the same time to do, no matter what 'Performance' setting you select.... It's always the second pass that takes the time!

Cheers

[DigitAl56K]

You can never be sure that there won't be an exception where a Slow or Slowest 1st pass won't give a more significant PSNR increase, so its best to leave the option there (more choice is good).

It would be interesting to know if anyone else has done any PSNR testing on the two methods for a variety of clips?

[CruNcher]

http://forum.doom9.org/showthread.php?s=&threadid=63782
some tips how to improve ?

[DJ Alik]

So I gave a liittle test to the new 5.1.1 here are the settings:

"Say It Isn't So" NTSC DVD source
B and GMC on
Psych OFF
2 pass, both slowest
Avisynth 2.52 (october 11 version)
VirtualDubMod 1.5.4.1
1825kbps
704x372 crop and Lanczos resize

2 passes took about 36 hours on my 1.4ghz Athlon. Here are the stats from DivX DRF Analyzer:

DivX DRF Analyzer v0.9.5 Report!
File Name: C:\say.avi
FourCC: DX50
Codec: DivX503b1009p
Resolution: [ Width: 704 Height: 372 ]
Frame Rate: 23.976 frames per second
The Video has 130106 frames [ 01:30:26 ]

Average Frame quality is HIGH [Average DRF/quantizer is 2.85]
Standard Deviation: Quality is HIGH [Std. Deviation is 0.70]
Image Resolution is HIGH

The file has Packeted Frames!

There are NO frame drops ( NO drops is better )

Recomended Resolution: [688x368] (Target DRF/quantizer=2.8)

Performance Caracteristics:
Macroblocks per frame: 1012 ( Poor Playback in Slow Computers, PIII450 or better required )
The Width is multiple of 32

Kilobits per Second: 1782.88
Kilobits per Frame: 74.35
Kilobits per Macroblock: 0.073
Bits per Pixel: 0.29

Frame Type Statistics :
I Frames: 1.91%
P Frames: 33.73%
B Frames: 47.82%
S Frames: 16.55%
N Frames: 0.00%
(More Advanced Codecs use B and S frames)
Frame Quality Statistics :

DRF=1&2: 41526 32.5%
DRF=3: 62760 49.2%
DRF=4: 23338 18.3%
DRF=5: 0 0.0%
DRF=6: 0 0.0%
DRF=7: 0 0.0%
DRF=8: 0 0.0%
DRF=9: 0 0.0%
DRF>9: 0 0.0%
KeyF/DeltaF: 1.94%
KeyDRF<4: 2482
KeyDRF=4: 0
KeyDRF>4: 0

AverageKeyDRF: 2.34
MAXDRF: 4
AverageDRF: 2.85
Deviation: 0.70

The only thing I might say is that there is a lot of riniging around the titles in the opening sequence and a lot of macroblocking (As you can see the DRF Analyzer found it too Macroblocks per frame: 1012

[DigitAl56K]

Originally posted by DJ Alik
The only thing I might say is that there is a lot of riniging around the titles in the opening sequence and a lot of macroblocking (As you can see the DRF Analyzer found it too Macroblocks per frame: 1012

Actually the DRF Analyzer is simply calculating how many macroblocks make up a frame.

This is ceil(Width / 16) x ceil(Height / 16)

or ceil(688 / 16) x ceil(368 / 16)

or ceil(43) x ceil(23) = 989 Macroblocks per frame

I actually think the DRF might have its sums wrong, as its doing 44x23 instead of 43x23 to get 1012.

In any case, its not actually telling you whether the video looks blocky or not, just how many 16x16 pixel blocks compose each frame.

[DJ Alik]

Regardless, it does look blocky. I can post some frames if you want. I was thinking since the bitrate is pretty high (1825 kbps) it shouldn't be blocky at all.

[SeeMoreDigital]

Hi DJ Alik

If the aspect ratio of your NTSC source is 2.35:1. Then 688x368 is a wierd 'crop and resize' frame size. Try 656x368.

If the aspect ratio of your NTSC source is 1.85:1 then try 832x464!

Both the above will maintain the same quantity of vertical image pixels as the source. And will resize the horizontal pixels only.

Cheers

[fedge]

divx developers:

Don't listen to the ignorance of some people here... Your new beta IS faster (my encodes work significantly better, with similar to same quality[hard to notice a difference from 5.1,if there is one])

One or two bugs though still..

[Decoder]

1. sometimes i get a freeze...(if i deactivate all but the max deblock settings.. i dont get any freezes...(its divx with ac3 audio..)

2. I can open up multiple instances of the Config Screen...

Other than those two little things it seems to work great.

My comp.. athlon 850 512mb ram.. geforce 256

[fedge]

Originally posted by DJ Alik
Regardless, it does look blocky. I can post some frames if you want. I was thinking since the bitrate is pretty high (1825 kbps) it shouldn't be blocky at all.

Ive noticed that NOISEY dvd sources or other noisy sources will macroblock.. a lot. It also depends on what kind of frames that are being inserted.. (a lot of I-frames soemtimes will tend to give a blocky appearance).. you can tweek parts of the film by setting them to be P and B frames ... that MAY help..but it will tend to blur some of the detail off.. (you could set this by upping the motion search parameter.. to 10-20% higher than what it is now...)

[DigitAl56K]

Hey guys, I got a new PSU today, which means my main PC is back up to full capacity.

I'm now running a test of 5.1.1b1 on Matrix: Reloaded (complete movie). I'll check for any blocking when its done (probably some time early tommorow morning).

How are everyone else's results? Any major hiccups? :) For the purposes of helping us track down any potential issues, can you please post your CLI when you report an issue.

For example: "My movie looks like a mosaic, my 1st pass CLI was 'xxxxxxx', my nth pass CLI was 'xxxxxxx', the source was 'xxxxxxx' (PAL/NTSC)" etc.

The more information you post the easier it is to track down issues.

-Al

[SeeMoreDigital]

Originally posted by fedge
divx developers:

Don't listen to the ignorance of some people here... Your new beta IS faster (my encodes work significantly better, with similar to same quality [hard to notice a difference from 5.1, if there is one])... Agreed.

I have to say, I like the new beta very much indeed. It's much more user friendly!

Cheers

[DJ Alik]

Originally posted by SeeMoreDigital
Hi DJ Alik

If the aspect ratio of your NTSC source is 2.35:1. Then 688x368 is a wierd 'crop and resize' frame size. Try 656x368.

Cheers

Where did you get 688x368?!? I said that it is 704x372 the other number is what DivX DRF Analyzer suggests, which i usually ignore.

[SeeMoreDigital]

Originally posted by DJ Alik
Where did you get 688x368?!? I said that it is 704x372 the other number is what DivX DRF Analyzer suggests, which i usually ignore. Well even using 372 vertical pixels is a little odd, if your NTSC source is 2.35:1.

As I say, if you encoded using 368 vertical pixels this would perfectly match the vertical pixels of your DVD source.

Why not give it a go and see how you get on?

Cheers

[FreakNGoat]

I tested Qpel vs. Slowest mode to see which one looked better. I encoded the full movie of lawnmower man at a bitrate of 1717 kbps. For both encodes I used fast psych mode, B-frames, and no GMC.

The Qpel clip was easily better looking than the Slowest mode one. Not only was it sharper, but the Slowest mode clip suffered from what appears to be a "shimmering effect" around certain objects. It is very distracting when you are looking at a still scene. The shimmering appears to result from blockiness. I can provide clips if anyone wants.

[SeeMoreDigital]

Hi FreakNGoat

I have to admit that i've never bothered using Qpel above 1500kbps! Can you confirm that the 'shimmering effect' is mostly seen in the background, foregroung or the overall image?

Cheers and welcome to the forum

SMD

[FreakNGoat]

Originally posted by SeeMoreDigital

I have to admit that i've never bothered using Qpel above 1500kbps! Can you confirm that the 'shimmering effect' is mostly seen in the background, foregroung or the overall image?


It actually seems to be all three; it just depends on the scene. It is usually just one part of the scene though that exhibits this behavior, not the entire image. I've posted a couple samples from my test which will help illustrate what I am talking about.

In the first scene, the shimmering is most noticable in the top half of the pitcher on the table.

Qpel clip 1 (http://www.sonic.net/gtaylor/clips/lawmower-qpel-1.avi)
Slowest clip 1 (http://www.sonic.net/gtaylor/clips/lawnmower-slowest-1.avi)

In the second scene, notice how much sharper the mans face appears in the beginning in the Qpel clip. The shimmering is very obvious and distracting around the flowers in the Slowest clip. They look like they are moving around.

Qpel clip 2 (http://www.sonic.net/gtaylor/clips/lawmower-qpel-2.avi)
Slowest clip 2 (http://www.sonic.net/gtaylor/clips/lawnmower-slowest-2.avi)

I've always used Qpel with good results. People who complain about Divx not being sharp probably aren't using Qpel. I am currently encoding this same movie in XviD using the same bitrate and resolution with VHQ 2 and Qpel on to compare quality and specifically sharpness with the Divx Qpel encode. I'll post my results.

Anyway, I'd like to hear some comments and questions about these clips.

Cheers and welcome to the forum

Thanks! I've been around for a few months, I just haven't posted much yet.

[DigitAl56K]

QPel raises the minimum decoding requirements (possibly therefore forcing less post-processing on slower computers), and is not supported by DivX Certified devices (or any device I'm aware of that is currently on the market). Be careful when using it.

Slow/Slowest modes make major improvements when using half-pel estimation, which is what DivX Certified devices require. Remember also that QPel can in fact be detrimental to quality at low bitrates. You say you just encoded "Lawnmower Man" at 1717kbps and QPel improved the quality. I just encoded "Matrix: Reloaded" at 602kbps (movie is over two hours) for a 1-CD rip. If I had used QPel here the effect would have been quite different.

What I'm trying to get at is although under some circumstances QPel is a nice feature, both with very low bitrate encoding or for DivX Certified compatibility its a no-no. This is where Slow/Slowest modes come in extremely handy - don't be so quick to put a feature down without thinking about its benefits :)

Hopefully in the future the RD algorithm will be adapted to support QPel also, and then everyone will be happy!

-Al

[Tuning]

May I ask one question:If you are only playing on Computer and need a quick encoding,will enabling Qpel,GMC,and BiDi in standard mode(May be all together?) produce better quality than going for the slowest/slow mode in 2-pass fashion?[High birate encoding=>1100]

Thanks

-Tuning

[FreakNGoat]

What I'm trying to get at is although under some circumstances QPel is a nice feature, both with very low bitrate encoding or for DivX Certified compatibility its a no-no. This is where Slow/Slowest modes come in extremely handy - don't be so quick to put a feature down without thinking about its benefits

I realize they have benefits, but I don't think that should make them immune to criticism. I'm saying they do not produce the highest quality encodes, and at the expense of twice the encoding time. I'm glad that Divx is working to improve quality on hardware devices and very low bitrate encoding.


May I ask one question:If you are only playing on Computer and need a quick encoding,will enabling Qpel,GMC,and Quarter pixel in standard mode(May be all together?) produce better quality than going for the slowest/slow mode in 2-pass fashion?[High birate encoding=>1100]


Yes, without a doubt if you're using higher resolutions as well (>512 horizontal), but I would turn off GMC based on what I see is a mild general consensus around here. Apparently it wastes bits the majority of the time. I haven't really done any of my own testing on it. Anyway, if your goal is a quick encode, definitely turn it off.

[allynm]

Originally posted by Tuning
May I ask one question:If you are only playing on Computer and need a quick encoding,will enabling Qpel,GMC,and Quarter pixel in standard mode(May be all together?) produce better quality than going for the slowest/slow mode in 2-pass fashion?[High birate encoding=>1100]

Thanks

-Tuning

does 5.1 / 5.1.1 beta even let you set gmc/qpel? if so, how?

[Tuning]

@All
ill enabling Qpel,GMC,and Quarter pixel in standard mode(May be all together?)
First of all sorry for this mistake,please read as Qpel,GMC and BiDirectional Encoding......

@FreakNGoat
Thanks for the info,I will do my own tests.

@allynm
You can enable/disable these features in divx config => Select profile Wizard => disable profiles =>Click Next.

:)-Tuning

[DigitAl56K]

Because various people have been reporting some bizarre timings relating to what options are enabled (some say turning off b-frames increases encoding times, likewise with psycho-vis), I did some lengthy tests this morning with the big Matrix Reloaded fight scene (I never want to see another Agent Smith so long as I live..).

I testest Standard, Slow and Slowest modes with:
1) No PV or Bi-directionsal encoding
2) PV but no Bi-directional encoding
3) Bi-directional encoding but no PV
4) PV and Bi-directional encoding
The test clip was 8421 frames (5:36:840) long. Feedback window was disabled.

Taking the no PV/no bi-directional encoding time as 100% duration, results were (averaging all pq mode results):

1) No PV or Bi-directionsal encoding 100%
2) PV but no Bi-directional encoding ~105%
3) Bi-directional encoding but no PV ~138%
4) PV and Bi-directional encoding ~141%

Which is what I had expected. Also, in case anyone was wondering there were no inconsistencies for any specific pq mode. The order in terms of ascending duration was always 1,2,3,4.

-Al

[DigitAl56K]

Is anyone still alive? ;)

[SeeMoreDigital]

Originally posted by DigitAl56K
Is anyone still alive? ;) Well I'm still alive!

I can't speak for everybody else but I bet some of them have been testing VP6 like me.

I've also been nagging nagui at Sigma for some up to date Xcard drivers!

Cheers

[colordog]

I've done a ton of encodes now with beta 5.1.1 - very happy with it, except that it's not 100 times faster. Still, I'll take the 50%.

Wondering if there's been any word on the non-beta release?

One thing I'd like to see is a way to pause the encoding while being able to disable the feedback window. I think it was Gej that said that to be faster, the feedback window had to be disabled, but then you lose the "pause" button.

[SeeMoreDigital]

Hi colordog,

I been testing the DivX beta with MPEGmediator. And never ever have the feedback window enabled!

And with MPEGmediator you also get a pause key!

Cheers

[Fr4nz]

Hi guys. I encounter a problem when I use XMPEG to encode in Divx: when I want to encode a dvd using 2 or 3 passes, selecting the IFO or the first vob of the film, xmpeg does the first pass correctly, then crashes but the encoding keeps going until it finishes correctly the n-passes.

So it's not a serious problem but it should be better to correct it.

The problem doesn't appear when I select and encode a small part of a vob (for example if I want to encode 2 minutes of a film).

Anyone else had this problem?

[Soulhunter]

Finally I found the time to install DivX 5.1.1 !!!


Was not able to install it before...

Because I did a very loooong enc. session with Matrix Reloaded.... ;)

It was pain and fun in one... No matter !

DivX 5.1 was not working for me, but 5.1.1 works now... :)


Here are the results of some test encodes I did !

Just to give something to discuss... ;)


Source:

Gladiator Trailer (PAL DVD) / 1:04 min. / 25 fps / 640x480


Results:

Quantizer2 / Bidi Enc. / Fast Psy. / Slowest
Time: 24:55 min. / Size: 37.871.616 Bytes / Avg. PSNR: 43.53

Quantizer2 / Bidi Enc. / Fast Psy. / Slow
Time: 20:21 min. / Size: 38.242.304 Bytes / Avg. PSNR: 43.51

Quantizer2 / Bidi Enc. / Fast Psy. / Standard
Time: 05:10 min. / Size: 38.064.128 Bytes / Avg. PSNR: 43.35


Quantizer2 / Bidi Enc. / Slow Psy. / Slowest
Time: 23:45 min. / Size: 90.476.544 Bytes / Avg. PSNR: 41.88

Quantizer2 / Bidi Enc. / Slow Psy. / Slow
Time: 21:55 min. / Size: 90.552.320 Bytes / Avg. PSNR: 41.91

Quantizer2 / Bidi Enc. / Slow Psy. / Standard
Time: 06:30 min. / Size: 46.712.832 Bytes / Avg. PSNR: 42.19


Note:

When Fast Psy. mode was used, DivX seems to use more B-Frames...

Think that causes a lower file size and also a higher PSNR result !!!

Bye

[LordIntruder]

Well thanks for the encodes but I deduce you made an error when reporting the filesize for the last test because if this one is correct, I think we are all gonna use those settings! :D Half less in filesize and even better PSNR result. :p

I also did a full movie encode and I really really REALLY appreciate the increased speed gain. Thanks for the work. :)

[Soulhunter]

Well thanks for the encodes but I deduce you made an error when reporting the filesize for the last test because if this one is correct, I think we are all gonna use those settings! Half less in filesize and even better PSNR result.
Hmmm... No, I'm 90% sure I did not an error !!! :D

But to be sure, Ive redone this test !!! ;)


The only change now is in Time... :rolleyes:

Its now 08:00 min. !!! :p

Because I did the encode while writing this here !!! :D

Don't know what goes wrong here... :(

Maybe its source related !?! :confused:

Or the last test was right, but 4&5 was wrong... ???

Ill do a second test with a other source !!! ;)

Bye

[Soulhunter]

Hi again !!!

As I said, here is a second test with an other source... ;)

Just to be sure, and see what was wrong with my first tests !!!


Source:

Matrix - Lobby chapter (PAL DVD) / 1:00 min. (last 1500 frames) / 25 fps / 640x256


Results:

Quantizer2 / Bidi Enc. / Fast Psy. / Slowest
Time: 11:38 min. / Size: 23.070.720 Bytes / Avg. PSNR: 44.18

Quantizer2 / Bidi Enc. / Fast Psy. / Standard
Time: 02:57 min. / Size: 20.875.264 Bytes / Avg. PSNR: 43.75


Quantizer2 / Bidi Enc. / Slow Psy. / Slowest
Time: 12:14 min. / Size: 29.556.736 Bytes / Avg. PSNR: 43.36

Quantizer2 / Bidi Enc. / Slow Psy. / Standard
Time: 03:32 min. / Size: 23.470.080 Bytes / Avg. PSNR: 43.19


This results looking a bit more logical... ;)


Bye

[LordIntruder]

Hi Soulhunter.

Thanks to redone some tests. :) Sorry I didn't got first you were working at constant quantizer 2 and the difference must come from here. I only work with Nth passes and in this area there are small differences between Standard, Slow and Slowest.

However I'm very surprised to see such a difference. On your first test you got 90Mb in Slowest and 45Mb in Standard for the exact same encode with Slow Psy. And same with the next test, there is a 5Mb difference in size between Standard and Slowest with Slow Psy.

Did anyone else find such differences with constant quantizer? I wasn't aware of this.

[Soulhunter]

Hi Soulhunter.

Thanks to redone some tests. Sorry I didn't got first you were working at constant quantizer 2 and the difference must come from here. I only work with Nth passes and in this area there are small differences between Standard, Slow and Slowest.
No problemo... !!! ;)

I did the Quantizer2 tests just because I do mainly 3 or 4 CD and 1/2 DVD-R encodes...

Yeah, I know I'm a HQ Freak !!! :D

So, for this size I aim for, Quantizer2 is mainly used... :p

This way I could check DivX 5.1.1 ability's for hi-bitrate encodes !!!


But MultiPass encodes are in progress... ;)

Just wait a little bit more !!!

Think they are done in 2-3 hours... :rolleyes:

[EDIT: Was a good guess... Finally 02:07h !!! :D]

Bye

[Soulhunter]

Today is Sunday... Sunday is testing day !!! :D

So, here are my MultiPass results... ;)


Source:

Chaser Trailer - MPEG1 (CG) / 1:19 min / 25fps / 384x288


Results:


MultiPass 250 kbps / No Psy. / Bidi Enc. / Standard

Pass1:
Time: 03:02 min. / Size: 14.090.240 Bytes / Avg. PSNR: 40.24

Pass2:
Time: 02:52 min. / Size: 16.564.224 Bytes / Avg. PSNR: 40.46

Pass3:
Time: 02:51 min. / Size: 16.564.224 Bytes / Avg. PSNR: 40.55



MultiPass 250 kbps / Fast Psy. / Bidi Enc. / Standard

Pass1:
Time: 03:02 min. / Size: 14.090.240 Bytes / Avg. PSNR: 40.24

Pass2:
Time: 03:28 min. / Size: 16.566.272 Bytes / Avg. PSNR: 40.31

Pass3:
Time: 03:26 min. / Size: 16.562.176 Bytes / Avg. PSNR: 40.22



MultiPass 250 kbps / Fast Psy. / Bidi Enc. / Slowest

Pass1:
Time: 15:22 min. / Size: 14.090.240 Bytes / Avg. PSNR: 40.54

Pass2:
Time: 15:29 min. / Size: 16.562.176 Bytes / Avg. PSNR: 42.02

Pass3:
Time: 15:43 min. / Size: 16.560.128 Bytes / Avg. PSNR: 41.17



MultiPass 250 kbps / Slow Psy. / Bidi Enc. / Standard

Pass1:
Time: 03:20 min. / Size: 14.090.240 Bytes / Avg. PSNR: 40.24

Pass2:
Time: 04:18 min. / Size: 16.568.320 Bytes / Avg. PSNR: 40.19

Pass3:
Time: 04:28 min. / Size: 16.560.128 Bytes / Avg. PSNR: 40.10



MultiPass 250 kbps / Slow Psy. / Bidi Enc. / Slowest

Pass1:
Time: 15:32 min. / Size: 14.090.240 Bytes / Avg. PSNR: 40.53

Pass2:
Time: 15:50 min. / Size: 16.562.176 Bytes / Avg. PSNR: 41.93

Pass3:
Time: 16:51 min. / Size: 16.560.128 Bytes / Avg. PSNR: 41.09


Thats all so far !!!

But more will follow...

Next Sunday is not far away ! ;)

Bye

[jos]

Hello,

It's my first post here. I hope I won't say anything particularly stupid.

I've done some compressibility tests with DivX 5.1.1 beta 1 on American Beauty at 800 kbps. The focus of these tests was on dependency between psychovisual enhancement modes and compressibility. The results are quite interesting for me:

PVE off: 71%
PVE fast: 61%
PVE slow: 51%

(HomeTheater profile, B-frames on.)

I used to think previously that PVE increases compressibility at the expense of some invisible details, giving more bits to the more visible parts of the movie. So now I have a question: does it still make any sense to use PVE regardless of the above results? What so good it does to balance the negative impact on bitrate?

Another topic -- I've read some discussions on MV-file usage. In one of my tests I found that when using GMC together with MV-file I get a choppy playback in some scenes.

Thank you all for very interesting posts :-)

J.

[Gej]

For theses that do not read the Subject !: DivX Pro 5.1.1 Beta 2 is now available


Hello folks,

This is the second and (hopefully) last Beta for DivX Pro 5.1.1. In this version you’ll find again some speed optimization and some bugs fixes.
Please enjoy…

http://labs.divx.com/archives/000021.html

What's new in DivX pro 5.1.1 Beta 2
-----------------------------------

Encoder fixes:
- Slow mode 5-10% faster than 5.1.1 Beta 1
- Slowest mode 5-10% faster than 5.1.1 Beta 1
- Issues with Psychovisual and DirectShow Encoder
- Resize issues with DirectShow Encoder
- Fix issues with capture applications

Decoder fixes:
- Issue with n B frames and Deblocking fixed

Changes:
- Psychovisual Disabled by default
- Feedback mode Disabled by default

NOTE: How we measure speed of the Codec ?
We want to measure the speed of the encoding, not of the Encoding application , of a MPEG2 decoder or some preprocessing tools. So we create some tests files that are already pre processed and resized and that are encoded using HuffYUV (and predict left option) and we use theses to actually measure the Codec speed using VirtualDub. This reduces the influence of the actual reading of the source file. People with SMP system or HyperThreading CPU can also create a simple AVS script that will just load and color converts the HuffYUV file before sending it to the codec, allowing the AVS script to run on a separate CPU/Thread than the codec itself.

If you already own DivX Pro, a DivX Beta release will install over your existing DivX Pro version unless you install it to a different directory. (You may want to keep a copy of your officially released DivX Pro codec in case Beta Prototype releases on a 15-day trial, making it easy for everyone to help improve the codec. If we push out yet another beta release after your 15 day trial is up , we will create an additional 15-day trial so you can continue using the prototype version.

The DivX Pro codec released on DivX Labs should be relatively stable. Remember, however, that these releases have a Beta or prototype release status so, uh….you could possibly run into a few bugs from time to time.

[colordog]

Howdy -

I just installed DivX 5.1.1 beta 2 over beta 1.

Under the "Options" tab, the DivX 5 "First Pass", "Nth Pass", etc., buttons no longer open up the codec settings window.

Not sure if this is a complete DivX bug, or if it's related to the version change. I do know for sure that I could bring them up in beta 1 though.

Um... since I'm an idiot, how can I access the codec settings now, since my GKnot buttons don't work?

[colordog]

Also -

Uninstalling beta 2 and reinstalling beta 1 restores functionality to the buttons.

I think beta 1 will expire in a day or two though.

[Angelus]

I just tried installing the new beta 2 codec but Gordian Knot is unable to see it. I did hte "bgregister.exe" after I installed it but that didn't help at all either. I re-installed beta 1 over it and beta 1 works normally. Any ideas?

[colordog]

@Angelus

I encountered the exact same thing.

I posted a question about it in the GKnot developer's forum, but no bites yet.

[Druizk]

@Angelus & @Gej

These error in DivX Pro 5.1.1 beta 2, no register en drivers of Windows the fourCC divx.

I installed manually in register of Windows with "regedit" utility.
In the key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32\

append New Value AlfaNumber with key "vidc.divx" whitout quotes and Value: "divx.dll" again whitout quotes....

Sorry my bad english.

[Gej]

Installer is back online

http://labs.divx.com/archives/000021.html

Sorry again for the delay

Gej

[Soulhunter]

Hi again...

Ive just finished my first "full" encode with DivX 5.1.1 !

It was again Matrix Reloaded... :cool:

IIRC, Its the 7th encode now !!!


My settings:

Res. 960x384 / @ 25fps

1st Pass: Standard / 2nd Pass: Standard

Bitrate: 2592 kbps

Bidi. Encoding = on / No Psy Enh.


Ive done exactly the same encode with DivX 5.05 some days ago... :rolleyes:

Now I have to say that the 5.05 encode looks better than the 5.1.1 one !

With 5.1.1, fine details are blurry and flat areas are smoothed...

Its not much difference, but its visible !!!

Sure, this was with beta 1...

And before you ask, PP was not enabled... ;)

Has someone else the same impression ???


Bye

[SeeMoreDigital]

Hi Soulhunter,

Personally I don't think it so strange that you've found that your DivX 5.0.5 encodes look better than your 5.1.1(b1) encodes, especially without post-processing. As I am of the opinion that DivX is relying more heavily on post-processing techniques to make encodes with it's newer codecs look better!

May I ask why you used an image pixel frame size of 960x384. As this equates to an aspect ratio of 2.50:1! 912x384 would be nearer to 2.35:1.

However, if you want encode the same quantity of vertical image pixels as your 2.35:1 PAL DVD source, you could also try 1024x432!

Shame about DivX 5.1.1(b2). Looking forward to tomorrow!

Cheers

[Soulhunter]

May I ask why you used an image pixel frame size of 960x384. As this equates to an aspect ratio of 2.50:1! 912x384 would be nearer to 2.35:1.
Uhm... Has it not a AR of 2.5:1 when you crop the black boarders ???

Think the original AR is 2.35:1, but with small boarders... !?! :confused:

Thought this just because the 16:9 AR with cropped boarders results in a 2.5:1 AR... !!!

Hmm... Now I'm really confused !!! :p

As I am of the opinion that DivX is relying more heavily on post-processing techniques to make encodes with it's newer codecs look better!
I remember that the DivX 5.05 encode had a avg. quant. of 2.1 !!!

So I think there should not be much need for PP... ;)

Or is DivX 5.1.1's PP more than de-blocking ???


PS: I'm also looking forward... ;)


Bye

[SeeMoreDigital]

Originally posted by Soulhunter
Uhm... Has it not a AR of 2.5:1 when you crop the black boarders ???

Think the original AR is 2.35:1, but with small boarders... !?! :confused:

Thought this just because the 16:9 AR with cropped boarders results in a 2.5:1 AR... !!!

Hmm... Now I'm really confused !!! :p Don't be too confused. I take it you just wanted to encode the image only and not the matte (black bars)!

Here's some 'Info about... Pixel Ratios and Pixel Totals' you may find useful when encoding from PAL sources
PAL DVD Player & DV Camcorders
Frame Aspect Ratio = 1.25:1 'Anamorphic Frame'
Image To Nearest To Nearest Matte Image Matte %
AR 16th Pixel Pixel Pixel Qty Pixel Qty Of Frame
1.33:1 720 x 576 720 x 576 000,000 414,720 00.00
1.77:1 720 x 576 720 x 576 000,000 414,720 00.00
1.85:1 720 x 560 720 x 554 15,840 398,880 4.04
2.35:1 720 x 432 720 x 436 100,800 313,920 32.17
2.40:1 720 x 432 720 x 427 107,280 307,440 34.98
--------------------------------------------------------------------------------
PAL Standard (4:3) TV/PC Monitor
Frame Aspect Ratio = 1.33:1 'True Frame'
Image To Nearest To Nearest Matte Image Matte %
AR 16th Pixel Pixel Pixel Qty Pixel Qty Of Frame
1.33:1 768 x 576 768 x 576 000,000 442,368 00.00
1.77:1 768 x 432 768 x 432 110,592 331,776 33.33
1.85:1 768 x 416 768 x 415 123,648 318,720 38.79
2.35:1 768 x 320 768 x 327 191,323 251,136 76.14
2.40:1 768 x 320 768 x 320 196,608 245,760 80.00
--------------------------------------------------------------------------------
PAL Widescreen (16:9) TV/PC Monitor - 'Not a Recognized Standard'
Frame Aspect Ratio = 1.77:1 'True Frame'
Image To Nearest To Nearest Matte Image Matte %
AR 16th Pixel Pixel Pixel Qty Pixel Qty Of Frame
1.77:1 1024 x 576 1024 x 576 000,000 589,824 00.00
1.85:1 1024 x 560 1024 x 554 22,528 567,296 4.04
2.35:1 1024 x 432 1024 x 436 143,360 446,464 32.17
2.40:1 1024 x 432 1024 x 427 152,576 437,248 34.98

Originally posted by Soulhunter
I remember that the DivX 5.05 encode had a avg. quant. of 2.1 !!!

So I think there should not be much need for PP...

Or is DivX 5.1.1's PP more than de-blocking ???I too think that it should be the case that PP should not be required when encoding at a bitrate of 2590kbps. Personally I would not bother using any of the DivX tools such as BiDi, GMC, PSY etc, at all!

I take it you are using GK to generate your encodes. What resizing tool are you using?

Cheers

EDIT: 2.40:1 aspect ratio's added and 'To Nearest Pixel' instead of ' To Nearest Even Pixel'

[Soulhunter]

Don't be too confused. I take it you just wanted to encode the image only and not the matte (black bars)!
Yes, I always crop the black boarders away... !!! :D
Here's some 'Info about... Pixel Ratios and Pixel Totals' you may find useful when encoding from PAL sources
Nice n' usefully this list... THX for it !!! ;)
I take it you are using GK to generate your encodes. What resizing tool are you using?
I use GK only to calculate bitrate and making my AVS... :p

PS: For resizing I used Lancoz...


Bye

[Angelus]

Gej said last night that there was an error in the new beta DivX installer, and thus took the link for the download offline. He should fix it soon, and that's why the buttons dont work. For more info, look at the Divx Codec section

[CruNcher]

@SoulHunter and SeeMoreDigital
Matrix Reloaded Pal is not 2.35:1 its 2.40:1 ;)

[SeeMoreDigital]

Originally posted by CruNcher
@SoulHunter and SeeMoreDigital
Matrix Reloaded Pal is not 2.35:1 its 2.40:1 ;) Well that's good to know!

So now if Soulhunter wants to keep his original 384 vertical pixel size, he must now use 928 horizontal pixels!

Hey CruNcher,
I've been doing some more tests with VP6 on an 3Ghz P4 PC with a clean install of WinXP O/S.

My VP6 tests so far have just involved CBR encodes and I have to say they look a lot better than my original batch of tests!

I'll get back to you with regard to sending you some of my test encodes!

Cheers

[jggimi]

His comments have now been "merged" from the GK development forum into this thread, just to keep everything in one place for Gej and his team to track.

Since replies are by date/time, they're on the previous page of this thread, and it can look just a little out of sequence there due to comments from two threads that are now in one.

[CruNcher]

Originally posted by SeeMoreDigital
Well that's good to know!

Hey CruNcher,
I've been doing some more tests with VP6 on an 3Ghz P4 PC with a clean install of WinXP O/S.

My VP6 tests so far have just involved CBR encodes and I have to say they look a lot better than my original batch of tests!

I'll get back to you with regard to sending you some of my test encodes!

Cheers

huh hehe i think you confound me with C0mPr355 ;)

[Fr4nz]

XMpeg 5 keeps crashing between passes also with 5.1.1 beta 2 when you encode the ENTIRE dvd. So all is normal during the first pass, then xmpeg crash but the encoding keeps going for all the n-passes. You have to keep the window error if you don't want to terminate the encoding. Very annoying. Plz Gej, can you fix it?

I noticed that this bug doesn't occur if you select to encode only a small portion of the film, but only if you encode it ENTIRELY.

EDIT: I'm sure this is not an xmpeg bug because this doesn't occur with 5.0.5 and with 5.1.

EDIT2: I'm doing further tests...stay tuned!

[colordog]

Just as with beta 1, I'm getting the further speed increase claimed by DivX with beta 2.

Nice.

[Custom_VCD]

When I go to encode the capture in the brand new Divx 5.1.1 beta 2, virtualdudmod gives me error saying

Can't Start Video Compression

The Source Format is invalid
error code -2

It always occurs during the second pass? Thanks in advance

[Angelus]

check the GKnot FAQ.

If VdubMod fails to encode the first pass with "videosourceavi error: the sourceimage format is not acceptable. (error code -2)" you may have to make a manual change in your Windows registry. See TelemachusMH's comment in http://forum.doom9.org/showthread.php?s=&threadid=51906.

Also, what version of GK and VDubMod are you using?

[fedge]

Maybe since this is beta2 it should have its own string.. just a suggestion


Also, I ve had no problms with beta 1(but i never do any capturing)

[Gej]

No problem capturing here, the Wrong video format can come from two things:
- The capture card is sending a color format not recognized by DivX
- You trial/Registration is wrong, the DivX codec in this case throw a "wrong video format" exception to exit the encoding app.

[Fr4nz]

UPDATE ABOUT DIVX BUG WITH XMPEG:

There are no problems if you decrypt the DVD on the HD and then encode it.

Very strange bug.

[Soulhunter]

About my first 5.1.1 "Reloaded" encode...

Wow !!! :eek:

Seems that Ive enabled psy. mode in my first DivX 5.1.1 Reloaded encode, without knowing it... :D

Because Ive done another encode (now with a 928x384 res. ;)) and now (without psy. mode) It looks much better !!!

Another thing...

Can somebody confirm that this new "post DivX 5.05" versions, look better on still scenes ??? I think with 5.1.x flat/uniform background looks more static now... (less texture movement) !!!



PS:

While using this new DivX versions, I have some feature requests...

1.

Could DivX write some sort of "analyze" log-file ???

This would save up all info you can see in the feedback window...

Like the min/max/avg of Bitrate, Quants and PSNR !!!

Maybe the percentage of I,P,B frames and all other info too ?!?


2.

Why is the video preview in the feedback window not resize able ???

Its disturbing when you work with high res. video... :angry:

Because you cant reach the bottom of the feedback window then !!!

A preview resize function like in VDub would be useful... ;)

Like 25%, 50%, 75%, 100%, 125%, 150%, 175%, 200% !!!


Bye

[Fr4nz]

Gej I've found another problems with XMPEG/Divx 5.1.1 combo.

As you can see from this image:

http://users.libero.it/i3ltt/Cazzate%20varie/movie.JPG

there are blocks which appears after a change scene (so they come from previous scenes, before an I-Block occurs).

This problem appears sometimes and without a reason (sometimes encoding is good, sometimes has this "block problem".

With Xmpeg/5.0.5 I've never had this problem.

Gej I'm guessing now if there's an incompatibility between these two programs... :confused: :confused:

Thanks for any answer!

PS: The encoding paramenters I used for the film in that pictures were: 1650kbps, b-frames activated, psy off.

[Torian]

@SeeMoreDigital (6th November 2003 18:46):
"I too think that it should be the case that PP should not be required when encoding at a bitrate of 2590kbps."
Definitely, it deteriorates the image quality at DVD-Quality encodes.

"Personally I would not bother using any of the DivX tools such as BiDi, GMC, PSY etc, at all!"
I disagre. Not using BiDi is a waste of Bitrate, but most importantly you should use PSY as Soulhunter seems to have discovered too. It is completely rewritten (since 5.1) and does not blur the image as it uses to with 5.0.5. If you want to preserve the image quality of a DVD (I do) this is mandatory and you can discern every pore of the actors faces. (I have a sample of a dvb-s capture w/ and w/o Psy which shows a dramatic difference).
As I intend to keep my movies somewhat compatible to standalone-players I do not use GMC.

[SeeMoreDigital]

Hello Torian,

Welcome to the forum

Originally posted by Torian

Ref to post by SeeMoreDigital (6th November 2003 18:46):
"Personally I would not bother using any of the DivX tools such as BiDi, GMC, PSY etc, at all!"

I disagre. Not using BiDi is a waste of Bitrate, but most importantly you should use PSY as Soulhunter seems to have discovered too. It is completely rewritten (since 5.1) and does not blur the image as it uses to with 5.0.5. If you want to preserve the image quality of a DVD (I do) this is mandatory and you can discern every pore of the actors faces. (I have a sample of a dvb-s capture w/ and w/o Psy which shows a dramatic difference).
As I intend to keep my movies somewhat compatible to standalone-players I do not use GMC. There's no doubt using BiDi can make your encodes look better!

I've used BiDi with many low bitrate 2pass encodes and it does make a difference for the better. But I've not seen any difference using BiDi when geneating 2pass encodes above 2000kbps. And this certainly seems to be the case when I view my encodes on my TV via Xcard!

Personally I can't say how well DivX performs when capturing or how well it performs when generating high bitrate CBR encodes, with or without BiDi + PSY!

However, I've dug out some old 600~700kpbs CBR encodes I did with DivX, WMV9, RV9, XviD, etc and compared them agianst the new VP6 codec. And VP6 is astonishing!

Can you confirm whether your are generating 1pass or 2passes encodes when using BiDi + PSY?

Cheers

[vio]

Just did a little test.

DVB source -> DVD2AVI -> Gordian Knot -> Avinsynth -> Virtualdub

704x400, 25fps, 500 frames.

B-frames, no pse, no mv. 1-pass quant 1.

Speed time (s) size (kb)

5.1
slowest 349 16,610
slow 271 16,590
standard 40 18,336
fastest 33 28,148

5.1.1
slowest 186 16,702
slow 176 16,720
standard 30 18,350
fastest 21 29,562

These are the settings I use to temporary backup small clips. Didnt realise the negligable difference in size between slow and slowest.

So half percent increase in size and about half the time to encode, not bad. Visually no difference and obviously (quant 1) great quality.

[Narsus]

Originally posted by Fr4nz
Gej I've found another problems with XMPEG/Divx 5.1.1 combo.


I had same problem with Divx 5.1.1b1.
Divx 5.1.1beta2 fixed this.

[Soulhunter]

@Torian
Not using BiDi is a waste of Bitrate, but most importantly you should use PSY as Soulhunter seems to have discovered too.
Uhm... What ??? :confused:

Ive nothing like this discovered... !!! :p

Please, read my posts again !!! ;)

I wrote that my first 5.1.1 "Reloaded" encode looked worse than the 5.05 one (smeared, vague, blurry) !!! Thought it was without psy.... But seems it was not !!! Because later I did a second encode (same source) without psy. mode (checked this time) that looked much better than the first 5.1.1 one !!! So the only thing I can think of, is that my first 5.1.1 encode (blurry one) was done with psy. !!! Maybe psy. is nice for lower bitrates, like RV9's in-loop filtering, but for high bitrates not...

But for the thing with BiDi, I think its also very useful for high bitrates... Seems to drop the image quality a bit... (Is this because B-Frames using lower Quants. ???) But for my "Reloaded" example, not using BiDi would drop the Avg. Quant. from 2.1 to something like 3 or so... (Not sure, haven't tested this yet ! ;)) No matter... Having every 2nd frame a bit less detailed does not hurt the overall quality when watching the movie !!!


PS:

Can now someone confirm now, that the new versions of DivX (5.1.x) look more static/solid and have less texture movement on plain background than with DivX 5.05 ???


Bye

[Snippit]

Quick question: I started encoding Indiana Jones The Last Crusade using DivX5.1.1b2, GKnot 0.28.6.2 at a rate of about 1600 kbps. GMC and BiDi turned on, PV off, slow setting, 2-pass session on a P4@2GHz. The encoding time appeared a bit ridiculous, so what I'm simply interested in is whether I've used the absolute wrong settings or if this is a normal encoding time using those settings.

Enc time: 9 hours for the first pass and an estimated 12.67 hours for second pass(terminated).

/S

[Angelus]

For most DVD encodes I use a 2-pass encode, using "Standard" speed with GMC and BiDi on the first pass and use "Slow" speed with the same GMC and BiDi on the second pass and it usually takes me a little over 7 hours for the whole encode and the muxing of the audio. So something may be wrong with your system. I have a P4 1.6 Ghz processor with 512mb ram. I've recently upgraded to a 7,200 RPM hard drive with 8 mb cache and i've seen encoding speeds increase 5-6 fps, sometimes even a lot more than that. It also depends on the length of the dvd you are trying to encode...

I think i read somewhere that it wasn't worth using slow on the first pass b/c it didn't really amount to any visible improved quality. And usually for me slow doubles the encoding time so standard speed to me is the best choice.

[Snippit]

On the other hand, using DivX 5.0.2 Pro for the same material lands me at around 3,5 to 4 hours for a 2-pass, 2CD encode using slowest, GMC on, BiDi on, QPel off and PSY off. Muxing of audio included. I definately don't think anything is wrong with my rig because it performs well in other instances.

I'm just wondering a little about what settings NOT to use, because so far I've either got shitty results with DivX5.1 or ridiculously long enc. times. The different options must be way different between DivX5.0 and DivX5.1.

Currently running a new 2-pass encoding session on slow-slow, GMC on, BiDi off, PSY off, QPel off, resize filter sharp bicubic, 1450 kbps, 25 FPS PAL, res. 704 x 304 for a movie 2 hours in length. First pass rendering rate @ about 8 fps.

Maybe I'm just a complete n00b, and that explains almost everything. ;)

[Angelus]

Well the reason you are getting 3.5 to 4 hours with Divx 5.0.2 and a lot longer with DivX 5.1.1 is b/c slow on the DivX 5.0.2 = standard on DivX 5.1.1. So that may have something to do with your confusion. By the way, was it 3.5 hours for the whole encode? Or for each pass? Because that's a big difference in time then...

[Snippit]

Originally posted by Angelus ...on the DivX 5.0.2 = standard on DivX 5.1.1.

Ah, well, that would probably explain part of it.

The time stated is for the entire session, that is AC3 --> MP3 + two passes + audio muxing.

Oh well terminated the previous session and started a new now using standard-slow, BiDi on, GMC on, QPel and PSY off. Lot's of sessions now really. :D

edit Well, completed in just over 9 hours but the result was not impressive to say the least. Blocky. Will do more experiments.

Anybody who actually got good results, please post your settings and I'll try them as well. :)

[Maggoty]

Howdy,
I'm also getting the slower encodes with 5.1.1b2 on the slowest mode setting. Around 8 hour or so for each pass, which is heaps heaps longer than the 5.02 codec. On my P4 2.4gig I used to get around 3 or so hours all up for 2 passes on the 5.02 codec.
I did a 1 cd encode of Xmen 2 with the 5.1.1b2 codec and I must say with an average bit rate of around 680kb the movie turned out pretty bloody good. For the length of the movie it came out pretty crisp.
Although the slow encoding times are a bit sucky, the final output is rather nifty and rewarding.
I'm viewing all my movies thru xbox media player on my tv though, never on my monitor, so the tv's low resoultion may improve things a bit though.
If they made the slowest mode as fast as the 5.02 codec's slowest mode, then that would totally be awesome.

Maggoty

[SeeMoreDigital]

Originally posted by Maggoty
... I'm also getting the slower encodes with 5.1.1b2 on the slowest mode setting. Around 8 hour or so for each pass, which is heaps heaps longer than the 5.02 codec... I think everyone is forgetting that when you use the slow & slowest modes with DivX 5.1.x (including the beta's) they do not equate to the same modes when using DivX 5.0.2!

As far as I am aware this fact has been well documented in DivX's website guides and notes!!

With DivX 5.0.2, when you move the slider fully to the right. It equals (or should now infact be slower than) DivX 5.1.x in standard mode.....

Cheers

[Soulhunter]

Hi, Its Sunday again.... ;)


Source:

The Matrix - Lobby Shootout / 3:07 min. @ 25fps / 720x400 pix. (Lancoz)


How much is the compression gain with B-Frames and how much do they reduce quality ???

Results:

QB @ Quantizer 2 / Standard / BiDi / No PVE
File size: 62.810.112 Bytes / Avg. PSNR: 46.90

QB @ Quantizer 2 / Standard / No BiDi / No PVE
File size: 75.253.760 Bytes / Avg. PSNR: 47.22

QB @ Quantizer 2 / Slowest / BiDi / No PVE
File size: 67.260.416 Bytes / Avg. PSNR: 47.05

QB @ Quantizer 2 / Slowest / No BiDi / No PVE
File size: 79.749.120 Bytes / Avg. PSNR: 47.34


How do the different speed settings affect multipass encodes... ???

Results:

MultiPass @ 2000 kbps / 1st Standard / 2nd Standard / BiDi / No PVE
File size: 46.954.496 Bytes / Avg. PSNR: 46.39

MultiPass @ 2000 kbps / 1st Standard / 2nd Slowest / BiDi / No PVE
File size: 46.968.832 Bytes / Avg. PSNR: 46.45

MultiPass @ 2000 kbps / 1st Slowest / 2nd Slowest / BiDi / No PVE
File size: 46.954.496 Bytes / Avg. PSNR: 46.47


Bye

[Torian]

A rather late update but I didn't have time before the sunday, still a little off-topic ;)

@Soulhunter: My apologies for not reading thoroughfully, I must have read what I was expecting.

@SeeMoreDigital:
"Can you confirm whether your are generating 1pass or 2passes encodes when using BiDi + PSY?"
2 pass for storage.

"But I've not seen any difference using BiDi when geneating 2pass encodes above 2000kbps"
To confirm my experience from 5.1 with beta2 I encoded the Black Hawk Down trailer @ 3500 kbps (768x432, comptest w/ q2 66%) 4 times testing Bi and Psy effects.
BiDi+Psy is slightly more detailed than Psy alone, no image degradiation visible. It probably still saves some bitrate.

The two versions w/o Psy are not able to reproduce the original version's texture and blurr fine details. Yet Psy exaggerates the texture a bit but at a higher bitrate (4500 *g*, keep in mind that it's a trailer) is nearly no difference to the original visible exept for stills of high motion scenes.
Another test w/o Psy at this bitrate didn't bring it much closer to the original, even @6000kbps it looks inferior.

I don't use PSNR because I care more about visible differences than the ones a computer can spot.

[DigitAl56K]

DivX 5.1.1 has been officially released, please see:
http://forum.doom9.org/showthread.php?s=&threadid=65334

[jggimi]

Since that is the case, I am un-Sticky-ing this Beta thread from the forum.