ATEM Mini Pro RTMP and SRT Workflow for StreamableRun Cloud OBS

The direct answer

An ATEM Mini is a strong front-end switcher for a StreamableRun production when you want multiple HDMI cameras, local switching, real buttons, and a clean program feed. Blackmagic describes the ATEM Mini line as compact live switchers with HDMI inputs, audio mixing, multiview on supported models, recording on Pro and ISO models, and built-in streaming on the models that include a hardware streaming engine.

The important part is choosing the right job for the ATEM. Let the ATEM handle local cameras, program switching, and embedded audio. Send the finished program into StreamableRun. Let StreamableRun Cloud Hosted OBS handle overlays that need remote control, fallback scenes, clips, destination management, monitoring, and producer handoff.

Also verify your exact model. Blackmagic's current ATEM Mini product page says the line's built-in streaming engine works with RTMP and SRT, while the ATEM Mini Pro tech specs list direct RTMP streaming over Ethernet or shared USB-C internet. Newer models and different ATEM Mini variants do not all expose the same streaming behavior. Check the model you actually own before building the runbook.

Who this setup is for

This setup is for studio shows, live podcasts, small venue streams, church productions, tournaments, classrooms, sponsor activations, pop-up events, and IRL teams that occasionally become a fixed multi-camera production. It is especially useful when one person can switch cameras locally while another producer manages the cloud output.

It is not the best starting point for a walking stream. The ATEM wants power, HDMI, cabling, audio planning, and a stable place to sit. If the streamer is moving through a city, use a phone app, bonded encoder, or compact field rig. If the production has tables, cameras, laptops, audio, and a producer, the ATEM starts making sense.

StreamableRun is the useful middle layer because it separates the local venue from public destinations. The ATEM can be rebooted, re-cabled, or replaced by a backup source while Cloud OBS gives the audience a fallback scene instead of a dead stream.

• Good fit: multiple HDMI cameras at a fixed location.
• Good fit: one local technical operator plus one remote producer.
• Good fit: events that need a fallback slate, sponsor assets, clips, and multiple destinations.
• Bad fit: a backpack stream where the device cannot stay powered and wired.
• Risky without rehearsal: any event where the ATEM is also new to the local crew.

Model checks before you promise SRT

Do the boring model check first. ATEM Mini, ATEM Mini Pro, ATEM Mini Pro ISO, ATEM Mini Extreme, and newer ATEM Mini variants do not all have identical streaming and recording features. The older Pro tech specs list RTMP direct streaming. Blackmagic's current product copy for the broader line mentions RTMP and SRT streaming protocols. Those facts can both be true because the line has multiple models.

That means the runbook should say the exact model, firmware, ATEM Software Control version, available streaming protocol, network interface, recording method, and backup output. Do not write SRT into a client plan because a product page for the line mentioned it. Confirm it in the control software and with the device on the bench.

If your model only supports RTMP direct streaming, that is still usable. RTMP into StreamableRun is often the simplest ATEM path. If your exact ATEM supports SRT and the venue network allows it, test SRT as a contribution path. The producer does not care which protocol sounded more modern; the producer cares which one reconnects cleanly before the audience notices.

• Write down the exact ATEM model and firmware.
• Verify whether your model supports RTMP only or RTMP plus SRT.
• Check whether streaming goes over Ethernet, shared USB-C internet, or another path.
• Confirm whether recording is to USB-C media, CFexpress, or another supported storage path.
• Keep a second contribution path ready, such as USB webcam into local OBS or a backup encoder.

Recommended architecture

The clean architecture is camera inputs into ATEM, ATEM program into StreamableRun ingest, Cloud Hosted OBS scene collection, then destinations. The ATEM should not own Twitch, Kick, YouTube, sponsor RTMP, and emergency graphics unless the show is tiny. It should send a finished local program to the cloud production layer.

In Cloud OBS, build a main ATEM scene, a holding scene, a technical slate, a clip or BRB scene, and a backup-source scene. If the ATEM feed stops, the remote producer cuts to fallback. If the venue fixes the cable, the producer returns only after the program feed and audio are stable. If one destination breaks, the producer handles it in StreamableRun without changing the ATEM.

This also keeps platform keys out of the venue switcher. A volunteer or local camera operator should not need access to every public destination just to switch between camera one and camera two. Give the ATEM operator the camera job. Give the StreamableRun producer the broadcast job.

• ATEM job: cameras, local audio mix, local program cut.
• StreamableRun job: ingest, Cloud OBS scenes, fallback, clips, destinations, remote monitoring.
• Producer job: public output, destination restarts, scene recovery, viewer-device checks.
• Streamer or host job: content, not emergency destination settings.
• Backup job: local OBS or second encoder ready if the ATEM stream output fails.

RTMP setup path

For ATEM Mini Pro-style RTMP direct streaming, create a StreamableRun ingest for the ATEM program feed. In ATEM Software Control, configure the streaming destination with the StreamableRun server URL and stream key or custom RTMP details. Use the same output resolution and frame rate you plan to send during the real show.

Then test the whole path: ATEM on air, StreamableRun ingest live, Cloud OBS main scene, destination output, platform preview, and viewer device. If you only test until the ATEM says it is streaming, you have not tested the production. The important failures happen downstream: wrong audio mapping, cropped overlays, platform rejection, bad keyframe behavior, and a producer who cannot tell whether the source is live.

Keep the ATEM bitrate practical. Kick's current guide, for example, asks streamers to use CBR and keep bitrate within the available upload speed, with listed RTMP settings up to 8,000 kbps. YouTube has broader live encoder ranges, but the venue uplink and the StreamableRun production profile still decide what is safe. Do not set the ATEM for a perfect fiber line if the venue is on shared Wi-Fi.

• Create a named StreamableRun ingest for the ATEM.
• Paste StreamableRun RTMP details into the ATEM streaming configuration.
• Use CBR and a conservative bitrate that the venue can hold.
• Test audio meters, embedded audio, and platform playback.
• Save the ATEM streaming profile and do not edit it minutes before the event.

SRT setup path if your model supports it

If your exact ATEM supports SRT streaming, treat it as a contribution protocol, not a shortcut around rehearsal. SRT can be useful over less predictable networks, but only when listener and caller mode, port behavior, passphrase, latency, firewall, and reconnect behavior are already understood.

OBS's SRT guide explains that mode and latency can be passed in SRT URLs, that OBS accepts SRT options supported by FFmpeg, and that latency should be large enough for the network round trip. The same thinking applies to any encoder-to-server SRT route: low delay is only useful if the route still recovers under jitter.

Test SRT on the exact network path. If the venue firewall blocks the port, if the ATEM cannot reach the ingest, or if the producer does not understand the reconnect state, RTMP may be the safer event choice. The protocol with a passed rehearsal beats the protocol with better theory.

• Confirm the model supports SRT in the control software.
• Confirm caller/listener behavior with the StreamableRun ingest path.
• Test port and firewall access from the venue network.
• Pick latency for recovery, not only for lowest delay.
• Keep RTMP or USB webcam output as a backup path.

Audio is where ATEM shows get messy

ATEM audio problems usually come from unclear ownership. The HDMI camera may send embedded audio, the mixer may feed a 3.5 mm input, the laptop may carry music, and the remote producer may only hear the final platform feed after delay. Decide which device owns the real program audio before the event starts.

In StreamableRun, keep the Cloud OBS audio layout simple. If the ATEM program has final mixed audio, do not duplicate the same mic from another source unless you are intentionally building a backup. If clips or browser sources add audio in Cloud OBS, the producer needs a known mute plan. A fallback scene with unexpected venue audio is not a fallback.

Do a clap or slate test through the final platform preview. Watch for audio delay, doubled microphones, low music, hot crowd mics, and missing left or right channels. The ATEM multiview can look clean while the public output has an audio problem. The viewer device is the truth.

• Choose whether the ATEM or Cloud OBS owns final audio mixing.
• Keep one main program audio path unless there is a planned backup.
• Test embedded HDMI audio and analog audio separately.
• Check audio on the public destination, not only in ATEM Software Control.
• Write the producer's mute order for main, clips, browser sources, and backup feeds.

Failure drills for events

A good ATEM event rehearsal intentionally breaks the path. Pull one camera input. Mute the wrong audio source. Stop the ATEM stream output. Unplug and replug Ethernet if the venue can safely test that. Restart one destination in StreamableRun. The team should learn what each failure looks like before the audience does.

The main recovery pattern is simple: Cloud OBS stays live, the producer switches to fallback, the ATEM operator fixes the local problem, and the producer returns to the main ATEM scene after the public preview is clean. The streamer or host should not have to explain network settings while on camera.

If the ATEM dies completely, use a backup source. That might be local OBS from a laptop, a phone ingest, a second encoder, or a static slate while the venue resets. StreamableRun gives the producer a place to hold the public stream while the local crew works.

• Failure one: camera input disappears.
• Failure two: ATEM audio changes or doubles.
• Failure three: ATEM streaming output stops.
• Failure four: destination rejects or buffers.
• Failure five: local venue internet drops.
• Pass condition: the public stream stays understandable while the team recovers.

Other resources

Use these pages to verify the exact ATEM features, SRT behavior, destination settings, and StreamableRun production pieces before building an event runbook.