TVU MediaHub SRT setup: send SRT to Callaba Gateway
More live video workflow notes and product updates.
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
TVU MediaHub SRT setup is a direct contribution workflow: configure the MediaHub output as an SRT Caller and receive it on a Callaba SRT Listener. Use this setup when TVU MediaHub is at the venue, or when its cloud/on-prem instance is the production output point for venue signals, and Callaba is the cloud SRT receiver for monitoring, recording, routing, multiview, or restreaming.
TVU’s public MediaHub documentation confirms SRT, RTMP, RTMPS, RTSP, NDI, HLS, UDP, RTP+FEC, and MPEG-TS/SPTS/MPTS as supported formats. The practical operator question is not whether the acronym appears in a datasheet; it is which endpoint calls, which fields must match, and what to check before the event.
Quick answer
To use TVU MediaHub with SRT, set TVU MediaHub 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.
TVU MediaHub sends one SRT caller feed into Callaba. Callaba receives it as an SRT listener and can use the same source for preview, recording, routing, multiview, playback, and restreaming in parallel.
- TVU MediaHubSRT Caller output
- Callaba GatewaySRT Listener receiver
- Preview
- Record
- Route
- Restream
What this setup does
This workflow makes Callaba the cloud SRT receiver for a TVU MediaHub output. MediaHub contributes the feed; Callaba receives it, shows preview and stream statistics, and can then record, restream, route, or expose the source to players and production tools.
Keep the default direction simple: MediaHub calls out to Callaba over UDP. That usually avoids inbound firewall rules at the venue or production network. Reverse the direction only when your MediaHub deployment is deliberately configured as an SRT Listener and the network path for inbound UDP has been tested.
What this model can and cannot do in this workflow
- TVU describes MediaHub as a cloud-based router for SDI and IP signal matrices with real-time encoding, scaling, and decoding.
- The MediaHub datasheet lists SRT, RTMP, RTMPS, RTSP, NDI, HLS, UDP, RTP+FEC, and MPEG-TS/SPTS/MPTS as supported input/output formats.
- TVU’s public API examples confirm SRT source and output URLs in Caller and Listener modes, including a latency parameter.
- Public MediaHub examples do not clearly document SRT passphrase, encryption, Stream ID, Rendezvous mode, or SRT library version. Confirm those fields in your account, UI, API, or TVU support channel before the event.
- RTMP and RTSP URL patterns are documented in the public API page. RTMPS is listed in the datasheet, but the public URL examples I found show RTMP syntax, so confirm the exact RTMPS destination format before relying on it.
- NDI is confirmed for MediaHub, but treat it as a LAN or edge workflow, not as the normal public-internet contribution path.
- SDI and SMPTE ST 2110/2022 paths are marked as optional edge-device workflows. Do not plan baseband or ST 2110/2022 without the required TVU edge resource.
- MediaHub-specific public material does not clearly confirm HDMI I/O or HEVC/H.265 support. Do not assume either unless your MediaHub deployment exposes those settings.
Recommended workflow
For a TVU MediaHub SRT gateway workflow, create an SRT Listener in Callaba first. Then configure the MediaHub output URL as an SRT Caller pointed at the Callaba public hostname or IP address and UDP port.
If your MediaHub environment exposes Stream ID or passphrase fields, copy them exactly on both sides. SRT Stream ID and passphrase values are case-sensitive and whitespace-sensitive; a trailing space, copied newline, or changed capitalization can break the handshake.
When not to use this setup
If MediaHub and the production switcher are on the same controlled LAN and you are already using NDI, local NDI may be simpler. If the only destination is a public platform and you do not need monitoring, recording, routing, or multiview in the middle, RTMP or RTMPS may be enough, provided your MediaHub account has the correct destination syntax.
If the job needs cloud monitoring, recording, returnable routing, restreaming, or API-controlled ingest, use the SRT-to-Callaba path. If the MediaHub SRT controls are not visible in your deployment, use RTMP/RTMPS first, then RTSP or NDI through an edge bridge only when that design is intentional.
Before you start
- Confirm your MediaHub deployment exposes SRT Caller or Listener settings for outputs.
- Decide the direction: MediaHub Caller to Callaba Listener is the normal internet-friendly path.
- Open the Callaba UDP port in the cloud firewall or security group.
- Prepare matching Stream ID and passphrase values only if both sides expose those fields.
- Check the selected MediaHub encoding profile against the players, decoders, and recording format required downstream.
Create the Callaba ingest
In Callaba, create an SRT server in Listener mode. Choose a UDP port, bind it to the public interface, and save the server. For the first test, avoid unnecessary authentication unless the production policy requires it; after basic transport works, add passphrase and Stream ID if MediaHub exposes matching fields.
Start the SRT server and keep the Callaba stream page open. You should be ready to check connection uptime, incoming bitrate, packet loss, RTT, retransmits, preview, and audio meters as soon as MediaHub starts sending.
Configure TVU MediaHub
In the MediaHub output configuration or API, create an SRT output. Choose Caller mode for the default workflow and enter the Callaba public hostname or IP address plus the Listener port. TVU’s public API examples show SRT Caller and Listener URL patterns and a latency value; use that as a reminder to set latency deliberately rather than leaving it unknown.
For a first internet test, start around 250-500 ms of SRT latency, then lower it only after RTT, packet loss, and retransmits are stable. If the MediaHub UI or API exposes passphrase, encryption, or Stream ID fields, match Callaba exactly. If those fields are absent, do not invent URL parameters for a live job without confirming them with TVU.
Settings table
| Where | What to do / field to fill | First-test value | Why / check |
|---|---|---|---|
| Callaba SRT server | Create Listener and choose UDP port | Public IP or DNS, UDP 10000-20000 range | MediaHub needs a reachable cloud listener. |
| Cloud firewall | Allow inbound UDP to the Callaba port | Same port as the SRT server | No packets will arrive if the security group blocks UDP. |
| MediaHub output URL area | Enter SRT Caller destination | srt://callaba-host:port with Caller mode | Caller from MediaHub avoids inbound venue firewall rules. |
| MediaHub SRT latency setting | Set latency in milliseconds | 250-500 ms for first public internet test | Increase if loss, RTT, or retransmits are unstable. |
| Callaba SRT authentication | Set Stream ID only if MediaHub exposes a matching field | Blank for transport test, then exact production value | Case, spaces, and copied newlines must match. |
| Callaba SRT authentication | Set passphrase only if MediaHub exposes a matching field | Blank for transport test, then exact production value | Public MediaHub docs do not clearly show this field. |
| MediaHub encoding profile | Select a profile compatible with downstream decoders | Use the approved production profile; confirm preview | Public samples show TVU264 and AAC, not a complete codec matrix. |
| Callaba stream page | Watch bitrate, preview, audio meters, RTT, loss, retransmits | Stable bitrate, visible picture, moving audio | This confirms both transport and usable media. |
Monitoring
After MediaHub starts sending, confirm that Callaba shows a connected SRT session, non-zero bitrate, stable connection uptime, and preview. Then check audio meters. A green transport connection without audio is not enough for a production handoff.
If the connection is stable but preview fails, check the MediaHub encoding profile. The public MediaHub API sample shows TVU264 for video and AAC for audio, but it does not publish a complete output codec matrix. Use a profile that your Callaba workflow and downstream decoders can actually play.
Failover and local ingest options
For production events, plan what happens if the main encoder, venue uplink, or primary contribution path fails. Callaba can be part of that continuity plan without changing the basic TVU MediaHub ingest workflow.
Recording and playback
Once ingest is stable, recording and playback are downstream choices in Callaba, not mandatory steps before routing. You can record the incoming MediaHub feed for compliance or editorial review, keep a browser preview open for operations, and route the same source to another destination at the same time.
Troubleshooting
| Symptom | Check in Callaba | Check on MediaHub | Likely fix |
|---|---|---|---|
| No SRT connection | Listener running, correct UDP port, firewall open | Caller mode, destination host and port | Fix IP/DNS, port, UDP firewall, or reversed role. |
| Handshake fails | Connection attempts, Stream ID, passphrase | Matching Stream ID/passphrase if exposed | Remove copied spaces/newlines and match capitalization exactly. |
| Connected but no picture | Incoming bitrate and preview status | Encoding profile and output format | Switch to a decoder-compatible profile and retest. |
| Dropouts or high latency | RTT, packet loss, retransmits, uptime | SRT latency and bitrate | Raise latency, lower bitrate, or improve the network path. |
| RTMPS fallback fails | RTMP app/key and endpoint logs | Exact RTMPS destination syntax | Confirm TVU’s RTMPS format; public examples mainly show RTMP. |
| NDI path not visible | Whether Callaba or bridge is on the same LAN | NDI source/output selection | Use an edge bridge or choose SRT/RTMP for cloud contribution. |
Official references
Vendor references
- TVU MediaHub product page
- TVU MediaHub datasheet
- TVU MediaHub API URL and type examples
- TVU encoding profile API sample
Protocol references
Callaba resources
FAQ
Does TVU MediaHub support SRT to Callaba?
Yes. TVU’s MediaHub datasheet lists SRT, and the public API examples show SRT Caller and Listener URL patterns. Before the event, confirm that your MediaHub deployment exposes the expected SRT settings.
Should TVU MediaHub be the SRT Caller or Listener?
Use MediaHub as the SRT Caller and Callaba as the cloud Listener for the normal internet workflow. MediaHub Listener mode is possible only when your deployment exposes it and the network can accept inbound UDP.
Can I use SRT Stream ID or passphrase with TVU MediaHub?
Public MediaHub examples do not clearly document those fields. If your UI or API exposes them, match Callaba exactly. Treat Stream ID and passphrase as case-sensitive and whitespace-sensitive.
Can I use RTMP or RTMPS instead?
Yes. MediaHub documentation confirms RTMP and RTMPS, but public URL examples show RTMP more clearly than RTMPS. Confirm the exact secure URL format before a live RTMPS fallback.
Where does NDI fit with MediaHub and Callaba?
NDI is confirmed for MediaHub, but it is usually a LAN or edge workflow. For cloud contribution over the public internet, SRT is the cleaner direct path unless you intentionally deploy an NDI-to-SRT bridge.
What codec should I choose?
Use a MediaHub encoding profile that Callaba preview and your downstream decoders can play. Public samples show TVU264 and AAC, but they do not define a full MediaHub codec matrix; do not assume HEVC unless your deployment exposes it.
Next steps
Build the SRT Listener in Callaba, send a short MediaHub test output, and verify transport statistics plus audio and video before the production window. After ingest is stable, add recording, multiview, restreaming, or routing as parallel outputs.
Try Callaba Gateway with TVU MediaHub SRT
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.