Bug in Koepi's [XviD-03012003-1] build

[philippas]

I get some nasty errors very frequently in the film.
I kept the 1st pass of the encode to check how it would look like, at quant 2 and i noticed the errors.

The settings i used are:
2-pass 1-pass
M.Search:6
Q.Type:H.263
Max. I-frame interval:200
Min. I-frame interval:1
bframes and everything else dissabled
Credits encode at 10(I-frames)& 12(p-frames)


The Script i used:

LoadPlugin("C:\Divx\GORDIA~1\mpeg2dec.dll")
LoadPlugin("C:\Divx\AviSynth\Plugins\convolution3d.dll")
vid=mpeg2source("E:\SPIDERMAN\1.d2v").trim(0,166630).crop(2,12,716,552).convolution3d(0,8,8,8,8,3,0).BicubicResize(512,288,0.5,0)
cred=mpeg2source("E:\SPIDERMAN\1.d2v").trim(166631,0).crop(2,12,716,552).BilinearResize(512,288).Blur(1)
vid+cred


I use Windows Xp sp1 and my cpu is an athlon xp.

I'm attaching a screenshot along with the settings and the avs that i used.

[NeVeRLiFt]

Could you describe the errors and what you saw?

I dont see your attachment... thats why I'm asking for you to describe it.

[philippas]

A moderator has to approve the attachment that's why you can't see it.
I get macroblocks with mixed or clear colour. The strange thing is that i did another 1st Pass using FluxSmooth instead of convolution3d and i didn't get any errors :confused:
Now i don't know if the errors are caused by the filter or xvid.

Has anyone got any problems with convolution3d ?

[Koepi]

avisynth 2.5 is _alpha_

the filter for it are...

..alpha..

what do you expect?

Koepi

[philippas]

@Koepi
No i didn't use that version of the filter. I'm using avisynth 2.07 that's why i didn't expect it to cause problems.

[EDIT]
I examined more carefully the video that i encoded using FluxSmooth and i was wrong in my previous post, i get the same errors as before only maybe less frequently. Having used both filters, convolution3d and FluxSmooth, without any problems in the past, makes me think that the errors are produced by Xvid.

[philippas]

Ok i disabled the filters (convolution3d & fluxsmooth) and i encoded a part of the video that i got errors, and the errors are still there.
I encoded that part with huffyuy and didn't get any errors.
I uninstalled xvid and i installed the stable version of koepi, still i got the same errors. In the stable version i unselected all optimizations and still the errors are produced!
Very strange.
Maybe the video is cursed:eek:

[-h]

If the video generates coefficients that are greater than the range [-256,255], dequantization will fail. Well actually only MMX/SSE dequant will fail, normal C should always work.

Seems a tad odd.

-h

[NeVeRLiFt]

I have some samples with B-frames made using Nic's latest build and they used to play fine except for a B-frame decoder lag error.

Now they dont play at all.

Get three different error's...

1) video plays, but the video stops and the audio keeps going... nothing gets it to play.

2) video plays back very jerky... like the B-frames are being skipped.

3) the video either plays then goes black and white letters scroll across stating something about a B-frame decoder error (are the video is just black stating a B-frame decoder lag error)

any ideals??

[NeVeRLiFt]

after more testing and careful uninstall and reinstall...

I have the builds down to whats doing what.

Koepi's build just plays back the samples with B-frames and skips them acting as if they are not there, this leads to very jerky video.

Nic's build plays them... but I get the black screen in the video with white letters... I have saw two error msg so far.
1) Warning Nothing To Output Bframe decoder lag(nothing but black screen with the white letters)
2) Broken Bframe, Mising RE(video plays but white letters appear and flash at top of screen stating the error Broken Bframe, Mising RE)

uManiac's build plays them back fine! :eek: :D :confused:
Certain samples play back fine and normal, while a few seem to be playing back in slower than normal. The slow back one's are the one's Nic's build said had Bframe decoder lag....

All samples with Bframes where made using Nic's latest build.

All in a nights testing ;)

/me yawns and gets ready for bed now!

[sillKotscha]

Originally posted by NeVeRLiFt
... but I get the black screen in the video with white letters... I have saw two error msg so far.
1) Warning Nothing To Output Bframe decoder lag(nothing but black screen with the white letters)
2) Broken Bframe, Mising RE(video plays but white letters appear and flash at top of screen stating the error Broken Bframe, Mising RE)

Hi NeVeRLiFt,

nice to hear that someone else noticed the same...

according to my thread here (http://forum.doom9.org/showthread.php?s=&threadid=42205) I can confirm your observations

have a look to the link in my first post and the link in my last post within my mentioned thread.

regards Sill

[NeVeRLiFt]

Thanks for the heads up.
Seems I'm not the only one having a Bframe decoder problem.
I know Bframes are still experimental... but I wanna use them :D
I dont have a problem with DivX5 so it must be in the build's or a decoder problem.

[kastro68]

Has anyone noticed a considerable difference in quality between koepi's 3.1.2003 build and older builds?

It may be just me, but i believe the 14/12/2002 build gives better results than the 3.1.2003 build.

[seewen]

Originally posted by kastro68
Has anyone noticed a considerable difference in quality between koepi's 3.1.2003 build and older builds?

It may be just me, but i believe the 14/12/2002 build gives better results than the 3.1.2003 build.

I only use B-frame ( no QPEL ), and I found that 3.1.2003-koepi was better than 24.12 & 29.12.

----

And since yesterday, I tried the new Umaniac Dev ( 9.1.03 ), and it is about 20-40% faster than 3.1.03-koepi.. ( same film & same parameters. Tried on 3 differets movies ).

But it seems that 3.1.03-koepi gives better result ( same film & parameters : B-frames, MSP-6, CHroma, Lumi, alternative curve "medium/defaults values ) than 9.1.03-umaniac.
But it could be only a psychological difference ;)

I don't know if the speed gain is due to the difference between koepi-umaniac code or between January-03 and December-02 General-XviD-Code.

[NeVeRLiFt]

I'm just switching between all three still.(Nic's, Koepi's and uManiac's)

Right now I'm using uManiac's and like it alot. Its fast, stable and very good results. When I want Bframes I use Nic's. And use Koepi's between them for testing and checking stuff.

[Koepi]

I'm using refdivx' lumi masking code which is slow, but produces nice images. umaniac compiles straight from cvs, with the old, ugly adaptive quantization code...

Koepi

[Teegedeck]

Hello Koepi,

do you use lumi-masking (ReferenceDivX' code) just for some special cases or frequently?

I'm asking because I've been a bit desperate, lately, finding good reasons to use it.

Yours,

Tee

[seewen]

Originally posted by Koepi
I'm using refdivx' lumi masking code which is slow, but produces nice images. umaniac compiles straight from cvs, with the old, ugly adaptive quantization code...

Koepi

Ok.

I wasn't sure, if it was B-frame or Lumi-Masking, but 1 of these option wasn't as good as yours.

[mikeson]

@Koepi:

May I ask why isn't refdivx' lumi masking code included in CVS?

[Assault]

@ Koepi
I tested several movies and noticed that revdivx' lumi masking code didn't improve compressibility but it made it even a little bit worse. Isn't the aim of lumimasking to improve compressibility by using higher quantizer at images where you don't notice it much?

Regards
Assault

[Teegedeck]

I had thought it would somehow make high quants look less ugly by removing more high frequencies with higher quantization; changing the quant-table on the fly or something. But hm, I'm not sure - it seems to act evenly on all quants. I know so little [edit: or in fact: nothing] about what ReferenceDivX' code does and it seems he hasn't posted much about it on the forum, either.

[MaTTeR]

Originally posted by Assault
@ Koepi
I tested several movies and noticed that revdivx' lumi masking code didn't improve compressibility but it made it even a little bit worse. I mentioned this a few days ago too. However I tried a few encodes with uManiac's instant build today and it actually did improve compressibility using Lumi.

[Teegedeck]

I had thought uManiac's CVS-builds yielded besser compressibility because the CVS still uses a too-small-limit of 2, not 1. But as we now know that the CVS has the _old_ lumi-masking code, that seems to be the reason.

[Assault]

If lumi masking doesn't improve compressibility I cannot understand the advantage of using it. :confused: :confused: :confused:

Assault

[sam_b]

If it looks better afterwards than using an increased bitrate without lumi then it is still doing it's job. It may need higher 'official' quant setting to reach the same bitrate, but that does not really matter. It's just superficial.

[Assault]

How does refdivx' lumi masking improve quality? What does it actually do? Is Teegedeck right and it removes more high frequencies with higher quantization?

Assault

[Koepi]

refdivx' code is based upon HVS and as such only removing detail where it's really not visible. BUT it can increase detail where it's necessary, too. So it's not just a "bitrate reducer". It's more bitrate redistirbutor - just within a frame.

Regards
Koepi

[Assault]

@ Koepi

That sounds very nice. ;)
I think I'll use lumi masking during my next full encodes. Thanks for clearing this up. :D

Assault

[Teegedeck]

Originally posted by Koepi
refdivx' code is based upon HVS and as such only removing detail where it's really not visible. BUT it can increase detail where it's necessary, too. So it's not just a "bitrate reducer". It's more bitrate redistirbutor - just within a frame.

Regards
Koepi

So it is a bit like I thought it was.

Hm, I guess I'll have to do more testing. As of yet I've only tested it on a very detailed, crisp source, at MPEG-quants 2 and 7. And at 2 it made for a degradation of quality, at 7 I couldn't tell much of a difference. Not enough tests to really tell. Maybe a question of personal taste, too?

[cweb]

I installed an older build (from December) by umaniac and bframe clips didn't play any more. So I just installed the Directshow standalone decoder by Nic. You can get it from Koepi's site. It fixed the problem and I can play them again.

With Koepi's builds it is included, but I think it wasn't included with some other builds.

Hope that helps.

Originally posted by NeVeRLiFt
Thanks for the heads up.
Seems I'm not the only one having a Bframe decoder problem.
I know Bframes are still experimental... but I wanna use them :D
I dont have a problem with DivX5 so it must be in the build's or a decoder problem.

[NeVeRLiFt]

Originally posted by cweb
I installed an older build (from December) by umaniac and bframe clips didn't play any more. So I just installed the Directshow standalone decoder by Nic. You can get it from Koepi's site. It fixed the problem and I can play them again.

With Koepi's builds it is included, but I think it wasn't included with some other builds.

Hope that helps.

I had Nic's latest build... this was stated in my post FYI.

[philippas]

Hi,
It turns out that my problem wasn't caused by xvid.
I recently added some extra memory in my system which was damaged. At first i thought that windows have been messed up, but after some testing i confirmed that the problems were caused by the memory.
I couldn’t post earlier cause i'm a bit busy this period. Looking forward to test the new features of xvid like GMC,b-frames e.t.c
Keep up the good work :)

[-h]

Why is it that XviD is always the component that causes unstable systems to finally topple over and crash?

-h

[Koepi]

THAT answer is simple, Dan :)

XviD is using every function unit on a modern processor (SIMD extensions, FPU, ALU,...), making the processors really warm.
If you don't have a proper fan for your system, the CPU will overheat and the system will freeze.

XviD is very memory (bandwidth) intensive.
Improper coolment of the northbridge, and *bang* system fails again. Or damaged memory *shudder* it shouldn't be too bad with broken memory, it should only produce artefacts (that's bad) or the application dissolves in digital nirvana without even throwing an exception.

To sum it up a bit, XviD is bringing every system close to it's "borders" of the spcifications (ie. cpu temperature again, chipset and memory temperature, or even worse, if there's a bug like the via southbridge bug for other functionalities of the chipset it can trigger it due to it's memory bandwidth demands, it should use the chipset schedulers at the limits as well).

I think I found the counterpart of cyclic kernel/gcc compilation in linsuxx - xvid does show such errors as well. :) (On my k6-2 I got many sig11's - bad memory... to bad i don't have that system anymore, would be fun to kow if it really unveils the error.)

I hope your question wasn't pure rethoric(?). Anyways, even if it was, it may help other people understand things a bit better :)

Best regards
Koepi

[NeVeRLiFt]

@Koepi

The same holds true for videocapturing with XviD. I noticed it really gets my capturecard warm.

[sillKotscha]

who captures straight to xvid???

aside from avih :D