XviD-19072002-1

[Koepi]

Ahoy,

here we are...

Changelog:

XviD-19072002-1:
- Compiled with intel compilers & optimizations
- EPSZ(^2) Motion Estimation activated
- New BFrame code from gruel with direct mode - still buggy and ugly though :-/
- Singlethreaded again due to speed issues

Find it following the XviD-link in my signature.

Regards,
Koepi

[Koepi]

This is a VERY experimental build due to CHLs code (he already mentioned that he calculates some time stamping in a wrong way), so this might be a bad build to archive something with (e.g. it keeps crashing after some 1000 frames on me when I use bframes).

Maybe in the next few hours there'll be some code cleanups, so this stuff get's more usable again ;)

Regards,
Koepi

[TactX]

Yup, for me it crashes when frameserving Avisynth -> VDub after 121 frames (its always after 121 frames) when using B-frames.

Normal Avi did pass 121 frames.

[Koepi]

Seems somewhat related to the resize settings. But those crashes using avisynth didn't occure on the same places:

1) 57XX (704x304)
2) 68XX
3) 192 (640x272)
4) 231

So it's somewhat random for my taste.

First crash kicked vdub into nirvana without any trails, the other 3 crashes produced a propper crash dump and had the error in the same place (access violation by a MMX instruction).

Regards,
Koepi

[TactX]

My avs was 640x480. B-frames set to 2/200% (No MV-hinting)

Setting B-frames to 1/200% works fine 'til now (same avs).


EDIT: 1/200% crashed @ 1873 frames (twice) !

btw, this happens encoding modes const. quant and 2pass (1st pass).

[rui]

Well, i was a little more lucky.

I encoded a clip with 2344 frames at a resolution of 576x240, using 2-pass encode, and with b-frames at 3/200%.
No problems, the resulting avi was very good, but it was a slow motion scene.

[Koepi]

I could reproduce your results with avi's (somewhat).

I did a small tv capture with postprocessing (thus vdub sending RGB data to the codec) - et voila, no crash occured.
Using the same capture without postprocessing and using "fast recompress" (sending yuv data to the codec) made vdub crash immediatly.

We're tracking down the problem with success in the xvid team, I guess I can upload a working binary sometime later today...

Regards,
Koepi

[rui]

Well, i just made a new test, using this time the trailer from the movie “The Replacements”.
I couldn’t get anything more fast motion than this.

I didn’t had any crashes again, and the resulting avi is superior to the one i had created with the prior build. Again, i used b-frames with 3/200%

So, even with all the problems you guys are having, the thing is evolving :)

[Koepi]

Ah, some of our polish friends misbehave again - I start wondering why this is more often the case as from other countries :-/ I'm getting REALLY fed up:

z-tpnetu.doskomp.lodz.pl - - [19/Jul/2002:16:12:18 +0200] "GET /~koepi/XviD-12072002-1.exe HTTP/1.1" 403 1824 "http://www.doom9.org/" "http://www.doom9.org/"

EDIT:

well, I solved it my own way, I shortly disabled referer checking and renamed useless files to the files that WANKER NERD %&$&/$/! wanted to leech.

*grmblfx*

BUT - doskomp.lodz.pl will make it into my firewall-script as generally DROPed.

Koepi

[TactX]

He obviously likes you very much :D



btw, changing to "full processing mode" did not help for me, but it does not crash that early !

[Doom9]

what are the two www.doom9.org lines for? I'm certainly not linking to your files

[Koepi]

Doom9:

that's what he entered into his GetRight or whatever download manager as referer and as web-client(!). I didn't even know that you have coded a browser that calls itself www.doom9.org without versioning and mozilla-compatibility ;)

Regards,
Koepi

[gldblade]

19.7.2002 15:00:
U xvidcore/src/encoder.c (rev.1.58) chl:
- removed debug code
U xvidcore/src/encoder.h (rev.1.15) chl:
- Bugfix for B-frame encoding (new parameters time_bp, time_pp to BVOP-ME)
U xvidcore/src/motion/motion.h (rev.1.12) chl:
- Bugfix for B-frame encoding (new parameters time_bp, time_pp to BVOP-ME)
U xvidcore/src/motion/motion_est.c (rev.1.34) chl:
- removed debug code

19.7.2002 13:40:
U xvidcore/src/bitstream/bitstream.c (rev.1.25) chl:
- Minor fix for time-hack


So, does this mean it's fixed yet?

*EDIT*
Using uManiac's build and it hasn't crashed on me yet... Currently on frame 2000.

[uManiac]

The instant build is not being built. There was an error introduced at 11:20 by albeu that does not allow XviD to be built by MSVC6. Are you using the debug build from me to get B-Frames ?

[gldblade]

>Are you using the debug build from me to get B-Frames ?

Yep.

>There was an error introduced at 11:20 by albeu that does not allow XviD to be built by MSVC6.

Drats.

*Edit*

Wait, if it didn't compile, why did the debug version have xvid.ax and xvid.dll in it?

[uManiac]

The XviD.dll and XviD.ax are from 10:00 on the 19th. XviD hasn't been built (successfully) since then by me. So the changes you wrote about from 13:40 and 15:00 are not yet in the build.

[Doom9]

@koepi: eek.. what a lamer..