Multithreading pre-processing pass in Megui?

[Adub]

Is this possible? I have tried using the Pre-processing tick box before and I am always restrained by a single threaded encode that runs on the same core as my Avisynth script. If the two were to run on different cores, or in multithreaded mode, then it would be a different story.

Oh, and I already know about MT avisynth, I use it all the time, just there are a few problems with the script I am using and it doesn't help all that much.

It would be better if we could get Mencoder's ffvhuff codec to run multithreading successfully.

[Adub]

Am I the only one who thinks this would be great?

[Doom9]

Does mencoder supports this in the huffyuv mode? MeGUI as a GUI app with unscheduled GUI updates is inheritently multithreaded, but it really comes down to the encoder.. if it supports multithreading, megui can support it, if it doesn't support multithreading, there's nothing megui can do about it.

[Adub]

I am pretty sure in the manual it says something about lavc having the "threads=(1-8)" option, but I don't know if ffvhuff has it enabled as well. I would assume so, as it is under the lavc options but I don't know for sure.

[ChronoCross]

I am pretty sure in the manual it says something about lavc having the "threads=(1-8)" option, but I don't know if ffvhuff has it enabled as well. I would assume so, as it is under the lavc options but I don't know for sure.

why don't you test it and let everyone know?

[check]

The other alternative would be to give MeGUI the option to either make use of trim() or run multiple jobs at one time.

[ChronoCross]

The other alternative would be to give MeGUI the option to either make use of trim() or run multiple jobs at one time.

which also has the possibility of getting grossly out of hand if megui starts trying to control the actions of a codec outside it's own featureset. Could lead to other unknown bugs.

[Adub]

why don't you test it and let everyone know?

I did try testing it, an it didn't seem to want to jump to both cores. Yes, the number of threads increased, but it still stayed on the one core. Although, that testing was the farthest I had ever gone with commandline so I am not so sure that I did it correctly.
But if I did, it may be hopeless for us, at least until the Mencoder guys can give the ffvhuff codec some proper threading support.

[check]

which also has the possibility of getting grossly out of hand if megui starts trying to control the actions of a codec outside it's own featureset. Could lead to other unknown bugs.
I'm not sure I understand what is being controlled, or where the possibility of huge problems come from.
With my idea a: if source is not .avs, create avs and load video via *source. Duplicate avs and add trim() with relevant parameters. Open n instances of program and have fun parsing stdout.
With b: run commandline for n jobs.

Can you elaborate where an issue would be?

[Doom9]

Every codec's rate control has a certain variability to it.. that variability doesn't go down when you decrease the length of the content to be encoded.. so if the average overshoot or undershoot is 1MB, your range of overshoot/undershoot will be ±N*1MB. Also, you effectively reduce the usefulness of multipass ratecontrol. While the size thing only matters for encode where size matters, the latter matters overall, except for the lossless case. However, what you suggest might be not be so hard to understand intellectually, but the ability for parallel processing has been shot down multiple times in the past. If you think it's easy, then I suggest you give it a shot.. you may find out that it's not quite as simple as you imagine when things don't run in linear fashion. For that matter I'm quite sure that every programmer has once upon a time ran into a concurrency issue.
And that's exactly what makes the splitting up less than desireable.. not only do you have to chop up sources and run them in parallel, you also have to put them back together in the proper order and as you should realize, jobs depend upon other jobs..

Is it doable: yes, is it less than a few hours away: yes, is it extremely hard to debug if something goes wrong: yes again.

[ChronoCross]

I'm not sure I understand what is being controlled, or where the possibility of huge problems come from.
With my idea a: if source is not .avs, create avs and load video via *source. Duplicate avs and add trim() with relevant parameters. Open n instances of program and have fun parsing stdout.
With b: run commandline for n jobs.

Can you elaborate where an issue would be?

doom9 said it perfectly.