Epiphan Pearl Nano SRT setup with Callaba Gateway
Written by Iurii Pakholkov
Founder of Callaba. Building cloud video tools for SRT, RTMP, WebRTC, NDI, live routing, monitoring, recording, and production workflows.
Release: Callaba 8.4
Epiphan Pearl Nano SRT setup is a direct contribution workflow: connect SDI or HDMI to Pearl Nano, encode the channel, and send SRT push to a cloud listener. For this model, SRT push over UDP is documented, along with caller, listener, rendezvous, Stream ID, AES key length, passphrase, latency, and recovery overhead controls. Callaba can receive that stream, show preview and stream health, record it, route it, restream it, and create playback paths after ingest is stable.
Quick answer
To use Epiphan Pearl Nano with SRT, set Pearl Nano as the SRT Caller and send the stream to a cloud SRT Listener. In this guide, Callaba works as the SRT gateway, receiver, monitor, recorder, and routing layer.
Pearl Nano sends one SRT contribution feed into Callaba. After ingest, Callaba can preview, record, route, restream, and provide playback in parallel; those are not mandatory sequential setup steps.
- Pearl NanoSRT caller from SDI/HDMI
- Callaba GatewaySRT listener and receiver
- Preview
- Record
- Route
- Restream
- Playback
What this setup does
This workflow uses Pearl Nano as the field encoder and Callaba as the cloud SRT gateway. The normal Pearl Nano SRT caller direction is outbound from the venue, which is usually easier for venue firewalls than accepting an inbound internet connection on the encoder.
If you are searching for Pearl Nano SRT gateway, Pearl Nano SRT to cloud, or Epiphan Pearl Nano SRT server, the practical answer is that Pearl Nano sends SRT; Callaba is the server-side receiver and routing layer. Pearl Nano can also ingest one SRT or RTSP network source, but I would not treat it as a general multi-source IP switcher.
Do not plan Epiphan Pearl Nano as a native NDI source. Official Pearl Nano materials list SRT and RTSP network input for this model; NDI and NDI|HX appear on other Pearl systems, not Pearl Nano.
Recommended workflow
Use SDI or HDMI into Pearl Nano, configure the channel for H.264/AAC for the first test, create an SRT push stream, and send it to the Callaba SRT server. H.265/HEVC is supported on updated Pearl Nano firmware, but H.264 is still the safer first choice when the downstream path includes RTMP, browser playback, or third-party decoders that may not accept HEVC.
4K/UHD is not something I assume on every unit. Confirm that the 4K Feature Add-on is active before planning 4K capture or 4K encoding. DCI 4K is not supported on Pearl Nano.
Before you start
Confirm firmware, power, input format, audio source, uplink speed, and the public network path before the event. For hard-to-diagnose SRT handshake failures, also confirm compatible SRT major versions using Pearl Nano firmware release notes or vendor support information, and compare that with the Callaba server build or support information.
Create the Callaba ingest
In Callaba, create an SRT server and choose a UDP port. Use listener mode for the first test. If your workflow uses Stream ID or a passphrase, type the exact values you will enter on Pearl Nano. Then copy the listener address and port for the Pearl Nano URL field.
If Pearl Nano is set as listener instead, the venue side must accept an inbound internet connection. That usually means public IP or port forwarding, firewall rules, and a tested NAT traversal plan. Treat that as an advanced fallback, not the normal Pearl Nano SRT setup.
Configure Pearl Nano
Open the Pearl Nano Admin panel. Go to the channel, open Streaming, click New stream, and choose SRT push. Expand the new stream settings, set Connection mode to Caller, paste the Callaba listener URL in the URL field, and enter the Stream ID, encryption, passphrase, latency, and recovery overhead values that match your Callaba ingest.
Epiphan documents a 125 ms default SRT latency. For public internet testing, I usually start at 250-500 ms if the path is unknown, then lower it only after packet loss, RTT, and retransmits are stable. Keep recovery overhead within the available uplink; the total stream demand is video bitrate plus overhead.
Settings table
| Where | What to do / field to fill | First-test value | Why / check |
|---|---|---|---|
| Callaba | Create SRT server and choose UDP port | Listener on a known open UDP port | Pearl Nano caller must reach this address and port. |
| Callaba | Configure Stream ID if your ingest requires it | Simple exact string, no spaces at the ends | Stream ID is case-sensitive and whitespace-sensitive. |
| Pearl Nano Admin panel | Channel(s) → channel → Streaming → New stream → SRT push | One test stream | Creates the Pearl Nano SRT output. |
| Pearl Nano SRT push settings | Connection mode field | Caller | Outbound from venue to cloud is the simplest path. |
| Pearl Nano SRT push settings | URL field | srt://callaba-host:port | Use the Callaba listener address and UDP port. |
| Pearl Nano SRT push settings | Stream ID field | Exact Callaba value | A trailing space or copied newline can break the handshake. |
| Pearl Nano SRT push settings | Passphrase field | 10-79 alphanumeric characters when encryption is used | Match AES/passphrase settings on both sides. |
| Pearl Nano SRT push settings | Latency field in milliseconds | 125 ms on clean paths, 250-500 ms for first internet test | Raise latency if packet recovery is unstable. |
Monitoring, recording, and playback
After you click Start on Pearl Nano, watch Callaba for connection uptime, incoming bitrate, preview, audio meters, RTT, packet loss, and retransmits. Recording, restreaming, routing, multiview, and playback are parallel downstream uses after the SRT feed is received; they do not need to be configured in a serial chain.
If you also record locally on Pearl Nano, treat that as a separate backup path. It is useful, but it does not prove the cloud SRT contribution is healthy; Callaba receiver stats do.
Troubleshooting
| Symptom | Check in Callaba | Check on Pearl Nano | Likely fix |
|---|---|---|---|
| No connection | SRT server is running, port is correct, no connection uptime | Connection mode, URL field, Start state | Use Pearl Nano Caller to Callaba Listener and confirm UDP reachability. |
| Handshake fails | Stream ID/passphrase mismatch, rejected connection logs if available | Stream ID, AES key length, passphrase, copied spaces | Retype case-sensitive values manually and confirm SRT version compatibility. |
| Connects then drops | RTT, packet loss, retransmits, incoming bitrate spikes | Bitrate, recovery overhead, latency field | Lower bitrate, raise latency, or improve uplink stability. |
| Preview but no audio | Audio meters and selected audio track | Embedded SDI/HDMI, XLR/RCA, USB audio source selection | Select the correct Pearl Nano audio source and test AAC first. |
| RTMPS fallback fails | RTMP server logs and publish authentication | RTMPS URL, stream name/key, CA certificate | Upload the required CA certificate or use SRT instead. |
| HEVC not visible downstream | Decoder/player capability | Codec choice and firmware | Use H.264 for broad compatibility; use H.265 only when the whole chain accepts it. |
Official references
Vendor references
- Epiphan Pearl Nano tech specs
- About streaming using SRT on Pearl Nano
- Pearl Nano SRT caller and listener setup
- Pearl Nano SRT AES encryption and passphrase
- Pearl Nano RTMP and RTMPS push setup
- Pearl Nano RTSP announce setup
- About 4K on Pearl Nano
- Epiphan Pearl systems comparison
Protocol references
Callaba resources
FAQ
How do I use Epiphan Pearl Nano with SRT?
Create an SRT listener in Callaba, then configure Pearl Nano SRT push as Caller and send it to the Callaba host and UDP port.
Can Pearl Nano be the SRT listener?
Yes, Epiphan documents caller, listener, and rendezvous modes. For cloud contribution, I still prefer Pearl Nano as Caller because the venue does not need to accept inbound internet traffic.
Is Callaba the Pearl Nano SRT receiver?
In this workflow, yes. Callaba receives the SRT contribution, shows preview and transport stats, and can record, route, restream, or publish playback outputs after ingest.
Does Pearl Nano support RTMP or RTMPS instead of SRT?
Yes. RTMP and RTMPS push are documented. For RTMPS, certificate validation can fail with private endpoints unless the needed CA certificate is installed on Pearl Nano.
Does Pearl Nano support NDI?
No for this exact model. Do not plan Pearl Nano as a native NDI or NDI|HX source. Use SRT or RTSP workflows instead.
Should I use H.264 or H.265?
Start with H.264 unless you control the whole decoder and player chain. H.265 is supported on updated firmware, but downstream compatibility is the deciding factor.
Next steps
Build a short end-to-end test before production day: Pearl Nano SDI or HDMI input, Callaba SRT listener, preview, audio meters, recording, and one final output. Save the working Pearl Nano stream settings and document the Callaba port, Stream ID, passphrase policy, latency, bitrate, and recovery overhead.
Try Callaba Gateway with Epiphan Pearl Nano SRT setup
Create an SRT server in Callaba, send the device feed to the gateway, and check the received stream. After ingest is stable, use Callaba outputs for preview, recording, restreaming, multiview, playback, routing, or API workflows as parallel downstream options.