At the start of 2017 it was a sad state of affairs for using a Mac on-set for heavy duty processing. The MacPro dated back to 2013 and the recently re-designed MacBook Pro Models didn’t come equipped with Intel’s latest Kaby Lake Processors nor did they exceed 16GB of RAM which has been a limitation for a long time now. The choice was to buy outdated technology, buy new inadequate technology or find another solution.
I had the privilege to use a Codex Vault XL for an Alexa 65 Job in January and got very well acquainted with the technology. When the Vault landed in Australia DOA (Dead On Arrival) the only option was to pull it open to see if I could get it running. Turns out it was just a connection on the power supply that had come loose in transit, but this process of looking inside made me realise that it was just a giant custom built computer. This got my brain ticking and I began to think outside the box. If a custom built computer can handle one of the most data heavy codecs in the world, 6K ARRIRAW, it can copy it, process it, transcode it. If you take away the proprietary technologies you just have a computer, which you can buy and build yourself which lead me to Hackintosh.
I started researching and compiling information, delving deep into the Hackintosh World. I’d never even built a computer from scratch before but did have some background knowledge such as pulling apart iPhones and MacBook Pros for DIY Home Repairs. I knew there would be speed humps along the way but I had a vision and wanted to bring a new level of game to the world of on-set transcoding.
Below is my finished rig alongside the documentation that I put together to educate clients about the advantages of using this over a standard data management kit.
PREMIUM DATA KIT
Over the past year I have seen requests for on-set transcoding steadily increase. It’s always a tricky service to deliver as the MacBook Pro in every Data Kit just can’t keep up with the workload and results in lots of unnecessary overtime. I see transcoding becoming a standard in the future as camera formats evolve and get more complex, it got me thinking, there has to be a better way to do this.
Designed completely from the ground up, the Premium Data Kit is the complete solution for on-set transcoding. Built specifically with quick turn around times in mind it offers transcoding capabilities up to 10x faster then a Standard MacBook Pro Data Kit.
Shoot high quality ARRIRAW and transcode at twice the speed of real time. Often avoided due to large file size and processing times, with transcodes this fast there is no reason not to utilize ARRI’s flagship format on your next production.
Phantom .cine Files are anything but edit friendly and always require transcoding. 1 Hour of Phantom Flex 4K Footage can be transcoded in 30 Mins with the Premium Data Kit where as a Standard MacBook Pro Data Kit would do the same work in 5 Hours. Amazing!
Shooting 4K or 3.2K ProRes 444XQ? It’s not the easiest codec to edit because of the large file sizes and drive speed limitations. Transcoding can convert your footage to a lower tier HD ProRes 422 to deliver your footage Post-Ready.
RED is still RED and remains the most difficult format to work with. Unless you are equipped with a RED Rocket X Card that is not guaranteed to be future proof with new RED Formats, it’s near impossible to get amazing transcode speeds. That being said, the Premium Data Kit combined with the ‘New On-Set Transcode Workflow’ still offers a modest speed improvement and time saving.
Anything to do with processing data, be it transferring or transcoding, you are always at the mercy of the weakest link in the chain. 99% of the time the Achilles’ Heel rests in the hard drives provided for each job. This problem will take years to solve, so in the interim I have devised a solution that will boast faster turnaround times. All I had to do was reinvent the workflow.
Utilizing the Super Fast SSD in the Premium Data Kit I can offload cards to this internal drive very quickly, creating a separate backup of the footage solely for transcoding. I then set off the transcode from the internal drive and start the transfer of the data from the camera card to the client drives simultaneously. By running both in unison you save time, often transcodes are complete before the card is finished being backed up. Due to the high specs of the machine there is no risk of errors while multi-tasking so your data will be completely safe and secure.
Portability is key for equipment on-set and data equipment is no exception. I drew inspiration from the design of Apple’s MacBook Pro when crafting the Premium Data Kit, I essentially wanted to create a jumbo laptop with the speed of a desktop computer. Constructed around the smallest full sized computer case on the market with custom fitted brackets to mount the screen on the enclosure. It has a wireless keyboard and trackpad where you’d expect and the screen folds down for travel. As you’d expect with any piece of film equipment, it comes with a road case. I enlisted Melbourne’s Aerolyte to construct a custom case made specifically for the unique shape of the Premium Data Kit. This provides rugged protection making it suitable for Air and Road Freight within Australia and Internationally.
The Premium Data Kit is built upon the Hackintosh Architecture which means that is runs a fully operational version of macOS despite not being an official Apple Computer. This is imperative as we rely on Mac Software, ProRes Codecs and OSX Formatted Drives for all of our daily work. I made this choice so that I could employ the use of technologies not yet adopted by Apple, such as the newest Intel Processors and NVMe SSDs which give me Internal SSD speeds of 2000MB/s comparable to the 110MB/s of a Lacie Rugged Drive. When building the machine only the highest quality parts were selected, no expense spared, the best of the best to ensure maximum speed, reliability and less wasted time. The internals are all modular which enables incremental upgrading, which means I can continue to update the machine as new technologies emerge. This keeps the kit at the forefront of the Data Management/Transcode World, a feat that isn’t possible with a traditional Apple Computer.
Please see below for a full list of tech specs:
- Quad Core Intel i7 Kaby Lake CPU Overclocked to 4.8GHz
- 64GB of DDR4 RAM @ 3200MHz
- Nvidia GeForce GTX 980 Ti – 6GB GDDR Graphics Card
- 1TB NVMe SSD (Read/Write @ 2000MB/s)
- 2TB RAID 0 SSD (Read/Write @ 850MB/s)
- 2x Next Gen Thunderbolt 3 Ports
- 2x Next Gen USB 3.1 Ports (1x USB-C, 1x USB-A)
- 5x Current Gen USB 3.0 Ports
- Highspeed 802.11ac WiFi
- Bluetooth 4.0
- 8x Low Noise Internal Fans
- 21.5” Full HD Display
- Silverstack and Shotput Pro Data Management Software
- DaVinci Resolve, Codex Production Suite, Redcine-X
- Various Other Data Management Softwares
That pretty much gives an outline to prospective clients of how the system works, why it differs to a normal setup and the advantages that is has to offer. I’ve been field testing this unit on-set the past 5 Months and can now say that it’s 100% reliable. More often then not transcodes are done before I’ve finished backing up the footage to the client drives, the system doesn’t crash any more or less then a normal Mac Computer and the advantages that it can bring to jobs that have quick turnaround times are paramount. Now, with all that being said, the R&D Period, the assembly and most of all the installation of macOS and all the other quirks of this process wasn’t as straight forward as one might think. I’m going to run through my setup process and all of the things that I learned along the way.
BUILDING A HACKINTOSH
First of all your two biggest resources when diving into the Hackintosh World are tonymac and the hackintosh subreddit. There is a wealth of information on the tonymac forums and all throughout reddit history, read long, read deep and you will be able to solve 95% of problems yourself. When you are absolutely stuck, reach out and the community will help, I had a bunch of trouble in the beginning and people were amazing in the troubleshooting process. But try to abide by my golden rule, don’t ask for help unless you’ve exhausted all options within your power. This basically means don’t go hassling people for assistance when you haven’t read the backlogs of forum posts and tried every last potential solution detailed online.
I’m going to start with my final part list so there is context for what I am referencing here on in. My build is as follows:
- macOS Sierra 10.12.3
- Motherboard: Gigabyte GA-Z170X-Gaming 5 with BIOS F20
- CPU: Kaby Lake i7 7700K
- CPU Cooler: Noctua NH-U9S with Noctua NF-A9 PWM as an Extra Fan
- RAM: 64GB Corsair Vengeance LED
- Graphics Card: Gigabyte GeForce GTX 980 Ti
- NVMe SSD: Samsung 960EVO 1TB
- SATA SSD: Crucial MX300 1TB SSD x2
- Extra: Gigabyte GC-ALPINE RIDGE (2x TB3 Ports via PCIe)
- Case: SilverStone Grandia GD09
- Power Supply: Corsair RM650i 650W
- Inlet Fans: Corsair 120mm Fan x2
- Exhaust Fans: Deep Cool 80mm Fan x2
- Keyboard: Apple Magic Keyboard
- Trackpad: Apple Magic Trackpad 2
- Wifi and Bluetooth: OSX Wifi Card
- Monitor: BenQ 21.5″ Full HD
- Various USB-C and TB3 Adaptors
- Brateck LCM CM (With Custom Modification)
- 50cm HDMI Cable
- Custom Y Power Cable
- Custom Transit Case
Software for Setting Up a Hackintosh
You require certain software when setting up a Hackintosh, I know there is a lot of debate in the community over if you should use UniBeast/MultiBeast or do a clean custom install with Clover and the effectiveness of some of the other tools. Being that I installed macOS on my rig over ten times trying to troubleshoot various problems I found that having all tools readily at your disposal is useful for quickly trying fixes recommended by others online. This is what I have in my essential toolkit:
- PlistEdit Pro
- EFI Mounter
- Clover Configurator
- Kext Utility
- Hide/Show Hidden Files (Paste Text from TextEdit into Terminal)
I built my Install USB with UniBeast and used MultiBeast for setup each time. Though based on my readings, if I were to do it again I would use a Custom Clover Install.
My Setup Process
When I completed this build Kaby Lake wasn’t supported in macOS and NVMe was still tricky so it was always going to be an uphill battle. I came across many bottlenecks in my setup process and it felt like an impossible slog at times. If one thing went wrong it’d have a snowball effect and it was often easier to go for a clean reinstall and start my process again then it was to figure out exactly what was causing the issue. Below I’ll share my installation and setup cheat sheet as well as explaining the speed humps that I had to cross.
NVMe on Install USB
As I was installing macOS to my NVMe SSD, I soon discovered that it wasn’t possible without some custom tweaks. Most of the guides online explain how to install macOS on a standard SSD but when NVMe comes into play, it won’t show up by default in the macOS USB Installer. I found that I needed to mount the EFI Partition of my Install USB using EFI Mounter, navigate to /Volumes/EFI/EFI/CLOVER and open my config.plist in PListEdit Pro. Here I would navigate to Root -> KernalAndKextPatches -> KextsToPatch and paste in the complete set of 17 Values for IONVMeFamily Pike R. Alpha Patches as seen below:
I found the easiest way is to download my plist, unzip it and open it in PlistEdit Pro, then you select all 17 ‘KextsToPatch’ and then ‘Paste as Child’ on your plist ‘KextsToPatch’, then save and close. You will also need to paste IONVMeFamily.kext to /Volumes/EFI/EFI/COLVER/kexts/Other. Doing this enabled me to use my UniBeast macOS Install USB to boot from nothing into the macOS Installer and install straight to my NVMe SSD.
There are more guides online of cleaner and better ways to get an NVMe SSD working on your system, I tried them and they didn’t work for me, thus is why I reverted back to this method. That doesn’t mean they won’t work for you though so it’s worth looking into other methods and searching and reading about NVMe on Hackintosh.
My Cheat Sheet
*Please note these instructions work flawlessly for the hardware/software combination listed above, any variations of hardware/software could provide different results*
1. Install macOS via Hackintosh USB
2. Upon full install, run MultiBeast and install as follows:
3. Use PlistEdit Pro to copy ‘KextsToPatch’ 0-15 from config1.plist to config.plist on your Boot Volume EFI. You can use EFI Mounter to mount your Boot Volume EFI Partition and PlistEdit Pro can have multiple plists open at once. While in your Boot Volume config.plist change RtVariables -> CsrActiveConfig to 0x67 and Change Boot -> Timeout to ‘1’.
4. Navigate to /System/Library/Extentions (referred to as SLE in the Hackintosh Community) and find IONVMeFamily.kext and copy it to EFI/Clover/kexts/Other which again is your Boot Volume’s EFI Partition. If you can’t find SLE you can use the ‘Go To Folder’ Command in Finder (Shift+Apple+G) and paste in ‘/System/Library’ and hit go or you can use the text above for Hide/Show Hidden Files to Show Hidden Files and navigate there manually in Finder.
5. Open config.plist from EFI in Clover Configurator and add FakeCPUID: 0x0506E3. This step is to spoof macOS into thinking you aren’t running a Kaby Lake Processor, with newer versions of Sierra and High Sierra you shouldn’t need to spoof the CPUID.
6. Reboot. You should restart and actually boot macOS off your NVMe SSD or SATA SSD this time rather then relying on your Install USB for booting. If you don’t, there is a problem.
My Kaby Lake 7700K CPU has an Integrated GPU called the Intel® HD Graphics 630. There are many documents detailing how to get this GPU working, I followed them all and every time it cooked my system in the way of a kernal panic and required me to reinstall macOS before anything would function again. I eventually gave up on the iGPU and disabled it in the BIOS and relied solely on my Discrete GPU.
7. Download the newest version of Clover EFI from the Official Clover Site. Update Clover to the newest version via Installer. Make sure to use the ‘Customise Install Option’ and select ‘NVRAM EMU’ kext and ‘RC Scripts’. Once installed open System Prefs -> Clover -> NVRAM and change ‘Save NVRAM Contents to Disk’ to ‘Always’.
8. Check that NVRAM is working via ’sudo nvram MyVar=TestValue’ and ‘nvram -p’. This process is done in Terminal. The command ’sudo nvram MyVar=TestValue’ will create a variable called ‘MyVar’ in your NVRAM and assign it a value of ‘TestValue’. The command ‘nvram -p’ will display everything currently in your NVRAM. After running the first command you should see the Variable and Value in your NVRAM. If you do then reboot and try ‘nvram -p’ again to verify that NVRAM is holding information through the reboot process.
NVRAM is not working in BIOS F21 for Gigabyte GA-Z170X-Gaming 5 Motherboard, revert to BIOS F20 for working NVRAM.
8a. Copy FakeSMC.kext from /Library/Extensions/ (often referred to as LE) to your Boot Volume’s EFI/CLOVER/kexts/Other Folder. Delete FakeSMC from /L/E/ and run Kext Utility to rebuild permissions. Kext Utility will automatically rebuild permissions upon opening. Reboot to test system boots up. MultiBeast installs the FakeSMC.kext to /L/E/ by default which many members of the community argue is the wrong place to put it, this process moves it from /L/E/ to your Boot EFI Partition where it should rightfully belong.
8b. Install HWSensors App, Install the App Only.
8c. Copy Hacked ‘FakeSMC.kext’ with PlugIns to your Boot Volume EFI/CLOVER/kexts/Other Folder, Use the ‘Replace’ Option When Prompted by Finder. Right Click -> Show Package Contents of FakeSMC.kext in your EFI, navigate to PlugIns and delete CPUSensors.kext. Reboot to test system boots up.
8d. Open HWMonitor to verify stats are shown. Install Intel Power Gadget and test that it works.
I found that using a Fake CPUID to trick macOS into thinking your Kaby Lake CPU is something else will glitch out the ‘CPUSensors.kext’ within HWMonitor and cause a kernal panic on boot. Basically all sensors work except those relating to the CPU, I couldn’t find a way to get around this except for adding the Intel Power Gadget to the mix. I currently run my rig with iStat Menus which is great, it taps into information from HWMonitors and it’s kexts, but if I need CPU Stats for load and temperature I open Intel Power Gadget. Not perfect but good enough for me.
9. Open your Boot Volume EFI config.plist and navigate to ‘System Parameters’ and add ’NvidiaWeb’, BOOL, YES. This is pretty straight forward, alternatively you do it via Clover Configurator.
10. Install NVidia Web Drivers and Reboot.
11. Open System Prefs -> NVidia Driver Manager -> Select NVidia Web Driver and Reboot. Sometimes you won’t need to use this step as NVidia Web Drivers will be selected by default after you install them. The web drivers will work if your NVRAM is working which is why we sorted that out before. If your NVRAM isn’t functioning you’ll default back to Apple’s Drivers which make your High End GPU a slug. NVRAM needs to work for your Discrete GPU to work.
12. Run the ‘iMac 17,1 Black Screen Fix’, Reboot.
13. Use MultiBeast to Update System Definition to iMac 17,1. Check your Boot Volume EFI config.plist in PlistEdit Pro, it’s under Root -> SMBIOS -> ProductName. It should say ‘iMac17,1’.
14. While the config.plist is still open, navigate to ‘System Parameters’ and add ’NoCaches’, String, Yes. Save config.plist and Reboot.
15. Run Kext Utility and Rebuild Caches.
16. Upon completion delete the recently created ‘NoCaches’ Parameter from your Boot Volume EFI config.plist. Reboot.
17. Edit EFI config.plist. Boot -> XMPDetection = YES and SMBIOS -> Trust = YES.
18. Boot into BIOS and Enable XMP Profile. Reboot. Check System Information to ensure RAM is now reading and running at 3200MHz. Shut Down.
19. Remove NVMe SSD or macOS SSD physically from the computer. Install Windows 10 on a Different SSD.
Installing Windows is a lot more straight forward then installing macOS on a Hackintosh Setup. It’s vital that you remove your SSD with the macOS Install on it before you install Windows, the two operating systems clash both at install time and afterwards. I initially didn’t know this and had a lot of trouble installing Windows. Once installed, the Windows EFI was present on my macOS SSD rather then the Windows SSD which was messy. Best to remove all other hard drives and just have your Install USB and your intended destination hard drive connected. I’ve done it this way twice now and it’s been flawless.
20. On Windows, install the Gigabyte Thunderbolt Driver. Then install the Gigabyte Thunderbolt FW Update Tool. Navigate to C:\Program Files (x86)\GIGABYTE\flashTBT and run the file “flashTBT_100.exe”. Shutdown your system and then completely pull power for 30 Seconds.
I found that I needed to disable the option in my BIOS for ‘TBT USB3.1 Force Power’ in order for both Thunderbolt 3 Ports to work.
22. Test Everything
23. After installation of REDCINE-X open you Boot Volume EFI config.plist in Clover Configurator and enable the ‘Shutdown Fix’ for proper shutdown. I’m not sure why REDCINE-X messes around with my shutting down procedure, but it did.
Now, I’m sure there are better ways to do what I did above, some of my steps could be redundant, there could be cleaner methods of achieving the same result. But in January 2017 I spent a solid two weeks messing about with my rig trying to get it working. It was stressful and a major pain in the ass. I’ve followed the above steps four times now when doing a clean install on my Hackintosh and haven’t had any issues, so I stick by it for me. For you, I suggest you follow one of the many other guides online but use this as supplemental information in combination with reading lots of forum posts to gather a good array of knowledge to solve any issue that you may come across.
My original setup was built using a Gigabyte GA-Z170X-Designare Motherboard based on recommendations from the community. It seemed like the natural successor to the Gigabyte GA-Z170X-UD5 TH Motherboard and had a lot of good features. The main feature for me being at least two Thunderbolt 3 Ports.
I had a lot of issues with this board and ended up canning it, please check out this thread in relation to my woes: GA-Z170X-Designare USB-C Issues
Basically I went through two boards, the first one got RMA’d with faulty TB3/USB-C Ports as detailed above, the second board had similar issues but not quite the same. All of the ports would work as USB-C from both directions, but only one TB3 port would work. I purchased my GC Alpine Ridge Card and tried connecting it to the Motherboard with the TB Header to get 3x TB3 Ports but it didn’t work as that GC Alpine Ridge Card isn’t officially compatible with the GA-Z170X-Designare Motherboard. I ended up returning that Designare MB and got my current Gaming 5 MB which was listed as compatible with the GC Alpine Ridge Card.
There are actually two different TB Headers on the seperate motherboards in this instance, the GC Alpine Ridge Card has both connections but it didn’t work with the Designare TB Header despite everything plugging up correctly. Weird but that’s the way it is. It all works a-okay now with my Gaming 5 MB, it’s great having 2x TB3 Ports.
CPU Overclock Tests
I’d never overclocked a CPU before but after doing a fair bit of reading I learned that it isn’t all that hard. So I dived in and ran a bunch of tests to see what I could get out of my CPU with a bit of OC. This is my raw data:
In macOS I was using iStat Menus / HWSensors in combo with Intel Power Gadget to monitor my CPU Temperatures. Intel Power Gadget would display the actual CPU Temp and I would verify that with my CPU Heatsink Data in iStat Menus. I was using the Yes CPU Test (Unzip, Open Text File, Copy to Terminal and Press Enter) to run my CPU Stress Tests in macOS. As my CPU was 4 Core with 8 Threads, I need to run the yes command 8 times, one per thread.
In Windows I was running CoreTemp and Real Temp simultaneously to monitor my CPU Temperatures and they were delivering very similar results. I used AIDA64 for my CPU Stress Tests based on various recommendations.
What I discovered is that my CPU seemed to run hotter in macOS then it did in Windows 10, strange. It could be that HWSensors and Intel Power Gadget aren’t providing the most accurate 100% readings of my CPU compared to the various CPU Sensors that I had running on Windows. What intrigued me further is that I would get a solid overclock running in Windows but then I would boot into macOS and it’d crash on boot, the only way I could get macOS to boot would be to increase the Vcore Voltage. So seemingly macOS needs a bit more power to boot up then Windows. So could this justify the hotter temps in macOS over Windows or was it still potentially faulty sensor information? I never got to the bottom of that question, for me, I’d be running macOS 95% of the time, I got a stable overclock at 4.8GHz running at a Vcore Voltage of 1.315V and my CPU Temp usually sits around 83°C – 87°C. A lot of sources online said that you shouldn’t really run your CPU hotter then 80°C as it can degrade its life over time, but the life of a CPU is meant to be around 10 Years, if I’m still using my 4 Core Kaby Lake i7 4.8GHz CPU in 5 Years I’d be very surprised. The shelf life exceeded the use life that was required of the CPU so I was happy to lock in this slightly hot OC on my CPU.
The two systems that I would be comparing here are my new Hackintosh Rig and my 2012 MacBook Pro. Being that a MacBook Pro similar to mine is the golden standard for Data Management here in Australia I opted to use this for transcode tests as it’s pretty representative of what everyone else is using.
The MacBook Pro Specs are as follows:
- MacBook Pro 10,1 with macOS Sierra 10.12.3
- CPU: Intel Core i7-3720QM 2.6GHz
- RAM: 16GB @ 1600MHz
- Graphics Card: Intel HD Graphics 4000 / NVidia GeForce GT 650M
- SSD: 256GB SATA
When running the tests I took the exact same source footage direct from a camera card and put it on the fastest internal SSD both the MacBook Pro and the Hackintosh. I’d then open DaVinci Resolve which was operating on the same version between both systems, I’d setup identical projects and setup identical transcodes. I’d run them both, record the data and compare. Here were my findings:
ARRI Alexa Formats
ARRIRAW Open Gate -> ProRes422HQ 1920×1080
MacBook Pro: 5.5fps, 6:55 Mins, No LUT
Hackintosh: 50fps, 46 Secs, With LUT
Notes: Hackintosh CPU at 50%, GPU Processor Maxed Out, GPU Memory at 10%
ARRIRAW 16:9 -> ProRes422HQ 1920×1080
MacBook Pro: 8.5-9fps, 1:31 Mins, No LUT
Hackintosh: 68fps, 12 Secs, With LUT
Notes: Hackintosh CPU at 500% out of 800%, GPU Processor Close to Maxed Out, GPU Memory at 10%
ARRIRAW 4:3 -> ProRes422HQ 1920×1080
MacBook Pro: 6-7fps, 2:54 Mins, No LUT
Hackintosh: 58fps, 20 Secs, With LUT
Notes: Hackintosh CPU at 50%, GPU Processor Maxed Out, GPU Memory at 10%
ProRes 3.2K 444XQ -> ProRes422 Proxy 1920×1080 w/LUT
MacBook Pro: 18fps, 1:25 Mins
Hackintosh: 58-59fps, 26 Secs
Notes: Hackintosh CPU Close to Capping Out, GPU at 50-60%
2.8K ProRes444 -> ProRes 422HQ 1920×1080
MacBook Pro: 16fps – 36 Secs
Hackintosh: 50fps – 13 Secs
3.2K ProRes 444 from Amira -> ProRes 422HQ 1920×1080 w/ LUT
MacBook Pro: 18fps, 3:01 Mins
Hackintosh: 58fps, 56 Secs
Notes: Hackintosh CPU Close to Capping Out, GPU at 50-60%
4K Phantom -> ProRes 422HQ 1920×1080
MacBook Pro: 5-5.5fps – 2:13 Mins
Hackintosh: 55fps – 13 Secs
Notes: Hackintosh GPU Capped Out, CPU at 50-60%
RED 8K 5:1 -> ProRes422HQ 1920×1080
MacBook Pro: 2.5fps, 5:51 Mins
Hackintosh: 5fps, 3:31 Mins
R3D 5K 5:1 -> ProRes 422HQ 1920×1080
MacBook Pro: 6-10fps – 10:01 Mins
Hackintosh: 8-12fps – 6:11 Mins
Notes: Hackintosh CPU Capped Out (Not Overclocked, Running at 4.2GHz), Graphics at 10%
Since I ran these tests I have used the rig extensively on-set with constant monitoring of frame rate and transcode times to identify what exactly is causing the bottleneck. Based on these initial findings and my further investigation there is no deadset weak link in the chain.
ARRIRAW and Phantom Formats are heavily GPU reliant, both formats cap out my GPU which would indicate that the GPU is the weak link but transcoding these formats at over 50fps is double realtime and 10x faster then the equivalent on a MacBook Pro which I would hardly consider slow.
The ProRes Codec is CPU heavy for decoding and encoding which is causing the bottleneck here. The GPU is still being utilised but not capping out. ProRes Transcodes run at 3-4x speed compared to the MacBook Pro and can be benefitted further by the ‘New Transcoding Workflow’ that I detailed above.
RED is RED and still to this day sucks unless you have a RED Rocket-X Card or a 28 Core CPU. My CPU is capped out obviously and the GPU is barely utilised. CPU is the weak link in the chain here.
So basically, you get some pretty solid advantages unless you are working with RED. Most jobs these days I find are shooting on ARRI Alexas in either ARRIRAW or 3.2K/2.8K ProRes 444, the Alexa Mini is super common as well as the Alexa XT and SXT. So the lack of speed working with RED isn’t a deal breaker as it doesn’t get utilised all that often. I’ve had 6K Open Gate ARRIRAW from an Alexa 65 on my Hackintosh Rig and it plays back at full res in real time from Resolve no problems. Other transcodes that I’ve thrown at it from 2.8K ProRes to H265 to Phantom .cine Files, it’s performed admirably and facilitated fast workflows that just wouldn’t have been possible before.
Once I got past the initial setup of my Hackintosh there haven’t really been any issues, except one. If you have done your research you’ll know that when using Thunderbolt on a Hackintosh you can not hot swap Thunderbolt devices. On Windows, no worries, on a native Mac, no worries, but 3rd Party Motherboards in combination with macOS won’t allow you to hot swap / hot boot TB devices. This basically means that if you turn your Hackintosh on, boot in macOS and then plug in a TB Hard Drive it won’t show up. It’s not until you reboot the system that the drive will mount and appear on the desktop as normal. One other thing you’ll need to do once the hard drive mounts to the Hackintosh is to Right Click and ‘Get Info’, down the bottom of the window you’ll have permissions, unlock the lock if required and make all permissions ‘Read/Write’, you’ll only need to do this once per drive for the duration of it’s lifetime. For most people this isn’t an issue but it is a pain when using this rig in high pressure environments on-set. Keyword there being pain, it’s annoying but not a deal breaker. You can work around it, most of the time it’s only your hard drives that are connected via Thunderbolt, most card readers are USB3. You only need to connect your hard drives once per day if you’re in one location, that’s one reboot, if you have multiple location moves thats a few reboots but I build in the rebooting procedure into my setup time and it isn’t much of a worry.
Earlier on in the year I had an Alexa 65 Job, I was running the Codex Vault off my Hackintosh Data Rig and all was going well. The Vault interfaces with Hackintosh through a glorified 10G Ethernet to Thunderbolt Convertor in the form of a Myricom PCIe Card in a Sonnet PCIe to Thunderbolt 2 Chassis. This works fine, hook it all up, reboot as normal and I could interface with the Codex Vault. But then I needed to use 2x 10TB Lacie 5big Drives each setup as RAID 0 and this is where the trouble started. I’d hook up both drives daisy chained together through one Thunderbolt Port and the Codex Vault 10Gig Ethernet Network was through the other Thunderbolt Port, I’d then reboot the system and get this:
This is what a kernal panic looks like. The system would start to boot into macOS, kernal panic as above and then restart itself. It’d stay stuck in this boot loop and just keep cycling through until you held the power button down and forced it to turn off. Funny thing though, if I leave the Kernal Panic Boot Loop going for say 5 Mins or so, eventually the system will boot as normal with both drives mounted and working perfectly.
Reaching out for help we identified that the kext causing the issue was called ‘com.lacie.driver.mvumi’ which comes from the Lacie RAID Manager software. I never got around to troubleshooting this actual kext as the job was moving too fast and I just dealt with an unpredictable 5-8 minute boot time each time I set the rig up. The problem would be that the RAID Drives won’t mount or be useable without the Lacie Software, though it was the Lacie Software that was causing the problem. The next time that I used the same hard drives with my rig I installed a new version of Lacie RAID Manager after uninstalling the old version and had zero issues, the drives worked flawlessly, hopefully Lacie had issues a fix. I’m yet to test it again in combination with the Codex Vault, we’ll just have to wait and see. If the issue did occur again I’d remove this kext temporarily and see if the system booted up, if it did and the drives were appearing it’d be sweet as, but if not a more serious problem would be at hand and I see no option but to stick with the current prolonged boot method.
THE FUTURE OF THE PREMIUM DATA KIT
One of the biggest bummers about anything to do with computers is the speed in which they get updated. I equipped my rig with a 980 Ti GPU which at the time was the 2nd best GPU that would work with macOS then 3 Months Later NVidia finally released Web Drivers for the 1000 Series GPUs and released the 1080 Ti GPU which would have been a much better candidate for my Data Rig. I’ve looked at upgrading to the 1080 Ti but have decided against it for the time being, the GPU is only capping out ARRIRAW and Phantom Transcodes which still run incredibly fast so until I upgrade my CPU the GPU is going to stay as is.
With recent updates to the iMac and MacBook Pro Line which introduce macOS to Kaby Lake CPUs things will get a lot easier in terms of setup. With new versions of Sierra and High Sierra there will be no need for FakeCPUID or disabling the iGPU which will be nice little bonuses. Which may even allow CPUSensors to work natively and bypassing the Intel Power Gadget Workaround.
The beauty about my Data Rig is that it’s able to be upgraded over time. My current plan is to hold out till the end of the year and see what happens in the Hackintosh Scene when the new iMac Pro comes out. It’s touted as having an 18 Core CPU which if replicated in the Hackintosh World would significantly speed up ProRes Transcodes as well as giving a solid speed boost to dealing with RED. Combo this with a new Graphics Card and it’ll be refreshed and ready to go. Other hot topics include Intel’s Cannonlake Platform which brings 6 Core CPUs to the mainstream. The problem is going to be finding motherboards that can run these new CPUs while having TB3 bundled in, as if you work in the film industry, Thunderbolt is commonplace be it hard drives or card readers. If you don’t have a system equipped with Thunderbolt it really isn’t going to cut it.
All in all, I’ve learnt a heck of a lot from this experience. I learnt how to build a computer from scratch, I learnt about setting up a Hackintosh and all the finesse that is required to iron out issues and lock down a fully working system, I learnt how to overclock, how to test overclocking and all about CPU Temperatures and CPU Cooling, I’ve expanded my transcoding knowledge along with a plethora of other skills.
If you are diving hard and fast into the world of Hackintosh then I hope this information serves you well and best of luck!
4 thoughts on “Building a Hackintosh for Transcoding”
Hello, have You tried using thunderbolt XR dock on Your hackintosh?
Hi Denis. Unfortunately I haven’t had the opportunity to use the TB XR Dock, most of the camera rental houses in Melbourne only provide the USB3.0 XR Docks. I’d be interesting to see how it works as the Codex VFS may bypass the mandatory reboot that you normally have to do for Thunderbolt on Hackintosh Systems.
Not sure if this was considered at the time of your tests for RED transcoding
I would say that poor render times for RED may be that Resolve is still set to pull from the debayer at full res, which is unnecessary for the purpose of creating 1080p renders which are a downscale anyway
You can change the Debayer size in Resolve in Project Settings > Camera Raw > RAW Profile: RED > Decode Quality.
Change from “Full” to “Quarter Res Good” or lower.
For 6K RED 8:1 footage with Decode Quality set to “Full”, we were getting 1-5 FPS render speeds for Avid DNxHD 1080p 36. When changed to Quarter Res, I now get 25-30 FPS which is better than realtime. And… the computer is a trash can Mac Pro!
No noticeable differences in quality when our asst editor compared some of the transcodes at full debayer and those at Quarter Res debayer.
You raise a very good point. The debayer setting makes a night and day difference in terms of transcode speeds for RED.
I had a job last year where the Director and Editor both demanded that we used ‘Half Res Premium’ for the RED 1080p Transcodes. I did tests all the way down to ‘Eighth Res Good’ and for the sake of offline files the quality difference was so small that it was almost imperceivable.
Despite my tests I couldn’t sell the Director/Editor on the time savings using a lower tier debayer setting. My solution to the problem was to update my Hackintosh to a 16 Core i9 CPU, CPU handles the RED Debayer and made a huge difference to transcode speeds. Now if I select ‘Quarter Res Good’ I’d be able to transcode 8K to 1080P at over 100fps, I’d need to check the exact figures though.
RED and NVidia have partnered up and soon we should be seeing more RED Processing being offloaded to the GPU which will help out a bunch.
Thanks for bringing the debayer settings up, I’m sure changing them will benefit many people out there doing transcodes for offline.