К нам приходит клиент с задачей: смотреть камеру видеонаблюдения прямо в приложении. Звучит просто, но на практике возникает ряд проблем. RTSP-поток от IP-камеры нельзя открыть нативными плеерами iOS и Android напрямую. RTMP устарел. WebRTC работает, но требует сигнальный сервер. Низкая задержка в 200 мс — это совсем другая архитектура, чем HLS с 5-секундным буфером. Мы за 5+ лет разработали проверенные решения для этих сценариев и реализовали более 50 проектов потокового видео.
В этой статье разберем реальные технические подходы: транскодирование на сервере, нативный RTSP-декодер и WebRTC-клиент. Вы узнаете, как реализовать PTZ-управление, запись и мультикамерность. Получите консультацию по вашему проекту.
Почему RTSP нельзя открыть нативным плеером?
AVPlayer не поддерживает rtsp:// — только http(s):// и HLS. ExoPlayer официально убрал RTSP в Media3 (хотя поддержка есть через RtspMediaSource, она нестабильна на ряде производителей с нестандартными прошивками). На Flutter нет зрелого нативного RTSP-плеера. Как указано в документации Apple, это архитектурное ограничение.
Рабочих подходов два.
Транскодирование на сервере (RTSP → HLS/WebRTC)
Медиасервер (MediaMTX, Nginx-RTMP + ffmpeg, Ant Media Server) принимает RTSP от камеры и отдаёт HLS или WebRTC endpoint клиенту. Клиент получает HLS — AVPlayer / ExoPlayer читают без проблем. Задержка HLS: 3-8 секунд при стандартном чанке 2 сек. Для мониторинга это приемлемо. Для домофона — нет.
paths: cam1: source: rtsp://admin:[email protected]:554/stream1 hlsAlwaysRemux: yes Клиент подключается к http://media-server/cam1/index.m3u8.
Нативный RTSP-декодер в приложении
iOS: VLCKit (MobileVLCKit) — обёртка над libVLC. Поддерживает RTSP, RTMP, H.264, H.265. VLCMediaPlayer с drawable = UIView — рендерит прямо в view. Задержка: 500-800 мс при сетевом буфере 300 мс. Минус: бинарник +30 МБ, App Store принимает без проблем.
Кастомный путь: FFmpeg через ffmpeg-kit-ios (FFmpegKitConfig.executeAsync), декодируем поток и рендерим через AVSampleBufferDisplayLayer. Даёт полный контроль над буферизацией и задержкой (можно довести до 100-200 мс при rtsp_transport tcp и минимальном analyzeduration). Сложнее в реализации, но результат лучше.
Android: ExoPlayer RtspMediaSource — для простых случаев. Для сложных (RTSP через TCP, H.265, многопоточные камеры) — ijkplayer или FFmpegKit. ijkplayer работает с Jetpack Compose через AndroidView.
Flutter: flutter_vlc_player (MobileVLCKit / libVLC Android) — кросс-платформенный вариант. video_player плагин RTSP не поддерживает.
Что выбрать: RTSP или WebRTC?
Если задержка не критична (мониторинг склада), достаточно RTSP через VLCKit/FFmpegKit. Если важна интерактивность (домофон, управление PTZ-камерой), WebRTC — правильный выбор с задержкой 100-300 мс.
Архитектура WebRTC: IoT-камера → WebRTC-совместимый медиасервер (Janus, Kurento, MediaSoup, Ant Media) → мобильный клиент через ICE/STUN/TURN.
iOS: WebRTC framework (pod 'GoogleWebRTC' или pod 'WebRTC-SDK'). Создаём RTCPeerConnection, получаем SDP offer от сервера, отвечаем answer, получаем RTCVideoTrack и рендерим через RTCMTLVideoView (Metal-рендеринг, аппаратное ускорение). Сигнализация — WebSocket (Starscream, URLSessionWebSocketTask).
Android: io.getstream:stream-webrtc-android или официальный WebRTC за Google. SurfaceViewRenderer для рендеринга VideoTrack.
Flutter: flutter_webrtc — использует нативный WebRTC под капотом. RTCVideoRenderer + RTCVideoView.
Для прохождения через NAT обязателен STUN (бесплатный Google stun.l.google.com:19302) и TURN-сервер для симметричных NAT (Coturn на своём сервере).
Как реализовать PTZ-управление?
Pan/Tilt/Zoom через ONVIF или проприетарный HTTP API камеры. На мобильном: UIPanGestureRecognizer → вычисляем дельту → отправляем ONVIF ContinuousMove запрос через HTTP. Pinch → AbsoluteMove с zoom-координатой.
Дроблинг запросов: не отправляем каждое событие жеста — throttle(300ms), иначе камера не успевает обрабатывать команды.
Запись и снапшоты
Снапшот с камеры: дешевле запросить JPEG snapshot URL напрямую у камеры (большинство IP-камер поддерживают http://cam/snapshot.jpg) чем захватывать кадр из видеопотока.
Запись потока на устройстве: AVAssetWriter (iOS) пишет CMSampleBuffer из декодированного потока в MP4. На Android — MediaMuxer + MediaCodec. Для записи на сервере — ffmpeg -i rtsp://... -c copy output.mp4 через медиасервер.
Мультикамерность
Список камер + миниатюры потоков. Не воспроизводим все потоки одновременно — только активную. Превью: статичный snapshot, обновляемый каждые 5 секунд (URLSession.dataTask + UIImageView). Экономит батарею и трафик на 90%.
| Платформа | RTSP-библиотека | Задержка | Особенности |
|---|---|---|---|
| iOS | MobileVLCKit | 500-800 мс | +30 МБ, App Store одобрен |
| iOS | ffmpeg-kit | 100-200 мс | Полный контроль |
| Android | ExoPlayer | 300-800 мс | Просто, но нестабильно |
| Android | ijkplayer | 200-500 мс | Работает с H.265 |
| Flutter | flutter_vlc_player | 500-800 мс | Кроссплатформа |
| Протокол | Задержка | Сложность клиента | Прим. |
|---|---|---|---|
| HLS (RTSP→HLS на сервере) | 3-8 сек | Низкая (нативный плеер) | Мониторинг |
| RTSP (VLCKit/FFmpegKit) | 300-800 мс | Средняя | Универсально |
| WebRTC | 100-300 мс | Высокая | Домофон, PTZ |
Процесс работы
- Анализ камеры и сети — проверяем протоколы, разрешение, NAT-прохождение.
- Выбор протокола и архитектуры — на основе требований к задержке.
- Интеграция плеера и тестовый стенд — запускаем демо с одной камерой.
- Оптимизация буферизации и рендеринга — добиваемся целевой задержки.
- ПТЗ, запись, мультикамерность — реализуем дополнительные функции.
- Тестирование на устройствах — проверяем на iOS, Android, разных прошивках.
- Передача кода и документации — обучаем команду заказчика.
Мы помогаем выбрать оптимальный протокол, что позволяет сэкономить бюджет. Стоимость разработки обсуждается после аудита вашего проекта. Свяжитесь с нами для бесплатного аудита вашего проекта. Закажите разработку видеопотока — получите консультацию по проекту.
Что входит в работу
- Архитектурная документация с выбором протоколов и конфигураций
- Развертывание демо-среды с одной камерой для тестирования
- Интеграция WebRTC с сигнальным сервером и TURN
- Обучение команды заказчика работе с кодом и конфигами
- Поддержка после запуска: гарантия 12 месяцев на решение
Сроки ориентировочно: от 3 дней до 3 недель в зависимости от сложности. Оценим ваш проект в течение 2 рабочих дней. Мы гарантируем работоспособность на всех устройствах.