Реализация SRT-стриминга с мобильного устройства

Реализация SRT-стриминга с мобильного устройства

SRT (Secure Reliable Transport) — протокол для профессионального стриминга по ненадёжным сетям. В отличие от RTMP он работает поверх UDP с механизмом коррекции ошибок (ARQ/FEC), выдерживает до 30% потерь пакетов и автоматически восстанавливает поток без перезапуска. Для мобильного стриминга из нестабильного LTE или публичного Wi-Fi — это принципиальное преимущество.

Где SRT лучше RTMP

RTMP на потере 5% пакетов начинает буферизоваться и рассыпаться. SRT с latency=500ms буфером держится при 20-25% потерь. Для репортажного стриминга с мест событий, для видеопроизводства на выезде, для удалённых трансляций — SRT стал стандартом в профессиональной среде (OBS, vMix, Blackmagic принимают SRT нативно).

Задержка: настраиваемая через latency параметр. 200 мс — минимум для хорошей сети. 500-2000 мс — для мобильных сетей с джиттером. Больше буфер — больше устойчивость, больше задержка.

iOS: HaishinKit с SRT

HaishinKit поддерживает SRT начиная с версии 2.x через 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: мы инициируем соединение
srtConnection.connect("srt://media-server.example.com:9998?latency=500&streamid=live/stream1")
srtStream.publish()

streamid — идентификатор потока на сервере (MediaMTX, SRT Live Server используют его для маршрутизации). latency в миллисекундах.

Reconnect при обрыве: SRT умеет автоматически переподключаться в рамках connectionTimeout. HaishinKit пробрасывает SRTConnection.Event.connect с reason — обрабатываем в делегате.

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

Библиотека rtmp-rtsp-stream-client-java поддерживает SRT через 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://media-server.example.com:9998?streamid=live/stream1&latency=500")

Под капотом — нативная libsrt (C++), скомпилированная под Android ABIs (arm64-v8a, armeabi-v7a, x86_64).

Альтернатива: FFmpegKit с libsrt

FFmpegKit собирается с libsrt — можно использовать напрямую:

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

Преимущество: поддержка H.265 (hevc_videotoolbox), больший контроль над параметрами. Минус: FFmpegKit процесс не управляет камерой напрямую — нужен отдельный захват через AVCaptureVideoDataOutput + pipe.

Listener vs Caller режим

SRT поддерживает два режима:

• Caller — мобильное устройство инициирует соединение на сервер. Самый распространённый сценарий.
• Listener — устройство слушает входящее соединение. Полезно для p2p без сервера или когда сервер находится за NAT.
• Rendezvous — оба конца одновременно инициируют соединение. Для p2p через NAT без relay.

Для мобильного стриминга используется Caller. Listener на мобильном — редкий сценарий (устройство IoT на мобильной сети без публичного IP).

Шифрование

SRT поддерживает AES-128/256 шифрование из коробки: passphrase и pbkeylen параметры в URL. Это отличает SRT от RTMP — шифрование встроено в протокол, не TLS обёртка поверх.

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

Мониторинг качества соединения

SRT API предоставляет статистику через srt_bistats(): pktSndLoss, pktRcvLoss, pktRetrans, mbpsSendRate, msRTT. HaishinKit пробрасывает часть статистики в SRTStream.info. Отображаем в UI: битрейт, RTT, потери пакетов — профессиональные пользователи это ценят.

При высоком pktSndLoss (>5%) — автоматически снижаем videoBitrate и увеличиваем latency параметр (требует переподключения).

Совместимость серверов

Сроки: интеграция SRT-стриминга на одну платформу с мониторингом качества соединения — 2-4 рабочих дня.