The marketing story about Apple Silicon is performance, and the performance is real. The parts that change how you build a live video rig are less obvious, and two of them can make a fast machine behave worse than the Intel Mac it replaced.

Unified memory changes how you spec a machine

On an Intel Mac with a discrete GPU there were two pools: system RAM and video RAM. A canvas lived in VRAM, and if you exceeded it, things fell over in GPU-shaped ways.

Apple Silicon has one pool shared by CPU and GPU. Practically, this is good news for video work:

  • No copy between system and video memory. A frame the CPU touched is already where the GPU can see it. This is why texture-sharing transports like Syphon are so cheap on these machines — there was never a bus to cross.
  • Large canvases stop being a VRAM question. A 8192 × 2048 canvas on a machine with 32GB has room; the same canvas on an 8GB machine is competing with everything else the system is doing.

The spec consequence: memory is the number that matters, and it cannot be changed later. A base-memory Mac mini will run a modest rig well and hit a wall you cannot buy your way out of after purchase. For live video, 16GB is a working minimum and 32GB is the number that stops you thinking about it.

The media engines are free performance you may not be using

Every Apple Silicon chip above the base tier includes dedicated hardware for encoding and decoding H.264, HEVC, and on newer chips ProRes. These are fixed-function blocks, separate from the CPU and GPU.

When software uses them, decoding several 4K streams costs almost nothing and the CPU stays free for everything else. When software does not — because it is doing software decode, or the codec is not supported in hardware — the same job lands entirely on the CPU cores.

This is where content preparation earns its keep. The same show, same machine:

  • HEVC or H.264 — hardware decode, minimal CPU, several streams comfortably.
  • ProRes — hardware decode on Pro/Max/Ultra chips, software on the base chip. Very high bitrate, so now your bottleneck is disk throughput rather than CPU.
  • VP9, AV1 on older chips, or anything unusual — software decode. One stream can saturate cores.
  • Image sequences — no decode at all, enormous disk bandwidth. Fine on internal SSD, poor over a shared network volume.

If playback is dropping frames, check what the media actually is before blaming the machine. Transcoding a problem file to HEVC often converts a frame-dropping show into an idle one.

Rosetta is where the surprises live

Rosetta 2 translates Intel code well enough that most applications simply work. The problem in live production is not applications — it is plugins and drivers.

A native application cannot load an Intel plugin. So a Mac-native host with an Intel-only plugin either refuses to load it, or the whole host has to run under Rosetta to accommodate it. And a host running under translation loses access to some native paths, which can cost more performance than the plugin was worth.

The places this bites in an AV rig:

  • Audio plugins. An old AU or VST that never got an Apple Silicon build forces a DAW or playback host into translation.
  • Capture card drivers. Blackmagic Desktop Video and similar are native now, but an old installed version may not be. Reinstall current drivers on any machine you have migrated rather than trusting what came across.
  • Virtual audio and video devices. These live at a system level and must be native. An Intel-only virtual device is not going to work at all.
  • Licence dongles and copy protection. Frequently the last thing to get a native build, and the thing that stops a show.

Check what is running translated:

ps -Ao pid,arch,command | grep -v grep | awk '$2=="i386" || $2=="x86_64"'

Anything in that list on a show machine deserves an explanation.

Display limits are per-chip, and lower than you would guess

This is the change that catches people replacing an Intel Mac. Display output capability on Apple Silicon is a property of the specific chip, not of ports or of adding a dock.

The base chips support fewer simultaneous displays than the Pro and Max tiers, and adding a Thunderbolt dock does not raise the ceiling — it just gives you more connectors competing for the same limit. Chaining DisplayLink adapters works by pushing frames over USB as compressed data on the CPU, which is a legitimate answer for a static signage screen and a poor one for live video.

Check the specific model’s stated display support before specifying a rig around output count, and treat multi-display playback as its own design problem — that is what the honest limits of multi-screen playback is about. The general lesson: if a rig needs many video destinations, get them out over NDI or SDI rather than as displays. Video transports do not have a display controller limit.

Thermals: better, and still a venue problem

Apple Silicon runs far cooler than the Intel machines it replaced, and the fanless models genuinely run silently — which is worth real money in a quiet room.

But fanless means passive, and passive means the enclosure is the heatsink. A MacBook Air rendering a canvas for two hours in a case under a desk in a marquee in February will throttle, and the symptom is not a warning — it is dropped frames an hour into the show, after everyone has stopped watching for problems.

Rules that hold up:

  • Anything doing sustained render work should have a fan. A Mac mini or a MacBook Pro, not an Air.
  • Air matters more than it used to. A Mac mini in a rack needs airflow around it, not a shelf with a cable bundle on top.
  • Test at temperature. A two-hour soak test in the actual venue tells you something a bench test cannot.
  • Watch for throttling rather than inferring it. sudo powermetrics --samplers smc will show you package temperature and any throttling, live.

Practical migration list

Moving an existing rig to Apple Silicon, in the order that saves the most trouble:

  1. Reinstall drivers and virtual devices from current installers. Do not migrate them.
  2. Audit for translated processes with the command above, and resolve or replace anything that appears.
  3. Re-grant permissions. Screen Recording and the rest do not reliably survive migration — this is how that fails.
  4. Re-check display topology. Output count is a chip property; do not assume the old rig’s display layout still fits.
  5. Transcode any problem media to a hardware-decoded codec.
  6. Soak test for the length of the show, at venue temperature.

Done in that order, the migration is usually uneventful and the machine is dramatically faster than the one it replaced. Done by restoring a Time Machine backup and heading to site, it is a lottery.

Originally published on the SpectraRig blog.