What is XviD's "kludge" edition? [Archive]

vkem

13th May 2003, 20:16

I can see some strange XviD-based codec named Kludge there:
http://sourceforge.net/projects/kludge/

Can anyone tell me what's it about and why so funny name with non-serious feeling? Why to do something which isn't compatible with standards?

13th May 2003, 21:10

The project summary pretty well explains it. And the reason why: MPEG4 is too restrictive :D. And why the lame name: because the whole thing is lame :p.

slavickas

13th May 2003, 21:56

@mf
what does all whose kludge's versoins mean. i've downloaded last but later saw that they all have the same date

Selur

13th May 2003, 21:58

1) Be buggy
2) Be incompatible with EVERYTHING (including older and newer versions)
3) Be better than DivX 6 once it comes out

by mf (http://forum.doom9.org/showthread.php?s=&threadid=51634)

@mf:
I did some encodes with h263/quant2/vhq4/chmo/chopt and the files with kludge are 1-2% smaller than the files i encoded with Koepis 03.05 build (with the same settings). ;)

Is this due to some changes made in kludge or just because it bases on a newer xvid version?

Cu Selur

Rrrough

13th May 2003, 22:40

I did some encodes with h263/quant2/vhq4/chmo/chopt and the files with kludge are 1-2% smaller than the files i encoded with Koepis 03.05 build (with the same settings).
same here, plus it crashes zoomplayer during playback when using b-frames >0.

but I guess, it's a feature :sly: :
1) Be buggy

cheers

p.s.: I like the project name, it doesn't sound like marketing hype :) does it have any meaning in any language ?

DaveEL

14th May 2003, 01:30

Originally posted by Rrrough
p.s.: I like the project name, it doesn't sound like marketing hype :) does it have any meaning in any language ?

http://dictionary.reference.com/search?q=kludge&r=67

DaveEL

Sirber

14th May 2003, 01:37

1. A system, especially a computer system, that is constituted of poorly matched elements or of elements originally intended for other applications.

2. A clumsy or inelegant solution to a problem.

:D

Funny

TheXung

14th May 2003, 02:15

cool

14th May 2003, 10:12

Originally posted by Selur
by mf (http://forum.doom9.org/showthread.php?s=&threadid=51634)

@mf:
I did some encodes with h263/quant2/vhq4/chmo/chopt and the files with kludge are 1-2% smaller than the files i encoded with Koepis 03.05 build (with the same settings). ;)

Is this due to some changes made in kludge or just because it bases on a newer xvid version?

Cu Selur
Well, the first 1% gain is from version 0.002a I think. sysKin figured some better solutions to stupid specifications in MPEG-4, and quickly optimized B-frame MC. Also, afaik, kludge allows B-frames to reference eachother, as opposed to only P-frames. So theoretically, the more b-frames you put, the more gain you'll get from kludge over xvid. That also has a limit of course (I guess), but sysKin would be better suited to explain :).

Also, we need developers :D. We (I :p) want DCT keyframes to be replaced by integer wavelets, and we (sysKin :p) also want to replace delta DCT by h.264's integer transform.

JimiK

14th May 2003, 12:18

Some developer correct me if I'm wrong, but I don't think it's possible that BFrames reference other BFrames.
Also, we need developers . We (I ) want DCT keyframes to be replaced by integer wavelets, and we (sysKin ) also want to replace delta DCT by h.264's integer transform.
Is this really planned? Wouldn't that make it quite another codec? I thought someone (sysKin or -h) wrote that you would rather have to create a new codec for this.
Best regards,
JimiK

14th May 2003, 13:39

Originally posted by JimiK
Is this really planned? Wouldn't that make it quite another codec? I thought someone (sysKin or -h) wrote that you would rather have to create a new codec for this.
Best regards,
JimiK
It already is a different codec.

Acaila

14th May 2003, 13:44

Some developer correct me if I'm wrong, but I don't think it's possible that BFrames reference other BFrames. You can code them in any way that you want, however they won't be called B-frames anymore and they won't be compliant to any standard specification. But if you don't case about that, then there's no reason why you shouldn't do whatever you want ;).
IIRC that's exactly the reason why Kludge was started, to make a codec not restricted by any standard (which means you can do a quite a lot of fun things to help compressibility).

I thought someone (sysKin or -h) wrote that you would rather have to create a new codec for this. And that is exactly what they are doing. But they are using XviD to have something to build on. It's always better to build from a starting base then to start from scratch. Kludge isn't meant to stay a version related to XviD, but rather a spin-off without the MPEG-4 restrictions.

Someone please correct me if I'm wrong with all this :).

14th May 2003, 13:59

Originally posted by Acaila
Someone please correct me if I'm wrong with all this :).
100% correct :).

TheXung

14th May 2003, 17:31

Originally posted by mf
we (sysKin :p) also want to replace delta DCT by h.264's integer transform.

Are you talking about replacing the residue encoding with hadamard instead of DCT? What would that buy you in terms of compressibility. Shouldn't it actually loose compressibility? The only advantage I see is making decoding/encoding faster.

14th May 2003, 17:48

Originally posted by TheXung
Are you talking about replacing the residue encoding with hadamard instead of DCT? What would that buy you in terms of compressibility. Shouldn't it actually loose compressibility? The only advantage I see is making decoding/encoding faster.
I'm talking about exactly what I say. We need a transform without any roundoff errors, and since hardware can never have infinite float resolution (except maybe in quantum computing ? :rolleyes:), you will always have those with a floating point transform. So, we need an integer transform. h.264's will do just fine :D.

shlezman

14th May 2003, 18:58

The Integer-Transforms comes together with the quantization and changing the VLC to CAVLC/CABAC adding a nice little in-loop filter could be nice too, changing to 16 MV, long-term reference frames a nice little network adaptation layer ect ...
hmmm looks very similar to H.264, then whats wrong with a Xvid kinda implementation of H.264 which is standard as well ?

Selur

14th May 2003, 20:32

will you also copy new Xvid "features" to kludge as far as it will be possible ?
(like trellis&co)

Cu Selur

JimiK

14th May 2003, 21:21

Thank you guys,
that was my mistake for not seeing that this is just a different codec. Maybe I thought I'd be in the XviD forum. So this project sounds very interesting. Lets have a look if there is room to improve XviD even more without Mpeg4 compliance. But sadly I already lost all visible macroblocks with the latest XviD ;)
Best regards,
JimiK

Atamido

14th May 2003, 21:59

Originally posted by Acaila
You can code them in any way that you want, however they won't be called B-frames anymore and they won't be compliant to any standard specification. But if you don't case about that, then there's no reason why you shouldn't do whatever you want ;).
IIRC that's exactly the reason why Kludge was started, to make a codec not restricted by any standard (which means you can do a quite a lot of fun things to help compressibility).
<shamelessplug> Then you should really look at storing data natively in Matroska. </shamelessplug>

Seriously though, the frame referencing in Matroska allows any other frame to be referenced, not just the frame immediately before or after. You can also reference an unlimited number of frames from a single frame.

It also allows several frames to be stored in a single block, without needing to create dummy frames.

outlyer

14th May 2003, 22:56

Originally posted by Pamel
<shamelessplug> Then you should really look at storing data natively in Matroska. </shamelessplug>
I thought the same. Maybe I've seem too many Chris' posts :devil:
Matroska really seems like the best way to implement Kludge's features/bugs :)

14th May 2003, 23:28

Originally posted by Pamel
<shamelessplug> Then you should really look at storing data natively in Matroska. </shamelessplug>

Seriously though, the frame referencing in Matroska allows any other frame to be referenced, not just the frame immediately before or after. You can also reference an unlimited number of frames from a single frame.

It also allows several frames to be stored in a single block, without needing to create dummy frames.
That's not what we're talking about. I don't give a damn about dummy frames. MPEG-4 by specification simply can't have B-frames reference eachother, AVI or no AVI. It's just a weird limitation, which is exactly the same for MP4 container, Matroska container, or AVI container.

outlyer

15th May 2003, 00:33

Originally posted by mf
That's not what we're talking about. I don't give a damn about dummy frames. MPEG-4 by specification simply can't have B-frames reference eachother, AVI or no AVI. It's just a weird limitation, which is exactly the same for MP4 container, Matroska container, or AVI container.
You still need hacks to implement this in AVI, right? I guess the same hack as to implement plain B-Frames.
Oh, and you still can invent some other kind of frame :D

Atamido

15th May 2003, 02:18

Originally posted by mf
I don't give a damn about dummy frames. MPEG-4 by specification simply can't have B-frames reference eachother, AVI or no AVI. Fortunately we are talking about Kludge, which is not MPEG-4, and therefore might someday have B-frames reference each other.

I was making the point that Matroska could handle types of complex referencing which would not be viable in other containers. So, if they decided to look at complex referencing in Kludge, Matroska would be the best way to store that at this time.

Mooooooooooooo.

15th May 2003, 10:20

Originally posted by Pamel
Fortunately we are talking about Kludge, which is not MPEG-4, and therefore might someday have B-frames reference each other.
As far as I know it already does.

gino25

15th May 2003, 14:56

I have encoded some videos but i have a lot of green lines similar to old xvid builds

15th May 2003, 15:41

Ok, my bad. Miscommunication between me and sysKin :p. I thought we already had b-frames reference past b-frames, but we don't. Going out to kick him now :D.

Sirber

15th May 2003, 15:45

You both live in the same city?

15th May 2003, 17:10

Originally posted by Sirber
You both live in the same city?
IRC kick :D.

gino25

15th May 2003, 17:47

Originally posted by gino25
I have encoded some videos but i have a lot of green lines similar to old xvid builds

If i doesn' t use vidomi it' s all ok.

But there is a bug with all settings and all encoders: I always have some wrong block in all frames?

What is this? Do you know this bug? Do you want that i put a photo?

But the codec is very good. With the same options the video is 10% smaller than xvid.

Thanks to developers:D :D :D :D

bergi

16th May 2003, 06:22

It's a little bit of topic, but where can i find a 16x16 kernel of the ordered hadamard transform? Or is there any formula to calculate it?

16th May 2003, 10:58

Originally posted by bergi
It's a little bit of topic, but where can i find a 16x16 kernel of the ordered hadamard transform? Or is there any formula to calculate it?
Try google.

Selur

16th May 2003, 14:42

Would it be possible to insert quant 1 into the 2pass quantiser distribution, so I won't end up with undersized files if I'm not using a tuned quantMatrix,.. ?

Cu Selur

Ps.: btw. Kludge got the same 'problem' Xivd has with VHQ,.. see: http://forum.doom9.org/showthread.php?s=&threadid=53383&perpage=20&pagenumber=2 (just wanted to bring this to your attention :) )

Acaila

16th May 2003, 16:42

You want quant 1? Last time I tried it wouldn't play correctly at all. Although it would fit perfectly with a name like "Kludge", I still don't think the creators intended to make a video codec whose videos you can't even play ;).

And VHQ slows down dual cpu's just like it does with single cpu's, nothing unexpected about that (one cpu is busy VHQ'ing, the other has to wait for it to finish).

Selur

16th May 2003, 17:08

"And VHQ slows down dual cpu's just like it does with single cpu's, nothing unexpected about that (one cpu is busy VHQ'ing, the other has to wait for it to finish)."
there's another cpu idling, there's power that could and should be useded is more like I see it,... ;)

"Last time I tried it wouldn't play correctly at all."
No playback problems here,... :D

gino25

16th May 2003, 17:50

But there is a bug with all settings and all encoders: I always have some wrong block in all frames.

Nobody has reply.

Am i only with this bug?

When there will be a new release?

Assault

16th May 2003, 18:30

I think I have found a bug. Everytime I enable b-frames in kludge (no matter what other settings I use) the video can't be played back. I only see a few frames (maybe 5-10) and then both zoomplayer and MPC get closed without any message. I can't say for sure but I think the first frame shows bframe decoder lag. With XviD I've only seen this message in VDub. Moreover even VDubMod crashes when I open such files and move the slider to the right. Without b-frames everything works fine.
I'm using Kludge-0.0003a.exe and I have an Athlon 1,2 Ghz with 256mb RAM and WinXP installed. I hope I've written all needed information.

Thanks to sysKin and mf for this great codec. My results without b-frames were very nice. ;)

Regards
Assault

16th May 2003, 19:08

Well, there is no directshow filter for kludge, so that would explain the decoder lag. For the rest I can't see what your problem is.

slavickas

16th May 2003, 21:03

well i can confirm too, that with b frames enabled kludge quickly crashes mpc

16th May 2003, 21:42

Originally posted by slavickas
well i can confirm too, that with b frames enabled kludge quickly crashes mpc
Good, so it's buggy :). Mission accomplished :D.

Assault

17th May 2003, 00:29

Originally posted by mf
Well, there is no directshow filter for kludge, so that would explain the decoder lag. For the rest I can't see what your problem is.
Well, I thought it would be important for you to know that kludge doesn't work with b-frames or rather that I didn't find a way for playing back such encodes until now. ;)

Please don't be too harsh with me because I didn't pay attention to your aim of creating a crappy codec. :p
Just kidding... :D :D :D

Regards
Assault

gino25

18th May 2003, 16:53

Also, we need developers . We (I ) want DCT keyframes to be replaced by integer wavelets, and we (sysKin ) also want to replace delta DCT by h.264's integer transform.

You must ask Nicloas (Rududu autor) to join your team. He made a good wavelets codec (rududu codec). She know very well wavelets

18th May 2003, 18:34

Originally posted by gino25
You must ask Nicloas (Rududu autor) to join your team. He made a good wavelets codec (rududu codec). She know very well wavelets
Well, what is it, he or she? lol

Selur

18th May 2003, 19:27

see:
http://rududu.ifrance.com/
and
http://forum.doom9.org/showthread.php?s=&threadid=52325

gino25

20th May 2003, 14:16

@mf

have you contact rududu nicolas?

20th May 2003, 14:18

Originally posted by gino25
@mf

have you contact rududu nicolas?
No. Bring em here :D.

rududu author

21st May 2003, 10:50

Originally posted by mf
Well, what is it, he or she? lol

It's he !

21st May 2003, 11:19

Originally posted by rududu author
It's he !
Hi! :)

Might you be interested in coding an integer wavelet algorithm in C for kludge? :)

Sigmatador

21st May 2003, 12:36

Also, we need developers . We (I ) want DCT keyframes to be replaced by integer wavelets, and we (sysKin ) also want to replace delta DCT by h.264's integer transform.

oooohhhh!! looks very promising ^c^ it will kill other codec ;)