MeGUI Feature Request Thread

[Sharktooth]

uhm... that way it's ugly.
well, i think this idea should be dropped at this point. we can already default megui to use always 2 threads for x264 even on single core non hyperthreaded cpus (for the reasons explained above).
and we can detect if there are more than 2 execution units and rise the number of threads to 4 for quad core or dual core hyperthreaded cpus...

[Morte66]

Originally Posted by Richard Berg

On my multi-cpu machines, I just run 2 copies of MeGUI (from separate folders, of course, so the xml files don't conflict). It's not that hard, and won't be very common right now.

Me too, it gets me from about 4.5 to 6fps on the stuff I've been doing lately. That's what made me put the request in. Oh well never mind, and thanks for looking at it guys.

[dimzon]

Originally Posted by Sharktooth

uhm... that way it's ugly.
well, i think this idea should be dropped at this point. we can already default megui to use always 2 threads for x264 even on single core non hyperthreaded cpus (for the reasons explained above).

And suspicions can be checked up:
We (rissain comminity ) take 2 clips coded with identical adjustments, in 1 and in 2 slices and we measure speed of their decoding on 2 processors nero the decoder (which supports SMP).

1 slice- 169 fps (both of the processor are loaded)
2 slice - 167 fps (both of the processor are loaded)

[Sharktooth]

interesting. maybe nero found a way to multithread the decoder using something different than slices. never looked into it...
however qt uses slices for that purpouse (but as we all know QT = coded like crap...).

[dimzon]

Originally Posted by Sharktooth

interesting. maybe nero found a way to multithread the decoder using something different than slices. never looked into it...
however qt uses slices for that purpouse (but as we all know QT = coded like crap...).

Elecard h264 encoders perform multithread encoding without slices too
Slices is easyest but not best way for multithreading

[Sharktooth]

indeed... but since i never used the nero decoder i thought it was using slices (like quicktime).
well, if all the mess is for accelerating quicktime playback we can drop even the 2 slices idea for single/non-multithreaded cpus.

[foxyshadis]

Well, Doom9, what about integrating Elder as a possibility? It isn't finished, but it already deals with the multiple encodings, segments, stats files, merging, and all that rubbish for you. And it works for xvid and x264. Obviously it wouldn't be bundled by default, since it's perl, but it'd be really nice to see it officially supported. Could just flip a switch and use its brand of massively multithreaded encoding rather than threads. (And since xvid and x264 support mt encoding anyway, once xvid makes it configurable you could move #threads to a global #cores option.)

[dimzon]

i believe it's easy to port Elder from rerl to C#
i'm interested in it

[Richard Berg]

Integrating Elder looks even more difficult than trying to sort out the dependency difficulties discussed earlier.

The more I think about it, the more I like having independent queues. The existing OO design should make it reasonably easy.

[Sharktooth]

IMHO idipendent queues is an ugly solution.

[dimzon]

Originally Posted by Sharktooth

IMHO idipendent queues is an ugly solution.

Lets wait for Doom9 refactoring first

[Mutant_Fruit]

IMHO idipendent queues is an ugly solution.

I agree aswell. I wouldn't like the idea of an app i was running having 4 independant queues because i have a dual-core dual-cpu machine.

How about this to help solve the dependancy issue... If a "job" is created, instead put all the jobs and dependant jobs inside an arraylist (just for an example, there's probably better ways of doing it. So we can go something like...

Arraylist Job1 = new Arraylist();
Job1.Add(job1_pass1);
Job1.Add(job2_pass2);
Job1.Add(job3_pass3);
....

Then...
foreach(Job job in Job1)
{
     display information in the queue
}

Then, if someone wants to multithread by running two jobs at once, you just have to check that you aren't running two jobs from the one arraylist at the same time. Also, if someone has 10 "Jobs" in the queue, re-ordering them could be made safer because instead of having 20-30 unlinked jobs, we'd now have 10 Arraylists. When they'd try to move "job7_pass3" upwards, instead we'd move the Job7 arraylist above the Job6 Arraylist, then we'd print out the queue again, thus keeping Job7's jobs intact.

I don't know how it works at the moment, but how does that sound? Stupid or not?

[dimzon]

Actually one job series can contain:
multiple independed audio jobs
2-3 depended video jobs (multipass)
mux job

in this case you can run multiple audio jobs at same time


talking about such architecture we are close to "Processor controlled via Data-Flow" ideology (used in all modern CPU)

what does we need to organize such functionality:
jobs must contain references to related jobs (i.e. 2-nd pass must refer on 1-st pass, mux must refer to 2-nd pass and all audio etc)
in this case we can run any job wich related jobs is already done

[berrinam]

Originally Posted by Sharktooth

IMHO idipendent queues is an ugly solution.

My main gripe with independant queues is that the user would have to be actively thinking about which queue is likely to take the longest and would have to do his/her best to ensure that the encoding time balances up. This is IMHO too much work for the user who is only interested in getting a good end-result video.

Originally Posted by Mutant_Fruit

How about this to help solve the dependancy issue... If a "job" is created, instead put all the jobs and dependant jobs inside an arraylist (just for an example, there's probably better ways of doing it. So we can go something like...
....
I don't know how it works at the moment, but how does that sound? Stupid or not?

I like this suggestion because it is simple. The issue about audio jobs not relying on each other, which dimzon raised, is not a huge concern, IMO, because the time taken for encoding audio is so small relative to video encoding.

Originally Posted by dimzon

what does we need to organize such functionality:
jobs must contain references to related jobs (i.e. 2-nd pass must refer on 1-st pass, mux must refer to 2-nd pass and all audio etc)
in this case we can run any job wich related jobs is already done

Didn't you suggest this sort of thing before? I agree that this is the optimum solution in customisability and reliability, but probably the most complex code-wise.

[dimzon]

Originally Posted by berrinam

but probably the most complex code-wise.

I don't think so - proper OO design can make it easy

[Doom9]

in this case you can run multiple audio jobs at same time

No, you cannot, because at the time you pass from audio to video encoding, that's when a bunch of postprocessing routines kick in that make sure you end up with the proper video bitrate.. instead you create an undeterministic waiting period from the time the first audio job has been processed, to the time the second has and the queue can continue.
Actually, it's probably not even as hard to run two queues.. as the statusupdate contains a reference to the job that triggered the update, and related jobs are already linked (they need be for out-of-order processing and proper between job updates).

what does we need to organize such functionality:

A job is a part of a linked list.. always has been for about a year now.. you can always get to the start of a series of jobs and to the end of it.. it takes no special treatment. It wouldn't even take too long to change existing functions to start/end jobs and the whole markJobxyz shebang to permit two jobs being processed in parallel (admittedly you have to place locks everywhere or it'll end up in disaster, but if you're a creative locksmith, you'll manage). What I find very perxplexing is that not a single person here but me is even thinking about the most basic question of how the heck you keep a user appraised of what's going on with two jobs in parallel, and how you need to explain a user that suddenly there's only one job being processed when there are 3 left in the queue. And on top of that, what's wrong with opening explorer, select your megui folder, press control-c, go to another folder, press control-v and you now can run megui two times completely independent without no worries whatsoever and not a single line of code needs to be written? What's wrong with the KISS approach for the 0.00001% of the users who cannot live with stock functionality?

[cc979]

just tried the 0.2.3.2097 devbuild works pretty good since the last time i tried, been busy with other things just wondering if there's any plans to show a rendering rate like the same as the video part ?

would be useful for benchmarking and comparing results with others

[Doom9]

just wondering if there's any plans to show a rendering rate like the same as the video part ?

And what would a rendering rate be? I understand rendering in terms of POVRay.. essentially an fps rate.

[dimzon]

Originally Posted by Doom9

And what would a rendering rate be? I understand rendering in terms of POVRay.. essentially an fps rate.

encoding_time/audio_duration

[cc979]

Originally Posted by Doom9

And what would a rendering rate be? I understand rendering in terms of POVRay.. essentially an fps rate.

something like kBps per second, processed/rendered sorry about that