[Will Duncan]

I may be just be lucky, but I haven’t had client machines with dedicated storage in over 5 years. Then again, I work on mostly collaborative projects for television or long-form / feature length productions and convince clients with smaller setups to have dedicated servers for various purposes.

I’ve built a few smaller scale 10GbE setups with consumer hardware for on-site productions over the last few years with very poor results. I’m not a particularly skilled network engineer but we ran in to a lot of issues with latency and speeds. I am pretty much exclusively using Arista switches at this point. They are probably the best investment I’ve made towards infrastructure in many years.

I am excited to see client machines with built in 10GbE though. My biggest concern will be seeing a lot of cheap storage solutions just into the prosumer space. I spent years battling failing thunderbolt RAID systems. Synology was actually a blessing in disguise for lower budget projects just because their software and system was so much more manageable. QNAP I haven’t had a lot of time with, but some of their newer offerings are very impressive from a hardware standpoint. I hope to see the SAN manufacturers really step up their game as a result. At this point we’re starting to battle how many K’s are loaded into whatever the latest camera is and it’s hard to stay ahead.

[Will Duncan]

Without a dedicated video card, it’s going to be tough. CPU and RAM meet minimum requirements, but the onboard Iris card will be a major bottleneck. Native MXF from the camera would probably benefit from converting to something else to reduce the load, but that’s a band-aid on a bigger wound I’m afraid.

Complexity of your timeline will always be an issue as well.

I haven’t personally worked with external GPU’s as of yet. But I do know people working with RED footage who offload that heavy lifting to an external box.

The good news, we can always work smarter. Hardware shouldn’t be a limitation unless you’re working for time / speed on deadline. Premiere is so much better at handling Proxy workflows now, the only major downside is taking the time to convert everything, which I personally welcome in the age of how fast can we produce stuff. Gives me time to organize and put things away properly.

[Will Duncan]

You may have just been lucky with the cleared cache fix. We’ve tried a year ago when we first saw the issues appearing in larger productions and the results were inconsistent.

We have 18 Mac’s being used for productions in-house, about 1/3rd are nMP with D500 or D700 cards. Only one doesn’t have the issue, which oddly enough is the first one we purchased. We battled this with TV deadlines and it was a nightmare for 2 seasons.

We have iStats Menu installed on most clients, and using the fan controller in the software to crank the fan speed on the nMP trash cans solves issues on all projects that are 1080p and under 30 minutes long it seems.

Which means it’s a cooling issue that has been documented all around the forums. DaVinci Resolve forums have a lot more chatter about it though. Apple hasn’t publicly said a word, although there are plenty of threads with the same problems we’re having.

4k and feature length content is a different story. Crank the AC and the fan speed, or utilize image sequence exports and then convert (as a workaround) which isn’t an ideal solution.

[Will Duncan]

We have this issue with D500 and D700 GPU’s on the nMP.

Adobe Premiere and DaVinci Resolve both cause the GPU to overheat. One of our 5 machines doesn’t have the problem, at least not often enough to notice. The downside is that on large exports, even with the fan speed pegged, we’ll have to go through massive projects frame by frame looking for the glitches. Sometimes they only appear once or twice.

During TV productions this season, we spent a lot of time reexporting. We saw a ton of glitches. They’re drastically less common with 1080 footage and exports, but when we switch gears to 4k or above, I know we’re going to have some long nights ahead of us on those projects.

iStat Menu and bumping up the fan speed solves the problem for smaller projects in Premiere which is an $18 fix. There are free fan speed controllers but you get a lot of nice tools with iStats, so I recommend it.

Resolve we had less luck with. Bumping the fan speed up solved 98% of the problems, but on a feature length 4k production there were still a lot of problems. We exported the color project as an image sequence (it’s massive in file size) and then brought it back in an converted it to ProRes 444. This solution added roughly 5-7 hours of computing time.

We haven’t exported the final product yet. But the image sequence and conversion to ProRes has been a solid workaround. I just don’t want my editors and production teams to think that’s some kind of fix. Adding a half day of computing time to your workflow is a nightmare.

[Will Duncan]

h264 w/ .mp4 in Premiere is limited to a mono, stereo or 5.1 conversion. If you set the export to Format: Quicktime, then the Preset to Custom, then in the video Tab select H.264, the Audio tab will now have channel mapping options.

The output will be an .mov for that file though. You SHOULD just be able to change the extension to .mp4 after export. At least I’ve seen a ton of people do that who use Premiere.

With ffmpeg from Terminal you just tell it to copy file.mov and output file.mp4, takes like .05 seconds.

[Will Duncan]

I haven’t noticed a memory leak on OS X, but I don’t have any Windows machines to compare at this time. I’d assume a memory leak would be isolated to the windows version.

I notice a lot of rendering problems, and generating peak files, conforming, etc…is taking a rediculously long time. Premature upgrade based on Adobe’s track record the last two versions, but I actually NEEDED the proxy on/off toggle and figured that feature might outweigh the bugs. So far, it’s been incredibly mysterious. Eat machine has it’s own bugs with PP 2015.3.

[Will Duncan]

.mp4 is a wrapper / container and not an actual video format.

Which codec are you using when you export?

Audio channel limitations are based on the codec. Most of the time people cook mp4’s it’s for a preset h264 which comes out as a .mp4 or .mov depending on the preset. Most of which are stripped down to a Stereo Pairs I believe.

[Will Duncan]

I spend 1/3 of my year doing large multicam Premiere projects (up to 24 cameras in one multicam), and my general rule of thumb is to get editors to build a line cut and ditch the multicam. I can always go back to it and grab changes I want and lay them on top of the timeline at a later time. But once timing is close we squash it.

We use Premiere and take it over to Resolve for color, so I have them flatten everything prior to color and then drop all effects, graphics and transitions onto the timeline once we have that finished.

Any time editors get too far ahead, put graphics and start making audio tweaks, etc…we just end up in a world of technical troubleshooting and we have to go in, create a new sequence, copy it over, blow everything away and then flatten.

Maybe I’ve been way off the mark, but I’ve met a handful of people working in a manner similar to myself. So for now, I’ll stick to what works.

It has been getting better over the last 3 years though. Sans last year final exports kept having popping audio and Adobe wouldn’t fall on their own sword and admit it was a bug.

[Will Duncan]

They’ll probably replace the whole logic board for that.

[Will Duncan]

I haven’t used that sync tool before. I’m mostly MacOS / Linux at work, and a split between rsync and robocopy, which looks to be the base of a lot of tools written for Windows.

I’ve spent a lot of time over the last few months transferring multiple hundreds of TBs of data, mostly over a 10GbE local network between OS X and NTFS RAIDs along with an object storage array.

rsync has definitely been the most reliable tool to date. But so much of the documentation, examples and search results are based on ssh’ing into a server where network speeds and disk IO is very slow.

Here is a good link that I came across. I am referring to the comments:
https://news.ycombinator.com/item?id=12058253

Since we’re on a 10GbE local network, I opted to pass `-avhW` when dumping a drive from the field. I don’t really have anyone to bounce this stuff off of, but passing the W in the arguments gets me closer to 180mb/s vs the typical 90-120 since it’s not splitting up the file now. So a little bit of a speed boost it seems which adds up when you have a lot of data.

I’ve never been able to achieve anywhere over 180mb with rsync though, and drive to drive speed should be much much higher.

With Finder I’m still closer to 350mb/s, but it’s my understanding that OS X Finder can do some bad things to large volumes given enough time and copies / writes to the volume. I can see 900mb/s with Finder in transfers to btrfs volumes, but those are newer and will probably degrade a lot as they get full.

I think what I need to learn to do is to run multiple rsync processes in parallel with each other. It’s staying organized that’s going to be the hard part.