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