SRT Browser Playback Limits and Server Ingest
SRT is a reliable transport protocol, not a browser playback protocol. It requires server ingest and conversion.
Short answer
SRT is good for reliable contribution over unstable public networks, but browsers cannot play srt:// directly. In web projects it is usually a server-side ingest source.
Where it sits in a video pipeline
SRT solves reliable transport and packet loss resistance, not browser playback entry.
A common structure is: remote encoder SRT -> ingest server -> HLS/WebRTC/FLV -> browser.
How to use it in a browser project
When the frontend receives srt://, it can only identify and explain it, not play it through video or MSE directly.
What the server has to do
The server must configure caller/listener mode, port, latency, passphrase and firewall, then output a web protocol.
Common development scenarios
- Remote capture, event contribution, unstable networks and cross-region source ingest.
Debugging order
- Check SRT mode, port, passphrase and latency settings first, then whether the converted output is playable.
Recommended conversion paths
- SRT -> HLS for compatible delivery.
- SRT -> WebRTC for low-latency preview.
- SRT -> HTTP-FLV for engineering monitoring.
Minimum usable implementation
- Frontend: ask users to enter the converted HLS/WebRTC/FLV playback URL.
- Backend: run SRT ingest and output a browser-compatible format.
Developer decision rule
SRT should be judged by its role in the delivery chain, not by the protocol name alone. Browser result: Not directly playable in browsers. Before promising playback, confirm the source type, whether a server conversion is required, CORS and HTTPS policy, codec support and the latency target.