Osprey Talon SRT setup hub: 4K-SC and UHD-SC
More live video workflow notes and product updates.
Osprey Talon selection
Choose the Talon by its source interface and raster, not by a shared SRT badge
Talon 4K-SC and Talon UHD-SC are both single-channel hardware encoders, and both current product entries list H.264, H.265 and SRT. That does not make them interchangeable. The first decision is the physical source and maximum picture format; the SRT connection comes after the encoder has a stable input.
Callaba is the receiver and operating layer in this design. It confirms that the intended Talon reached the expected endpoint, exposes transport health and decoded media, and can then attach Multiview, recording or a downstream route.
Compare the two Talon inputs before opening a port
The table is a buying and pre-flight aid, not a substitute for the installed unit’s manual. It captures the durable distinction that changes the workflow and keeps similar model names from becoming a copied configuration.
| Decision | Talon 4K-SC | Talon UHD-SC |
|---|---|---|
| Source interface | HDMI 2.0 or 12G-SDI | One 12G-SDI input |
| Documented raster boundary | UHD and DCI 4K formats, up to 4096×2160 | Up to 3840×2160p60 |
| Shared transport capability | Product entry lists H.264, H.265 and SRT | Product entry lists H.264, H.265 and SRT |
| Detailed procedure | Open the 4K-SC guide | Open the UHD-SC guide |
Give each system one clear responsibility
Talon owns the source
Input lock, source timing, color and audio selection, codec profile and output bitrate belong to the encoder. HDCP or an unsupported source format must be diagnosed here, before the network.
The handoff owns the contract
Record the peer address, UDP port, Caller or Listener role, Stream ID, passphrase policy and agreed latency. Security fields and available controls must be rechecked against the installed firmware.
Callaba owns acceptance
Use receiver state, sustained bitrate, decoded video, audio, a sample recording and the final destination to prove the feed. A connected socket alone is not an accepted program.
Build one clean Talon-to-Callaba path
Begin with the real production source, not a lower-resolution convenience signal. Confirm the exact chassis, firmware and source interface, then create one Talon encode profile. Create the matching Callaba endpoint and choose the SRT role from actual network reachability: the side behind restrictive NAT commonly originates the session, but the event network decides the final design.
Start only this path. If the session does not establish, compare mode, address, port, firewall, Stream ID and encryption without also changing codec settings. If transport connects but there is no useful picture, return to source lock, timing and encode status. This separation makes the model hub useful during an incident rather than merely descriptive.
Use a five-part acceptance meter
Only after all five checks pass should the team add more destinations, a recovery route or automation. That order prevents encoder and network capacity issues from being hidden behind a larger fan-out.
Keep the production record reproducible
Save the exact Talon model, firmware, source format, encoder profile and redacted SRT contract with the event runbook. Add a sample recording and Multiview screenshot from the rehearsal. Re-run the acceptance meter after firmware changes, source changes or a move to a different uplink; a saved profile is useful evidence, not proof that the current path still works.
Verify against Osprey’s current documentation
Check Osprey’s Talon encoder family, software and firmware page, and manual library before committing the workflow. Product controls can change with software, so this page deliberately avoids inventing a universal field-by-field procedure.
