Rududu codec : new test version

[rududu author]

Originally posted by easyfab

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)

no prob with the luma, you are using the codec with quant that I have not tested and as I said I changed the quantizer settings. For the tests I made (around quality = 12) it was better than previous version, but all this will improve with time. Try to use the old quant settings.

you should not use the mean of a psnr (it's not useful), especialy the mean of Y, U and V because the main factor here is Y and to calculate the total psnr you must use the square error for Y, U and V.

This is probably my last post before I leave my home, I will continue working on rududu but I will not be able to answer to you posts (no net).

Bye !

Nicolas

[Tommy Carrot]

The new version is indeed worse on higher quality (>40) setting, but around 10-20, it's really impressive.

[unmei]

27/7 probably has a picture flip with YV12

the scenario is this:
i ripped from DVD to VBLE, a true YV12 process even in Avisynth. Then i encoded to Rududu/matroska in VDM using fast recompress (still YV12). Now when i watch this file on the comp with a Matrox card, the picture is like it should, but when i watch the file on the comp with Radeon card the picture is flipped upside down. The player doesn't matter.

weird it didn't happen in my tests on 27/7, it occured on a file i made not for testing rududu :(
(could be during the test i didn't use pure YV12 process)
else great quality considering the file turned out much smaller than i thought

[PatchWorKs]

...how to set the encoder.
I'm bit confused. I want have a good quality codings from MPEG-1 sources.

Could someone help me ?

Note: i successfully muxed Rududu+Vorbis streams in a OGG !

[Sirber]

Originally posted by unmei
Radeon card the picture is flipped upside down. The player doesn't matter.A fix could be to use FFDSHOW flip picture property.

[unmei]

Lol Sirber,
that wasn't a "help i need to turn my monitor upside down" post. I have subtitles in that same file and flip the picture with VSfilter. I meant it shouldn't be like this, there is something wrong with the orientation or colorspace whatever in the stored data :D

[r0cket]

DS decoding is too slow on my Celeron 566 overclocked to 866. It can't handle 512x384. But though the picture looks very nice with current version and default options. I am watching the clip with 0.5x real time - that means i should notice more artifacts - but no! Everything is perfect!

P.S.: Gotta buy a newer CPU ;)

[r0cket]

Just thought that this (http://rocket.rbcmail.ru/rud_2003-07-27_redist.exe) may be a bit more convenient for some testers.

[IvS]

r0cket: it's a nice effort to make an NSIS installer. but, however good it may be, i seriously think you should ask for the author's permission first.
(personally i think it's perfect the way it is, right click + install, and can remove from add/remove programs. that has nothing to do with the above though :))

[unmei]

completely O/T: maybe you shouldnt buy a celeron next time :) my P3 has only 600 mhz and i watch 640x480er rududu near-to-fluently on on it (and i think when this grafix card would support YV12/overlay it were fluent)

Anyway i guess the decoder is not much optimised yet. It could also have a cofig tab for setting speed options or postprocessing (if there are postprocessing routines applicable to rududu). But i think this has less impoertance - i wait for even better encoding in the next release, not for improved playback :)
Decoding speed sure becomes important when the encoding is out of the child age - but for testing it's not the main issue.

[r0cket]

Originally posted by IvS
it's a nice effort to make an NSIS installer. but, however good it may be, i seriously think you should ask for the author's permission first.
As we can see from the readme.txt included in the pack:
This software is free and you are encouraged to distribute it freely.

Originally posted by IvS
personally i think it's perfect the way it is, right click + install, and can remove from add/remove programs. that has nothing to do with the above though :)[/B]
Yeah, maybe but i have had some problems with uninstalling it from add/remove menu.

Originally posted by unmei
maybe you shouldnt buy a celeron next time
the money was the problem then, besides that was 2 years ago. anyway it's not the place to discuss this.

Originally posted by unmei
i wait for even better encoding in the next release, not for improved playback
maybe you're right, but some people (like me) won't be able to test it. but it doesn't matter much to me - going to buy something cool this fall :D

[Tommy Carrot]

Originally posted by unmei

Anyway i uess the decoder is not much optimised yet. It could also have a cofig tab for setting speed options or postprocessing (if there are postprocessing routines applicable to rududu).

I don't think rududu uses any postprocessing. Wavelet codecs just have no blocking artifacts. Anyway, i was almost able to playback a 1080x436 test encoding on my athlon 1700. A little flickering sometimes, but not bad performance from an experimental codec.

[General Lee D. Mented]

Originally posted by Tommy Carrot
I don't think rududu uses any postprocessing. Wavelet codecs just have no blocking artifacts. Anyway, i was almost able to playback a 1080x436 test encoding on my athlon 1700. A little flickering sometimes, but not bad performance from an experimental codec.

There's artifacts if you know what to look for. I don't think rududu divides the frame into blocks, so there's no blocking artifacts. If it did you'd probably see some though.

[PatchWorKs]

I successfully coded a 704x384 movie with defaut settings, resulted a 601 MB file (video stream only).
Quality is OK, but i have mutch space to use on my disc (i use Mode2CD burn, so i can store 800 MB), 'cause my audio stream is really small (35,7 MB - vorbis 64 Kbps,stereo,32000 Hz,lowpass filtered @ 19500 Hz).
How can i improve video quality (size) ?
Have i just to put 'Quality' @ zero or can i set something other ?
(i'm really confused about 'Node Cost' parameter...)

Thanks a lot.

[unmei]

lowering node cost gives a bigger filesize ,therefore you might want to do that, but i recommend setting a really small quality value first (but other ppl see this different :)

[superdump]

Patchworks: If you look at this page each variable of Rududu that an enduser can alter is explained - Rududu "options explained" (http://www.ifrance.com/rududu/details.htm)

[IvS]

Originally posted by r0cket
As we can see from the readme.txt included in the pack: "This software is free and you are encouraged to distribute it freely."

Hmm i did read this but didn't assume it can be distributed in any form one likes, assumed the files from the site can be distributed freely. Indeed I may be wrong. A clarificatioin on this will be useful Nicolas :). Thanks.

[r0cket]

and till he gets back lashes :) here is a small update (http://rocket.rbcmail.ru/rud_2003-07-27_redist.exe) with license page. and, for even more convenience, with component selection page (encoder or/and decoder).

[IvS]

you need to make it clear that this is not an official distribution by the author, but a redistribution by you. as with Koepi's xvid installer for example, "(Koepi's build)" is added. since your installer is of a redistribution (not build), something like "(r0cket's redist.)" could be sufficient.

[r0cket]

Done! (http://rocket.rbcmail.ru/rud_2003-07-27_redist.exe)

[r0cket]

Well, i've done some tests with some wierd results.
Here are the pics:
original (http://rocket.rbcmail.ru/pics/original.jpg)
rududu default settings (http://rocket.rbcmail.ru/pics/rududu_green_problem_default.jpg)
rududu qulity=0, nodecost=0 (http://rocket.rbcmail.ru/pics/rududu_green_problem_qual0_nc0.jpg)
What is this green area in the bootom left corner? Nothing in the clip, that could leave track like this.
BTW, those pics are anamorphic, so don't wonder.

[rududu author]

I'm back :)

Originally posted by unmei
27/7 probably has a picture flip with YV12

the scenario is this:
i ripped from DVD to VBLE, a true YV12 process even in Avisynth. Then i encoded to Rududu/matroska in VDM using fast recompress (still YV12). Now when i watch this file on the comp with a Matrox card, the picture is like it should, but when i watch the file on the comp with Radeon card the picture is flipped upside down. The player doesn't matter.

weird it didn't happen in my tests on 27/7, it occured on a file i made not for testing rududu :(
(could be during the test i didn't use pure YV12 process)
else great quality considering the file turned out much smaller than i thought

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 ?

Originally posted by r0cket
Well, i've done some tests with some wierd results.
Here are the pics:
original
rududu default settings
rududu qulity=0, nodecost=0
What is this green area in the bootom left corner? Nothing in the clip, that could leave track like this.
BTW, those pics are anamorphic, so don't wonder.

can't see the pictures ... the site doen't work


Hmm i did read this but didn't assume it can be distributed in any form one likes, assumed the files from the site can be distributed freely. Indeed I may be wrong. A clarificatioin on this will be useful Nicolas . Thanks.

well, if you want to pack the files in an other way, there is no pb.

Nicolas

[superdump]

:D Welcome back Nicolas.

[r0cket]

Originally posted by rududu author
can't see the pictures ... the site doen't work
works fine, just tested.

[superdump]

Nicolas: in case you haven't noticed i've e-mailed the pictures to you. :)

r0cket: Nicolas will see them soon enough. ;)

[rududu author]

Originally posted by r0cket
works fine, just tested.

now it works for me too, strange ...

Try the last version at the same file size and say me if it's better or not.



Added a very bad rate control to rududu (but it could be worse). To use it, select "bitrate" and set the bitrate (should be in 1024bits/s), the first quality that will be used is the quality you see in the dialog.

Any comment ? (http://www.ifrance.com/rududu/Rududu20030824.zip)

Nicolas

[Tommy Carrot]

I didn't try the rate control, just tested the overall quality.

This was just a quick test, so the observations may not apply to all cases. ;)

Node cost=1 always gave me more detailed image compared to the default (nc=4), when i've tried the match the filesizes. (nc=4 with quality 48 was quite close to nc=1 with quality 30, on filesize). So IMO the default setting should be Node cost=1.

The vibration problem is not exist anymore, the image is very stable.

But the green/purple color distortion is back!!! It was completely eliminated from the previous version.

The detail level is improved, right now quite close to xvid (with node cost=1), and IMO has the potencial to even surpass it.

[superdump]

I briefly tried the rate control in amongst other things. Because of the way I am I immediately set node cost to 0. I also obtained better results through using a lower node cost and higher quality value than vice versa (as Tommy Carrot also points out) but due to not losing details this makes it difficult to reach lower bitrates (even on a Futurama episode it would seem). It did seem to try it's hardest to get there though.

I have also noticed the blotchy colour problem again. I thought I noticed it disappear at what could have been an I-Frame or equivalent and then the problem slowly returned until the next I-Frame or equivalent. This assumes of course that I-Frames or equivalents are used. :)

I will test more thoroughly soon.

[Tommy Carrot]

Well, at quality 0 (node cost=1) setting the green/purple bug is invisible, in fact, i can't see any artifact at all. The quality is about the same as xvid's quant 2, but with a bit smaller filesize. Nice work!

Seems to me this codec is not yet tuned for lower bitrates, but at higher bitrates it's already competitive to mpeg4.

[Sirber]

i need numbers!! What is low bitrate, and high bitrate :)

[Tommy Carrot]

Originally posted by Sirber
i need numbers!! What is low bitrate, and high bitrate :)

It depends on the source ofcourse. :)

[Sirber]

Can you give me some exemples... :p

[RadicalEd]

I managed to get the average bitrate around the area of 700 - 1000 kbps depending on the node cost setting. Bitrate was just set to 1 so as to get the lowest possible.

I'm finding the quality hard to judge, just because my eye is so programmed to seeking out the usual block based dct type artifacts. The wavelet compression is so radically different that it's hard to compare. It's nice not seeing any blocks at 700 kbps where they were abundant in XviD, but in place of it is a general mudiness. There also seems to be a problem with chroma trailing behind an object sometimes for several seconds. At first glance it appears to be related to keyframes.

Definitely interesting, I have some playing around to do with the settings.

[superdump]

Is it me or is the CPU usage to decode Rududu encoded stuff getting higher? I can't watch a 640x344 encode resized to full screen because my lowly athlon xp 1600+ can't keep up with the resizing on top anymore.

CPU usage to decode at stock res is 80% or higher for most of the video. :\ I hope this can be sped up a little.

***EDIT***: Nope, it's not slow. It was just me being a big nonce and trying to playback a 60fps video. :) No wonder it was a little jerky.

As regards the rate control. After conducting a few more tests, I've found that as long as the floor of the codec's ability isn't reached, it hits filesizes reasonably well. So possibly some sort of "I'm struggling to reach the set bitrate, i'll increase node cost by 1 and see how I fair then" algorithm might be useful for people who don't want to have to do multiple encodes for the same material. Maybe eventually linking node cost to some human visual system or something and making it completely dynamic. :)

[Tommy Carrot]

IMO node cost should be hardcoded to 1. Ok, the lowest reachable bitrate is higher, but at a given bitrate, it always gives sharper and more detailed picture. Increasing the node cost blurs the image too strongly (for my taste at least).

[superdump]

I don't know about hardcoded, but defaulted maybe. I believe there are many people who use codecs at the 1 or 2CD per film level, which is about 600-1500kbps ish generally. If this range is attainable then OK, but also think of the people who want to set node cost to 0. :)

[deXtoRious]

Could anybody suggest codec settings that would match, let's say a 550 kbps 2-pass xvid? Or suggest a way to find these options?

[superdump]

deXtoRious: It's going to be difficult to hit that bitrate without it looking horrible currently. But here's the method (it will take multiple encodes so I suggest you try it on a clip for the moment):

1. The bitrate method
-Set the bitrate to something really small (less than 100 say)
-Set the node cost as high as it will go
-Encode
-If target bitrate is met then that's it, if the file is too small then lower the node cost and try again, if the file is too large then I don't think you'll reach the target bitrate.

2. The "quality" (I like to think of them as quantisers instead) method:
-Set the node cost to 0 and set the quality to 63.
-Encode
-If the file is too small then start lowering the quality value until you hit somewhere near the filesize. If the file size is too large, start increasing the node cost. If you get to node cost 7 and the file is still too big then you probably won't be able to meet the target bitrate.


Currently the second method is still my favourite as I know what's happening. Basically it's still a bit hit and miss because this is still only a very early implementation of rate control and while it works in certain circumstances it can't hit very low bitrates like 500kbps because it reaches the floor of the codec's current ability.

[rududu author]

Few words about the default settings :

I have found these settings optimizing for psnr on a short sequence (12s) and with more noise than a good dvd will have. That's why the node cost is set to 4 by default (it was the best result). Basicaly high node cost are usefull if the source is noisy, but will blur more a good source. I think (but I have not verified) that nodecost = 1 will always give better results than 0. With these settings I get about 0.8 db psnr (Y) better than XVID with VHQ on a source different from the testing one (102s) but also a little noisy. All this at constant quantizer (quality = 0 for rududu and Q = 3 for XVID). I have to admit that I have not seen a difference visualy, but the rududu quality was a lot better than before.
All this to say that those settings are not the best for all sources and that it's possible to do better. If someone has psnr results showing that nodecost = 1 is better than nodecost = 4, I will be very interrested.

About the low bit rates and the color issue :

at quality = 63, more than 70% of the bitrate is allocated to the motion vectors. This is a matter of rate-distortion optimization of the encoder. I will not solve this now.
So as only 30% of the bitrate is allocated to the wavelet coefficients, and that a part only of this bitrate is for the color, the color quality is bad. And it's very difficult to tweak it because the psnr curve is going up and down in a strange way ...
I will improve all this with time :)

Nicolas

[Tommy Carrot]

Nicolas, PSNR is an interesting thing, but it doesn't always give reliable result. The real quality measure are the eyes. And node cost 1 gives more pleasing results (at least for me ;)), even if the psnr is lower (like qpel with xvid: better detail level, but lower psnr).

But anyway, great work! This codec is quickly progressing, once the bitstream is frozen, it will be very handy for tv-captures too, because it handles the noise much better than xvid.

[rududu author]

Originally posted by Tommy Carrot
Nicolas, PSNR is an interesting thing, but it doesn't always give reliable result. The real quality measure are the eyes.

Sure, I know this :). But doing psychovisual tests alone is very difficult, so psnr is the measurement of the poors !It's also very difficult to see 0.1 db psnr difference with the eyes, so psnr is usefull for little improvements (and you do big improvements with a lot of little improvements).

[deXtoRious]

I just encoded the Matrix Reloaded trailer with node cost set to 0 and quality to 63. The video was over-smoothed and looking quite terrible. Is it ok for a new codec, or am I just doing something wrong?

[superdump]

Nothing wrong as such, but at q63 it's going to struggle to produce a very good output.

Low bitrates (like 500kbps) are going to be very difficult to obtain with this codec for a little while to come, I believe, let alone good looking low bitrates. Not that this is a bad codec, quite the contrary, it's just its current range doesn't really cater for 500kbps people.

If someone discovers some settings which look good with rududu at ~500kbps then I would like to see them. :)

The methods I described to you had no real intent to look good, I was just suggesting methods to reach 500kbps.

Anyway, have fun. :)

[deXtoRious]

Understood, thanks. But could you please tell me at what bitrate (and settings) does Rududu begin looking good?

[Tommy Carrot]

Originally posted by deXtoRious
Understood, thanks. But could you please tell me at what bitrate (and settings) does Rududu begin looking good?

Quality setting up to 10-15 with node cost 1 gives quite good result (comparable with xvid/divx). Above that there are some color problems, and the image is getting blurry. I don't think this codec is properly tuned for lower bitrates, so we'll have to wait for that.

[Ishan]

I just tried last build set to bitrate mode @ 1024kbits and node cost 1 on a HQ anime source and the result is just amazing.
No artifact and near no bluring.
Have to run a full encode thow to check file size precision.
This codec gonna kicks ass!:D

[Lobuz]

The color problems are present even with q0, nc0 and are slightly noticeable. Besides that problems it's quite nice codec.

Regards
Lobuz

[deXtoRious]

YAY! Finally a bitrate mode!

[deXtoRious]

Ok, I've tested it a bit. The results were quite dissatisfying. I encoded the Matrix Reloaded trailer (640x480) using bitrate mode to 550 kbps. The quality was good (though not as good as divx5 and xvid), however the file size was 18mb instead of 10mb, meaning that even with a 1.8 times larger bitrate, Rududu couldn't reach up to divx5/xvid. OK, that's allright for a new codec. However it wasn't the end of the problems. I decided to take some PSNR readings, but the avisynth script (which I had succesfully used with other codecs earlier) crashed VirtualDubMod. A bit later simple clicking on the video file in My Computer crashed explorer.exe as well. Can anyone explain this?

[Tommy Carrot]

I've tested it a lot, but never caused any crash here. :confused:

The low bitrate (and i consider 550 kbit to be low) abilities of this codec is not perfect, read back a few pages. But it's quickly improving.