I would suggest you use an input box for an pretty much unlimited number of threads instead of checkboxes. the checkboxes essentially hard-codes/hard-wires the number of threads and cores that mediacoder can handle. so with a machine like this, you would have a problem:
http://exxactcorp.com/index.php/solution/solu_detail/42
it has 80 threads and 40 cores. and by the way, this proc http://ark.intel.com/products/53577/Int ... Intel-QPI) can have up to 8 procs tied together. this server (I personally would call it a desktop) has 4.
once you get the code set to unlimited, I suspect newsrooms would probably be more interested in your code. and then they can start using computers like this to - reduce their conversion time and speed up their work.
well, even a 32-bit integer for the number of threads or a 64-bit integer for the number of threads would work well for quite a long time and on many platforms.
as for a maximum, you can ask the OS what the maximum number of cores and threads are through the Win32 API.
http://blogs.msdn.com/b/timid/archive/2 ... cores.aspx
http://stackoverflow.com/questions/2901 ... -threading
Jim Michaels
issue with hard-coded number of cores/threads
issue with hard-coded number of cores/threads
----------------------------------------
Jim Michaels
Jim Michaels
Re: issue with hard-coded number of cores/threads
Currently the number of threads is calculated upon different encoders and number of CPU cores.
When things work together, things work.
Re: issue with hard-coded number of cores/threads
not entirely true. I just downloaded it, and ran the config thing. yes, it queries the proc's number of threads. this is a good step.but the fact is, the GUI still has a physical limit on the number of threads. fix that by changing the array of checkboxes in the tasking tab (a fixed number of threads maximum!) to a textbox for the value and a button which fills this in for you by querying the proc. maybe by default this could have the value of 1.stanley wrote:Currently the number of threads is calculated upon different encoders and number of CPU cores.
like I said, there is already a very nice 4-proc 40-core 80-thread 512GiB HPC server which breaks this limit. see http://exxactcorp.com/index.php/solution/solu_detail/42
that proc is capable of typing up to 8 procs together. so I wouldn't be surprised if they came up with a cube...
this one looks like a standard server, but with more horsepower.
----------------------------------------
Jim Michaels
Jim Michaels
Re: issue with hard-coded number of cores/threads
Hello,
I agree with jmichae3. I just bought a DUAL-CPU E5-2697v2 and I'm disappointed to see that Mediacoder is limited to 16 threads.
I use x64 version 0.8.28 build 5588. There is probably an earlier version...
How can I use the full potential of my conifugration ?
Regards,
Philippe.
I agree with jmichae3. I just bought a DUAL-CPU E5-2697v2 and I'm disappointed to see that Mediacoder is limited to 16 threads.
I use x64 version 0.8.28 build 5588. There is probably an earlier version...
How can I use the full potential of my conifugration ?
Regards,
Philippe.
Re: issue with hard-coded number of cores/threads
from the x264 wikki:
threads
Default: auto (frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors)
Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16). The speed gain should be slightly less than linear until you start using more than 1 thread per 40px of vertical video, at which point the gain from additional threads sharply decreases.
x264 currently has an internal limit on the number of threads set at 128, realistically you should never set it this high.
threads
Default: auto (frame based threads: 1.5 * logical processors, rounded down; slice based threads: 1 * logical processors)
Enables parallel encoding by using more than 1 thread to increase speed on multi-core systems. The quality loss from multiple threads is mostly negligible unless using very high numbers of threads (say, above 16). The speed gain should be slightly less than linear until you start using more than 1 thread per 40px of vertical video, at which point the gain from additional threads sharply decreases.
x264 currently has an internal limit on the number of threads set at 128, realistically you should never set it this high.
my quant puzzles http://puzzles.nigelcoldwell.co.uk go look