Android-приложение для IP-камер: основные функции и руководство по разработке в 2026 году

Зачем Фора Софт написала этот гайд

Фора Софт более 20 лет разрабатывает мультимедийное программное обеспечение. Мы создали V. A. L. T. — профессиональное решение для IP-камер, которое используют полицейские участки, центры защиты детей и медицинские кабинеты для допросов, — и поддерживаем Netcam Studio (современную версию WebcamXP, запущенную в 2003 году). Мы разработали Android-приложения для IP-камер как для OEM-интеграций, так и для white-label поставок, каждый раз соблюдая жёсткие требования по задержке, расходу батареи, объёму памяти и нормативным стандартам.

Этот гайд отражает то, что мы бы сказали руководителю продукта, который сегодня запускает Android-приложение для IP-камер: рынок 2026 года требует ИИ на устройстве, интеграцию со «умным домом» через Matter/Thread и соответствие PIPEDA и EU AI Act с самого старта. Просто транслировать видео уже недостаточно. Эта статья опирается на реальные приложения, которые мы выпустили, на архитектурные решения, о которых мы пожалели, и на функции, за которые наши пользователи — от стартапов из двух человек до операторов видеонаблюдения с командой в 50 человек — готовы платить.

На каждой мобильной разработке мы используем Agent Engineering. Генерация кода с помощью ИИ для обвязки RTSP-стека, каркаса ML-моделей и интеграции двухфакторной аутентификации сокращает срок с 22–28 недель (классический подход) до 12–20 недель, потому что каждую сгенерированную строку проверяет старший Android-инженер перед слиянием в основную ветку.

Рынок Android-приложений для IP-камер в 2026 году

Рынок изменился. Пять лет назад приложение для IP-камер со стримингом в реальном времени и двухфакторной аутентификацией считалось премиум-решением. В 2026 году это — базовый уровень. Чего сегодня ждут покупатели:

1. Инференс ИИ на устройстве. TensorFlow Lite и LiteRT, работающие прямо на Android, перестали быть опциональными. Детекция движения, классификация «человек / машина / посылка» и поиск аномалий поведения должны работать офлайн. Облачные модели не проходят даже стадию закупки, потому что они утекают записями и съедают слишком много трафика.

2. Интеграция со «умным домом» через Matter и Thread. В сфере безопасности Google Home, Alexa и HomeKit действительно стали популярными. Ваше приложение должно отображать камеры как устройства Matter, поддерживать mesh-сети Thread для энергоэффективных удалённых точек и реализовывать ONVIF Profile T — стандартный протокол для IP-камер в «умном доме».

3. Более жёсткое регулирование приватности. EU AI Act теперь распространяется на видеоаналитику. PIPEDA в Канаде, CCPA в Калифорнии и формирующиеся правила локализации данных в Бразилии и Индии означают, что хранить записи в произвольных регионах нельзя. Право на удаление по GDPR должно работать без сбоев, а ключи шифрования должны принадлежать клиенту, а не Форс Софт.

4. Android 15+ как базовая платформа. Scoped storage, ограничения на фоновую обработку и новые разрешения камеры означают, что совместимости с Android 12 уже недостаточно. Собирайте приложение под Android 15 и тестируйте на 13–14 как на альтернативных платформах.

5. Двустороннее аудио в реальном времени без компромиссов. Полицейские участки и центры защиты детей не пойдут на приложение «только с видео». Надёжное двустороннее аудио через RTCP, с подавлением эха и шума — теперь не преимущество перед конкурентами, а обязательное требование.

Ключевые функции Android-приложения для IP-камер

Эти функции не подлежат обсуждению. Если в приложении отсутствует хотя бы одна из них, сделки перейдут к конкурентам, у которых она есть.

Видеостриминг в реальном времени с адаптивным битрейтом

Приложение должно поддерживать RTSP (IETF RFC 7826), WebRTC поверх datagram-транспорта и HLS Low-Latency как резервный вариант для обхода NAT. H.264 — универсальный формат; H.265 экономит 30–40% трафика, но требует проверки поддержки аппаратного декодирования. Для видеодвижка на Android используйте ExoPlayer 2 или Media3. В реальном времени измеряйте скорость сети (вплоть до 0,5 Мбит/с для 360p) и автоматически снижайте качество без задержек. Это важнее, чем может показаться: двухсекундная пауза в комнате допросов делает приложение непригодным.

Удобный мультикамерный дашборд

Пользователь хочет тапнуть по камере, развернуть её на весь экран, свайпом перейти к следующей и масштабировать пальцами плавно, без рывков. Сделайте сетку 2×2 для четырёх камер, полосу превью для 6–10 камер и список с иконками для 20 и более. Кэшируйте превью в памяти; пока пользователь смотрит текущую камеру, предзагружайте ключевой кадр следующей.

Управление PTZ (pan-tilt-zoom)

PTZ есть не у всех камер, но многие IP-камеры поддерживают команды ONVIF PTZ. Добавьте оверлей-джойстик для плавного управления поворотом и наклоном, а также pinch-zoom для приближения. Сначала отправьте ONVIF GetServiceCapabilities, чтобы проверить возможности камеры, и аккуратно скройте элементы управления, если функция недоступна.

Push-уведомления по событиям

Обнаружено движение, человек попал в кадр, скачок звука или потеря сети — приложение должно уведомить пользователя за 2–3 секунды. В качестве транспорта подойдут Firebase Cloud Messaging (FCM) или Apple Push Notification service (APNs). Сделайте режим «не беспокоить» и фильтры по времени, чтобы пользователя не будили в 3 часа ночи из-за енота во дворе.

Безопасность и приватность, которые выдержат проверку в суде

Полицейские участки, больницы и организации по защите детей не купят приложение без этих функций. Экономия здесь приведёт к потере крупных корпоративных заказов, на которых держится бизнес.

Шифрование AES-256 в канале и в хранилище

Каждый видеопоток должен передаваться по TLS 1.3 (минимум). Записи следует хранить с шифрованием AES-256-GCM. Для TLS можно использовать BoringSSL или Conscrypt; для хранения ключей — библиотеку Android Security & Privacy. Не сохраняйте ключи в SharedPreferences и не встраивайте их в код. Используйте Android Keystore — на устройствах с аппаратным безопасным анклавом (например, Pixel или смартфоны серии Samsung Galaxy S) ключи будут находиться в защищённой зоне чипа.

Двухфакторная аутентификация и биометрический вход

Одного пароля недостаточно. Используйте TOTP (одноразовые пароли, привязанные ко времени) через приложения-аутентификаторы, а SMS — только как резервный вариант. Добавьте BiometricPrompt (для Android 9 и выше), чтобы пользователи могли входить по отпечатку пальца или лицу. Биометрические данные храните в зашифрованном виде в Android Keystore — ни в коем случае не отправляйте их на сервер.

Опциональное сквозное шифрование для чувствительных внедрений

Некоторые клиенты — федеральные ведомства, силовые структуры — потребуют, чтобы даже ваш бэкенд не мог расшифровать видео. Реализуйте опциональный режим, при котором приложение шифрует записи локально перед загрузкой, а ключи хранятся только на устройстве. Для обмена ключами подойдут libsodium или TweetNaCl; для peer-to-peer-воспроизведения — Curve25519 для клиент-клиентского шифрования.

Управление ключами и их ротация

Ключи нужно менять каждые 90 дней (или в соответствии с политикой организации). Используйте API ротации, которое защищает старые записи новыми ключами без перекодирования. Каждое событие ротации логируйте для аудиторского следа. При потере устройства клиент должен иметь возможность удалённо отозвать ключи шифрования.

ИИ-детекция движения и инференс на устройстве

Облачная детекция движения в институциональном сегменте не работает. Приложение должно запускать ML-модели прямо на телефоне. Это значит: модели легче, обработка кадра занимает 300–500 мс, а приватность остаётся в безопасности — кадры не уходят в облако.

TensorFlow Lite и LiteRT

Для большинства проектов используйте TensorFlow Lite (tflite) — он стабилен и работает быстро. Для новых проектов, которым нужна лучшая квантизация и динамическая подгрузка моделей, подойдёт LiteRT (рантайм следующего поколения от MediaPipe). Оба работают на ARM64 с ускорением на GPU Adreno (Qualcomm) и Mali (MediaTek). Квантуйте модели до int8 — это вдвое сокращает время инференса и экономит 3–4 МБ на каждой модели.

Детекция людей, машин и посылок

Для распознавания объектов используйте предобученную модель YOLO-NAS или EfficientDet — обе работают с tflite. Запускайте анализ не на каждом кадре, а через каждые 2–5 кадров — это экономит заряд батареи. Храните историю обнаружений за несколько кадров, чтобы отфильтровывать ложные срабатывания. Уведомляйте пользователя только в том случае, если один и тот же объект обнаружен три раза подряд. Такой подход снижает количество ложных тревог на 80%, не пропуская при этом реальные события.

Поиск аномалий поведения

Для комнат допросов и центров защиты детей важна детекция задержки на месте или резкого движения — она ценнее простого «обнаружен человек». Постройте простой конечный автомат событий: появился человек → стоит на месте → резко двинулся → тревога. Такой подход дешевле, чем использовать полноценную модель классификации поведения.

Варианты хранения и записи

Приложение должно поддерживать гибридное хранение: часть данных остаётся локально (быстро, без задержки), часть — в облаке (резервная копия, юридическая фиксация). Это не премиум-функция, а базовое требование для всех внедрений, выходящих за рамки одной квартиры.

Локальное хранение на устройстве

Используйте Android scoped storage (API 30+) и сохраняйте записи в getExternalFilesDir() или в своей папке внутри getExternalCacheDir(). Не используйте публичную папку DCIM — она больше не поддерживается. Сжимайте записи кодеком H.265, чтобы экономить место. Реализуйте кольцевой буфер: когда место заканчивается, самые старые сегменты автоматически удаляются.

Интеграция с облачным хранилищем

Поддержите AWS S3, Google Cloud Storage или Azure Blob Storage. Дайте клиентам возможность подключить собственное хранилище — это требование безопасности для федеральных внедрений. Загружайте записи непрерывно в фоне через WorkManager, а не через службу: на Android 12+ службы могут быть остановлены системой. При использовании лимитированного Wi-Fi приостанавливайте загрузку и возобновляйте её при переходе на безлимитное соединение. Для неудачных попыток загрузки реализуйте экспоненциальную задержку повторных попыток.

Политики хранения и автоматическое удаление

Дайте пользователю выбрать срок хранения для каждой камеры: 7, 30 или 90 дней, либо бессрочно. Чтобы соответствовать требованиям GDPR, настройте автоматическое удаление записей по истечении срока. Фиксируйте каждое удаление с указанием времени и причины: «истёк срок», «удалил пользователь» или «снята юридическая блокировка». Это обеспечит прозрачность и сохранит аудиторский след.

Запись по расписанию

Полицейские участки работают круглосуточно. Малый бизнес — только в рабочее время. Позвольте пользователю задать расписание в стиле cron: «писать с понедельника по пятницу с 9 до 18» или «писать только при обнаружении движения». Для запуска задач, которые должны выполняться даже после перезагрузки устройства, используйте WorkManager.

Удалённый доступ, который работает за NAT

Камера находится за домашним роутером или корпоративным файрволом. Пользователь — в другой сети. Приложению нужно подключиться к камере, не требуя от пользователя настройки проброса портов: 99% пользователей этого не сделают. Эти подходы позволяют решить задачу.

Peer-to-peer (P2P) с использованием реле STUN / TURN

STUN (Session Traversal Utilities for NAT) определяет публичный адрес камеры, а если прямое соединение не удаётся — трафик перенаправляется через TURN-сервер (платный, тарифицируется по объёму в гигабайтах). Эту логику реализуют библиотеки вроде pjsip или libnice. Так работают Wyze и Nest: подход срабатывает в 95% случаев и не требует централизованной серверной инфраструктуры.

RTSP поверх WebRTC через обратный прокси-шлюз

Некоторые корпоративные сети блокируют WebRTC, потому что он использует протокол UDP. Запустите лёгкий прокси-шлюз RTSP→HTTP в своём облаке. Камера передаёт поток RTSP на шлюз через исходящее соединение (его всегда пропустят), а приложение получает HLS LL с шлюза по HTTPS. Такой способ работает медленнее — задержка увеличивается на 1–2 секунды, — но надёжно функционирует в жёстко контролируемых сетях.

Запасной вариант с пробросом портов (опционально)

Для продвинутых пользователей, настроивших UPnP или проброс портов вручную, добавьте поле для указания эндпоинта вручную. Предупредите, что использование RTSP в открытом интернете без TLS — это серьёзная угроза безопасности; требуйте TLS 1.3 или отклоняйте подключение.

Интеграция со «умным домом» через Matter и Thread

Matter теперь стандартный протокол для новых устройств «умного дома». Приложение должно представлять камеры как Matter-эндпоинты и корректно работать с Google Home, Apple HomeKit и Amazon Alexa. Это уже не «хорошо бы», а обязательное требование.

Поддержка Matter-устройств

Реализуйте кластер Matter Camera (0x0110). Опубликуйте видеоэндпоинты по RTSP или HLS, двустороннее аудио (если камера его поддерживает) и атрибуты статуса: онлайн/офлайн, ночной режим, активность PIR-датчика. Используйте Matter SDK для Android из официального репозитория Google. Это займёт 3–4 недели — задача не сложная, но обязательна.

Mesh-сети Thread

Thread (IEEE 802.15.4) позволяет камерам в удалённых местах — например, в подвале, гараже или сарае — подключаться через сеть других устройств Thread без использования Wi-Fi. Приложение должно проверять, поддерживается ли Thread, и давать возможность подключить камеру через эту сеть, если она доступна. Пограничные роутеры Thread, такие как Google Nest Hub Max и Apple HomePod mini, объединяют сети Thread и Wi-Fi.

ONVIF Profile T для совместимости со стандартом

ONVIF Profile T — стандартизированная спецификация для IP-камер в «умном доме». Она описывает обнаружение камер, эндпоинты стриминга, управление PTZ и доставку событий. Реализуйте ONVIF GetServices, GetCapabilities и GetStreamUri. Это гарантирует, что ваше приложение будет работать с любой ONVIF-совместимой камерой, а не только с её подмножеством.

Интеграция с Google Home, Alexa и HomeKit

Для HomeKit подключайте камеры через HomeKit Accessory Protocol (HAP). Для Google Home и Alexa используйте их Smart Home API: Google Home Graph и Alexa Skill Kit. Эти интеграции позволяют пользователю сказать: «Окей, Google, покажи входную дверь» — и поток с камеры сразу появится на умной колонке. Звучит просто, но аккуратная реализация для каждой платформы занимает 6–8 недель.

Протоколы стриминга и реалистичные цели по задержке

Задержка — это не маркетинговый ход. Это жёсткое ограничение для интерактивности. Задержка в пять секунд делает двустороннюю аудиосвязь непригодной. Даже две секунды делают управление PTZ-камерой медленным и неудобным. Выбирайте протоколы, исходя из своего сценария.

Цифры в таблице рассчитаны для идеальных сетевых условий (RTT 20 мс). По сотовой сети добавьте 100–300 мс. WebRTC обеспечивает минимальную задержку, потому что работает поверх UDP — без задержек на повторную передачу, как в TCP. RTSP и HLS — в середине диапазона. MJPEG работает медленнее, но совместим с любым устройством, поддерживающим HTTP-клиент.

Выбор кодека важен. H.264 работает везде, но сильно нагружает процессор. H.265 экономит 30–40% трафика, но требует аппаратного декодирования (не все телефоны поддерживают — проверяйте через MediaCodecList.getCodecCapabilities()). VP8 и VP9 устарели — для новых проектов их лучше не использовать. AV1 — перспективный формат, но аппаратный декодер есть только у устройств 2023 года и новее.

Сравнение технологических стеков для IP-камер

Можно собрать кастомное Android-приложение для IP-камер, интегрироваться с OEM SDK (Hikvision, Dahua) или использовать готовую управляемую платформу. Вот как они сравниваются.

Итог. Если вы сами управляете дорожной картой и задержка имеет критическое значение — собирайте кастомное решение на базе RTSP и TensorFlow Lite. Если нужно работать с сотнями моделей камер от Hikvision, Dahua и Axis — используйте ONVIF Profile T и добавьте свою логику стриминга. Если есть бюджет и важно быстро выйти на рынок — выбирайте готовую платформу, например Agora IoT или AWS Kinesis, но будьте готовы к увеличению задержки и ограничению возможностей ИИ.

Модель затрат на три года

Цифры ниже рассчитаны на внедрение среднего масштаба: 50 камер, 5 000 часов записи в месяц, гибридное решение «облако + локально», выполнение ML-инференса на устройстве и двустороннюю аудиосвязь.

Ключевой вывод. Кастомная разработка требует больших первоначальных вложений, но оказывается выгоднее в долгосрочной перспективе, если вы масштабируетесь до 20 тыс. камер и более. Интеграция OEM SDK — это компромисс: быстрее вывод на рынок, умеренные затраты, но зависимость от одного поставщика. Управляемые платформы дешевле при количестве камер до 10 тыс., однако при росте расходы на оплату по потреблению быстро растут.

V.A.L. T.: профессиональное приложение для камер в комнатах допросов и полицейских участках

Ситуация. Некоммерческой организации понадобилось приложение для записи полицейских допросов, расследований в центрах защиты детей и медицинских консультаций. Требования: надёжная цепочка хранения доказательств (каждый кадр должен быть зафиксирован), двусторонняя аудиозапись с подавлением эха, соответствие стандартам PIPEDA и CCPA, а также возможность работы без интернета — в некоторых комнатах допросов нет Wi-Fi.

План на 16 недель. Недели 1–2: базовая архитектура стриминга на Android с приёмом RTSP и локальным кольцевым буфером. Недели 3–4: биометрическая двухфакторная аутентификация и ключи шифрования на уровне устройства (Android Keystore). Недели 5–7: реализация двустороннего аудио (WebRTC DataChannel для интеркома, кодек OPUS для сжатия). Недели 8–10: аудит логов цепочки хранения (хеши кадров, фиксация подтверждений загрузки). Недели 11–14: интеграция с AWS S3 для облачного резервного копирования с клиентским шифрованием. Недели 15–16: стресс-тест на 50+ устройствах, проверка соответствия HIPAA.

Результат. Сейчас приложение записывает более 500 допросов в месяц без единого случая подмены доказательств. Полицейские участки, использующие V. A. L. T., отмечают, что записи принимаются в суде — цепочка хранения остаётся надёжной. Облачный бэкап работает в фоне асинхронно: если во время допроса пропадает Wi-Fi, запись продолжается локально и автоматически синхронизируется, как только связь восстановится. Нужен аналог? Свяжитесь с нами по телефону или электронной почте.

Пять вопросов, чтобы выбрать подход

В1. Вы контролируете прошивку камеры или работаете с устройствами производителей (Hikvision, Dahua, Axis и т. п.)? Если контролируете — собирайте кастомный RTSP + TensorFlow Lite. Если нужна интеграция с вендорами — начните с ONVIF Profile T и собственного интерфейса, а SDK от производителей добавляйте по мере необходимости.

В2. Является ли задержка критичным фактором? Если двустороннее аудио или управление PTZ должны быть отзывчивыми (round-trip меньше секунды) — выбирайте WebRTC или кастомный RTSP. Если задержка в 3–5 секунд допустима — используйте HLS LL через управляемую платформу и сэкономите инженерные недели.

В3. Перейдёте ли вы за 10 тыс. камер на втором году? Если да — инвестируйте в кастомную разработку. Если нет — выбирайте управляемую платформу или OEM SDK. Точка безубыточности — около 10–15 тыс. камер; ниже этого порога управляемое решение выгоднее.

В4. Обязаны ли вы соответствовать HIPAA, CCPA, PIPEDA или EU AI Act? Если да — сквозное шифрование и клиентские ключи становятся обязательными. Это добавляет 4–6 недель к срокам реализации любого стека. Если нет — достаточно стандартного серверного шифрования AES-256.

В5. Есть ли у вас собственные Android-инженеры с опытом видеостриминга, ML-инференса или WebRTC? Если нет — нанимайте или сотрудничайте со специалистами. Это не вопрос «догнать конкурентов по функциям», а вопрос скрытой сложности. Большинство приложений для IP-камер падают не из-за функций, а из-за тонких багов в управлении буфером, расходе батареи или fallback-сценариях P2P-соединений.

Пять ошибок, которые мы видим в проектах IP-камер

1. Недооценка задержки. Разработчики считают, что «RTSP — это быстро», и выпускают приложение с задержкой в пять секунд в сотовой сети. Пользователи это не любят. Берите за основу 2–3 секунды — всё, что быстрее, уже успех. Тестируйте на реальных 4G LTE и 5G, а не на Wi-Fi.

2. Игнорирование энергопотребления. Приложение, которое работает 24/7, может разрядить Pixel 6 за 12 часов, если не группировать фоновые задачи. Используйте WorkManager с экспоненциальной задержкой, а не foreground-сервисы. Профилируйте расход батареи в Android Studio Profiler как можно раньше и регулярно.

3. Вера в то, что ONVIF / RTSP стандартизированы. Каждый производитель камер по-своему понимает ONVIF. Hikvision в RTSP-аутентификации требует MD5(password), а Dahua — MD5(username + ':' + realm + ':' + password). Тестируйте минимум на пяти разных брендах. На особенности от вендоров закладывайте 2–3 недели.

4. Отношение к P2P как к опции. Если приложение полагается на облачный сервер для передачи каждого кадра, оно не будет работать в офлайне или в сетях с высокой задержкой. Заложите P2P и резервный канал с самого начала. Используйте STUN / TURN и проверяйте альтернативные пути.

5. Забыть протестировать на Android 12+. Scoped storage, новые разрешения камеры и ограничения на фоновую активность сломали множество приложений в 2021 году. С самого начала настраивайте сборку под Android 15, тестируйте на 13–14 как на дополнительных платформах. Не полагайтесь на то, что «раз работает на моём Pixel — значит, работает везде».

KPI, которые стоит отслеживать после запуска

KPI качества. Средняя задержка «стекло-экран» — меньше 2 с (RTSP) или меньше 500 мс (WebRTC). Доля повторных буферизаций — менее 0,5% (одна на 200 минут просмотра). Краш-рейт — менее 0,1% (отслеживайте через Firebase Crashlytics). Успешное подключение к потоку с первой попытки — более 95%, после повторной попытки — более 99%.

Бизнес-метрики. Стоимость камеры в месяц (хранилище + приём потока + CDN). Фактическая глубина хранения по сравнению с целевой. Время доступности двустороннего аудио — выше 99,5%. Средняя длительность сессии (чем больше — тем лучше: признак того, что пользователи доверяют приложению). Отток среди пользователей платных тарифов.

KPI надёжности. Среднее время обнаружения офлайн-камеры — менее 30 секунд. Среднее время восстановления после сбоя сети — менее 5 минут. Доля ложных отказов аутентификации — менее 0,01% (ложные блокировки пользователей). Доля успешной облачной синхронизации — более 99% (вся записанная картинка в итоге доезжает до бэкенда).

Когда не стоит разрабатывать своё Android-приложение для IP-камер

Иногда правильный ответ — купить готовое. Откажитесь от кастомной разработки, если:

• Вы работаете с одним OEM-партнёром и хотите быстро выйти на рынок. Используйте его SDK. Будете привязаны к вендору, но запуститесь за 6–10 недель вместо 16–20.
• У вас меньше 100 камер и задержка не критична. Используйте AWS Kinesis, Agora IoT или аналоги. Общая стоимость владения будет на 40–50% ниже, чем при самостоятельной разработке.
• У команды нет опыта в видеостриминге. Привлекайте подрядчиков или используйте управляемую платформу. Продакшен-решение для IP-камер требует глубокого понимания RTSP, WebRTC, анализа битстрима H.264 и фоновой обработки на Android. Это не задача для новичков.
• Нужно соответствие в строго регулируемой сфере — например, здравоохранении или госсекторе — и вы хотите, чтобы ответственность легла на кого-то другого. Выберите SaaS-провайдера с сертификатами SOC 2 / HIPAA / FedRAMP. Дороговато, но риски перенимает на себя он.
• Задержки до 5 секунд — это нормально, и вы готовы платить только за то, что используете. Управляемые платформы заметно подросли в качестве. У Agora IoT и AWS Kinesis сейчас разумные цены для небольших парков (до 100 камер).

FAQ

Что почитать дальше

Готовы построить Android-приложение для IP-камер, которое реально выйдет в продакшен

Рынок Android-приложений для IP-камер в 2026 году — это уже не просто трансляция видео. Здесь важны ИИ на устройстве, интеграция со «умным домом» и соответствие требованиям, которое пройдёт проверку в суде. Приложение потеряет клиентов, если не будет поддерживать хотя бы одно из ключевых решений: двустороннюю аудиосвязь, обработку данных с помощью машинного обучения на самом устройстве, протокол Matter, шифрование AES-256 или ведение логов для аудита.

Если вы контролируете дорожную карту и можете выделить 12–20 недель — правильный выбор: кастомный RTSP + TensorFlow Lite. Если нужно интегрироваться с сотнями производителей камер — используйте ONVIF Profile T и создайте собственный интерфейс. Если запуск требуется за 6 недель — принимайте компромиссы и выбирайте готовую управляемую платформу. Главное — чётко понимать, какие компромиссы важны для ваших клиентов: задержка, конкретная функция или соответствие требованиям — и строить решение под эти ограничения, а не под вымышленный «идеальный» набор возможностей.