Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
13th September 2011, 15:34 | #241 | Link | |
Registered User
Join Date: May 2005
Posts: 1,462
|
Quote:
__________________
Gorgeous, delicious, deculture! |
|
13th September 2011, 23:25 | #243 | Link | ||
Registered User
Join Date: Aug 2007
Posts: 374
|
In DynamicAssembledCode::Call
Quote:
Quote:
|
||
15th September 2011, 22:21 | #248 | Link | |
Registered User
Join Date: Dec 2006
Posts: 280
|
Quote:
I do want to use multi threading. But I wonder whether 2.5.8 MT is better than 2.6. Or is it perhaps better to just run 2 or 4 simultaneous encoding proccesses? I do not know. I was hoping somebody would help me with making that decision, instead of gruelly trying it out myself. |
|
15th September 2011, 22:27 | #250 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Yes. |
|
15th September 2011, 22:30 | #251 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
All options other than the vanilla 2.5.8 (including all the 64-bit variants, all the MT variants and all the Avisynth 2.6 variants) are either: a) way too unreliable, b) way too limited, or c) all of the above to be useful in a production environment. Last edited by TheFluff; 15th September 2011 at 22:32. |
|
15th September 2011, 22:32 | #252 | Link |
Registered User
Join Date: Dec 2006
Posts: 280
|
64bit is a no go as well?! Blah. It's not a "production environment" either... mmm, I mean, you make it sound "serious" or something *chuckles*
I just want to encode fast... Shit... That's all... Maybe I should run 2-4 64 bits avisynth? |
15th September 2011, 22:35 | #253 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
Just stick with Ye Olde 32-bit 2.5.8. If it was good enough for your grandfather, it should be good enough for you, and if you have to use so many filters that you run out of memory, the source was probably so bad that it wasn't worth encoding anyway. Remember this, kids: trying to add multithreading to a huge software project that was written without a single thought of thread-safety in mind is madness and a recipe for an eternity of crashing. If said software project also loads and uses many third-party plugins that ALSO were written without a single thought of thread-safety in mind, you might as well kill yourself and end up in Hell already, because that's probably going to be more pleasant than what you're going to end up with. Last edited by TheFluff; 15th September 2011 at 22:52. |
|
15th September 2011, 22:38 | #254 | Link | |
Registered User
Join Date: Dec 2006
Posts: 280
|
Quote:
|
|
15th September 2011, 22:43 | #255 | Link | |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
Quote:
edit: it might work if you only use it in single-thread mode, but honestly, avs-mt is just so buggy that you're not likely to notice much of a difference in stability anyway... Last edited by TheFluff; 15th September 2011 at 22:48. |
|
15th September 2011, 22:47 | #256 | Link |
Registered User
Join Date: Jun 2010
Posts: 443
|
For me the most stable versions are SET's 2.6 builds. Every version is stable for me without multithreading, but using multithreading I have found 2.6 to crash less than 2.5.8.
It seems to be different for everyone but that's how it is for me |
15th September 2011, 22:47 | #257 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
There are a shitload of variables involved - complexity of the script, which filters are used (even the version of the filter can be crucial), in which order the filters are used, number of threads - should I go on? All you can do is try for yourself. |
|
15th September 2011, 22:55 | #260 | Link |
Excessively jovial fellow
Join Date: Jun 2004
Location: rude
Posts: 1,100
|
The operative phrase here being "for me". Since the entire thing is basically thread-unsafe, poking at anything that might change the way your OS schedules threads may also change the application's behavior and crashiness/non-crashiness. This is of course entirely impossible to predict and depends on so many factors (including things such as your OS version and your hardware configuration) that it's essentially meaningless to try to replicate.
|
Thread Tools | Search this Thread |
Display Modes | |
|
|