XviD 1.0.0 build by Jawor (01.06.2004)

[Jawor]

Get it here.

If you say "A", you should say "B", so here it is - a bugfix release compiled from CVS (1.06.2004). It contains fixes for the following bugs (quoted form sysKin's signature):

- (core) UGLY TRELLIS BUG which probably reduces sharpness of the image, but possibly even produces artifacts
- (core) motion estimation buglet slightly reduces b-frame's quality
- (VfW) video is not playable via ICM (mplay32.exe, files embedded in Office applications etc)
- (VfW) calculator does not open many useful audio/subs extensions by default
- (VfW) calculator calculates audio size wrong when given bitrate and length (2.4% error)
- (core) 1 fps files fail to decode

How to install:
After unzipping, right-click the file xvid.inf and choose Install.... Voila!

Disclaimer:
Please consider this build an experiment. If installing or using these binaries will cause any damage, don't blame me! Use it at your own risk.
These binaries were compiled with mingw32-gcc, they should be as fast/slow as the 13.05.2004 release.
This package does not contain a DirectShow decoder.

[dapipa]

ook,will check it out as soon as i get home
p.s.i'm getting worried about that buggy trellis quantization - is it fixed once & for all?all my encodes are made with RC4 & trellis turned on - should i re-encode them with one of these new builds(yours/celtic_druids)?to tell the truth - i didn't watch most of them - 99% of them are just 'back-ups' of my DVB captures(i still have about a half of the source mpeg2 streams),so - dumb question - is there a possibility that the encodes might contain some trellis artefacts?i suppose the answer is yes,but - is there a way to find out,whether there are some artefacts or not,without watching ALL THAT STUFF over,or would it be simplier to re-encode?

[pernas]

Great !

I'm testing it right now. My only concern (not big) regarding
all new flavours of 1.0.0 releases is how to keep track of them

[Jawor]

Originally posted by dapipa
p.s.i'm getting worried about that buggy trellis quantization - is it fixed once & for all?all my encodes are made with RC4 & trellis turned on - should i re-encode them with one of these new builds(yours/celtic_druids)?to tell the truth - i didn't watch most of them - 99% of them are just 'back-ups' of my DVB captures(i still have about a half of the source mpeg2 streams),so - dumb question - is there a possibility that the encodes might contain some trellis artefacts?i suppose the answer is yes,but - is there a way to find out,whether there are some artefacts or not,without watching ALL THAT STUFF over,or would it be simplier to re-encode?

I used Trellis with all Release Candidates and I couldn't see any artifacts. I suppose the only way to check if there are any is to watch all of these clips.

Of course you can re-encode them, but there's always a chance that the developers invented new bugs while fixing the old ones

IMO re-encoding them is not worth the time.

[Koepi]

That trellis bug isn't that huge, it works "non-optimal" for 1.0-final. With that fix applied, it works better.

Regards
Koepi

[Teegedeck]

When I posted two snapshots, old-trellis vs. post-fix-trellis, the immediate reaction I got was "I don't see any difference" - so it obviously isn't necessary to encode anything again. After the bugfix the picture produced by trellis has definitely become sharper but I don't know how many people have the eyes and equipment to let them notice it.

[Jawor]

Originally posted by Teegedeck
After the bugfix the picture produced by trellis has definitely become sharper but I don't know how many people have the eyes and equipment to let them notice it.

I suppose nobody.

My encodes created with 1.0 Betas & RCs look OK, although these releases had many more bugs

[Koepi]

Jawor,

I just noticed you make up new codenames for xvid. That's bad. Could you please stick to the "official" codenames if you use any? You're possibly creating confusion with that, and xvid doesn't deserve that.

Regards
Koepi

[virus]

Koepi is right.

Jawor, may I suggest the use of the sourcecode date instead of a codename? If you're providing a patched xvidcore version, then strictly speaking it's no more xvidcore-1.0.0 (the original, dated May 9). At least the date may differentiate them clearly.

virus

[Asmodeus]

I agree. Build + date is good idea. As for codename, you can use next time some strange name, for fun, like ...."szczebrzeszyn" Joke

[Jawor]

If you really think I created some confusion, I'll give up codenames