SDI is refreshingly binary. Either the switcher locks to your signal or it does not, and there is no “it’s mostly working”. That makes it the most predictable way to get video out of a Mac, and it makes the failures feel abrupt.

When a DeckLink output is rejected, it is nearly always one of four things.

1. You asked for a mode the card does not do

SDI is not a resolution and a refresh rate that you dial in freely. It is a short, fixed list of standardised modes, and your card supports a subset of them.

A DeckLink Mini Monitor does 3G-SDI, so it tops out at 1080p60. A DeckLink 8K Pro does 12G and will do 2160p60 on a single link. A card that does 6G will do 2160p30 but not 2160p60. Asking a 3G card for 2160p60 does not produce a degraded picture — it produces nothing.

Non-standard resolutions are simply not available. If your canvas is 1344 × 336 because that is what the LED wall is, SDI will not carry that. You place it inside a standard frame — 1080p is the usual choice — and tell the processor where in the frame to look. That is the normal way to work, and it is covered in what an LED processor actually wants from your Mac.

Check what the card claims before debugging anything else:

system_profiler SPPCIDataType | grep -A 4 -i blackmagic

And confirm the Desktop Video driver version matches what your software expects. A mismatched Desktop Video install is a surprisingly common cause of a card that appears in System Information and not in the application.

2. The frame rate does not match the house

The switcher, or the LED processor, or the router, is running at one frame rate. If you hand it a different one, it will not lock. There is no negotiation on SDI — the receiving device either recognises the timing or it does not.

Decide the show’s frame rate at the top of the job and make everything agree. In Australia that is usually 50 whenever a broadcast camera or a hire camera package is involved, and 60 for a corporate show with a Mac and a projector. What it must not be is both.

The subtle version of this failure: 59.94 versus 60. They are different modes. A device set to 1080p59.94 will not lock to 1080p60. If a signal is intermittently rolling or tearing rather than absent, suspect this pair, along with 29.97 versus 30 and 23.98 versus 24.

3. Colour range is set wrong at one end

This one does not stop the lock — it just makes the picture look wrong, which is worse, because you will spend an hour looking at content instead of settings.

Computers are full range: black is 0, white is 255. Video is traditionally limited range: black is 16, white is 235. SDI carries limited-range values by convention.

So if the Mac sends full range into a device expecting limited, blacks go below legal black and clip, highlights blow out, and everything looks contrasty and crushed. Send limited into a full-range expectation and blacks come up grey and the picture looks flat and washed.

Both ends have a setting. Find both, make them agree, and note which way round on the show file. If you are only allowed one diagnostic, send a greyscale ramp — the point where it stops changing tells you where it is clipping.

4. Genlock, or the absence of it

In a facility with a reference generator, every device is locked to a common timing reference. Sources that are genlocked can be cut between cleanly. Sources that are not will glitch on the cut, because the switcher has to resynchronise.

Whether you need to care depends entirely on the destination:

  • Feeding a processor or a projector directly? Genlock is irrelevant. There is nothing to cut against.
  • Feeding a switcher with frame synchronisers on every input — which describes most modern production switchers, including the ATEM range? The switcher absorbs the timing difference. You are fine.
  • Feeding a broadcast switcher or a router in a facility that runs reference? You need to genlock, and you need a card that accepts reference — the smaller DeckLinks do not.

If a vision engineer asks whether you are genlocked, the honest answer is usually “no, but the input has a frame sync”. If they are running a facility on reference, that answer will not satisfy them, and the fix is a card with a reference input, not a setting.

Things that are not the four, but bite anyway

Cable and connector quality. 3G-SDI over a tired cable is marginal in a way that presents as intermittent loss under vibration. 12G is much less forgiving again — use cable rated for it, keep runs short, and be suspicious of any adaptor in the path. A 12G run that works on the bench and fails in the venue is usually a cable, not a card.

Thunderbolt bandwidth, for external boxes. An UltraStudio sharing a Thunderbolt bus with a fast SSD and a dock can run out of headroom. Symptoms are dropped frames rather than loss of lock. Give a video device its own bus where the machine allows it.

Audio embedding. SDI carries embedded audio, and whether your software populates it is a separate question from whether video is working. If the switcher has picture and no sound, check what the application is actually embedding and on which channel pairs — not the cable.

Thermals. A PCIe DeckLink in a Mac Pro under sustained load in a hot venue will throttle or fault. Cards that “work in the shop and fail on site” often have a temperature story.

Why bother, when NDI exists

NDI is easier to rig and needs no cards. SDI still wins in specific circumstances, and they are common in live work:

  • The destination is hardware that predates NDI. Most switchers, most LED processors, most routers. SDI is what they have.
  • Latency and quality. SDI is uncompressed and effectively immediate. No encode, no decode, no subsampling, no network.
  • It does not share a failure domain with anything else. A cable per signal, no switch, no VLAN, no discovery protocol, nobody plugging a laptop into the show network. When something breaks at 7pm, that isolation is worth a lot.

The general shape of a Mac rig ends up using all three transports in the roles that suit them: Syphon inside the machine, NDI between machines, SDI where the destination is hardware. NDI or Syphon? covers the first two, and SpectraMap speaks all three so the decision can be made per-output rather than per-rig.

Originally published on the SpectraRig blog.