Capture Card No-Signal Recovery Runbook for Cloud OBS Streams

The direct answer

When a capture card says no signal, protect the public stream first. Switch Cloud Hosted OBS to a prepared fallback, then isolate the failure in order: camera or console output, HDMI cable, capture-card input, host connection, OBS source mode, and local program output. Do not turn a clean production outage into a public troubleshooting session.

OBS explains that a Video Capture Device source can use device-default or custom resolution and FPS, selected video format, color space, range, buffering, and linked audio. A no-signal screen is often a mismatch between one of those settings and what the camera or console is actually sending. The answer is usually specific, not mystical.

Use StreamableRun as the public recovery layer. The local machine can lose a card, restart OBS, or get a replacement cable while Cloud OBS holds a BRB, clips, slate, backup ingest, or another camera. Destinations stay live and the producer has a visible plan.

Read the failure shape before unplugging anything

A black preview, a no-signal message, a frozen frame, and a source that never appears in the device list are different failures. A black preview can be a camera output or format mismatch. No signal often points to a broken upstream handshake. A frozen frame may be buffering, a driver, or a camera that stopped sending. A missing device is commonly host connection, permissions, power, or driver behavior.

Ask three short questions. Is the camera or console itself outputting? Does the capture card appear in the operating system and OBS device list? Does a known-good simple mode work? Start with 1080p at a conventional frame rate and the device default settings if the intended 4K, HDR, 4:2:2, or high-frame-rate path is unclear. Then add complexity back one change at a time.

Do not swap five things in a panic. If the signal returns, you will not know whether the cable, source mode, USB port, or OBS restart fixed it, and the same failure will be waiting next show.

• Black preview: inspect input, source visibility, and color settings.
• No signal: inspect camera output, cable, card input, and mode match.
• Frozen frame: inspect source freshness, buffering, driver, and camera state.
• Missing device: inspect power, USB or PCIe connection, and host recognition.
• Wrong audio: inspect linked capture-card audio and program ownership separately.

Match the camera and capture source

OBS documents that a capture source will not display if its configured resolution is unsupported by the device. The camera output, capture card capability, and OBS source must agree on resolution and frame rate. A card can be excellent and still show nothing if a camera suddenly changes from 1080p59.94 to 4K60, turns on HDR, or switches its HDMI output mode.

Start by opening the camera or console output menu, not the OBS filter panel. Confirm clean HDMI, correct output resolution, frame rate, and whether the device sleeps when its display closes. Then open the capture source and choose device default or the matching custom mode. Use the card's configuration utility only after you know the intended input.

If the route includes HDR, treat it as a whole-path check. OBS notes that external HDR capture needs a compatible 10-bit format such as P010 and that capture support varies. A public SDR stream is not the place to discover an accidental HDR conversion.

Cables, power, and host connections are part of the signal

An HDMI chain is only as good as the least cooperative connector. A cable can work with a static monitor but fail on a high-bandwidth mode. A USB capture card can work until a hub shares power or bandwidth with storage. A camera can look awake while its HDMI output is disabled by a menu or power state. Treat the physical route as part of the show file.

Carry a short known-good HDMI cable, a replacement USB cable where applicable, and a direct host-port option. Label the card input and output. If the capture card has pass-through, do not confuse a monitor that sees picture with OBS actually receiving a compatible capture signal. Test both.

During recovery, change the smallest physical item first when the symptoms support it. Reseat a cable. Move a UVC device to the tested direct port. Power-cycle the camera. Then inspect OBS. Do not randomly update firmware in the middle of a show; firmware is a rehearsal task unless a vendor gives a specific urgent fix.

• Carry a tested short HDMI cable and direct USB path.
• Know which port is card input, pass-through, and host output.
• Avoid untested hubs for the main camera route.
• Check camera sleep and clean-output settings.
• Test monitor picture and OBS capture separately.

Use fallback as a real operating state

A fallback scene is not a decorative BRB card. It is an independent public state that gives the technical team time to work. Build one in Cloud Hosted OBS with known-good audio, text that does not overpromise, and no dependency on the failed capture source. Add a clips scene or backup camera if the show format allows it.

When the main capture fails, the cloud producer switches first. The local operator diagnoses second. The host gets a simple cue: continue audio, read a transition, or take a short break. The producer keeps a viewer preview open and does not return to main simply because the local OBS preview has picture again.

If the capture path is important enough to be the only camera, it is important enough to rehearse the fallback. Test it with the card powered, camera output disabled, cable removed, and local OBS restarted. Each failure produces a slightly different recovery timing.

• Cloud OBS Main: normal program.
• Cloud OBS Backup: alternate camera or independent ingest.
• Cloud OBS Technical Hold: stable graphic and safe audio.
• Local operator: repair only the named failing component.
• Producer: return after a public viewer preview confirms the recovery.

Run the reset ladder

Use an agreed escalation ladder so two people do not reset different things at once. Step one: verify the public fallback is live. Step two: confirm camera or console output. Step three: reseat the known-good cable. Step four: verify the card is visible to the host. Step five: reopen or reset the OBS capture source with a matching simple mode. Step six: restart the local application or card only if the earlier checks fail. Step seven: move to the backup ingest if the main route cannot be restored quickly.

Keep the reset owner clear. The camera operator should not be changing Cloud OBS scenes. The cloud producer should not be changing camera menu items by remote guesswork. A technical lead decides when to stop chasing the main card and stay on a backup for the rest of the segment.

Log symptoms, not drama: camera output confirmed, card missing from host, cable swapped, 1080p default worked, 4K60 failed, backup used. That record turns a recurring mystery into a specific next rehearsal.

• Protect public output.
• Verify source output.
• Verify cable and physical route.
• Verify host recognition.
• Test a simple matched OBS mode.
• Restart only the component that evidence points to.
• Escalate to backup on a defined timer.

Handoff and prevention

Put the capture-card model, camera mode, port map, source name, cable type, audio route, backup source, and fallback scene in the producer packet. This is not busywork. A new operator cannot infer which of four HDMI cables is the right one from a dim venue photo.

Before each stream, run a sixty-second visual preflight: image present, focus and exposure acceptable, audio present, source name correct, local program reaching StreamableRun, Cloud OBS main scene correct, backup scene correct, destinations healthy, viewer preview clean. Then test one intentional source loss while there is still time to fix a mistake.

The final goal is modest: a capture-card issue should change the show gracefully, not end it. StreamableRun gives a producer the cloud scenes and destination controls to do that while the local team works through the physical path.

• Record the working mode and port map.
• Check main and backup before every call time.
• Test one planned failure before a high-stakes stream.
• Keep platform destination keys out of the camera laptop.
• Review the incident after the show and change the kit only with evidence.

Other resources

Use these official OBS sources to verify capture-source controls and HDR requirements, then use your card and camera manuals for their exact modes, power behavior, and firmware. The real gate is a rehearsal of the exact route.