Rududu codec : new test version

[rududu author]

Hello all !

I just released a new version of Rududu, so I'm very interrested to know what you think about it, what should be improved, what is good ...
for the english speaking people, the page is :
http://www.ifrance.com/rududu/codec3en.htm
pour les francophones :
http://www.ifrance.com/rududu/codec3.htm

thank you for your answers

Nicolas

[Sirber]

Allo Nicolas.

Pense-tu offrir les sources aussi?

Hi Nicolas.

Do you think you'll release the sources?

[gino25]

great!!!!!!!!!!!!;) ;) ;) ;)

[rududu author]

Originally posted by Sirber
Allo Nicolas.

Pense-tu offrir les sources aussi?

Hi Nicolas.

Do you think you'll release the sources?

Ce n'est pas exclu, mais pas pour le moment. Peut-être lorsque j'aurais trouvé un boulot.

It's possible, but not now. Maybe when I'll found a job.

[gino25]

What are settings for a high quality encoding?

I tried some settings but video has not much details

[rududu author]

Originally posted by gino25
What are settings for a high quality encoding?

I tried some settings but video has not much details

Well ...

good question :-)

The min quality was 32, but I limited it to 64 because of some (stupid ?) reasons. So you can't for the moment. And if you try to set the dead zone ratio below 256-ThresRatio you will see a beautifull bug. So I have to correct all this.

Sorry :-)
I have too much tested with the settings for a "middle" video quality...

Nicolas

[Koepi]

This sounds definatly interesting. Can you please give some more information like

- is the codec meant for archive or capturing purpose? (i.e., which datarate does it perform at "best")
- how fast is it? (i.e., does it do 720x576 in 20x realtime or is it more like 5fps)

... and so on.

If we test it, we need to know the "design goal" to give a proper feedback.

Thanks for your nice work, keep it up!

Best regards
Koepi

[Sirber]

I'd like to know if it's I frames only in wavelet or if there is P frames too... :)

[rududu author]

Originally posted by Sirber
I'd like to know if it's I frames only in wavelet or if there is P frames too... :)

All the frames are compressed with wavelet. it's the antonini 9/7 transform, used in the JPEG2000 standard.

[gino25]

I have tried a lot of settings. But in all videos there is low details. (quality was at max)

Ruududu version2 have more details.

Why? Help

[Sirber]

Won't we have greater quality by using p-frames?

[rududu author]

Originally posted by Sirber
Won't we have greater quality by using p-frames?

There are P frames, I'm just saying that I frames and P frames are compressed using wavelet (even the motion vector field will be compressed using a simple wavelet)

[Sirber]

That's great! I taught it was only I frames... sorry :)

[Koepi]

So i still have to assume things and don't get any real insights? :P

Let me summarize:

rududu codec is
- an (integer?) wavelet (antonini 9/7 transform) codec
- using I- and Pframes
- using wavelets for compressing motion vectors (wtf? wavelets and motion vectors don't mix, sounds like a block based attempt again)
- optimized for medium quality at unknown speed and for unknown purpose (archive quality / temporary capturing space+speed)
- had better quality in the last beta version
- written by Nicolas from france

That's all we have about that codec for now. Or did I miss anything?

[Sirber]

This seems correct with the infos we have now. Maybe Nicolas didn't understand your question...

From Koepi (Translated by Me):

Ça a l'air vraiment intéressant. Pourais-tu svp nous donner des informations de plus comme

- Est-ce que le codec a été conçu pour archiver ou pour capturer (c-a-d a quel kbps il donne la meilleure qualité)
- Quel est sa vitesse? (c-a-d, est-ce qu'il fais du 720x576 a 20x la vitesse du temps réel (mouhahaha) ou c'est plus du 5 fps)

... et on continu!

Si on doit le tester, on doit savoir le "but" pour pouvoir te donner des commentaires pertinents.

Merci pour ton bon travail, lâche pas!

Meilleurs veux

Koepi

[Koepi]

Thanks for translating that Sirber, my french is _really_ rotten ( I can't even "decompress" most of your french abbreviations :) ) and additionally, our main language here is english so that everyone has the chance to understand things.

Merci beaucoup pour tous (even that looks wrong to me - I need a refresh-your-french-class it seems),

Koepi

[Sirber]

Merci beaucoup pour tout

no "s" :)

It means "Thanks a lot for all"

[Koepi]

I know what I _want_ to write ;)

I only missed the tout<->tous difference. So after all it's (EDIT: = my french) not way worse as it was after school ;)

EDIT2: after reading this in english I think in german we're way shorter, here we just say "Danke für alles" - 3 words vs. 4 in french and 5 in english :)

Regards
Koepi

[Sirber]

lol :)

I was just teasing :D

[spyder]

"Thanks for everything" <-- 3 words in English :)

[Sirber]

I know I know I'm not goud with English... :(

You hurt my feelings :( ;)

[Kyo]

"Gracias Por Todo" 3 Words <- Spanish :)

But I know that only one kanji suffice to win :p

/Sorry for be OT

[gino25]

Have you tried the codec?

Which settings have you used? And the quality is good?

[rududu author]

Originally posted by Koepi
So i still have to assume things and don't get any real insights? :P

Let me summarize:

rududu codec is
- an (integer?) wavelet (antonini 9/7 transform) codec
- using I- and Pframes
- using wavelets for compressing motion vectors (wtf? wavelets and motion vectors don't mix, sounds like a block based attempt again)
- optimized for medium quality at unknown speed and for unknown purpose (archive quality / temporary capturing space+speed)
- had better quality in the last beta version
- written by Nicolas from france

That's all we have about that codec for now. Or did I miss anything?

Sorry, I didn't see your last post, i will answer your questions:

Rududu is intended for an archiving purpose and I would like it to be a medium (600kb/s) to low bit rates codec. For the moment don't use it for archiving because : I didn't fixed the bit stream and I make changes to the codec every day and there is no error resilience or correction process, so if you change a bit in the stream the codec will crash.

So yes, it's an interger wavelet transform implemented on 16 bits MMX. I had precision problems with this but it seems to be fixed now.

It use I and P frames and no B frames and I will try to not use B frames in the futur.

I plan to use the Haar wavelet transform (the simplest wavelet) to compress motion vectors. it's more for convenience purpose than because wavelet is better. Yes it's a bloc based codec like all the "good" codecs in this world ... What's wrong with that ?

For the moment not optimized for any purpose (neither for speed nor for a bit rate). It's just a developpement step, I didn't spent a lot of time tweaking it to get the best result, I don't think it's useful as it's not a final release.

If you think the quality was better in the last version ...
I don't think so, the fact is that in this version I limited the minimun quantizer and then you can't get high quality at high bit rate, that's all.

Yes, written by Nicolas from France, near Grenoble. Is this important ?

In fact with this version I just want to know how do you think rududu compare with the other codecs, saying at the same file size (as there is no rate control algorithm in rududu for the moment).

@Koepi (or other xvid developper): a question about xvid : do you limit the quantizer for the DC component of the DCT transform ? What are the min and max that are used in xvid ?
Thank you.

[ChristianHJW]

Originally posted by rududu author For the moment don't use it for archiving because : I didn't fixed the bit stream and I make changes to the codec every day and there is no error resilience or correction process, so if you change a bit in the stream the codec will crash.

Nicolas, you could use matroska for that, use it as an elementary stream with minimal overhead, it will do exactly what you wnat it to do. spyder had plans to make this once, he looked into it and found that matroska could offer very good performance here if you strip out everything you dont need and use simply the track structure !

I tried using your codec today, and it gave me the same error as last time i tried :

compressor output error : invalid source format ( error code -2 ). I know i had this problem once and could fix it with Selur's help, but i cant find the thread here anymore that would tell me what to do :( ....

[rududu author]

Originally posted by ChristianHJW

I tried using your codec today, and it gave me the same error as last time i tried :

compressor output error : invalid source format ( error code -2 ). I know i had this problem once and could fix it with Selur's help, but i cant find the thread here anymore that would tell me what to do :( ....

It's because my very limited codec just want to use image dimentions multiples of 64, so 512x384, 640x320, ... if your image dimentions are not multiple of 64 you will get an invalid source format.

[Koepi]

Thanks for your reply Nicolas! :)

I hope you didn't get me wrong, I just summarized what I could find as information on this thread and on your page about the codec.

Someone posted he had better results with the last beta version, so I put it in there.

The XviD quantizer range is from 2 to 31 (quant 1 is quite useless as it does increase the size of a frame by a huge amount while not giving any visible quality increase).

What's so bad about the block based attempt? Well, wavelets can perform on the whole image at once (like Eduardo impressively demonstrates with a capture-targeted demo implementation of a floating point wavelet over at his sourceforge page [http://sf.net/projects/btwincap/ ]. The codec is meant for developers only and Eduardo has good reasons to write that).
Thus you could use a temporal wavelet as well. I don't believe the gain of using wavelet instead of DCT is noticable - I think that's why you're trying to use a wavelet on the motion vectors as well now.

Best regards
Koepi

[ChristianHJW]

Originally posted by rududu author It's because my very limited codec just want to use image dimentions multiples of 64, so 512x384, 640x320, ... if your image dimentions are not multiple of 64 you will get an invalid source format.

Impressive !! Its encoding my 448 * 320 movie with 23 fps on my PIII 1000 MHz laptop !!!

Thanks for pointing out Nicolas, i missed that, shame on me .... and drop an email to the list if you needed help with using matroska ES for your codec. You could use all the Goodies like EDC/ECC, etc. ...

[Tommy Carrot]

My impressions:

It may be arguable, that the new version is better detail-wise at a given quantizer, than the older version (Nicolas, why did you changed the quantizers to quality slider? It seems to me, that quality/10=quantizer, right?), but the vibrating screen problem has been fixed, the image is quite stable now.

If the codec doesn't use b-frames, why are the odd frames much shorter than the even ones (or inversely ;))? This is a way to eliminate the vibrating?

Could we get some short description about the function of the lower 3 sliders?

[rududu author]

Originally posted by Koepi

What's so bad about the block based attempt? Well, wavelets can perform on the whole image at once
Thus you could use a temporal wavelet as well. I don't believe the gain of using wavelet instead of DCT is noticable - I think that's why you're trying to use a wavelet on the motion vectors as well now.


I said that the motion compensation is block based, but the wavelet transform is performed on the full frame.
When I said that I want to use wavelet for the motion vector coding, I didn't said I want to use 3D wavelet. The scheme I plan to use is just a substitute to the median based prediction of the motion vectors for MPEG4, and I think it will not perform better, it's just because it's more simple for me. But you're right on 1 point : I will try to improve my codec.
About the use of wavelet instead of the DCT :
I have red a lot of papers doing my codec and I know that wavelet and DCT are quite the same for video coding, I know also that 3D wavelet doesn't perform better than motion compensated systems (that's why I don't plan to use it). But I think that wavelet's artifacts are much less noticeable than DCT ones, and that wavelets can perform better for very low bit rate. But all this is my opinion, you can have a different one.
My codec is not a "state of the art" codec. It's just a lot of experimentations (that's why I spent so time to output a new version : I tested a lot of not so good ideas).

About the details now :
There are less details than in the last version (not sure, but ...) but the video looks better. As I said I have not tweaked the codec to have the better. I have to do the same job that has been done to decide the MPEG quant matrix : match the quantization system on the human visual system. And this is only experimental results : so test, improve, test, improve, ...

@Tommy Carrot :
You're right, I will rename quality "quantizer" as it's directly related to the quantizer. In the last version it was already called quality and now you have about : new_quality = old_quality * 8.
Some frames are smaller because 1 frame use quality and the other use quality * 2 (so the second is smaller).I don't know if the overall result is better or not, I just wanted to try (and it's not to correct vibrating).
There is no B frame, but I will try to use "false" B frames (frame predicted by 1 frame but not used to predict an other frame).

I will now stop experimentations for some time to make a "usable" codec.

Nicolas

[Sigmatador]

a small question for nicolas: what do you think about the actual Ogg Tarkin source code ?

edit: Thanks for all = Merci pour tout = Danke für alles = Gracias Por Todo
don't forget the "A LOT" in your translation, it's more equitable ^^ ( i can play ? : arigatô <-- One word :D oops i forgot something ? :p )

[Sirber]

Originally posted by Sigmatador
a small question for nicolas: what do you think about the actual Ogg Tarkin source code ?

edit: Thanks for all = Merci pour tout = Danke für alles = Gracias Por Todo
don't forget the "A LOT" in your translation, it's more equitable ^^ ( i can play ? : arigatô <-- One word :D oops i forgot something ? :p )

arigatô = merci = thanks.

It's japanese :)

[Sigmatador]

Originally posted by Sirber
It's japanese :) [/B] You win ^^ lol
hum. let's return to the wavelet discussion ;)

ps: glurps 3h00am in france --> oyasumi nasai :D

[Sirber]

I know maybe 5 words in japanese... but like you said, lets return to wavelet :)

[rududu author]

Originally posted by Sigmatador
a small question for nicolas: what do you think about the actual Ogg Tarkin source code ?


I've downloaded it, but didn't looked deeply how it work. For the moment it's mainly a static frame coder (I frames) and a 3D wavelet codec.
I've subscribed to the Tarkin mailing list but there is no activity since months.
I don't know what this project will become, but its goals are very difficult to carry out (1 film on 100Mo). In 10 years we will see ...

Nicolas

[Sigmatador]

Originally posted by rududu author 1 film on 100Mo [/B]

wouah they're crasy ^^ lol

hum your codec works, so i prefer it ^^ good job!

[Tommy Carrot]

Upon closer inspection, i realised, the colors are finally correct, watching the clips in Virtualdub. I'm glad this is fixed. But the DSF is still changes the colors (darker, more brownish, etc).

The last major disadvantage left imho the motion trails. 4 example, at higher quality (quantizer) setting, the moving trees leave behind green colorization on the sky, etc... If you could fix this somehow (though i guess this would be hard task), the codec would really compete with the most popular codecs (i really like the lack of mosquito noise, and blocks).

[IvS]

I'd love to check out the codec, but, with VirtualDub/mod when i try to encode a video, no matter what size or anything, any video, i get "Output compressor error: The source image format is not acceptable. (error code -2)".
All codecs work for me, but with this one i've tried anything but i just can't figure out why this error won't go away. (fast/normal/full processing mode as well. No filters. Even with/without audio.
I'm using the latest Rududu version, have a pentium 4.
I'd be glad to help by doing/answering anything (that i can) you ask in order to find the problem.
And thank you for this free video codec! That's always good to see.

[ChristianHJW]

Originally posted by IvS I'd love to check out the codec, but, ... The source image format is not acceptable. (error code -2)".

I had the same problem, the input resolution must be dividable by 64 for both width and height, like

320 x 256 ... etc. . If you had checked this thread here more thoroughly you would have read that ..

[IvS]

:scared:...damn! I did read, but somehow didn't understand it well, i assumed it needs a standard resolution like 320x240 etc...man..
Thanks Chris.. I hope this will be changed soon and there will be better resolution support.

(Gee crap :).. now that i look, i missed the two posts concerning just that. need sleep)

[rududu author]

Originally posted by Tommy Carrot
Upon closer inspection, i realised, the colors are finally correct, watching the clips in Virtualdub. I'm glad this is fixed. But the DSF is still changes the colors (darker, more brownish, etc).

The last major disadvantage left imho the motion trails. 4 example, at higher quality (quantizer) setting, the moving trees leave behind green colorization on the sky, etc... If you could fix this somehow (though i guess this would be hard task), the codec would really compete with the most popular codecs (i really like the lack of mosquito noise, and blocks).

It seems to me that the dshow filter as the right colors, but as it uses overlay, the colors could be different from the rgb output (on most video cards you can set contrast/britness...). Someone other thinks the colors are wrong in the dshow filter ?

Thank you for your feedback about the codec. I don't know if I will be able to improve this, but I will try. Is this effect more important on colors or on luminance ? (difficult to say, but this could help).

Anyway, the more feedback I get, the more I will be able to improve the codec.

Nicolas

[ChristianHJW]

My test results are, well, mixed :D :

- file size compared to the MPEG4V3 source was 38%, but i forgot the quality setting i was using, i guess i out the slider to the middle :)

- the output is looking a bit 'cloudy', means there are areas of reduced resolution and smearing, but despite that its working fine ...

[Sirber]

Can we get some screenshots?

[vkem]

Originally posted by Kyo
"Gracias Por Todo" 3 Words <- Spanish :)

But I know that only one kanji suffice to win :p

/Sorry for be OT

Heh, in Finnish it's said "Kiitos kaikesta", 2 words :D

[Tommy Carrot]

Here (http://www.ifrance.com/rududu) is a newer version. I have not tried it yet, but the resolution limitation has finally gone.

[gino25]

Good!!


Let' s start tests

[Sirber]

Will lastest version have bitrate control?

[rududu author]

Will lastest version have bitrate control?

No, and no rate-distorsion optimisation. For the version 1.0, I will just fix the stream syntax and the algo / transforms used. And try to remove bugs.

bitrate control and optimisations can be done without modifying the decoder and I will try to do this later.

I will also implement B frames (contrary to what I thinked first) but not immediatly, so the decoder will be able to read a stream with B frames but will not be able to decode them. Also I don't want to put B frames in avi, so I will wait for an API to put B frames in matroska (or what you want, but there is no API).


Upon closer inspection, i realised, the colors are finally correct, watching the clips in Virtualdub. I'm glad this is fixed. But the DSF is still changes the colors (darker, more brownish, etc).

in fact the coeff used for RGB->YUV and YUV->RGB were wrong, so two mistakes were done in vdub (input, output) and only one in the dshow filter (input) so the filter seams wrong but in fact was the only right. Now it should be OK for input RGB24 and output RGB24, but the input RGB32 is still buggy.


I will also explain the quantization process on the site so you will be able to understand how to use the properties window.


Nicolas

[Atamido]

Originally posted by rududu author
I don't want to put B frames in avi, so I will wait for an API to put B frames in matroska (or what you want, but there is no API). There are currently a couple of methods to get B frames into matroska.

1. Create a DirectShow encoder, and then connect that to the matroska muxer. (pretty good)

2. You could have the codec pass dummy frames to VirtualDub, and then have it create its own file seperately (like the log file is created with DivX). From there you just tell Mosu how to parse the file, and he could add it to mkvmerge. (atsa hack, but it would let you use VirtualDub)

3. Create an encoding tool to use the Lem API. (Simple, but not a lot of support)

[unmei]

Last update: 1/1/1970

i'm really surprised this page was last updated and a codec like this existed already on day one of the linux era ;D

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

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

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

[LigH]

*Cough* - blowing the dust off this thread...

Seems that there is no further development since september; how bad, this could have been such a great project.

[rududu author]

well, not so dead, just "sleeping".
I will continue the developpement, but I have no time at the moment.

Nicolas

[LigH]

So, at least, thank you for this "sign of life", and best whishes!

[unmei]

hey yeah, thanks for clearing the situation, nicolas! Take your time, i'm just glad you haven't given up :)

[pieter1976]

I think a Wavelet is a kind of interpolation.

Not a very good one.

I wonder if better compression ratio's could be achieved using better interpolations.

http://audio.rightmark.org/lukin/graphics/resampling.htm

This is dynamic interpolation using edge enhancement.

[d'Oursse]

Originally posted by pieter1976
I think Wavelet is a kind of interpolation.
no, not at all.

interpolation is getting information with few data (you have the values of a function at points 0 and 1. You want a approximated value of this function for all real numbers between 0 and 1, for example)

wavelets (more precisely a wavelet basis) are a way to describe information (a function) at different levels of detail (sorry for this very short description).

If you are interested, look at books and papers of Y. Meyer, S. Mallat, I. Daubechis, A. Cohen and so many other authors about wavelets.

[pieter1976]

This is what i know about wavelets

It first uses a image that is smaller than the size of the origenal.

second the resolution is increased.

pixels are smoothed

detail is added

resolution is increased

pixels are smoothed

detail is added

enz..

enz..

the part of increasing the resolution and smoothing the pixels is called interpolation.

please tell me if I am wrong.

[Lefungus]

You're wrong.
It'll be too tedious to explain wavelets on a forum in a foreign language. Like D'Oursse, i suggest you grab a book on the subject. There are also many sites on the subject that may interest you :)

[pieter1976]

I have looked at several paper and even made a computer program in Delphi to test it and it gave similar results.

these are the basics

You use four pixels

12
34

Than calculate the everage of the four pixels(low resolution part)
after that calculate the high frequenties (detail information)

Do this in a recursive way

The high frequenties values are compressed by losing bits.

http://www.acm.org/crossroads/xrds6-3/sahaimgcoding.html

[Lefungus]

Originally posted by pieter1976

http://audio.rightmark.org/lukin/graphics/resampling.htm

This is dynamic interpolation using edge enhancement.

This is off topic, but i would love to have a smart-edge resize avisynth filter :)

[pieter1976]

yes that would be great. It must be posible to make dvd resolution frames out of VHS frames and still have a good quality.

[Lefungus]

The authors doesn't seem to offer some source code though :/

[pieter1976]

I have made a smartedge filter but it is very slow and i don't know how to make one for a program like virtualdub.
It also needs some more work to be ready.

Does someone know how?

maybe a thread on this subject should be started.

[Selur]

yeah, a (avisynth/directshow) resizer with this might be cool, but without any sourcecode or at least a paper that discribes it,...

hoping for rududu author to find some time to develop rududu a bit ;) (I like the codec and like LigH I think it is a great project)

Cu Selur

[kilg0r3]

Hey Nicolas,

I don't know if you are still listening, but what about joining your project with that of the BBC?

[superdump]

Hmm, over a year on and no more news? Even if it's just another - "I'm still alive, I have no time to work on it and I'm unlikely to in the future. Here's the source code."

[General Lee D. Mented]

Hmm, over a year on and no more news? Even if it's just another - "I'm still alive, I have no time to work on it and I'm unlikely to in the future. Here's the source code."

Boo!!

[Sirber]

already 1 year? :(

[superdump]

Boo!!Hello there GLDM. How are you doing? Any progress with WARP? :)

[issa]

I have looked at several paper and even made a computer program in Delphi to test it and it gave similar results.

these are the basics

You use four pixels

12
34

Than calculate the everage of the four pixels(low resolution part)
after that calculate the high frequenties (detail information)

Do this in a recursive way

The high frequenties values are compressed by losing bits.

http://www.acm.org/crossroads/xrds6-3/sahaimgcoding.html

You can said decoding process is kind of interpolation. However, in interpolation, you are guessing the thing in between, but the in wavelet, you alway have the orignal (sort of) information of the gap.

[General Lee D. Mented]

Hello there GLDM. How are you doing? Any progress with WARP? :)

Nope, not really. Been too busy with moving, working, getting married, etc. I did eventually find the overflow bug, but I've never gone back and made any changes or improvements. I just haven't had the time and enthusiasm to bother.

[General Lee D. Mented]

You can said decoding process is kind of interpolation. However, in interpolation, you are guessing the thing in between, but the in wavelet, you alway have the orignal (sort of) information of the gap.

Well the thing is, with interpolation you're assuming that the intermediary values have a linear relationship to the sample points. With a wavelet or DCT system, you encode your data as the parameters to generate functions that fit the sample points. So instead of just guessing the middle, you guess whatever your function graph produces with the parameters you have available on decode. The problem is, if your function isn't a good match for your data, your quality/size ratio sucks, and it's more compute intenseive than just simple averaging.

I've got a compromise system design for this BTW, never implemented it.