Canon Cinema EOS SRT Auto-Reconnect Setup for Cloud OBS

The direct answer

Canon's recent Cinema EOS firmware updates for the EOS C400, EOS C80, and EOS C50 add automatic reconnection attempts during SRT protocol streaming when the connection is lost, using the camera's SRT reconnection timeout setting. Canon Australia and Canon Singapore list that behavior in the C50 firmware notes, and Canon Canada lists it for the C400 firmware. Current coverage from RedShark and CineD also points to SRT auto-reconnect as one of the practical live-production changes.

For streamers and small production teams, this is useful because a cinema camera with native SRT can become a cleaner contribution source. It does not mean the camera should own the whole show. Auto-reconnect helps the camera try to restore its transport. It does not replace Cloud OBS fallback scenes, producer monitoring, destination checks, backup audio, or a second ingest.

The best setup is Canon Cinema EOS camera over SRT into StreamableRun, StreamableRun Cloud Hosted OBS for scenes and recovery, then platform destinations managed separately. Test auto-reconnect on a private destination before a real stream. The feature is only valuable if the producer knows what viewers see while the camera is reconnecting.

What changed in the Canon firmware

The key livestreaming change is automatic SRT reconnection. Canon's firmware notes describe the camera attempting to reconnect during SRT protocol streaming if the connection is lost, for the duration set in the SRT reconnection timeout setting. The updates also include workflow items such as USB external control on some models and improved level indicator behavior, depending on the camera.

That matters because native SRT cameras sit between phone-app IRL and full hardware encoder workflows. A C400, C80, or C50 can be a high-quality camera source that sends directly over IP. For events, studios, small crews, and mobile productions, fewer boxes can be attractive. But fewer boxes also means each box has more responsibility, so the recovery plan needs to be clear.

Auto-reconnect should be treated as a camera-side recovery attempt, not a viewer-side guarantee. If the camera reconnects after ten seconds, the producer still needs a public output during those ten seconds. If it reconnects with no audio, wrong bitrate, wrong route, or bad exposure after a move, the public show still needs human judgment.

• Update firmware on a test day, not at the venue.
• Save camera network and streaming settings before changing firmware.
• Test SRT reconnection timeout with the exact network path used for the stream.
• Confirm audio returns correctly after reconnect.
• Confirm Cloud OBS source behavior after the camera reconnects.

Who should use camera-native SRT

Camera-native SRT is useful when the camera is near a reliable network or when the crew wants fewer intermediate devices. A studio, venue, press room, church, small sports production, podcast room, or creator desk can benefit. Instead of HDMI into a capture card into a laptop into OBS, the camera can send an IP contribution feed to the cloud.

It is less ideal when the camera operator is walking through random mobile coverage with no producer. A phone app like Moblin or IRL Pro may be a better fit for pure mobile IRL because it is built around phone connectivity, battery behavior, orientation, and quick field control. A Canon Cinema EOS body is heavier, more expensive, and usually part of a planned production.

The sweet spot is a serious stream that wants cinema-camera image quality but still wants Cloud OBS recovery. Put the camera on SRT, send it to StreamableRun, and let the producer handle overlays, destinations, fallback scenes, and guest or chat elements in the cloud.

• Good fit: fixed or semi-fixed camera with wired, venue, or managed wireless network.
• Good fit: higher-quality desk, studio, panel, sports, event, or sponsor streams.
• Maybe: mobile camera rigs with a dedicated operator and known network route.
• Poor fit: casual walking IRL where a phone app is easier to operate and recover.

Canon SRT to StreamableRun setup path

Create a named SRT ingest in StreamableRun before touching the camera. Decide caller/listener mode, port, passphrase, latency, and stream naming. Keep the ingest name readable: Canon Main, C80 Stage Left, C50 Desk, or C400 Field, not a serial number. A tired producer should understand the source list instantly.

On the camera, configure SRT with the StreamableRun ingest details and set a reconnection timeout that matches the show plan. A very short timeout may give up before a normal network wobble clears. A very long timeout may leave the producer waiting on a source that needs manual attention. The right number depends on the event, but it should be written into the runbook.

In Cloud OBS, build scenes around the camera as one source. Add backup phone, local OBS, BRB, slate, and clips scenes. If the camera feed disappears, the producer cuts away. If the camera reconnects, the producer confirms video, audio, exposure, and sync before returning to main. Auto-reconnect should create an easier return path, not an uncontrolled auto-cut back to public output.

• StreamableRun ingest created and named by source job.
• Canon SRT settings entered and saved in a camera profile.
• Cloud OBS scene built for camera main, backup, BRB, slate, and destination test.
• Private output used for reconnect rehearsal.
• Producer confirms before returning the camera to public main.

Test reconnect like a real failure

A reconnect test should not be a gentle settings-screen check. Start a private stream, confirm the Canon feed appears in StreamableRun Cloud OBS, and then break the path in a controlled way. Unplug Ethernet if wired. Disable the network path if wireless. Stop the receiver if that is the safer simulation. The producer should see exactly how the source disappears, how long it takes to return, and whether audio comes back cleanly.

Watch three things at once: the camera status, StreamableRun ingest status, and viewer output. If the camera says it is reconnecting but Cloud OBS never receives it, the problem is not solved. If Cloud OBS receives the source but the viewer hears nothing, the problem is audio. If the source reconnects but the producer never cut to fallback, the problem is the runbook.

Repeat the test at the expected bitrate and resolution. A reconnect that passes at a low test bitrate may not behave the same at the event setting. Also test after the camera has been running long enough to warm up, especially in packed venues or hot rooms.

• Start private destination and confirm normal output.
• Break network path in a controlled way.
• Producer cuts to BRB, slate, or backup source on the agreed timer.
• Camera attempts SRT reconnect for the configured timeout.
• Producer returns to main only after video, audio, and sync are confirmed.

Audio and control still need a plan

SRT auto-reconnect is a transport feature. It does not guarantee that your audio routing, camera control, tally, guest audio, or local monitor returns exactly how the crew expects. Camera firmware updates can add useful control features, but the show still needs a practical audio and control map.

Decide where microphones enter the chain. If audio is embedded in the camera, test that it returns after reconnect. If audio is mixed elsewhere, make sure Cloud OBS receives the right source after the camera drops. If the producer has remote control over camera settings, write down which controls are allowed live and which are locked once the show starts.

Do not bury a camera-control experiment inside a public show. Test external control, focus behavior, iris changes, ISO changes, and record start/stop during rehearsal. A camera that can be controlled remotely is powerful, but wrong remote control during a live event can ruin a shot faster than a network drop.

• Confirm public audio after reconnect, not only camera meters.
• Lock camera settings that should not move during live output.
• Assign one person to camera control if remote control is enabled.
• Keep emergency mute and backup audio options in Cloud OBS.
• Record a private sample and review it before the live segment.

When a capture card is still better

Native SRT is not always the best path. If the camera is right next to a local production machine, HDMI or SDI into a capture card or switcher may still be simpler. Local capture can reduce network variables, make monitoring obvious, and fit teams that already run local OBS as a source into StreamableRun.

Use native SRT when the camera and cloud are separated by distance, when fewer boxes matter, when a venue network is reliable enough, or when the production team wants IP contribution without a laptop at the camera. Use capture when the camera is already on a desk, the operator needs local control, or the show depends on a switcher with multiple physical sources.

Both paths can feed StreamableRun. That is the point. StreamableRun should be the production layer, not a bet on one cable or one protocol. Canon SRT can be the main source and local OBS can be backup, or local capture can be main and Canon SRT can be emergency backup. Pick the architecture by recovery path, not by feature excitement.

• Use SRT for distance, IP contribution, and cloud-first camera placement.
• Use capture cards for local switching, simple monitoring, and stable nearby camera setups.
• Use both when the event justifies a real backup path.
• Keep Cloud OBS scene names the same even if the source transport changes.

Other resources

Use these pages to verify Canon firmware behavior, current reporting, SRT setup details, and StreamableRun production features before changing a camera contribution workflow.