XviD-1.0.1-05062004 Bugfix Release

[Koepi]

Aloha everyone,

we're proud to announce the first bugfix release for XviD 1.0-series.

Changelog:

XviD-1.0.1-05062004:
- (core) small trellis bug which probably reduced sharpness of the image,
but possibly even produced artifacts
- (core) motion estimation buglet slightly reduced b-frame's quality
- (core) 1 fps files failed to decode
- (core) intra coefficients were sometimes not clipped correctly, which might
(in theory) produce artifacts (don't worry, noone has seen the artifacts yet)
- (core) if two p-frames were more than one second apart, b-frames in between are not decoded
- (VfW) video was not playable via ICM (mplay32.exe, files embedded in Office
applications etc)
- (VfW) calculator did not open many useful audio/subs extensions by default
- (VfW) calculator calculated audio size wrong when given bitrate and length (2.4% error)

Fetch it at my site. Sorry for the 5 hours delay between the official announcement and releasing the binary, but I was already sleeping at 1:45h when the official announcement was made, so you had to wait until I get up and copy the prepared site over ;)

Btw., please update your links and bookmarks to point to my site via
http://www.koepi.org/ (http://www.koepi.org) which Haseeb was so kind to register and point to my site.

Regards
Koepi

[hyper84]

Thanks Koepi!:D

[timeismoney]

Thanks Koepi & all developers

though only minor bug fix, but to preciseness

[malkion]

Appreciate the bugfix.

I'll find out in a jiffy if the Brightness lever works.

[celtic_druid]

If you (or anyone else) wants a build with a working brightness control then they need a cvs head build.

[Pen-Pen]

gureto ! ;)

[Mc|Atm0s]

La Sicilia ringrazia Koepi! :D

[iago]

danke schön mi amigo! ;)

[Koepi]

Sende sagol iago :-)

Nice to see you again - any feedback for 1.0/1.0.1 yet? :)

Regards
Koepi

[Prettz]

Outstanding.

[bond]

its disgusting!

[RadicalEd]

Originally posted by bond
its disgusting!

..ly seductive http://www.animemusicvideos.org/phpBB/images/smiles/icon_eek.gif

[V-tec]

Hi all!

also with this build I have always the same problem: vdubmod crashes... I don't know why and don't understand why...

this is the VdubMOD report:crashinfo.txt (http://digilander.libero.it/ctectr/crashinfo.txt)

with the Jawor's build or a buid compiled (05/06/04 CVS) by me there are no problems...

I Have Athlon XP 2700+ No OC
Win XP Pro Sp1

[Koepi]

Uninstall any older builds (especially if you used different installers than mine) before installing this one.

It seems your windows xp locks the xvidcore.dll, xvidvfw.dll and / or the xvid.ax so you get this behaviour.

As you're able to compile xvid yourself you should know that :confused:

Koepi

[SeeMoreDigital]

Originally posted by Koepi
...any feedback for 1.0/1.0.1 yet? :)

Regards
Koepi Beautiful

[V-tec]

@Koepi,

I have uninstalled the previous version of XviD, and restarted my PC but the problem is not gone...
VdubMod crashes not always in the same point, but crashes independently by the source.

I'm sorry for my English.

[Koepi]

v-tec:

I know too little about your setup so I don't know what's wrong. It's no general xvid error as you're the only one to experience this.

My guess is that your own build (and Jawor's) aren't optimized with ICL so they're not as demanding to your hardware as my build.

If you search for that a little (at least 2 threads about that on the first 3 pages of this forum) you'll see that "perfectly stable" systems can behave weird when using xvid - better cooling, less aggressive memory timings,... all that can help there.

Koepi

[Blueseb]

is it safe to reuse a 1st pass stats file form 1.0 to do a 2nd pass with the new build? (it would save ~5h computing time to me)

cheers

[Herculezz]

This is Excellent. With the final release I had many troubles when trying to convert from xvid format to another format like dvd. It gave me exceptions. This release has fixed all that. Koepi what do you think caused that?

[guada]

thank you koepi,

A small question, it is always based on the devapi-4 or devapi-3?

[Prettz]

Originally posted by Blueseb
is it safe to reuse a 1st pass stats file form 1.0 to do a 2nd pass with the new build? (it would save ~5h computing time to me)

cheers
I would guess the answer is absolutely not if you want decent quality, as the bugfixes center around quantization bugs that would affect the input image. The two passes would each be dealing with two different-looking images.

[Manao]

guada : dev-api-4 : the dev-api-3 is now a thing of the past.

blueseb : yes, it's totally safe.

prettz : statistics kept between the two passes are only frame's sizes, so it's safe for such a small bugfix to keep the statfile.

[Prettz]

Originally posted by Manao

prettz : statistics kept between the two passes are only frame's sizes, so it's safe for such a small bugfix to keep the statfile.
I always take a paranoid view towards things like this, and I can't stand the idea of taking chances with quality. But now that you mention it, you're probably completely right. Even with a differing frame size of several hundred bytes I doubt it could have any noticeable effect on bitrate distribution (I really have to work on thinking things through before making a post).

However, the stats file also includes the frame type and quantizer (which I guess is always 2 for I/P and 3 for B) in addition to the frame size. In my mind syskin's i/p/b decision code is a delicate miracle worker that must be left utterly undisturbed at all costs :)

[Sharro]

First, the little dot in the Atlantic thanks God for the luck of existing in the world all the people in Xvid development. World would be a worst place without you :-)

Now, the serious stuff, I've seen people compiling builds with some sort of logging capability and ... damn... this is very usefull, so here is my dream:

Option to Automatically Export settings to a txt file in the beggining of an encode.

Logging capabilities (either first or second pass named by date and hour and pass1 or pass2 in the end of name). This could be done in two ways (options)... a full log (frame by frame) or just a statistic txt (with the information present in xvid status window at end of encode).

It would avoid extra tools for simple tasks.

END OF DREAM.

All else... damn... IT LOOKS SO GREAT....

All the best

Sharro
Aka Xvid Tribalistic Fan

[Soulhunter]

Originally posted by Sharro
I've seen people compiling builds with some sort of logging capability and... Yeah, something like the virus hack (http://forum.doom9.org/showthread.php?s=&threadid=76557) would be a very nice feature... :)

Last but not least, a k*k tahnks for this build !!!


Bye

[guada]

Hello Manao, :)

I appreciate your commmentaries a lot especially when it is a matter for the technical domain. ;)
For what concerns the codec Xvid devapi-3 or 4, I think that it is not necessarily of the past since it stays the basis of work of the future optimizations of the codec Xvid v1.0 and Xvid v1.01.
The only problem that encourages me to keep the Devapi-3, it is the picture that it delivers in the very ultra low bitrate(8kbps).
It reminds me among other things, the touching side of CCE 2.70 pro: gifted of a big natural, honest picture and a precision of good invoice. Of course, it is not the same register but for me it is all as.
Will you tell me why exploit the ultra low bitrate?
It is very clear, to bring the codec to its last stoppings making the optimum regulating stand out that will be used for the high bitrate. (I consider that a codec that proves to be efficient in the streaming permits to see a picture of big beauty to high bitrate).
It is my point of view, obviously that' s debatable...

[Sharro@Home]

Originally posted by Soulhunter
Yeah, something like the virus hack would be a very nice feature... :)
...
Bye

Undoubtedly a good implementation, still I (and guess many other people) would prefer to have it all in the "same" place :p
Oh ... Koepi congrats for your new "home" ! ;) (Just when I managed to memorize his old one)...

All the best


Sharro

[Soulhunter]

Ehm, sorry for disturbing... :rolleyes:

But, unfortunately Ive to 2nd V-tec's statement !!!


With the v.1 final build, everything worked perfectly...

But with this new build VDub disapears without any error message after some minutes... :confused:


Tested with...


- CPU: Athlon 2600XP (Barton)

- MoBo: ASRock K7S8XE

- RAM: 1024MB Mushkin DDR400

- OS: WinXP Home + SP1 & DX9b


EDIT: Problem solved...


Bye

[Koepi]

Those are usually RAM roubles if an application vanishes into nothing.

Try less aggressive memory timings and run an extensive memchk86...

Regards
Koepi

[Soulhunter]

Hmm, Ive already done a 2 hour test with MemTest !!!

No errors, and this was @ CL2...

But to be sure Ive also tested @ CL3, still the same problem !!!


Your v.1.0 build (09052004) does not cause problems like this... :confused:


To be absolutely sure, I will do a even longer test !!!


EDIT: Problem solved...


Bye

[Soulhunter]

Ok, Ive done another stability test... ;)

I ran MemTest for over 600 cycles here !!!

http://img8.imageshack.us/img8/7365/Memtest.png

No errors...

But to be absolutely sure, I started also a XviD (v.1.0) encode while this !!!

http://img8.imageshack.us/img8/9457/MemtestVDub.png

Even a simple action like opening the start menu needed 10 seconds at this point... :eek:

But again, no errors !!!


So, I assume its not my HW that causes this problems with your new build... :rolleyes:

Maybe something is wrong with my OS ???


EDIT: Problem solved...


Bye

[Soulhunter]

Originally posted by V-tec
With the Jawor's build or a buid compiled (05/06/04 CVS) by me there are no problems...
So I decided to test Jawors 05-06-04 build as well... :rolleyes:

Odd, his (XP optimized) build runs without any problem !!!


EDIT: Problem solved...


Bye

[Rash]

I know that question may sound strange, but now XviD produces a 100% MPEG4 compliant stream right? As long as I stick with the profile levels, I can play the stream on any player/program MPEG4 compliant that support that level, including stand-alone "TV-players". Right? :)

[Soulhunter]

AFAIK, it does still not limit the bitrate... ;)


Bye

[RadicalEd]

Yeah, there is no level conformance currently. Gruel is working on VBV for 1.1 as we speak, and after that it's just a matter of implementing the other constraints (VCV & VMV) before perfect compliance.

[virus]

the final (hopefully... it needs testing anyway) code for VBV compliance has been committed to CVS HEAD two days ago. Check this message by gruel (http://edu.bnhof.de/pipermail/xvid-devel/2004-June/004310.html) on the developers' maillist.

[Soulhunter]

Ok, my problem seems to be solved !!!

Read here (http://forum.doom9.org/showthread.php?s=&postid=510121)... ;)


Bye

[lordadmira]

That thread doesn't seem to state any kind of conclusion. Have u come to any conclusive conclusion about the problem? The only time I've had programs "vanish" is when virtual memory was exhausted. Try spying on ur system and Vdub with TaskInfo.

[BloodyRipper]

man, you're REALLY dedicated to whole this job!!

[cheerow]

Hello, folks!

Recently I stepped through a XviD clip with ffdshow's quantizer visualization and frame type display enabled and noticed that only on I & P frames the quantizer was adaptive while on all b-frames the quantizer was constant throughout the entire frame.

Is this normal? Wouldn't it be better if b-frames were adaptive too? Sorry, if this has been discussed before!

settings for this encode were:
b-frames(max 8, sensitivity 20), adapt quant, gmc, chroma motion, trellis, turbo, matrix: HVS-best



BTW: (not really related to the above) I also noticed that ffdshow's postprocessor can cause flickering in some videos, especially the mplayer algo, nic's is better but still some flickering.

[CruNcher]

cherrow yes their is no adaptive quantization for b-frames yet and this is a problem, people shouldn't use any b-frame settings that higher the p-frame quantization but the b-frame stays lower this will couse flicker and this happens easily if you use adaptive quantization with some comon quality b-frame settings like x/100/100 for example will result in this flicker problems with adaptive quantization active.

[Fox Mulder]

CruNcher, do you mean that settings for B-VOPs other than the defaults of 2/1.50/1.00 will cause flicker if Adaptive Quantization is on?

[lordadmira]

I think what he was trying to say is that if u have quantizer offsets set for B frames, the video will flicker the more B frames there are. This is because of the jump in compression between P and B frame sequences. The use of AQ can exacerbate this under non-standard settings. Although it's hard to imagine a scenario where AQ will lead to flickering since it doesn't dramatically alter the average quant of a frame.

LA

[lordadmira]

I tried to use the Stats Reader 2.1 to read a stats file from 1.0.1 and it crashed when I tried to open the stats file.

STATSREADER caused an invalid page fault in
module STATSREADER.EXE at 018f:004018f2.
Registers:
EAX=fffffe44 CS=018f EIP=004018f2 EFLGS=00010207
EBX=0063f300 SS=0197 ESP=0063f270 EBP=fffffe44
ECX=0063f824 DS=0197 ESI=0063fbd8 FS=67af
EDX=0064f078 ES=0197 EDI=ffff8a10 GS=0000
Bytes at CS:EIP:
f7 42 2c 00 00 00 80 0f 85 f9 02 00 00 f7 42 10
Stack dump:
5f49fd0c 0000283a 0000283a 00000000 00000d78
5f4a703c 00002e06 5f4a703c 00005d96 5f4a703c
000023de 5f4a703c 000028ce 00000000 00000000
000001d0

[Didée]

Originally posted by lordadmira

(1) I think what he was trying to say is that if u have quantizer offsets set for B frames, the video will flicker the more B frames there are.
(2) This is because of the jump in compression between P and B frame sequences.
(3) The use of AQ can exacerbate this under non-standard settings.
(4) Although it's hard to imagine a scenario where AQ will lead to flickering since it doesn't dramatically alter the average quant of a frame.
(1) No, that is not what CruNcher was trying to say. And it has not much to do with the mere number of B-frames.

(2) No, it is not because of the (normal-conditioned) "jump". It is because of a possible (abnormal-conditioned) "inverse jump".

(3) Almost right. AQ can create the problem. No problem without AQ, so there is nothing to _exaggerate_ for AQ.

(4) Dunno if that scenario is hard to image for someone. But it's a scenario very easy to create :D And it has nothing to do with the *average* quant - it's a per-block quant problem.

Simply put, that kind of flickering may occur if a given block in a B-frame is coded with a lower quantizer than its reference block in the P-frame. With XviD's default settings, this will never happen. But it will happen if one adjusts the ratio/offset in order to get lower quants for the B's.
E.g. with the example CruNcher gave: "X-1.0-1.0", which is indeed a somewhat common setting.

Using AQ, the quant for each block may be altered in the range of +/- 2. Now, when the actual settings force an effective offset of only "1" for the B's (or even "0" - I've heard rumours some people were doing so), then AQ will sometimes produce blocks in P-frames which quantizer is higher than the quantizer in the corresponding block in the B-frame. Simple as that.

BTW, basically the problem is known since a long time. There was a short period at the end of 2003, where one or more (non public) alpha builds of XviD had a b0rked evaluation of the B-frame settings, resulting in the B-frames *always* getting lower quants than the P-frames. The result was _very_ flickering, indeed.


Syskin, we probably are in need of a new bug ;) :

"Limit AQ to not produce per-block quants in P's that exceed the corresponding block-quants in B's."
Waitaminute - is that possible at all? The P's are coded before the B's get coded, so that might become difficult ...


- Didée

[bond]

to sum it up for everyone:

there is no problem with AQ atm when using the default ratio/offset B-frame values
AQ might show problems if another ratio/offset than the default one gets used

[lordadmira]

But that AQ'd macroblock is going to be predicted into the subsequent B frame so it's quant will(should) be the same. Are u saying that blocks in a B frame can't have different quants (I don't see why not) even when they're compensated blocks? I know that AQ isn't applied to B frames. If ur saying that then AQ is a big waste since *no* AQ'd blocks can be predicted forward except to another P frame.

U seem to be talking about flickering of individual blocks. I was talking about whole frame flicker since that's what I thought he was trying to describe.

LA

[cheerow]

Hello,

I just wanted to say that I did NOT see any flickering in the video when postprocessing was OFF. That's why I said it was caused by ffdshow's postprocessing. And I also used the defaults for b-frame ratio/offset! I had only 'max consecutive BVOPS' and 'sensitivity' in zone options changed! But still the flickering was caused by postproc!! I think someone didn't catch my point here :)

Regards

PS: the flickering was mainly noticable in large more-or-less-one-colored areas (like sky)

[pelle412]

I've run into a strange but reproducible crash while encoding a particular clip. The first couple of frames of this clip can be fetched at http://www.geocities.com/pelle412/clip.avi.

1. Open clip in VDubMod (1.5.10.1)
2. Choose Fast Recompress
3. Choose Compression
4. Choose XviD Codec
5. Load Defaults
6. Uncheck Packed Bitstream
7. Save new file and start job

VDubMod crashes pointing towards xvidvfw.dll. My System is Athlon XP 2800, 768 MB RAM, Win XP SP1.

EDIT: Forgot to mention, but with Packed Bitstream enabled, the crash doesn't occur. Also, if I resize the clip down to 512x272 it won't crash even with packed bitstream unchecked.

EDIT: Additional tests made me notice another VDubMod error message before M$'s dialogs pop up in the way: "An integer division by zero has occured in module xvidvfw.dll.

EDIT: Running the clip through AviSynth produced the same crash.

Script:
AVISource("clip.avi")

if I add some filtering, e.g. Convolution3D("moviehq") the crash no longer occur (probably because the frames fed to XviD has changed).

[unmei]

pelle412, i did 1-7 on your clip and it doesn't crash. Neither with mkv out nor with avi out.

XP SP1, Pen^3 600 Mhz, intel mobo (P3B-F or something like that), 768 SDR RAM

[edit]
also no crash on a Athlon XP 2600, Asus A78X-X, 1GB DDR RAM and win XP SP1

[edit2]
we are talking about XviD 1.0.1 koepi's build 2004-06-05, correct?
[one more edit..]
just found out that i use VDM 1.5.10.1 build 2366 while your clip was apparently done with build 2439 :o

[pelle412]

Hmm, it seems strange. Maybe there's something wrong with my system? It's been encoding for quite a while. It only happens when I enable packed bitstream though, which is the truly weird thing. It also happens on the first frame which means the CPU and chipset haven't started working really hard yet.

EDIT: erhm, only happens when I disable packed bitstream, and only on this clip.

[lordadmira]

I have build 2439 and it didn't crash. Win98.

[pelle412]

Well then it seems like it's a problem on my side. It's puzzling though. It only happens with this clip, using XviD 1.0.1 and no packed bitstream. DivX 5.1.1 worked fine too.

[CruNcher]

@lordadmira
the whole frame flickering problem is another one and only happens when very high bitrates are used DVD kind and the quantizers look like this p2 -sharp b3 -blurry p2 -sharp b3 -blurry p2 -sharp b3 -blurry this will couse a per every b-frame flicking :) i didn't test that myself yet, but i saw it. And what i can say is that b-frames are still not that perfect this quant flickering also happens without useing AQ but is not that visible as with AQ, only a slight intensity difference is percived.

[cheerow]

Are there any plans on implementing AQ for B-frames in XviD?

[Tuning]

A question regarding decoder.

Is there problem in brightness, as i can see new XvID decoder tends to be a lot darker than FFDShow or DivX decoders.

Thanks.

[Koepi]

tuning:

try selecting different colour spaces for output, i.e. force YV12. Or try the compatibility renderer.

Regards
Koepi

[Teegedeck]

Originally posted by CruNcher
@lordadmira
the whole frame flickering problem is another one and only happens when very high bitrates are used DVD kind and the quantizers look like this p2 -sharp b3 -blurry p2 -sharp b3 -blurry p2 -sharp b3 -blurry this will couse a per every b-frame flicking :) i didn't test that myself yet, but i saw it. And what i can say is that b-frames are still not that perfect this quant flickering also happens without useing AQ but is not that visible as with AQ, only a slight intensity difference is percived.
I encode at high bitrates all the time and don't have that problem and cannot reproduce it. I think the flicker you saw probably had other reasons.

Thus I believe Didée and bond gave a far more plausible explanation.

[Tuning]

Originally posted by Koepi
tuning:
try selecting different colour spaces for output, i.e. force YV12. Or try the compatibility renderer.


Thanks Koepi, everything working fine now. :)

[virus]

@Koepi:

no silent update to fix the "wrong version in the about box"-problem scheduled? (as posted here (http://forum.doom9.org/showthread.php?s=&threadid=76557&perpage=20&pagenumber=2) a couple of weeks ago)

cheers
virus

[Koepi]

virus:

you consider that a real problem? That's so minor...

well, let's see if I want to install the compiler already, I still am reconfigurring my system after a fresh installation.

Regards
Koepi

[virus]

Originally posted by Koepi
you consider that a real problem? That's so minor...Yeah, I agree it's minor. Originally I feared other data defined in xvid.h may have been invalid, especially the bitstream version. But seeing reports that your build correctly marks the stream as "version 35", I surely agree it's really minor... anyway, as you know the About box is built dinamically querying xvidcore for the embedded version. That means that at least something's wrong in xvidcore, so just to be safe... ;)

Also, given the amount of bugreports for XviD 1.0.1 (close to zero if any), I think this version will last very long, so maybe having everything 100% perfect may be a good idea (of course, there's really _no_ hurry if you're busy on different tasks).

(BTW: have you identified what exactly caused this glitch?)

cheers :)
virus

[Koepi]

virus:

hm, the core has the right bitstream number in xvid.h - i'll investigate.

Regards
Koepi

[galocza]

hi,
now i tried the "new breed", i really liked the bitrate mode in 2-pass.
but my encodes are jerky when played back. then i found out what it was: when motion precision is on (level doesnt matter) i have this problem playing them back with both ffdshow and xvid dsdec. switched off, its ok. went back to Nics 030716 build its ok.
thought about as filters and anything but the clean material fed to vdubmod does the same so i really think its something to do with xvid.
any advice?

ps: i didnt play around with settings (im a real noob for that, almost everything is default: only max i-fr interval is set to 250 and display encoding status is swithed off).
thx

[Koepi]

galocza:

uninstall both ffdshow and xvid. (I mean it. uninstall them properly and don't install a 1.x build over an older build - I switched installer systems and upgrading doesn't work!)

Then, fetch the latest ffdshow from http://athos.leffe.dnsalias.com/ and install it.

After that, fetch the latest xvid binary from my site, install it.

It should work flawless then.

Regards
Koepi

[egandt]

I'd suggest ffdshow from: http://mitglied.lycos.de/ieggei2/ffdshow/ if you have a P4 or AMD64 processor, the SSE2 optimization make all the diffrence in the world if you resize or denoise.

ERIC

[yaz]

@galocza
pls, allow to PM you !
the bests
y

[galocza]

@Koepi:
thank you, ill follow your instructions. btw ive uninstalled xvid before the new one but not ffdshow...

@egandt:
unfortunatelly i have neither of them 8(, i dont have sse2.

@yaz:
ok ive set it but i almost never log in (im mostly a reader not a writer here 8), but i (more or less) regularly check this email account: mymovies@freemail.hu.

thank you all,
galocza