Rududu codec : new test version

[Ishan]

I can't get rududu to work in an OGM container, the OGG DShow filter keep complaining about unknown codec.

[Gaia]

Originally posted by Ishan
I can't get rududu to work in an OGM container, the OGG DShow filter keep complaining about unknown codec.

Why you want to but rududu inside ogm container?
Current versions of rududu are just for testing you know.
Not for arciving. I haven't tested rududu yet myself but i am sure you get lots of backward compatibility issues if you start burning you rududu encodes now...

[Ishan]

Hey! Don't be so agressive!
It was just a bug report, and yes I know it's experimental and bla bla bla...

Just tried an hires encode (1024x436) but in bitrate mode the max 1500kbps is too small.
Something like 3mbps could be a better limit.

[Sirber]

3mbps... The Legendary RV9 Nerd don't like that number :p

[Tommy Carrot]

Originally posted by Ishan
Hey! Don't be so agressive!
It was just a bug report, and yes I know it's experimental and bla bla bla...

Just tried an hires encode (1024x436) but in bitrate mode the max 1500kbps is too small.
Something like 3mbps could be a better limit.

In this case just use quality mode. The bitrate is not limited this way, and quality=0 to 15 with node cost=1 gives very good result imo.

[unmei]

is the video upside down in vdub too ?
what is the sign of the height of the video in graphedit at the renderer input pin ?

OK it took me a long to to look into this again as i didnt have the clip anymore. The one clip i still have that is made with the juli version only shows funky color patches no pic at all :) but with encodes done with the august release and the same method as the one i reported problems with do not show flipped picture on YV12 anymore.

From my memory, i'd say it only occured in DS players, not in VD but i'm not sure and i think its solved in the new version anyway :D

[Ishan]

@Tommy Carrot
I've already tried quality based mode, but I wanted to try out the bitrate mode with a HiRes encode and 1500kbps is not enough ( i got many visible artifact even at 1500kbps NC=1 ). but well if this codec wasn't meant to be used with very hires source i'll don't complain :D

[PatchWorKs]

We're talking about bitrate, quality, artifacts... but which resolution ?
I'm testing @ 640 x *

[Tommy Carrot]

Originally posted by PatchWorKs
We're talking about bitrate, quality, artifacts... but which resolution ?
I'm testing @ 640 x *

IMO this codec works best on higher resolution (720 or higher), because the blurness is less noticable on high res.

After a few tests i came to this conclusion: rududu is slightly worse than xvid or divx in the dvd-rips, but much better in tv-captures at medium or low bitrates (640*480, 600-1200 kbit), because of the better noise-handling, the missing blocks (which can be horrible in these circumstances with mpeg4 codecs) and mosquito noise.

Of course this is just the theory, because the color problem influences the result, but i'm assuming it will be fixed.

[Ishan]

@Tommy
i don't totaly agree with this, i have a hires (1024x436) and very detailled source (it's final flight of the osiris from the R2 dvd with black bar cut and horizontal resize to get the proper ratio (2.35:1)) with a little sharpening.
The resulting avs looks very sharp and detailed with no blocks and very little mosquito noise.

in quality based mode the encode looks good at quality=1 and NC=1 but bitrate mode is too limited (max bitrate 1.5mbps) and the resulting file is blurry even @ 1.5mbps (maybe i'm asking too much :D).
i'm not very concerned by filesize...

With a good 2 passes mode and a somewhat less limited bitrate mode this codec can totaly kills all others IMHO. (and a somewhat higly optimised DShow decoder :D , on my XP1800+ the playback is very jerky)

Rududu gonna rulez!:D

[Tommy Carrot]

Originally posted by Ishan

in quality based mode the encode looks good at quality=1 and NC=1 but bitrate mode is too limited (max bitrate 1.5mbps) and the resulting file is blurry even @ 1.5mbps (maybe i'm asking too much :D).
i'm not very concerned by filesize...



If you're not concerned by filesize, why do you use bitrate mode? Quality mode is the way to go. :)

[Ishan]

@tommy

well i mean i'm not concerned if the file is big, but i like to set it via bitrate :D

[superdump]

It appears a new version has been posted today @ Rududu's site (http://www.ifrance.com/rududu)

*Goes to play with the new toy* :D

[deXtoRious]

So, what's new?

[superdump]

I don't know. I may e-mail him asking if he can start including a changelog.

[rududu author]

Originally posted by deXtoRious
So, what's new?

More bugs and artefacts :)

I have corrected a small bug in the chroma motion compensation (at the bottom of the image)
The main change is that I now compress U and V planes using the Y plane. I don't know if it's better (not tested against the old version) but if it's better it should be a very small improvement.
I also changed the default settings for UV quantization, so now more bits are spent on U and V

Good night !

[edit] @ superdump : how do you know I am releasing a new version just hours after ?

[superdump]

Nicolas: Lol, I just happened to feel like glancing at your site to check for a new version and there it was "(189Ko, updated 14/09/2003)". :)

[deXtoRious]

I was hoping for some mega-improvement making Rududu usable in my test...:(

[rududu author]

Originally posted by deXtoRious
I was hoping for some mega-improvement making Rududu usable in my test...:(

Why can't you use it in your tests ?

[Tommy Carrot]

I've tried the new version, the color issues are mainly gone. Nice work!

[Lefungus]

Nice work rududu !

The picture is much much better than before, and i think it begins to be competitive :)

i've made a little clip, and compared it with last xvid dev-api-4. I was lucky so i got almost same size, with default parameters.

http://perso.wanadoo.fr/reservoir/comp/rududu.png
http://perso.wanadoo.fr/reservoir/comp/xvid.png

then i compared it with the SSIM metric (higher is better)

rududu clip got 75.43
xvid clip got 77.81

It's good considering how much tuned is xvid.

The next thing required, imo, to be able to try to tune it, is a fairly accurate bitrate mode. As now, changing parameters makes final size too much deviated.

[deXtoRious]

Why can't you use it in your tests ?

Because it makes a 25mb file when it should make a 10mb file (550kbps)! How am I supposed to compare two files under identical conditions, when one of them is 2.5 times bigger than the other?

[Latexxx]

Originally posted by Lefungus
Nice work rududu !

The picture is much much better than before, and i think it begins to be competitive :)

i've made a little clip, and compared it with last xvid dev-api-4. I was lucky so i got almost same size, with default parameters.

http://perso.wanadoo.fr/reservoir/comp/rududu.png
http://perso.wanadoo.fr/reservoir/comp/xvid.png

then i compared it with the SSIM metric (higher is better)

rududu clip got 75.43
xvid clip got 77.81

It's good considering how much tuned is xvid.

The next thing required, imo, to be able to try to tune it, is a fairly accurate bitrate mode. As now, changing parameters makes final size too much deviated.

Your clip looks like a interlaced cource which hasn't been interlaced before encoding. Comparing clips like that only cause super-crap quality, which doesn't show the true quality of the codecs. It might also bee the resizing algo of of the image-editor you are using.

[superdump]

Originally posted by rududu author
Why can't you use it in your tests ?

Sometimes even at q63 node cost 7 it can't get there.

dextorious: Try quality 63 and node cost 7 rather than the bitrate mode.

[Lefungus]

Originally posted by Latexxx
Your clip looks like a interlaced cource which hasn't been interlaced before encoding. Comparing clips like that only cause super-crap quality, which doesn't show the true quality of the codecs. It might also bee the resizing algo of of the image-editor you are using.

HUH ?

The clip is fully progressive.

But it has been zoomed 2X under vdub, i don't which resizing method it uses. It has been zoomed only for screenshots of course. The ssim comparison has been made without any resizing.

Anyway, i don't know why you think it's interlaced ?!?

[Sirber]

for a 1-man codec, it's been well developped :D

[Lefungus]

Proper screenshots, not resized

http://perso.wanadoo.fr/reservoir/ru1.png
http://perso.wanadoo.fr/reservoir/ru2.png
http://perso.wanadoo.fr/reservoir/ru3.png

http://perso.wanadoo.fr/reservoir/xv1.png
http://perso.wanadoo.fr/reservoir/xv2.png
http://perso.wanadoo.fr/reservoir/xv3.png

[Sirber]

RU1 seems sharper than XV for the shoulder, but in other pics, rududu seems blurier

[Tommy Carrot]

The main advantage rududu has over xvid (and other mpeg4 derivants) is the lack of blocks and mosquito noise (and this is reached without smoothing away the details with postfiltering). If you enlarge the images to full screen, you'll see the difference.

[Sirber]

BTW, RV9 don't post-process :p

[Lefungus]

yes, but rv9 process video somewhere before, so same result at the end.

[RadicalEd]

RV doesn't preprocess :\

[Tommy Carrot]

RV has in-loop filtering afaik. This means the content is filtered on both the encoder- and the decode-side. This is a little more effective than post-filtering, but still, smoothes away many details. A wavelet codec doesn't need any filtering.

[CruNcher]

Lefungus you should also post the encoding time i know for some this is not of high interest but to show how much ruddudu can still be optimized i think its worth it :)

[Mug Funky]

hmm... haven't tried the codec yet, but i'm thinking it's time to get some new webspace.

i can't read the site for all the ads i get.

[rududu author]

'lo

I have to ask you some help, about what change is there when you run a prog in a debug session (in the debugger) and when you run it normal.
Here is what is strange :
I have a debug build of rududu. When I run it in the debugger and compress a file, the output is 1.25Mo. Then I test the psnr using avisynth and I have two results : 39.86 if I run the test in the debugger and 37.81 if I run the test outside (so normal). Here (http://www.ifrance.com/rududu/paris_rud_crash.avi.Y.txt) is the file with the two tests. You can also see a big Mean Deviation difference.

Now I have done the same compressing outside the debugger, with all the parameters the same. The output is 1.41Mo and decompressing outside the debugger give 39.52 db psnr and 39.46 inside. Here (http://www.ifrance.com/rududu/paris_rud_00.avi.Y.txt) is the file with the two tests.

I have no clue of what changes between runing inside and outside the debugger. Someone as an idea ?
All the test above are done on a debug build, but I have tested also with a release build and the results are exactly the same. So the difference seems to be only running inside/outside the debugger.

Thanks for your help !

[edit] not a rududu bug, it seems it's an mpeg2dec3 post process bug

[bergi]

@rududu author

Can you give me/us more infos about you algorithm inside your codec I'm sure you know Wavelet 9/7 (http://sourceforge.net/projects/btwincap/) an the smearing effect. I'm also working on a wavelet based codec, i've already implemented keyframes and deltaframes without motion vectors and in my tests this effect also appears. I've tested a smooth filter but this only works with small quants. I think Wavelet 9/7 has only fullpel motion vectors, does halfpel look better? And what about the macroblock edges? I think they are very hard to compress with wavelets?

[rududu author]

Originally posted by bergi
@rududu author

Can you give me/us more infos about you algorithm inside your codec I'm sure you know Wavelet 9/7 (http://sourceforge.net/projects/btwincap/) an the smearing effect. I'm also working on a wavelet based codec, i've already implemented keyframes and deltaframes without motion vectors and in my tests this effect also appears. I've tested a smooth filter but this only works with small quants. I think Wavelet 9/7 has only fullpel motion vectors, does halfpel look better? And what about the macroblock edges? I think they are very hard to compress with wavelets?

seems to me that wavelet 9/7 as no motion compensation, just substract the last frame. halfpel motion compensation give about 10-15 % better compression that fullpel motion compensation. Read my details (http://www.ifrance.com/rududu/details.htm) page and ask more questions if you have.

@ all the developpers : somebody with an idea about my problem ? (last post)

[bergi]

@rududu author

Perhaps some problems with the mmx registers (emms). And if you work with a float wavelet transform VC always uses doubles, perhaps in debug mode it's different. And perhaps rounding mode in the FPU is changing during debugging?

Just some ideas...



I've looked inside the Wavelet 9/7 code and there is a motion compensation, but only fullpel. I think in early versions of your codec the smearing also appears, but now the picture look very well and no smearing (i've made only one small test but couldn't notice it). How do you remove the smearing? Or is the smearing just not noticeable with halfpel because of less high frequencies?

[rududu author]

Originally posted by bergi
@rududu author
I've looked inside the Wavelet 9/7 code and there is a motion compensation, but only fullpel. I think in early versions of your codec the smearing also appears, but now the picture look very well and no smearing (i've made only one small test but couldn't notice it). How do you remove the smearing? Or is the smearing just not noticeable with halfpel because of less high frequencies?

given a look to the code : I have seen that there is a motion estimation fonction but it's not used, the only motion compensation that is used is : byte_to_float_delta, and the c implementation :

void byte_to_float_delta_c(
float* fdata, // Pointer to the first data row in floats
uint xd,uint yd, // X,Y size of the image
uint stride, // Stride in floats for each row
byte* bdata, // Pointer to the plane to be converted
uint bstride, // Plane stride.
byte* pbdata) // Pointer to the previous plane already converted
{
// Process row by row
while (yd--) {
// Process each column...
for (uint xc=0; xc < xd; xc++) {
// Convert bytes to floats
fdata[xc] = ((int)bdata[xc]) - ((int)pbdata[xc]);
}
// Advance to the next line...
bdata += bstride;
pbdata += bstride;
fdata += stride;
};
}

As you can see, there is just a substraction. In the first version of rududu, I was using fullpel motion compensation with a non overlapping block motion compensation.
Motion compensation (even fullpel) should remove the edges artifacs you see.

Nicolas

[Ramirez]

Hi, I've some serious problem with smearing here; (latest build / bitrate mode 1000kbps),other setting where left on default.

One short clip (http://storm.wronger.com/sample.zip) and one still frame (http://storm.wronger.com/rududu/1087.html).

Thanks a lot for your work.

[Sirber]

I did a test with the opening of Naruto, I asked 400kbps (:D) but I got something about 1000 or more :(. IMHO the Rate Control isn't quite perfect :). But!!!, Quality was kicking ass!!! :D

[unmei]

about the inside/outside debugger i can only agree with bergi, it would be the most probable.
One other thing the debugger can affect, but wich is probably not relevant in a video codec is that since the debugger fills in code for observing variables, it can affect the sync'ing of different threads in a way that a if you do not properly lock stuff, one thread might obtain states of a object driven by a different thread that is behind or ahead of what you expect it.
(this was cause of some really weird things i got lately, i have no experience in proper mulithreading, but delphi made me learn some the hard way - i was not even aware things were running in different threads first and it gave me different behaviour inside/outside the debugger :)

LoL its Sirber of course asking for 400kbit :D well this codec is not from real networks in case you have not noticed yet :P

[Joe Fenton]

Yet another thing to contemplate - depending on the system, when running the program, bss is not initialized. When running under the debugger, the space may not be initialized, or it may be cleared initially, or it might be filled with a certain value (I've seen 0xDEADBEEF used in more than one system). It sounds like maybe you rely on a variable to have an initial value when it is in an uninitialized section of the data.

You have to be careful about this. Sometimes, initializing variables occurs inside a conditional structure. This usually generates a warning on most compilers I've used. If the conditional is not called before the variable is used, you could get "strange" results, hence the warning.

Not saying this IS your problem, just that the fact that it works differently under the debugger reminded me of this.

[Mug Funky]

one thing for people concerned about bitrate v quality tests:

why not encode the rududu clip first, then do an xvid 2-pass with "desired file size" set to that of the rududu clip? i tried this and got pretty competitive results. i think the main place this competes with xvid is it's lack of blocking at b-frames (xvid does a fair amount of this, at least with my chosen settings, where rududu doesn't have b-frames at all).

no stills pr stats to show anybody... just food for thought.

great encoder though! even at an early stage it's performing exceptionally well at speed and filesize. some more time (and maybe its own sourceforge project:)) and it'll be a real winner.

[Sirber]

Originally posted by unmei
LoL its Sirber of course asking for 400kbit :D well this codec is not from real networks in case you have not noticed yet :P XviD, DivX, WMV9, H264, even VP4 can do 400kbps with you ask 400kbps :p. It's not Real related :sly: Why you people always think about RV9? :D

[vkem]

With the newest Rududu build, encoded in 768x568 in AVI and Matroska. The audio goes too fast, and video lacks behind. My processor is AMD XP 2200+, 512 MB RAM and WinXP. Players tested are ZoomPlayer and Windows Media Player.

[PatchWorKs]

Rududu is rising !
It's now supported in DVX (http://www.planetdvb.net/) !!!
Check it out !!!

To the author: keep in touch with Dolemite to optimize the work...

[PatchWorKs]

Forum seems dead... any news ?

[Tommy Carrot]

Originally posted by PatchWorKs
Forum seems dead... any news ?

Well, Nicolas doesn't respond to the mails since about a month ago...