View Full Version : DivX 5.0.3 released


timeToy
25th January 2003, 06:06
Taken from the Version History at
http://www.divx.com/divx/divxpro_win_versions.php

New:

- Support for interlaced video.
- New de-ringing post-processing algorithm. It is activated when the post-processing level is set to Level 6.
- Video Buffer Verifier (VBV) model (one and two pass encoding).
- Nth Pass™ encoding.
- Support for DivX Certified Profiles. With the new DivX Certification program, DivXNetworks is enabling third parties to create "DivX Certified" products that are rigorously tested and fully compatible with the entire suite of DivX® video technologies. There are four levels of official DivX Certified video products: Handheld Video Devices, Portable Video Devices, Home Theater Video Devices and High Definition Video Devices. Now, when you encode video, you have the option to force your video to comply with one of the DivX Certified Profiles to ensure that your video will play back properly on certified products.
- DivX Decoder verification logo.
- New internal application programming interface (API).

Improved:

- The motion estimation algorithm is better optimized for High Definition resolutions (up to 1080p, or 1920 x 1080 pixel resolution
- The pre-processing performance is now improved with with the IYUY 4:2:0 color space
- The global motion compensation (GMC) algorithm is better optimized to improve visual quality

Changed:

- Updated the quarter pixel motion estimation algorithm (Qpel) to comply to the new revision of the standard 14496-2 DCOR1. Videos encoded with the older version of the Qpel algorithm can still be decoded.
- Removed MP4creator and the MPEG-4 file output option due to some compliance issues. This will return in our next release once these issues are resolved.
- Removed the Intelligent IVTC functionality due to persistent problems caused by lack of variable frame rate file format support.
- Changed the block skipping threshold for high quantizers, which improves visual quality when high quantizers are used.

Fixed:

- Fixed a bunch of little cosmetic bugs in the DirectShow decoder properties page.
- Fixed a bug where the last P frame before an I frame was not displayed when Smooth Playback was selected.
- Fixed a practically unnoticeable YUV->RGB16 color conversion rounding bug.
- Fixed a bug that was the cause of some of VirtualDub's "Cannot Start Video Compression" errors.
- Fixed a few issues with DivX 3.11 compatibility.
- Modified the decoder to deal with a bug in the old OpenDivX encoder
- Fixed a problem where some rounding operations were not done toward zero, as is required by section 7.4 of the spec. This fixed an intra case in MPEG-2 inverse quantization.
- Fixed a bug where some frames would be corrupted by an out-of-range error.
- Fixed several rounding issues related to MMX/SSE/SSE2 optimizations.
- Fixed an MMX bug in RGB32 color conversion.

timeToy
25th January 2003, 06:09
I wonder if they post it at 5:03 GMT ?

cordraconis
25th January 2003, 09:38
The version info I found there, is a tiddy bit more complete ...

The N'th-pass feature looks promising, but I don't have time to lay it on my testbench :(
(Shouldn't there be a law to prevent new releases of Video codecs during the exams ??? :D )

Nevertheless, I'll have to reboot now to finish the installation.

(I also think it's cool that I have already installed the new release, before even Doom9 himself had a chance to put it in his News-section on his site :cool: )
BTW: for the last weeks, I noticed that the newsupdates on his site are in the afternoon ... or maybe his server is only updating around 11h ??? anyone can comment on this?)

greetz!

Caleb666
25th January 2003, 10:12
this new version does looks promising...

makes me think that xVid will never reach the same level as DivX :)

Ice009
25th January 2003, 11:33
can you actually download the pro version? i went to the website and it appears you have to purchase it?

don't they have a free adware version like they did with 5.0.2?

plazz2000
25th January 2003, 11:36
I've been able to upgrade with this https://secure.divx.com/downloads/DivXPro503Bundle.exe

Does anyone else find that the options for QPel and GMC are greyed out?

And what's this "Bitrate Modulation" for Nth pass encoding?

cordraconis
25th January 2003, 11:44
don't be too sure about this ...
Personally I'm a big fan of Lame-Encoder ... I once compared it with the different settings of Fraunhofer, and aldough they are the pioneers of MP3-encoding, Lame is open source and a LOT better than the "official" codec. (one reason why I would never pay to download MP3's, since they would probably use the Fraunhofer, and if I'm gonna pay for it, then I want my *own* settings for the encoder *I* prefer... (but that's off-topic :) )

Right now I'm making a lot of Passes for the first 10000 frames of LOTR Extended edition. (2-pass, 3-pass, 5-pass and 10-pass encode).
The 3-pass is to see the effect of an extra pass, the 5-pass to see the effect of a lot of passes, and the 10-pass to see the effect of the most passes I'll ever plan to use. (In my course of Analytical Chemistry, there is also a technique of doing several reiterations of a given calculation, as to become the final acidity (pH) of a solution. I learned that if you need more than 5 passes, then your assumptions to start from were erroneous. :)
So that's why I'm curious of the result from the 5-pass.
Also, I think that the Curve-modulation (hi/lo motion) is more meant to *reduce the number of passes* to reach optimal results. In theory, if you do a lot of passes, then the bitrate distribution should be optimal, regardless of the amount of High/Low-motion scenes. If you leave it to "Constant quality", and do a high number of passes, the result should be always the same.

My command line in the Encoder is:
-bvnn 600 -psy 1 -key 600 -log "c:\divx.log" -w -mv "c:\mvinfo.bin" -p -b -pq 5 -vbv 7800000,1835008,1376256 -profile 4

(Sharp bicubic, Smart Crop in Gordian knot, resolution 640*..., Fast Recompress, Bitrate 600)

I'll keep you posted on the results of my first test ...
(P.S. Am I the first to test this "Nth-pass"-feature?
:cool: )

mikeson
25th January 2003, 12:25
@plazz2000:

Does anyone else find that the options for QPel and GMC are greyed out?

Disable "1 - Choose your profile" and here you go... ;)

Teegedeck
25th January 2003, 13:01
Originally posted by Caleb666
this new version does looks promising...

makes me think that xVid will never reach the same level as DivX :)
Have I missed any important new DivX-feature that isn't there in XviD (dev-api), already? Interlaced-support, (real) GMC, maximum bitrate...

This n-pass sounds great: 'We still don't hit aimed filesize in 2nd pass? Bugger, let's just have a couple more passes and we'll hit it eventually! Voila; problem solved.' (I shouldn't be so malevolent, XviD is still plagued by a 2-pass bug that's been introduced a couple of weeks ago.;))

What I like most about this release is the removal of non-working features... (Was a bit daring to have things there that just do harm but still could be listed as 'features'.)

Iznogoud
25th January 2003, 14:18
After short testing with 2-pass, pro-features on 5.03 looks very good to my eyes. Compared to XviD hmm.... I guess to my untrained eyes they are quite close but I let the flamers to decide wich is truly better;) Anyways it's good to have competition, so welcome back Divx.

OBcecado
25th January 2003, 14:30
Hi, I've encoded a spiderman trailer with following settings, In 5 pass, it seems good, but is it worth the extra time for each pass ?
I used following Cli:
-bvnn 1200 -psy 1 -key 300 -log "C:\divx.log" -w -mv "c:\mvinfo.bin" -p -b -g -q -pq 5 -vbv 7800000,1835008,1376256 -profile 0
Best regards

cordraconis
25th January 2003, 14:34
And here are the results form my N-passes, as I already explained before ... (post-processing set to min.)

It's a bit difficult to explain, but the main difference between all the passes comes down to ... Quantisation!

When I started the next-pass, there was a small window popping up for a fraction of a second, and I could read something about Average Quantisizer. In the 8th, 9th and 10th pass this number was the same. I think the N-passes means finding the ideal Quantizer or something ... Correct me if I'm wrong.

If I compare the 2 with the 3-pass, then there are less ringing artefacts in general: Around the logo in the beginning, on the panning scenes of the Map of Middle Earth (also less jerckier than with the 5.0.2 codec and GMC :)), around the bodies of people walking around in the battle, etc ... The Macroblocks are also reduced, and that's even clearer in the 5-pass.
If you look at the golden LOTR-logo in the beginning of the movie, then there are small cubes of different brightness that are "dancing around". You also have this in the backgound, and in low-contrast scenes (like the "Clouded" mountains where Gollem lives, and in scenes with a lot of smoke.) In the 5-pass, the "dancing blocks" are reduced, and the "ringing" is gone. In the 10-th pass, there is no ringing and macroblocks any more, and the low-motion parts of the movie look "stable". There are even slightly more details in the massive charging-scene with the orcs and elves/humans. The lack of details is clearly becouse of the low bitrate, but everything has it's limits! :rolleyes:

To summarize:
* The more passes, the better the quantisation, this means:
- No ringing around sharp edges and stationary (or slowly moving) objects.
- Less macroblocks in high-motion scenes.
- A Stable background. (compare a 2-pass scene of the setting sun in the first 10000 frames of LOTR, and a 5 or 10-pass!)
- Better low-contrast encoding. (smoke, clouds, ... see above).

* The GMC is better than in 5.0.2, and acceptable.
* The lack of details (at low bitrates!!!) is mostly because of the reduction of macroblocks. (for me, they tend to "add details", or to mask the lack of them, so objectively it seems that there are less details, which isn't.)

* My advice for 1CD-rips would be not more than 10 passes (which is already overkill :sly: ), and for 2CD-rips, not more than 5 passes (idem dito). If the result is still not satisfying, use gordian knot to recalculate, or to do a comression test.

* It has not escaped to my attention, that if the Quantisizer is indeed the "key setting" for those N-passes, then it could be possible to use this information to manually set 5.0.2 to make optimal rips in 1-pass. Also, if indeed in the 8th, 9th and 10th pass this avg quantizer was the same, this could be used to automate the #of passes till there is no change anymore. Maybe this could be something for Johnny's DivX5 Enc ???

Thanks for staying with me till here :), but now I really have to study for my exam on monday ... Maybe I'll check the forum this evening.

cheers!

cordraconis
25th January 2003, 14:37
Originally posted by OBcecado
Hi, I've encoded a spiderman trailer with following settings, In 5 pass, it seems good, but is it worth the extra time for each pass ?
I used following Cli:

Best regards

My guess is your bitrate is wayyyy too high to see differences ... try again with 500 or 600 in stead of 1200 ;)

bye!

Dark-Cracker
25th January 2003, 15:07
hi,

is there a way to configure the quantizer and rc period ? it seems to me they have remove these settings.

valnar
25th January 2003, 15:08
Anyone know if the latest GKNot works with 5.03?

Robert

mikeson
25th January 2003, 15:22
@Dark-Cracker:

Have you tried CLI? Maybe the same settings as in DivX 5.0.2... ;)

valnar
25th January 2003, 15:46
Have you tried CLI? Maybe the same settings as in DivX 5.0.2... ;) [/B]

No, but then I'm a L@MeR. I'd prefer to have GKnot do my CLI for me. I hope DivX didn't change any CLI parameters from 5.02 to 5.03.

Just curious... :D

Dark-Cracker
25th January 2003, 15:57
@mikeson

yes i have try with the cli mode (it doesn't work) and with the registry key (doesn't work too).

Ps: it seems to me gknot doesn't use climode but a mime64 encoded string, i think it will not work with divx5.0.3, wait and update of gknot.

Ps: nth pass give me a green first frame and a dark video until it rush a kf . does someone have the same problem ?

Bye.

seewen
25th January 2003, 17:25
Originally posted by Dark-Cracker
hi,

is there a way to configure the quantizer and rc period ? it seems to me they have remove these settings.

They are not in the GUI, but the Official Guide says that you can use it with CLI :

-dr 12,2,2000,10,20


But maybe that the new "bitrate modulation" option, influence these settings ( Quant Max/min, RC avg period, etc..) .. no ?

And some other parameters ( but not Quant and RC avg Period ) can be tweaked in the registery

HKEY_CURRENT_USER\Software\DivXNetworks\DivX4Windows

Boulder
25th January 2003, 18:10
I wonder if they even tested the package properly before releasing it. The decoder can't be configured, it resets itself every time. If you press default, you'll get zero postprocessing:mad:

Back to XviD again, it seems.

seewen
25th January 2003, 18:17
Originally posted by Boulder
I wonder if they even tested the package properly before releasing it. The decoder can't be configured, it resets itself every time. If you press default, you'll get zero postprocessing:mad:

Back to XviD again, it seems.

Exactly the same with the encoder GUI :

If you choose profile "home cinema" for example, you can choose "B-frame" for 1st-pass, but not for Nth...
Maybe it's automatic, but it's strange so. Beccause if you un-select profile(s), then you can set "b-frames" for "Nth pass too".

And if you unselect profile(s), and you want to set "Avg bitrate @1000 kbps" and "Max Bitrate @5000 kbps", if you go in an other tab ( "manage setting" or "profile" ), and then you come back in the "bitrate control" tab, the "Max Bitrate" is reset at ( 10 * Avg Bitrate )...

Maybe divxnetwork will release 5.0.4 in a short time ;)

Caleb666
25th January 2003, 18:32
QPel and GMC are disabled by default.

Why?
Since the upcoming hardware divX players aren ot supporting these optionsy yet.. so they also disabled them by default in this version.

YOU CAN STILL ENABLE IT! so don't panic.

symonjfox
25th January 2003, 18:50
Now I'm encoding a movie to test it ... 5 pass VBR. I don't like that there isn't a 1 pass quality based (like in divx 5.02 or xvid). All my movies were encoded by that way and looks better than 2 pass vbr (5.02) let's hope well with 5.03.

I have a good speed increase with 5.03 using my athlon xp.

seewen
25th January 2003, 19:01
Originally posted by symonjfox
[B]Now I'm encoding a movie to test it ... 5 pass VBR. I don't like that there isn't a 1 pass quality based (like in divx 5.02 or xvid).

of course there's "1 pass Quality based". Just disable "profile" option ( in "profile" tab), then you could choose +1 pass quality based", " 1st pass OLD pass", "2nd pass OLD pass", etc..

CruNcher
25th January 2003, 19:06
QPel and GMC are disabled by default.

Why?
Since the upcoming hardware divX players aren ot supporting these optionsy yet.. so they also disabled them by default in this version.


hmm good argumentation but maybe also because they saw that their a mile away from the standard also ;)

X-guy
25th January 2003, 19:25
Im sorry for the maybe dumb question,but how do i enable more then 2 passes on the 5.03?

oddball
25th January 2003, 20:40
Use nth pass on the drop down and select how many passes you want.

X-guy
25th January 2003, 20:58
Originally posted by oddball
Use nth pass on the drop down and select how many passes you want.

Where? i dont see any options to choose passes...maybe i need to put it menualy in the CLI line? if so where exactly?
thanx.

plazz2000
25th January 2003, 21:09
You don't actaully enter how many passes you want. Just keep on saving it five times, with the same settings for 2nd, 3rd, 4th and 5th times.

Big speed increase on my Athlon XP2400+, 32fps+ on the nth passes.

jonny
25th January 2003, 21:15
@cordraconis:


* It has not escaped to my attention, that if the Quantisizer is indeed the "key setting" for those N-passes, then it could be possible to use this information to manually set 5.0.2 to make optimal rips in 1-pass. Also, if indeed in the 8th, 9th and 10th pass this avg quantizer was the same, this could be used to automate the #of passes till there is no change anymore. Maybe this could be something for Johnny's DivX5 Enc ???


:D
some testing about this is required first (and for sure... i must first adapt divx5enc to this new version... i was planning to release the new version this days... i guess i was wrong :))

kakomu
25th January 2003, 21:16
Whenever I try to set my confog settings, this version isn't keeping them saved (as in the quality settings will reset itself all the way to the left). Is anyone else encountering this problem?

X-guy
25th January 2003, 21:46
Originally posted by plazz2000
You don't actaully enter how many passes you want. Just keep on saving it five times, with the same settings for 2nd, 3rd, 4th and 5th times.

Big speed increase on my Athlon XP2400+, 32fps+ on the nth passes.

ahh thanx a lot man,now i hope that a new version of GK will be out quick ;)

cordraconis
25th January 2003, 23:13
Here is an interesting analogy that I came up with for the "Curve modulation":

"I believe that with "High motion modulation" the codec will give more bits to the high-motion scenes, and less to the low-motion scenes. It will do this anyway after lets say 10 passes, but if you use the "modulation", then it'll give more bits *faster*, so you'll have the same result after lets say 5 passes. Something like a N2O injection in your engine: Your top-speed will still be the same, only you'll get there a lot faster !!! :D "
(taken from another thread)

After the exams, I know what to test!
(the Curve modulation that is ! ;)
Hahaha!

stax76
26th January 2003, 02:24
now i hope that a new version of GK will be out quick


because GK uses mime encoded strings, a new codec version
is always a problem. There is a GKnot similar tool with
support for DivX 5.03 incl. multi pass support, the program has
more then 20 dialogs and supports everything that can be done
manually. You just type in how many passes you want. It works
with the original codec dialog, you can invoke the original
codec dialog for the first, the second and multi pass and for
the credits, no need for jobs at all, the latest beta version
can be found here (http://www.planetdvb.net/board/index.php?act=ST&f=22&t=31&st=75)

'Dolemite

leadman584
26th January 2003, 02:51
I have tried to get into the Divx Forums to post these comments, but it is either down or blocked. I just loaded the new codec and experimented some. Obviously these are merely first impressions.
I still use Avisynth 2.07, till Wednesday or Thursday anyways, after the more stable build of 2.5 is posted at the Avisynth site. Also still using VDub 1.14.13 P4, at least till I get a stable build of Avisynth 2.50, then off to VDubMod.
I attempted a 5 pass encode with Divx 5.03Pro(don't ask), The last pass #5 would not complete due to missing Index blocks. I muxed the audio into the video from pass 4 and it is incredible. My settings were as follows: resolution 512x384(kinda a pain to type these in every pass, framerate 29.97, though input to 30fps in Divx. bitrate selected was 905. final filesize for a 8:22.8 clip was 62.7MB, including mp3 cbr 128 track. The results were very nice. Tried a 1 pass with max q, and the final filesize using the same .avs file was 118 MB, again including the same mp3 track. There was very little noticeable difference between the 2 files. Mostly artifacts around print.
The most annoying part of this encode was confirming the overwrite to each dix logfile, every single darn pass. Gotta be a better way, I'm sure one of the encoding masters will enlighten me on this point.
For me each pass encoded around 32 fps, but with 5 passes almost, that's still gonna take awhile. I suppose I should be happy that it's not as slow as an H264 encode. The divx logfile showed every other frame as a B frame, you don't notice it, I've tried.
The new Divx player looks very nice, makes my old encodes look better in playback (with post processing settings at max). You still can't seek in a video that used Nandub to mux CBR MP3 audio track. The WEF will definitely need to take a look at this newest release by the folks at DXN. I'm sure I screwed up somewhere with the last pass(I hope). The lack of GMC or Q-pel in supported modes does not seem to degrade the Video at all. I'd be interested to hear from other folks that have tried this new Divx release, but from what I've seen so far, Xvid has some competition again(I've used Xvid for the last coupla months, looks like it's back to Divx, maybe).

smok3
26th January 2003, 02:56
ok, iam testing the interlaced input, i tryed almost everything so far, it does not look that it is recognized by the encoder and marked such for the decoding process (just a plain ntsc interlaced feed, no resizing, and i try to swap field priority also), any ideas on how should that work?
tia :D

edit: ok i think i got the idea, things should stay interlaced no-matter if played on computer screen or tv :rolleyes:

Snollygoster
26th January 2003, 03:11
Originally posted by leadman584
The most annoying part of this encode was confirming the overwrite to each dix logfile, every single darn pass. Gotta be a better way, I'm sure one of the encoding masters will enlighten me on this point.

Just click "Do Not Prompt With Errors and Warnings" on the DivX 5.03 encoding tab...

leadman584
26th January 2003, 03:45
Thanx gotta set of VOB's to try this new codec on a full feature.

dTb
26th January 2003, 04:51
Won't get to test this for a few days, maybe that's a good thing, wait till there's a bit more feedback.
The divx forum does seem to be down atm, they upgraded yesterday, I was able to get on and post but there were a few bugs. Maybe not such a good idea to update the forum and release a new divx version at the same time.
To people wondering about the adware version, atm it is temporarily unavailable to some countries for some legal reasons. Someone gave me a link for it on a google cached page, I'd never heard of this but I'm sure many of you will know what to do.

PkmoNk
26th January 2003, 05:00
I think I caught a bug or something.

I encoded some music videos @ 1-pass batch.
Some sync properly while, while some gets asynced, and while comparing it to the original, the avi video seems to be ahead of the mpeg video.

Does anyone know why this happens? and how to fix it?

Rash
26th January 2003, 06:23
Just a stupid question. If you don't set how many times you want Nth Pass to encode, then how does the encoder know which is the last pass to actually create the video file? Or it simply keeps creating real video files and you have to keep overwritting them?

Sorry, I just haven't downloaded the 5.03 yet, just curious. :)

Snollygoster
26th January 2003, 06:26
Yup it overwrites every file after the 2nd pass...

WRFan
26th January 2003, 07:02
I wonder if they even tested the package properly before releasing it. The decoder can't be configured, it resets itself every time

yeah, the divx people get on my nerves, the forum and forum registration don't work properly and such stupid bugs in the programme. I found out that one can set the decoder settings by starting the windows media player classic, starting a divx file in the player and then go to properties and from there start the decoder settings. then I set them and clicked ok, and they were set. but when using the decoder settings programme directly, the settings used to reset themselves. and I can't start the registration dialogue - before it started and said something like "you are already registered, do you want to reregister?" but now it doesn't start at all. the programme itself is however registered, I have no problems with encoding, so that doesn't matter that much, just shows that there's something wrong with the divx team's heads. updating their forums when a new version comes out, what a "good" time for that!

dTb
26th January 2003, 07:36
I was just running a small test and I realised something, the nth pass is essentially the same everytime. Maybe this is already implemented in virtualdubmod, if not they should implement a feature to copy the nth pass job in job control. Instead of repeating the same steps n number of times you could just copy and paste the number of nth jobs you want. :cool:

I was also thinking about the gknot compressibility test, for the time being I suppose manual tests are the only way to go using the same 2-pass first pass method that was used previously. I might give the multipass first pass a try and see if it works.

Atlantis
26th January 2003, 11:21
Ok nobody has mentioned this. Have you noticed? Every time I play a Divx file, the decoder shows a Divx logo for a few seconds at the beginning. It’s very annoying. ---(Edited)

bond
26th January 2003, 11:27
You can turn the display of the logo on or off in the codec properties dialog.

Atlantis
26th January 2003, 11:28
Ah Thanks!

n9801904
26th January 2003, 13:10
I really don't get the version numbering they are using! Surely that last digit should be used for big fixes and the second digit for new features. Not that it makes any difference (a rose by any other name... ;)

Shouldn't this be DivX 5.1.0 and then, when the bugs are fixed they could release 5.1.1, 5.1.2 etc..

Snollygoster
26th January 2003, 14:25
Originally posted by WRFan
yeah, the divx people get on my nerves, the forum and forum registration don't work properly and such stupid bugs in the programme. I found out that one can set the decoder settings by starting the windows media player classic, starting a divx file in the player and then go to properties and from there start the decoder settings. then I set them and clicked ok, and they were set. but when using the decoder settings programme directly, the settings used to reset themselves. and I can't start the registration dialogue - before it started and said something like "you are already registered, do you want to reregister?" but now it doesn't start at all. the programme itself is however registered, I have no problems with encoding, so that doesn't matter that much, just shows that there's something wrong with the divx team's heads. updating their forums when a new version comes out, what a "good" time for that!

If you open any player eg: ZoomPlayer and you configure the decoder in there it will keep its settings ;)

WRFan
26th January 2003, 14:41
Originally posted by Snollygoster
If you open any player eg: ZoomPlayer and you configure the decoder in there it will keep its settings ;)

yes, that's what I said in my post above: setting the settings in windows media player classic works, but not in the standalone programme. the disadvantage is of course you have to have a divx file on your harddisc to play so that the settings dialogue becomes accessible in the player. but it's kind of annoying to start the player every time one wants to change settings. I use wmp 9 for playback and one can't access the divx settings from there. meaning I have to start the other player just for settings change. hope the divx people fix this bug soon.

another question: are the Quarter Pixel & the GMC greyed out in your settings? because they are on my pc, and I have no idea why. Bi-directional Encoding is accessible, but not the other two.

Garfield
26th January 2003, 14:46
I'm a little bit lost with this new release and what have been said here, can we use the Nth pass efficientely or not ?

Snollygoster
26th January 2003, 15:32
Originally posted by WRFan
another question: are the Quarter Pixel & the GMC greyed out in your settings? because they are on my pc, and I have no idea why. Bi-directional Encoding is accessible, but not the other two.

1. Media Player 9 Sucks

2. If you read the beginning of this post you will see that if you unclick the DivX profile in the last tab the Qpel and GMC will become available again. They are disabled by default for ISO complian issues with hardware manufactures.

Stigma
26th January 2003, 15:53
When i try to encode with multipass my video ends up looking like i encoded it with waaaay to low bitrate (but i didnt). I havent been ableto figure out why yet. N'pass - 1'st pass, then 2(or more) N'th pass. The result is allways the same.

Also 2 other things im wondering about. If itry to encode very short clips (only a few seconds) then i get a black screen to start with (1-3 secs).

And if i want to encode with B-frames, then why cant i select them on when i do the N'passes? they are grayed out... i know ican disable the profile, but it shouldnt be nessecary right? If i disable the profile and encode within the restrictions of that profile with only B-frames it should be allright no?

-Stigma

jonny
26th January 2003, 15:59
dTb:


I was also thinking about the gknot compressibility test, for the time being I suppose manual tests are the only way to go using the same 2-pass first pass method that was used previously. I might give the multipass first pass a try and see if it works.


You can't, log file generated by "multipass first pass" have a different format.

Dark-Cracker
26th January 2003, 16:56
and normaly the compressibility test use min & max quant @ 2, and u can't adjust quantizer in divx 5.0.3

Sirber
26th January 2003, 23:38
Compared to XviD-dev for two pass, XviD produce sharper image, with less macro-blocks and ringing effect. Also, in the DivX clip, GMC + QPEL + BF is mad with black screen and produce wierd contrast.

Iznogoud
26th January 2003, 23:47
@Dark- Cracker

"u can't adjust quantizer in divx 5.0.3"

there is "1-pass quality-based" option like in 5.02, u can select q 31-2.

jonny
27th January 2003, 02:16
You can adjust this with CLI config, anyway the log generated by original first pass seems to be changed too :(

I can suggest you a manual method for now:

1 - Check "Compressibility Check" in GKnot and save your avs file.
2 - Open the avs file in VDub, select 1-pass quality based and set the quantizer to 2 (set the other options as you want)
3 - Open the avi file, go to File > File Information
4 - Take a look at the column "Min/avg/max/total delta frame size", take a note of the "avg" value.
5 - Multiply "avg" by the total number of frames, so you have the "predicted size" at quality based 100%.
6 - Take a note of the "Video Size in KB" in Gknot (you must multiply this value by 1024 to obtain the size in bytes).
7 - 100 * "Video Size" / "predicted size" is an approximation of the comp.test value...

I have not tested the method but should work (if you like to do some math :))

This method is not 100% accurate with b-frames enabled.

Thanks goes to Elia for this nice manual method (that work with every codec)! ;)

jarthel
27th January 2003, 02:40
I just encoded a dark anime (Boogiepop Phantom) and a colorful one (Rurouni Kenshin). I tried both encoding with QPEL and without.

QPEL encodes is bigger. But the most amazing of all is that the new encodes of the Boogiepop Phantom are 2 to 3 times larger than the one encoded by 502. I was randomly viewing the frames in vdubmod and I didn't see any difference for such a huge filesize difference.

also, 503 is about the same in terms of speed as with 502.

one word to describe 503 for me -->> disappointed.

danwatt
27th January 2003, 06:41
Here are my test results: I encoded the menu-loop VOB from The Matrix (VTS_02_0.vob) which is about 5 minutes long. I did 8 passes at 600k at 720x400 (nearest res to the aspect ratio that meets 16x16 block requirement). I have done several tests, including using "Constant quality" versus "High modulation".

My method : import the two versions into After Effects, perform a difference on the two videos, and boost the levels to see where the differences occur.

I took samples at 2, 4 and 8 passes for "Constant quality", and compare them to the original and then compare the passes against each other. It would seem that there are significant changes between 2 and 4, though there are a few scenes (generally right after areas where key frames were present and motion wasn't too high). Between 4 and 8, however, there were more scenes with little difference between them. 600k is rather low given the high motion nature of the video, but it did bring out how the motion does change the final result in n-pass mode. Results summary: 4-5 passes seem to be enough, but it would appear that going higher does still "change" the video (though visually, its hard to tell the difference without doing some image math in a program like After Effects).

As for constant vs high modulation : (after 5 passes on both sides) it would appear that the high modulation pays more attetion to blocks with moving edges. There were numerous frames that had about 25% of blocks that were identcal between the two, but blocks that had the most change (when you see image diference, it looks more like noise) were most definately edges (around people).

Either way, I don't think the human eye, unless the video is zoomed in, can distinguish between higher passes. It seems like a waste to do 8 passes and get about half of the video a bit closer to the original, and by that I mean a random pixel is 1-5% closer to the original. You just cant visually tell the difference. My advice would be to do 3-4 passes, if you have the CPU power to spare, and to use the high modulation settings. I have yet to test the low settings for "moving head" type movies (where the background pretty much stays the same), but for most movies, you probably would not want to go that way anyhow.

Please, someone who is not in college, do some more testing on the differences between the # of passes. I'm sure you can mathematically prove (at least, moreso than I have) that there is a limit to the number of passes. My advice in testing is not to perform a visual difference between the two, but a mathematical difference.

DarkBahamut
27th January 2003, 07:56
Originally posted by Snollygoster
Yup it overwrites every file after the 2nd pass...

Wouldnt that keep doing the 2nd pass over and over again?

maormini
27th January 2003, 08:33
I have just encoded "Saving Silverman" in both 5.0.2 two pass and 5.0.3 five pass, the results were very dissapointing!

The 5.0.2 encoded movie had less artifacts and ringing around objects and the movie looked better overall.
The bitrate that I used for both codecs was 1440kbps and the resolution 512x272, used GMC & B frames NO Qpel.

I will try the codec with a different movie but for now my conclusion is to stick to 5.0.2 till they address the problems brought up here in the forum.

cordraconis
27th January 2003, 08:44
Very good! I knew there are programs to "see" the difference between video files, but I didn't think of it. Your way is more objective than staring at the same scenes over and over again, with your nose on the screen :D

I'm also pleased that my suggestion of not going over more that 5 passes, proofs correct. (Mathematicly spoken.)

Keep us posted about the results of you low-modulation tests.

Originally posted by danwatt

Please, someone who is not in college, do some more testing on the differences between the # of passes.

Yeah, rub it in ... :rolleyes:
(Bl**dy exams ... :D )

LeonMcNichol
27th January 2003, 10:16
I did some quick testing of the codec and compared it to the others. I must say, I'm not pleased with it. I did some screen captures with virtualdub. GeoCities (http://www.geocities.com/overpowerfreak/divx503_test/test.html) Homestead (http://chiefinspectorleon.homestead.com/files/test.html)

I was shooting for the same size and not the same bitrates. This was the bitrates and sizes for each of them w/o sound.

DivX5.0.3 Pass 02 - 832Kbps @ 9,594,880 bytes
DivX5.0.3 Pass 10 - 832Kbps @ 9,590,784 bytes
XviD 2 Pass - 843Kbps @ 9,721,856 bytes
DivX3 SBC - 815Kbps @ 9,398,272 bytes

[Edit] Bugger Geo... Let's see how homestead does... I would use my main site, but it seems to be having ftp problems and of course keenspace got hit by that worm thing... *sigh*

seewen
27th January 2003, 14:24
Originally posted by LeonMcNichol
I did some quick testing of the codec and compared it to the others. I must say, I'm not pleased with it. I did some screen captures with virtualdub. GeoCities (http://www.geocities.com/overpowerfreak/divx503_test/test.html) Homestead (http://chiefinspectorleon.homestead.com/files/test.html)

I was shooting for the same size and not the same bitrates. This was the bitrates and sizes for each of them w/o sound.

DivX5.0.3 Pass 02 - 832Kbps @ 9,594,880 bytes
DivX5.0.3 Pass 10 - 832Kbps @ 9,590,784 bytes
XviD 2 Pass - 843Kbps @ 9,721,856 bytes
DivX3 SBC - 815Kbps @ 9,398,272 bytes

[Edit] Bugger Geo... Let's see how homestead does... I would use my main site, but it seems to be having ftp problems and of course keenspace got hit by that worm thing... *sigh*

It's very strange.. I nevers saw such an horrible result on an Anime with a bitrate of 850 ( I think that the Resolution is less than DVD-res ? )...

And DivX 3.11 gives better result than DivX 5 PRO... And better result than XviD ???

Sorry, but I find that something is really strange in this test.. ( maybe I'me wrong.. But it's the first time since month that I see DivX 3 giving better result than XviD/DivX5 ;))

danwatt
27th January 2003, 19:39
The method (for those who want to do it)
Extract certain frames from the video. You can do this manually in VDbub, or I did it in Bink (www.radgametools.com), which can script what frames to extract) so I could script it from each file. Then, perform a "difference" against the original (either in Photoshop, by layering one on top of other and setting its layer to "difference", or by the use of ImageMagick, a command line tool, that can be scripted). Then boost the levels (I did this in Photoshop, the ImageMagick tools didn't give me the options I wanted), I did 0,1.00,10 (0 black, 1.00 gamma, 10 white) on the input levels. Alternatively, you can just import the two video clips you want to compare into After Effects (or similar program), put one on top of the other, and set is mode to "difference", then put a new ADJUSTMENT layer on top of the other two, and give it a levels effect (same settings as in Photoshop).

The more brighter the resulting pixles, the more different they are from the original. Remember, levels are boosted significantly so you can actually see the changes, otherwise they are hardly visible. Black pixels indicate a perfect match, and at the levels we are talking about, there should be no colors NEAR black. If it looks black, then it is black, and you have a perfect match.

I will be posting frame grabs later once I test low modulation.

Kent Wang
27th January 2003, 20:06
Does nth-pass allow for more accurate filesizes too?

danwatt
27th January 2003, 22:27
At 600kbps, pass 2 comes out to 20652kb for low modulation, while after 8 passes it comes out to 20580. For regular modulation, 20644 vs 20588. For high modulation, 20630 to 20584 (and just for note : 6-8 have the same size). Conclusion (from this test, at least)? N passes doesn't really do anything for the filesize, since the difference is far less than 1%. What needs to be tested is 5.0.3 vs 5.0.2, which I think someone else on the forum has already done.

leadman584
27th January 2003, 23:08
I noticed something kinda weird on an encode with Divx Pro 5.03. I did a 5 pass on a 94 min. movie at 887 kbps. The size of each video file was virtually identical in size from pass 2 to pass 5. The strange part was that if you use any player other than Divx on highest settings, you can actually make out each macroblock during a camera movement, with any other player. Well I only tried WMP, and Zoomplayer. Just seemed weird, wonder if anybody else has seen this, or is it just me.

danwatt
27th January 2003, 23:57
Ok, I have some sample images, as 24bit PNGs as to retain full quality.
#0 : Original frame (1968, of VTS_02_0.VOB from The Matrix (the VOB that contains the menu loop))
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_orig.png

#1: Visual comparison of 4 modes
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_4_2_low_high.png
#2: Difference of each mode versus the original frame (instead of boosting levels, I set contrast to 100%, which still is probably not the correct way to do this)
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_4_2_low_high_diff.png
#3: Composited differences of each mode versus the others (black = the same)
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_4_2_low_high_compare.png
#4 : Take the left part of 3, move over the right, and do a difference
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_left_vs_right.png
#5 : Take the top part of 3, and move over the bottom, and do a difference
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_top_vs_bottom.png

Comments:
#4 : Notice that there are several regions that are the same for left vs right

#5 : since everything is black (with the exception of my text overlay), the output is actually the same. What this means: the difference between 4 pass, high and low, is the same as the difference between high, pass 2 and 4. Which means, that 4 passes in low would be the same as 2 passes in high. I am seriously doubing this is true, and I have a feeling that the method of boosting levels that I am using is causing some precision problems later down the line (doing 8 bit math over and over again results in fine details being lost).

#6: Comparison of pixels between pass 4 and pass 2
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_4_2_high.png

#7: Comparison of pixels between pass 8 and pass 4
http://xco.cs.uiuc.edu/Members/danwatt/divx/1968_8_4_high.png

Due to the nature of the "difference" mode, this also means that if we take the top part of #4 and move over the bottom part, it's result is also black (I did not bother to post a pic). Again, somehow I seriously doubt my results here.

#6 and 7 : Some weird things seem to be going on in extended passes. I tried comparing pass 8 to passes 5-7, and there were no differences. It would appear that after pass 4, for this frame, it locked on to a quant value. I am a little confused why the upper right and upper left changed, since these are really low motion areas.

I am actually taking a course in computer graphics (I am a CS major) dealing with both 2D and 3D image processing, so if I find some time this semester I might actually write a program to do a more accurate comparison of the different modes.

Hope this is informative to some of you, maybe it will help form the basis of better quality comparisons.

Rash
28th January 2003, 00:04
Originally posted by leadman584
I noticed something kinda weird on an encode with Divx Pro 5.03. I did a 5 pass on a 94 min. movie at 887 kbps. The size of each video file was virtually identical in size from pass 2 to pass 5. The strange part was that if you use any player other than Divx on highest settings, you can actually make out each macroblock during a camera movement, with any other player. Well I only tried WMP, and Zoomplayer. Just seemed weird, wonder if anybody else has seen this, or is it just me.

That is because the Decoder Settings doesn't change the Quality Level. DivX Player does and its default is higher than DivX's. So when you play anything on WMP or any other and on DivX Player, the difference is clear. I posted a thread about this here in this forum.

EagleDM
28th January 2003, 01:36
The DECODER config that comes with the Divx 5.03 package is BROKEN, no matter what YOU DO, it WILL switch back to default (3 lines) instea of FULL postprocessing.


I found the solution.


Use BSPLAYER, open a Movie and then go to the BSPLAYER menu and choose Properties, then select the DIVX Codec and the SAME DECODER window will open, now Choose MAX postprocessing, click apply, now close bsplayer.

Now, the next time you open up the Decoder Options it will stay at the MAX postprocessing level, and of course, WMP and ANY other player will stay on the MAX postprocessing level.

This is because the Decoder Configuration windows DOES NOT change the decoder Postprocessing level, but, if you INVOKE this window from inside a player it will update properly.


I hope this helps with all the 'decoding' problems.

I was thinking the Encoder was 'wrong' in the first place till I found this SERIOUS BUG.

Ecuador
28th January 2003, 01:57
Even if it is during my exam period, I couldn't resist doing my own tests with the n-pass encoding. I only tried one movie (Final Fantasy selected scenes @ 600kbps B-frames but no GMC, Qpel), at 2,3,4,5 passes (n-pass mode) as well as the old 2-pass method.
I don't have time for uploading the screenshots, but I thought I would share my opinion anyway.
So, I must say that in almost every scene I found the 2-pass result in n-pass mode to be inferior to the old 2-pass method! The difference was becoming clearer in fast and complex scenes, with more blocks and artifacts.
On the other hand, the 3-pass result of the n-pass method was slightly better than the old 2-pass method, especially in scenes with clouds, transparencies, etc. From then on, 4th and 5th passes provided almost identical results when compared to the 3rd pass.
Of course, this is just one movie (and a rather unusual one), but it has quite demanding scenes, and I happen to like it...

dTb
28th January 2003, 03:27
Originally posted by jonny
You can adjust this with CLI config, anyway the log generated by original first pass seems to be changed too :(

I can suggest you a manual method for now:

1 - Check "Compressibility Check" in GKnot and save your avs file.
2 - Open the avs file in VDub, select 1-pass quality based and set the quantizer to 2 (set the other options as you want)
3 - Open the avi file, go to File > File Information
4 - Take a look at the column "Min/avg/max/total delta frame size", take a note of the "avg" value.
5 - Multiply "avg" by the total number of frames, so you have the "predicted size" at quality based 100%.
6 - Take a note of the "Video Size" in Gknot.
7 - 100 * "Video Size" / "predicted size" is an approximation of the comp.test value...

I have not tested the method but should work (if you like to do some math :))

This method is not 100% accurate with b-frames enabled.

Thanks goes to Elia for this nice manual method (that work with every codec)! ;)

Thanks for this jonny, I've just had a go at it. At point 7 should that be 1000 instead of 100?
I've gone through this once so far:
Avg Delta Frame = 11,589
Total # frames = 111,424
Predicted size = 1,291,292,736
Video Size = 640,207KB
Final Value = 0.0496
Final Value if 1000 instead of 100 = 0.496

Now the second value seems more like a usual comp test value to me, I have to admit however that I get a bit confused working in Bytes, Kilobytes etc. Maybe it should be 1024 instead of 100 with a final value of 0.508.

Any help would be appreciated.

LeonMcNichol
28th January 2003, 05:14
Originally posted by seewen
It's very strange.. I nevers saw such an horrible result on an Anime with a bitrate of 850 ( I think that the Resolution is less than DVD-res ? )...

And DivX 3.11 gives better result than DivX 5 PRO... And better result than XviD ???

Sorry, but I find that something is really strange in this test.. ( maybe I'me wrong.. But it's the first time since month that I see DivX 3 giving better result than XviD/DivX5 ;))

Yes, I found it strange too and did another test, this time no filters and no b-frames. So I believe that it is infact the b-frames which made such a shitty encode. This was the first time I've ever encoded with b-frames and will probably not again.

Click Here For The New Test! (http://mysite.verizon.net/res0xeep/test.html) (This time on my ISP's site.)

As you can see, I think I've messed up my XviD settings somehow, other than that, divx5.0.3 did great! I'm switching back from XviD to it again.

midiguy
28th January 2003, 08:42
I haven'ty actually tested the codec yet, but I did look at the encoder GUI, and noticed something that was not yet mentioned on this forum... when you activate "Multipass, nth pass" an option pops up inthe log file section, called "Update log file". by default, this is not checked. did any of you leave this unchecked by any chance? I am tihnking that if you don't check this, the encoder is assuming that the current pass is the final pass, and there is no need to update the log file... but let's say you do a 5 pass encode, and do not check that "Update log file" box on any of your passes. I am tihnking the encoder would do something like this:

1st Pass: does first pass
2nd Pass: does second pass
3rd Pass: does second pass again
4th Pass: does second pass again
5th Pass: does second pass again

correct me if I am wrong?

seewen
28th January 2003, 09:18
Originally posted by midiguy
I haven'ty actually tested the codec yet, but I did look at the encoder GUI, and noticed something that was not yet mentioned on this forum... when you activate "Multipass, nth pass" an option pops up inthe log file section, called "Update log file". by default, this is not checked. did any of you leave this unchecked by any chance? I am tihnking that if you don't check this, the encoder is assuming that the current pass is the final pass, and there is no need to update the log file... but let's say you do a 5 pass encode, and do not check that "Update log file" box on any of your passes. I am tihnking the encoder would do something like this:

1st Pass: does first pass
2nd Pass: does second pass
3rd Pass: does second pass again
4th Pass: does second pass again
5th Pass: does second pass again

correct me if I am wrong?

You are right, of course.

But I didn't even thought that "testers" could have forgottent to check this option ;)

jonny
28th January 2003, 09:50
I've gone through this once so far:
Avg Delta Frame = 11,589
Total # frames = 111,424
Predicted size = 1,291,292,736
Video Size = 640,207KB
Final Value = 0.0496
Final Value if 1000 instead of 100 = 0.496

Now the second value seems more like a usual comp test value to me, I have to admit however that I get a bit confused working in Bytes, Kilobytes etc. Maybe it should be 1024 instead of 100 with a final value of 0.508.


640,207KB = 1,024 * 640,207 bytes = 655,571,968 bytes

100 * 655,571,968 / 1,291,292,736 = 50.77 < this is the comptest value :)


(Generally: 1MB = 1024KB = 1024*1024 bytes)

LeonMcNichol
28th January 2003, 12:35
DivX5.0.3 has a horrid problem with B-Frames. It encodes shit... Seriously, I'm getting those God aweful blocks that was in my previous test. There is something wrong. Look:

http://mysite.verizon.net/res0xeep/images/b-frames.jpg

Can someone else test and confirm this? This is terrible. I never worked with b-frames before, so I don't know if the previous 5.0.2 had this problem. So I'm not sure if it's a bug in the latest build. All I know is, no B-Frames for me.

seewen
28th January 2003, 14:18
Originally posted by LeonMcNichol

Can someone else test and confirm this? This is terrible. I never worked with b-frames before, so I don't know if the previous 5.0.2 had this problem. So I'm not sure if it's a bug in the latest build. All I know is, no B-Frames for me.

Sincerly I cannot make any differences between 5.0.2 & 5.0.3 ( ALways use B-frames, Never GMC/Qpel ).

And the quality is really "perfect", meen as good as XViD ( Posting Captures-screens won't be very usefull in this case ;) ).

The last movie I've made is AVALON ( but I've made 3-5 others with 5.0.3) :
Bitrate 876, resolution 640x352, 2-pass ( "multipass, 1stpass" + 1x "Multipass, Nthpass" ), with B-frames,bitrate modulation -0.1 , Avisynt 2.5 ( FastBicubicResize, Undot, aSharp. No other filters ).

And I've made a comparison with DivX 5.0.2, and it's impossible to say that there's a difference.

maormini
28th January 2003, 14:38
I did another comparison between 5.0.2 to 5.0.3 this time I raised the bitrate to 1800kbps hoping not to see such a big difference, but again the results were very dissapointing!

The 5.0.2 was made in 2 pass + B-frames + GMC the 5.0.3 was made in 6 passes + B-frames + GMC! The filesize calculated was to be 1340MB.

The results were as following:

5.0.2
Size: 1240MB
Quality: Excellent.
Ghosting, Artifacts, Blocks: Minimal, almost unnoticable.

5.0.3
Size: 1350MB
Quality: Good.
Ghosting, Artifacts, Blocks: No blocks, a lot of artifacts and ringing around objects, picture was sharp but had some noise.

My conclusion for now is that 5.0.3 is more accurate getting the filesize (5.0.2 peeks to fast!) but manufactures unexplainable noise and artifacs in the picture.
Sorry I don't have any screenshots for you!

For now I am sticking to the good ol' 5.0.2!

midiguy
28th January 2003, 15:14
Originally posted by maormini
My conclusion for now is that 5.0.3 is more accurate getting the filesize (5.0.2 peeks to fast!) but manufactures unexplainable noise and artifacs in the picture.
Sorry I don't have any screenshots for you!

For now I am sticking to the good ol' 5.0.2!

looks like there is a b-frames problem in 5.0.3.

midiguy
28th January 2003, 15:20
I don't understand how the people from DXN could miss such a HUGE bug (again!).

OvERaCiD23
28th January 2003, 18:42
I haven't done any n-th pass encodes, but 1-pass quality based Q2 is vastly imrpoved. With 5.0.2, macroblocks would still exist on solid objects (walls and such). I couldn't find any very noticeable blocks with 5.0.3 (movie was 'Vulgar', a Kevin Smith movie). This movie had a bit of noise as well, and I used FluxSmooth to remove it. Usually noise and solid colored walls = annoying blocks, but no. I am going to watch it through to ensure it's not buggy anywhere, especially since I used b-frames. I've also done 'The Good Girl', and it's just finishing up so I'll see how that went as well.

Rash
28th January 2003, 23:21
Hey people I'm sorry but, what program are you using to view your videos? Don't forget that, unless you find a way of getting that damn Quality Level bar to max on Decoder Settings, your image quality will be awful on any program you use to view your encoded videos. Don't forget DXN default is too low.

Like I posted in this forum already, I felt a great difference in image quality by comparing the same video on WMP and DivX Player. This difference is not so noticeable on 5.02 videos, but it's quite annoying on 5.03 videos. ;)

BoNz1
29th January 2003, 00:13
I disagree, you do not need to turn up the quality bar, if the movie is encoded properly, you don't need any postprocessing or at least very little or else it will blur it. And when you are testing the codec try to turn off all postprocessing otherwise you may not get an accurate idea of how it is actually performing. As for postprocessing, most of my movies look worse with it even 5.03 encoded ones, but some is acceptable for low bitrate movies and poorly encoded movies. That said they should fix the bug that doesn't allow you to adjust the postprocessing.

movmasty
29th January 2003, 00:44
divx postprocessing is very good, and can also fix bad encoders,

if you have a fast enough cpu, will make playing a 640xxx video better enlarged on a 1280 screen than untouched on a 640 screen.

It is a must when a movie needs always to be resized when played, when the res is under 576,
a little video at 512xxx looks very good on a 1024 screen.

i recently tried to encode Woody Allen's piking up pieces at 800x432,
to play it with a monitor res of 800x600,but encoding it at 768x416 and playng at screen res of 1152,an almost round ratio of 1.5, gives better result

Rash
29th January 2003, 01:27
@Bonzi

I only mentioned that because of this line on "What's New" on 5.03
"New de-ringing post-processing algorithm. The new algorithm improves the perceived video quality during playback. It is activated when the post-processing level is set to Level 6."
http://www.divx.com/divx/divx_win_versions.php (second dot)

In fact I could see a great difference, mainly in the ringing effect (the one that annoys me most), by setting the post-processing to max. So, to me, it seems that the 5.03 encoder leaves a lot stuff to the post-processing.

dTb
29th January 2003, 02:33
@jonny, thanks a lot :D pretty simple really.

About post-processing, I agree with BoNz1. If you have a high quality encode post-processing can smooth out some detail. It is very good however on low quality video and if you can't stand ringing like Rash then definately use it.
Personally, if you're comparing codecs I think it's best not to use any post-processing or at least make comparisons with and without.

I've encoded one movie so far using nth pass and I'm pretty happy with it. Virtually every second frame is a b-frame and I'm not getting anything like LeonMcNichol's problem.

BoNz1
29th January 2003, 03:48
@Rash, I do agree in a poorly encoded low bitrate movie postprocessing is advantageous, I too would like to see what the new de-ringing can do even though I might rarely if ever use it.

LeonMcNichol
29th January 2003, 04:34
Originally posted by dTb
I've encoded one movie so far using nth pass and I'm pretty happy with it. Virtually every second frame is a b-frame and I'm not getting anything like LeonMcNichol's problem.

Really? Have you tried comparing it to a non b-frame encode of the exact thing? Compair frames, like I have done?

dTb
29th January 2003, 04:52
Sorry, it's too late for me now to encode the same movie without b-frames. I'm gonna start on a new one now so I'll try encoding a section with and without.
Maybe the problem has to do with anime, what I've done so far has been with live action movies.
There is something drastically wrong in your screen grabs, are the bottom two actually b-frames or is it something thats affecting the other frames as well.
I assume you know a b-frame will always have double the quantizer of the adjacent frames, I don't think this explains your prob however.
I don't compare frame to frame much because afaik it's not a very good method for camparing quality.

LeonMcNichol
29th January 2003, 06:09
Originally posted by dTb
Maybe the problem has to do with anime, what I've done so far has been with live action movies.
There is something drastically wrong in your screen grabs, are the bottom two actually b-frames or is it something thats affecting the other frames as well.

I don't know if they are actually b-frames... I already deleted the sources. I know this sort of horrid stuff was all through it though. It really was bad. I don't know if it's just anime or what, but I don't like this. I'm at my mom's now and don't have access to my computer or dvds, so testing has haulted 'till I go home Thursday. (This computer is slow... 1/2 the speed of mine.)

I did however encode before I left (while I was sleeping), Area 88 episode 1 w/o b-frames. I must say, I'm quite pleased at the results. It was a 50 minute episode and I was shooting for 350mb OGM file. (2 audio with srt subtitle.) Ended up 1mb over (351) because I calculated the audio wrong. (I encoded the dubbed first to ogg and just a-sue-me-d that the japanese would be the same size. Normally it is, but this time it wasn't.) It compressed very well for the bitrate and resolution. (512x384) Artifacts were almost non-existant. (I supposed this could have something to do with the anime.) So I'm quite pleased with DivX5.0.3 w/o b-frames. I should test a live action movie with b-frames to see if I get the same problem. Maybe my version is busted... But I'm not the only one reporting a b-frame bug.

dTb
29th January 2003, 06:58
Something that's occured to me is whether you're using the profiles or not. So far I have been using the high quality profile.

SiXXGuNNZ
29th January 2003, 07:20
I made a divx 3.11 of chapter 15 of the matrix, it looked better then a 10-pass with 5.03

LeonMcNichol
29th January 2003, 07:53
Originally posted by dTb
Something that's occured to me is whether you're using the profiles or not. So far I have been using the high quality profile.

It was the home theater profile. You know, the "default" setting.

@SiXXGuNNZ

Try turning off b-frames and do the 10-pass thing and compair the b-frames to the non b-frames. I was getting that too, when it comes to b-frames on. DivX3 was giving a lot better results.

N_F
29th January 2003, 11:40
I did my first test yesterday (hadn't time to do it earlier). These are my conclusions from comparing frames in AVSCompare:

2 pass-encoding 5.02 vs. 2 pass encoding 5.03

5.02 will give a slighty better picture on some frames, but 5.03 will give a considerably better overall picture, especially on bad frames with a lot of blocks.

2 pass-encoding 5.03 vs. 8 pass encoding 5.03

On a blind test I find myself prefering different encodings depending on the frame but the difference is only marginal.


In general the difference between 2 pass-encoding 5.02 vs. 2 pass encoding 5.03 is much bigger than 2 pass-encoding 5.03 vs. 8 pass encoding 5.03 IMHO. This was at least the results from some random frames in a 3 minute clip. But unless some further tests show very different results I'm not likely to use more than 2 passes.

A lot of people seems to have very different opinions on this subject.

maormini
29th January 2003, 13:23
Hi!

I have done some more tests between the codecs, I wan't to share some of the screenshots. The problem is, I need to know how to get good screenshots and where can I store them for you to see?

Anyone?

hakko504
29th January 2003, 13:31
@maormini

Screenshots: Open the final AVI in VDub(Mod). In the video menu you will find the option 'Copy source to clipboard'. Then paste it in any image-editing program you happen to have lying around, like M$Paint, M$PhotoEditor, Photoshop,...

Where to put them: If you only want to put up a single frame from two different encodes the you can attach them to posts here, but we will not allow large bmp files. I recommend a webhosting service like geocities or fortunecity.

seewen
29th January 2003, 15:59
And a way to compare difference between 2-pass & 10-pass ( for example ), is to use "Subtract()" cmd in Avisynth.
( I don't know if it works for Avisynth 2.0x.., but it should )

For example :

clip1 = AviSource("X:\Folder\2-pass.avi")
clip2 = AviSource("X:\Folder\10-pass.avi")

Subtract(clip1,clip2)

But it's often too difficult to see differences. So you can apply the "trick" of Avisynt documentation :

clip1 = AviSource("X:\Folder\2-pass.avi")
clip2 = AviSource("X:\Folder\10-pass.avi")

Subtract(clip1, clip2).Levels(127, 1, 129, 0, 255)


And so you will see that a lot of frames are 100% identical, and others are identical by 90%, etc..

I was surprised to see the differences between passes. Some frames are identical but the man running in the center of the screen wasn't.

A+ ( and I really don't see "bug(s)" with B-frames.... For me 503 is more pleasant than 502.)

Subtract help : http://www.avisynth.org/index.php?page=Subtract
Compare help : http://www.avisynth.org/index.php?page=Compare

Karl Beem
29th January 2003, 16:22
Originally posted by N_F
I did my first test yesterday (hadn't time to do it earlier). These are my conclusions from comparing frames in AVSCompare:


AVSCompare?? Where can I find it?

manono
29th January 2003, 17:26
Hi-

Download And Discussion of AVSCompare (http://forum.doom9.org/showthread.php?s=&threadid=40675&highlight=AVSCompare)

Rash
30th January 2003, 04:06
Well, I did my test today, but this time in the full movie.

I did 6-pass 5.03 against the usual 2-pass 5.02 and no post-processing at all. I believe the image quality on 5.03 is better, just that it took almost the whole day to encode. :P
I could see some artifacts on objects moving in a fixed background though (they are also noticeable at max post-processing). But I believe it is either the B-Frames or GMC, I'll see that later.

crazybus
30th January 2003, 23:33
I've got a question. GMC should reduce filesize when used with a fixed quantizer correct? I'm getting about 10% larger files with it on. QP reduces the size slightly and B-frames about 40%.

Cabadam
31st January 2003, 17:09
I know there is a fix for the Pro version so you don't have adware, but does it work for 5.03? I'm afraid to upgrade right now ;)

six6
31st January 2003, 17:54
I seem to have a problem encoding with 5.0.3. When I play back the video it looks like the attached picture. 5.0.3 plays back 5.0.2 encoded video fine. My cli was

-bvnn 795 -r 480,264,3 -key 300 -log "G:\vid related\get shorty.log" -w -mv "G:\vid related\get shorty.bin" -b -g -pq 5 -vbv 7950000,1835008,1376256 -profile 0

and it doesn't seem to get better with more passes, I did two for this movie. Anyone have any ideas why this is?

six6
31st January 2003, 18:21
sorry, the address for the picture is
www.tc.umn.edu/~frye0031/index.htm

jggimi
31st January 2003, 18:46
Since you put the image on the web and posted a url before I even had a chance to validate the attachment(it would have been my first act as a new mod), I've deleted it...

(I guess I just took my first action, then, after all.) :rolleyes:

Stigma
1st February 2003, 14:10
Six 6 : Yes i know exactly what is causing it. its not in the coding at all, but in the de-coding.

Your 99% likely using FFdshow like i do, and FFDshow then overrides DivX and decodes instead ofthe default decoder (thats usually a good thing since FFDshow is much faster and has more options). Anywaythe problem is that if you have a little old FFDshow installation it wont work good with 5.03 video.

Solution: Instal the latest alpha build for FFdshow. I works exelent, iwe tested it alot =)

-Stigma

symonjfox
2nd February 2003, 17:54
This Alpha build works fine for me! It solves this DivX 5.03 problem, and also solved many Xvid problems (such as b frames and other things) but I get the same color problem opening Xvid files, created with lastest Koepi Xvid build. I don't know what to do.

JensG.
3rd February 2003, 09:38
I encoded first DVD of pal extended version of "Lord of the rings". 640x256, soft bicubic, psychovisuals strong, + quarter pixels, + GMC, + b frames, scene detection 45 %, key frames 250. In 5.0.2 RC averaging period half of overall frames. (Average quant in analyse.log of 5.0.2 was about 3.9)

I encoded 2-Pass in 5.0.2 and 5-Pass in 5.0.3, where I left the nth pass slider in mid position for constant quality.
In 5.0.2 I had to give a slightly higher bitrate than calculated, while in 5.0.3 the correct bitrate was the one calculated by Gordian Knot.
I compared the final avis via avscompare. In the action scenes of the prolog 5.0.3 had less block artifacts. Later on in the film this advantage of 5.0.3 was gone. I did not count, so I do not know the final score for block artifacts, but I guess finally they are pretty similar for both codecs. It was striking that many times the blocks were in different frames, most often one frame apart. (I.e. 5.0.2 had blocks in frame 100 000, 5.0.3 in 99 999.)

When comparing credits of 2nd DVD, I noticed that credits at given quant were larger in 5.0.3, about 10 %.


==> My conclusion:
- Nth pass in 5.0.3 has more accurate bitrate distribution. Unfortunately I cannot tell how much this is affected by the slider position in nth pass.
- Block artifacts appear in both codecs, many times in different frames.
- 5.0.3 gives larger credits encoded at constant quality.

Since in my case the quality of 5.0.3 was not obviously better, I will stick to the old codec. Probably until it is completely supported by Gordian Knot.

Kent Wang
3rd February 2003, 09:47
JensG: That was one of the more thorough and relevant tests yet. But could you try comparing constant quality with the other options? Perhaps they will prove to be a reason to upgrade.

JensG.
3rd February 2003, 11:06
Originally posted by Kent Wang
But could you try comparing constant quality with the other options? I do not know what exactly you mean. Do you mean the slider position in nth pass or the pro features or encoding with constant quantizer?
Since the computer has no other movies to encode at the moment I could certainly try some different settings.

Kent Wang
3rd February 2003, 11:11
Originally posted by JensG.
I do not know what exactly you mean. Do you mean the slider position in nth pass or the pro features or encoding with constant quantizer?
Since the computer has no other movies to encode at the moment I could certainly try some different settings.

I mean the slider in 5.0.3.

JensG.
3rd February 2003, 11:58
Will be done! But it will take two days to compare results :-(

cordraconis
3rd February 2003, 12:12
Originally posted by Kent Wang
JensG: That was one of the more thorough and relevant tests yet.

*cough*, Maybe I'm a little bit overstressed right now :rolleyes:, but more extensive tests have already been conducted, search the forum ...
Avicompare is indeed a more "objective" way, and encoding the *whole* movie is indeed better, but he didn't compare between different Nth-passes. Maybe that 's a good idea for the future.
:D

JensG.
6th February 2003, 15:37
After comparing 5-Pass with slider position to left, middle and right I am a bit clueless. In high action scenes slider to left (high motion) gave best results. So it must have taken away the bitrate from somewhere else. But I could not not find from where. I guess since the overall quality of the encode is so good, the loss of detail is hard to find in other scenes. Probably there is a quant of 3 used instead of 2, which is still real good. So the slider position should have more effect when encoding at lower bitrate.
Slider to right (low motion) showed some more block artifacts in high motion.
When watching the movie the differences were irrelevant.
After all I have still not found any obvious quality difference for upgrading.
When comparing 3rd, 4th an 5th pass by avisynth subtract I found the differences getting smaller each pass. I think most differences appear when there is movement in the foreground against a stagnant background.