Stable Live Video from Mobile via SRT Protocol

Stable Live Video from Mobile via SRT Protocol

Your mobile device streams live video from the scene, but the LTE network is unstable—packet loss reaches 20%. RTMP streams break, viewers see a black screen. We solve this with the SRT Protocol. Unlike RTMP, SRT works over UDP with built-in error correction (ARQ/FEC), tolerates up to 30% packet loss, and automatically recovers the stream without restarting. In fact, SRT is 5 times more reliable than RTMP under similar packet loss conditions. For mobile streaming over unreliable LTE or public Wi-Fi, this is a game-changer. Our team has over 5 years of mobile development experience and has delivered over 20 video streaming projects. We guarantee stable SRT connections in challenging network conditions with certified developers. A typical project with both iOS and Android integration starts at $1000, with savings on server costs compared to RTMP. Contact us for a consultation on your project. Integration starts from $500 for basic setup on one platform.

Why SRT Outperforms RTMP on Mobile

At just 5% packet loss, RTMP starts buffering and breaking; SRT with a latency=500ms buffer remains stable at 20-25% loss. SRT provides up to 10 times lower latency (200–2000 ms vs 5–10 s) and uses jitter buffers and FEC to maintain quality. For reporter-style streaming from events, remote video production, and field broadcasts, SRT has become the professional standard—native support in OBS, vMix, and Blackmagic. Latency is adjustable via the latency parameter: 200 ms minimum for good networks, 500-2000 ms for mobile networks with jitter. Larger buffer = more resilience, but higher delay. Infrastructure savings: SRT doesn't require expensive servers or TCP accelerators—it runs over UDP, reducing operational costs.

Ensuring a Stable Connection Under Weak Signal

SRT supports automatic reconnection within connectionTimeout. While basic parameter tuning helps, we go further: we monitor pktSndLoss and when it exceeds 5%, we automatically reduce videoBitrate and increase latency. This requires a reconnection but prevents a total stream failure.

iOS: HaishinKit with SRT

HaishinKit has supported SRT since version 2.x through SRTConnection:

import HaishinKit let srtConnection = SRTConnection() let srtStream = SRTStream(connection: srtConnection) srtStream.videoSettings = VideoCodecSettings( videoSize: CGSize(width: 1920, height: 1080), bitRate: 5_000_000, profileLevel: kVTProfileLevel_H264_High_AutoLevel as String ) srtStream.audioSettings = AudioCodecSettings(bitRate: 192_000) try srtStream.attachCamera(AVCaptureDevice.default(.builtInWideAngleCamera, for: .video, position: .back)) try srtStream.attachAudio(AVCaptureDevice.default(for: .audio)) // Caller mode: we initiate the connection srtConnection.connect("srt://192.168.1.100:9998?latency=500&streamid=live/stream1") srtStream.publish() 

The streamid identifies the stream on the server (MediaMTX, SRT Live Server use it for routing). latency is in milliseconds. Reconnection on disconnect: SRT automatically reconnects within connectionTimeout. HaishinKit exposes SRTConnection.Event.connect with a reason—handle in your delegate.

Android: rtmp-rtsp-stream-client-java with SRT

The rtmp-rtsp-stream-client-java library supports SRT via SrtCamera2:

val srtCamera = SrtCamera2(binding.surfaceView, connectChecker) srtCamera.prepareVideo( width = 1920, height = 1080, fps = 30, bitrate = 5_000_000, rotation = 0, profile = CodecUtil.H264_BASELINE ) srtCamera.prepareAudio(bitrate = 192_000, sampleRate = 44100, isStereo = true) srtCamera.startStream("srt://192.168.1.100:9998?streamid=live/stream1&latency=500") 

Under the hood: native libsrt (C++) compiled for Android ABIs (arm64-v8a, armeabi-v7a, x86_64).

Alternative: FFmpegKit with libsrt

Build FFmpegKit with libsrt and use it directly:

-f avfoundation -i 0:0 -c:v h264_videotoolbox -b:v 5M -f mpegts "srt://server:9998?latency=500&streamid=live/test" 

Advantage: H.265 support (hevc_videotoolbox), more control. Con: FFmpegKit doesn't manage the camera directly—you need a separate capture via AVCaptureVideoDataOutput + pipe.

Listener vs Caller Mode

SRT supports two modes:

• Caller — the mobile device initiates the connection to a server. Most common.
• Listener — the device listens for incoming connections. Useful for p2p without a server or when the server is behind NAT.
• Rendezvous — both ends initiate simultaneously. For p2p through NAT without relay.

For mobile streaming, we use Caller. Listener on mobile is rare (IoT device without public IP).

Encryption

SRT has built-in AES-128/256 encryption via passphrase and pbkeylen in the URL. This is a differentiator from RTMP—encryption is protocol-level, not a TLS wrapper.

srt://server:9998?passphrase=MySuperSecret&pbkeylen=32 

Quality Monitoring

SRT API provides statistics via srt_bistats(): pktSndLoss, pktRcvLoss, pktRetrans, mbpsSendRate, msRTT. HaishinKit exposes some stats in SRTStream.info. We display bitrate, RTT, and packet loss in the UI—professional users value this. When pktSndLoss exceeds 5%, we automatically reduce videoBitrate and increase latency (requires reconnection).

SRT vs RTMP Comparison

Server Compatibility

What's Included in the Work

1. Requirements analysis and library selection.
2. Integration of SRT streaming on iOS and/or Android.
3. Configuration of latency, passphrase, streamid parameters.
4. Implementation of quality monitoring (RTT, loss, bitrate).
5. Documentation and training for your team.
6. Post-launch support.

Timeline: integration on one platform — 2–4 business days. Cost starts from $500 per platform. To evaluate your project, contact us — we'll respond within 1 business day. We have successfully completed 20+ projects with guaranteed performance metrics.