XviD-19122002-1

[Koepi]

Hey folks,

since I got plenty mails requesting a newer build (why? To have more useless, buggy bitstreams?) I decided to put up a new build - without testing it for functionality (in fact, the test-run is needing some other 5 hours...)

As usual, ICL7, high optimized, ReferenceDivX' lumi masking code, Foxer's corrected 2pass.c (dealing with vdub1.4.13/delay frames), some additions I forgot, and now the real changelog:

- Fresh CVS checkout.
- More 3Dnow! Extended and XMM optimizations.
- Fixed VLC table size bug according to GomGom's proposal.
- other changes I forgot already...

Enjoy!

Regards
Koepi

[lighty]

Originally posted by Koepi
why? To have more useless, buggy bitstreams

Why not? It is always some kind of surprise waiting for us to blow in our faces. It gives some meaning to my life and make me feel alive... just to have new toy to play with. :p :p :p

[Sirber]

Yehoo! a new build!!! :D I'll test if those 3DNOW opt. give more speed.

Thanks for making this build Koepi :)

[edit]

Encoding at 18-22 FPS on a Athlon 2000+.

[NuclearFusi0n]

a tad faster :)
is there no more "dynamic hpel/qpel" box?

[wing1]

Just when you think it's safe to go into the water.....da duh da duh da duh....:D

something seems to be wrong....how come I am seeing debug infos during encoding using avs2avi? and the result constantly equals to 1/2 of what the actual time that the encoding sayz it is?

A new feature added to the codec ( yippy!!!!) finally post processing flags!!!!!

[Bulletproof]

Yikes when I try to decode a video with this build it shows a partial picture all messed up and green then crashes mplayer, and it even messes up my mouse pointer graphics in windows.

[Teegedeck]

Originally posted by Bulletproof
Yikes when I try to decode a video with this build it shows a partial picture all messed up and green then crashes mplayer, and it even messes up my mouse pointer graphics in windows.

You're only trying to scare us, huh?:p

Right?

[bond]

Originally posted by lighty
It gives some meaning to my life and make me feel alive...;)

"last night koepi saved my life..." :D

[ookzDVD]

Try to encode short Vanilla Sky's Trailer 2:50 minutes clip,
with 2-pass-int, B-frame (3/150/100), with Qpel & Chroma Motion enabled with no problem.

Playback use ffdshow 20021113 build with no problem.

[cabal]

i am always waiting for a new "koepi release" :) what are the 3dnow optimizations in detail ?? i think compiling with intel c7 automatically runs almost perfect on both cpu's ?!? ( according to germann magazin ct' )

greetings cabal

[NuclearFusi0n]

it works fairly well
when decoding with ffdshow, it works fine if i check "use xvid" it has splotchy color if "use xvid" is unchecked.
everything goes to hell if i disable ffdshow, and use the xvid ds filter, but everything works fine in virtualdub.

what does "use xvid" mean in ffdshow? (sorry, i dont want to wade through that monster ffdshow thread)

edit: I LOVE THE SPEED!!!!!!!!!!!!!!!!11 (athlon xp 2000+)

[Koepi]

@cabal:

Nice to see you posting here :)

This is quite off-topic, but who cares. Compilers _can't_ do wonders. Avery Lee has a very nice example up on his virtualdub homepage (http://www.virtualdub.org/docs_compiling) :
Isn't assembly language dead with modern compilers?

void add_pairs(float *dst, const float *src, int count) {
if (count) {
do {
float x = *src++;
float y = *src++;

*dst++ = x+y;
} while(--count);
}
}

F:\test>cl /c /O2ax /G6s fpu.cpp && dumpbin /disasm fpu.obj
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

fpu.cpp
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


Dump of file fpu.obj

File Type: COFF OBJECT

?add_pairs@@YAXPAMPBMH@Z (void __cdecl add_pairs(float *,float const *,int)):
00000000: 8B 54 24 0C mov edx,dword ptr [esp+0Ch]
00000004: 85 D2 test edx,edx
00000006: 74 1F je 00000027
00000008: 8B 44 24 08 mov eax,dword ptr [esp+8]
0000000C: 8B 4C 24 04 mov ecx,dword ptr [esp+4]
00000010: D9 00 fld dword ptr [eax]
00000012: 83 C0 04 add eax,4
00000015: D9 00 fld dword ptr [eax]
00000017: 83 C0 04 add eax,4
0000001A: D8 C1 fadd st,st(1)
0000001C: 83 C1 04 add ecx,4
0000001F: 4A dec edx
00000020: D9 59 FC fstp dword ptr [ecx-4]
00000023: DD D8 fstp st(0)
00000025: 75 E9 jne 00000010
00000027: C3 ret
00000028: 90 nop
00000029: 90 nop
0000002A: 90 nop
0000002B: 90 nop
0000002C: 90 nop
0000002D: 90 nop
0000002E: 90 nop
0000002F: 90 nop


What was that again?

As you can see, handmade optimizations aren't beatable by a machine.

ICL can't produce 3dnow/3dnow extended code.

We now have a mem_transfer function in 3dnow extended. I didn't look into the code, but I believe it's faster than the pure mmx'ed function. in several other places some functions which were only mmx'ed (so: no xmm or sse/2) have now a 3dne counterpart, which should increase performance on athlons/durons a bit.

(Yet the most time critical function still has no 3dne version, according to syskin interpolate16x16 is mostly used...).

I hope this helps you understanding things a bit better.

Best regards
Koepi

[cabal]

yes , thx for the info :)


greetings cabal

[shirka]

I tried to encode a short passage of Star wars episode 2, but crash with 2nd pass. I attached some info files.
My system : Athlon XP 1800+, 256 DDR Ram, Windows XP Pro, Virtualdub 1.4.13

[Sirber]

@shirka

Look into the forum, there is 2 thread (is there a "h"?) about crash with VDub. No soluce yet. I'm using DVD2AVI by OGO and work #1. I use AutoDub for to get the right ratio (autodub crash on my computer also).

[MaTTeR]

Still getting the crashes here on 1st and 2nd passes too.

[JasonFly]

Is it good to use insta build in a more conventional way without usiong b-frame nor qpel?

I mean i m not interested in bframes yet but i see these optimizations for athlon and I'm wondering if the latest build are better than 04/10/2002 in this sector.

Thanks you for your work Koepi

[HarryM]

DS filter in last binaries is TOTALLY broken. And I dont know why...:mad:
Build 19122002 is most problematic!

Q-pel ON, B-frames = 3, chroma ME = ON, frame size 544x224 pixels

http://sgfan.ic.cz/download/544x224.jpg

Q-pel ON, B-frames = 3, chroma ME = ON, frame size 576x320 pixels

http://sgfan.ic.cz/download/576x320.jpg



I use Win98SE and ZoomPlayer 2.90 for playing.

When I playing AVI file (generally I use OGM, AVI I use for movies with AC3 audio), I see this "BROKEN B-FRAME, MISING REF FRAME". Ffdshow (without 'use xvid.dll' feature'!) playing this AVI correct. Above OGM's too.

[Bulletproof]

Originally posted by Teegedeck
You're only trying to scare us, huh?:p

Right?

Nope, i'm serious, it crashes my mplayer and really shows messed up video.

[cult]

found a "bug" (I think)-when trying to compress credits with more than 25/25 quant,you get a crash.Otherwise it works ok.SAme happens with insta build 20/12/02
using celeron@1ghz,w2k

[HarryM]

The newest build is really faster :), but the 'DS filter problem' hinder in regular use of XviD (only for my? You don't have problem with native DS filter?) :(

IMHO:
It is only my impression or q-pel feature is from build to build much and much bluring???

[fraatz]

hi!
i don't have a problem with the build in any way. dsahow is working flawlessly,too.
my only impression on qpel is that using them with bframes yields to some flickering macroblocks (luminance changes rapidly) on unicolor objects. but it produces a *very* sharp pcture here with hvsgood matrix and bilinear resize!! would be nice if someone could confirm the bug ;)
-f

[wing1]

Quality, playback and speed wise, the new build has no problem at my end. The only problem I am seeing so far is using the codec with avs2avi CL compressor. I am seeing debug information scrolling inside the dos window along with the normal program output; Furthermore, avs2avi reported 2x the encoding frame numbers that it had actually compressed...

[Sgt_Strider]

well I know I'll probably get flame for this but this build isn't mpeg4 iso compliant right? I encoded star wars episode 2 with b-frames, q-pel, and chroma. When I attempt to use MP4UI to mux the video and music file, it said not mpeg4 compatible...

[Sirber]

@Sgt_Strider

Why don't you use OggMux? It's always compatible :)

[celeron]

@HarryM
Yap you are rigth there is a DS filter problem, but only whit movies encoded whit old versions of xvid.
But the DS filter in decoding the sample made by this version works very good.

@Keopi
Great speed increse, 17/19 fps in a duron morgan 1.2ghz.:D

Ps: sorry bad english

[Gaia]

Originally posted by Bulletproof
Nope, i'm serious, it crashes my mplayer and really shows messed up video.

You are right, this happens to mee too. Video is totally messed up and it messes up the mouse pointer too. There's something wrong with this build. Decoder works fine with old movies too. I am using Duron 950.

[Koepi]

Originally posted by Sgt_Strider
well I know I'll probably get flame for this but this build isn't mpeg4 iso compliant right? I encoded star wars episode 2 with b-frames, q-pel, and chroma. When I attempt to use MP4UI to mux the video and music file, it said not mpeg4 compatible...

It should be standards compliant - dunno what went wrong on your side. Maybe you used one of the non-standard features like modulated quantization? If you use bframes, make sure to have "dx50 bvop compat." checked, don't use packed bitstream.

Else switch to stable tree, those features definatly comply with mpeg4 standards.

Koepi

[JimiK]

@fraatz
I can confirm this problem (at least I think it's the same you're referring to). In my opinion it has nothing to do with QPel, but with Bframes (what is sad, because I like Bframes much better). On unicolor planes it looks like there are small things, rushing over the plane, right? I viewed it in VDub and like you said, it's macroblocks that get lighter and darker. The problem is drastically reduced when you prefilter your picture with Conv3d. I also noticed an increase of this problem with the newer builds. Oldest build I tested was Koepi-1411.
Now I have another question about Bframes and Bf-offset. The Bf-quant is calculated with the average quant from previous and next P-quant. Is this a "maximum" quant or should this quant always be used. In debugview on 2nd-pass I had the following output: 3 Bframes max, Ratio 150%, P2-B3-B2-B3-P2. That's strange enough because I think there should not be a Bframe with quant 2. Now when I raise the offset to 400, nothing changes. Nobody else wrote about this, so I think it's correct. All I want to know, why is this so?
Best regards,
JimiK

[Sgt_Strider]

Originally posted by Koepi
It should be standards compliant - dunno what went wrong on your side. Maybe you used one of the non-standard features like modulated quantization? If you use bframes, make sure to have "dx50 bvop compat." checked, don't use packed bitstream.

Else switch to stable tree, those features definatly comply with mpeg4 standards.

Koepi

For quantization type, I use mpeg on the first and 2nd pass. Can you tell me which feature is possibly not mp4 compliant? That will really help me find out what's my problem.

[HarryM]

I am mad from last xvid builds. :mad:

Do exist any users, using win98SE and with FULLY FUNCTIONAL DS filter (xvid.ax)?

I test 19122002 build at another PC's (PC's of my friends) with win98SE and xvid.ax is NOWHERE O.K.

[Trahald]

(why? To have more useless, buggy bitstreams?)

hey.. you guys know your taking chances.. hehe... the stable release from april is still available for the faint of heart ;)

i havent used xvids dshow in ages.. ive been happy with ffdshows output with the streams i get with the unstable builds

[fraatz]

@HarryM: "I am mad from last xvid builds. " Then use the STABLE TREE!!
@JimiK : Yes. That's exactly what I mean. Anyone of the developers know about the problem? I saw a post of Syskin who said it's a decoding problem, but it's definately not! I can mail anyone interested a 760 kb clip which shows the problem quite well..

[sysKin]

Originally posted by JimiK
[B]Now I have another question about Bframes and Bf-offset. The Bf-quant is calculated with the average quant from previous and next P-quant. Is this a "maximum" quant or should this quant always be used. In debugview on 2nd-pass I had the following output: 3 Bframes max, Ratio 150%, P2-B3-B2-B3-P2. That's strange enough because I think there should not be a Bframe with quant 2. Now when I raise the offset to 400, nothing changes. Nobody else wrote about this, so I think it's correct. All I want to know, why is this so?
Codec actually asks the core for a specified quant, and prints this quant to debug view - but it doesn't matter. This quant value will be ignored for b-frames.
It would be nice if xvid.dll didn't print this value at all. It should also be ignored in the statistics...
Yes. That's exactly what I mean. Anyone of the developers know about the problem? I saw a post of Syskin who said it's a decoding problem, but it's definately not! I can mail anyone interested a 760 kb clip which shows the problem quite well..That's true, it's not a decoding problem. It might be an mpeg-4 artifact simply caused by compression (related to high quantizer and the way b-frames are compressed), but I think this is a bug.
I don't know what causes it...

Radek

[Didée]

The problem of "flickering blocks" was already a topic some weeks ago, in this pretty long thread (http://forum.doom9.org/showthread.php?s=&threadid=38074) - somewhat later in the thread, from page 6 on, or so.
The problem was described and confirmed, but alas, nobody has come up with a solution yet.
To note it once again: at least on my side, this problem only occured since the core was able to perform qpel together with b-frames (but it's not caused by the use of qpel).
By that time, some little bug seems to have introduced. The former builds, that could not use qpel along with b-frames, didn't have this problem.
So is "bleeding-edge-technology" ;)

... and you should appreciate the work of the XviD developpers each and every time you use XviD.
It is awesome work.

[edit]
Oops - hi Syskin. Seems I was typing very slowly ...

[HarryM]

@fraantz:
This problem of xvid.ax, not encoder (xvid.dll).
Encoder is O.K.
When I use vdubmod (e.g.) for editing and triming of video, all is great O.K. No problem.
But problem is, if I use newest builds for DECODING (via xvid.ax). Not only for my newest encoded videos (encoded by unstable builds), but this is problematic for my any months(!) old regular xvid movies (full DivX4 compatible) too.

In last weeks is in xvid.ax something, what make impossible decoding of XviD into OVERLAY correct.
When I forbid 'YUV transformation' in 'Video Renderer', video is O.K. But this is'nt solution!

Any errors in color conversion at xvid.ax possible?

[BoNz1]

Ok, I have searched the forums a lot about this but I can't get xvid to run as fast as I would like. Now I am not complaining or anything but I have noticed that other people have posted that they can get like 15-17fps, I can only get maybe 8-9fps on a p4 1.6ghz w/ 512MB DDR. I used dvd2avi 1.76 to make a .dv2 file. Then I used avisynth2.5 to save it as a avs script using a lanczos resize to 640 by 256. I used the mpeg2dec3 as well as vdubmod set to fast recompress. The xvid settings I used were as follows motion search precision 6, quantization mpeg, 4c XVID, Max I frame 300, Min I frame 1, lumi masking on, chroma motion on, 1/4 pixel on, B-frames 3 150 100, DX50 B-VOP Compatibility on, Min I quantizer 2, Max I quantizer 31, Min P quantizer 2, Max P quantizer 31, I-frame boost % 20, Below I-frame distance 10, I-frame reduction % 30, High 0, Low 0, use alt cc off, bitrate playback delay 250, Payback with bias on. Now I realize that the settings that I used are going to make it quite slow but surely there must be another way that I can make it go a bit more faster, I am encoding LOTR it is going to take me 8hrs to do each pass. If anybody has any suggestions on how to speed this process up a little more I would be very grateful, thanks.:) Oh and BTW I am using the latest build Koepi's 19122002-1.

[HarryM]

Yes.
I have right. Bug in xvid.ax.

Problem is exactly between 'xvid.ax' and 'video renderer' in Win98SE.

I keep in memory, that BSplayer use your (own) video renderer - bsrendv.dll.
I test BSplayer for playing and... all is O.K.!

I laborate next. In ZoomPlayer I enable 'Force overlay mixer'. Now I have

'xvid.ax' > 'overlay mixer' > 'video renderer'.

Any videos is O.K. now, but not all :( Videos with height mod32 are defected at playing (green-screen, see my older post and linked jpgs!!! ). Videos with height mod16 are O.K.
Interest, generally is mod32 more compatible than mod16, but mod32 is defected, mod16 is O.K...:rolleyes:

I laborate next. I forced DirectVobSub, I set it 'Load always' feature enable...

'xvid.ax' > 'dvobsub.ax' > 'overlay mixer' > 'video renderer'

All videos are O.K. at playing now!!!


I think, that this bug is any stupidity in xvid.ax
Can anyone correct this bug, please???
Windows XP use another 'video renderer' as Windows 98(SE). I don't test on WinXP (maybe without problems), I use Win98SE only. Many peoples use Windows98SE for now (20-30%?).

[cjv]

@HarryM:

Relax, man I don't understand why you are so mad that xvid.ax does not work. Yes, there may be a bug and I'm sure this "stupidity" :confused: will eventually fixed. This is a developer build...and I doubt getting the decoder fixed is the highest priority right now, seeing as most people use ffdshow anyways.

You say that the problem is only with Win98 and xvid.ax. Upgrade to Win2k/XP/Linux or try using ffdshow and see if the problem persists.

cjv

[MoonWalker]

Originally posted by sysKin
It would be nice if xvid.dll didn't print this value at all. It should also be ignored in the statistics...

You mean we shouldn't take the quant's of b-frames for statistics(eg avg quant)??.. Is there any other way to calculate the "true" quant of the b-frame?

Thanks,
MoonWalker

[HarryM]

I study 2-pass (and debugview list) at b-frames. P-frames are always smaller than at quant=2 (it is normal, right), but B-frames are generally bigger than at quant=2...

E.g.:

...
1478 P-frame stats1=11547 actual=8745
1479 B-frame stats1=1478 actual=1508 (actual b-frame is bigger than stats1?)
1480 B-frame stats1=1254 actual=1358 (actual b-frame is bigger than stats1?)
1481 P-frame stats1=8794 actual=5478
...

It is normal???

[CruNcher]

@ all
ok the newest xvid.ax is badly damaged everybody knows that know and ffdshow has also problems with anamorphic content so the best is you all use XviD-03122002-1.exe "xvid.ax" it is stable and everything is fine for me :) it will be fixed im sure but it takes time

[NuclearFusi0n]

I'm still suffering from the problem shown here (http://forum.doom9.org/showthread.php?s=&threadid=40714).

Settings for XviD ()
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 1064099KB
I-frame Boost: 0%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 20%
Curve Compression: Payback with Bias, Bitrate Payback Delay: 250frames
High Bitrate Scenes: 0%, Low Bitrate Scenes: 0%
Hinted Motion Estimation: OFF
Alternative Curve System: OFF,
Motion Search Precision: 6 - Ultra
Quantization Type: MPEG
FourCC Used: XVID
Max I-frame Interval: 300, Min I-frame Interval: 1
Lumimasking: OFF
Interlacing: OFF
Greyscale: OFF
Quarterpel: ON
Global Motion Compensation: OFF
Chroma Motion: ON
Max B-frames: 2
B-frames Quantizer Ratio: 150%
B-frames Quantizer Offset: 100
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON
Print debug info on each frame: OFF
Min I-frame Quantizer: 2, Max I-frame Quantizer: 31
Min P-frame Quantizer: 2, Max P-frame Quantizer: 31
Max Bitrate: 10000kbps, Max Overflow Improvement: %, Max Overflow Degradation: %
Start Credits: OFF, End Credits: OFF,

Desired Size: 1064099KB
1st pass: 791,116 KB
2nd pass: 790,382 KB

I also have decoding problems. The video looks OK when loaded in VirtualDubMod, but when i try to decode with ffdshow + "Use XviD", i cant decode it. THe program i'm using just goes *poof* and closes. Zoom Player, Windows Media Player 6.4, they both just close themselves. When i uncheck "Use XviD" the programs will open and start playing, but everything looks pretty bad (the video looks quite a bit cleaner in virtualdub) when i disable ffdshow, everything goes to hell.

The video looks pretty good with QPEL only, no bframes, and it matches my desired size to a few KB.

edit: i'll be glad to cut a clip out and upload it to anybody that needs to reproduce the issue.

[cjv]

If you look at your first pass vs. second pass size, you will see that they are almost the same. This means you are maxing out the bitrate when you use b-frames. You say that it comes out to the right size when you don't use b-frames. Thus, there is nothing wrong with XviD. You could try a larger resolution, but I would personally just burn the encode withouth b-frames and be done with it.

cjv

[NuclearFusi0n]

Originally posted by cjv
If you look at your first pass vs. second pass size, you will see that they are almost the same. This means you are maxing out the bitrate when you use b-frames. You say that it comes out to the right size when you don't use b-frames. Thus, there is nothing wrong with XviD. You could try a larger resolution, but I would personally just burn the encode withouth b-frames and be done with it.

cjv
The quality leaves quite a bit to be desired though. :(

[Trahald]

finished first pass with new build.. b-frames and chroma motion only.. looks great.. pass 2 tonite

[HarryM]

Originally posted by NuclearFusi0n
I'm still suffering from the problem shown here (http://forum.doom9.org/showthread.php?s=&threadid=40714).

I also have decoding problems. The video looks OK when loaded in VirtualDubMod, but when i try to decode with ffdshow + "Use XviD", i cant decode it. THe program i'm using just goes *poof* and closes. Zoom Player, Windows Media Player 6.4, they both just close themselves. When i uncheck "Use XviD" the programs will open and start playing, but everything looks pretty bad (the video looks quite a bit cleaner in virtualdub) when i disable ffdshow, everything goes to hell.

The video looks pretty good with QPEL only, no bframes, and it matches my desired size to a few KB.

edit: i'll be glad to cut a clip out and upload it to anybody that needs to reproduce the issue.

I have same experiences too (build 19122002). Exactly. I can't use ffdshow + 'use Xvid.dll for decoding' feature. Windows totally freezes :(
Actually usable for me is only pure ffdshow. But quality of q-pelled videos with pure ffdshow isn't 100% :(

[Koepi]

Stop whining!

We're tracking down the playback issues, I hope this afternoon (after I return from work) I can compile something new.

And now _finally_ get the point - 2nd pass can't be bigger than 1st pass, it's not meant to be that way. If you saturate the codec, use different settings. E.g. set bframes to: 3 / 100 / 100 instead of the default values.

Or set bframes to -1.

That'll all increase quality - and if the quality still doesn't satisfy you, use the stable build which is called that way because it isn't "code in progress", which tends to be buggy. Reminds me that I wrote that initially, that I note that on my site (UNSTABLE),...

You know what you get, why do you always forget about that?

Regards
Koepi

[Teegedeck]

Well, I don't know what's all the compainin' about, either.

Of course we should use the unstable build for experimenting only - but when I compare the results I get with all the unstable features - I just couldn't get near that with the stable build at the low bitrates I'm currently using. Looks great.

Just remember that this thing doesn't come with a warranty and enjoy what already has been accomplished at this point.

[gino25]

Still Hinted me doesn' t work in this version. Do you know when (and if) it will be reactived with no bugs?