Відеоспостереження в мобільному додатку на смартфоні — технічно найважча частина розумного дому. Стримінг з IP-камер у реальному часі, надійна детекція руху з push-сповіщеннями, перегляд архіву записів, організація P2P-з'єднання без виділеного IP — кожен із цих пунктів вимагає нетривіальних інженерних рішень. За роки ми реалізували понад 20 проєктів: від квартирних домофонів на Raspberry Pi до комплексних систем безпеки з десятками камер. Наш досвід включає інтеграцію з камерами Hikvision, Dahua, Reolink та іншими моделями, роботу з різними протоколами (RTSP, HLS, WebRTC) та мережами будь-якої складності — від простого домашнього NAT до корпоративних VPN. Це дозволяє гарантувати стабільну роботу додатку навіть при нестабільному мобільному інтернеті та в складних NAT-сценаріях, де пряме з'єднання неможливе. Розглянемо ключові технічні аспекти, які визначають якість та продуктивність додатку для розумного дому. Ми використовуємо SDP (Session Description Protocol) для конфігурації WebRTC та ICE (Interactive Connectivity Establishment) для NAT traversal. RTSP використовує RTP для транспортування медіа та RTCP для контролю.
Який протокол відеостріму обрати для мобільного додатку відеоспостереження?
Три основні протоколи для IP-камер: RTSP, HLS та WebRTC. У таблиці нижче — ключові відмінності.
| Протокол | Затримка | Використання | Нативна підтримка на мобільних |
|---|---|---|---|
| RTSP | 300–800 ms | Прямий стрім з камери | Ні, потрібна бібліотека (VLC, media_kit) |
| HLS | 3–15 s | Перегляд архіву, ретрансляція | Так, у браузерах та AVPlayer |
| WebRTC | < 500 ms | Live-перегляд, двосторонній зв'язок | Так, через спеціальні SDK |
RTSP — стандарт для більшості NVR/DVR та IP-камер (Hikvision, Dahua, Reolink). Низька затримка, але немає нативної підтримки. На Flutter ми використовуємо відеоплеєр (flutter_vlc_player), що підтримує RTSP, HLS та інші протоколи. HLS працює всюди, але затримка 3–15 секунд. Сервер (FFmpeg, MediaMTX) бере RTSP-потік камери та віддає HLS. Ідеально для архіву, прийнятно для live з моніторингом, неприйнятно для двостороннього зв'язку. WebRTC — мінімальна затримка, P2P без сервера-посередника. Використовуємо для intercom та baby monitor. На Flutter: flutter_webrtc, на React Native: react-native-webrtc. Вимагає STUN/TURN сервери — coturn self-hosted або Twilio/Cloudflare.
Чому WebRTC кращий для live-перегляду?
HTTP Live Streaming дає затримку від 3 секунд — це забагато для домофона або спостереження в реальному часі. WebRTC забезпечує <500 ms, що критично для сценаріїв, де потрібно реагувати миттєво. Затримка WebRTC у 6-30 разів менше, ніж HLS, що робить його набагато кращим для live-перегляду. Крім того, WebRTC підтримує двосторонній аудіозв'язок без додаткових протоколів. Для більшості home security додатків оптимальна зв'язка: WebRTC для live + HLS для архіву.
P2P та NAT traversal
Користувач дивиться камеру вдома, перебуваючи в роумінгу. Камера за NAT роутера без білого IP. Варіанти:
| Метод | Працездатність | Затримка/вартість | Складність |
|---|---|---|---|
| UPnP/Port Forwarding | Залежить від користувача | Нульова | Висока (користувач) |
| TURN relay | 100% | Ретрансляція, затримка +50ms | Середня (сервер) |
| Hole punching (ICE через STUN) | 75–85% | STUN-сервер безкоштовний | Низька (клієнт+сервер) |
| Тунелі (WireGuard/Tailscale) | 99% | VPN-сервер | Середня (налаштування) |
UPnP/Port Forwarding — користувач має сам налаштувати, нереалістично для споживчого продукту. TURN relay — всі дані йдуть через relay-сервер. Працює завжди, але дорого та додає затримку. Hole punching (ICE через STUN) — пряме P2P з'єднання через обмін зовнішніми IP/портами. Працює в ~75–85% випадків із Symmetric NAT. coturn як STUN безкоштовний. Типова економія при використанні hole punching замість TURN relay становить до 90%: при обсязі трафіку 100 ГБ на місяць це 10 доларів США проти 100 доларів через Twilio. Тунелі (WireGuard, ZeroTier, Tailscale) — пристрої в домашній мережі підключені до VPN-мешу. Мобільний додаток підключається до того ж мешу. Tailscale SDK для мобільних є офіційний. Найнадійніший варіант, вимагає налаштування на стороні роутера/сервера.
Реальний проєкт: квартирний домофон-камера на Raspberry Pi + WebRTC + coturn. Hole punching працював у 80% випадків, для решти TURN relay. Середня затримка відео в P2P режимі — 180–250ms. Економія на relay-трафіку склала до 90% (при типовому обсязі трафіку вартість relay через Twilio — близько $0.10 за гігабайт).
Як реалізувати motion detection сповіщення?
Детекція руху на стороні камери: більшість IP-камер надсилають HTTP webhook або MQTT при спрацьовуванні. Приймаємо на бекенді → FCM/APNs push з content-available: 1. На iOS: UNNotificationServiceExtension для додавання прев'ю-зображення. Камера разом з webhook надсилає URL знімка — extension завантажує та прикріплює до notification. На Android: BigPictureStyle через Firebase Messaging. Детекція через ML на клієнті — не робимо, вбиває батарею.
Запис та архів
Локальний запис на SD-карту камери → перегляд через архів у додатку. NVR API (Hikvision ISAPI, Blue Iris API) для навігації. Timeline архіву — горизонтальна смуга часу з мітками руху. На Flutter: кастомний CustomPainter з Canvas.drawRect для кожного сегмента. Хмарне зберігання: завантажуємо фрагменти руху на S3/GCS з TTL-політикою 7–30 днів. Середня вартість хмарного зберігання для 30-денного архіву з 10 камерами — близько 1000 гривень на місяць.
Що входить в роботу
- Проєктування архітектури додатку з урахуванням масштабування
- Розробка модулів стрімінгу, сповіщень та архіву
- Інтеграція з хмарними сервісами (S3, Firebase)
- Тестування на реальних камерах та мережевих сценаріях
- Документація з API та деплою
- Підтримка після запуску (2 тижні гарантійного супроводу)
Процес розробки та терміни
- Аналітика та вибір протоколів — обговорюємо типи камер, очікувану затримку, сценарії використання.
- Проєктування — малюємо архітектуру, визначаємо стек (Flutter/React Native, coturn, FFmpeg).
- Розробка — реалізуємо стрімінг, P2P, сповіщення, архів.
- Тестування — перевірка на різних моделях камер та типах NAT.
- Деплой та документація — розгортання серверів, публікація в App Store/Google Play.
Базова версія (одна камера, RTSP/HLS, сповіщення) — 5–7 тижнів. Повнофункціональне рішення (мультикамерний вид, WebRTC, архів, двосторонній зв'язок) — 3–5 місяців. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію щодо вибору архітектури та термінів реалізації.