EEVblog #726 - Dual Xeon Video Editing Machine Build

[EEVblog]

Dave builds and tests the 24 core dual processor 2.6GHz Intel Xeon E5-2630 v2 video editing machine and benchmarks against his current 8 core i7 3770K machine at 3.5GHz.
This is one hour of PC building and software testing, if you find this stuff boring, don't watch it!
CORRECTION:
The i7 3770K is actually running at 3.7GHz
UPDATE:
Even doing a 1 hour render at 240W consumption, the heatsinks do not even get warm to the touch.

[EEVblog]

<comment ignore filter now on> 

[pickle9000]

<comment ignore filter now on> 

Funny,

Anyway is the plan to use both the systems to render video? That would increase workflow. Get Seppy on desk processing something?

[necessaryevil]

<comment ignore filter now on> 

Too bad! Now you aren't gonna read that I like your video!

The Core i7-3770K has a base frequency of 3.5GHz, but it has a maximum turbo frequency of 3.9GHz. It overclocks itself!

Dave's config. I don't know a few things like the exact type SSD, or the hard drives he will install.

• 2x Xeon E5-2630 v2 [CPU])
• 2xCooler Master Hyper T4 [CPU cooler]
• 24 GB DD3 ECC (2x8GB + 2x4GB) [RAM]
• Super Micro X9DA/E9 [main board]
• Gigabyte Radeon R9 290 [GPU]
• 2x240 GB Kingston [SSD storage]
• Corsair RM650 80+ Gold [PSU]
• Corsair Graphite 730T with extra screw  [enclosure]

[Lightages]

Being anal retentive when it comes to building computers, yes, I was complaining the whole time about your build. Does it make a difference? Only to my ego probably, but.... GET THE AIRFLOW RIGHT!!!!!!

[Stonent]

Just a couple of things:

Make sure you've got the Intel Rapid Storage drivers installed:

https://downloadcenter.intel.com/product/55005/Intel-Rapid-Storage-Technology-Intel-RST-

Even if you're not running RAID, it makes sure Windows 7 is treating SSDs correctly, and also provides early failure warnings on the drives. Hopefully your bios was set to AHCI, IRRT or RAID mode when Windows was installed or the rapid storage drivers may refuse to load.

Also the chipset support software:

https://downloadcenter.intel.com/product/1145/Intel-Chipset-Software-Installation-Utility

[necessaryevil]

Being anal retentive when it comes to building computers, yes, I was complaining the whole time about your build. Does it make a difference? Only to my ego probably, but.... GET THE AIRFLOW RIGHT!!!!!!

Shut up! 

[German_EE]

The engineer in me looks at those big heatsinks suspended in thin air and thinks WRONG, but I can't see any way to deal with them apart from mounting the motherboard horizontally.

Anyway, hyperthreading in Windows 7, this may help:

http://windows7themes.net/en-us/how-to-enable-hyperthreading-in-windows-7/

[woox2k]

Talking about exporting, compressing video many times before uploading them to YouTube. Considering that you are only keeping the files outputted by Handbrake, i think it would make sense to export videos from Vegas with minimum compression. That would make the files a lot larger but if you're going to recompress them with handbrake anyway it should not matter. Exporting raw/minimal compressed videos from Vegas should be faster than compressing them as well.
Even though your videos look pretty good it's a bit odd to think that these files get compressed 4 times before i see them. (Camera > Vegas > Handbrake > Youtube)

PS. 12core Xeon should be a lot faster than a single 4/8core CPU, there must be something wrong with Vegas settings. Remember that HyperThreading does not give 100% boost and in reality you are comparing 12 core CPU against a 4 core one, not 12 vs. 8 you stated in the video.

[necessaryevil]

Hmm.. about minimum compression: remember that upload speeds are lower than download speeds. Also, Dave has pointed out that Australia isn't the best country in the world to get fast internet. On the other hand, Dave has an 8 mbit upload, which is decent and can do about 3 GB/hour.

//edit:
I should have known it was more now, since that video is quite old!

[Corporate666]

Being anal retentive when it comes to building computers, yes, I was complaining the whole time about your build. Does it make a difference? Only to my ego probably, but.... GET THE AIRFLOW RIGHT!!!!!!

What's wrong with the "airflow"?  Looks like it comes in the front, through the CPU coolers and out the back - I don't see anything he could have done differently.

Not to mention, if you look at "pro builders" on Youtube, those that dote over airflow will get the most miniscule of gains from tons of time spent.

[woox2k]

Hmm.. about minimum compression: remember that upload speeds are lower than download speeds. Also, Dave has pointed out that Australia isn't the best country in the world to get fast internet. On the other hand, Dave has an 8 mbit upload, which is decent and can do about 3 GB/hour.

He stated that he recompresses Vegas files with Handbrake before storing/uploading them. I was talking about minimizing compression in the Vegas, it should not really affect the output size of the Handbrake but would make the process a lot faster and better in quality.

[woox2k]

GET THE AIRFLOW RIGHT!!!!!!

This fan configuration he has is perfectly ok for the task, it's not like he's going to overclock those CPU's (even if he could, those Xeons have locked multipliers)

[allikat]

Don't change the heatsink configuration unless you absolutely have to.  Turn on a front fan.  It'll be fine.  If enough air is moving through the system, it won't be in contact with the heatsinks long enough to warm up much. 
A nice logical setup with airflow from front to back is good. Don't mess with it.  If you have any heat issues (which I doubt) then just add a few more intake fans to the case.  In tests, additional intakes (known as a positive pressure configuration) works better than extra exhaust.


Also: You do not need heatsinked memory. You only need heatsinks on memory for looks and/or if they're going to be over-volted. Since you're not going to overclock the system, just buy memory that will fit under your CPU heatsinks, with fast base clock numbers. IE DDR3-1333 (Aka PC3-10600) or higher. Don't worry about timing stats,

Intel chips like fast memory speed (AMD chips prefer fast cycle timings) for maximum speed.
Your software is the issue here Dave. It's not using your GPU correctly with either current AMD or Nvidia cards.  I think they may be buying into the bandwagon of requiring professional grade cards for video rendering (Nvidia's Quadro and AMD's FirePro). Nvidia for certain has cut the processing power of their consumer cards in half for the past few years, which will definitely have an impact on render performance.

I don't have any kind of sensible solution here, the only way to get more render performance involves going to a pro grade card, and one that will match or exceed your current consumer card will cost thousands.

Other thoughts: Supermicro make awesome dual CPU boards. Every dual chip board I've ever used (from Pentium 2 days onwards) has always been Supermicro, and they've been rock solid reliable.

[bktemp]

Talking about exporting, compressing video many times before uploading them to YouTube. Considering that you are only keeping the files outputted by Handbrake, i think it would make sense to export videos from Vegas with minimum compression. That would make the files a lot larger but if you're going to recompress them with handbrake anyway it should not matter. Exporting raw/minimal compressed videos from Vegas should be faster than compressing them as well.
Even though your videos look pretty good it's a bit odd to think that these files get compressed 4 times before i see them. (Camera > Vegas > Handbrake > Youtube)

Are there any good codecs for intermediate storage?
There are some lossless codecs but they have a bad compression ratio (only around 2-5 times smaller than uncompressed data). Using those the hard drive limits the speed.
H264 compresses well, but needs a lot more processing power. Is there a way in between? Since Handbrake is faster on the new machine, finding a better output format for Sony Movie Studio could solve all the problems.

[woox2k]

There are some lossless codecs but they have a bad compression ratio (only around 2-5 times smaller than uncompressed data). Using those the hard drive limits the speed.

Dave did buy 2 SSD drives, 1 for the OS and the other for rendering videos. He could use that render drive just to keep lossless files exported from Vegas before compressing them in Handbrake and later storing compressed videos on normal rotating (slow) drive.

[george graves]

Talking about exporting, compressing video many times before uploading them to YouTube. Considering that you are only keeping the files outputted by Handbrake, i think it would make sense to export videos from Vegas with minimum compression

I didn't watch the video all the way through, but he's exporting to a file, and then using handbrake? Is that correct?

[woox2k]

I didn't watch the video all the way through, but he's exporting to a file, and then using handbrake? Is that correct?

Yes

[dexters_lab]

Hmm.. about minimum compression: remember that upload speeds are lower than download speeds. Also, Dave has pointed out that Australia isn't the best country in the world to get fast internet. On the other hand, Dave has an 8 mbit upload, which is decent and can do about 3 GB/hour.

He stated that he recompresses Vegas files with Handbrake before storing/uploading them. I was talking about minimizing compression in the Vegas, it should not really affect the output size of the Handbrake but would make the process a lot faster and better in quality.

minimizing compression or outputting higher quality from vegas will increase render time

[EEVblog]

I am watching at SD 480 and like your previous video I still see blocky artifacts throughout the video. I do not see them at HD. Watch a 480 SD version Dave and I'm sure you too will see it. I have tried 3 machines Linux, XP Win7 all Firefox.
If you have recently changed something I suggest changing it back for your SD throwback viewers.

I simply upload a full HD version Youtube and it does the rest making the lower res versions, always has, always will. Youtube have been known to change and re-process the videos all the time. If it's just my videos doing this I'd be very surprised.

[EEVblog]

Since Handbrake is faster on the new machine, finding a better output format for Sony Movie Studio could solve all the problems.

If I had one I'd already be using it. I've tried many including frameserving and they had all had little issues that don't make them usable.

[EEVblog]

On the other hand, Dave has an 8 mbit upload, which is decent and can do about 3 GB/hour.

I have 20Mbit upload, but do have a monthly cap that could be an issue if I'm not careful.

[dexters_lab]

Dave, out of my own personal curiosity, would i be able to get a copy of the two source files and the project file for your test clip?

just wanted to compare rendering speed to my setup now i have the gpu working

[dexters_lab]

I am watching at SD 480 and like your previous video I still see blocky artifacts throughout the video. I do not see them at HD. Watch a 480 SD version Dave and I'm sure you too will see it. I have tried 3 machines Linux, XP Win7 all Firefox.
If you have recently changed something I suggest changing it back for your SD throwback viewers.

I simply upload a full HD version Youtube and it does the rest making the lower res versions, always has, always will. Youtube have been known to change and re-process the videos all the time. If it's just my videos doing this I'd be very surprised.

It is only the last two of yours I have noticed this on. If you haven't changed anything then I don't know what to suggest. No one else here has responded to confirm my experience is more widespread than just me. No-one did either on the LG TV teardown either. I'll do a bit more checking to see if it happens now on earlier videos.

I pasted a picture on that LG TV teardown thread and it shows a time  so that should make it simple for you to verify if you can reproduce  my report. Remember SD 480 not HD HD is fine. It is prevalent during the first minute too.

i have seen it too, but it's youtube. i believe they render as many as 16 different versions once it's uploaded

[max-bit]

Performance GPU :
Radeon R9 290 SP: 4,8 Tflops DP:  606 GFlops
Radeon HD 7970 SP: 3,8 Tflops DP:  950 GFlops
Radeon HD 7990 SP: 8,2 Tflops DP:  1,9 TFlops !!!

[george graves]

I didn't watch the video all the way through, but he's exporting to a file, and then using handbrake? Is that correct?

Yes

Eeek! Well there's your problem!  At least part of the problem.  Dave, no wonder why you are frustrated!

Why transcode twice? Plus handbrake is a consumer tool.  So is Sony Vegas "non-pro"  or what ever they call it(the pro version is ok - it does do non-standard video frames well- but that's not what we are talking about here). If I was video blogging for a living, I'd either live with some cheap software, or go towards a more professional set up.  After some 700 videos, you have to be getting sick of all these headaches. I honestly feel your pain.

I did a little test, and while running photoshop, a screen cap software, firefox with +40 tabs open(yea, I'm still on firefox - don't judge me), I imported a clip of your show, set the project as 1080p, 29.97.  And set it up for an export to encode.







I can export 1 min of video in 25 seconds.  And most of that is the overhead of the audio.  I can export an hour long show in about 6 mins.  (specs are 1080p, 29.97). It's not magic.  It's just a professional workflow.  QT references files, and such - it would be even faster if I had used Avid's AMA importer.

And before you say "oh, well that was just a simple clip"  here... a 3 camera talking head shoot,



That's a way more complicated timeline then you'll ever do on the EEVblog.

I can't help to notice that you keep complaining about not getting "pro" performance out of a "consumer" set up. After editing 700 videos, the learning curve to some new software should be minimal.  And with that, you can actually use a supported video card, and all that jazz.  And with that, you'll get a "pro" workflow.  Trust me...it's all about the work flow. And the right tools let you do that.

[dexters_lab]

Did you see it on the same two recent EEVBlog videos I reported, or on other non-EEVBlog YT videos?

no idea tbh, i dont pay that much attention to video glitches!

which ones did you report?

[Grapsus]

Dave, I might have an explanation for CPU2 slowness. This machine you built is a NUMA architecture. It's almost like two separate computers with a fast interconnect. Each CPU has it's own memory controller and its own RAM. When CPU2 tries to access CPU1 RAM it is significantly slower than when it accesses its own RAM. In a NUMA architecture the memory space is absolutely non-linear with respect to access time. That's why extra precaution must be taken in order to fully exploit such a machine. When a program or the OS is not aware of the non-linearities in memory space, performance can drop a lot.

I don't know how it works on windows, but on Linux you can set an affinity for certain CPUs and certain memory regions on NUMA architectures, it solves the problem when you have several processes sharing the resources. For a single process I don't think there is a way around it if the software is not aware of NUMA and doesn't schedule its threads and memory accesses in a certain way...

[Dany J.]

Hello everyone wanted to join the community since a long time, well now i did after this video i hope i can help everyone with my knowledge and learn from you guys, though i wish there is a proper introductions forum.

anyhow i just wanted to share with you my setup since now you got a True graphics card you can boost the rendering speed tremendously using OpenCl offcourse.

the main thing here is to use the MainConcept codec it may seem slow horrible but when an AMD card is around it's awesome. first of all make sure you install the latest Omega catalyst from AMD. Enter movie studio then go to "Options" "preferences" then select the "video" tab and make sure your graphic card can be selected in there, select it and restart movie studio.. now the real test is use the same video you used as a benchmark, choose the MainConcept AVC/AAC then internet video 1080p and customize it with these settings:

-res 1920x1080
-profile high
-framerate 50 (untick auto adjust)
-untick use deblocking filter
-choose constant bitrate (i recommend i MAX of 10Mbps, although you can choose whatever you like but youtube will compress it to max 5-6mbps)

go to system and click check gpu you should get OpenCL is available..( not GPU, not AMD, not Cuda)
and finally choose render using OpenCl if available.

Sorry for the details but honestly it's a pain to see my i5-3570k along with a radeon HD6950 perform wayyyyy better than a dual Xeon, R9-290 PC.

Dave you should see a huge boost for real, try it and let me know we should figure this out my machine isn't better than yours lol

[Fungus]

Dave: I'd seriously give Cyberlink PowerDirector a try instead of Sony...

I just rendered a 9 minute 22 second video video in 2 minutes 13 seconds on my Intel i5@3.5GHz, that's 4.2 times real-time speed.

Video was 1080p@25fps (to match my camera).

Yes, you render video at twice the frame rate but you also an have an i7 with twice as many cores as my i5, it should work out about the same. If you're currently rendering at 0.5 times real-time then you should end up 8 times faster than before.

------------------------------------------

Update: Just for a laugh I downloaded this entire 53 minute blog video and re-encoded it at 1080p@50fps. It took 15 minutes 52 seconds and my CPU usage was 50% the whole time - must only be using two cores (I had the 'Hardware encoder' option selected).

[firewalker]

Is necessary to export a re-encoded video from the editing software, since you are using a two step process?

Alexander.

[Fungus]

Is necessary to export a re-encoded video from the editing software, since you are using a two step process?

If he's adding overlays, then, yes...

[firewalker]

Can the program export to a "fast format" with minimum compression? Yes the file would be crazy big.

I never had to play around with so demanding formats, and lengthy videos.

Alexander.

[Towger]

Here we go. Here we go. Here we go...  They have come out of the woodwork with their comments on how mine is faster/better than yours.

Dave,

Time to run a competition. Upload the raw test clips and get them produce a video on how they edited them together and show how fast they rendered to them to the required formats/size.

[jazz]

Does the vfw Version of x264 not work with Movie Studio? http://sourceforge.net/projects/x264vfw/ (since that's basically what he's using to render it in the end anyway)
I'm guessing it either doesn't work, or there are other major downsides to using it? Sorry if it was mentioned elsewhere and I just missed it.

[dexters_lab]

Can the program export to a "fast format" with minimum compression? Yes the file would be crazy big.

I never had to play around with so demanding formats, and lengthy videos.

Alexander.

it can yes, but 'crazy big' would be a major understatement

just test rendered something on mine... 18Gb per minute of video

[Fungus]

Time to run a competition.

Maybe.

Dick-waving about hardware won't be very useful (nobody's going to buy a new machine) but software comparisons could be worthwhile. I chose PowerDirector after comparing it with Premiere Pro. Rendering speed was a big factor, plus it's a lot simpler to use for 'blog' type videos.

I'm guessing Dave really wants a super codec for Sony Movie but I'd say take a look at PowerDirector if you haven't tried it.

get them produce a video on how they edited them together

For PowerDirector:

1) Drop the clips in the 'bin' at top left
2) Drag them to the timeline, trim the head/tail of each one (if needed)
3) Right-click the audio and select "normalize track"
4) Go to the 'produce' screen, choose your compression preset, render it.

Optional steps (it only takes a few minutes so it's worth doing):
5) Load the output of step 4, extract the audio to a .wav file (right-click->"Extract audio")
6) Compress the dynamic range using Audacity.
7) Replace the audio in the video.
8 ) Render again - this step goes really fast because only the audio needs to be compressed (the software is smart enough to not recompress the video track if it matches the output format).

[mariush]

Dave, lots of suggestions and stuff here.

Did you consider to output the whole video as 59.94 fps instead of 50 fps when you're using two cameras?  It's probably easier to add a bunch of frames to make 60 frames out of 50, compared to dropping frames... you should check that out. Might decrease rendering time.

With this new machine, you should check again lossless codecs like Magicyuv : http://magicyuv.com/index.php/download/magicyuv for the initial rendering.  It's a heavily threaded codec, it would love those 12-24 cores and it would compress output fast but the downside is for a 1080p 60fps video, the bitrate of the output is probably going to be in the range of 80-100 mbps.  Don't matter, since you're going to recompress anyway, right? 

You just have to render to avi and select the codec for video and leave uncompressed audio and afterwards handbrake will recompress to h264 and aac or mp3 audio.  And you should disable the live preview window while rendering the video.
 

[v81]

Hi Forum, Hi Dave, DS1054z arrived today
My 1st scope
My 1st post

Saw a link to the forum whilst typing the below on youtube, thought i might be better here....


Seeing heaps of comments re "try plugging in the additional power connector".
It's not going to happen as the PSU involved does not have the connector, only comes in the 850W and higher models (check qty of EPS connectors in TechSpecs tab.
It might be a good idea to upgrade considering the workload involved should fully load both CPU's whilst in progress, hence why not make maximum power available?

I do understand your reasons for not using the GPU, thumbs up on that.

RE: Hyperthreading, it has no significant benefit in this scenario.
You will likely find it has no effect on the i7 if you turn it off there too.
It is fairly normal for the HT cores to not appear fully loaded in some cases.
Best practice when theorizing speed is to forget the HT exists and count using physical cores, IE your i7 has 4 x 3.xGHz, new rig has 12x2.6GHz

I think i can rustle up 8 sticks of near matched (2gig?)DDR3 memory, can confirm in the morning.
If you're interested in trying it let me know.

I think RAM + CPU power + SSD source&destination (i know you don't wanna hear it) along with some method tweaking will net you some excellent results.
Ultimately i think we should see all 12 cores fully utilized through every step where multi-threading could possibly be used.

If your hard disks are not the bottleneck at any point then i really believe you've yet to find the best method/codec to do this.

I think you are yet to see the best of this dual socket beast, don't give up on it yet.

You came across on the video as if to say "My way is the best way" and didn't sound too keen on hearing any opinions, but maybe consider that some of us actually are good at this kind of thing (but i promise i suck at engineering, 1st ever scope arrived today, i'll be watching your other vids to learn to use it!).

.....

Other things i'd try....

1)Try looking for bottle necks in Resource Monitor, i usually open it from the performance tab of task manager.
Check the various tabs, i would head straight to the Disk tab and see if any disks are near or at 100% Active time (blue line in graphs).

2)Rotate the CPU fans as you considered.
The thermal paste install method was A1 in my opinion if a little much in qty, but you mentioned that.

3)Fire up the intake fans to encourage fresh ambient air into the case.
If you'd like to cut back on fans then make it the exhaust fan, the warmer air will find its way out due to both convection + positive case pressure from intake fans (leave the top open).
The cpu fans will also encourage airflow in the right direction.
The intakes will also provide airflow to the PSU/GPU if/when needed, possibly stopping the GPU from ramping up its noisy fans (they are only quiet whilst they are slow!)

Please be kind, i'm new!

[fourier]

I've been interested in how much problems you've been having trying to get great performance out of your machines for what seems to be a relatively simple project.

Dave, is there any chance you can upload the 1 minute project test + rendered file and your encode settings somewhere? I really feel there's better ways to get faster performance out of your projects than just throwing massively overkill hardware at it, but I can only experiment if I have some test files to work from.

[andiz]

Hi everyone,
my first posting here. I was struggling for some time (no, not another forum, time consuming, etc.) but finally i decided to register and contribute to this nice forum. I think the benefits are much higher than being a passive reader.

@Dave:
Don't waste your money in getting faster RAM for your setup. It isn't worth at all, because in terms of video encoding (and 90% of all other workloads), the speed increase you can expect from faster memory than DDR3-1333 is 5%.

Have a look at:
http://www.anandtech.com/show/6372/memory-performance-16gb-ddr31333-to-ddr32400-on-ivy-bridge-igp-with-gskill/11

Tests from other reviewers lead to the same results so I think you can rely on that.


Greetings from Germany...

[v81]

.....Did you consider to output the whole video as 59.94 fps instead of 50 fps when you're using two cameras?  It's probably easier to add a bunch of frames to make 60 frames out of 50, compared to dropping frames... you should check that out. Might decrease rendering time....

Only theorizing here, but i'd have thought dropping frames would take less effort than creating frames?

[dexters_lab]

Does the vfw Version of x264 not work with Movie Studio? http://sourceforge.net/projects/x264vfw/ (since that's basically what he's using to render it in the end anyway)
I'm guessing it either doesn't work, or there are other major downsides to using it? Sorry if it was mentioned elsewhere and I just missed it.

it does work, quality of the output is good and more optimised like the output from handbrake, but vfw just makes things seem clunky... .avi files, separate audio codec needed

i tried it on mine but it was slower than the built-in codecs

[Corporate666]

Dick-waving about hardware won't be very useful (nobody's going to buy a new machine) but software comparisons could be worthwhile. I chose PowerDirector after comparing it with Premiere Pro. Rendering speed was a big factor, plus it's a lot simpler to use for 'blog' type videos.

I'm guessing Dave really wants a super codec for Sony Movie but I'd say take a look at PowerDirector if you haven't tried it.

Dave has already said he is not interested in switching software or dramatically changing his workflow.

Everyone has an idea of what he could do differently to speed things up, but many of the suggestions are just false (like "you need SSD's" or "you need more RAM!" or "It's your video card!").

Now it's even looking like the Xeon suggestion isn't working out either.

I do think the root cause of all this is Sony Vegas sucks... but if that's the constraint he's imposed on his workflow (which is completely reasonable, IMO), then any suggestions have to work within that.

[dexters_lab]

RE: Hyperthreading, it has no significant benefit in this scenario.
You will likely find it has no effect on the i7 if you turn it off there too.

really? on my i7 vegas is 30% slower rendering with HT turned off.

[dexters_lab]

I do think the root cause of all this is Sony Vegas sucks

you could be right there, i like the editor it's seem quick and powerful to me, it's just their output codecs seem  to let it down, if they could get the output quality and effeciency as good as the handbrake engine we wouldn't need to render it twice

[salviador]

Why not the new i7-5960x ??

[DanielS]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

[bktemp]

Maybe Dave could tweak the compression settings in Sony Vegas for more speed: In most H264 encoders it is possible to select between different levels of efforts the software takes to reduce the data rate. Using a faster setting gives a lower quality and a larger filesize, but since filesize does not matter because it gets recompressed afterwards using Handbrake the lower quality could be compensated by using a higher bitrate. I would also try using PCM instead of AAC as audio format.

[Corporate666]

I do think the root cause of all this is Sony Vegas sucks

you could be right there, i like the editor it's seem quick and powerful to me, it's just their output codecs seem  to let it down, if they could get the output quality and effeciency as good as the handbrake engine we wouldn't need to render it twice

When I was choosing software, I tried Vegas, Avid and PowerDirector.  I settled on PD as the one I liked best - I found Sony just to be awkward.  I actually find all these programs to be too geared towards the casual user and they try to dumb down their interfaces which makes for frustration for experienced PC users.

Having said that, didn't Dave say in one of his previous videos that someone from Sony had contacted him to say that some option or other shouldn't be grayed out and was going to look into it?  Anything ever come of that, Dave?

[TiN]

Just to be picky, don't count CPU cores with HT 3770K is 4core 8thread one, and 2630's are 6core12thread
Also it's best to use all blue slots on LGA2011, since it's quad channel platform. But to be honest, gain going from 2 channel to four is usually not much, you can add memory later.

I'd rather recommend looking into GPU-aided video editing software, since software which do processing on GPU (e.g. NVIDIA CUDA), as that is usually way faster than any CPU. Vegas seem to support GPGPU since version 11 Pro, but I am not sure exactly, as I had use only Adobe stuff for edit/encoding.

[v81]

RE: Hyperthreading, it has no significant benefit in this scenario.
You will likely find it has no effect on the i7 if you turn it off there too.

really? on my i7 vegas is 30% slower rendering with HT turned off.

Doesn't sound right, though i guess it depends on the encoder being used.
Most encoders show very little benefit from HT.

[Grapsus]

  the quantity of BS and ignorance I see in this thread is shocking. Before comparing carrots and oranges please take a look at the motherboard manual :

http://www.supermicro.com/products/motherboard/Xeon/C600/X9DAE.cfm

Now look page 1-10 "System block diagram", see how half of the memory is connected to CPU1, the other half to CPU2 and a bus called QPI between CPU1 and CPU2 ?

Then you should read about how this link between the CPUs works :

http://www.intel.com/content/dam/doc/white-paper/quick-path-interconnect-introduction-paper.pdf

How do you think it works when CPU2 is trying to access a location that is physically connected to CPU1 ? It has to send a request to CPU1 through QPI, CPU1 then decodes the request routes it  to its memory controller which fetches the data from the memory and the response is sent back through QPI. QPI is a complete networking protocol with routing, OSI layers etc. Add to this cache handling, resource sharing, contention. Therefore there is a performance penalty when a CPU tries to use a location that's not directly attached to it.

A single consumer CPU like a Core i7 has only one memory controller, it doesn't have this interconnect problem.

On the other side this dual processor Xeon with QPI is a server architecture whose aim is to go way beyond 128 GB of RAM. This architecture called NUMA is a trade-off in order to fit so much RAM in a single machine. The gain is memory quantity and the drawback is non-uniformity in access times. However on servers, the penalty is minimal. The typical workload is 100s of processes in parallel, each serving a separate client or a request. A NUMA-aware OS pins each task to a particular CPU and then allocates pages of memory attached to the same CPU. So a process scheduled like this only sees local memory and it's all nice.

This is all very well described even on wikipedia:

http://en.wikipedia.org/wiki/Non-uniform_memory_access

The benefits of NUMA are limited to particular workloads, notably on servers where the data are often associated strongly with certain tasks or users.

Imagine you try to run a task trying to take advantage of all the cores and all the memory at the same time, the OS will be forced to give away RAM from different physical CPUs to the same process. If the process is not aware that accessing location A from thread X is faster than from thread Y performance will be shit.

But how can you blame consumer video rendering software for not being aware of this server architecture ? This is nonsense.

The real solution is either to find a video software that explicitly supports non uniform access architectures or to find a way to share the workload among several separate processes. The later might be possible for video, with one process rendering the first half of the movie and another one rendering the second half.

[victor]

At this point, maybe you should get another camera that shoots at 60fps or another that shoots at 50fps and render without changing the frame rates (you said it a few times that this is the problem). I'm not sure if is viable money wise, but maybe it's you best option, if you doing this on the sole purpose of rendering speed.

Or maybe its time to look for another editing software and re-learn your workflow. Almost any editing software do the job you need, since you only need the basics, just trim and join clips looking at waveforms, and text overlay.

[DanielS]

really? on my i7 vegas is 30% slower rendering with HT turned off.

Doesn't sound right, though i guess it depends on the encoder being used.
Most encoders show very little benefit from HT.

Poorly written and threaded encoders scale poorly. Video transcoding is one of those algorithms that should scale quite well with processing power since the problem can be split into multiple mostly independent streams and stitched backed together. During the Handbrake/x264 part of Dave's benchmarks, Handbrake appeared to be doing a fairly good job at keeping all 24 threads busy.

With 24 threads in a dual-CPU NUMA configuration and only half the memory channels available on each socket, many things can go wrong unless the software has NUMA-aware optimizations, such as setting affinity for threads to specific CPUs and then making sure all the RAM they need comes from that CPU as much as possible, duplicate shared tables between CPUs, etc. to avoid snooping and data transfers over the QPI bus.

There are already tons of multi-threading performance gotchas under normal single-socket circumstances and I imagine many more than the few above come in when you add multi-socket NUMA in the equation.

[coppice]

EATX would be an odd size for a modern server board. Most follow the SSI forum outlines.

[Razor512]

The issues you are having with hyperthreading is due to how the OS manages the threads. Normally for proper use of hyperthreading, the OS will make sure that all physical cores are in use before a logical core is used, and the most demanding threads should never share a physical core unless there is no better alternative.
If the OS does not fully support this, then you end up with cases where 1 physical core is stuck having to handle 2 heavy threads while there are other available physical cores being underutilized.

A good example of this (while not intel), is the crappy AMD FX where they went with the core module crap. The core modules work better than hyperthreading as most of the processing hardware is duplicated, thus fewer components are shared. (hyperthreading shares all of the processing hardware of the core, but allows it to load up 2 threads thus all of the cores processing components can be better utilized)

http://www.extremetech.com/computing/138394-amds-fx-8350-analyzed-does-piledriver-deliver-where-bulldozer-fell-short/2

As you can see, if 2 threads fall on the same core module (thus some processing components are begin shared), then you get an overall drop in performance. If 1 core in each core module is disabled, then the overall performance of a 4 threaded workload increases. If all 8 cores are turned on, and the OS is left to decide which cores are used, then you get a non optimal use of the 4 threads, and some end up sharing a core module, and overall performance suffers.

The performance impact of 2 threads falling on the same core in a hyperthreaded environment is far higher since no processing components are duplicated, so the worst case scenario is an application not being able to fully use all of the physical and logical cores, and then mistakenly assigning 2 important threads to the same physical core.
Lucky for intel is they did not try to hide the fact that the logical cores were not true cores, thus it is easy to identify which is a physical core, and which is a logical core (provided they release updated drivers to properly inform the OS). On the AMD side, they did do the same, instead they count all of them as a full core, thus there are many cases where the FX chips are perform far slower than the Phenom II (older gen).

The Core i7 3770k is 4 physical cores, and 4 logical cores (which share all of the resources of the physical core, thus they only offer a benefit if there are parts of the core not being fully used)

On a side note, if you use adobe premiere pro, then 32GB will be the minimum that you need to fully use each core since it allocates memory for each core in order to make sure that you you do not run memory limits. (64GB is the bare minimum for 4K video)
Adobe premiere pro is designed around supporting a large number of cores, and is regularly used in dual and quad CPU environments.

[Razor512]

RE: Hyperthreading, it has no significant benefit in this scenario.
You will likely find it has no effect on the i7 if you turn it off there too.

really? on my i7 vegas is 30% slower rendering with HT turned off.

Hyperthreading on the 3rd and 4th gen intel CPU's offers a 20-30% performance boost on certain multithreaded workloads by allowing the physical core to be more fully utilized. There are some some workloads where it will lower performance (e.g., in some games (such as far cry 4 or second life).

Hyperthreading offers its full benefit pretty much only in video editing, and and software based 3D modeling (with lesser improvements in other workloads), provided the application is optimized for a hyperthreaded environment (e.g., adobe premiere pro will get a very good performance boost from it).

[eV1Te]

Does anyone have real life experience with other codecs for mastering and intermediate storage? I have used Avids DNxHD previously but I never benchmarked it and I never checked if it had good multithreaded performance.

The main conclusion from these tests are that Handbrake can utilize the 12 cores much better than Vegas built-in codecs. Hence the best thing is to move away from Vegas own codecs and use one that can handle 12 cores.

FYI: this motherboard has a 128 Gb/s QPI interconnect for the memory between the 2 cpu's, more than enough for this task.

[Grapsus]

FYI: this motherboard has a 128 Gb/s QPI interconnect for the memory between the 2 cpu's, more than enough for this task.

Yeah, sure, all subtle multi-processing issues boil down to bandwidth...  Like when one CPU screws the other CPU local cache (1ns latency) so it has to perform a new RAM access (200 ns).

[rodcastler]

And Dave keeps experimenting with our brains by adding the scope-flipping guy into these videos just in case anyone notices.... Well played Dave!

[FHR]

Hey Dave,

So to begin with: Hyperthreading IS SUPPORTED in Linux and Windows XP+! It would be stupid if Win 7 wouldn't support HT.
The second thing I noticed and cringed when you builded the PC: The memory configuration. You are mixing RDIMMs and UDIMMs. That just won't work (very well). The RDIMMs (or Registered ECC) are basically "the ones with many chips rotated in weird directions on them".
According to SuperMicro document: "* Mixing of Registered and Unbuffered DIMMs is not allowed. * Mixing of ECC and non-ECC is not allowed."

I think your main problem lies in software. The thing you are using for your video editing obviously wasn't designed to run on 12 threads, let alone 24 threads. That's why when you turned HT off it ran slightly faster. The handbrake was blazing fast, because it was designed to use multiple threads.

Sources:
Windows 7 hyperthreading http://www.informationweek.com/software/operating-systems/windows-7-boosts-hyper-threading-support/d/d-id/1079573?
Mixing UDIMMs, RDIMMs http://www.supermicro.com/support/resources/memory/X9_DP_memory_config.pdf

[eV1Te]

FYI: this motherboard has a 128 Gb/s QPI interconnect for the memory between the 2 cpu's, more than enough for this task.

Yeah, sure, all subtle multi-processing issues boil down to bandwidth...  Like when one CPU screws the other other CPU local cache (1ns latency) so it has to perform a new RAM access (200 ns).

Sure you are correct, there is much more to how bottlenecking occurs.

What I tried to say was simply that video encoding is not a memory-bandwidth intensive operation (about 300 MB/s if encoded in real-time for 50 fps full HD).

This was confirmed by the good performance seen in handbrake on the Xenon setup (more than twice as fast as the i7) which would otherwise bottleneck as well.

[Fungus]

if you use multiple edit sources eg: sample clips, old clips, sources from diff kinds of cameras, etc, you will find that VEGAS is more tolerant of being able to drop almost all kinds of clips into the edit window. PD cannot do that, or maybe i did not explore much when i tried it. but if you do try dropping all these onto the timeline and scrubbing, 25fps, 30fps, 30DF, 60DF, 50fps, etc ... some mobile phones shoot at 30fps + 1 frame (dont ask me why) and it seems vegas have a soft buffer that accomodates all these very well. in PD, once you select a frame rate/size, you have a hard time dropping in edit material which do not conform to its edit base frame size, esp weird size pictures

Never seen that but it wouldn't a problem for most people - everything is at 1080p.

It does warn you if the frame rate of a clip doesn't match the frame rate of your project (for video quality reasons I assume) but it's a preference that you can turn off.

[m100]

Not that I've done much of this before but if it is an acceptable configuration i'd take one of the processors out,  then reinstall W7 and the app from scratch and see what the video rendering performance is.  It could be quicker.    (added to save Dave the trouble!) 

[cbmuser]

the quantity of BS and ignorance I see in this thread is shocking. Before comparing carrots and oranges please take a look at the motherboard manual

And, yet, you are absolutely wrong. This is not a NUMA issue at all but a typical showcase of Hyperthreading having a negative impact on compute-intensive software. This is neither new nor unexpected unless you never worked in an HPC environment. The effect is observed quite often and even before Dave mentioned it in the video, my first thought was to disable Hyperthreading.

Hyperthreading can sometimes have negative impact in cases where all cores are already saturated by parallel tasks because it interferes with the scheduler of the operating system. We have seen similar problems on the SGI UV-1000 (512 cores, 1024 threads, 2 TiB RAM with external NUMAlink5): A process that was taking around 500 cores would run much slower when Hyperthreading was enabled since the scheduler of the kernel created a much higher overhead which was visible in a high system load. Simply disabling Hyperthreading on-the-fly through sysfs (echo 0 > /sys/devices/system/node/node*/cpu${cpu}/online) immediately resolved the issue and all cores were 100% user load. And the code that was used actually used numactl to specifically bind CPUs and memory to avoid NUMA performance impacts when accessing memory on a remote node.

Adrian

[FHR]

Video rendering is not HPC. HT is useful for video rendering. It's not like he's running Hadoop on his machine. But I agree that this has nothing to do with NUMA. It's badly designed software.

I have dual L5520 machine at home (HT ON) and I don't have any problems with "normal" software (Adobe AE, FFMpeg, Chrome, Mass Effect, Maya) running swiftly and without hiccups. I run linux, though AE refused to work so I have Win 7 on second SSD.

[warp_foo]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

I was going to post a similar comment. While I agree with Dave that you may not *need* a huge amount of RAM, filling in all of the RAM channels (and equivalent quantity of RAM per CPU...)  will be a win. 32GB using 8x 4GB DIMMs across both CPUs is probably reasonable. I doubt going from 1333 to 1600 will actually make a noticeable difference, but quad channel access will.

m

[Grapsus]

the quantity of BS and ignorance I see in this thread is shocking. Before comparing carrots and oranges please take a look at the motherboard manual

And, yet, you are absolutely wrong. This is not a NUMA issue at all but a typical showcase of Hyperthreading having a negative impact on compute-intensive software. This is neither new nor unexpected unless you never worked in an HPC environment. The effect is observed quite often and even before Dave mentioned it in the video, my first thought was to disable Hyperthreading.

Hyperthreading can sometimes have negative impact in cases where all cores are already saturated by parallel tasks because it interferes with the scheduler of the operating system. We have seen similar problems on the SGI UV-1000 (512 cores, 1024 threads, 2 TiB RAM with external NUMAlink5): A process that was taking around 500 cores would run much slower when Hyperthreading was enabled since the scheduler of the kernel created a much higher overhead which was visible in a high system load. Simply disabling Hyperthreading on-the-fly through sysfs (echo 0 > /sys/devices/system/node/node*/cpu${cpu}/online) immediately resolved the issue and all cores were 100% user load. And the code that was used actually used numactl to specifically bind CPUs and memory to avoid NUMA performance impacts when accessing memory on a remote node.

Adrian

First, I never said that HT wasn't a problem. I demonstrated why it was foolish to compare the number of cores and the amount of RAM between a single CPU and a NUMA architecture and also that is was equally foolish to state that some software sucks because it can't fully take advantage of such a machine all by itself.

Second, where do you actually provide facts to prove that the problem is HT only and not NUMA or HT+NUMA ? Bro, that's so cool you worked in HPC environment where HT was a problem on a totally different workload, good for you.

[FHR]

And yet the software "sucks". It can't use that many threads.  It wasn't designed to run on that many threads (the "640kB of RAM would be enough for everyone" approach?). Even if the software was NUMA-optimized, there is no guarantee it will provide better performance.

[elgonzo]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

I was going to post a similar comment. While I agree with Dave that you may not *need* a huge amount of RAM, filling in all of the RAM channels (and equivalent quantity of RAM per CPU...)  will be a win. 32GB using 8x 4GB DIMMs across both CPUs is probably reasonable. I doubt going from 1333 to 1600 will actually make a noticeable difference, but quad channel access will.

m

While i would not speak about a massive bottleneck, allowing the CPU to utilize all 4 memory channels (4 or 8 DIMMs per CPU) will provide some performance gain (around the 10% mark, i speculate), which is going to be a better performance improvement than swapping the two existing DIMMs per CPU with two faster DIMMs.

By the way, Dave has 3 DIMMs of each kind. He could actually use all of them (3 DIMMs per CPU), which would allow the CPUs to interleave accross 3 memory channels. While not as fast as 4-channel interleave, it would still be a little faster than just 2-channel interleave. So, why did Dave not use all the DIMMs he already has?

[warp_foo]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

I was going to post a similar comment. While I agree with Dave that you may not *need* a huge amount of RAM, filling in all of the RAM channels (and equivalent quantity of RAM per CPU...)  will be a win. 32GB using 8x 4GB DIMMs across both CPUs is probably reasonable. I doubt going from 1333 to 1600 will actually make a noticeable difference, but quad channel access will.

m

While i would not speak about a massive bottleneck, allowing the CPU to utilize all 4 memory channels (4 or 8 DIMMs per CPU) will provide some performance gain (around the 10% mark, i guess), which is more than just keep running with two faster DIMMs.

By the way, Dave has 3 DIMMs of each kind. He could actually use all of them (3 DIMMs per CPU), which would allow the CPUs to interleave accross 3 memory channels. While not as fast as 4-channel interleave, it would still be a little faster than just 2-channel interleave. So, why did Dave not use all the DIMMs he already has?

I don't think this is correct, three channel RAM went out with the X58 chipset. The E5 Xeon is quad channel, so populating all of the blue or black DIMM slots would be appropriate. Intel's website does say a 'maximum' of four channels, but all of the data I've dug up suggests the C604 chipset works best with quad channels.

YMMV...

m

[Skimask]

Look at all the anecdotal evidence and sample sizes of one!
Overall, a highly educated crowd 

[elgonzo]

I don't think this is correct, three channel RAM went out with the X58 chipset.

The chipset does not contain the memory controller anymore. The memory controller is integrated in the CPU.
And the Xeon E5-26xx v2 family (Ivy Bridge-based) does indeed support interleaving memory accesses across 3 channels. read here page 16 and following; (The linked PDF is from Fujitsu, but other server/workstation vendors will likely also have similar documentation. Note that for dual CPU configurations, using 3 channels per CPU is also sometimes called "6 channels"; HP uses/d this nomenclature, for example).

(Side note: 3-way interleave is not possible with the 12-core CPU family members. Since those CPUs have two memory controllers, you will always end up with an even number of channels for interleaving...)

The E5 Xeon is quad channel, so populating all of the blue or black DIMM slots would be appropriate. Intel's website does say a 'maximum' of four channels, but all of the data I've dug up suggests the C604 chipset works best with quad channels.

As said before, the memory controller is inside the CPU. The C602/C604 chipset has nothing to do with memory...
Anyway, of course using all 4 memory channels works best. But that was not my point. The point was that Dave has already three of the 8GB DIMMs and three of the 4 GB DIMMs. So why did he only use two of each type?

(There might be a hypothetical chance that the SuperMicro BIOS blocks such configurations - i don't know-, but what would be the purpose of such?) EDIT: As expected, the BIOS of the SuperMicro board does indeed support interleaving across 3 channels. From the board manual, page 4-13: "This feature selects from the different channel interleaving methods. The options are: Auto, 1 Way, 2 Way, 3 Way, and 4 Way."...

[plexus]

It could be your Sony software. one benefit of software aimed at pros is a focus on performance. not always, granted. but I would suspect the Sony software because Handbrake is >2x as fast. That is a clue that the machine is working to performance but the Sony software is not taking advantage of it. I am not a coder but from what I understand the software has to be coded to take advantage of CPU efficiencies and options. For $40US can you sign up for month with Adobe CC and download and try the latest version of Premiere. it would be worth it just to trouble shoot.

[barnacle2k]

Like many in this thread already suggested:


Change your video encoding process, export uncompressed or lightly compressed (mpeg2) from your editing software and then shove the result into handbrake.
Yes that intermediate file will be absolutely humongous but you can delete it immediately after the handbrake pass is through.
That file should go onto an ssd because of the high datarate (100mbps+).

One thing on the pc build:
The GPU power cable looked not fully plugged into the power supply (they take a LOT of force to get right).

[elgonzo]

@barnacle2k, thank you for making sure that also people who broke their glasses or misplaced their contact lenses are able to read your post...

[true]

Why use one SSD for OS and the other for video? This is an offline render rig. Stripe the SSDs and use along with uncompressed / light compressed export from Vegas.

If the export is still slow, blame Vegas.

(But, from the video, there are other PEBKAC-type issues...)

[Armxnian]

Some quick tips:

1. Connect the 2nd cpu 8pin... it doesn't actually draw more power unless it is needed. The motherboards for 6 core processors all have an 8 pin 12v header, so why would you think two 6 cores don't require 2 connectors?

2. ECC ram is useless for video encoding/rendering, and is slower than non-ecc ram as it has to detect potential data corruption. 1333mhz is also bottom of the range for ddr3.

3. x264 can use as many processors/cores/threads as the OS supports. The Sony application itself isn't what needs to support x amount of cores, it's the codec itself. You will find some are single threaded, others can use as much as you have. All professional codecs should support 24 threads.

I never really understood your choice for 60/50fps Dave. Yeah people say they like it, but that's compared to 25fps. Why not invest in a 4k camera? Youtube 4k isn't the best right now but it still looks better than 1080p, and will only improve. I don't see the point of 50/60fps for electronic videos, where you're staring at something that isn't moving.

[muffenme]

The real reason is that Hyper-Threading may be Killing your Parallel Performance.  http://www.pugetsystems.com/blog/2014/07/02/Hyper-Threading-may-be-Killing-your-Parallel-Performance-578/ Dr Donald Kinghorn wrote about the problem with Hyper-Threading.

[EEVblog]

So, why did Dave not use all the DIMMs he already has?

Because the manual told me not to do that.

[true]

1. Connect the 2nd cpu 8pin... it doesn't actually draw more power unless it is needed. The motherboards for 6 core processors all have an 8 pin 12v header, so why would you think two 6 cores don't require 2 connectors?

Why would you think it does? It works. Dave isn't a computer guy, he's an electronics guy. I am sure the CPU and memory controller won't be burdened with his CPU choice and one connection is fine.

2. ECC ram is useless for video encoding/rendering, and is slower than non-ecc ram as it has to detect potential data corruption. 1333mhz is also bottom of the range for ddr3.

Not sure you understand how memory works. For his use case, any RAM performance difference between different types or speeds of modules for his RAM channel count is almost non-existent. Likewise, 1333MHz vs 1600MHz vs faster won't make much of a difference for his use case. As stated before, using more RAM channels may improve performance.

3. x264 can use as many processors/cores/threads as the OS supports. The Sony application itself isn't what needs to support x amount of cores, it's the codec itself. You will find some are single threaded, others can use as much as you have. All professional codecs should support 24 threads.

Codec support is likely limited by Vegas. I haven't used Vegas in some time - if there is a way to use x264 encoder through Vegas export that might be easiest for Dave but really he should be exporting to an uncompressed or lightly compressed output to fast storage and transcoding that. OR see Bud's post below regarding using a frameserver and tools Dave is already familiar with.

I never really understood your choice for 60/50fps Dave. Yeah people say they like it, but that's compared to 25fps. Why not invest in a 4k camera? ...

...uh

[rs20]

I never really understood your choice for 60/50fps Dave. Yeah people say they like it, but that's compared to 25fps.

Um, yeah.... what frame rate are you suggesting?

Why not invest in a 4k camera? Youtube 4k isn't the best right now but it still looks better than 1080p, and will only improve. I don't see the point of 50/60fps for electronic videos, where you're staring at something that isn't moving.

Most people's monitors are barely in excess of Full HD right now, and in any case 4k would put huge demands on your optics (both the camera and the end-viewer) and offer no advantage to anyone sitting more than 30cm from the screen. In summary, 4k makes no sense, 50 fps is beautiful. Also, Dave moves quite a lot.

[Bud]

Lots of great advices here, so i feel obligated to give one, too:

Dave should alltogether skip rendering step in Vegas and stream straight to Handbrake via a frameserver.

http://www.vegasvideo.de/vegas-2-handbrake-en.html

Edit: sorry mean Encoding step

[true]

So, why did Dave not use all the DIMMs he already has?

Because the manual told me not to do that.

The manual also told you to use the same size and type throughout the system "for best performance" but you aren't doing that either. But it did _not_ say you could not do this.

Use motherboard manuals for advice, not stringent guidelines. Same for any modern PC hardware. What is supported and what works fine are different things. In fact, for your configuration the manual section 2-4 explicitly identifies a 2 CPU + 6 DIMM loadout. I understand your DIMMs are different brands and sizes but this mixing, even though not ideal, should still work. All of your memory is registered ECC. The recommendation from Supermicro in the manual is sound (4 DIMM in CPU1, 2 DIMM in CPU2) and may make more sense than the one stated in this forum (3 DIMM in each) but your software is the limitation so both are worth trying out. There is no risk of frying things by trying.

To reiterate, 3-channel mode should work. 4ch in CPU1 and 2ch in CPU2 is recommended by SuperMicro. You can mix modules. If it doesn't work or shows no improvement, you can remove the RAM.

[rs20]

Lots of great advices here, so i feel obligated to give one, too:

Dave should alltogether skip rendering step in Vegas and stream straight to Handbrake via a frameserver.

http://www.vegasvideo.de/vegas-2-handbrake-en.html

Edit: sorry mean Encoding step

Your message made me wonder... why is everyone assuming that the codecs are to blame*? The evidence in Dave's video shows the CPU utilization dropping when the video transitions from requiring 60 --> 50 translation to just compressing 50 fps. How does the codec even know what the input file frame rate is, let alone have its performance be affected by it? Observed behaviour seems consistent with the rendering step being limited to having, say, 8 frames in flight at a time, leaving the codec starved of input.

                    +-----------+                  +-------+         
  50/60 fps frames  |           |   50fps frames   |       |         
+-----------------> | Rendering | +--------------> | Codec | +------>
                    |           |                  |       |         
                    +-----------+                  +-------+         

A frameserver may be a neat way to test this theory, because I assume that you can tell frameserver to just dump the frames to /dev/null, if you do this and the "rendering" still takes ages and has CPU utilisation all over the place, then we've found our culprit: the video editing software isn't rendering (as opposed to encoding/compressing) enough frames in parallel.

* Disclaimer: I haven't really been reading these threads, so it's probably false that everyone is assuming this.

[george graves]

Yes.  Frameservers are another option.  I've done that in the past.  But it's kinda of a PITA.  More professional software will allow you to send a project to the encoding software - either directly, or via a quicktime reference file (as I already showed in this thread).  Export and then encode for youtube is a waist of time.

[Armxnian]

1. Connect the 2nd cpu 8pin... it doesn't actually draw more power unless it is needed. The motherboards for 6 core processors all have an 8 pin 12v header, so why would you think two 6 cores don't require 2 connectors?

Why would you think it does? It works. Dave isn't a computer guy, he's an electronics guy. I am sure the CPU and memory controller won't be burdened with his CPU choice and one connection is fine.

2. ECC ram is useless for video encoding/rendering, and is slower than non-ecc ram as it has to detect potential data corruption. 1333mhz is also bottom of the range for ddr3.

Not sure you understand how memory works. For his use case, any RAM performance difference between different types or speeds of modules for his RAM channel count is almost non-existent. Likewise, 1333MHz vs 1600MHz vs faster won't make much of a difference for his use case. As stated before, using more RAM channels may improve performance.

3. x264 can use as many processors/cores/threads as the OS supports. The Sony application itself isn't what needs to support x amount of cores, it's the codec itself. You will find some are single threaded, others can use as much as you have. All professional codecs should support 24 threads.

Codec support is likely limited by Vegas. I haven't used Vegas in some time - if there is a way to use x264 encoder through Vegas export that might be easiest for Dave but really he should be exporting to an uncompressed or lightly compressed output to fast storage and transcoding that. OR see Bud's post below regarding using a frameserver and tools Dave is already familiar with.

I never really understood your choice for 60/50fps Dave. Yeah people say they like it, but that's compared to 25fps. Why not invest in a 4k camera? ...

...uh

His two processors draw 80w each, I thought it was more towards 140w for each, so never mind on that point.

He seemed happy for a 20% gain. Non ecc and faster memory can improve performance, not dramatically, but it can.

As for uncompressed, you need to test it. x264 might be faster since it does not have to decode the stream but it has more data to process. You can also try just using a lower bitrate straight out of Sony and not encoding a 2nd time. I doubt the quality of Sony's codec at low bitrates though.

I never really understood your choice for 60/50fps Dave. Yeah people say they like it, but that's compared to 25fps.

Um, yeah.... what frame rate are you suggesting?

Why not invest in a 4k camera? Youtube 4k isn't the best right now but it still looks better than 1080p, and will only improve. I don't see the point of 50/60fps for electronic videos, where you're staring at something that isn't moving.

Most people's monitors are barely in excess of Full HD right now, and in any case 4k would put huge demands on your optics (both the camera and the end-viewer) and offer no advantage to anyone sitting more than 30cm from the screen. In summary, 4k makes no sense, 50 fps is beautiful. Also, Dave moves quite a lot.

I'm suggesting 25/30fps at 4k. You don't need a 4k monitor to get increased quality. 4k downsampled to 1080p is going to look better than 1080p.

30cm? Where did you pull that figure out of? Did you forget to factor in screen size, eye sight, and overall subjective bias? I wear glasses and sit 2ft. away from my monitor and can notice the difference of 4k vs 1080p on a 1080p monitor. The difference is more on native 4k.

In summary, 50fps makes no sense. You are staring at a board of test instrument for 95% of the video. The only thing moving is Dave's hand when he points at things. Huge demands on your optics? You don't have to watch it at 4k, 1080 will be available. 50fps is a waste of bandwidth if you really want to get picky about network strain. 4k monitors are getting relatively cheap and more are adapting, no point in getting comfy with high frame rate with eevblog type content.

[EEVblog]

1. Connect the 2nd cpu 8pin... it doesn't actually draw more power unless it is needed. The motherboards for 6 core processors all have an 8 pin 12v header, so why would you think two 6 cores don't require 2 connectors?

I don't have a 2nd cable.

[EEVblog]

Or maybe its time to look for another editing software and re-learn your workflow. Almost any editing software do the job you need, since you only need the basics, just trim and join clips looking at waveforms, and text overlay.

What makes you think I haven't.
In fact I have, many times, and I have not always used Sony.
I've tried every package that everyone has suggested, including the high end professional ones everyone swears by, and they ALL have issues in some way that have caused me not to take them up beyond the sometimes one trial video
I have downloaded the latest Cyberlink power director to try (again, have tried it years ago, it was not suitable) as it now promises lighting speed and several have testified to that.

[EEVblog]

In summary, 50fps makes no sense.

Ok, I'll just switch to the 25/30fps 4K cameras I have.
Oh, that's right, I don't have 4K cameras 

[Armxnian]

In summary, 50fps makes no sense.

Ok, I'll just switch to the 25/30fps 4K cameras I have.
Oh, that's right, I don't have 4K cameras 

I said think about it for a future investment. No one "needs" 4k, you provide high resolution images of teardowns. At the same time, no one "needs" 50fps when looking at a non moving object on a non moving camera. It's not like you magically miss out on information on a whiteboard if you watch it in 25fps. I'm simply stating the fact that for optimal quality, higher resolution > higher frame rate for your style and content. Those who say there is no noticeable difference in image quality in 1080 vs 4k are the same who said there is no difference in 720 vs 1080 and 480 vs 720 a few years ago. If there is no difference, an entire industry wouldn't make the jump as the technology becomes available.

You've mentioned often that more content and higher quality content = more success. You went from 4x real time to 1/3rd real time. If it actually effects the amount of content you put out it's not worth it. 4k could be worth it.

[Dr. Frank]

Dave,

I really enjoyed your video, just sitting in front of my self assembled, downgraded 20W  µATX / E350 PC..which barely manages to display this nice video in HD.

That Xeon machine is a really wonderful big beast.. and I also can understand your disappointment.. encountered that also quite often..

Good luck in finding the tin-opener for appropriate performance!

Frank

[Stonent]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

Would also probably be best that each CPU has an identical memory configuration to the other.  I think the Dell Precision Workstations with Xeon cpus will warn you if your memory layout is not optimal at start-up.

[Psi]

I was very surprised the OS actually booted when moved from a generic single CPU machine to a radically different server grade motherboard with dual cpu and totally different bios.

Usually the windows kernel/reg settings are fixed at install time for your chipset (AMD vs Intel) and your multiprocessor architecture.

There's so many things that could have caused a BSOD doing that i am amazed it actually worked.
I've done it before myself but i've only had luck when the computers were similar.

[EEVblog]

I said think about it for a future investment. No one "needs" 4k, you provide high resolution images of teardowns. At the same time, no one "needs" 50fps when looking at a non moving object on a non moving camera.

Sure, but:
a) Countless people have commented on the excellent quality of the 50fps footage. Who are you or anyone else to tell them that they don't need it? trust me, if hardly anyone saw the difference or didn't mention it then I wouldn't bother doing it. But they do, and I've been inundated with people saying they love it, so I've kept doing it.

b) I can do 50fps now with the gear I have invested in, which is why I am doing it. It doesn't cost me anything except render time. 4K on the other hand is a massive investment in all new cameras (multiple), all new workflows (so was 50fps, but not in new camera workflow, just rendering), almost certainly a much higher bitrate than I'm running now (greatly increases my expense and effort for raw footage backup), perhaps new 4K monitors to match, etc.

It's not like you magically miss out on information on a whiteboard if you watch it in 25fps. I'm simply stating the fact that for optimal quality, higher resolution > higher frame rate for your style and content.

I do not disagree at all.

Those who say there is no noticeable difference in image quality in 1080 vs 4k are the same who said there is no difference in 720 vs 1080 and 480 vs 720 a few years ago. If there is no difference, an entire industry wouldn't make the jump as the technology becomes available.

I have been considering moving to 4K for while now, but was disappointed in the camera releases at the CES in Jan, so did not make the switch.

If it actually effects the amount of content you put out it's not worth it.

It doesn't really, it's just rendering time. Screws up getting videos to market quickly, e.g. Shooting Mailbag on Monday and releasing it on a Monday, but apart from that, no.
BTW, the great thing about Sony Moviestudio/Vegas is that I can (and sometimes do) run more than one instance at once. e.g. I can be editing another video while the previous one is rendering. I think I once tweeted a photo of me with 3 instances running at once for something I was doing.

[EEVblog]

UPDATE:
1) 3 DIMM's does work. Not any faster

2) Hyperthreading is confirmed slower with Handbrake

3) Direct uncompressed output using the Sony YUV Video For Windows codec actually works (it had issues on my old machine)
1:46 for the 1min test video which is pretty good and the fastest yet. That was to the SSD. File size was 12.163GB for the 1 min, so that means a 1 hour video would need 730GB.
Such an output would need about 114MB/s write speed, so that makes a 7200 rpm drive a WD Black suitable. 1GB+ of SSD would of course be very expensive and of no improvement.
So this seems like the best solution for now.
I might try some of the other VFW codecs again, but I've been advised by top people close to the metal that the Sony CODEC is pretty darn good at this.

4) x264vfw still does not work. Major problems with output file audio/video sync. But FYI, render time was 2:27 for the 1min video. For those not aware, x264vfw is essentially directly streamaing the output from Sony to handbrake (which uses the x264 codec as well)

[bktemp]

3) Direct uncompressed output using the Sony YUV Video For Windows codec actually works (it had issues on my old machine)
1:46 for the 1min test video which is pretty good and the fastest yet. That was to the SSD. File size was 12.163GB for the 1 min, so that means a 1 hour video would need 730GB.
Such an output would need about 114MB/s write speed, so that makes a 7200 rpm drive a WD Black suitable. 1GB+ of SSD would of course be very expensive and of no improvement.
So this seems like the best solution for now.
I might try some of the other VFW codecs again, but I've been advised by top people close to the metal that the Sony CODEC is pretty darn good at this.

You could try the Lagarith Lossless Video Codec. It probably compresses a bit better and is quite fast.
http://lags.leetcode.net/codec.html

[rs20]

3) Direct uncompressed output using the Sony YUV Video For Windows codec actually works (it had issues on my old machine)...

Purely out of curiosity, how did CPU usage trend using this codec? Are the CPUs still starved when going from 50fps to 50fps?

[EEVblog]

Purely out of curiosity, how did CPU usage trend using this codec? Are the CPUs still starved when going from 50fps to 50fps?

Yes, they are, very little use, so it basically seems to become primarily an I/O issue when doing it this way. Although I'm sure the CPU and memory width helps also.
Full pelt CPU at 60fps to 50fps.
I just realised the source video material was coming from a slow 5400 hard drive, so not sure if that impacts that or whether or not the clips were already in memory or however it works.
Also, in this case the drives should be put on the two SATA3 ports. Currently on the SATA2 ports I think.

[EEVblog]

And it seems no one noticed that I plugged the video card into a PCIEx16 slot going to the 2nd CPU 
I have no idea what bottleneck that adds in practice, but it won't help.

[EEVblog]

Non ecc and faster memory can improve performance, not dramatically, but it can.

Seems not:
http://www.techspot.com/article/845-ddr3-ram-vs-ecc-memory/

And someone pointed out the E5-2630v2 does not support faster than 1333MHz memory, but that seems to be incorrect:
http://ark.intel.com/products/75790/Intel-Xeon-Processor-E5-2630-v2-15M-Cache-2_60-GHz
It can support up to 1600Mhz it seems.

[Psi]

could try going to huffyuv codec (multithreaded version) in Sony and then huffyuv to h264 in handbrake

Huffyuv is compressed but lossless. Files are large but realistic for a intermediate step.

Im not sure how the multithreaded performance of huffyuv compares to other codecs.

[Ed.Kloonk]

And it seems no one noticed that I plugged the video card into a PCIEx16 slot going to the 2nd CPU 
I have no idea what bottleneck that adds in practice, but it won't help.

Wondering if that's why the Sony Software baulked when you transplanted the system. Some kind of inumeration mismatch. Hardly matters now tho...

[Fungus]

I said think about it for a future investment. No one "needs" 4k, you provide high resolution images of teardowns.

Right now the 4k cameras are still in the 'early adopter' price range, ie. too expensive.

Those who say there is no noticeable difference in image quality in 1080 vs 4k are the same who said there is no difference in 720 vs 1080 and 480 vs 720 a few years ago. If there is no difference, an entire industry wouldn't make the jump as the technology becomes available.

The 'industry' will jump as a marketing move - to sell new TVs. They'll advertise and pay for TV presenters/celebrities to casually mention how amazing their new TV is, even though they probably got theirs for free, it was the top-of-the-line model, and they probably don't even know what to look for in a TV image.

Plus: As soon as manufacturing costs go down to the same price level as the old ones, all the stores will stop selling the old stuff. All you'll be able to buy is 4k (or whatever) whether it's noticeably better or not.

In short: The industry 'jumping' doesn't tell you anything about the quality of a product. The difference to the consumer might be very small.

If you watch movies from 10 feet away on a 100" TV then of course 4k is going to look much better than 1080p. On a 24" panel? Not so much...

[mariush]

3) Direct uncompressed output using the Sony YUV Video For Windows codec actually works (it had issues on my old machine)
1:46 for the 1min test video which is pretty good and the fastest yet. That was to the SSD. File size was 12.163GB for the 1 min, so that means a 1 hour video would need 730GB.
Such an output would need about 114MB/s write speed, so that makes a 7200 rpm drive a WD Black suitable. 1GB+ of SSD would of course be very expensive and of no improvement.
So this seems like the best solution for now.
I might try some of the other VFW codecs again, but I've been advised by top people close to the metal that the Sony CODEC is pretty darn good at this.

You could try the Lagarith Lossless Video Codec. It probably compresses a bit better and is quite fast.
http://lags.leetcode.net/codec.html

MagicYUV is much faster and often compresses better (but depends on content)

ps.  I don't like Google Chrome and I'm too used to Firefox to use something else, so I'm stuck with 25 fps. 50fps is not that big of an improvement to make me switch to Chrome just to watch the videos.
 
4k would work on any browser and would be a nice thing especially for pcb closeups or similar things. It would take more disk space (as 4k cameras i saw record at 60-100mbps) to back up stuff but for most of your videos about 20 mbps for final render would be enough (since there's not much motion and so on). But hard drives are relatively cheap.

I don't think about it from the viewpoint "people have 1080p monitors or lower", i think of the large sensors in 4k cameras and the sharpness, fine detail etc compared to regular hd cameras, it would help for some of your videos.

[Fungus]

I have downloaded the latest Cyberlink power director to try (again, have tried it years ago, it was not suitable) as it now promises lighting speed and several have testified to that.

There might be a new version or two since then (I'm new to video editing).

I'm not going to claim Power Director is perfect. There's definitely a lack of "power user" options for engineers to fiddle with but if you relax and trust it, it seems to do the job.

It needs two things to make it perfect for blog-videos IMHO:
a) Better audio handling in the 'trim' tool - I want to see the audio and hear it when I move the scrubber.
b) A dynamic range compressor on the Audio track. The 'normalize track' tool works great but it's conservative with the level, I want a bit more volume.

I can live with (a) and I do (b) as a separate step (it's easy to do...)

I haven't tried Sony, I started out with Premiere Pro ("PP").

PP never gave me the impression that it was for casual users or people who aren't being paid by the hour. Everything was long and involved, with endless options. PD is much simpler.

Things that really killed Premiere Pro for me:
a) No way to match the audio levels across all the clips. Audio mixing is a lot of manual work in PP.
b) No way to remove a clip from the timeline and have it close the gap automatically. WTF?!! Similarly for inserting/replacing clips. You're screwed if you want make changes in the middle of the timeline.

nb. This was on PP CS6 so (b) might be fixed. I googled long and hard for an answer to (a) but there's nothing.

[Fungus]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

Would also probably be best that each CPU has an identical memory configuration to the other.  I think the Dell Precision Workstations with Xeon cpus will warn you if your memory layout is not optimal at start-up.

Why? Each CPU has it's own memory controller. What difference would it make?

People going on and on about RAM are barking up the wrong tree IMHO.

Workstation RAM is expensive. At best you'll only shift the bottleneck somewhere else. Fiddling with the RAM certainly won't get you the 200-300% speed increase implied by all those CPUs.

I'd say the problem is with the software, not the hardware. Dave needs a better codec for Sony or a different video editor.

[EEVblog]

Wondering if that's why the Sony Software baulked when you transplanted the system. Some kind of inumeration mismatch.

Yes, could very well be. Have done it before and it's worked

[EEVblog]

Why? Each CPU has it's own memory controller. What difference would it make?
People going on and on about RAM are barking up the wrong tree IMHO.

I think the 4 channel thing has merit, I at least want to fill all 4 slots on each CPU.

Workstation RAM is expensive. At best you'll only shift the bottleneck somewhere else. Fiddling with the RAM certainly won't get you the 200-300% speed increase implied by all those CPUs.

Agreed. I don't expect a big improvement.
Anyway someone is kindly donating some.

[george graves]

I'm not going to claim Power Director is perfect.

It needs two things to make it perfect for blog-videos IMHO:
a) Better audio handling in the 'trim' tool - I want to see the audio and hear it when I move the scrubber.
b) A dynamic range compressor on the Audio track. The 'normalize track' tool works great but it's conservative with the level, I want a bit more volume.

a) No way to match the audio levels across all the clips. Audio mixing is a lot of manual work in PP.
b) No way to remove a clip from the timeline and have it close the gap automatically. WTF?!! Similarly for inserting/replacing clips. You're screwed if you want make changes in the middle of the timeline.

Trading one consumer software for another isn't going to help.  If you want pro rendering times, you need pro software - and a set up to match.  I've said it already.  And yes, as mentioned...let me highlight this....every piece of editing software has it upside and down sides. As a professional editor, I've edited on Media 100's, Avid, Premiere, Sony Vegas Pro, Xpress, Xpress DV.  Heck I started in tape to tape.  My first "edit" was on a set of sony 3/4" Umatic VTRs. One of the traps is, that if you get use to one piece of software, and then try to move to the other, your knee jerk reaction will be "Why is the heck can't I do XYZ that I use to be able to do so easily!!!"  You quickly get over it, and learn the "real" way of doing things.  In the end it's much better. 

A few things.

- "normalizing" audio is like using a hammer on top of someone's head to say hello.  A graphic compressor/limiter is much better.
-  I'm not a huge fan of premiere pro - but the latest version is awesome - and it's only like $30 a month.  And it's not hard at all to learn.  If you can learn eagle cad, PP is super easy.
- yes even PP has fit to fill, over wright, JKL trimming, and most importantly, 3 point editing (3 point editing is where you supply 3 of 4 parts, IN, OUT of both the source and record - it'll calculate the other.)  (My guess is that almost no-one in this thread even knows what JKL trimming is.)
- 4K for a talking head video?    Yea, enjoy those render times.

Things we learned in this tread:  Someone is having fun building a PC and learning about the world of video. And he likes to re-encode his encodes.

[adam1213]

Adding more CPUs can result in contention for shared resources e.g. memory. This can result in worse performance.

note: It may be something else impacting performance.

[Dany J.]

dave did you even try my method?? man my HD6950 is rendering at double the real-time speed on exactly the same setting you made your videos, if it didn't work then pretty sure you have your setup wrong, IT IS IMPOSSIBLE TO NOT GET HUGE BOOST USING AN R9-290

[EEVblog]

4k would work on any browser and would be a nice thing especially for pcb closeups or similar things. It would take more disk space (as 4k cameras i saw record at 60-100mbps) to back up stuff but for most of your videos about 20 mbps for final render would be enough (since there's not much motion and so on). But hard drives are relatively cheap.

60-100Mbps is twice to over 3 times my current bit rate at 50/60fps.

I don't think about it from the viewpoint "people have 1080p monitors or lower", i think of the large sensors in 4k cameras and the sharpness, fine detail etc compared to regular hd cameras, it would help for some of your videos.

Of course it would.
Unfortunately it's not a simple matter of going out and buying a couple of 4K cameras. Everything has to be tested in a complete end-end workflow, not only for features and suitability, but speed and operator sanity during use.
For example, my more expensive Sony NEX-VG30, an otherwise awesome HD camera, is practically useless for my day-to-day blog shooting as a main camera. That is why I use my less expensive and technically inferior Canon HF G30 camera for most bench stuff. If has a lot of little things that enable a better, faster, and less stressful workflow. The last thing I want is a technically awesome 4K camera, but is annoying as hell to use when you have to shoot 200 clips in a day.
And then other changes might be forced upon me as an unforeseen result. It can be like starting the blog from scratch and learning all over again.
And if 50fps rendering is annoyingly slow, I can't wait to process 2-3+ times the bitrate 
So switching to new 4K cameras is to be done with the utmost of caution and fear.

[EEVblog]

dave did you even try my method??

Yes.

man my HD6950 is rendering at double the real-time speed on exactly the same setting you made your videos

Wrong. You are rendering at a very low 10Mbps. And I'd bet you aren't using a mix of the exact same 60fps and 50fps source AVCHD files that I am either.
These things make a huge difference.

[Dany J.]

no i tried it before i posted it i rendered at 26 Mbps and it was still around double realtime, i will try to mix videos and will see if you are right about that

[Dany J.]

look right now i am gunna record it on video, will use a mixed HD game of throne clips 1 50 and 1 60fps, will render at exactly the same setting you use.. and i will let you see the difference between using CPU alone and GPU.

[RoTTe]

Just an idea: Give us the RAW Sony Vegas project and leave us fight to win the contest. Tons of people rendering the same project sharing the time and specs of his computer. A lot of data to compare . This CPU vs GPU vs Memory vs HyperThreading vs whatever vs SATA vs USB3 NEC vs USB3 xPress Intel vs more things kill me please. I love to stablish a base line (maybe a lower specs machine go faster -hello software problem-, maybe the actual rendering time is pretty good for the specs -hi there hardware power-)

Good luck!

[Dany J.]

Here you go dave check this video out.i even did that while capturing my screen in HD res lol
i didn't show entire rendering process just time estimated time left by SOny movie studio and i completed the rendering it is almost the same

Without the screen cap running the time is:
8:13 CPU
1:20 GPU

don't tell me your video are different and this stuff, it is clear man that my CPU had a rough time dealing with this 2 minute clip while with GPU it was a breeze although it is an old beast. so Opencl is the way to go still wondering why it didn't work for you
http://youtu.be/1zbfnwaV9ds

edit: the whole clip is 2 minutes long realtime

[george graves]

Just an idea: Give us the RAW Sony Vegas project and leave us fight to win the contest.

That's never going to happen.

[Fungus]

Trading one consumer software for another isn't going to help.  If you want pro rendering times, you need pro software

That's complete rubbish. Repeating it endlessly won't make it any more true.

(Perhaps you'd like to post some "pro rendering times" for us to look at and analyze. I already posted the time taken to render this blog video...)

Rendering speed comes from a tiny 'codec' module. Provided he knows what he's doing, a guy in a shed can optimize that just as well as a team of 'software architects' sitting on a cloud somewhere. There's no big secrets out there. Video encoding is a mathematical transform.

You really think Cyberlink are holding back? Why would they? Rendering speed is a big selling point (and also very easy for reviewers to measure and compare!!)

http://www.version-2.com.sg/products/cyberlink/powerdirector9/truevelocity

nb. Quite another thing is broadcaster-level installations which can often have custom hardware accelerators, etc. Even so, I think they tend more towards racks of consumer PCs these days.


You want case studies of corporations vs. guys in sheds? Intel set up a special software division a while ago to produce libraries that would run faster on an Intel CPU than anywhere else, libraries for things like JPEG decompression. Everybody needs fast JPEG decompression, right?

Intel threw lots of resources at it for several years but it was never even as fast as ordinary libjpeg, which was mostly written by a single guy in his spare time.

Eventually "Intel Performance Labs" faded from view and even Google can barely find "IJL15" (the last version of the infamous jpeg library).

[Corporate666]

Trading one consumer software for another isn't going to help.  If you want pro rendering times, you need pro software

That's complete rubbish. Repeating it endlessly won't make it any more true.

People who consider themselves "pros" have a vested interest in hyping their unobtanium skills, software and hardware and like to profess others don't "get it", when they are shown to be incorrect.

I think George is still smarting from his 3rd of 4th time of being proven wrong about what Dave is doing wrong.

[Fungus]

Just an idea: Give us the RAW Sony Vegas project and leave us fight to win the contest. Tons of people rendering the same project sharing the time and specs of his computer.

Dave is looking for a BIG difference, not a few percent.

He already has a decent i7 and a massive Xeon machine to try Sony Vegas on. He's already tried different graphics cards, it's not working out.

What's needed is either a) A better codec for Sony, or (b) Some completely different software that *does* have a better codec.

[victor]

I'm don't claim myself an expert, I'm just giving ideas.

Just release your raw 1 minute sample to see if anyone can beat your time, then you can try some software/hardware settings yourself. IF YOU WISH.

[RoTTe]

Just an idea: Give us the RAW Sony Vegas project and leave us fight to win the contest. Tons of people rendering the same project sharing the time and specs of his computer.

Dave is looking for a BIG difference, not a few percent.

He already has a decent i7 and a massive Xeon machine to try Sony Vegas on. He's already tried different graphics cards, it's not working out.

What's needed is either a) A better codec for Sony, or (b) Some completely different software that *does* have a better codec.

Two weeks ago, I updated the ATI drivers (why ? i don't know). I lost a lot of hours later with two monitors (U2713HM of dell) one blue fog and the another one with a red thing overlay killing my eyes. Somehow the new ATI driver mix the DDC calibration from one monitor and ignore the another one.

I know that is not the normal thing because the normal thing don't fuck my monitors from the beginning. There are a lot of parameters with codecs and encoding, my laptop uses the integrated graphic card (i7 HD4000 blah blah) for encoding/decoding software and the NVIDIA for another things (You need to execute Altium associated with the Nvidia card or you'll hammer the laptop hard).

Maybe I lost something important but I don't know if 3x the realtime with that config is the normal timming, the epic timming or just the worst timming of the world. Do you know for sure ? I don't

[Fungus]

I just noticed that PowerDirector is listed on Intel's "Quick Sync Enabled" page but neither Sony nor Adobe are:

http://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html

Maybe that's why PD renders so fast.


PS: And I guess it also destroys George's "professional grade" software theory. Surely "professional grade" software would use any special hardware resources that are available and our cheapo "consumer grade" software wouldn't...right?

[Armxnian]

3) Direct uncompressed output using the Sony YUV Video For Windows codec actually works (it had issues on my old machine)
1:46 for the 1min test video which is pretty good and the fastest yet. That was to the SSD. File size was 12.163GB for the 1 min, so that means a 1 hour video would need 730GB.
Such an output would need about 114MB/s write speed, so that makes a 7200 rpm drive a WD Black suitable. 1GB+ of SSD would of course be very expensive and of no improvement.
So this seems like the best solution for now.
I might try some of the other VFW codecs again, but I've been advised by top people close to the metal that the Sony CODEC is pretty darn good at this.

You could try the Lagarith Lossless Video Codec. It probably compresses a bit better and is quite fast.
http://lags.leetcode.net/codec.html

could try going to huffyuv codec (multithreaded version) in Sony and then huffyuv to h264 in handbrake

Huffyuv is compressed but lossless. Files are large but realistic for a intermediate step.

Im not sure how the multithreaded performance of huffyuv compares to other codecs.

These codecs are outdated, not even developed anymore. They also require ridiculous CPU power which would increase render and encode times compared to uncompressed. Compressed lossless also has to be decoded to be reencoded using x264, which will take time. Also lagarith has problems with playback so you can't watch the video until you encode it again. These codecs were meant for systems with good CPU power but low drive speed. Capturing uncompressed 4:4:4 at resolutions of 1080 or higher and at high frame rate was impossible unless you had 10 drives in raid. Not much of a problem now as 2 ssds can give you over 1GBps writes.

Non ecc and faster memory can improve performance, not dramatically, but it can.

 
Seems not:
http://www.techspot.com/article/845-ddr3-ram-vs-ecc-memory/

And someone pointed out the E5-2630v2 does not support faster than 1333MHz memory, but that seems to be incorrect:
http://ark.intel.com/products/75790/Intel-Xeon-Processor-E5-2630-v2-15M-Cache-2_60-GHz
It can support up to 1600Mhz it seems.

This article is meh. Why test system ram performance using a GPU benchmark instead of video rendering or encoding, where lots of data is written and accessed from ram. Also they don't mention the fact that non ecc sticks have been available in much higher bandwidth at lower cost for quite a while now. Everyone in this thread is comparing 1333 to 1600, well that isn't that big of a jump, and 1600mhz is often CHEAPER than 1333mhz. You can pick up some Kingston ddr4 16gb quad channel 3000mhz and 12 cas latency ram for $250. Compare that to 1333 instead of 1600. Ddr3 prices for higher bandwidths are even cheaper.

Also, the figure on the Intel site is just what the memory controller is rated for. You can use speeds as high as your motherboard supports if your controller is up to it. 16gb doesn't put much strain on the integrated memory controller, so you can get much higher bandwidth sticks. Ivy bridge i7s were rated for 1600mhz memory, I ran 2400 with no problem.

For your case, there is no point in upgrading. As mentioned before, upgrading one part is almost always going to be bottlenecked by another part. Upgrading a system based on parts you already have is a waste of money. I've learned the hard way, and just ended up selling the parts and building from scratch, essentially losing money.

I said think about it for a future investment. No one "needs" 4k, you provide high resolution images of teardowns.

Right now the 4k cameras are still in the 'early adopter' price range, ie. too expensive.

Those who say there is no noticeable difference in image quality in 1080 vs 4k are the same who said there is no difference in 720 vs 1080 and 480 vs 720 a few years ago. If there is no difference, an entire industry wouldn't make the jump as the technology becomes available.

The 'industry' will jump as a marketing move - to sell new TVs. They'll advertise and pay for TV presenters/celebrities to casually mention how amazing their new TV is, even though they probably got theirs for free, it was the top-of-the-line model, and they probably don't even know what to look for in a TV image.

Plus: As soon as manufacturing costs go down to the same price level as the old ones, all the stores will stop selling the old stuff. All you'll be able to buy is 4k (or whatever) whether it's noticeably better or not.

In short: The industry 'jumping' doesn't tell you anything about the quality of a product. The difference to the consumer might be very small.

If you watch movies from 10 feet away on a 100" TV then of course 4k is going to look much better than 1080p. On a 24" panel? Not so much...

TV manufacturers are a business, they make money by milking early adopters of 4k tvs were no 4k content exists. Monitors are another story, you create content, view images, videos, games, whatever, but you get the benefit as 4k content exists. There is no 4k on cable/sattelite, streaming services, or bluray, so buying a 4k tv is a waste of money. You can't compare that to monitors.

For the rest of us, it is a positive jump. More 4k screens means more 4k content. Wouldn't you want to watch your movies in 4k? I would.

1080 on a 24inch screen is fairly low PPI, you can get a noticeable increase in sharpness by upgrading. You don't sit far from your monitor, you sit close.

[Fungus]

Just an idea: Give us the RAW Sony Vegas project and leave us fight to win the contest.

the best raw clip is TV static noise. it will max out encoding capability.

Download this blog video and use that. Let us know how you get on.

I already posted my results here: https://www.eevblog.com/forum/blog/eevblog-726-dual-xeon-video-editing-machine-build/msg635434/#msg635434

[Fungus]

buying a 4k tv is a waste of money. You can't compare that to monitors.

Yep, that's why I didn't...

[Armxnian]

buying a 4k tv is a waste of money. You can't compare that to monitors.

Yep, that's why I didn't...

No, you didn't buy one because they're overpriced, not because you think there is no benefit . 1080 on a 4k screen is theoretically better than on a native 1080 screen.

Monitors on the other hand have come down in price. You can get a 4k IPS panel for $500. They were $3000 a year ago. You honestly might not notice the difference vs a 1080 monitor, so there is no need to get a 4k monitor. But I will enjoy 4k content on a 1080 or 4k screen, and will persuade Dave to make 4k content in the future 

[Fungus]

buying a 4k tv is a waste of money. You can't compare that to monitors.

Yep, that's why I didn't...

No, you didn't buy one because they're overpriced, not because you think there is no benefit

I meant I didn't make that comparison. Obviously there's a benefit when you're using a computer close up, just not for watching TV.

[IanJ]

Hi all,

I haven't gone right through this thread.......so don't flame me if it's been posted already!.......but have you seen this:-

http://www.sonycreativesoftware.com/Forums/ShowMessage.asp?Forum=12&MessageID=716066

This hidden menu is available in Vegas Movie Studio HD V11 & Movie Studio Platinum 13 (I have both).
Interesting!....albeit a pity I only have a single i7(4770).....but I wonder what Dave's machine would make of these tweaks!

Ian.

QUOTE:-
Vegas 9 can make use of all the processor threads your system provides, but it has a built-in limitation of 4. This can be changed to 8 however if you know the following trick:

Hold down the Shift key when you open Options/Preferences. This will cause the Preferences window to open with a new tab called Internal. This is where you can change the limit of 4 threads to 8. Do this as follows:

1. Enter the text "threads" (no quotes) in the text box at the bottom. This will display all the parameters containing the word "threads."

2. Find the line that says Maximum video render threads (or something like that - I no longer have VMS 9 to look at.)

3. In that line change both the Default and Value numbers to 8 (or whatever the number of processing threads your system has.)

4. Hit OK, then close Vegas and re-open it.

You are now running with all threads active and usable.

To clarify some terminology: Intel now makes CPU chips that are multi-threaded. That means a single chip can process more than one instruction stream at a time, thus enabling one physical chip to do the work of multiple single thread ships.

"Thread" means a stream of instructions, which is the work processed by the CPU or "core". Core is really an obsolete/incorrect term that came into being yeas ago when main memory was referred to as "core memory" to differentiate it from cache memory built into processor chips.

In the case of the i7 line of processors, each i7 has 4 CPUs inside it. And each of these is dual channel. This means an i7 based computer can process 8 instruction streams ("threads") simultaneously, assuming there is enough memory in the system to support that.

Since raw CPU power is typically the limiting factor on render speeds, having more threads running speeds things up considerably. When rendering with Vegas you want all the CPUs you can get (and all the memory too,)

[FHR]

So this is the limiting factor! I said it has to be software fault. People here were saying all kinds of crazy and hyper-sophisticated things, including highly advanced NUMA architecture. And it all comes down to a software, respectively it's config.

[EEVblog]

Here you go dave check this video out.i even did that while capturing my screen in HD res lol
i didn't show entire rendering process just time estimated time left by SOny movie studio and i completed the rendering it is almost the same

Without the screen cap running the time is:
8:13 CPU
1:20 GPU

don't tell me your video are different and this stuff, it is clear man that my CPU had a rough time dealing with this 2 minute clip while with GPU it was a breeze although it is an old beast. so Opencl is the way to go still wondering why it didn't work for you
http://youtu.be/1zbfnwaV9ds

edit: the whole clip is 2 minutes long realtime

Nope, doesn't work for me, sorry.
Yep, I did it exactly the same as you showed, just like I've done it time and time again before when it didn't work.

[EEVblog]

Hi all,
I haven't gone right through this thread.......so don't flame me if it's been posted already!.......but have you seen this:-
http://www.sonycreativesoftware.com/Forums/ShowMessage.asp?Forum=12&MessageID=716066
This hidden menu is available in Vegas Movie Studio HD V11 & Movie Studio Platinum 13 (I have both).
Hold down the Shift key when you open Options/Preferences. This will cause the Preferences window to open with a new tab called Internal. This is where you can change the limit of 4 threads to 8.

Well I'll be damned, didn't know about this.
But no, sorry, doesn't work. Increased to 12 threads and it's now slower. Over 3 minutes.

[IanJ]

Hi all,
I haven't gone right through this thread.......so don't flame me if it's been posted already!.......but have you seen this:-
http://www.sonycreativesoftware.com/Forums/ShowMessage.asp?Forum=12&MessageID=716066
This hidden menu is available in Vegas Movie Studio HD V11 & Movie Studio Platinum 13 (I have both).
Hold down the Shift key when you open Options/Preferences. This will cause the Preferences window to open with a new tab called Internal. This is where you can change the limit of 4 threads to 8.

Well I'll be damned, didn't know about this.
But no, sorry, doesn't work. Increased to 12 threads and it's now slower. Over 3 minutes.

Presume you changed BOTH max settings in there.

Ian.

[EEVblog]

Presume you changed BOTH max settings in there.

Yes. And BTW, I'm pretty sure it doesn't matter because the "64bit" version already has it's own max threads setting and that is already set to 16 on both by default.

[rs20]

But no, sorry, doesn't work. Increased to 12 threads and it's now slower. Over 3 minutes.

Well, if increasing it makes it slower, decreasing it should make it faster, right?    But more seriously, that is interesting. The only (no particularly productive) theory I can offer is that the CPU's cache can't keep all those extra threads in memory, so stuff is continually getting bounced off to the RAM. Just like using too much RAM causes swapping.

[EEVblog]

Well, if increasing it makes it slower, decreasing it should make it faster, right?    But more seriously, that is interesting. The only (no particularly productive) theory I can offer is that the CPU's cache can't keep all those extra threads in memory, so stuff is continually getting bounced off to the RAM. Just like using too much RAM causes swapping.

No, it has nothing to do with the setting, I'm using the 64bit version. I just verified that it's still slower after changing back, using the the Sony AVC codec, so somethign else is at play here.
Sony YUV high bitrate output time remains consistent.

[Smokey]

I'm joining this party 10 pages late.  I didn't read everything, and I'm sure someone already said this but....

You can either have the warm fuzzy feeling of something you are used to and comfortable with, or you can build a system for speed to get some job done.  It's a render box for your job, not a daily driver facebook browser.  Why limit the machine in any way?  If it runs faster on Linux, install Linux.  If your Sony Vegas software isn't optimized and can't take advantage of the hardware, get new software.  It's like driving your car with the parking brake on and complaining about not going fast enough.  You proved that handbrake is significantly faster (even without hyperthreading) so the machine has more potential than you are able to take advantage of with the setup.  To put it in EE terms, if you needed to professionally debug a USB3 bus are you going to buy an optioned up modern scope but refuse to enable the USB3 protocol analyzer?

[EEVblog]

If your Sony Vegas software isn't optimized and can't take advantage of the hardware, get new software.

I've said this a dozen times before, but it seems I have to keep repeating myself.
I have tried many different software packages, even the "professional ones", practically every package on the market in fact.  They all have little issues for my particular workflow that keep making me come back to Sony (which has issues too, but less, and yes, it's familiar).
Don't underestimate the importance of familiarity. In the end, it's only rendering time, I don't have to sit there and watch it. But switching to another package that did this more convolauted than I am used to for my workflow, then that would stress me out day in and day out.
It ain't as easy as you think to just change software.

[Rotareneg]

When rendering from Movie Studio 13 Platinum I use Debugmode FrameServer and AviSynth to serve frames to ffmpeg (this works with Handbrake too.) That way I can avoid having to render to an intermediate file.

[Grecord]

So a few things you mentioned in the vid reminded me of some other vids I've seen recently, Linking them here.

https://www.youtube.com/watch?v=kc6Rbel6n1g,  https://www.youtube.com/watch?v=khDsbxa5_G0,       
Charts at4:40 and mention of vid rendering at 5:20, Well I hope there's a nugget of insight in there somewhere.

[Fungus]

Hi all,
I haven't gone right through this thread.......so don't flame me if it's been posted already!.......but have you seen this:-
http://www.sonycreativesoftware.com/Forums/ShowMessage.asp?Forum=12&MessageID=716066
This hidden menu is available in Vegas Movie Studio HD V11 & Movie Studio Platinum 13 (I have both).
Hold down the Shift key when you open Options/Preferences. This will cause the Preferences window to open with a new tab called Internal. This is where you can change the limit of 4 threads to 8.

Well I'll be damned, didn't know about this.
But no, sorry, doesn't work. Increased to 12 threads and it's now slower. Over 3 minutes.

Menus like this are there to let people figure out the optimum settings. It makes sense that the one the final end-user sees is the optimum for the codecs. Rendering speed is a big selling point, and also one that's easy to measure/compare on different machines. They wouldn't knowingly choose a bad setting.

I think the problem lies in the codecs themselves, there's only so much parallelism you can do - compressed video depends heavily on the results of the previous frame. You can't process every frame in the video in a separate thread, you have to wait for the previous frame to complete.

You can split up the workload of each frame but there still needs to be a master thread making the decisions about which data goes through to the next frame and that job can't really be done in parallel. Once it becomes the bottleneck then using more threads won't help.

[rs20]

I think the problem lies in the codecs themselves, there's only so much parallelism you can do - compressed video depends heavily on the results of the previous frame. You can't process every frame in the video in a separate thread, you have to wait for the previous frame to complete.

You can split up the workload of each frame but there still needs to be a master thread making the decisions about which data goes through to the next frame and that job can't really be done in parallel. Once it becomes the bottleneck then using more threads won't help.

What I'm saying here isn't connected to the reality of how codecs are implemented, but: You're describing the hard way of parallelizing a video codec. Every nth frame in a compressed video is a complete, independent frame, so you can break up a video into a bunch of separate, independently compressible blocks, boundaried by these complete frames. The easy way to parallelize is to hand out these blocks to cores as they become idle. Downside is that there are a lot more frames waiting for consideration in memory at a time, but it wouldn't be GB. A hybrid of these two techniques would make even more sense.

[Fungus]

What I'm saying here isn't connected to the reality of how codecs are implemented, but: You're describing the hard way of parallelizing a video codec. Every nth frame in a compressed video is a complete, independent frame, so you can break up a video into a bunch of separate, independently compressible blocks, boundaried by these complete frames.

If it's embarrassingly parallel then why don't they do it?

[rs20]

If it's embarrassingly parallel then why don't they do it?

It is embarrassingly parallel, if you're willing to set aside a gig of RAM just for keeping all these blocks of frames stored. The hard way of parallelizing requires less RAM, so if they think they can implement it correctly the hard way, that'd be the optimal way to do it -- leaving more RAM for the renderer. If they choose that approach, but forget to design with 12-core machines in mind (as you correctly suggested several messages ago)... then we end up having this discussion.

[coppice]

What I'm saying here isn't connected to the reality of how codecs are implemented, but: You're describing the hard way of parallelizing a video codec. Every nth frame in a compressed video is a complete, independent frame, so you can break up a video into a bunch of separate, independently compressible blocks, boundaried by these complete frames.

If it's embarrassingly parallel then why don't they do it?

The term embarrassingly parallel is usually applied to something which can be split into a huge number of threads, so it would keep something like a GPU busy. He didn't say that. He said video could be split into enough threads to keep a 24 core machine busy, which is feasible with the amount of RAM buffering you can do in a modern machine.

[sync]

Well, if increasing it makes it slower, decreasing it should make it faster, right?    But more seriously, that is interesting.

Almost all applications will go slower with too many cores. Amdahl's law give you the theoretical maximum speed up. But in reality there are things which will slow down with more cores.
Also is often preferable not too use all available cores with your application. Leave one or two free for the operating system.

[Fungus]

If it's embarrassingly parallel then why don't they do it?

It is embarrassingly parallel, if you're willing to set aside a gig of RAM just for keeping all these blocks of frames stored.

A whole gig of RAM? Yeah, that's such a massive problem these days. If that's the only reason it's not doing it, then...

The term embarrassingly parallel is usually applied to something which can be split into a huge number of threads, so it would keep something like a GPU busy. He didn't say that. He said video could be split into enough threads to keep a 24 core machine busy, which is feasible with the amount of RAM buffering you can do in a modern machine.

From the Wikipedia page I linked to: "In parallel computing, an embarrassingly parallel workload, or embarrassingly parallel problem, is one for which little or no effort is required to separate the problem into a number of parallel tasks."

He claimed that all they need to do is to split the video up in to chunks of 'N' frames then compress each chunk separately in its own thread. That seems like "very little effort" to me so why aren't they doing it?

RAM? Finger-in-the-air calculations would suggest that even 24 threads wouldn't need more than a couple of gigs for the codec.

eg. A 1920x1080 buffer with RG+B stored in single precision floats is under 24Mb, a couple of those per thread, multiply by 24, it's about 1Gb. They'll also need 'N' frames of source video each and some workspace. Source is 6Mb per frame, the compression routines don't need much because they work on individual 8x8 blocks....call it another 1Gb.

Even if it was twice that it would be no big deal - a machine with 24 CPUs can be expected to have that much.

Or ... thinking radically .... the codec could look at how much RAM is in the machine and adjust the number of threads to use 50% of that (or whatever).

Bottom line: It's easy to code so I really can't see an excuse for not maxing out all the CPUs.

PS: Render speed is probably more important to a codec developer than the end users...the developer has to sit there for hours watching video encode while he twiddles his thumbs. Every single optimization counts!

[Fungus]

Almost all applications will go slower with too many cores.

But not all... some of them are "embarrassingly parallel".

Also is often preferable not too use all available cores with your application. Leave one or two free for the operating system.

Encoding threads can be set to low priority without much loss in overall encoding speed. You could keep on reading EEVBLOG forums with no problem even if all CPUs were in use by the codec.

[sync]

Almost all applications will go slower with too many cores.

But not all... some of them are "embarrassingly parallel".

Yeah, the TOP500 Linpack benchmark and other non-real world things...
Only very few applications scale well with 100s or 1000s cores.

[Fungus]

Yeah, the TOP500 Linpack benchmark and other non-real world things...
Only very few applications scale well with 100s or 1000s cores.

3D Movie rendering is quite "real world". So is weather forecasting and any number of engineering calculations that use finite element analysis (which is done for an awful lot of things these days).

[sync]

3D Movie rendering is quite "real world". So is weather forecasting and any number of engineering calculations that use finite element analysis (which is done for an awful lot of things these days).

These are real world applications. But not the Linpack benchmark. It runs a independent Linpack process on each core without communication between them. This is completely different from FEM or weather forecasts. Which have dependencies and communications between the processes/threads. This is a big problem for scaling with more cores. I guess that 3D movie rendering doesn't have this problem and scales easily and well.

[DanielS]

This is completely different from FEM or weather forecasts. Which have dependencies and communications between the processes/threads.

The main goal of any high-performance computing application is reducing dependencies to the absolute minimum. For things like atomic-scale FEM, you can divide your problem space into twice as many isolated cubes as you have CPU cores available with some overlap with neighboring cubes, process one simulation step, resolve border interactions between completed adjacent cubes, once the step-one cubes are done, start sending out step-2 cubes, rinse and repeat. Depending on how massive the simulation is, processes may not need to talk with each other more than once every several minutes and at this point, linpack actually becomes a reasonable best-case approximation.

When you want your problem to scale to 100 000 cores, you cannot afford to waste much more than 1/100 000th of your time on inter-process communications system-wide. If such machines exist, whoever commissions them must have a few programmers who know how to write useful software that scales to that extent. In my scenario above, inter-process communications would be nearly nonexistent beyond the initial setup, periodic progress tracking and background transfers to keep data sets and results moving without letting CPUs stall.

[mux]

Sorry if this has been asked before but I can't find it: has Dave uploaded source files somewhere so we can try out settings for ourselves? I use Vegas as well and I've used CUDA offloading a couple times with some success. Maybe I can find out better settings to speed things along.

[sync]

The main goal of any high-performance computing application is reducing dependencies to the absolute minimum.

I agree. Compare this to Dave's Sony Vegas problem. I don't think it's well optimized in this regard. He didn't get full CPU utilization with all the cores. I think it's because of dependencies.

For things like atomic-scale FEM, you can divide your problem space into twice as many isolated cubes as you have CPU cores available with some overlap with neighboring cubes, process one simulation step, resolve border interactions between completed adjacent cubes, once the step-one cubes are done, start sending out step-2 cubes, rinse and repeat. Depending on how massive the simulation is, processes may not need to talk with each other more than once every several minutes and at this point, linpack actually becomes a reasonable best-case approximation.

Interesting. My experience with commercial mechanical and CFD FEM simulation software is that there is many communication between the nodes. I didn't saw no communication for minutes. Only for a few seconds max.

[Stonent]

Just had a thought.

For comparison's sake, move all the memory to the primary processor's NUMA node and remove or disable the second processor completely and run the tests again.  That might show inherent issues with parallelism or NUMA cache misses / transfers between nodes.

[necessaryevil]

Is there any chance of a followup, Dave? You predicted a shitstorm of comments, but on the contrary: I liked it and now I want to know!

[Fungus]

Is there any chance of a followup, Dave? You predicted a shitstorm of comments, but on the contrary: I liked it and now I want to know!

Big mystery:  What did Dave decide to do....? 

[Rasz]

Big mystery:  What did Dave decide to do....?

Thats simple: ignore feedback, conclude he was right all along. Thats what I would do
Many people already said problem lies in the insane double encoding workflow, bud Dave wont change it, end of story.

[DanielS]

Interesting. My experience with commercial mechanical and CFD FEM simulation software is that there is many communication between the nodes. I didn't saw no communication for minutes. Only for a few seconds max.

Harmless, non-performance-critical background chatter, sure: even when simulation domains are mostly independent, partial results still need to get forwarded to whatever node is scheduled to resolve border effects with the neighbors when the related blocks complete and the scheduler needs to keep tabs on what the nodes are doing to decide what to schedule where so everything can run smoothly, making sure everything has the data it needs before it needs it. An actual remote data dependency on the other hand would quickly ruin performance.

[Fungus]

Big mystery:  What did Dave decide to do....?

Thats simple: ignore feedback, conclude he was right all along. Thats what I would do

Nah, the engineer in him won't let him sleep at night if he does that. Look at the machine he just built to try and solve things.

Many people already said problem lies in the insane double encoding workflow, bud Dave wont change it, end of story.

It wouldn't be a problem if the encoding was faster.

I don't get what's so compelling about Sony Movie that he can't switch. The "workflow" for what he's doing is pretty much the same in all video editing packages. He's not making Hollywood moves here with green-screen actors mixed with CGI and 20 layers of post-production lighting effects, he's joining short video clips together, trimming start/end of each clip, adding overlay text then encoding the result.  If another package encode three or four times faster than Sony then I say use that other package.

[EEVblog]

Thats simple: ignore feedback, conclude he was right all along. Thats what I would do
Many people already said problem lies in the insane double encoding workflow, bud Dave wont change it, end of story.

I've already said I'm moving to a faster uncompressed output from Sony and have posted times from that.

[EEVblog]

Nah, the engineer in him won't let him sleep at night if he does that. Look at the machine he just built to try and solve things.

The machine I just built was done so because:
a) People kindly sent me some stuff for free to use
b) It would at least offer some improvement over what I have now, and it was interesting to find out how much.

I would not have chosen the hardware I did if it was all from scratch.

[EEVblog]

Is there any chance of a followup, Dave? You predicted a shitstorm of comments, but on the contrary: I liked it and now I want to know!

Probably not on the main channel, it's just not that interesting.
I have already posted what I plan to do on the blog page.

[Fungus]

Thats simple: ignore feedback, conclude he was right all along. Thats what I would do
Many people already said problem lies in the insane double encoding workflow, bud Dave wont change it, end of story.

I've already said I'm moving to a faster uncompressed output from Sony and have posted times from that.

It still takes 1:45 for a 1 minute video though. Not exactly screaming speed (five times slower then PowerDirector would do it).

[EEVblog]

It still takes 1:45 for a 1 minute video though. Not exactly screaming speed (five times slower then PowerDirector would do it).

That remains to be seen. I have installed it but have not yet tried it. IIRC last time I tried it it was, meh.

[necessaryevil]

The Xeon Phi is out now! I hope someone will donate one to Dave!

[Fungus]

It still takes 1:45 for a 1 minute video though. Not exactly screaming speed (five times slower then PowerDirector would do it).

That remains to be seen. I have installed it but have not yet tried it. IIRC last time I tried it it was, meh.

Actually, no ... I can encode 1080p50 video at 3.5x speed on my i5.

You have an i7 with twice as many cores so it should be way faster than that - you might be able to encode an hour of video in ten minutes!

[vlad777]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

I completely agree. Dave doesn't seem to appreciate memory channels but they are duck's guts of speed.

[DanielS]

You have an i7 with twice as many cores so it should be way faster than that - you might be able to encode an hour of video in ten minutes!

The i7 has exactly the same number of cores as the i5, except the i7 has 2MB extra L3 cache and has HyperThreading enabled, which lets each core run two threads for better thread-level parallelism and more efficient use of execution units within each core.

[Fungus]

You have an i7 with twice as many cores so it should be way faster than that - you might be able to encode an hour of video in ten minutes!

The i7 has exactly the same number of cores as the i5, except the i7 has 2MB extra L3 cache and has HyperThreading enabled, which lets each core run two threads for better thread-level parallelism and more efficient use of execution units within each core.

That's what I meant to say - it can do nearly twice as much work as an i5.   

I think each pair of cores has two execution units but a single floating point unit. Heavy floating point math is a teeny bit less efficient with hyperthreading than with separate cores.

The FPU works like a FIFO: You put numbers in the front and 'X' clock cycles later the result comes out the other end, with 'X' depending on the operation.

If two threads are putting numbers into the FIFO then single cycle instructions like addition can take a hit because they have to alternate. OTOH instructions which take many clock cycles (multiply, divide, sqrt, sin/cos, etc.) will make much better use of the FPU because with two threads you can have twice as many of them passing through the FIFO at the same time.

In reality the effect on single-cycle instructions isn't too bad because it's quite difficult to put a new number into the FIFO on every single clock cycle - you need to store results, fetch new operands from RAM, etc., this frees up the FPU for the other thread. With the rigth code they can interleave perfectly with no clashes.

(Or at least, that's how "hyperthreading" worked when I was younger...)

[Fungus]

Another thing to keep in mind: LGA2011 CPUs have a quad-channel memory controller so unless you put four similar DIMMs on each CPU, you are only enabling half of the RAM bandwidth each CPU is capable of. This could be a massive bottleneck when all 24 threads are enabled.

I completely agree. Dave doesn't seem to appreciate memory channels but they are duck's guts of speed.

I think Dave appreciates it just fine (he actually mentioned it in the video!), he just doesn't believe it's the bottleneck here.

FWIW I agree with him.

Think: The CPU usage meter works by looking at OS time slices  If the CPU usage meter is showing "50% idle" then RAM configuration isn't the problem. The problem is that 50% of the CPUs aren't being handed any work to do by the compression codec.

The time to talk about RAM bank configurations is when the meter shows 100% usage, not before.

[Fungus]

In either case however if the CPU's are at 100% then increasing memory bandwidth is not going to get you more CPU cycles.

True, but that's not what the CPU meter shows.

The CPU meter doesn't know how many CPU cycles did useful work and how many were wasted due to slow RAM (it will show "100%" in both those cases so long as the thread is doing *something*, no matter how slowly).

[DanielS]

Think: The CPU usage meter works by looking at OS time slices  If the CPU usage meter is showing "50% idle" then RAM configuration isn't the problem.

Another thing the CPU usage is showing is that there is a roughly 2:1 bias toward scheduling things on a single socket. Since the software likely does not have explicit NUMA support, most of its code and data will land on a single CPU and the scheduler will try to keep most of its threads on it to minimize socket-to-socket overhead.

Dual-channel 1600MT/s RAM is just about ideal for a quad-core i5 under most circumstances and is mostly still adequate for a 4C8T i7. For a dual-socket 6C12T Xeon, dual-channel 1333MT/s is grossly inadequate when CPU0 ends up hosting most application code and data for both sockets.

BTW, Intel's LGA2011 CPUs have memory controller instrumentation which allows the scheduler to make decisions based on memory controller load. If CPU0's memory controller is under heavy load, it makes no sense to schedule threads that rely on code and data hosted on CPU0 on other CPUs since there is no spare bandwidth to serve them.

[Fungus]

In either case however if the CPU's are at 100% then increasing memory bandwidth is not going to get you more CPU cycles.

True, but that's not what the CPU meter shows.

The CPU meter doesn't know how many CPU cycles did useful work and how many were wasted due to slow RAM (it will show "100%" in both those cases so long as the thread is doing *something*, no matter how slowly).

You've very subtly changed from "any work" to "useful work". Is that significant?

No, just trying to explain what the CPU meter shows. To me it shows very clearly that RAM isn't the bottleneck (yet)

[Fungus]

BTW, Intel's LGA2011 CPUs have memory controller instrumentation which allows the scheduler to make decisions based on memory controller load. If CPU0's memory controller is under heavy load, it makes no sense to schedule threads that rely on code and data hosted on CPU0 on other CPUs since there is no spare bandwidth to serve them.

Sure, but do you think Windows is that smart?

[DanielS]

Sure, but do you think Windows is that smart?

There would not be much of a point in supporting multi-socket configurations if the scheduler is going to do a piss-poor job at trying to make the whole thing work reasonably efficiently. Though Microsoft might reserve the finer scheduling tricks for Windows HPC Server.

Even without the memory performance instrumentation, the CPU's performance counters have numbers on clock ticks and instructions executed that the scheduler can use to determine how efficiently the CPUs are at running processes and how much of an impact using remote CPUs has on threads hosted on each CPU. If CPU0's throughput drops more when scheduling CPU0-hosted processes on remote CPUs than what other CPUs contribute to CPU0's workload, you reduce the amount of CPU0 processes scheduled elsewhere to keep throughput close to optimum.

[Fungus]

Sure, but do you think Windows is that smart?

There would not be much of a point in supporting multi-socket configurations if the scheduler is going to do a piss-poor job at trying to make the whole thing work reasonably efficiently. Though Microsoft might reserve the finer scheduling tricks for Windows HPC Server.

Either that, or .... you put in an API so that users can do it themselves:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa363804%28v=vs.85%29.aspx

Even without the memory performance instrumentation, the CPU's performance counters have numbers on clock ticks and instructions executed that the scheduler can use to determine how efficiently the CPUs are at running processes and how much of an impact using remote CPUs has on threads hosted on each CPU. If CPU0's throughput drops more when scheduling CPU0-hosted processes on remote CPUs than what other CPUs contribute to CPU0's workload, you reduce the amount of CPU0 processes scheduled elsewhere to keep throughput close to optimum.

It's a pretty theory but do you have any evidence to show that's what's happening here?

[DanielS]

It's a pretty theory but do you have any evidence to show that's what's happening here?

While it does not go into details, this MSDN article definitely states that Windows' scheduler does favor scheduling threads on the CPU closest to the process' memory:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684251%28v=vs.85%29.aspx

That alone is enough to explain why only one CPU gets consistently loaded by non-NUMA-aware software.

[Fungus]

It's a pretty theory but do you have any evidence to show that's what's happening here?

While it does not go into details, this MSDN article definitely states that Windows' scheduler does favor scheduling threads on the CPU closest to the process' memory:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684251%28v=vs.85%29.aspx

That alone is enough to explain why only one CPU gets consistently loaded by non-NUMA-aware software.

Yes, but it doesn't say it will ONLY schedule them on those CPUs (which makes sense - a thread running with slow(er) memory access can still do useful work).

[IanJ]

Here you go dave check this video out.i even did that while capturing my screen in HD res lol
i didn't show entire rendering process just time estimated time left by SOny movie studio and i completed the rendering it is almost the same

Without the screen cap running the time is:
8:13 CPU
1:20 GPU

don't tell me your video are different and this stuff, it is clear man that my CPU had a rough time dealing with this 2 minute clip while with GPU it was a breeze although it is an old beast. so Opencl is the way to go still wondering why it didn't work for you
http://youtu.be/1zbfnwaV9ds

edit: the whole clip is 2 minutes long realtime

Been doing some testing in order to try an replicate this.......to no avail so far (I get same/similar speeds as Dave), but what I did see is that in your YT vid you picked a profile called "BO"....a custom one you had saved. The issue I found though is that it depends on what profile you picked in the first place that you eventually saved to "BO" can influence the encoding.

Can you tell me what profile used to generate "BO".

PS. The fastest I can achieve (50fps source rendering to a 50fps .m2ts) is 17mins for a 9min video........pro-rata down works at about 3.77mins for your 2min video.

PPS. However, can't help but feel that this quote I found says it all:-
"as someone who uses vegas pro and media studio a decent amount I can say that GPU acceleration is hit or miss depending on the codec/container you source files are in as well as the render file type".

Thanks,

Ian
[i7 4770 cpu)

[DanielS]

a thread running with slow(er) memory access can still do useful work).

If the main CPU is running into memory bandwidth/IO contention, having extra processes from CPU1 accessing CPU0's memory may cause performance of processes running on CPU0 using local memory to degrade worse than whatever work CPU1 can provide and you end up with worse overall performance. With 12-24 threads competing against each other for open memory rows and bandwidth, things can get ugly fast much like how the performance of network links tends to go down the drain once they start congesting.

The "useful work" might not be so useful. I don't remember if Dave tried disabling the second CPU - I spot-checked the video but did not find that part if he did. On paper, a  single Xeon with quad-channel memory should easily match his i7.

[eneuro]

http://docs.nvidia.com/cuda/cuda-c-programming-guide/

The challenge is to develop application software that transparently scales its parallelism to leverage the increasing number of processor cores, much as 3D graphics applications transparently scale their parallelism to manycore GPUs with widely varying numbers of cores.

Anyway, if we divide 24 cores in new dual CPUs upgraded system by 8 in reference we get: 24/8= 3, but if we multiply 24 cores by 2.6 Ghz ~ 62 [core GHz] and oryginal 8 cores * 3.7 Ghz ~ 30 [core Ghz] than it looks like 62/30 ~ 2 x times more [core Ghz] in new setup 
However, it is only a estimation of [core GHz] without any investigating architecture differencies and memory setups.

Probably Nvidia Tesla's with optimized software for those monsters could make @Dave happy, especially no need to give away any solar energy back to grid with setup like those 
http://www.nvidia.com/object/tesla-supercomputing-solutions.html
ASUS GeForce GTX 780 Ti for less than $1000, so worth to test its GPU processing power 

3GB Memory ~1GHz clock
http://www.nvidia.com/gtx-700-graphics-cards/gtx-780ti/
CUDA Cores    2880   
This thing should be really powerfull 2880 cores x 0.9 Ghz ~ 2500 [core GHz] which is 40x times more than latest @Dave setup

[Fungus]

a thread running with slow(er) memory access can still do useful work).

If the main CPU is running into memory bandwidth/IO contention, having extra processes from CPU1 accessing CPU0's memory may cause performance of processes running on CPU0 using local memory to degrade worse than whatever work CPU1 can provide and you end up with worse overall performance. With 12-24 threads competing against each other for open memory rows and bandwidth, things can get ugly fast much like how the performance of network links tends to go down the drain once they start congesting.

The "useful work" might not be so useful.

You can always come up with a theoretical pathological case, yes.

But Xeon CPUs have big caches and a few pages ago we were discussing how that's unlikely to happen with a video codec. Video encoding is embarrassingly parallel.

[DanielS]

But Xeon CPUs have big caches and a few pages ago we were discussing how that's unlikely to happen with a video codec. Video encoding is embarrassingly parallel.

Video encoding might be embarrassingly parallel but it is not the only variable in the equation: you have the file reading and parsing, the audio and video decoders, then you have whatever pre-processing the editing software applies on top, the audio and frame rate conversions when necessary, whatever other post-processing the video editing software might do before sending video to the encoding CODEC, packing the output file, etc. Each and every intermediate processing step may add a number of potential bottlenecks on top of the resource sharing issues for the second socket if they are not perfectly tuned to work with each other, which they rarely are when combining software from multiple independent sources - this can already be hard enough to achieve even within one's own code.

[vlad777]

AMD landed a deal with Avid.
FirePro cards will support Avid Media Composer 8.4

1:40

[Fungus]

But Xeon CPUs have big caches and a few pages ago we were discussing how that's unlikely to happen with a video codec. Video encoding is embarrassingly parallel.

Video encoding might be embarrassingly parallel but it is not the only variable in the equation: you have the file reading and parsing, the audio and video decoders, then you have whatever pre-processing the editing software applies on top, the audio and frame rate conversions when necessary, whatever other post-processing the video editing software might do before sending video to the encoding CODEC, packing the output file, etc. Each and every intermediate processing step may add a number of potential bottlenecks on top of the resource sharing issues for the second socket if they are not perfectly tuned to work with each other, which they rarely are when combining software from multiple independent sources - this can already be hard enough to achieve even within one's own code.

So basically we agree. The problem ISN'T the RAM, it's the codec. Putting that RAM in there will make bugger-all difference, a few percent at most.

[vlad777]

Check out this 18 core Xeon!

[miguelvp]

That´s it!

Time to ask my work to get me a better machine than this crappy E5640 dual xeon at 2.67 GHz 8 cores each.

I can´t work with this sub'par system anymore after watching that.



Then again maybe it won´t allow me to take coffee breaks if it compiles my stuff in less than 5 minutes.

Edit, and yeah I can make those processors sweat a bit:

[necessaryevil]

Tried out some other memory yet, Dave?