DivX 6 - Helium Codec error

[ChrisBensch]

I'm using DGIndex 1.4.0, Avisynth 2.55, avs2avi 1.39 to encode hi-def .ts's into DivX 6 (helium codec release). When I run avs2avi in my command window, I get an error "KMP_ALL_THREADS unable to form team with 32 threads, using 31. Consider using a number larger than 32"

I can't find this error anywhere, any ideas?

[iNFO-DVD]

I tried using the HELIUM codec for avi.NET and got that exact message in my debug window. I'm not sure exactly what it is. I found the codec to work on some occasions and then not.

Maybe it's just still too beta, looking forward to further updates as I have a HT P4.

[ChrisBensch]

I've also ran this build of DivX 6 on my laptop, Pentium M 2.10GHz with the same results.

[ChrisBensch]

Ok, I just got a shiny new Dell Dimension 9100 with a Pentium D 820 (dual core 2.8GHz). I decided that I'm going to muck with the "KMP_ALL_THREADS" variable until I get it. For my machine, I stop getting the error if I "set KMP_ALL_THREADS=65" either in a batch file or in my system environment variables. I'm not really seeing any speed increases, maybe .5 - 1.0fps. My encoder machine only has 512MB RAM, I'll be upping to 2GB shortly to see if that makes a difference. My next box with probably be a Pentium D 840 (or whatever is out at the time).

[mic]

I tried using the HELIUM codec for avi.NET and got that exact message in my debug window. I'm not sure exactly what it is. I found the codec to work on some occasions and then not.

Maybe it's just still too beta, looking forward to further updates as I have a HT P4.
If it helps, and it is a major guess -- probably shouldn't even post it, wouldn't if not for avi.NET etc., but here goes :rolleyes: :

In my experience I think that what can happen too often with HT or Dual Core, winxp, and the way xp handles (or doesn't handle) video related files & filters, threads can get mucked up rather easily when doing video processing. .NET doesn't help.

To me it seems a prob. related to HT/DC, RAM timings, dual-chan, and performance m/board design -- scaling back or turning off can help. I mention .NET really without anything to back it up besides playing with it seems to help. If you have a lot of video files/filters installed as I do, older versions of wrong files can get used & cause prob. Often it seems a process is working fine, but while working xp will try to access network -- this seems where a lot of prob & crashes can occur, especially if firewall locked.

I've had various prob occur with different video software, where cpu usage is often pretty low to moderate, but always moving a lot of data around. Turning off network in xp rather then at firewall is a must, if you turn it off at all. M/board, RAM, CPU settings effect but don't cure. Setting for multiple cpu don't seem to matter in software. Worst offenders seem to be often older video files/filters -- renaming folders containing these (like graphedit) when not in use eliminates random prob. so far (fingers-crossed) for several months.