DivX 5.2.1 3rd pass encoding error

[tritium]

Hrmm, First post, lets hope its not somewhere else i cant find.
Anyhow, installed DivX 5.2.1 recently, and using GKnot to encode. Couple of problems.

1)
If i open the First Pass .... Credits for the DivX codec settings, GKnot dies about a min after it. No errors, just quits, as if i pressed ALT+F4. I saw a post about this somewhere else, but it didnt help. Its no biggie really, i can still set my settings, and encode fine, but its annoying.

2)
For a 3 pass encode, the first two passes are fine. The 3rd pass runs, and at the end of it, VDub reports an encoding error, and sits there until i click 'Ok'. The weird thing is, that the avi file is fine. when i preview it, no problems. The error seems to occur on the last frame or something, so i have to manually append the credits, and mux the audio.
This again, would be no hassle, except for the fact that I can't queue up a few encodes, and leave them for the weekend, as the process fails at the end of pass 3.

Tried reinstalling codecs, and GKnot, but same problem.
Everything was cool before i installed the new codec, so i am fairly certain that its a problem with 5.2.1.

Suggestions?


DX - 1st Pass:
-bvn1 780 -pre 0.00,0.00,0 -psy 0 -key 300 -log "c:\divx.log" -b 2 -g -sc 50 -pq 3 -profile 0 -nf

DX - Nth Pass:
-bvnn 780 -psy 0 -key 300 -log "c:\divx.log" -w -b 2 -g -pq 3 -vbv 7800000,3145728,2359296 -profile 0 -nf

DX - Last Pass:
-bvnn 780 -pre 0.00,0.00,0 -psy 0 -key 300 -log "c:\divx.log" -w -b 2 -g -pq 64 -vbv 7800000,3145728,2359296 -profile 0 -nf

[tritium]

damm, of course, i find this:
http://forum.doom9.org/showthread.php?s=&threadid=83719

anyhow, its not a heat problem, none of the chips are OC'd, only get 50% CPU usage(2 CPU system) anyhow.

[Magno]

I get the same problem than you when encoding the 3rd pass, and i haven't any temperature issue: 50 Celsius degrees during the process.

Anyway, the third pass is completed successfuylly despite of the problem, so you can queue a fourth pass and it will be done although the problem will keep apearing.

[tritium]

unfortunately not,
The 3rd pass(final pass) fails, VD-Mod throws up a message box, reporting the error, and the encode session hangs, until I click the 'ok'(next morning), to accept the message / error.

woe is me.

[DigitAl56K]

Are you both using GMC?

[tritium]

Yes for me anyhow.

[Magno]

No, i never use GMC: it increases encoding speed by a lot and only gets a few megs of extra compression.

@tritium: i use VirtualDubMod and i don't get any error message, so i suppose this all is codec's fault
Anyhow, i remember the first few times I encoded using 5.2.1 that error didn't appear....

[tritium]

i use gknot, but since that fires up VirtualDubMod, and i get the message, i guess its all the same really. i might knock up an application that will detect the error window, and click the ok button while i'm away.
if i do i'll post up a link here if you wish to try it out.

[AsTimeGoesBy]

Originally posted by tritium
damm, of course, i find this:
http://forum.doom9.org/showthread.php?s=&threadid=83719

anyhow, its not a heat problem, none of the chips are OC'd, only get 50% CPU usage(2 CPU system) anyhow. Originally posted by tritium
unfortunately not,
The 3rd pass(final pass) fails, VD-Mod throws up a message box, reporting the error, and the encode session hangs, until I click the 'ok'(next morning), to accept the message / error.

woe is me.
I have noticed the same (with DivX v5.21). VirtualDubMod shows an error (Code -100) after the 3rd pass.

Some users here think this is caused by hardware problems of any kind.
I would never exclude that possibity of course, because also my PC has a wrong front side bus an thus a slighty overclocked CPU.
Well i know, some of you will say now: '...here you have it!' and skip reading this post...

But for me, i have made a >30h memory test with memtest86+, this was some weeks ago. And during my holidays i have encoded almost 10 DVDs as 2-pass-divx (took >100h) without any problems.
I never would say now my PC is stable, but it doesn't leave the impression of a unstable device.
So far the environement...


The above-mentioned error happens only at the end of the 3rd pass - if it happens at all.
But the length of the video doesn't matter, i have experienced this error at a test sample of 26sec and at films of more than 1h.


I have no doubt that video encoding is tough work and a massive load for CPU and other components. So it always could be a hardware weakness.
That's why i will lower CPU and memory timings and try to then to reproduce the error as soon as possible.