Rududu codec : new test version

[outlyer]

Originally posted by unmei
i'm really surprised this page was last updated and a codec like this existed already on day one of the linux era ;D
Yeah, a lot of pages/projects got last updated this day :D

[Tommy Carrot]

I've found some bugs:

The colors are much brighter if decoded with virtualdub. (the DSF plays with correct colors though)
If the video resolution is not divisable with 64, the playback is totally messed up.

Other than these, the quality is very good. The high quality/bitrate encoding sometimes gives even better result than xvid.

Keep up the good work. ;)

[rududu author]

Originally posted by Tommy Carrot
I've found some bugs:

The colors are much brighter if decoded with virtualdub. (the DSF plays with correct colors though)
If the video resolution is not divisable with 64, the playback is totally messed up.

Other than these, the quality is very good. The high quality/bitrate encoding sometimes gives even better result than xvid.

Keep up the good work. ;)

Thank you for testing, very usefull for me. Can you explain in more details what resolutions did you tested. For me the colors under vdub and dshow are different but one uses overlay and not the other, so I don't know if it's the codec or the overlay settings (the difference is not big). Do you see this difference only with rududu or with other codec also ? Can you send me screenshots of vdub / dshow frames (to the mail on the site).
Did someone experienced problems with a video with width multiple of 8 but not 16 ( 696, 680, 664, ... )with the dshow filter ? (I have aligned on 16 bytes but I don't know if this should always be done or if it must be negociated with the video rederer)

Nicolas

[Tommy Carrot]

The overlay colors seems to be o.k., but decoding with virtualdub always gives me wrong colors. You can check it like this: start 2 separate virtualdub, load the source video into the first, and load the rududu encoded video into the second. So you can compare them directly, and you'll see the color mismatch.

I've tested with 720x288 res, which gave unwatchable result. But with 704x256, it was ok. I've tried 384x288 (bad), but 384x256 was again ok, so i think the "division by not 64" was the problem.

Sorry, i cannot give screenshots, i've made all tests on another computer, but i hope i could help with these too. :)

[rududu author]

Originally posted by Tommy Carrot

I've tested with 720x288 res, which gave unwatchable result. But with 704x256, it was ok. I've tried 384x288 (bad), but 384x256 was again ok, so i think the "division by not 64" was the problem.

Thank you, I have seen the color error, I will correct this. I have tested a 720x288 video and I have seen a bug on key frames, but this doesn't seem to be related to the video size. Could you give me more details on what goes wrong for you. My main test video is 696x376, so not multiple of 64 and I can't see anything wrong. Do you have problems with this resolution ?

[gino25]

I have tried encode a short video. But colors are not egual to source. In fact PSNR is 15.

[rududu author]

Originally posted by gino25
I have tried encode a short video. But colors are not egual to source. In fact PSNR is 15.

Well, one computer to test seems to be not enough :-) !
I'm interrested in what software you used to calculate the PSNR : I can compute PSNR internaly with the codec but don't know a prog to do that (I have seen some but not really usefull).
PSNR 15 is a very bad PSNR, so is it because of a color / luminance shift or is it due to an other reason (bad image) ?

[gino25]

I'm interrested in what software you used to calculate the PSNR

Avisynth

Image is very good, but color/luminance is different from original.

[Tommy Carrot]

The colors are different, if you use fast repack to encode. With full processing mode, they are fine.

The image problem is this: the pixels of next lines are not correctly positioned under the previous. They are shifted left or right like this.

correct image:
1234567
1234567
1234567
1234567

But this is
1234567
2345671
3456712
4567123

/I hope it's understandable what i want to say. :)/

Yes, it is not connected with the multiples of 64, but still, at some resolution it occurs. I've tested with WMP 6.4, maybe other media players don't have this bug.

[unmei]

Anime test results

well you can read it all even if you're not interested in anime, but it might well be the codec behaves differently for real life pictures.
Also i have only tested one single source.

Source 640x480, 25 fps huffYUV (downssized from DVD, very little filtering but has mpeg2 blocks)
1000 frames, target bitrate: 900-1000 kbit/s

the source has a pan over the sky, then a storm arises, brown clouds gather over a sand desert, a meadow moved by wind (mast moving white ziczac lines), some close faces and a backpack with lots of static vertical lines and finally a tornado and a forset in front. All in all a very demanding source with lots of fast moving particles and lines but as well some rather still close ups to test the typical talk anime :D

i made 24 test files. First 2/3 i 've set Q=20 and then all parameters to default, except one at once which i tested on extremes and sometimes intemediate values. Then i tested the coupling between TR and RR. Finally i set Q to high values (0 and 1) and tested the interaction with raising DZ or NC. finally i checked for behaviour of Q in the range 0..10

first observations:
if q10 -> 272mb then q20 ->+/-180mb
none of the parameters affect the encoding speed. No way to speed up or, as its a fast codec rather: sad i cannot throw more clock cycles in to get a better result :(

(dead zone ratio)
small -> bigger filesize
big -> small filwsize, colors seem a bit more funky, like a over saturated TV picture.
On the CRT i did this first tests, its really hard to tell the difference between 192 and 384, except that DZ=192 produces a file about 1.8 times bigger than DZ=384

(treshold ratio)
small -> bigger filesize, sharper edges, I and P frames come close
big -> small file, softer edges, lot of "huge" wavy bumps in flat areas, motion errors, randomly moving waves, <- all of the beforementioned applies mainly to color, not luma. everything looks like trough a bumpy class, text becomes unreadable but surprisingly other detail "remains" . huge "I frame boost" ie I frames are not affected thus the quality "pumps"
TR=4 is about 3 times bigger than TR=123, default TR=64 is about 2.25 times bigger than TR=123
i think its goo to lower quality here a bit, it gains much compression.

(round ratio)
seems to be the inverse of treshold, or they are coupled in a opposed way.
small -> smaller file
big ->bigger file
i did not see much difference between default and very big (that coul be different if TR were above default too)
the size difference is analogue to treshold ratio

(coupling of threshold / round)
TR=RR=4 is about the same as TR=RR=123, same quality same filesize (small values give a tiny bit smaller files).
Therefore what metters is the difference or or qutient of the two values.
from the tests with one value fixed at default i conclude:
-TR small, RR mid = waste of bits
-TR mid, RR big = waste of bits
-> TR < RR = waste of bits
-TR big, RR mid = ugly, small file
-TR mid, RR small = ugly, small file
-> TR > RR = ugly, small file
my recommendation: TR = RR, or TR a little bit bigger than RR to save space. never TR < RR, its useless and bloats the file.

(node cost)
NC=0 is about 1.5 times the size of NC=7.
the only think i could see was high node cost could introduce some edge and line ghosting similar to some VCD MPEG-1

(conclusion)
*set the quality high. Q=0 or 1, but sure not below 10.
*don't touch treshold and round ratio.
*then raise the node cost until the filesize went down to what you want. You can also raise the dead zone ratio but i IMHO node cost is preferred. Or for low bitrates do it with like 1/3 raising DZ and 2/3 NC instead of really high NC.

*the default settings are in no way bad, only using the quality slider gives good results as well, actually the difference is marginal and other people might prefer not to raise NC but Q

*IMHO the codec has the potential to surpass Xvid and RV9 in the target range about 600-1000 kbit/s, especially if you consider how fast it is today (4x over a single pass of my average xvid setup! )- if it only had some CPU eating and quality kicking feaures. I could not get a really clean picture, therefore if nothing much changes rududu is not suited for hi quality encodes (see RV9, could that be some issue with non-mpeg (wavelet?) or do people just not want quality encodes??).

PS i used full processing mode

[rududu author]

I have corrected the color bug, should be OK this time :
Here is the new files (http://www.ifrance.com/rududu/Rududu20030713.zip)

@ Tommy Carrot
I have compiled a version with 16 bits (instead of 32 bits) alignement for the YUY2 output, this should correct your problem. I don't know how to see if the graphic card want 32 bits aligned datas or not. (my old card didn't need 32 bits alignement). Here is the special version (http://www.ifrance.com/rududu/Rududu20030713bis.zip)
I will see how to make a version working with all, I have to learn ...

@ unmei
Good test ! I will explain how to use all the options now I have corrected some bugs.
A remark : wavelets doesn't like blocks, so it's better to use a good quality video source to test.

Nicolas

[gino25]

I can' t see videos encoded with rududu with all player (ex windows media player, bsplayer, the core, ecc). The image is composed by some linees. If i open the video with virtualdubmod all is ok.

I tried yuv12, and rgb videos. Why?

[rududu author]

try the special version, the link is in my last post. Say me if it solve the pb. I'm working to fix this bug, but as everything works fine on my computer, I'm not sure whether I'm trying to fix the right bug or not.

[rududu author]

This time it must be corrected for everybody :

The dshow filter must support RGB32 and YUY2 output without problem, so no upside-down image and no alignment issue.

Your bug reports and comments are wellcome, thank you for your help.

Nicolas

The new files (http://www.ifrance.com/rududu/Rududu20030714.zip)

[Tommy Carrot]

The picture is now solid at all resolution i've tried. :)

[superdump]

I've encoded a short clip which I've been using as a test scene and it came out just fine. The quality is good considering the early stage of this codec. It's pretty quick too. :)

Just one problem... when I tried to run a psnr test via avisynth it vertically flipped the picture for some reason or other. Which unfortunately seriously detrimented the calculated average psnr. Bah.

Otherwise it plays back perfectly. Good job! :)

[rududu author]

Originally posted by superdump
Just one problem... when I tried to run a psnr test via avisynth it vertically flipped the picture for some reason or other. Which unfortunately seriously detrimented the calculated average psnr. Bah.

I suppose avisynth uses yuy2 output. I have flipped the output in yuy2 (as it was before in fact) for the vfw driver. I have seen that avisynth can process yv12 (planar 4:2:0), I will add a yv12 output to get rid of the color space conversions.

Nicolas

new files (http://www.ifrance.com/rududu/Rududu20030715_2.zip)

[superdump]

I ran a psnr test with these new files and obtained a value approximately equal to that of divx.

I think the next step, aside from tweaking to improve quality, would be to implement either some sort of rate control. The two main methods are either attempting to maintain an average bitrate while allowing a certain fluctuation in the rate according to the complexity of the frame in question, or something like xvid and ffvfw where you run an analysis pass then in the second pass you specify a filesize and the rate is altered to attempt to maintain a constant quality while producing the desired size of output.

The latter of the two is preferable (and better :)), but implementing both will allow your codec to appeal to more people.

Thanks for your effort.

[IvS]

I agree with the points superdump has just made :) and would like to add, that these features will also make the codec simply better ;) and behave like the other current widely used modern video codecs. I see good things ahead for this codec, i've checked it out as well since the last version that has better resolution support (thanks for adding/fixing it!). Great to see a new competitor.

[Blight]

You may be able to borrow a lot of xvid's code for this if you output similar data on the complexity of the frames.

[rududu author]

Originally posted by Blight
You may be able to borrow a lot of xvid's code for this if you output similar data on the complexity of the frames.

I can't take code from xvid : xvid is gpl'ed and rududu not, at least not for the moment. But I can read the code :)

I know rate control is important for a codec, mainly to be usable, but I want to fix the stream and so release a 1.0 version before.

I have also to implement B frames, rate-distortion optimisations, long-term motion compensation, more than 1/2 pxl accuracy (1/4, 1/8), a new and very experimental wavelet transform (doesn't work) :) , and all the ideas you can have ...



I have some questions :
- I have started writing some explanations about the codec in the details page of rududu's web site : does some of you have questions about this ? Is it understandable ?
- As you can see in the property window of rududu you can change the "quantization matrix" of the codec. This matrix is used in a similar way as the mpeg/h263 quantization matrix. This is a very important tweak for the codec because using this you can match the human visual system and/or the video source statistical properties (movie, anime, ...). The issue is that this tweaking is very subjective and it's very difficult to compare results (I mean using a subjective mesure). So does some of you tried changing this coefs ? Does any of you have experience in this kind of tests ?
- In the latest version (Rududu20030715_2.zip (http://www;ifrance.com/rududu/Rududu20030715_2.zip)) I added the YV12 and I420 support for output, is there any problem for those whose the graphic card support this input ?

Good night ! (at least for me)

Nicolas

[Wilbert]

I added the YV12 and I420 support for output
Very cool!

I can't take code from xvid : xvid is gpl'ed and rududu not, at least not for the moment.
Does that mean you are considering to change that?

[Tommy Carrot]

Another bugreport. :D

In the delta-frames the image is slightly green/purple in spots. Mostly visible on the dark parts and with strong compression (quality 63). The keyframes are free from this though.

Doesn't seems to be a colorspace conversion or overlay bug.

[Kurtnoise]

Hi !!

I'm trying your last version codec (v20030719) but I've the same problems like gino25 in this message ::mad:

I can' t see videos encoded with rududu with all player (ex windows media player, bsplayer, the core, ecc). The image is composed by some linees. If i open the video with virtualdubmod all is ok.


I tried yuv12, and rgb videos. Why?

But with the 20030713 & 20030715 versions, it works like a charms ;) So strange, don't you ??

So......great job Nicolas :D

[rududu author]

Does that mean you are considering to change that?
It's a possibility, but not now. For the moment I'm more interrested in the technical problems than by what I will do with rududu.

In the delta-frames the image is slightly green/purple in spots. Mostly visible on the dark parts and with strong compression (quality 63). The keyframes are free from this though.

This is a problem I'm facing since a long time. As the same transform/algo is used to compress Y and U/V, I think it's not a bug but a quantization issue : if you can find inter UVmin/max solving this pb without too much increase in the file size it will be the solution. As I said the quantization coeff that I have used are not too bad but are not the best, as exemple the 01/05/2003 version was better for low bit rates so the maxs can be improved a lot.
All the coeffs that you can set in the property window are sent in the bit stream, this is done because I know that I'm not able to find the best coeff now (and a good compressor can change the coeff at each frame). So if you find coeffs that work better, I'm interrested !

But with the 20030713 & 20030715 versions, it works like a charms So strange, don't you ??
Well, not so strange in fact. Since 20030715_2 rududu will use YV12 output if available, so I suppose your video card support YV12 (or I420) output. But I can't test this with my card as it don't support YV12 output. So I'm very interrested in your bug report : can you confirm that your card support this output ? what are the sizes of the video that works (if any) or doesn't work ? If you put a video that doesn't work in graphedit, that are the properties of the connection between rududu and the video renderer (YV12, I420, size, ...) ? What are the same properties after you push play and stop ? the size should have changed. Thank you for testing

Nicolas

[rududu author]

updated the site with a new version correcting the YV12 and I420 output. I have tested under avisynth and it worked, it should work also for the card output but I can't test. Tell me if it correct your bug.

In the delta-frames the image is slightly green/purple in spots. Mostly visible on the dark parts and with strong compression (quality 63). The keyframes are free from this though.

In fact it could be a quantization bug, I don't know. Anyway it is related to the quantization process. Will be difficult to find, don't expect a fast correction. (if it's not a bug I will see how to correct this anyway)

Nicolas

http://www.ifrance.com/rududu/Rududu20030722.zip

[superdump]

rududu author:

This codec has really huge potential and I will thoroughly enjoy testing it for you.

For it to have any chance whatsoever to mature it really does need some comprehensive rate control method. If you wish to speak with me for ideas then say so in a post on here and I'll e-mail you.

Many thanks for the vast improvements being made on this codec. :)

Have fun!

[Animaniac]

WOW. I just tested Rududu with a pretty nasty anime source, and the results were astounding (Default settings, quality 5). File size (roughly half as small) is smaller than XviD at equal visual quality. Rududu artifacting is interesting too, insofar as when it does artifact, it looks somewhat like noise. This noise actually makes the picture look a little better!!! It's quite interesting. Rate control would be awesome.

[rududu author]

Originally posted by superdump

For it to have any chance whatsoever to mature it really does need some comprehensive rate control method. If you wish to speak with me for ideas then say so in a post on here and I'll e-mail you.

I agree with you, a rate control algo will help the codec to be more used. As it was not intended to be used as a "true" codec but only to test I thinked a rate control algo was not necessary. Now I can start implementing a basic rate control, not too complex because I have other things to improve. Tell me what are your ideas about this, I have some interresting papers about the subject but I haven't read them at the moment.

Nicolas

[rududu author]

I have corrected an important bug in the color motion compensation.
I have seen some bugs in the motion compensation but not corrected for the moment.
Does some of you experienced crash with rududu ?
I have changed the default quantization factors, may be better ?

Nicolas

http://www.ifrance.com/rududu/Rududu20030724.zip

[superdump]

It depends what you think of as better. With the previous build with node cost and quality set to zero the output was about 300kbytes/s. With this new version it is about 400kbytes/s.

That's about all I can compare. :) Although I am testing increasing node cost and reducing quality to produce similarly sized files to see which produces the highest psnr. I hope this may be of some use.

EDIT: OK. Here are the results.

The clip is 1 minute long, of high motion from the horse chase scene on the first disc of The Lord of the Rings extended edition. It has a resolution of 704x288. The target bitrate used in XviD was 950kbps and I tried to match the filesize of the rududu encodes to that of XviD.

XviD dev-api-4, gmc-vhq4-cm-b-frames(default)-trellis, using h.263 quants.
filesize: 7,162,856 bytes
PSNR: 41.0113 (compare done with avisynth cvs 17/07/2003)
Comments: Blocking is VERY visible on the lower of the image throughout the period 8 to 30 seconds. The texture detail of Frodo's hood is lost and so are a lot of other fine details. The dust that splashes up on a closeup of Arwen's horse's hoofs is preserved quite well.

Rududu: 250 max kf int., node cost 0, quality level 55. otherwise defaults.
filesize: 7,172,096 bytes
PSNR: 40.5426
Comments: More blurred than XviD and less detail is preserved (probably due to the blurring). Blocks are difficult to spot during the high motion of the scene and can only be rarely noticed. When they are they noticed are not annoying.

Rududu: same as above but node cost 1
filesize: 7,161,856 bytes
PSNR: 40.5415
comments: no noticable difference when compared to the above rududu encode.

Rududu: 250 max kf int., node cost 2, quality level 54.
filesize: 7,077,888 bytes
PSNR: 40.5001


Nicolas, I will e-mail you a few shots to illustrate the differences. I will also run another test on a low motion clip of similar length, resolution and using a similar bitrate. :)

EDIT 2:

Low Motion, same settings as above. It is from the second disc of said film. It is the scene where Celeborn and Galadriel first meet the fellowship (less Gandalf of course).

dev-api-4
filesize: 5,601,280 bytes
PSNR: 46.3263
comments: In a word... excellent. In more than one word, there is very little I can crticise about this video clip. The glow around the two elven characters has a slight banding effect.

Rududu: node cost 0, quality 34
filesize: 5,560,320 bytes
PSNR: 43.3438
comments: The image is quite noisy, but detailed is well-conserved, not as well as XviD however. The banding effect on the glow is more pronounced and the whole image has a "shimmering" quality to it. By that I mean the luminance level of random areas on the image seem to fluctuate slightly between frames.

Rududu: node cost 1, quality 34
filesize: 5,513,216 bytes
PSNR: 43.3259
comments: no clearly discernible difference when compared to the above.

The shimmering is quite annoying and is probably worth looking into.

Thank you for your time. :)

[Tommy Carrot]

Originally posted by superdump
Comments: More blurred than XviD and less detail is preserved (probably due to the blurring). Blocks are difficult to spot during the high motion of the scene and can only be rarely noticed. When they are they noticed are not annoying.


I thougth wavelet codecs are free from blocking artifacts, and rududu is not block based, so there shouldn't be blocks. Maybe the source included them.

[Sirber]

Wavelet don't block, but remove details and blur on low-detail places.

[superdump]

The artifacts look similar to blocks but they are blurred. I have snapshots if anyone wishes me to e-mail them a few. I also thought that wavelet codecs were not supposed to produce macroblock-style artifacts, and these probably are not macroblock-style artifacts but have some other cause. :)

Edit: I have been informed by Nicolas that the blocking artifacts are caused by intra-block motion estimation which is used in certain cases. It is a different method to mpeg-4 and he says it doesn't seem like it can be improved. actually it can, but the implementation is difficult. He said he'd work on other more important things for the moment. However, there was another artifact in the screenshots I sent him which he had not seen before. He will be working to fix this or at least improve it as always.

Thanks again for your hard work Nicolas. :)

[Atamido]

I looked at the screenshots, and there are indeed blurred blocks. Essentially, you can tell there are blocks, but the edges between the blocks are blurred, whereas MPEG-4 blocks have a definate edge to them. The blocks are also not all perfectly aligned like the MPEG-4 blocks. They are almost random...

[Tommy Carrot]

It seems to me the keyframes has much lower quality than the delta-frames, with much less details. This was not the case with the older builds.

[MfA]

Even with overlapping there is a block structure to the motion compensation, and by the same virtue of wavelet coding not causing blocking they are also poor at encoding these blocking artifacts, that is probably what you are seeing.

[superdump]

MfA: Hello :) Overlapping was the method Nicolas spoke of to make it better. Maybe there's a better way of tackling motion compensation then....?

[MfA]

Mesh based motion compensation should give less visible artifacts, but mesh based motion estimation/coding is hard to do well.

[superdump]

That is very probably why he's leaving it until he has nothing more important to do. :) Any progressions made are good. I look forward to a new build.

[Tommy Carrot]

Originally posted by MfA
Even with overlapping there is a block structure to the motion compensation, and by the same virtue of wavelet coding not causing blocking they are also poor at encoding these blocking artifacts, that is probably what you are seeing.

I find these artifacts much more tolerable than the mpeg style blocks. Also there are much less ringing (noise around the edges). So this codec has really great possibilities in the future imo.

The only problems are the slight vibration of the picture, and the green/purple colorizations. I think these problems are related. The other artifacts are really not bothering.

[rududu author]

It seems there is some confusion in this thread :)

It's true that the wavelets doesn't produce blocs : the wavelet transform in done on the whole frame and there is no blocks in this step. The blocks comes from the motion compensation : I'm using overlapped block motion compensation and you can see the blocks mainly in high motion scenes when the codec uses the "intra" mode for some blocks : the mean of the block is sent and this is used as prediction. It's not very good and could be improved but it's an easy solution :)

An improvement that can be made is using overlapped block motion estimation instead of block motion estimation. It needs more time because it's an iterative process but can improve a few the quality.

About the mesh based motion compensation, I doubt it will be used some day because you can only represent continous motion (can't represent an object passing over another).

It seems to me the keyframes has much lower quality than the delta-frames, with much less details. This was not the case with the older builds.

No more in the new build. Anyway you can change all this setting the max and min quantizer.
I have not explain what the quant are used for, but you can try :). If you set the quality to 0, the values for min quant will be used, so you will be able to see what each quant change.

The only problems are the slight vibration of the picture, and the green/purple colorizations. I think these problems are related. The other artifacts are really not bothering.

I have corrected some color related bugs, I don't know if it will correct what you think about.
About the vibrations in the picture (can be luma or chroma) you can correct this using smaller quantizer for the LL, 1 and 2 bands (inter).
In this new build I have tried to adapt the mpeg quant matrix to wavelets, it's probably not the best but I don't know how to find the best values for the quantization.

Nicolas

http://www.ifrance.com/rududu/Rududu20030727.zip

[MfA]

Mesh motion compensation is not necessarily continuous, it is just easier that way. Warping/rubber-sheet mesh motion compensation can capture occlusion, the vertices will just be bunched on the motion edge, it only fails when stuff moves fast enough to cover and uncover its background in between two frames ... that doesnt affect many pixels.

[superdump]

Nicolas: The new version is looking good but it seems to blur out a lot of detail. Maybe that's how it's always been, but is there any way to maintain more detail from the input? (and don't say increase the quality setting for the codec :P :))

Also, as for the shimmering I mentioned. It does appear to still be present. I will do a compare from the previous on this tomorrow evening and tell you whether any improvement has been made.

Thanks for the hard work.

[Animaniac]

On an anime source, Rududu seems to produce "rainbow" colored artifacting. It seems as though a given block of the picture takes on alternate colors thereby green tinting the image for this block on instance, then pink tinting on instance etc. For "flat" colors this somewhat randomized change of color of time occurs in large blocks, whereas around detailed parts of the image this coloring effect occurs in smaller blocks. Sorry if this explaination misuses terminology...

[unmei]

i had this green/purple issue in my last test some pages back too. But with the new test with 2003-07-27 i dont have it anymore. Maybe i just happened to circumvent it consciouslessly ? Or is it because this test uses a cleaner DVD source than my last one (NOT washed with filters, just the DVD has excellent quality)...

well it looks damn good at 1200 kilobit and still way better than the 2003-07-15_2 for lower datarates.
And no problems with YV12 overlay (source resolution 640x480).
I'm a bit irritated with low nodecost but quality settings of 50 and more. In my tests this scenario stands no chance against quality around 30-40, node cost 3-6 and maybe a little raised dead zone if necessary. With anime that is.

Keep it up Nicolas,
if you improve it at this pace you might soon get a Rududu forum beside the big divX and Xvid ones - j/k i guess this takes a bit longer...but the codec is really surprising

(i just tested against VP4 (http://forum.doom9.org/showthread.php?threadid=58377) and imho on2 could get lost in space)

[superdump]

unmei: in a brief testing I conducting a page or so back it seemed that using a node cost of 0 in all situations produces a better output and you're better off reducing the quality.

A complete counter-observation was made in the very early stages however. Maybe it changes with each new release. :)

[unmei]

nah i don't think this changes so drastically :p

Either its effect is one to judge by personal taste or it depends strongly on the source.
I only tested with anime (as i nearly exclusively encode anime) - so it could well be i would find be the high node cost terrible too on real life source but so far i like it...

[easyfab]

Here some little test with rududu 24/7 version and new 27/7 version.

source: The mummy vts_01_2.vob image 6500 to 7500 (slow motion scene)
avs script:
LoadPlugin("...\mpeg2dec3.dll")
mpeg2source("01.d2v",idct=7).trim(6500,7500)
crop(2,76,714,424)
LanczosResize(704,288)


psnr result: (y u v average)
------------

rududu 24/7 default settings + quality 59 (4.93 mo)
result
34.36 39.84 39.79 38.00

rududu 27/7 default settings + quality 48 (4.96 mo)
33.68 39.02 39.73 37.74

rududu 24/7 default + quality 60 + node 2 (4.89 mo)
34.36 39.88 39.81 38.02

rududu 24/7 default + quality 60 + node 2 + RR 70 (4.99 mo)
34.49 39.97 39.87 38.11

rududu 27/7 default + quality 50 + node 2 + RR 70 (4.88 mo)
33.45 39.71 39.62 37.60

rududu 24/7 default + quality 60 + node 3 + RR 80 (4.96 mo)
34.36 39.55 39.86 37.92

rududu 27/7 default + quality 49 + node 3 +RR 80 (4.96 mo)
33.68 39.78 39.72 37.72

vs others codecs :

wmv9 complex decoder max quality 1000kb (4.88mo)
35.15 40.12 40.66 38.64

xvid dev4 17/07/03 mode 4 trellis chroma mpeg (4.88mo)
35.49 40.32 40.83 38.88

divx manihi slowest pass2 (4.85mo)
34.70 39.54 39.93 38.06

ffvfw motion estim sad +hq +trellis quantizer mpeg +4mv
35.06 40.47 40.49 38.68

ffvfw motion estim satd +hq +trellis quantizer mpeg
34.97 40.41 40.44 38.61

vp3 hq sharp
34.09 40.29 40.87 38.42

vp4 hq sharp
34.60 40.42 40.90 38.64

According the psnr test there is a prob with the luma encoding in the 27/7 version (my eyes don't see a great diff but i prefer the 24/7 version encoding more detailed IMO)

My eyes result :) :
-------------------
1)Xvid the more detailed image (i'm very impressed with this dev4 version))
2)ffvfw same but more visible artifacts around the characters
3)wmv9 a bit blurry but no artifacts
4)rududu 24/7 some background are blurry but the characters are detailed
5)rududu 27/7 same but less detailed IMO
6)vp4 not so bad but not enough detailed
7)divx manihi (I'll try later with the stable version)
8)vp3 no detailed (in sharp mode ?)

More tests to do with different bitrates and others scenes

[easyfab]

oops,
I forgot the most important:

Merci Nicolas for your work,
Rududu codec has a good potential and can give a great codec in the futur.