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