Atomos Ninja Phone and Ninja TX Workflow for SRT, RTMP, and Cloud OBS

What changed for streamer operators

Atomos has been pushing its monitor-recorders further into live contribution. Ninja Phone turns an iPhone or iPad into a monitor, recorder, and streamer for an HDMI camera. Atomos also says Ninja TX gets NDI TX and RX preloaded, while connected Atomos workflows can output RTMP/S or SRT in its live production tools. For streamers, the interesting part is not the marketing line. It is that mirrorless cameras can now become more practical field sources without dragging a full laptop rig everywhere.

The production decision is still the same: do not let the field device become the whole show. Send the Atomos path into StreamableRun as a named ingest, then run the public broadcast from Cloud Hosted OBS. That gives the producer scenes, fallback, destination keys, monitoring, and a recovery plan that do not depend on the person holding the camera.

Use Ninja Phone when the camera-plus-iPhone rig is the right lightweight field source. Use Ninja TX or connected Atomos gear when NDI, SRT, RTMP, monitoring tools, timecode, or more traditional production control matter. Use StreamableRun as the operating layer that turns whichever field feed survives into a watchable show.

Choose the field role first

The gear choice should come after the job. A Ninja Phone rig is strong when the streamer wants an HDMI mirrorless camera with an iPhone screen, local recording, and a mobile connection. Ninja TX starts to make more sense when the production needs a monitor-recorder with built-in connectivity, NDI use, or a field role that looks closer to broadcast contribution. An Atomos cloud or production surface setup can make sense for a small multicam social show, but that still does not replace the need for a stable public output plan.

Write the role in one sentence before cabling anything. For example: mobile mirrorless camera walking into StreamableRun; tripod camera at a fan event into StreamableRun; stage camera backup primed with RTMP; NDI camera source converted to SRT for cloud production. If the role cannot be explained that simply, the producer will not recover it quickly while live.

• Ninja Phone role: HDMI camera into iPhone or iPad, mobile monitoring, recording, and streaming from a compact rig.
• Ninja TX role: monitor-recorder with connected production features, NDI workflows, and a more hardware-focused field source.
• Atomos cloud production role: small switched show that can output RTMP/S or SRT when the team wants a separate production layer.
• StreamableRun role: receive the feed, run Cloud OBS scenes, hold fallback, manage destinations, and support remote producer handoff.
• Producer rule: the field role should be swappable. If the Atomos path dies, the show should have another scene to hold viewers.

SRT vs RTMP from the field

SRT is usually the better field contribution choice when the sender, receiver, and firewall path are under control. OBS's SRT guide explains caller and listener mode behavior, and the SRT protocol is built around packet recovery, latency buffers, acknowledgements, retransmission, and encryption features. For a moving or remote camera, that matters. A little latency can be a good trade if the feed recovers from imperfect networks more cleanly.

RTMP is still useful because many tools and destinations understand it. It is often easier to configure, easier to test against common platforms, and good enough for a steady wired connection. The tradeoff is that RTMP is not designed around lossy mobile recovery the same way SRT is. If the network gets bad, the producer needs a fallback scene instead of hoping RTMP behaves like bonding.

For StreamableRun, the simple rule is this: use SRT when the Atomos path and your network allow it, use RTMP when compatibility is the priority, and never make protocol choice a substitute for a recovery plan. The viewer does not care whether the source was elegant. They care whether the stream stayed understandable when the field feed stumbled.

• Use SRT for remote contribution where latency, packet recovery, and firewall mode can be rehearsed.
• Use RTMP for simple wired or known-good paths where tool compatibility matters more than transport recovery.
• Keep latency values written down so a producer does not change them live by guessing.
• Test caller/listener mode from the actual venue network, not only from home fiber.
• Keep an RTMP backup or phone backup ready if the SRT route is new to the team.

Ninja Phone field path

Atomos says Ninja Phone works with iOS 18-capable iPhones and iPads through the Mavis Camera app, connects to an HDMI camera, and supports H.265, H.264, and ProRes recording depending on device capability. The product page also lists 4Kp24/25/30, 1080p up to 60, HDMI-A input, USB 3.1 Gen 1 output, and two-channel 48 kHz PCM over HDMI. Those specs are useful, but the live test should focus on the whole path, not the spec sheet.

A streamer-friendly path looks like this: mirrorless camera to Ninja Phone, iPhone over 5G or Wi-Fi, then the supported live output route available in your Atomos or Mavis setup into StreamableRun, with Cloud OBS handling the scene and destination output. If your exact setup does not expose a custom RTMP, SRT, or compatible contribution path, use the device as a local camera/monitor/record source and contribute through local OBS or another tested encoder instead of guessing live. The camera operator should not also own overlay timing, destination keys, clip playback, and fallback. Their hands are full with focus, exposure, battery, phone heat, and the physical shot.

If the Ninja Phone route is mostly for mobile quality, keep the first version simple. Do not combine a new camera, new phone app, new codec, new cloud route, new overlay package, and new destination setting on the same day. Get the camera into StreamableRun cleanly first, then add polish.

• Name the ingest by job, such as Ninja Phone Main or Mirrorless Walk.
• Keep the phone display visible enough for the operator to see whether the app is still live.
• Test phone heat, battery, cable strain, HDMI connection, and data coverage as live risks.
• Use Cloud OBS for overlays and destination output instead of building the whole show on the phone.
• Give the producer a fallback button before the first public field test.

Ninja TX and NDI path

Atomos says Ninja TX gets NDI TX and RX preloaded, and its NDI workflow page calls out uses like an NDI encoder or decoder, confidence monitor, visual signal tester, cloud connection using SRT, hot backup primed with RTMP information, and HDMI/SDI conversion on supported models. That makes it interesting for teams that already use NDI in a venue, studio, or production cart.

NDI is not automatically the right public contribution path for an IRL stream over the open internet. It is usually stronger inside a managed local network. If the camera is on the same venue network as a producer machine, NDI can be a good local source. To reach StreamableRun, decide whether the path should be converted to SRT, RTMP, or another supported contribution route. Do not expose an NDI plan to the public internet just because it is convenient in a studio.

In Cloud OBS, treat the Ninja TX or NDI source like any other camera job. Main scene, backup scene, slate, audio check, and destination test. The advantage is producer control, not a prettier topology diagram.

• Use NDI inside a controlled local network when it helps move camera feeds around a venue.
• Use SRT or RTMP to cross networks into StreamableRun unless your architecture says otherwise and has been tested.
• Keep a hot backup source ready if the NDI network is shared with venue traffic.
• Do not assume HDR or 10-bit workflow survives every destination; test the final platform path.
• Document whether the source is local NDI, SRT contribution, RTMP backup, or Cloud OBS output.

Destination strategy

Atomos live production docs talk about RTMP/S and SRT outputs, while platform docs still put hard constraints on the final public stream. Kick's help center recommends H.264-oriented OBS settings with CBR, up to 1080p, and a 2-second keyframe interval. YouTube supports more options, including HEVC and AV1 in specific paths, but YouTube support does not mean Twitch, Kick, and every custom RTMP destination want the same output.

That is where StreamableRun earns its place. Field contribution can be SRT, RTMP, NDI-converted, or phone-based. Cloud OBS can then produce a conservative output for multi-destination streams, or a YouTube-specific output when the show really needs a YouTube-only feature. Keep the destination decision in the cloud, not buried in the field device.

• Multi-destination show: use a conservative H.264 output profile unless every destination supports the newer path.
• YouTube-focused show: test HEVC, HDR, HLS, or Enhanced RTMP privately before changing the production output.
• Kick-focused show: follow Kick's current bitrate and keyframe guidance instead of copying a YouTube profile.
• Custom RTMP: test every endpoint because custom ingest behavior varies a lot.
• Producer handoff: list each destination, its output profile, and its recovery action.

Rehearsal that actually finds problems

Do a rehearsal with the exact camera, Atomos device, phone or network path, StreamableRun ingest, Cloud OBS profile, and destination preview. A tabletop test on office Wi-Fi does not prove a fan meetup, a convention hallway, a sideline, or a moving street stream. The test needs movement, cable strain, battery drain, network transitions, and a producer who is not standing next to the camera.

Force the source to fail. Stop the Atomos stream, unplug HDMI, drop the network, restart the app, and switch Cloud OBS to fallback. Then return only after the producer sees the feed in StreamableRun and on a normal viewer device. This is the part most gear videos skip. It is also the part that keeps a public stream from ending badly.

• Start with a private destination and run the route for at least a real segment length.
• Switch from main to fallback and back while the field source is reconnecting.
• Check audio after every reconnect, not only video.
• Confirm the producer can tell the difference between Atomos source failure and destination failure.
• Write the working firmware, app, protocol, bitrate, and latency settings in the runbook.

Other resources

Use these pages to verify current Atomos device behavior, SRT/RTMP output options, platform output constraints, and StreamableRun production features before using an Atomos rig on a live stream.