DivX Manihi Codec Beta

[Gej]

DivX Manihi Codec Beta is up at DivX.com

http://www.divx.com/divx/windows/beta/


Welcome to the new codec beta release. The release is full of new features that will improve the overall quality of your digital video experience. A list of new features and fixes can be found in the "What's New" section below. The Quality Assurance (QA) period will run for about three weeks starting 2003-07-25. All the results must be e-mailed back to us by 2003-08-15 at the latest. Intermediate results are welcome. Please submit your bugs through our bug submission form .You can discuss your bugs and feedback with the DivX community in the DivX Beta Release Feedback Forum.


What's New:

* High Quality encoding mode
- Different motion estimation criteria
- Rate distortion algorithm

*High Quality psychovisual mode
- Texture cortex masking and Rate distortion algorithm
- Hybrid mode (Texture cortex masking)

* High Quality B frame mode
- The motion estimation for B frame has been improved
- Quantization modulation is changed

* Feedback mode
- Allows visual feedback during encoding

* Decoder rearchitecture
- Decoder is 10 to 30% faster on all CPU platforms
- Decoder supports auto-postprocessing

* Encoder GUI
- The codec GUI has been redesigned to ease accessibility and simplify overall usage.
- RC modes: Enabled complexity vector logfile, and experimental texture / motion modulation switch
- RC to support real time control through API support
- I frame insertion forced through API support


Fixed:

* Fix for quantizer overshoot when over bitrate following a transition to a complex scene
* Change in quantizer from one frame to next limited to change in ideal quantizer or +-2
* Fix for a bug in RGB32 to YUV conversion on P4
* A minor issue with Multiple CPU configuration
* Fix for broken B-frames ('P' in FrameSpec was occasionally producing an I frame)
* 3.11 Compatibility improved (NO mismatach at all on ALL the clips tested, more than 60 hours of contents!)
* RC VBV enforce "3 sec" max bitrate
Bugfixes, performance improvements in nth-pass strategy planning
* MV reuse is functional
* Qpel, B frames and slow and slowest mode doesn't generate artifacts anymore

[cordraconis]

d**n, I was looking around on your website becouse I have some Probs with Dr.Divx, and I just saw your new béta.

It seems you were faster than me to report it to Doom9, héhé.

:p

[SiXXGuNNZ]

very nice!

when I get my new dvd-rom drive next week I will be testing this thing out :)

well I tested it right quick on some avi sources, but that isn't very accurate :D

[The People's Elbow]

In VDubs compression dialogue it still says "kauehi" though codec seems to have changed - at least the settings did.
Is it me or a little bug in the frontend?

greetz Elbow!

[SiXXGuNNZ]

Originally posted by The People's Elbow
In VDubs compression dialogue it still says "kauehi" though codec seems to have changed - at least the settings did.
Is it me or a little bug in the frontend?

greetz Elbow!

I dunno ay, mine says DivX Pro Manihi Codec

[Animaniac]

Originally posted by The People's Elbow
In VDubs compression dialogue it still says "kauehi" though codec seems to have changed - at least the settings did.
Is it me or a little bug in the frontend?

greetz Elbow!

I needed to uninstall Kauehi before installing Manihi, for it to work correctly.

[rozemab]

Is it possible to install Manihi without messing up my Divx Pro install?

I would like to try it out with vdub etc. and not affect my Dr Divx configuration.

[Gej]

You can install Manihi safely, it'll not impact DrDivX, as it use it's own private encoder.

[saeed]

I have just downloaded and installed manihi. but what I got was kauehi in the decoder and the encoder. The previous version on my system was 5.03 not kauehi. the reamde file is for manihi, though.

The file size is 1,912,749 bytes. Can someone confirm that.

[The People's Elbow]

I had to delete the divx.dll manually to get manihi working, maybe my system is messed up a bit ;)
This new overlay dialog is a pretty thing, but for job encoding it's a disadvantage, because its always showing the encoded output which slows down encoding while I'm asleep... can that be disabled?

greetz elbow!

[pluonk]

I installed Manihi today and am now encoding a movie with VDubmod (which btw correctly identifies as "DivX Pro Manihi Codec"). It runs extremely slowly, ~7fps, while 5.05 and previous encoded at 15-20fps (for the same type of movie, which is PAL interlaced using FieldDeinterlace). The settings for Manihi are the defaults (perfomance/quality: standard, psychovisual enh: slow, -Qpel, +GMC, +Bframes). Has anybody tested it or know what's wrong?

Btw, I closed the overlay dialog, hoping that it was to blame for the slow performance, but it didn't help at all. If I choose to keep this codec, does anybody know how to prevent this dialog from popping up each time VDubmod runs?

[saeed]

To disable the feedback window you have to click the settings bottun next to OK bottun and check the option.

I guess it is slower because of the new psychovisual enhancement and the motion estimation in B-frames.

[SeeMoreDigital]

Well here we are again with another DivX test codec. Great fun!

To disable the feedback window you have to click the settings bottun next to OK bottun and check the option.
I guess it is slower because of the new psychovisual enhancement and the motion estimation in B-frames.

Granted the decoder will be slower if psy etc is used. But if you disable the feedback window the encoder should run approx twice as fast.

I'm currently encoding Tomb Raider 1 (PAL 96min) in anamorphic (720x576) with video at 913kbps and audio at 96kbps. So I should have some results in a few hours.

As per normal I'll compare this new encode against previous encode versions such as DivXPro5.0.5 & Kauehi. And view the output on my TV via the Xcard.

[Fr4nz]

Originally posted by pluonk
I installed Manihi today and am now encoding a movie with VDubmod (which btw correctly identifies as "DivX Pro Manihi Codec"). It runs extremely slowly, ~7fps, while 5.05 and previous encoded at 15-20fps (for the same type of movie, which is PAL interlaced using FieldDeinterlace). The settings for Manihi are the defaults (perfomance/quality: standard, psychovisual enh: slow, -Qpel, +GMC, +Bframes). Has anybody tested it or know what's wrong?

Btw, I closed the overlay dialog, hoping that it was to blame for the slow performance, but it didn't help at all. If I choose to keep this codec, does anybody know how to prevent this dialog from popping up each time VDubmod runs?

Also the GMC active slows down the encoding ALOT.
Try to put psyco on fast and disable GMC..it should be really faster.

[SeeMoreDigital]

My first test with DivX Manihi is complete.

To be honest I can't see any difference between this version and Kauehi. I will generate a lower bitrate encode tomorrow. Maybe (I hope) this will reveal some more positive results.

All is not lost though as I do prefer the new interface.

Anybody else like this?

[Fr4nz]

I also tried Manihi at 1000kbps and I can't see any difference with Kauehi (same options enabled). Oh I have to say also that I find Kauehi faster, so I think I'll stick with it.

[Morbo]

Overlay window is ultra cool:cool: :cool:

Looks like a nice release overall again gej..

Cheers!!

[silver_cpu]

I have an interesting problem...

Ever since I upgraded (from Kauehi), whenever I try to encode through VirtualDubMod , it gives me this error:

VideoSourceAVI error: the source image format is not acceptable. (error code -2)

Anyone know what this means? I've tried different settings, as well as changing the resolution (thought I might have hit a bad one), but nothing seems to help. I'm trying to encode one of the pieces in "the animatrix," can anyone describe what VDM's problem is, and how to fix it?

EDIT: Well, it seems that this is a system-wide problem. I tried out Xvid and Divx3 just in case it was truely DivX5 that had caused the problem, that didn't fix it. Vor some reason, VDubMod is rejecting the video stream. I've tried uninstalling and reinstalling the GKnot rip-pack (0.28.5, with 0.28.5.2 patch), and un-installing DivX (even running a registry cleaner to catch stray reg entries), reinstalling with the retail 5.0.5 codec (none of the betas). Nothing works :( It keeps giving me the same error, but I can't seem to locate that error when I search the boards... Maybe I'll have luck and figure out what it is soon.

[LordIntruder]

Look here, it may solve your problem:

http://forum.doom9.org/showthread.php?s=&threadid=51906

[silver_cpu]

Thank you so much! It worked perfectly :)

[LordIntruder]

I've just given a short try to Manihi.

I can compare the speed as I have just encoded a full movie with Kauehi and I use the SAME avs.

With the same parameters, if I select the new psy in slow mode + standard encoding, it's around one hour longer compared to Kauehi new psy + standard encoding.

Now if I select new psy in fast mode, it's almost two times shorter to encode the full movie!?!

However I stopped the tests 10 min after launching them with VDM. By the way encoding time are given by VDM and I can say they are rather accurate. But I will do full encoding tests with the same movie to compare.

I really wonder what are the differences between those two modes quality speaking because the speed improvement in new psy fast mode is awesome. I wonder if it worths to encode in new psy slow if it takes up to two times more time. Some tests have to be done in this area.

Could Gej or any other divx people team tell us, if possible, what are the differences we could expect from new psy fast and slow modes?

Of course if we combine new psy slow with slow encoding it's even slower than Kauehi new psy + slow encoding.

Finally I noticed with Manihi than whether you select new psy in fast mode or you disable it, there is no noticeable improvement in encoding speed. At least with my 1800+ and on a 10min test. So I think the new psy fast mode can always been ticked and now the question is rather or not new psy in slow mode improve the overall image quality or not.

MV has done is come back but I wonder if enable it can lower quality by a bit or not? With older divx 5, 5.01, etc... many people noticed a small loss in quality with MV enabled. Could it be same here? Another thing to look at.

And cheers for the new GUI and the feedback window. It's complicated to analyse but at least I can shine my friends on. :D

[dTb]

Not much to really report just yet but the mvinfo.bin file wasn't generated on my first encode so I'm leaving it unchecked at the moment. Other users have reported this on divx.com.

@SeeMoreDigital, I can't give any figures but disabling the feedback overlay doesn't seem to make much difference. Certainly not double the speed in any case.

I'm unsure atm what the difference is between the fast and slow pve, I suspect fast may be the old method and slow is the new. I'll try to confirm later but if someone wants to check themselves I think I know a way. The old method often generated frames with average quants that were not whole numbers (ie. 4.75) while the new method in Kauehi always generated quants with whole numbers.
Try encoding one file with fast and one with slow and use the osd in ffdshow to check the average quants of frames during playback.

DigitAI56k from divx.com made a comparison and mentioned that encoding speed greatly increased when using q-pel when compared to the standard half-pel. This is the opposite to what you'd normally expect so maybe it's some kind of bug.

I generally like the new encoder gui but having the b-frame option in the profile wizard is a bit of an annoyance (to a lesser extent with gmc and q-pel because I usually don't use them) but is understandable.

In Kauehi the sct was ignored when using the slow and slowest performance/quality settings, I figure this to also be the case in Manihi but am unsure till someone from DARC confirms it. More info can be found on why this is the case in the divx labs forum. Personally I like this and feel it's possibly a reason why high motion is improved in Kauehi.

Just some info I thought people here might find usefull:)

[DigitAl56K]

Please see this regarding the speed of Manihi:

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

And here are some test results I've compiled so far:

http://www.btinternet.com/~digital56k/DX_MB1_R1_D56K.pdf

[SeeMoreDigital]

Like DigitAl56K I've managed to generate some more DivX Manihi tests. But this time I selected a lower bitrate.

My encodes were also generated with the 'Feedback Window' disabled and enabled. And with the 'Show Picture' output disabled and enabled.

According to Gej there should'nt be much difference with the encoding speed but my results don't agree!

Now, for all those people who don't already know. I prefer to encode my output files in anamorphic (720x576) ie with no cropping and resizing and also view the output via Sigma Xcard.


My encode information is as follows: -

Source 'Video Only' File Information
Selected Movie: StarWars 2 PAL
Selected Chapter: 41
Clip RunTime: 06m 17s (377.24 secs)
Total Frames: 9431
Pixel Size: 720x576
Video Type: Mpeg2 (M2V)
Field Type: Progressive
Output AR: 16:9 (1.77:1)
Image AR: 2.35:1
File Size: 243,030KB (237.33MB)

------------------------

Encoded 'Video Only' File Information
Application Used: MpegMediator 1.5
Output Pixel Size: 720x576 Anamorphic
Codec Used DivX Manihi
Bitrate Used 627kbps
Number of Passes 2

------------------------

Encoded File Number 01
Performance/Quality: Standard
Feedback Window: Disabled
Show Picture: N/A
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 80%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 768 frames
Selected Profile: Home Theater
Bidirectional Encoding: Unchecked
1st Pass Encode Speed: 07Min 52Sec
2nd Pass Encode Speed: 07Min 54Sec
File Size: 29,105KB (28.42MB)

------------------------

Encoded File Number 02
Feedback Window: Enabled
Show Picture: Enabled
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 80%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 768 frames
Selected Profile: Home Theater
Bidirectional Encoding: Unchecked
1st Pass Encode Speed: 14Min 14Sec
2nd Pass Encode Speed: 15Min 07Sec
File Size: 29,105KB (28.42MB)

------------------------

Encoded File Number 03
Feedback Window: Enabled
Show Picture: Disabled
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 80%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 768 frames
Selected Profile: Home Theater
Bidirectional Encoding: Unchecked
1st Pass Encode Speed: 10Min 09Sec
2nd Pass Encode Speed: 10Min 02Sec
File Size: 29,105KB (28.42MB)

------------------------

In conclusion. Using this bitrate and settings DivX Manihi does not look as good as WMV9 VCM.

Sorry!

But not to be daunted, i'm currently performing some more tests using DigitAl56K settings.

Cheers

[LordIntruder]

DigitAl56K: about your first link I wonder what you mean in:

"Also remember that the encoder isn't configured correctly when you first load it, click the "Restore defaults" button to set it up correctly the first time"

Manihi isn't correctly set up? What is wrong with it? The only thing I notice strange could be the "Scene change threshold: 80%". I would have set it up to 50% but I may be wrong.

Nice work with your pdf. :)

[SeeMoreDigital]

Hi LordIntruder,

I think you may be correct regarding the default settings.

Even so, something can't be quite right if pressing on the default button alters the original installation settings.

Anyway, at least Manihi installation did not involve downloading and installing a new default settings registry file, like Kauehi!

Enjoy

[SeeMoreDigital]

OK. I've now encoded the same file using DigitAl56K settings. And I have to say there is an visible improvement in quality. So thanks for that.

I also performed the same encode again but this time disabled the Output Profile.

To confirm my results: -

Application Used: MpegMediator 1.5
Output Pixel Size: 720x576 Anamorphic
Codec Used: DivX Manihi
Bitrate Used: 627kbps
Number of Passes: 2

------------------------

1st Pass
Performance/Quality: Standard
Feedback Window: Disabled
Show Picture: N/A
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 300 frames
Selected Profile: Home Theatre
Bidirectional Encoding: Unchecked
1st Pass Encode Speed: 07Min 54Sec

2nd Pass
Performance/Quality: Slowest
Feedback Window: Disabled
Show Picture: N/A
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 300 frames
Selected Profile: Home Theatre
Bidirectional Encoding: Unchecked
2nd Pass Encode Speed: 58Min 26Sec

File Size: 29,109KB (28.42MB)

------------------------

1st Pass
Performance/Quality: Standard
Feedback Window: Disabled
Show Picture: N/A
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 300 frames
Selected Profile: None
Bidirectional Encoding: Unchecked
1st Pass Encode Speed: 07Min 54Sec

2nd Pass
Performance/Quality: Slowest
Feedback Window: Disabled
Show Picture: N/A
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 300 frames
Selected Profile: None
Bidirectional Encoding: Unchecked
2nd Pass Encode Speed: 58Min 28Sec

File Size: 29,109KB (28.42MB)

------------------------

Conclusion: -
Much better but unfortunately still not as good as WMV9 VCM. Even when viewing the output via the DivX Player 2.1

[SeeMoreDigital]

Is there any chance of enabling the old Mp4 output capability in future versions of the application?

Quite a few of us would like to create DivX quality Mpeg4 video streams with AAC / AAC+ audio!

[Darrius "Junto" Thompson]

Originally posted by SeeMoreDigital
Is there any chance of enabling the old Mp4 output capability in future versions of the application?

Quite a few of us would like to create DivX quality Mpeg4 video streams with AAC / AAC+ audio!

We can't do this from within the codec again. This caused quite a bit of problems both technical and product. Obviously one product issue is that the file won't be decodeable on and DivX Certified Hardware device so we don't want general users who don't understand this compatibility issue to create these files with the risk of thinking it would play on these devices. I haven't tried it in a while but I believe the MPEG4IP project had a command line app that was pretty fast at rewrapping a .avi to .mp4. Yepp just checked. Not sure how compliant it currently is but if they are keeping it up to date then it will might be more compliant than anything we might be able to leak out to you since we haven't updated ours in quite a few months.

Why the interest in the MP4 file format now?

http://mpeg4ip.sourceforge.net/faq/index.php#Divx

Darrius

[LordIntruder]

Hi SeeMoreDigital :)

I didn't even notice the "max keyframe interval" is set to 768 by default!!! I was a bit confused with the 80% to even notice this 768 figure! :(

Gosh, 768 on my PAL dvd 25fps = 30sec without any keyframe at worst.

I restore all the default config and now we retrieve our good old values. :) This is why you now get quality improvement over your first tests I suppose, you where with the default settings right?

[SeeMoreDigital]

Thanks for the quick reply Darrius,

My interest in MP4 is more to do with the container. I really like the DivX video format but I would like to experiment with AAC audio. Which is not possible with the AVI container.

In my opinion AAC audio and more importantly AAC+ audio will take off with a vengence in the coming months. We may even see (or should I say hear) 6Ch AAC/+ soon!

Quite a few people are generating AAC/+ test encodes at just 64kbps. And have reported favourable results. And since Mp3pro is unlikely to appear alongside encoding applications and players (even your own) then AAC and the Mp4 container seems the way forward.

As you are aware both RealMedia and WMV9 audio sounds alot better than Mp3 at 64kbps. And 6Ch audio is also possible (admittedly at 128kbps) with these codecs too.

DivX video is improving, your latest beta codecs prove that. But please don't forget about the audio. Not everybody wants AC3!

[DigitAl56K]

Remember that when quality testing, you must configure the decoder correctly. This might mean disabling the automatic post processing, setting full deblocking and deringing, and if you intend to scale the video (double size/fullscreen) you should have "overlay extended" and "yuv extended" enabled also so that your graphics card filters the output as it would for WM9 and that colourspace conversions are avoided.

[Gej]

It seems that there are some issue with the installer setting some default value, I suggest that you click on the "default settings" inside the codec before attempting an encoding, just to make sure that there is no issue (like the 768 frame keyframes interval that is, for sure, a little too much)

[bond]

in my tests

1) no mv file was written
2) i couldnt do a second pass - divx tells that there is something wrong with the source (the source image format isnt acceptable - error code -2)
i used (vob -> d2v -> mpegdecoder)

[SeeMoreDigital]

Hi DigitAl56K

Originally posted by DigitAl56K
Remember that when quality testing, you must configure the decoder correctly. This might mean disabling the automatic post processing, setting full deblocking and deringing, and if you intend to scale the video (double size/fullscreen) you should have "overlay extended" and "yuv extended" enabled also so that your graphics card filters the output as it would for WM9 and that colourspace conversions are avoided.

Well we have managed to view our DivX and WMV9 VCM encodes on a 42" plasma screen today via Sigma Xcard (using the Jove Player). And we also veiwed the same files on the same screen using our ATI cards VGA output.

On both occasions the WMV9 encode looked better at this bitrate.

I am happy to use any other suggested settings as they are found.
I am also happy to mail CD-R's of my tests to anybody who's genuienly interested.

[temporance]

@SeeMoreDigital,
In my tests, I find the quality of WMV9 VCM to be more variable than other codecs (can see thsi on a plot of PSNR). It also seems to start off with a higher quality which reduces as the clip goes on.... make sure you take a look at frames later in teh clip when comparing.

On your Mahini settings, what about Psychovisual?

[SeeMoreDigital]

Hi temporance,

In my first tests I've not used any psy. However I'm lucky that at work there are five of us (or more sometimes) that are able to give an opinion about an encode.

Many encodes are also generated on more than one PC. So there's no problems with say, codec clash on any given PC!

I'm going to try some more tests tomorrow with Manihi using the same keyframes interval as WMV9's 8000ms (8 seconds), which equals 200 frames.

Cheers

[DigitAl56K]

Ok, more information:

Gej tells me that the reason QPel is currently running so much faster is that the new RD algorithm is not enabled for QPel.

This means that slow/slowest modes (which feature the RD algorithm) are only available for half-pel, and that you will have to put up with slow encoding for now in order to test them.

If you have been testing with QPel and experienced a lower quality than WM9, this may be why.

[SeeMoreDigital]

OK. I've generated some more DivX 'Manihi' files today using settings that are as close to M$'s WMV9 VCM encoder as I could.

My results are as follows: -



Source 'Video Only' File Information

Source 'Video Only' File Information
Selected Movie: StarWars 2 PAL
Selected Chapter: 41
Clip RunTime: 06m 17s (377.24 secs)
Total Frames: 9431
Pixel Size: 720x576
Video Type: Mpeg2 (M2V)
Field Type: Progressive
Output AR: 16:9 (1.77:1)
Image AR: 2.35:1
File Size: 243,030KB (237.33MB)

-------------------------------------------------------
-------------------------------------------------------

DivX Encode Information

Application Used: MpegMediator 1.5
Output Pixel Size: 720x576 Anamorphic
Codec Used: DivX Manihi
Bitrate Used: 627kbps
Number of Passes: 2 VBR


First Pass
Performance/Quality: Standard
Feedback Window: Disabled
Show Picture: N/A
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 200 frames
Selected Profile: None
Bidirectional Encoding: Unchecked
1st Pass Encode Speed: 07Min 54Sec


Second Pass
Performance/Quality: Slowest
Feedback Window: Disabled
Show Picture: N/A
Psychovisual Enhanc: Disabled
Enable Crop: Unchecked
Enable Resize: Unchecked
Pre Processing Source: Unchecked
Scene change threshold: 50%
Source Interlace: Encode as Progressive
Max Keyframe Interval: 200 frames
Selected Profile: None
Bidirectional Encoding: Unchecked
2nd Pass Encode Speed: 59Min 10Sec

File Size: 29,107KB (28.42MB)

-------------------------------------------------------
-------------------------------------------------------

WMV9 VCM Encode Information

Application Used: MpegMediator 1.5
Output Pixel Size: 720x576 Anamorphic
Codec Used: WMV9 VCM 'Latest Release'
Bitrate Used: 615kbps
Number of Passes: 2 VBR


First Pass
Under 'Compression' Tab: -
Decoder Complexity: Main
Performance: Full 5 'Better Quality'
Max Keyframe Interval: 8000ms (200 frames)
Log File: First pass - General info added

Under 'Pre-processing' Tab: -
Source Mode: Encode as Progressive
Frame rate downsamp: 1:1
Resize to: Unchecked
Enable cropping: Unchecked

Under 'Save/Load' Tab: -
All Presets: Not Used
1st Pass Encode Speed: 09Min 38Sec


Second Pass
Under 'Compression' Tab: -
Decoder Complexity: Main
Performance: Full 5 'Better Quality'
Max Keyframe Interval: 8000ms (200 frames)
Log File: Second pass - General info added

Under 'Pre-processing' Tab: -
Source Mode: Encode as Progressive
Frame rate downsamp: 1:1
Resize to: Unchecked
Enable cropping: Unchecked

Under 'Save/Load' Tab: -
All Presets: Not Used
2nd Pass Encode Speed: 74Min 54Sec

File Size: 29,096KB (28.42MB)

-------------------------------------------------------
-------------------------------------------------------

Conclusion: -
Sorry, but at this bitrate, in my opinion (and the opinion of my co-workers) the encoded image does not look as good as WMV9 VCM. That's not to say it's poor, because it's not poor by any stretch of the imagination. Indeed it far exceeds the current version of DivX Pro 5.0.5 and produces images that look slightly better and encode faster than Kauehi. It even encodes faster than WMV9 VCM!

And as I mentioned before I really like the new GUI. I'm very pleased with the results and so is my Xcard. And who knows, when Sigma release their new drivers (which will be available very soon by all accounts) the images on TV screen may look even better!

Now, I realize ofcourse that not everybody likes to encode at low bitrates. And once you get above 950-1000kbps DivX Manihi really shines. Indeed at 1500-2000kbps a 2pass VBR encode looks better than some first generation DVD's and even most of SkyDigital's output in the UK today!

Great work you guys and thanks!

[temporance]

@SeeMoreDigital, a couple of questions:

A closed question... what postprocessing are you using for your comparison?



And a leading question... if I was an untrained viewer, which video would I like the best?

[Untrained viewers aren't sensitized to blocks like us "pros" and prefer the sharpest looking video, even if it has more blocking because [i]blocks look sharp -- this explains your opinions of Sky Digital!]

Edit: another question: what's the CPU load of playback for DivX Manihilate and WMV9?

[Fr4nz]

Why you don't use bidirectional encoding with Manihi?? IMHO It could enhance the quality...

[SeeMoreDigital]

Hi temporance

A closed question... what postprocessing are you using for your comparison?

I (or should I say we) have tried the following post-processing settings: -

With DivX
Deblocking: Max / Deringing: Max. And we've disabled Post Processing too.

With WMV9
We've tried post-processing at default. And we've disabled it in the registry

I understand what you mean about 'untrained' viewers. But that's not so much the case with me as I've been in this field of work for over twenty years now. Sure, I don't confess to know everything, (I'm more a hardware man myself) that's why we are all here on the forum.

That said, I agree that it's a common mistake for people judge their encodes by sitting too close to their monitors. But as I said before that's why we view them on a 42" plasma screen, in the correct light and use a variety of different PC - plasma output connections.

Now, when it comes to the SkyDigital quote. I think it's fair to say that the quality of the output (BBC1, BBC2, ITV1, ITV2, Ch4 and Five) has dropped. I've noticed this more and more over recent months and when I switch over to my terrestrial digtal box and watch the same output the image appears to be better.

Shame really, because it used to be the other way around. My only conclusion is that the drop in SkyDigital's quality is due to the terrestrial broadcasters trying to squeeze more regional channel variations out of the same transponders!

Oh, and as for the CPU load. For some reason WMV9 VCM uses less. Which is strange because when the same file is encoded as an .wmv stream it uses more. More even than DivX.

MingCL at M$ is aware of this, as I posed this question to him on a previous thread.

I'll mail you some of our tests if you like!

[temporance]

By "untrained viewers" I meant people that just like to watch TV and movies, not compress them or talk about video quality. These are the lowest common denominator that make up 99% of Sky's customers. They'd prefer blocky to soft.

[SeeMoreDigital]

Ha Ha,

I'd have to agree with you there.

But what can SkyDigital or any other digital customers do? Back in 1998 they were given a 'quality' product to start with. Todays decoders are better than ever and yet the quality of the broadcasted image is poorer than ever.

It's a conundrum, a double edged sword, six of one and half a dozen of the other. It's a pain in the ar*e, is what it is!

[Sumster]

Just finished encoding "How to Lose a Guy in 10 Days". It was a 640x480 (4:3 fullscreen) encode using lancos resize. 2-CD rip so the bitrate was almost 1500. B-frames on, GMC off, PVE off. Turn on WRITE MV on first pass and then READ/UPDATE MV on second pass. Used the "SLOW" setting for both.

1) Averaged about 2.0 fps on my Athlon 1800+ with 512 mb.... took about 23 hours per pass (total of 45 hours for both passes).

2) No speed increase on the second pass :(. No MV file was written so I am not sure if my settings should have been different. I assumed the second pass would be much quicker by re-using the motion vectors.

3)Quality was phenomenal... the best quality rip ever. PSNR calculations to follow.

4) Love the dialog box (I had picture and graph DISABLED during the encode). What does "SAD" mean? What are the grey boxes in "Compensated Mode"?

Take care..

Sumster

[Sagittaire]

My personal test: Visual and PSNR test with RV9 EHQ, XviD, DivX, WMV9

http://forum.doom9.org/showthread.php?s=&threadid=57687&perpage=20&pagenumber=1

Manihi standard mode is better than XviD Koepi 24/06/03 ...

SAD is an fonction of Motion Estimation.

[LordIntruder]

temporance:

"untrained viewers"....They'd prefer blocky to soft

I don't see why untrained users would love sharp videos and so call pro would love blurry ones? You prefer a blurry video that means blurry details, etc... rather than a sharp image? Well I never use post-processing because I don't want a modified video. I do not use any post-pro to blur nor sharper it. Unless the video is bad, macroblocked, etc... so I may used post-pro to blur it a bit otherwise not.

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.

[Fr4nz]

@ SeeMoreDigital: 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...!

[V-tec]

Menihi produces a very good quality encodings, but is good for test only, (20+20+20+...+n) min to encode 4 min of video is not good...
I hope that in final version it's run faster

[Sagittaire]

Manihi standard mode is a very faster mode (same speed of DivX 5.05) ...

[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.

[Fr4nz]

I ripped a lot of DVDs for backup reasons (I have a kiss DP-450 player, so I can enjoy Divx in my parlor ;) ). Anyway artifacts are really less noticeable if you watch your divx on Tvs rather than on monitors. For my eyes I find that "sufficient" quality is at ~900kbps, beyond 1100kbps good quality and over 1400 great quality (with these bitrates you can put one hour of film on a single 700mb CD, and this is great!). When I encode at ~900 I usually do 3 passes with psycho on medium and b-frames activated.

I tried Kauehi some days ago at low bitrates and I found it very great altough it should be more optimized in order to obtain smaller time encodings. Manihi is so much slow that I'll wait the next beta release...or the next CPU :cool:

[SeeMoreDigital]

Hi Fr4nz,

You know, there are a lot of people on the forum that don't take people like us too seriously (people who like to rip entire movies to a 700MB CD-R).

Unlike you I don't have a Kiss player I have an Xcard and I've generated quite good looking encodes (for viewing on a TV) well below 900kbps.

Infact just to drive people absolutely mad. Here is a brief list of the 'Bitrate per min per 700MB CD-R'

For 60mins A/V per CD-R with audio at 64kbps. Set the video to 1556kbps
For 60mins A/V per CD-R with audio at 96kbps. Set the video to 1524kbps
For 90mins A/V per CD-R with audio at 64kbps. Set the video to 1016kbps
For 90mins A/V per CD-R with audio at 96kbps. Set the video to 984kbps
For 120mins A/V per CD-R with audio at 64kbps. Set the video to 746kbps
For 120mins A/V per CD-R with audio at 96kbps. Set the video to 714kbps
For 150mins A/V per CD-R with audio at 64kbps. Set the video to 584kbps
For 150mins A/V per CD-R with audio at 96kbps. Set the video to 552kbps

The longest film I have encoded to fit onto a 700MB CD-R is Star Wars 2 at 137mins (in full anamorphic 720x576).

Love it or hate it - DivX still looks better than VHS or even S-VHS tape - even at low bitrates!

[dTb]

Debate over what is or isn't a low bitrate is pointless, what's high for one video is low for another. I really wish people would stop using bitrate as an indicator for video quality.

[Fr4nz]

Well when you start to see enormous blocks it's a matter of fact, not a matter of eyes...

[SeeMoreDigital]

OK people. I can see (no pun intended) that this could quickly turn into one of those heated 'quality -v- in my opinion' type arguments. So please don't start falling out.

Anyway, I recon in a few years time. The next generation/our kids will be laughing at us....... I can hear it now.......

'Hey, what's this'?

'Oh, it's just another one of those 352x240 video clips on my Dads PC'!

'Jeez, just look at the crappy quality the used to put up with in their day'

Know what I mean guys!

I'm off now. Back into the work void. As I'm about to save another customers, old treasured eight minute 15fps 'black and white' memories onto a shiny digital disc!

Cheers and be happy. As all things will change. Sooner than you think!

[Fr4nz]

I'm just waiting for Manihi beta 2 now ;-))))

[SeeMoreDigital]

Hi Fr4nz,

You know, after reading DigitAl56K's posts. I get the feeling that there won't be another DivX beta.

I think DivX might be ready now to 'go for it' with a new release!

[Fr4nz]

So let's hope that this new release will be very very faster than the Manihi beta 1, cause it really has huge encoding times.

[Acaila]

As DigitAl56K has shown in his posts/tests DivX Manihi is NOT slow. It's just as fast as previous versions of the codec UNLESS you enable the settings that were meant to slow things down to squeeze some extra quality out of it.

Just be glad you have the choice of getting extra quality (which will always come at the expense of longer encoding times), we didn't have that choice with previous releases. If you don't like the lower speed, just use the codec on 'standard' mode and you won't loose anything compared to earlier versions (but you won't gain much either).

And I fully agree with what dTb said about bitrate being an invalid indicator for quality. Too bad it has become so much a part of society to express compression in bitrate, because although bitrate and quality are related, knowing one says absolutely nothing about the other.

[SeeMoreDigital]

A good reply Acaila,

I've been saying for quite some time that you can get away with far less bits without sacrificing too much quality. Especially if your viewing the output on a TV screen instead of a PC monitor.

How quickly we forget that before DVD, our 'on mass' quality image benchmark was VHS.

It's a shame that DivX is the only company brave enough to license their software for use in a hardware player. And the sooner more affordable DivX players become available the better.

DivX would certainly benifit itself, by encoraging more users to get away from the PC and onto the TV!

Anyway, that's my two cents worth!

[Fr4nz]

Well in "standard" mode manihi goes at about 10fps/sec..and this is TOO MUCH SLOW compared to the 21fps/sec of the "slowest" mode of 5.0.5 (same options enabled).

[SeeMoreDigital]

Well Fr4nz,

You're right you should not be encoding as slow as that.

If I were you, I would press the default button, then go thru the various screens and deselect all the options such as, bi-di encoding, psy etc and do a test encode!

Please report back!

[silver_cpu]

SeeMoreDigital:

I think the framerates he's talking about are *with* b frames *and* GMC. Believe me, I did it myself just now. I get about 10-15fps on 5.05 with my 950mhz system (both of those features enabled), and about 2-4, if I'm lucky (normally 2-) with Manihi. Crazy encoding times...

Is the speed-boosted alpha to come out as a beta soon? Or does anyone know if they're waiting to bundle more updates/fixes into the next beta, rather than release it with just that update?

[SeeMoreDigital]

Yes,

There are problems with the Manihi Beta codec if you enable these functions (bi-di and GMC). These have been noted by DivX and appear to have been resolved - see DigitAl56K's posts and 'round 2' tests.

If you disable these functions for the time being your encodes should be on a par with DivX 5.0.5.

I have to admit I did not come across these anomolies myself as I don't (or very rarely) use these settings.

Cheers

[Fr4nz]

Guys, I use only b-frames, not GMC or QPEL.

@SeeMore: I find b-frames very useful if not really nedeed if you want to achieve good quality when you encode at low-bitrates, because of the nature of b-frames (prediction, etc.).

Disabling b-frames means less quality...

[SeeMoreDigital]

Well not necessarily. Bi-directional can make a difference if you're encoding at low bitrates. But not too much of a difference if your creating your encodes for viewing on your TV via Kiss player.

I can't see any difference on a TV with or without bi-di!

[Fr4nz]

I like to aim at perfection ;) :sly:

[DigitAl56K]

Manihi Beta 2 should be out soon with fixes for the MV file (expect major speed increases such as in my R2 doc) and the psycho-vis.

If you're still testing Manihi Beta 1 then I recommend you avoid the psycho-vis because it can cause severe artifacting/memory leaks/crashes. Gej has already fixed this though amongst some other bugs.

Manihi is looking *very* good though so hopefully it won't be too long until the release version! (I think I recall reading the beta feedback period runs up until the 15th).

[DigitAl56K]

@SeeMoreDigital:

Although you might not see the difference in quality b-frames will give you on your kiss/tv setup right now, just wait a few years until we're all using the high-def profile with high-def certified players and HDTV's :) Think of the future :)

[SeeMoreDigital]

Originally posted by DigitAl56K
Although you might not see the difference in quality b-frames will give you on your kiss/tv setup right now, just wait a few years until we're all using the high-def profile with high-def certified players and HDTV's :) Think of the future :)
Yes, I've already experimented and generated some high-def DivX encodes.

One of my tests involved transcoding the 1440x816 WMV9 Terminator trailer using DrDivX. Unfortunately neither my Sigma's Xcard or PC could play back such an encode properly - not enough processing power!

According to Sigma, the largest video input frame size it can handle is 720x576. So out went my 1024x576 (true 16:9) test encodes as well. Which was a great shame, because these look really great on a PC.

I would like to know if Kiss users have tried such tests as it may just be a Sigma thing!

But like you say.......... Think of the future!

EDIT...
I've been meaning to ask. Do you know which was the last version of DivX that could generate .Mp4 file extensions?

Cheers

[DigitAl56K]

The last version of DivX including the option to write output to an MP4 file was DivX5.02.

[SeeMoreDigital]

Thanks DigitAl56K

Originally posted by DigitAl56K
The last version of DivX including the option to write output to an MP4 file was DivX5.02.

Do you know if it was possible to generate 2pass Mp4 VBR encodes with this version?

[DigitAl56K]

Yes: All DivX modes are VBR, and it was possible to convert any valid DivX or DivX+MP3 AVI file to MP4 from the encoder dialogue, as well as writing video directly to an MP4 file during encoding.

[Flame10]

I have a request, can you guys please make the encoding config window a bit smaller in height as ppl like me who tend to work in 800x600 res can't see the whole dialog as it is more than 600px. Maybe if the DivX [Manihi] Logo is shortened a bit.

BTW, I get a crash in divx.dll everytime I try to encode w/o any/Uncompressed audio stream using Virtualdub, this seems to be happening only with Divx Kauehi/Manihi, not with any earlier ones.

Edit Sorry, for late posting, Beta 2 Kaukura is already out, I think this problem will be solved in it