DivX Kaukura Codec Beta

[Gej]

This is the last stop before reaching our final destination. The island we are going to explore today is Kaukura.

This beta version offer stability improvements, cosmetic fixes and speed optimization over Manihi. Give it a test run and provide us with your feedback.

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



What's New:

* Psychovisual mode:
- Speed Optimization
- Psychovisual mode is now capable of operating on Chroma. This option is not enabled by default for performance reasons. In order to enable it you must create an empty file in C:\ called "DivxPvShapingChroma.txt" for "fast" mode and "DivxPvSimpleChroma.txt" for slow mode. Results show a very little gain (around 1-2%) in JND tests.

What's Fixed:

- A bug with different number of frames between passes with VirtualDub
- GUI improvements
- A bug with MV (reuse) and psychovisual mode used together
- Installer issues
- Crashes involving setting crop/resize values

[dTb]

Cool, I'll get stuck into some testing monday.

One question, will the old psychovisual mode be available in the final release? I primarily used it when encoding credits where I thought it helped a lot in improving the overall quality at the low bitrates I was using.
The way quantisers were used in the old mode seemed to work well with credits, I'll do some testing with the new pve to see how it goes.

[phrentec]

Hello Gej. Before reaching your final destination is there any chance you can let DivX operate in a color depth of 8-bit( or 256 colors)? It seems that DivX (and all other compression codecs I can think of) can't work in just 8bit of color and instead works in 24 and 32 bit. In fact I think DivX doesn't even work in 16bit from what I'm seeing here. Well in many cases video looks better dithered(ie 256 colors) instead of blocky when at lower bitrates.
Thanks.
Regards.

[Gej]

No way DivX or other codec works in 8bit (they actually not even work in RGB 16bit or 24bit, but in 12bit YUV)

Sorry, but if you want genuine 8bit suport you have to use cinepak !

[phrentec]

thanks for the clarification.

[nuked]

original 2 pass still produces files that are less than 1/3 of correct size.

[nuked]

For the record I'm getting about 4.5 frames per second on slow with normal preprocessing, bframes, no gmc, no qpel, no physc at 720x 304 resolution on a 2.0 ghz p4. Definitely faster than manihi but still too slow for me. I wont use slow mode unless it or my hardware gets to about twice that.

[SeeMoreDigital]

Blimey!

I've just carried out a short encoding speed test.

Source
Harry Potter 2 trailer @ 02m08s

01 test @ 570kbps
Settings Used - None
1st pass 'standard' - 02m10s
2nd pass 'slowest' - 00m56s

02 test @ 570kbps
Settings used - BiDi only
1st pass 'standard' - 03m07s
2nd pass 'slowest' - 12m03s

03 test @ 570kbps
Settings used - GMC only
1st pass 'standard' - 03m52s
2nd pass 'slowest' - 00m58s

So on this basis. If you don't use any settings at all. It will encode faster than a 'Borg cube at maximum warp'!

Images are not too bad either..... More detailed tests to follow!

EDIT...
Still not sure if the post-processing works properly.

[nuked]

Wow, the first test is indeed impressive. Bidi really slows it down by like a factor of 12!? Even if it does though... is it really worth ditching Bidi to get the improvements of slow mode?

[SeeMoreDigital]

Well, this is indeed strange.

I've tried twice now to generate an DivX Kaukura encode of StarWars2 with video at 647kbps and Mp3 audio at 64kbps (24,000Hz).

The 1st pass using 'standard' setting took 02h 38m 10s.
But the 2nd pass kept failing. Generating an 'Mpeg audio sync error' after 173,489KB had been encoded.

I tried using both the 'standard' and 'slowest' settings for the 2nd pass - but no joy as yet!

I will try again. However this time I will set the audio to 96kbps(48,000Hz).

It will be interesting to see what happens now!

[silver_cpu]

Most likely, the resampling will fix your problem. At 96kbps, the mp3 encoder resamples down to 32khz. I think the speed improvements are phenomenal, they really do make a big difference. If we could see similar improvements in b-frame compression, DivX would enter a whole new world of professional encoding. Thanks, DivX team! Keep up the good work :)

Edit: BTW, is it possible to make the first two passes using no GMC, no qPel, and no Bframes, and then include them in the last pass? Or do they need to be in each pass to work correctly?

[SeeMoreDigital]

Originally posted by silver_cpu
Most likely, the resampling will fix your problem. At 96kbps, the mp3 encoder resamples down to 32khz. I think the speed improvements are phenomenal, they really do make a big difference.
Yep that was my thought. Strange that Kauihi did'nt suffer from this problem. I don't know about Manihi, as I never tried it at 64kbps!

Originally posted by silver_cpu
Is it possible to make the first two passes using no GMC, no qPel, and no Bframes, and then include them in the last pass? Or do they need to be in each pass to work correctly?
Now I'm glad you've asked this because I was thinking the same. I was also thinking that if the Gej's (and DigitAl56K's) info is correct regarding the first pass settings. ie don't bother using 'slow' and 'slowest' modes. Why bother having them at all!

[Gej]

Now I'm glad you've asked this because I was thinking the same. I was also thinking that if the Gej's (and DigitAl56K's) info is correct regarding the first pass settings. ie don't bother using 'slow' and 'slowest' modes. Why bother having them at all!

The 1st pass generate a log file that record several data about the video to be encoded, 1st pass doesn't actually generate any watchable file. So using "standard" during the 1st will generate a log file and gather the required data (though theses will not be as accurate than if generated using "slow" or "slowest" but the difference is really really low thus can be neglected)
Then using this log file during the 2nd pass to actually encode using "slow" or "slowest" mode can be a huge time saver, and still using all the advantages of the advanced modes in term of visual quality.
WARNING: YOU CAN'T DO THAT IF YOU USE A MV FILE !!
If you plan to use a MV file during the Nth pass, you HAVE to use the same performance settings.

original 2 pass still produces files that are less than 1/3 of correct size.

Yes, actually something is broken on the original RC, It'll not be fixed as it'll be removed in the final release.


My favorite’s settings so far:

Common setting:

Home Theater profile: on
B frames: on
Psy: fast (no chroma hack)
NO MV file

1st pass
performance: Standard

2nd pass
performance: Slowest

(okay the 2nd pass is insanely long, but the quality is really great, the amount of blockyness is REALLY reduced with "slowest" and Psy "fast", and when playing on a 1st generation DivX enabled DVD player (they do not have any deblocking) even a 2 hour movie on 1cd do not look blocky at all during the higher action scenes)

[nuked]

"Yes, actually something is broken on the original RC, It'll not be fixed as it'll be removed in the final release."


:( I guess I'll smile again anyway though if these new speeds become available with b-frames, but I'm still stuck with 2 pass for now and original was better.

edit: I meant stuck with standard 2 pass.

[Gej]

I'm not sure original RC was better, honestly, the original has the fatal disadvantage not to take care of the VBV, that make it rather dangerous when it come to hardware compatibility.

If only difference between original and new, beside the VBV enforcement is the fact that original 2pass mode was slightly biased toward low motion (it allocate proportionally more bit to low motion part than Nth pass RC does when motion modulation is set on 0)
If you want to achieve the same effect you should use the bitrate modulation to value around 0.10-0.15.

[silver_cpu]

So if I wanted to use an MV file, then I'd need to make sure that all passes, including the last, were encoded at the same speed (slowest, or standard, or whathaveyou), and that qpel, gmc, and bframe settings would have to be the same for each pass? Or could I enable those after the log file was created?

[Gej]

No, no, no

Qpel, GMC and B frames must be consistent from passes to passes, MV reuse or not.

[silver_cpu]

ok, thanks for the info :)

Edit: But let's say I didn't want to wait for 3 "slowest" passes. Is "standard" really quite decent? Or do you get a substantially noticeable difference when you encode in "slowest" mode? I've got about 800kbps in my video stream.

[Gej]

I rather just do 2 passes and use "Slow" than 3 passes and use "standard"
check here a PSNR graph of the differences:

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

Slow and slower really does make a difference (as well as PSY "fast")

[SeeMoreDigital]

My StarWars 2 test encode is now finished. I did'nt use any Qpel, GMC and BiDi etc. Just used the read/write log and MV file.

Source
StarWars 2 02h 16m 39s (8199sec) PAL

Video @ 750kbps
Audio @ 96kbps
Settings Used - None
1st pass 'standard' - 02h 38m 01s
2nd pass 'slowest' - 01h 31m 12s
3rd pass 'slowest' - 01h 32m 06s

I have to say that I am very impressed with the results. The encoded image is much cleaner than DivXPro5.0.5. And as you can see I managed to do 3 passes in around the same time as I would have expected to do 2!

I appreciate that most users prefer to use BiDi (that's B-frames for you newbies). So not to be put off, I'm going to generate the encode again with Gej's favourite setting ie Home Theater profile: on / B frames: on / Psy: fast (no chroma hack)/ NO MV file / 1st pass: Standard / 2nd pass: Slowest.

Cheers

[Sumster]

Gej...

Would you suggest doing the following. Running in "STANDARD" mode for 4 passes USING the MV file, and then do the final pass in SLOWEST without the MV file?? That way, the final pass is not dependent on the MV from the previous 'standard' passes, but the standard passes will all be quick (and allow more info through the rate algorithm). Of course, ALL passes would have to be the same in regard to B-frames, Qpel, etc.

Thanks,

Sumster

[SeeMoreDigital]

OK boys and girls.

I've just carried out two more tests with Kaukura. Again without using any Qpel, GMC and BiDi etc. Just creating an read/write log and MV file.

This time I encoded Planet Of The Apes.

For my first test I decided to encode the 1st pass using 'standard' and the 2nd and 3rd passes in 'standard' also.

For my second test I decided to encode the 1st pass using 'standard' and the 2nd and 3rd passes in 'slowest' mode.

I was expecting the second test to take longer to do than the first test but I was very surprised when they took the same time to encode. The other strange thing is that they looked exactly the same. Which inturn also looked exactly the same as my 2pass Manihi encode - It was even the same file size!

Gej, somebody, anybody, please explain?

[Gej]

MV file stand for Motion Vector file, it's a file that contain all reference to all motion vectors for all blocks in all frames. If you generate this file during the 1st pass with performance “standard” when you enable MV reuse during the Nth passes, even if you select performance “slowest” it will use the data from the file, so “slowest” will be useless.

[SeeMoreDigital]

Originally posted by Gej
MV file stand for Motion Vector file, it's a file that contain all reference to all motion vectors for all blocks in all frames. If you generate this file during the 1st pass with performance “standard” when you enable MV reuse during the Nth passes, even if you select performance “slowest” it will use the data from the file, so “slowest” will be useless.
So, are you also saying that when you encode using 'MV' that it's pointless to use more than 2 passes?

And don't you guy's ever stop working?

[sapient]

From what gej is saying, I figure that the speed tests that digital56k did some days ago and got us so excited are actually invalid. If I remember corectly he did 4 passes in standard and a final one in slowest using the mv file. If I understood gej correctly, that would actually result in a fifth standard pass. My own tests show that kaukura is still very slow, with or without b-frames (second pass @ slowest w/ psy fast, w/o b-frames = 3xtime of 1st pass standard)

sapient

[Flame10]

Here is a strange issue.

Whenever I try to do a batch directory processing or running a batch .vcf file processing in Virtualdub, it crashes in divx.dll, now this crash also happens if a single file is opened and just after loading a Configuration file the encoding is started, however just by choosing the Audio codec manually, the encoding works w/o any crash. I'm using Mp3 codec and the setting is surely stored in the .VCF config file, as it remains autoselected when I try to manually configure the audio codec again. I was thinking that this may be an issue with the radium codec I'm using but this crash never happens with Divx 5.05 version or prior, so it seems that some sort of bug must have cropped in.

Gej/any other developer can you please check this out.

[Sumster]

Gej...

can you use MV re-use for the first 4 passes in standard, and then in the 5th "slowest" pass simply NOT use MV?? Then, at least, you are using MV to speed up the first four passes.

[SeeMoreDigital]

Originally posted by sapient
...My own tests show that kaukura is still very slow, with or without b-frames (second pass @ slowest w/ psy fast, w/o b-frames = 3xtime of 1st pass standard)
This is a little odd sapient. When I did some speed tests, without Bi-Di, GMC, Qpel etc I found Kaukura to be the fastest DivX codec ever. Are you sure you've deselected everything including the Profile, Psychovisual enhancements and disabled the feedback window?

If you missed them, my tests were as follows: -

Source
Harry Potter 2 trailer @ 02m08s

01 test @ 570kbps
Settings Used - None (except Write/Read Log/MV file)
1st pass 'standard' - 02m10s
2nd pass 'slowest' - 00m56s

02 test @ 570kbps
Settings used - BiDi & Write/Read Log/MV file
1st pass 'standard' - 03m07s
2nd pass 'slowest' - 12m03s

03 test @ 570kbps
Settings used - GMC & Write/Read Log/MV file
1st pass 'standard' - 03m52s
2nd pass 'slowest' - 00m58s

As you can see the second pass and subsequent passes are really quick!

[SeeMoreDigital]

Originally posted by Flame10
Here is a strange issue.

Whenever I try to do a batch directory processing or running a batch .vcf file processing in Virtualdub, it crashes in divx.dll, now this crash also happens if a single file is opened and just after loading a Configuration file the encoding is started, however just by choosing the Audio codec manually, the encoding works w/o any crash. I'm using Mp3 codec and the setting is surely stored in the .VCF config file, as it remains autoselected when I try to manually configure the audio codec again. I was thinking that this may be an issue with the radium codec I'm using but this crash never happens with Divx 5.05 version or prior, so it seems that some sort of bug must have cropped in.

Gej/any other developer can you please check this out.

There is something different about how both Manihi and Kaukura encode audio. I too have the Radium codec installed and experienced a problem. But mine was encoding audio at just 64kbps - which I have to admit not alot of people here would do!

[sapient]

@seemoredigital

You are using the MV file! This means, according to gej, that your second pass is actually done at standard, not slowest. And as I said I also used psy fast, but nothing else

[BRMSlash]

Well, it took me a few attempts to actually get this to install. As soon as the installer tried to access the registry, the mouse pointer sat there flashing between normal and the hour glass and progressed no further. I then tried installing it on my old computer, which installed just fine. So I returned back to my new computer and ran Ad-aware and it found Gator from my previous installation of divx5.05pro, which is fine. I then deleted all gator files that Ad-aware found. DivX Kaukura then installed fine. I also tried with Manahi and I had the same problem until I deleted Gator(the Gator folder was the critical thing I found), any of the old official releases had no problem installing with Gator though. Weird?

I can handle that slight annoyance, but now it is impossible for me to finish a 1-st multipass with Kaukura. My computer just locks up and I have to hard reboot. I am using GordianKnot 0.28.5.2 to create the avs. I then add ConvertToRGB32() to the last line (this reduces red blockyness greatly). I then queue up two passes using Gej's favourite settings in either Vdub or Vdubmod. It then locks my computer at a random spot in the first pass. I revert to Manahi and then all is fine, no more lock-ups. This is very annoying, especially when this is close to the "final destination". Maybe it's just my machine, but it's only a few weeks old (AthlonXP3000+)? Any ideas anyone? Any assistance would be greatly appreciated.

[SeeMoreDigital]

sapient,

Yes, I did use the MV file setting to generate my 2 an 3 pass test file encodes.

As I said before. Just have a go at generating some short test encodes without using any settings.

Then introduce various settings, one at a time. To see how it affects the speed of your encodes.

Cheers

[BRMSlash]

I take back what I said about Manahi working. My comp just froze around 85%. I think it must be the new bios I updated to. Damn you EPOX. I will investigate further, I had Manahi working last week.

[sapient]

@SeeMoreDigital

I will try what you suggest as soon as I get home.

Your results indicate that standard encoding with hinted mv results in a great speed increase. But slowest mode is still very slow. You can't speed it up using mv, or you 'll end up doing a standard pass instead. You would have to do the 1st pass @ slowest wich would not help things. To sum up, if I understood gej correctly, the options for slowest right now are the following 2:
-1st pass standard, second pass slowest, no mv
-1st pass slowest, second pass slowest with mv

(@Gej - Am I correct?)

Both options require at least one full length, unaccelerated slowest pass that is still pretty darn slow. Adding b-frames to the mix seems to make things even slower. I will test this more thoroughly later today and report back.

sapient

[Fr4nz]

Yeah bidirectional encoding is slow like hell now!!! :(

[nuked]

Hey Gej.. see the link below for something I think would be a really neat feature to have in a final divx. Wouldn't it be wonderful if we could all quit worrying about screwed up hybrid telecine jobs? I hope this doesn't bend any cross posting rules too badly, but I'm not sure where to plant this idea to see if there is any interest. Maybe I'm just naive and crazy though. I think this would be a feature that people just don't realize how much they'd like cause they don't have it yet. Of course some support would be needed in dvd2avi and avisynth or such but it has to start with codecs I think.

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

by the way.. I've done minimal testing of the interlace support in kaukura (I assume it's the same as before) and I don't see it doing anything useful, in fact it increases file size of quality based encodes of both interlaced and telecined 30 fps content just a tiny bit over the progressive option. I still need to test on lower bit rates though to see if it improves visual quality. Some filters in the playback codec for swap, rate-doubling bob, and blend would be very nice too.

[SeeMoreDigital]

I found time today to carry out some more low-bitrate encode tests. However this time I decided not to create/use the MV log setting. The results are as follows: -

Source
Harry Potter 2 trailer @ 02m08s

04 test @ 570kbps
Settings Used - None, except Write/Read Log
1st pass 'standard' - 02m06s
2nd pass 'slowest' - 19m00s

05 test @ 570kbps
Settings used - BiDi only + Write/Read Log
1st pass 'standard' - 03m18s
2nd pass 'slowest' - 19m50s

06 test @ 570kbps
Settings used - GMC only + Write/Read Log
1st pass 'standard' - 02m50s
2nd pass 'slowest' - 20m21s

07 Gej test @ 570kbps
Settings used - Home Theater profile, Psy: fast + Write/Read Log, No MV file
1st pass 'standard' - 02m46s
2nd pass 'slowest' - 19m36s

This really does confirm what Fr4nz, sapient, etc and Gej have said about encoding with BiDi etc..... It's hellishly slow.

Even on my PC, a 2nd pass using the 'slowest' setting would take 10hours for ever 1hour of A/V. What a shame!

However, as I've said before, using the MV setting really does speed things up. And produces a very good looking image for viewing on a TV. When you begin to encode above 950kbps using MV alone, it's a totally different story...... As you obtain great looking encodes at fast encoding speeds!

I really like the idea of incorporating MV (motion vector) support. As this process makes far more sense to me than having to use a multitude of other settings!

But that's just my opinion!

[Gej]

When MV reuse is enabled, in the Nth pass it does not matter what performance is selected, In practice, MV reuse is disabled for B-frames, so the performance selected will be used to perform Motion Estimation for the B-frames.

[SeeMoreDigital]

Hi Gej

May I ask again please. Given that encoding with MV is very quick indeed, when no other settings are activated.

Is it pointless to use more than 2 passes?
Would using 'Psy: Fast' help?

Cheers

[silver_cpu]

Gej: are you saying that when we enable Bframes, the nth passes disregard the MV file? If so, one would wonder why, and if the MV file effectively replaces bframes, since it wouldn't need to estimate backwards...

Also, I'm very interested in what people are saying about the MV file.

When MV reuse is enabled, in the Nth pass it does not matter what performance is selected

So are you saying that no matter what performance setting you select on the second pass, the MV file dictates the quality setting for the encode (and therefore the quality setting is dependant on the MV file's data)? Or are you stating that the quality setting is independant of the MV file, and that it simply uses the data for its own processing purposes? If this were true, then all passes would need to be in the desired quality, i.e. "slowest."

And does it make any difference to encode for more than two passes, and what can the codec do in subsequent passes that it can't (or doesn't yet) do in the second?

[dTb]

Hmm, my understanding from what Gej has said is that the use of the mv file makes the performance setting irrelevant in an nth pass and that a b-frame will not use any mv info from the mv file and will therefore make use of whichever performance setting was selected to obtain this information.
Hope this clears things up for you silver_cpu, I'm fairly sure I've understood what Gej means but I guess he can clarify further if needed.

The Performance setting part makes sense to me, the motion estimation done determines the motion vector information stored in the mvinfo.bin file from my understanding. The purpose of this file is so that the process of determining this info is not repeated when it's not necessary. When the mvinfo.bin file is enabled the motion estimation may simply be disabled altogether during an nth pass, the rest of the work done by the codec probably remains the same regardless of the performance setting. I hope I'm making sense here.

From the b-frame part it seems that there's a possibility you can gain a benefit while using b-frames by setting the performance slider higher on an nth pass. I guess some testing would need to be done to decide if there is indeed any quality benefit and also if there is any speed benefit.

[silver_cpu]

So I guess my next test will be to guage quality with and without bframes at a certain bitrate. Anyone have a good idea on how to go about this in a good way?

[SeeMoreDigital]

silver_cpu
So I guess my next test will be to guage quality with and without bframes at a certain bitrate. Anyone have a good idea on how to go about this in a good way?
Well, as I've said previously, I've already carried out such tests (and more besides the ones posted). Which is why I'm a little confused about how to setup Kaukura's. Or should I really say I'm confused about which settings are useless/don't function when encoding with the MV log file.

Last night I posted a reply to one of Sagittaire's threads (in the 'new A/V formats section) which I think is relevant here:-
With regard to DivX Kaukuru I think it is DivX's finest codec so far.
However, this version has even more user settings than previous versions, which in my opinion will confuse many users. And as such cause much argument regarding 'what setting is the best to use etc'!

I've generated many low bitrate tests using all manor of Kaukuru's settings. But at the end of the day I would dump the lot and just set up the codec to write/read MV files - when you do this the encoder 'goes into warp drive'!

And there you have it..... I know it's only my opinion, but I really do think that most users will soon get bored/fed up with using the 'slowest' settings and only use the fastest method - ie write/read MV log files.

So I'm sure I'm not alone in wanting to know. When you use MV, what other settings are you able to use?

Come on Gej. Put me out of my misery!

[Fr4nz]

Gej optimizations for the new b-frames quantizations are really needed since bidi is too slow now.

[Acaila]

When you use MV, what other settings are you able to use?
1- When you use enable MV files during 2nd pass the codec will just copy those motion vectors, i.e. the codec will use whatever performance setting you've used during the 1st pass.

2- B-frames do not use the info from the MV file, so the B-frames will perform a new motion estimation/compensation at the performance setting you're using during the 2nd pass.

e.g.
1st pass: performance standard, disable B-frames, enable MV
2nd pass: performance slow, disable B-frames, enable MV (all frames will use same performance as 1st pass = standard)

1st pass: performance standard, enable B-frames, enable MV
2nd pass: performance slow, enable B-frames, enable MV (P-frames will use standard, B-frames will use slow performance setting)

And I disagree about the new versions having more settings, all it has is more performance options, it really doesn't take very long to understand what they do. But then I also think more control is usually better. For the newbies it's just a matter of not messing with the settings and using the defaults until you know what you're doing.

[SeeMoreDigital]

OK, I think I'm getting it.

Gej originally wrote...
"No, no, no. Qpel, GMC and B frames must be consistent from passes to passes, MV reuse or not."

And then he wrote...

"When MV reuse is enabled, in the Nth pass it does not matter what performance (setting) is selected. In practice, MV reuse is disabled for B-frames (BiDi), so the performance selected will be used to perform Motion Estimation for the B-frames".

Maybe the wording was a little confusing?


You mention the following setting: -
1st pass: performance standard, enable B-frames, enable MV
2nd pass: performance slow, enable B-frames, enable MV (P-frames will use standard, B-frames will use slow performance setting)

All of which I used during my second test. Using these settings was indeed faster than using no MV file.

Gej also wrote: -
"...I rather just do 2 passes and use "Slow" than 3 passes and use "standard"... Slow and slower really does make a difference (as well as PSY "fast")..."

I wonder if better encodes would be generated by using the following settings or would the benefits be too small: -
1st pass: performance slow, enable B-frames, enable MV
2nd pass: performance slow, enable B-frames, enable MV

I will do a speed test for this setting but it's obvious it will be long.

You also wrote: -
"And I disagree about the new versions having more settings, all it has is more performance options, it really doesn't take very long to understand what they do. But then I also think more control is usually better. For the newbies it's just a matter of not messing with the settings and using the defaults until you know what you're doing."

Granted it's good to have options but DivX has so many of them now, it's hard to tell 'visually' which one makes any significant difference or which option cancels out another option! Maybe there should be little 'pop up warnings' saying something like 'Be advised - selecting this option makes no significant difference to your encode' or 'Be advised - selecting this option is not possible'!

I notice RMV9 and WMV9 don't give you as may chances to 'get it wrong'! So it must be just an Mpeg4 thing. Which is probably why XviD is full of people discussing the same 'image quality versus settings issues' that we are doing here

One other thing I have noticed is with regard to post-processing (PP) when viewing your encodes via the DivX player 2.1. And that is, if you watch an encode with PP and then immediately select another encode (without closing down the player) the PP for the second encode is lost!

Still it's always fun to learn from each other - Keep coding!

[sapient]

The problem with kaukura is not that there are too many options, it's that half of the options do not work or in some cases do not work in the "obvious" way. If these issues are not resolved for the final, there should be a thorough redesign of the interface to make clear which options work and which don't. For example, when mv reuse is selected, the performance slider should be disabled. And the b-frame options should probabley be moved. Another idea is to have separate preformance sliders for p-frames and b-frames, since different performance levels are possible. In any case you have to make the options more straight-forward. One must be able to understand what's going on without having to search the discussion forums!

sapient

[Acaila]

I wonder if better encodes would be generated by using the following settings or would the benefits be too small: -
1st pass: performance slow, enable B-frames, enable MV
2nd pass: performance slow, enable B-frames, enable MVI believe that should give a nice improvement since now all frames will get to use the 'slow' setting. But you're right, it might take a while to complete :), though MV will still speed things up a bit here.
I notice RMV9 and WMV9 don't give you as may chances to 'get it wrong'! So it must be just an Mpeg4 thing. Which is probably why XviD is full of people discussing the same 'image quality versus settings issues' that we are doing here
IMO having a lot of settings is the result of the evolution of a codec. The more features get added, the more settings you need to control those, because not everything can and should be handled internally. I think that once RV9 and WMV9 get to the same level of 'maturity/age' of DivX and XviD, they will also have a lot more settings than they do now.
One other thing I have noticed is with regard to post-processing (PP) when viewing your encodes via the DivX player 2.1. And that is, if you watch an encode with PP and then immediately select another encode (without closing down the player) the PP for the second encode is lost!That's because the PP is controlled by the DirectShow overlay, and there can only be one instance of this at any given time. So if you open a new video while another one is already occupying the overlay, the second video won't have access to PP. It's a windows thing, nothing the codec can do about it.

[SeeMoreDigital]

Acaila,

Many thanks for the info.

I'm sure your words here are very useful for a lot of people - not just a thicko like me!

Going back to the settings issue. I can't imagine RV9 and WMV9 ever going down this route.
RV9 has recently introduced EHQ, which has vastly improved what is already a very capable codec, (at just about every bitrate and pixel frame size) without resorting to 'sliders' and 'check boxes'!
And as for WMV9. Well what can you say here... Would they really want to be bombarded with loads of 'what does this do?' or 'this does'nt seem to do anything' emails.

Maybe it is wishful thinking on my behalf to think that DivX should keep things simple. I would just hate the idea of potential new DivX users moving onto a different product because they find the quantity of setting too daunting!

I also think sapient makes a good point. Maybe the DivX interface should be totally redesigned. Maybe it should be split up into 'Novice User' and 'Expert User'.
But I do, really strongly believe that pop up 'help explaination panels' wouldn't go a miss!

We can only hope that DivX are looking and listening to both sides of the user coin.

Cheers and thanks again Acaila.

[bond]

gej
would be great if there can be an option in the codec interface which makes the feedback window not load automatically!

btw. i cant disable the feedback window by clicking on the right up corner "x" in windows