XviD-08032003

[sungey]

they are as compatible as h263 as far as i know ... ^^ ...

[terwin]

At first, the new b-frame decision works perfectly for me. MSP=6,h263,VHQ4,qpel,cm,bf(3/100/200/0)

Only a short question. Can I change the b-frame threshold in the 2nd pass?

cu terwin

[JimiK]

@Arcon
I'm not sure who's xvid.ax is in CVS as I don't build this dsfilter. But I thought it would not be Nic's. Koepi is using Nic's filter as decoder in his latest build. The "normal" dsfilter should be smaller and you can't select postprocessing in it's properties, but have to set it in the properties of the dll config dialog. Of course you should believe Nic that he's doing no postprocessing if you don't select it.
What do you mean with "old dsfilter that has no built in postprocessing"? If I'm not completely wrong, then there is pp when using the "small" xvid.ax for quite some time now.
Maybe I'm really wrong, would be nice if somebody could clear this up for me.
Best regards,
JimiK

[Arcon]

Originally posted by JimiK
What do you mean with "old dsfilter that has no built in postprocessing"?
the XviD-17022003-1 build had a smaller xvid.ax that had only an info-dlg as properties, no postprocessing settings. the new xvid.ax from the current build has all of nic's pp-options. it might well be that the old filter did pp too, but at least it wasn't obvious to me :)

[Assault]

@Arcon

With the XviD-17022003-1 build you can choose both luma deblocking and chroma deblocking in the xvid configuration under decoder options. ;)

Regards
Assault

[sungey]

anyone has trouble with Nic's dshow filter included in 16/03 build ? it doesnt work on my pc .. if i use ffdshow alpha with xvid.dll decoding .. my Explorer.exe crashed.. using xvid.ax yield errorneous output (probably overlay since in vdub with Directshowsource() it works) .. only vfw works for me now ...

im using winXP and mplayer2.exe

[Nic]

Please read the sticky entitled "when posting bugs...". Saying "yields errorneous output" is never going to help get your problem solved.

Try running dbgview and tell me if any output comes out when using my filter, also do all movies produce "errorneous output"? Could you describe: "errorneous output"? (is the screen green, multi-colored scrambled stuff, black, etc)

Cheers for any info,
-Nic

[sungey]

oops sorry bout that Nic ... it was my graphic card driver which is outdated ... :( .. now it runs correctly :)

The output was scrambled and has many horizontal lines ....

[gino25]

I have the images green. Full green. Why? With nic 17/02/2003 all ok.


I' ve tried nic decoder, and ffdshow, and the decoder in koepi' s package

[ookzDVD]

@forum,

hmmm.... this thread has been spread into playback problem :(

[((( atom )))]

i really don't know what exactly went wrong in this thread, but i want to ask everybody involved to calm down a little bit, please.

when i turn my tv on, there is a war already going on wich is very unneccesary and my wish can only be that there is at least peace amongst people, that all follow their HOBBY here together.

it sometimes is of great help not to take to seriously in what way people react and it sometimes is of great help to say, that it wasn't meant this way, etc.

no more to add.

[Koepi]

I'm perfectly calm :confused: but anyways, this seems to show my point perfectly.

Let's close this thread, and focus on xvid again.

Regards
Koepi

[bond]

peace ;)

anyways there already is a new build up on uManiac´s site, perhaps someone wants to start a new thread about it?

[pandv]

Yes new Umaniac's build, and

max iframe interval works again

Testing this night.

Pandv

[NeVeRLiFt]

@Koepi

I dont have any respect for you know more. You really do give this forum a bad name... even with all you do, your personality and attitude sucks big hairy goat balls and you my friend are a smartass asshole thats needs to get off their high horse.

I will keep using Nic's and uManiac's builds since there not as buggy and seem to work better and give me better quality and less weird problems. Hell no wonder Standalone DVDunits are moving to support DivX3.11a, cause your to busy acting a fool and not making a better XviD build. Instead of adding these weird features and breaking stuff... why dont you fix whats already there bro?


Keep it real Koepi.... I used to be your biggest fan :p



Long live Nandub :sly:



/me yawns and goes back to test 1pass encodes with Nic's newest build and keeps getting blown away at the size and quality of these 1pass encodes :D


Thank you and have a nice day!

[Koepi]

Sorry neverlift, but you know the rules - as you're _again_ violating them I took the freedom to "abuse my powers" once more (strike for rule 4 violation).

If you have a personal problem with me (like birdy), then do what the rules suggest: mail doom9 and other mods.

Your accusations of me producing bad xvid builds: well, I have some fancy features activated which straight CVS builds don't use - but _you_ know these builds are unstable and alpha and there is a clear warning in the releasenotes which exactly mentions this.

They don't produce worse results than other builds, you're mumbling weird stuff there. It's an attempt to make me look bad which I won't accept. Blend in here or leave (I suggest that you directly follow the second option as you're again just trying to make trouble as you did before your last suspension and thus don't show any progress towards the first).

Focus on XviD again: uManiacs build has no real changes in core. The difference is an updated build/makefile for unix-platforms which doesn't have any impact on quality or performance.

Koepi

[ookzDVD]

@forum,

I notice that Nic's released new build dated 16-03-2003, and his DSF
is updated.

Thank you.

[Mel Maconoo]

@ Koepi


i will let you know this.. your the one makin' the build and let no one tell you off.. if they don't like it so be it.. you said "unstable build".. i will support your progress programers do have problems.. but you don't have to talk mad noise to them just say what YOU think is wrong.. Koepi keep releasing your builds i have had very few problems with them and Nic also.. I do understand they are unstable but i prefer the unstable cause of the new features.. thank you and keep up the good work.. >_<

[Didée]

Nic's build 16-03-2003: Problems

I hardly dare to disturb all that urgent personal flaming above.
Nevertheless, back to the topic VIDEO.

With Nic's current build, some technical bugs appear to me:

1. As soon as I mark an *.ogm file (with any XviD inside) in explorer, my complete shell crashes down after 2-3 seconds! (Explorer restarts). That's not very nice.

2. When enqueuing two jobs in Vdub (1st + 2nd pass), the second pass crashes immediately if Vdub's status window was opened. Without status window, second pass starts fine.

Hadn't time to elaborate this very much, but I could definetly nail it down to that certain build. Deinstalled Nic's 16032003, installed Koepi's 08032003-1, and everything was fine again. De-installed 08032003-1, installed 16032003 again - and everything crashes again :(

System is WinXP + Athlon XP.

Anyone else having similar problems?

[Koepi]

Can you try the updated decoder-only installer from my site please and tell if that decoder (nic's latest ;) ) is causing that in conjunction with my build?

Thanks,
Koepi

[Nic]

It will be the DShow filter causing it, does it happen when clicking on XviD AVI files as well or only OGM contained ones ?
As _always_ all/as much info is needed when posting bugs.

Thanks alot & ill try to do a new compile tonight to see if that helps :)

Cheers,
-Nic

[ookzDVD]

@forum,

Nic's 16-03-2003 build is working very well on my machine.

[Didée]

Sorry for providing not so awful much information. As I noted, there was not enough time for playing around.

Koepi: No, Nic's decoder from 23-02 has proven to work well with your 08-03 build. IF it is the decoder, then it is the new one from 16-03 that's causing the probs.
However, I'm not sure that the decoder is the (only) culprit. There is also the thing with VdubMod crashing on start of 2nd-pass if the status window is active - I never experienced something like that before.

Nic: nope, no problems with highlighting any AVI files, the crashing only occurs with OGM. With all OGMs lying around on my HD.

After all, it looks funny :) : imagine double-clicking an OGM file, the movie starts (and keeps) playing perfectly, and in the background Windows goes down in flames and restarts itself (okay, its only the shell) ... hihi!

[Nic]

Thanks for the info! :) Ill look into it tonight :)

Cheers,
-Nic

[jarthel]

/me is also using Nic's build :)

though it seems to suddenly crashed but when I ran first pass again, it works.

/me scratches his head

/me thinks I need a reformat :(

jayel

[Defiler]

Sorry for the long post. Please bear with me.

I wasn't going to mention this, since I presumed that I was doing something wrong.. However, recently I've been getting dramatically worse results with XviD than I am used to. I'm mentioning it in this thread because perhaps it is related to the recent XviD (developer) builds.

Previously, I had no difficulty creating XviD files that far surpassed what I could do with DivX.. In the last week or two, this hasn't been the case.
I was encoding Macross - Do You Remember Love?, trying to get the optimal one-CD output. I'm not at home, so I can't refer to my exact settings, but as you will see, I'm not sure they are vital to the discussion. My final goal was to do a two-CD version, but I sometimes like to tune the settings with lower target filesizes in order to make the differences more obvious.

First, I did two-pass XviD (tried this with Nic's 03-16 build, and with the one immediately prior.. can't recall the date right now..) using only "old-school" options. I often do this, just to check the validity of my Avisynth script, etc. Therefore, I used H.263, precision=6, no qpel, chroma motion, GMC, b-frames, or VHQ.
Using Avisynth 2.51 beta, mpeg2dec3, Decomb, Crop, and LanczosResize, and Con3D in "AnimeHQ" mode. (very simple 6-line script)
VirtualDubMod 1.4.13.1, Windows XP Pro SP1, dual Xeon 2.8/533.

(The following images are JPEG quality 95, about 70KB each)

The encode worked fine, but the quality was nasty.
http://hellninjacommando.com/temp/dyrl/type1.jpg

I was a little shocked by this, since the input looks pretty clean prior to compression:
http://hellninjacommando.com/temp/dyrl/original.jpg

Next, I went the other direction with XviD, and enabled GMC, qpel, chroma motion, and lumi-masking. Basically, all of the options that do not have interaction issues (I know not to use GMC and VHQ together, etc.)
This didn't change the output by much:
http://hellninjacommando.com/temp/dyrl/type2.jpg

Just for grins, I reinstalled DivX 5.03 Pro (I purchased DivX 5 when it came out, but I haven't used it recently, thanks to the amazing quality of XviD.), and did an "n-pass" encode with an identical target filesize, GMC, Qpel, and B-frames enabled. The XviD and DivX files differ by only around 100KB in size.
Amazingly, the quality was much better. This is the opposite of what I was expecting.
http://hellninjacommando.com/temp/dyrl/divx-1cd.jpg

Am I possibly experiencing an SSE2-related bug? I haven't had the opportunity to retest with any significantly older XviD builds, or with SSE2 disabled. The reason it didn't leap immediately to mind is that I've had good results with XviD since upgrading to the Xeons, as you can see here: (13MB)
http://hellninjacommando.com/temp/hook.ogm


Any comments? If this is the wrong thread to discuss this in, I will happily move it elsewhere.

[sungey]

NiC 16032003 prob ...

When i enable "use Xvid.dll" in ffdshow alpha and then play an Xvid clip (mplayer2.exe) .....movie plays fine but my Explorer crashed... im using Athlon Thunderbird and WinXP ...

it doesnt bother me much .. i always use NiC dshow decoder .. just giving some info .. :) .. if noone can reproduce the same result with ffdshow alpha ... i will just assume my WinXp is screwed :) .. ehehehe

[ssjkakaroto]

isnt anyone getting artifacts like the ones in the 14022003-1 build when using vhq 4, cm and bframes?? with either koepis or nics build

[sam_b]

@Defiler

I assume that you have tried lots of different playback filters and they all give a sub-optimal result? Lots of people having playback issues at the moment. Including me. What happens when you throw your old-skool encode into the divx5 decoder?

[Bulletproof]

Defiler, my personal opinion is that XviD does not do well with low contrast images, I had the same problem 2 weeks ago. The solution that I tried is to use the Lumafilter option within MPEG2DEC3 (This only does a minor improvement for me, but better than none), then I also changed the resize to Bilinear, and use only STABLE version settings, that means no Q-pel, no B-frames, no VHQ, no Luma Masking. The only thing I had enabled was Chroma motion. Then look at the encode again and it should be alot better. BTW, I think that DivX5 picture you posted has post processing on it.

[Didée]

Some more about Nic's 16-03-2003

In the meantime, I found that above described chrashes on my system are only related to xvid.dll, and have nothing to do with the dshow filter:

"Vdub-2nd-pass-crash" and "Hilighting-ogm-crash" behave as follows:

Koepi's 08-03-2003: no crashes, with every kind of dshow filter
Nic's 16-03-2003: crashes ever for me, with all dshow filters
Insta-build 20032003: no crashes at all (so far).

I tested with Nic's standalone dshow filters from 23-02 and 16-03, and with vanilla, dll-dependand CVS decoders from Koepi's 17-02-2003 and Umaniac's Insta-20-03-2003.

The pattern seems clear to me now.
However, if there are no, or very little, other reports of that behaviour, I would simply suggest:
Let it be, and invest your time more useful (go out, drink a beer ...)
It could be some interaction of {a very particular detail in my system setup} and {a very particular detail in the core of that day}.
I will check again with the next build.
Thanks for all efforts

Didée

[Defiler]

Originally posted by Bulletproof
Defiler, my personal opinion is that XviD does not do well with low contrast images, I had the same problem 2 weeks ago. The solution that I tried is to use the Lumafilter option within MPEG2DEC3 (This only does a minor improvement for me, but better than none), then I also changed the resize to Bilinear, and use only STABLE version settings, that means no Q-pel, no B-frames, no VHQ, no Luma Masking. The only thing I had enabled was Chroma motion. Then look at the encode again and it should be alot better. BTW, I think that DivX5 picture you posted has post processing on it. Yeah, I tried the "stable" settings only, MPEG2DEC3, etc.. I didn't enable any DivX 5 post-processing, so unless it does some without telling me (other than what is inherent in H.263), then it shouldn't have any. To me, it looks closer to "original.jpg" than the others.

sam_b: I haven't tried an extensive number of decoders, but I'm pretty sure this isn't a playback issue. When I get home, I'll try running it through the DivX 5 decoder, etc.

Thanks for the replies, both of you.

[kilg0r3]

@ Defiler

The settings including compression ratio or average quant would certainly help. Waiting until you get home ...

I have seen similar frames when experimentig with custom matrices. Btw is therer a 'anime matrix'?

[kastro68]

This is just my experience, but I am almost certain that the 17-2-2003 build gives better results than the 8-03-2003 build.

Cheers.

[kilg0r3]

Originally posted by kastro68
This is just my experience, but I am almost certain that the 17-2-2003 build gives better results than the 8-03-2003 build.


I'd appreciate, if someone could take the time to make a little frame-by frame comparison :)

[sysKin]

Originally posted by kastro68
This is just my experience, but I am almost certain that the 17-2-2003 build gives better results than the 8-03-2003 build.
Quick question: with bframes, or maybe the effect is there even without bframes?
New bframe decision is strictly experimental and comments like this are exactly what I want to hear. (well not necessarly bad comments ;) but if it's bad than tell me)

sysKin

[kilg0r3]

@ Syskin

I can't imagine the question which bframe decision mode is working better, being resolved without systematic tests. Any suggestions for a setup? E.g., what bframe settings would suggest for such a test, and, which compression ratio?

Tonight I encoded 'About a Boy' and it fit onto one cd with full resolution. I don't know the quant distribution, yet, since the first pass size was about 831 and the target size 695. The highest quant i spotted was an occasional 6 of a bframe. Visually, the result was very good. Yet, I used the hvs(what does hvs mean btw)-good-picture matrix. I put the settings and my script at the end of this post.

Another thing I am currently compiling a list of bugs/non-bugs/fixed bugs on my place. I would appreciate any input; also from the side of developers.

Settings for XviD (08.03.2003)

Mode: 2 Pass - 2nd pass Int. - Desired Size: 700000KB

I-frame Boost: 0%
Below I-frame Distance: 10% - I-frame Bitrate Reduction: 20%
Curve Compression: Payback proportionally - Bitrate Payback Delay: 250frames

Motion Search Precision: 6 Ultra - Quantization Type: MPEG Custom
FourCC Used: XVID - VHQ Mode: 1 - Mode Decision
Max I-frame Interval: 300 - Min I-frame Interval: 10
Lumimasking: OFF - Quarterpel: OFF - GMC: OFF - Chroma Motion: ON - Chroma Optimizer: OFF

Max B-frames: 3 - B-frames Quantizer Ratio: 126%
B-frames Quantizer Offset: 100 - Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON

Min I-frame Quantizer: 2 - Max I-frame Quantizer: 31
Min P-frame Quantizer: 2 - Max P-frame Quantizer: 31

Start Credits 0-1350, End Credits: 138620-145563
Encode credits in greyscale: OFF
Credits I-frame Quantizer: 20 - Credits P-frame Quantizer: 20


AVS Script

LoadPlugin("C:\Programme\Avs\Mpeg2Dec3.dll")
LoadPlugin("C:\Programme\Avs\Unfilter.dll")
LoadPlugin("C:\Programme\Avs\Convolution3dYV12")

#H-RES MOVIE
a = 704
#V-RES MOVIE
b = 288
#H-RES CREDITS
c = (a/4)
#H-LEFT-EXT BORDERS CREDITS
f = 16
#H-RIGHT-EXT BORDERS CREDITS
e = (a-c)
e = (e-f)

Source = Mpeg2Source("Z:\Rip\Rip2\Source.d2v", cpu2="xxxxox", moderate_h=30, moderate_v=55)

Cred1 = Trim(Source,0,1350). greyscale()
Cred1 = Crop(Cred1,8,80,704,424). BicubicResize(c,b,0,0.5). AddBorders(f,0,e,0)

Movie = Trim (Source,1351,138619)
Movie = Crop(Movie,8,80,704,424). BicubicResize(a,b,0,0.5)
Movie = Convolution3d(Movie,0,3,8,5,8,2.8,0). Unfilter(3,3)

Cred2 = Trim(Source,138620,0). greyscale()
Cred2 = Crop(Cred2,8,80,704,424). BicubicResize(c,b). AddBorders(f,0,e,0)

Return Cred1 + Movie + Cred2

[Sigmatador]

@syskin
compressibility of the 08032003 build with b-frames threshold at 100 is very similar to the 17022003 build. But dark areas are a bit better :D

[Defiler]

Originally posted by kilg0r3
The settings including compression ratio or average quant would certainly help. Waiting until you get home ...I just performed the following test:

MPEG2Source("dyrl.d2v",cpu=0,iPP=true)
Telecide(guide=1,debug=false,chroma=true)
Decimate(cycle=5,mode=2,quality=3)
Crop(32,26,656,432)
BicubicResize(640,360)
Convolution3d(preset="animeHQ")
Trim(83500,84500)

I made three output files.. two using the 03-16-2003 XviD build.
The first used none of the "extended" options, just VHQ 1 with SSE2 disabled in the Debug tab. Target filesize is 4MB, 1001 frames, 23.976fps, 41.750 seconds, 785kbps.
Next, I simply added Qpel, Lumi-masking and Chroma Motion to the prior XviD options.
Finally, I used DivX 5.03 Pro with a 785kbps target, GMC, B-frames, and Qpel enabled. All other options at default.

The first XviD file is 4106KB, the second is 4104KB, and the DivX file is 4034KB.

In this test, the difference is much more subtle. The XviD versions are slightly worse than DivX, particularly during scene transitions.. but not as bad as what I was seeing when I encoded the whole movie. To me, this suggests that the problem might lie in the decisions XviD is making as to where to allocate bits in the second pass. This is a very low-contrast, low-motion scene. Because I've trimmed it out, it's not having to compete with the ridiculous number of dogfight scenes in this movie. Heh.

[kastro68]

Originally posted by sysKin
Quick question: with bframes, or maybe the effect is there even without bframes?




It was with B-frames. I haven't tried any comparisons without B-frames. For longer movies (2hrs or more) and movies that are hard to compress, the results are very apparent. However, I left the 8-03-2003 codec at the default settings... maybe if I told it to use more b-frames (which to my understanding, can be done by increasing the b-frame threshold) the result may be different.

However, it is easier to get undersized files using the 17-2-2003 build and vhq4... which just means I have to use a larger reso or sharper resize filter.