View Full Version : XviD 1.0.2: random crashes now par?
eichlan
11th November 2004, 09:59
Hello,
I just went on and downloaded Kopei's xvid 1.0.2 "stable" binaries. I also had this problem when I downloaded 1.0.0, and 1.0.1, but no earlier versions... No matter what I do, after a while, the codec just crashes while encoding. It does it in such a way that no program I have will stay alive long enough to give me a report on what actually happened. This is frustrating as this is the coolest release yet, you know, except for the crashing.
Is anyone else having this problem, and if so, does anyone know how to fix it? It does it on a P4 and both Athlon XP machine's I have, all have at least 256 megs of memory, and none of them have had problems with any pre 1.0 releases. The encodes look amazing, right up until the encoder crashes. Oh, and all of the machines are running XP SP1...
...oh, also, it happens no matter what options I use, and what options I change, I even tried wiping the registry of all xvid references and re-installing, no dice.
Please help me! I really want to encode! Thanks a lot!
Koepi
11th November 2004, 12:27
Do you overclock your computers?
If not, did you check proper cooling and/or memory?
XviD stresses your CPU and memory subsystem more than any other application will (given you use builds compiled with ICL like mine).
Regards
Koepi
eichlan
11th November 2004, 23:42
Overclocking? absoutely not! My machine is fast enough! And as far as cooling is concerned, that is definately not an issue. And this is not the most cpu-intensive application I run by a longshot, and nothing else does this. It is DEFINATELY version 1.0.0, 1.0.1, and 1.0.2. I havn't tried the latest beta yet, but this has not happened under any other "stable" package, any of my software, or any other version of xvid, ever. And it happens on every machine I have. Sorry, and it is the Kopei build.
Manao
12th November 2004, 07:02
eichlan : what version of virtual dub are you using ? what are your machines ? do you use avisynth ?
eichlan
12th November 2004, 07:33
Technically, the only thing that should matter is that this machine is an Athlon XP+ 2700, I can give more specs on the processor if you want, but I've verified complete diagnostics on the system, and it is fine. It works with earlier versions of everyone's xvid, even ones that other people have had problems with.
I have tried the vfw and directshow interfaces, and doing it through ffdshow. I have tried serving frames directly into virtualdub, and through avisynth. I have tried virtualdub, and virtualdubmod, both the latest versions, I checked monday on both sites. I have also tried custom diagnostic software and simple directshow conversion software. Oh, also media player classic on capture mode.
No matter what I do, it crashes in the same inexplicable way, which is, without any notice, and windows doesn't even pick it up as a crash. I have seen this behaviour before with rampant and out-of-bounds memory writes, not that I'm saying that's the problem, I just think it's odd that it was only introduced in the "stable" releases.
Also, I have tried turning on and off every combination of options I can think of, including disabling all optomizations. Nothing helps. Generally it lasts longer if I use a fresh intstall and never change any settings at all, but then the picture isn't as great as it could be, and it does still crash eventually.
At first I thought that it may be a problem related to certain frame data, so I've tried many, many, many different sources ranging from DVDs to tv shows, tape captures, rendered sources, and so on. It crashes in a different place each time, even with the same options. If I try an encode enough times, eventually, it sometimes works, but I don't have the patience for that.
Windows is Windows XP Pro with SP1 installed, and, as far as I know, the latest security updates and whatnot. I've tried everything from heavy process loads, to average, to nothing but the core windows processes running and always the same results. It does use some memory, but no where near the 512megs that I have installed at the moment...
...and yes, my memory is fine, just ran a 10 pass check on it all, my disks are fine, I just checked them. I checked all major buses in the system, and ran coherency checks on every device in my system that has one, just in case anyone asked about that. The temperature never exceeds low-to-average temps, and just in case, I generally keep a fan from the outside on anyway, and of coruse, it gets cold in the mountains here ;)
Right now, not really an issue, I'm using an old uManiac build, but I would like this one to work, and I guess you guys would too...but it seems like it does work for everyone else :(
Thanks!
Manao
12th November 2004, 07:59
eichlan : XviD is better at checking memory than any memory checker I tried up to now. Though it's disturbing that you're claiming XviD won't work on any of your machines, which would tend to dismiss a faulty hardware, i still think hardware is guilty, especially if you tried several ways of encoding. I once had some memory which was making XviD - and only XviD - crash, and as soon as I removed it, XviD wasn't crashing anymore.
eichlan
12th November 2004, 08:22
Well hey, guess what everone! It's not XviD's fault!
I just downloaded the complete source, configured and installed it (after completely removing the one I had) and now it works perfectly. Dunno what was up with that, but now it's working better, faster, and no crashes. I'm going with the source distro's from now on...
Thanks everyone!
P.S. xvid uses very little memory when I ask it to, and so to make sure of what was on, I mapped out memory, using different regions in physical memory, it still failed, no matter what, it's something to do with the build, I figure...sorry Kopei, I've always loved your builds, it's nothing personal...maybe I just have a quirky processor ;)
Koepi
12th November 2004, 08:22
I'm 100% confident your hardware is at fault. Else everyone else would suffer from random crashes due to out-of-memory-writes.
I've seen this application-disappearng-behaviour only in cases where the systems where overclocked beyond stability.
Sorry mate, just believe these guys around here who have seen enough BS in this direction already.
(And, if you'd try to listen and react on it [thus: trying different RAM, controlling heatsink+fan,...] you'd very soon notice that you're pointing your finger at the wrong direction. Would be great to hear if this helped your problem.)
Starting to get annoyed
Koepi
eichlan
12th November 2004, 08:38
Um, sorry.
I just tried out a friend's 512 dimm in my other machine...the current one is still going with my build...and it crashed immediately...tried again, got into it about 5-10min, crashed again. The two machines have the same processor and motherboard. The machine that my friend uses has the new xvid and he used it yesterday, worked fine with his memory...
I didn't think I said anything to offend anyone, but once again, sorry...
I don't know what to tell you, but if anyone else ever has this problem and wants to try the build I just made (only vfw), they're welcome to it...
...sorry...
Also, I don't doubt that it's hardware-related, however, it's not a problem with xvid, is all I was saying...not everyone can build their own copy, so I'm glad that your build works for them, there must be something odd about my setup...I dunno, but when I built my own copy, it works fine...so it's probably, in my opinion, a combination of the special hardware I have, and something between the way xvid works, and build options you have, Kopei. I'm disappointed, like I said, because I've always loved your builds. I'm a fan, not an antagonist...
Koepi
12th November 2004, 09:21
Something you could try is to use higher memory latency values. You won't really notice a speed difference, but if you use i.e. 133MHz DDR memory specified for 3-3-3-3 at 3-2-2-2 it can already start this behaviour. (Or like my memory at my machine: 133MHz DDR 3-2-2-2 runs at 166MHz 4-3-3-3 - bottom line this is fine with the specs, but can result in odd behaviour. Fortunately I don't use no-name memory anymore and am on the safe side therefor.)
I've seen systems where the heatsink was so full of dust that the processor didn't get sufficient cooling in a longer encode. Worst case i've seen was a heatsink with too much "cooler paste" (can't remember the right english word for it now) which in effect resulted in a usually usable system. But with xvid it crashed (the temperatures still seemed fine) - the problem was, that the cpu got too hot in single spots. Removing that paste and applying the heat sink with just a very thin film of cooler paste fixed the issue(!).
My binaries are so highly optimized that every little issue which you don't notice with any other software will show up encoding with these builds.
You should notice some noticable speed-drop with your own build compared to my build. If you haven't the possibility to do a "proper" system update (i.e. the mainboard bios might be guilty as well as it decides on the default memory timings), it's of course a possibility to use a gcc- or M$-compiled build and live with the performancce drop.
Sorry that I run out of ideas how to "properly" solve the issue for you.
Regards
Koepi
eichlan
12th November 2004, 09:25
It's all cool, I have no issues anymore, and my build does run faster, so...I dunno what to tell you. Maybe my processor is installed wrong, but at least for now, I don't have to mess with it.
Thanks
Mug Funky
12th November 2004, 16:50
@ eichlan: you put the chip in upside down, didn't you? ;)
@ koepi: i didn't know that about the cooler-paste (i have no idea what it's called, either). and the CPU fan dust thing is something i might watch for if i start getting crashes. i don't overclock, and this computer's run (reasonably) fine and stable for nearly 5 years, so it should be fine.
the builds are that heavily optimized? cool. when i finally upgrade, i'm using your Xvid builds for benchmarking :)
Leak
12th November 2004, 19:12
Originally posted by Mug Funky
i didn't know that about the cooler-paste (i have no idea what it's called, either).
"Thermal grease" is what you're looking for - and since it conducts heat worse than a heatsink's metal but better than air, you use it to keep the air out of the space between heatsink and what it's supposed to cool.
(Of course, if you really want to get a little bit of thermal grease out of that syringe-looking thingy it comes in and you push just a little and it's still waaay too much and you use some cardboard to spread it over a Radeon 9800 Pro and it's all over the place and I'm starting to freak a bit - maybe that's just me... ;))
np: Faction - And Not Very Transparent (Intelligent Toys 2)
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.