DivX Manihi Codec Beta

[SeeMoreDigital]

Hi Fr4nz

Originally posted by Fr4nz
please could you try to make some tests with B-Frames activated and then tell us the results?
Oh and tell us also if the encoding speed is lower...!

No problemo, I will do this tomorrow


Originally posted by LordIntruder
And I don't understand neither why people compare the different encodes with the post-processing mode on. To my point of view we have to compare encodes without these tools to see the rough differences between codecs and after put post-processing on and compare again and in the final report say when post-pro was and wasn't used.

Yes, I have to agree with you here, I much prefer to view my tests without post-processing. With DivX this is easy to do. But unfortunately, with WMV9 you can only do this by visiting the registry.

Cheers

[sapient]

Having had limited experience with the new divx versions, I can't help wondering what's the point of the "slow" and "slowest" modes. Who in their right mind would virtually disable their pc for 2 DAYS (!) just to encode one movie? Are these modes going to get any faster anytime soon? Or are they there just so divx can boast a better possible quality over the competition?

I understand that there might be some (very few though) professionals who want top quality and can sacrifice the computing time (e.g. game developers - divx seems to have won over several of them for the cut-scenes), but maybe there should be a different product for these people than for the average consumer.

sapient

[Selur]

"Who in their right mind would virtually disable their pc for 2 DAYS (!) just to encode one movie? Are these modes going to get any faster anytime soon?"
If the quylity would be worth it, I would.
Hell if there were a good/fast h264 decoder I would use h264 eve if it would take me 3 days to encode,.. ;)

"but maybe there should be a different product for these people than for the average consumer."
Why? Wouldn't it be just better if people who can't 'afford' the cpu time, just don't use the 'slow' and 'slowest'(or comparable) modes?

Cu Selur

[Mango Madness]

If a user/company wants to dedicate multiple days to encoding sources then there should be products to meet that demand. Personally, I will always use the slowest modes because if i didn't, there would always be something eating away at my mind that things could be better. Just my 2 cents on the matter.

[sapient]

@mango madness

That's what I meant by "in their right mind". You sound a lot like someone that has obsessive-compulsive dissorder.:) So thats one more reason for a separate product. It wouldn't aggravate people's conditions:p

Seriously now, if you are a pro interested in that level of encoder, there are other solutions out there... As for us common users, we 'll just torture ourselves, like mango madness, for little result, just so the divx team scores one against the other guys.

[SeeMoreDigital]

In response to Fr4nz's post dated Tue 29 July. My (our) results are as follows: -


SOURCE 'VIDEO ONLY' FILE INFO
Pixel Size: 720x576
Video Type: Mpeg2 (M2V)
Field Type: Progressive
Output AR: 16:9 (1.77:1)
Image AR: 2.35:1
Clip RunTime: 06m 17s (377.24 secs)
Total Frames: 9431
Total Size: 243,030KB (237.33MB)

========================================================

DivX ENCODER AND SETTINGS INFO
Application Used: MpegMediator 1.5
Output Pixel Size: 720x576 Anamorphic
Codec Used: DivX Manihi


FIRST PASS
Under 'Select Profile Wizard' button.
Disable profiles: Checked
Mpeg4 Tools: -
Use Quarter Pixel: Uncheched
Use GMC: Uncheched
Use Bidirectional Enc: Checked
Video resolution: N/A
Video Frame Rate: N/A

Under 'General' Tab.
Performance/Quality: Standard
Bitrate: Multipass, 1st pass
Encoding bitrate: 627kbps
Multipass encoding files: -
Read log files: Greyed out
Write log file: Greyed out
Write MV file: Checked

Under 'Video' Tab.
Video Settings: -
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Advanced: -
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 200 frames

Under 'Settings' button.
Manual CLI: N/A
Saved Settings: N/A
Add codec settings: N/A
Do not prompt....: Checked
Dis. feedback window: Checked
Feedback Window: Disabled
Show Picture: N/A

Encoding Speed: 10Min 14Sec

---

SECOND PASS
Under 'Select Profile Wizard' button.
Disable profiles: Checked
Mpeg4 Tools: -
Use Quarter Pixel: Uncheched
Use GMC: Uncheched
Use Bidirectional Enc: Checked
Video resolution: N/A
Video Frame Rate: N/A

Under 'General' Tab.
Performance/Quality: Standard
Bitrate: Multipass, nth pass
Encoding bitrate: 627kbps
Multipass encoding files: -
Read log files: Greyed out
Update log file: Checked
Write MV file: Checked

Under 'Video' Tab.
Video Settings: -
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Advanced: -
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 200 frames

Under 'Settings' button.
Manual CLI: N/A
Saved Settings: N/A
Add codec settings: N/A
Do not prompt....: Checked
Dis. feedback window: Checked
Feedback Window: Disabled
Show Picture: N/A

Encoding Speed: 71Min 50Sec

File Size: 29,108KB (28.42MB)

========================================================

Conclusion: -

There is no doubt, using Bi-directional encoding (B-Frames) slows down the encoding process.

[SeeMoreDigital]

Let me begin by saying I have no problems with people giving their opinions with regard to a 'beta' software's speed and/or performance. And I openly support and encorage anyone who wishes to improve a product, which ultimately, will benifit us all.

However,I can't see the point of knocking people who don't mind experimenting, however log it takes to generate an encode.

We all have different spec PC's and we all use our time in different ways. And we are all here to learn from each other!

OK, with that said. The first pass of the 'beta' DivX encode can be reduced quite a bit by using the 'standard' setting instead of the 'slowest' setting. Someting that was revealed to us all, on July 8th, in one of Gej's posts (ref to Kauehi tread). And there does'nt appear to be any loss in detail by using this method, with regard to the finished encode. Whether you're encoding in 2passes or 3.

I have no doubt that DivX will speed up the encoding process (unlike M$ with their final release version of WMV9 VCM - Don't know what happened there!) but I can't imagine there will be massive improvement.

Anyway, I'll get off my soap box now. As it's getting a bit slippy!

Cheers

[Fr4nz]

SeeMoreDigital could you make a PSNR comparison between DivX samples made with b-frames activated and WMV9 samples?
With b-frames activated DivX should gain some points...tell us ;)

[temporance]

Originally posted by SeeMoreDigital
Conclusion: -

There is no doubt, using Bi-directional encoding (B-Frames) slows down the encoding process. Yes, but what about the quality? ;) Do you still think WMV9 is better?

[Fr4nz]

Originally posted by temporance
Yes, but what about the quality? ;) Do you still think WMV9 is better?

This is exactly the point: using bidirectional encoding should give a quality boost.

[ominte]

Just a few tests @ quantizer 2 with Manihi

I enocoded the source into HuffYUV and used this for the compare. Then encoded each setting below individually and ran compare.

SOURCE FILE INFO
----------------------------------
Pixel Size: 720x576
Video Type: Mpeg2 (M2V)
Field Type: Progressive
Output AR: 16:9 (1.77:1)
Running Time = 23 sec
Total Frames: 588

AVS
-----------------------------------
SetWorkingDir("C:\Program Files\AviSynth 2.5\plugins\")
LoadPlugin("mpeg2dec3.dll")
LoadPlugin("decomb.dll")
mpeg2source("D:\LAURA_REG24_UKAUS_DISC1_P\VIDEO_TS\sw.d2v", idct=7)
Telecide(order=1, guide=2, post=2)
crop(8,74,704,432)
LanczosResize(720,304)
------------------------------------

Compare AVS
------------------------------------
clip1 = AVIsource("original.avi").assumefps(50)
clip2 = AVIsource("enocode.avi").ConvertToYUY2().assumefps(50)
Compare(clip1,clip2,"YUV","psnr.log")
------------------------------------

Results
========================================
Special Settings | Filesize | PSNR AVG|
-----------------------------------------
slowest search___| 4.08MB | 45.6914 |
slow search_____ | 4.07MB | 45.6906 |
standard search__| 4.16MB | 45.5548 |
fast search______| 4.11MB | 45.2818 |
scne thres. 50%__| 4.16MB | 45.5576 |
GMC____________| 4.17MB | 45.5535 |
NO bframes______| 4.81MB | 45.7913 |
quarterpixel______| 4.15MB | 45.5014 |
psy.enhanc.(fast)| 4.11MB | 45.4852 |
psy.enhanc.(slow)| 3.79MB | 44.9331 |
divx best________| 4.86MB | 45.8839 |
Xvid best________| 4.06MB | 45.8764 |
=========================================

NB - *Unless otherwise stated all encodes use bframes, scene change threshold 80% and "standard" search and whatever features listed in the table.
*"divx best" uses scene change threshold 50%, no bframes, and the slowest search. I decided on these settings from my results in the table.
*"xvid best" includes motion search 6, h.263, no bframes, vhq4 and chroma motion. Encode was at quantizer 2.
*Sorry about the filesizes but I was in a hurry and decided to test at quantizer 2.

[SeeMoreDigital]

Sorry you guy's. I should have thought about providing more info.

We've just finished playing back the 'bi-di' and 'non bi-di' files and there is a difference between the encodes. When viewed with 'post-processing' turned off.

The background image appears to be a little more stable and the foreground image appears to be less blocky. The whole image appears to be a little softer though.

Which is'nt all bad because the overall effect makes the encode more engaging!

It's still not quite up there with WMV9 VCM. But fairly close!

[Fr4nz]

@SMD: I think bi-di is a MUST when you encode, at any bitrate, ESPECIALLY if you use low bitrates.

[dTb]

I've just completed some testing. I decided to take a 5 min segment from Star Trek - Nemesis (PAL region 4)and encode it using the range of performance/quality settings in Manihi from standard to slowest, each with and without the slow pve mode. I also encoded it with 5.0.5 to provide a comparison for improvements.

I chose a segment runing from 7min 30s to 12min 30s as it has a fairly nice range. 15s of the end of the wedding reception, 3min 30 on the bridge of enterprise with about 3 pans of the ship exterior and the last 35s on the very brigh planet surface with some fast motion in the buggy.

AVS as follows

LoadPlugin("i:\PROGRA~2\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("i:\PROGRA~2\GORDIA~1\undot.dll")
mpeg2source("G:\DVD Movies\Star Trek - Nemesis\Nemesis.d2v")
trim(11250,18750)
crop(0,72,720,432)
undot()
LanczosResize(640,360)
undot()
Temporalsoften(2,3,3,mode=2,scenechange=6)

@750kbps this scored a compress test of 34.47% in enc using 5.0.5, no offence to the author of enc but I'm starting to have doubts as to it's accuracy with small files like this (it's probably due to the nature of the test).
Nonetheless I feel any reference to this being a high or low bitrate without relating it to a compress test is incorrect. What's high for one video is low for another. Obviously this is quite low.

I first encoded the video to huffyuv which on a side note I later realised was a very good move as it drastically cut down encode time.

Each file was encoded 2-pass (nth-pass mode) using the home theatre profile with no settings changed between passes. B-frames were used throughout as well as a sct of 47% and max keyframe interval of 250.

File #1
DivX 5.0.5, Slowest mode, no pve
Total Average PSNR: 41.93

File #2
Manihi, Standard mode, no pve
Total Average PSNR: 41.71

File #3
Manihi, Standard mode, slow pve
Total Average PSNR: 41.73

File #4
Manihi, Slow mode, no pve
Total Average PSNR: 41.97

File #5
Manihi, Slow mode, slow pve
Total Average PSNR: 41.93

File #6
Manihi, Slowest mode, no pve
Total Average PSNR: 41.98

File #7
Manihi, Slowest mode, slow pve
Total Average PSNR: 41.94

Visually comparing these files is where things become difficult, file #7 is a noticeable improvement over file #1 but comparing #6 with #7 it's a lot harder to tell.
To my mind comparing #1 & #7 shows that psnr needs to be taken with a grain of salt.

I'll post more comments soon after further visual study.

[SeeMoreDigital]

Hi dTb,

Nice too see your back with us, after your holiday break.

Originally posted by dTb
Visually comparing these files is where things become difficult, file #7 is a noticeable improvement over file #1 but comparing #6 with #7 it's a lot harder to tell.
To my mind comparing #1 & #7 shows that psnr needs to be taken with a grain of salt.

I agree with you here. You can't just compare low bitrate encodes using PSNR alone. And the figures generated often don't tell you the real 'visual' story.

Although I (we) do generate PSNR tests. I don't post the results, as I'd far rather use my eyes. And the eyes of my co-workers!

Anyway, over this weekend I'm going to encode my favourite 136min test movie. And give Manihi a proper test.

[kl33per]

To my mind comparing #1 & #7 shows that psnr needs to be taken with a grain of salt.
I agree with you here. You can't just compare low bitrate encodes using PSNR alone. And the figures generated often don't tell you the real 'visual' story.
Hi, this is my first post here (didn't like waiting five days at all, but I can see why it's there), but previously have hung around Hydrogen Audio and Divx.com.

I definately agree. I've now read of a number of people who've tested Manihi who have found that even though the encoded viseo has an equal/lower PSNR than say a DivX 5.05 encode, the 'perceptual' quality is much better.

[jonny]

@dTb:
It's hard with small clip! (you can use a really high % of analisys in those cases... or a full 100% encode to find the error free value ^^)

[nuked]

Has anyone tried using the old 2-pass encode on manihi? I am getting file sizes about one third what they should be with it. They come out dead on as expected if I use n-pass where n is 2, no other diferences in my settings. I read once that the 2-pass method was at least at one time better than an n=2 pass. Is this still true? (well obviously not if I can't get the right file size, but assuming that's just a glitch or user error....)

[bond]

Originally posted by nuked
I read once that the 2-pass method was at least at one time better than an n=2 pass. Is this still true?in my opinion yes, but there is still a discussion going on about that at the moment (read other threads about that)...

[kl33per]

I don't know of anyone whose tested the old 2-pass method and I think most people consider it redundant. Some people drivel on about how the quality is better on low-motion, but that can be achieved with n passess using bitrate modulation.

[bond]

Originally posted by kl33per
Some people drivel on about how the quality is better on low-motion, but that can be achieved with n passess using bitrate modulation. [/B]hey, i just wrote in the other thread that i compared org. 2-pass vs. nth-pass and that i couldnt reach better quality/sharpness (or at the least the same) with using bitrate modulation even at the the max possible level (0.25) compared to original 2-pass :rolleyes:

but everybody has to decide for himself (at least i dont see original 2-pass as redundant...)

[nuked]

@bond

yeah.. that's kinda the impression I'd gotten from other threads. I haven't done any testing on my own, maybe I will, but I do know that personally I prefer to tilt the quality a little more towards the low motion scenes.... anyway, that's for another thread.

Hmmm... well I hope it's not broken, or not permanently. I don't really have the cpu time to spend on a 4 pass encode. I guess for now I'll go back to 5.05, which I may as well do anyway for limited cpu time.

[temporance]

Originally posted by bond
hey, i just wrote in the other thread that i compared org. 2-pass vs. nth-pass and that i couldnt reach better quality/sharpness (or at the least the same) with using bitrate modulation even at the the max possible level (0.25) compared to original 2-pass :rolleyes:Hey bond - if you're getting worse video even after three or more passes then you should check what you set as max bitrate - if the max is less than 10x target bitrate then you could get quality loss with nth pass. Of course orig 2-pass has no max rate so doesn't have this problem.

[bond]

Originally posted by temporance
if you're getting worse video even after three or more passes then you should check what you set as max bitrate - if the max is less than 10x target bitrate then you could get quality loss with nth pass. Of course orig 2-pass has no max rate so doesn't have this problem.interesting point,
yes, the max bitrate is set to 10x target bitrate, but perhaps that can cause some "problems" as i think that dxn cuts the max. bitrate to reach the hardware compatiblity they want to achieve, although i wonder if a low motion scene will ever need 7000kbps?

[SeeMoreDigital]

For me, the whole question of allowing the 'user' to adjust the 'Bitrate Modulation' is a strange one.

Surley DivX could create an application that can automatically formulate the correct setting(s), during the first pass, and write the necessary information into the 'log/MV file' ready for the second pass?

I don't know about anybody else but I've never seen such a function in any other codec manufacturers software.

In my opinion, this is DivX's achilles heal, especially when encoding at low bitrates!

[nuked]

What's so strange about it? Some users like like more detail in high motion scenes some like more in low motion scenes. It's totaly subjective. There is no "correct" way to do it. You can leave it at the default and pretend the option isn't there if it makes you happier. I agree they'd save themselves a headache by leaving it out, but only because by puting it in someone will always complain about it... but that goes for any options... one good reason not to open source things, what people don't know about and can't fool with wont bother them.

And why is ther a cult of people who keeps saying they don't crop and resize like it makes them more holy than the rest of us, cause I can't see what else it has to do with anything here. Certainly at least for many situations NOT cropping and resizing is just a really really bad idea, but again it's all subjective, so whatever makes you happy :). Personally I do it when it looks best to do it and not when it doesn't :).

[dTb]

Nuked, in regards to the original 2-pass in Manihi, I doubt the new rc algorithm has been implemented for this mode so there probably isn't much point in testing it.

In regards to my earlier test I'm finding it hard to make definitive judgements as to what differences there are between the clips as they're all pretty similar and tend to struggle in the same areas.
The standard mode in Manihi does seem to be an improvement over 5.0.5, I think it's safe to say there is an improvement using the slow mode and again with the slowest. Whether or not to use PVE I'm finding is harder to judge, in one case it made some bleeding in an enterprise exterior shot worse.

At this point I'd say if you want similar encoding times to 5.0.5 use the standard mode in Manihi as I'm fairly certain there's some improvement there, slow and slowest will yield improved results but whether the extra encoding time is worth it is up to you. I'm uncertain whether I'll use slow and slowest for whole movies atm, hopefully DARC can really optimise these modes.

[SeeMoreDigital]

I know what you mean nuked.

But surely most of the people want to see, most of the detail, most of the time.

As we all know the codec is capable of producing very good levels of detail in both the fast motion and low motion areas.

So like you say, why give people the choice? Why not do away with the function altogether? And change the main bitrate input setting of the codec accordingly.

As you are no doubt probably aware. If you take the same 'video only' input file and use the same bitrate in different encoders (WMV9, Xvid, RMV9 etc) you'll obtain totally different file sizes.

So who's to say that the bitrate we enter into the DivX codec, is correct anyway?

Does'nt that make you wonder why no other codec manufacturer has this setting.

Maybe when you enter a desired bitrate in say, RMV9 the codec nominates a fixed percentage of that bitrate and uses it to balance the modulation detail more precisely in both the fast bits and the slow bits.................

I don't know. I'm just bouncing ideas around!

[nuked]

hmmm.... I haven't noticed totally diferent file sizes, but I've only used xvid, divx (and sbc, but that's a bit diferent bllgame). They both come out pretty close in file size to what I expect with a pocket calculator unless maxed out of course.

I guess there is always a line drawn somewhere as to just what the users can control though in any software... I suppose the software package that allows full control is called C++. You're right, most people seem to agree that wasting too many bits on explosions and such is not desireable. Does seem like orig 2 pass made alot of people happy without any adjustments. I don't think the control is in anyway a drawback though aside from a possible bad default value.

Well I certainly plan to move on from 5.05 sooner or later, cause after all eventually I'll have to and I'm sure the kinks will get worked out. I'm doing a nth pass, n=2 encode now with manihi, almost done. Maybe I'll run an old 2-pass overnight if I feel like reinstalling the old version and see how they match up.

edit:
I guess I don't see what mean about changing the "main" bit rate though or about the bit-rate being "correct". By correct do you just mean the actual bit rate is the same as the one you enter? As far as I understand bitrate modulation has nothing to do with main bitrate, only where the bits are used... no?

[nuked]

dtb... I agree there's not point in testing orig 2-pass in manihi terms of seeing how well it performfs cause it shouldn't be diferent than before. The only test I want is to know if it still works and I think I've answered that myself..no.. but it's a beta version anyway so I guess it's not critical yet. The quesiton is then will this be abandonded entirely and will the multipass come up to the same standards for similar encoding times? That's what I am still waiting to find out. I'm not really interested in n>2 or in the slow or slowest modes. I have a nice computer but it needs to spend its daytime hours earning its keep and after all 2 passes can and should be good enough.

[kl33per]

Originally posted by dTb
The standard mode in Manihi does seem to be an improvement over 5.0.5
The standard mode in Manihi is the old 5.05 algorithms, so yes they should produce almost exactly the same results and speed as 5.05 (discounting New B-frames and new PschoVisual).

[DigitAl56K]

Guys, there is a bug with the Manihi decoder.

Auto-post processing should work ok I believe, so that if you have this option enabled your system should post-process the decoded video at an appropriate level for your system while you watch it.

However, if you have been trying to force full de-blocking or de-ringing then the likelyhood is that you have infact been watching video with no post-processing performed whatsoever.

Please use RegEdit to set:

HKLM\Software\DivXNetworks\DivX4Windows\PostProcessing

The value should be 4 for full de-blocking, and 6 for full de-blocking+de-ringing.

This is only effective when auto-post-processing is completely disabled, of course. You may need to reset this value every time you modify the decoder configuration, so my recommendation is to export it to a .reg file on your desktop for easy configuration.

Hopefully this will boost your visual quality test results, and also explains why I considered WM9's post-processing superior to Manihi's in my first round of testing - DivX wasn't doing any ;)

I will include these details in my next batch of testing.

Keep up the good work everyone
-Al

[DigitAl56K]

Oh yes one other note regarding post-processing - do not use auto-post-processing when performing PSNR testing because it will drop down to 0PP as your CPU usage gets too high. You must force full post processing using the aforementioned method.

[DigitAl56K]

@SeeMoreDigital

Regarding the modulation control - This mimics one of the ways DivX3.11 was able to be tweaked to achieve better quality depending on the content type. It actually does make a lot of sense: If you are encoding a clip that is mainly low motion but contains a few high-motion sequences then you do not want bandwidth to be allocated severely disproportionatly to the high motion scenes, so that you might nudge the slider towards low-motion to prevent this from happening. This might be helpful when trying to squeeze the best possible quality out of certain videos at lower bitrates.

[SeeMoreDigital]

Hi again DigitAl56K,

Thanks for the tip about the post-processing control.

Regarding the modulation control - This mimics one of the ways DivX3.11 was able to be tweaked to achieve better quality depending on the content type. It actually does make a lot of sense: If you are encoding a clip that is mainly low motion but contains a few high-motion sequences then you do not want bandwidth to be allocated severely disproportionatly to the high motion scenes, so that you might nudge the slider towards low-motion to prevent this from happening. This might be helpful when trying to squeeze the best possible quality out of certain videos at lower bitrates.
As I've said before. Having control over the bitrate modulation may indeed be useful. And yes I have used it but only in conjunction with GMC. But I still can't help feeling that by leaving such a control in the hands of the user leaves DivX open adverse comment.

What happens, if say, you have a film with fast scenes in the first and third quarters of the movie and slow scenes in the second and fourth quarters of the movie.

Perhaps such films should be cut it into four, encoded separately and joined back together to get the best results!

I really can't understand why some software wiz has not been able to write some clever code/software that could make better use of such a function by allocating the correct amount of bits when and where required. (And then hide it out of the way for good).

I think it's almost sad to be able to see DivX perform really well in certain portions of an encode and then not as well in others. All because of a function that is set in stone!

It's just my view.

[DigitAl56K]

Originally posted by SeeMoreDigital
What happens, if say, you have a film with fast scenes in the first and third quarters of the movie and slow scenes in the second and fourth quarters of the movie.


This is why you have the modulation control. You would tend the slider towards low motion if you didn't want the first and third quarters of the movie to get a lot more bandwidth than the second and fourth quarters. Alternatively you could tend it towards high motion to favour giving more bandwidth than normal to the second and fourth quarters and less to the first and third.

Any way you look at it, this actually works out the same as would splitting the movie into four parts and trying to encode seperately with a finite number of bits for the sum of all parts.

[Mentar]

Since there have been several posts on this subject, I want to voice a different opinion: For me personally, the encoding speed is fairly negligible, as long as there is quality to be gained. I've encoded anime episodes of 24 minutes which have taken 48 hours on an Athlon 1300 for a single pass (to huffyuv) due to a complicated filter chain. The DivX 4-pass I usually do on the huffy later on tends to be just a quick breeze, and even if it would take another half day.

I recognize that my approach is definitely not representative for the average encoders, but there _is_ a demand for slow hi-quality modes too.

[SeeMoreDigital]

When the new version of DivX comes out I can't imagine that 'first pass' encoding time will take as long as it does now.

Even the M$ WMV9 VCM encoder has a quicker 'first pass'. Using either one of it's possible 5 settings!

The 'second pass' is a different story. As hopefully the longer the pass the better the encode. This is certainly the case with WMV9 encodes below 900-950kbps (the background imagery becomes totally shake free making the overall imagery much more watchable during low motion scenes). However I'm yet to create an DivX encode at below 950kbps that looks as good, even when using the 'slowest' setting, GMC and bitrate modulation.

I am a big fan of DivX, so I am convinced they will crack this 'low bitrate' barrier very soon!

[DigitAl56K]

Some tips:

For first pass set the performance/quality slider to "Standard", then later change it to "Slowest" on your final pass. Your first pass will then run almost as fast as WM9's first pass.

Regarding second pass speed, Manihi Beta 1 still does not write the MV file and hence encoding speed is slower than in normally would be with the release build.

I have a preview of a version with the MV enabled (expect it on the labs site very soon) in which the second pass is ~41% faster than WM9's second pass.

Also, try out the new "slowest" psychovis mode - this includes new masking algorithms that can substantially increase perceptual quality (even though PSNR will drop it will look better).

[SeeMoreDigital]

Thanks DigitAl56K,

Personally I already use the 1st pass and 2nd pass method you describe.

But it's good to mention it again, for all those people that may have missed it on previous posts!

I have to admit I have not tried the new "slowest" psychovis mode. So I will give this method a ago. Right after I finish encoding Planet of the Apes (using WMV9 VCM. With video@737kbps and audio @96kbps). Only another 18 hours to go!

I have to ask. Are you anything to do with DivX. If not how did you come by the preview versions of their applications?

Cheers and thanks for the posts.

[DigitAl56K]

I'm not officially "anything to do with divx", though I have been moderating the forums for a long time now. I happened to be discussing some Manihi issues with Gej on Friday when he told me the MV file was fixed, and as I am running some more detailed tests this weekend he was kind enough to let me have a pre-release build. As I say, it should appear on the labs site in the near future. I'm also going to be posting some more interesting results hopefully later on Sunday (it just takes a little time to compile them).

Although I probably shouldn't be talking about pre-release features here, I doubt Gej would object to me informing you of the kind of speed increase I'm seeing - especially as so many posts comment on the encoding duration of Manihi. Again, more detailed results will follow soon :)

[SeeMoreDigital]

Originally posted by DigitAl56K
I have a preview of a version with the MV enabled (expect it on the labs site very soon) in which the second pass is ~41% faster than WM9's second pass.
I forgot to ask. Is this 41% faster than WMV9's 'slowest' (#5) setting? If so that's a fantastic improvement!

[sapient]

Given the time that the second pass takes using the slow or slowest modes, I was wondering, if I used this time for more "standard" mode passes, how would the quality compare? In other words, for the same amount of encoding time, which strategy would give a better image quality, one nth pass @ slowest or more nth passes @ standard?

[DigitAl56K]

Please see here for my Round 2 Manihi test results:

http://forums.divx.com/viewtopic.php?topic=52630&forum=23

It should make interesting reading for those concerned with speed/quality.

[SeeMoreDigital]

Originally posted by DigitAl56K
Please see here for my Round 2 Manihi test results:

http://forums.divx.com/viewtopic.php?topic=52630&forum=23

It should make interesting reading for those concerned with speed/quality.
The info and test results in your 'Round 2' document is great news.

After enabling full post processing (6) in the registry, I decided to playback my DivX encode of Planet of the Apes (video@749kbps / audio@96kpbs).

And I have to say 'the eyes don't deceive here' as the DivX encode appears to look every bit as good now as my WMV9 VCM encode (video@735kbps / audio@96kbps).

I shall generate some more encodes of the same movie today using "slowest" psychovis mode and report back!

I just wish I had the speedy boy 'preview' version of Manihi!

Cheers

[sapient]

@digital56k

Although interesting, your results do not answer my question...
How would a 2 pass encode using slowest in the 2nd pass compare to an all-standard 5-pass encode that would actually take less time?

@the divx guys

We would all like to see this terrific new speed improvement... When will it be making a public appearance?

[Fr4nz]

Hey guys now I'm just guessing if I could stick to a 3-pass encoding with the old 5.0.5 instead of using the new Kauehi/Manihi standard 2-pass mode, keeping a similar quality when I encode at low bitrates (900kbps) using b-frames and psycho enhancements with both codecs (medium psycho with 505 and fast psycho with manihi)...

I find Manihi very slow (too slow) for now.

[Sirber]

900kbps is low bitrate? LOL!!!!! I have some movies at 400-450kbps with nice quality (BTW, not in DIVX).

[temporance]

Originally posted by Sirber
900kbps is low bitrate? LOL!!!!! I have some movies at 400-450kbps with nice quality (BTW, not in DIVX). Well, we all have our own standards, Sirber. ;)

900kbit/s is a low bitrate for all modern codecs if you want to be able to see any of the finer detail at a decent resolution. Sure, 400k can look "nice" to one set of eyes, but 900k at DVD res will look nicer but still nowhere near as good as an uncompressed 270Mbit/s 601 copy (or 1.5Gbit/s uncompressed HD)!

[DigitAl56K]

@sapient:

"Although interesting, your results do not answer my question...
How would a 2 pass encode using slowest in the 2nd pass compare to an all-standard 5-pass encode that would actually take less time?"

The result is very dependant upon the content type. Slowest mode improves quality by calculating the best combination of block/frame-type decisions to reduce the bits spent, thereby freeing bits for other parts of the video. Therefore, slowest mode is always likely to squeeze a little extra quality from the video because the rate control strategy in multipass does not examine these decisions.

However, a three pass encoding (as the document mentions) in standard mode all the way through will still give you very good results - in fact your results should be almost identical to a three pass in DivX5.05 in slowest mode.

Because DivX 5.05 did not use the MV file either, there is no performance gain in reverting to DivX 5.05, simply use Manihi in Standard mode throughout. You then have the option of using the new psycho-visual modes, which should substantially improve perceptual quality despite dropping the PSNR.

I don't have any statistics which allow me to say "3 passes on standard is equivelent to xx% of the quality of 2 passes on slowest" - which I realise is what you are looking for, I may run some tests on this - however I suspect the results will be content dependant.

@Sirber

I would consider 900Kbps to be "better than average" bitrate, taking ~720Kbps as average because at this bitrate artifacting starts to become more noticeable to the naked eye at an acceptable distance from the screen. Also ~720Kbps is what many people use for 1-cd rips.

Although in some cases you may get away with a lower bitrate, I imagine it comes at the cost of lower resolution, noise reduction filters, a "smoother" resulting image etc.