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

Зачем Фора Софт написала этот плейбук по Android и IP-камерам

Фора Софт выпускает программное обеспечение для видео и систем наблюдения уже более 20 лет. Наша платформа видеонаблюдения V.A.L.T. работает в полицейских участках, залах суда и медицинских клиниках: до 9 синхронизированных HD-потоков на экран, полный PTZ и двусторонний звук — и каждое такое внедрение начиналось с одного и того же вопроса: как получить чистое видео с IP-камеры в мобильном приложении и при этом не убить ни задержку, ни безопасность.

Этот гид — тот же плейбук, который мы передаём техническим руководителям до подписания договора на работу с Android и IP-камерами. Здесь — выбор протокола, выбор библиотек, тонкости ONVIF, ловушки кодеков и пункты соответствия требованиям, которые почти всегда упускают на этапе оценки. Всё проверено на реальных клиентских проектах, а не списано с README на GitHub.

Если вы продакт-менеджер, который оценивает Android-вьюер, CTO, который проводит аудит существующего приложения, или ведущий инженер, которому нужно второе мнение, — материал для вас. Более широкую картину того, как мы строим, мы публикуем регулярно: про разработку VMS на заказ, про архитектуру AI-видеонаблюдения и про кейс перестройки платформы более чем на 1 млн строк кода на 40% быстрее с инженерией на агентах.

Решение за 60 секунд

Если вам нужно в 2026 году выпустить Android-приложение, которое смотрит, записывает и управляет IP-камерой, стек по умолчанию такой: ExoPlayer (Media3 1.9.2) с модулем-источником RTSP для работы в одной локальной сети, libwebrtc для удалённого доступа и go2rtc или MediaMTX в роли моста. ONVIF используйте только для обнаружения и PTZ, никогда как транспорт для стриминга. К LL-HLS стоит обращаться лишь тогда, когда нужно поддерживать старые устройства или слабые сети.

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

Что изменилось для Android-приложений с IP-камерами в 2025–2026

1. Media3 пришёл на смену ExoPlayer. Media3 1.9.2 от Google теперь — поддерживаемый дом для RTSP, HLS, DASH и SmoothStreaming. Из коробки он работает с H.264 + AAC и, при тонкой настройке буферов, выдаёт задержку RTSP 1–2 с без самописного кода.

2. Правила для foreground service ужесточились. В Android 14 появились обязательные объявления foregroundServiceType; Android 15 жёстко их проверяет. Сервисы, играющие видео в фоне, должны объявлять mediaPlayback, иначе билд завернёт Play Store.

3. Мосты RTSP → WebRTC выросли. go2rtc и MediaMTX оба работают на Raspberry Pi, держат десятки потоков и выдают WebRTC с задержкой меньше 500 мс. Два года назад под это требовался кластер Kurento.

4. CCPA 2026 вступил в силу 1 января. Оценки приватных рисков и аудиты кибербезопасности теперь обязательны для бизнеса выше пороговых значений; приложения, близкие к видеонаблюдению, почти всегда эти пороги переходят.

5. AV1 на мобильных устройствах пока сырой. Облачные кодировщики вроде AWS Elemental MediaConvert получили поддержку AV1, но декодирование AV1 на стороне Android-устройств неравномерное. H.264 по-прежнему остаётся выбором, который «везде поедет»; H.265/HEVC всё так же ломается примерно на трети установленной базы.

Сравнение протоколов: RTSP, ONVIF, WebRTC, HLS, LL-HLS

Выбирайте протокол под ваш бюджет задержки, профиль сети и набор устройств — а не тот, на котором случайно крутится демо от вендора камер.

RTSP-библиотеки для Android: Media3, LibVLC, IJKPlayer, GStreamer

Если вы остановились на RTSP, следующая развилка — выбор библиотеки. Так мы ранжируем варианты в 2026 году.

В 80% Android-проектов с IP-камерами, которые мы выпускаем, ответ — Media3. Он бесплатный, официальный, хорошо обкатан на свежих версиях Android и позволяет агрессивно настраивать буферы. Ниже — минимальный сниппет на Kotlin, который опускает задержку RTSP примерно до 1 с на современном устройстве.

val loadControl = DefaultLoadControl.Builder()
    .setBufferDurationsMs(
        /* min = */ 100,
        /* max = */ 500,
        /* playbackBufferMs = */ 100,
        /* playbackAfterRebufferMs = */ 200
    )
    .build()

val mediaSource = RtspMediaSource.Factory()
    .setForceUseRtpTcp(true)                // firewall-friendly
    .setDebugLoggingEnabled(BuildConfig.DEBUG)
    .createMediaSource(MediaItem.fromUri(rtspUrl))

val player = ExoPlayer.Builder(context)
    .setLoadControl(loadControl)
    .build()

player.setMediaSource(mediaSource)
player.prepare()
player.playWhenReady = true

ONVIF на Android: обнаружение, PTZ и ловушка WifiManager

ONVIF — это открытый стандарт, который даёт единый способ обнаруживать камеры, получать их RTSP URI, управлять PTZ и событиями. На практике важны четыре профиля: S — для массового видеонаблюдения, T — для тепловизионных камер, G — для премиальных PTZ (вроде купольных скоростных) и M — для метаданных и аналитики. Большинство потребительских и SMB-камер соответствуют Profile S.

Главная Android-специфичная ловушка ONVIF. WS-Discovery использует multicast UDP на порту 3702. На Android вы обязаны держать WifiManager.MulticastLock на время обнаружения, иначе ОС молча выкидывает multicast-пакеты. Симптом: на ноутбуке обнаружение работает, на телефоне возвращает ноль камер. Каждый раз.

val wifi = getSystemService(Context.WIFI_SERVICE) as WifiManager
val multicastLock = wifi.createMulticastLock("onvif-discovery").apply {
    setReferenceCounted(true)
    acquire()
}
try {
    val devices = OnvifManager().discoverAsync(timeoutMs = 4000)
    // map devices -> GetStreamUri -> Media3 RtspMediaSource
} finally {
    multicastLock.release()
}

Для реальной SOAP-обвязки RootSoft/ONVIF-Java — зрелый и Android-дружелюбный вариант. Если вам нужен PTZ сложнее базового pan/tilt, проверяйте его на конкретной модели камеры — соответствие вендоров ONVIF неравномерное, особенно за пределами Profile S.

WebRTC: путь к задержке менее 500 мс через go2rtc или MediaMTX

RTSP в принципе не способен надёжно выдавать задержку ниже 1 с по шумному потребительскому интернету. Когда оператору безопасности нужно крутить камеру через PTZ, поймать быстрое событие или начать двусторонний звуковой диалог — вам нужен WebRTC.

Современный ответ — не пишите свой SFU. Запустите go2rtc или MediaMTX на небольшой виртуалке (для десятков камер хватит сервера уровня Hetzner AX или дроплета DigitalOcean), направьте их на ваши RTSP-источники и отдавайте WebRTC. Оба проекта — открытый код, активно поддерживаются и стабильно укладываются в задержку менее 500 мс на потребительских сетях.

go2rtc — лёгкий вариант. Один бинарник, YAML-конфиг, встроенный веб-интерфейс для быстрой проверки, спокойно живёт на Raspberry Pi 4. MediaMTX (бывший rtsp-simple-server) чуть тяжелее и помимо WebRTC поддерживает SRT, RTMP, HLS и LL-HLS — берите его, если нужен мультипротокольный выход.

На Android потребляйте WebRTC через стандартный libwebrtc Android SDK. Если хотите глубже разобрать компромиссы между собственным WebRTC и готовыми SDK, посмотрите наш разбор архитектуры WebRTC и стоимости.

Реальность кодеков: H.264 везде, H.265 с оговорками, AV1 ещё нет

Камеры по умолчанию идут в H.265 ради экономии полосы; у Android-устройств установленной базы по-прежнему длинный хвост без аппаратного декодирования HEVC. Когда примерно треть ваших пользователей сваливается на программный декодинг, вы видите всплески CPU, разряд батареи и тепловой троттлинг уже на десятой минуте.

Наше правило: предпочитайте подпоток H.264 на камере (большинство Hikvision/Dahua/Axis такой отдают), проверяйте MediaCodecList перед выбором потока и откатывайтесь на LL-HLS с транскодом на мосту, если у устройства нет HEVC, а камера отдаёт только H.265. AV1 пока не безопасный основной кодек на Android под задачи IP-камер — оставьте его в списке «посмотрим в 2027 году».

fun supportsHardwareHevc(): Boolean {
    val list = MediaCodecList(MediaCodecList.REGULAR_CODECS)
    return list.codecInfos.any { info ->
        !info.isEncoder && info.isHardwareAccelerated &&
        info.supportedTypes.any { it.equals("video/hevc", ignoreCase = true) }
    }
}

Бюджеты по полосе пропускания и питанию для разных разрешений

Конкретные числа, по которым стоит планировать — каждый тикет в духе «почему так лагает», который мы разбирали, упирался в одну из этих строк.

На устройстве рассчитывайте, что воспроизведение 1080p H.264 сжигает 4–6% батареи в час на среднем Android-смартфоне с включённым экраном. Долгий просмотр в реальном времени требует foreground service, политики wakelock и UI, который приглушает или снижает разрешение, когда пользователь сворачивает приложение.

Фоновый стриминг: правила foreground service на Android 14 / 15 / 16

Начиная с Android 14 любой сервис, который держит поток с камеры живым в фоне, обязан объявить foregroundServiceType. Android 15 и 16 проверяют это жёстко; ревью Play Store отклоняет несоответствующие билды.

Для видеовьюера правильный тип — mediaPlayback. Объявите его в манифесте, свяжите с MediaSessionService и показывайте постоянное уведомление во время стриминга. Если приложение пишет видео, на Android 14+ также могут понадобиться camera и runtime-разрешения.

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />

<service
    android:name=".stream.CameraPlaybackService"
    android:foregroundServiceType="mediaPlayback"
    android:exported="false" />

Безопасность: аутентификация, TLS и ловушка незашифрованного RTSP

Digest-аутентификация RTSP не шифрует полезную нагрузку. Простые URL rtsp:// — ровно те, которые раздают админки большинства NVR — отправляют учётные данные и видео открытым текстом. В любой сети, которая вам не принадлежит, это смертельный паттерн.

1. Заворачивайте RTSP в TLS или VPN. Используйте rtsps://, если камера это поддерживает; иначе поднимайте туннель WireGuard или Tailscale до моста и пускайте RTSP внутри него.

2. Храните учётные данные правильно. Android Keystore для API-ключей и паролей от камер. Никогда не пакуйте их в ресурсы APK; никогда не логируйте; ротируйте при выходе пользователя из системы.

3. Network Security Configuration. Ставьте по умолчанию cleartextTrafficPermitted="false", а затем точечно открывайте конкретный хост LAN для on-prem RTSP, если без этого никак.

4. Pinning сертификатов — аккуратно. Прибивайте сертификат моста, если инфраструктура ваша. Не прибивайте сертификаты потребительских камер — обновления прошивки ротируют их самоподписные сертификаты, и устройство превратится в кирпич.

5. Аудит-логи. GDPR и CCPA оба требуют знать, кто смотрел что и когда. Логируйте события открытия / закрытия / скачивания потока на сервер, не только на устройстве.

Соответствие требованиям: GDPR, CCPA 2026 и BIPA для распознавания лиц

GDPR. Считайте записанное видео персональными данными. Включайте автоудаление после 30–90 дней, если у вас нет задокументированного законного основания хранить дольше. Размещайте таблички там, где камеры смотрят на публичные или полупубличные пространства; поддерживайте соглашения о обработке данных с каждым третьим лицом (облачное хранение, аналитика), который касается видеоматериала.

CCPA (с 1 января 2026 года). Калифорния теперь требует оценки приватных рисков и аудиты кибербезопасности для бизнеса выше порогов по выручке / объёму данных. Приложения для видеонаблюдения и аналитики регулярно эти пороги переходят. Заложите инженерное время на оба процесса.

BIPA (Иллинойс) и аналоги. Если приложение делает любое распознавание лиц или биометрическую кластеризацию, BIPA Иллинойса выставляет вам штраф 75 тыс. ₽ за неумышленное и 375 тыс. ₽ за умышленное нарушение. Явное opt-in согласие и аудируемые сценарии удаления не опциональны. У Техаса и Вашингтона есть смежные статуты.

HIPAA и HITECH. Если в приложении хоть когда-нибудь камера показывает пациента, обращайтесь с этим как с PHI на всём пути. Шифрование при передаче, шифрование при хранении, журналы доступа, соглашения с бизнес-партнёрами. Наше внедрение V.A.L.T. в медицинских клиниках построено ровно по этому шаблону.

Эталонная архитектура Android-приложения для IP-камер

Ниже — стек, который мы рекомендуем как умолчание в 2026 году. Каждый слой — либо лидер рынка, либо хорошо поддерживаемая альтернатива с открытым кодом, и каждая стрелка отработана в проде на одном из проектов Фора Софт.

Что касается слоя AI, у нас есть отдельные материалы по автоматическому обнаружению аномалий для камер безопасности и разбор компромиссов edge vs. cloud — где должен жить инференс.

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

1. Мультикамерная сетка с адаптивным качеством. Стены 4×1, 3×3 и 4×4 на низкоразрешённых подпотоках; полное разрешение по тапу. Ровно так V.A.L.T. вытягивает 9 HD-потоков на экран, не расплавляя устройство.

2. Управление PTZ — жесты и кнопки на равных. Drag-to-pan, pinch-to-zoom и экранные кнопки для пользователей в перчатках. Шлите команды PTZ через ONVIF; делайте debounce — дешёвые камеры падают под быстрым вводом.

3. Двусторонний звук там, где камера это умеет. Камеры ONVIF Profile T его отдают; на клиенте сочетайте с аудио по WebRTC.

4. Лента событий с движением и AI-детектами. Прокручиваемый таймлайн с цветовой кодировкой событий; тап перематывает к клипу. Это нужно и судебным экспертам, и операционным командам.

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

6. UI, устойчивый к офлайну. Кэшируйте превью и метаданные; делайте переподключение прозрачным; показывайте таймстампы «последний раз видели», когда камера отваливается.

Мини-кейс: V.A.L.T. на Android для залов суда и клиник

V.A.L.T. — платформа видеонаблюдения Фора Софт, развёрнутая в комнатах допросов, залах суда и медицинских консультационных кабинетах. Android-клиент делает ровно то, что описано в этой статье: находит IP-камеры на объекте через ONVIF, забирает их RTSP-потоки, показывает HD-сетку 3×3, даёт полный PTZ и двусторонний звук для удалённых операторов.

Техническая форма: Media3 RTSP для просмотра в локальной сети, libwebrtc через мост MediaMTX для удалённого, ONVIF для обнаружения и PTZ, HIPAA-совместимое хранилище для клинических площадок, аудит-логи на каждой границе. Типичная сессия: оператор одновременно смотрит три комнаты, поворачивает одну через PTZ, ставит закладку и экспортирует подписанный клип — всё меньше чем за 60 секунд, с задержкой PTZ-петли меньше секунды.

Модель стоимости: MVP Android-приложения для IP-камер в 2026

Реалистичный MVP Android-приложения для IP-камер — вьюер, обнаружение через ONVIF, воспроизведение по RTSP и WebRTC, PTZ, лента событий, экспорт клипов и базовое облачное хранилище — укладывается в диапазон 2,2–5,2 млн ₽, когда мы поставляем его через свой процесс инженерии с агентами. Сроки обычно 8–12 недель на MVP и ещё около 8 недель на аналитику и шлифовку.

Инфраструктура в рантайме. Мост: сервер класса Hetzner AX-32 примерно за 4 500 ₽ в месяц держит 30–50 одновременных потоков 1080p. Облачное хранилище: Wasabi с совместимостью S3 — около 450 ₽ за ТБ в месяц без платы за исходящий трафик. TURN: Coturn на том же сервере или управляемый сервис примерно за 30 ₽ за ГБ ретранслированного трафика.

Следите за скрытыми издержками. Циклы ревью в магазинах приложений, декларации приватности Google Play, QA по конкретным странам и вендорам ONVIF и те самые 2–4 недели на буфер и тюнинг кодеков, которые всегда всплывают за неделю до запуска. Закладывайте, не выкидывайте.

Фреймворк решения: выбираем стек за пять вопросов

В1. Какой бюджет задержки действительно нужен продукту? Меньше 500 мс (допросы, живой PTZ через WAN): WebRTC через go2rtc или MediaMTX. 1–2 с (стандартный просмотр в локальной сети): Media3 RTSP. 2–6 с устраивают: LL-HLS.

В2. Клиенты в одной сети с камерой? Да: вероятно, хватит RTSP, без моста. Нет (удалённые, много площадок): нужен мост, скорее всего WebRTC. Не пытайтесь выставить RTSP в публичный интернет.

В3. Какие камеры принесут пользователи? Hikvision / Dahua / Axis / Amcrest: Profile S закроет потребность. Reolink и потребительские бренды: ONVIF неровный — закладывайте откат на вендорские SDK для двух самых популярных у ваших клиентов моделей.

В4. Есть ли биометрия или распознавание лиц? Да: согласия класса BIPA, opt-in-сценарии и аудируемое удаление — это объём работ первого уровня, а не догонять потом. Нет: CCPA и GDPR с хранением всё равно действуют, но рисковая оболочка меньше.

В5. Нужен ли PTZ с задержкой меньше секунды в первом году? Да: закладывайте WebRTC + libwebrtc, мост и TURN в бюджет. Нет: запускайте сначала на RTSP, добавляйте WebRTC во второй фазе, когда подтвердите product-market fit.

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

1. Считать, что RTSP вытащит задержку меньше секунды. На потребительском интернете надёжно — не вытащит. Если продукту нужен порог меньше 1 с, закладывайте WebRTC с первого дня. Прикручивать мост после подписания договора — самая дорогая ошибка, которую мы видим.

2. Забывать про multicast-блокировку WifiManager в ONVIF. Обнаружение работает на ноутбуке, тихо отказывает на телефоне. Бывает в каждом аудируемом нами Android-проекте с ONVIF.

3. Выпускать только H.265-потоки. Около 35% Android-устройств всё ещё не умеют декодировать HEVC аппаратно. Договаривайтесь с камерой о подпотоке H.264 или закладывайте транскод на мосту.

4. Сливать учётные данные через незашифрованный RTSP. Digest auth — это не шифрование. Заворачивайте соединение в TLS или туннелируйте через WireGuard; никогда не пускайте сырой rtsp://user:pass@host по недоверенной сети.

5. Игнорировать типы foreground service на Android 14+. В эмуляторе поток работает, Play Store билд отклоняет. Объявите mediaPlayback и парное разрешение с первого дня.

KPI, которые подтверждают, что интеграция здорова

KPI качества. Задержка glass-to-glass p95 (<2 с для RTSP, <500 мс для WebRTC), частота замёрзшего кадра за 10-минутную сессию (цель <1%), частота отката кодека (доля сессий, ушедших с H.265 на H.264/LL-HLS; цель <10%).

Бизнес-KPI. Ежедневные активные сессии камер, средние минуты стриминга на пользователя, доля сессий без сбоев (целевое 99,5%+), частота тикетов поддержки на 1 000 минут стриминга.

KPI надёжности. Успешность переподключения после обрыва сети (>95%), успешность ONVIF-обнаружения на объекте (>90% для поддерживаемого списка вендоров), расход батареи в час живого просмотра (<7% на эталонном устройстве).

Когда НЕ нужно делать своё Android-приложение для IP-камер

У вас меньше трёх отличий продукта от конкурентов. Если в списке желаний «смотреть камеры, записывать, уведомлять» — и больше ничего, white-label поверх tinyCam Pro или IP Cam Viewer уедет быстрее и обойдётся дешевле на годы вперёд. Своя разработка оправданна, когда нужны встроенный AI, мультиарендность, уникальный UX под вертикаль или сценарии цепочки хранения.

Вы не проверили регуляторный путь. HIPAA, BIPA, CJIS и часть правил публичного сектора ЕС превращают «MVP за 10 недель» в 9-месячное болото сертификации. Проверьте комплаенс до старта разработки.

Парк камер узкий и вендорский. Если вы общаетесь только с камерами одного вендора и он даёт white-label SDK — пользуйтесь им. Своя работа окупается, когда нужно охватить пять и более вендоров или когда SDK вендора не умеет WebRTC.

О чём спросить партнёра по разработке до подписания договора

Покажите одно реальное измерение задержки RTSP на устройстве. Glass-to-glass: камерой телефона на миллисекундный таймер на экране ноутбука. Цифры задержки в питче нарисует кто угодно; видео-доказательство — почти никто.

Покажите матрицу покрытия ONVIF. Какие вендоры, какие версии прошивок, какие особенности. Это племенное знание — у честного партнёра будет таблица с пометками «работает / не работает / странно».

Покажите свой workflow инженерии с агентами. Выпустить видеоплатформу более чем на 1 млн строк за квартал — это не подвиг одиночки, это процесс. Спросите партнёра, как его процесс устроен.

FAQ

Действительно ли Media3 ExoPlayer воспроизводит RTSP с любой IP-камеры?

Да, для потоков H.264 + AAC — а это большинство камер. Из коробки Media3 не везде проигрывает H.265 по RTSP, и часть вендоров присылает нестандартные расширения SDP, которые модуль игнорирует. Под крайние случаи планируйте транскод на мосту go2rtc или MediaMTX в дружественный Media3 профиль.

WebRTC всегда лучше RTSP для IP-камер?

Только когда вам действительно нужна задержка меньше 1 с — комнаты допросов, живой PTZ через интернет, двусторонний звук. Для просмотра в одной локальной сети с задержкой 1–2 с RTSP через Media3 дешевле в эксплуатации (нет моста, нет TURN) и быстрее в разработке. Выбирайте протокол под требование к задержке, а не под демо.

Как автоматически находить IP-камеры в локальной сети?

Используйте WS-Discovery из ONVIF: multicast SOAP поверх UDP на 239.255.255.250:3702. На Android сначала возьмите WifiManager.MulticastLock — без него ОС выкидывает multicast-пакеты и обнаружение возвращает пустоту. Библиотеки вроде RootSoft/ONVIF-Java берут на себя SOAP-конверт и разбор ответов.

Как управлять PTZ из Android-приложения?

Шлите ONVIF PTZ SOAP-команды (ContinuousMove, RelativeMove, AbsoluteMove) на URL PTZ-сервиса камеры с Android-клиента. Делайте debounce агрессивного пользовательского ввода — потребительские камеры не тянут жестовые потоки на 60 Гц, и перегрузка ONVIF-эндпоинта приводит к потерянным командам и «залипшим» поворотам.

Безопасно ли пускать RTSP в публичный интернет?

Нет. Простая RTSP digest-аутентификация передаёт учётные данные и видео так, что в проводе это тривиально наблюдается. Заворачивайте в RTSPS/TLS, если камера это поддерживает, туннелируйте через VPN вроде WireGuard или Tailscale или мостите в WebRTC с DTLS/SRTP. Никогда не публикуйте открытый URL rtsp://user:pass@host.

Сколько времени занимает разработка Android-приложения для IP-камер?

Хорошо проработанный MVP (мультикамерный просмотр, PTZ, лента событий, экспорт клипов, облачная запись) укладывается в 8–12 недель для команды из двух инженеров на нашем workflow инженерии с агентами. Добавьте 4–8 недель на AI-аналитику, шлифовку под HIPAA/BIPA и QA по нескольким вендорам ONVIF. Типичная итоговая стоимость: 2,2–5,2 млн ₽ за MVP.

Сколько камер реально можно показать одновременно на телефоне?

С подпотоками низкого разрешения и аппаратным декодированием H.264 — комфортно от 9 до 16 плиток на современном среднем устройстве. Полное HD на десятке потоков быстро уведёт устройство в тепловой троттлинг. V.A.L.T. ограничивает 9 одновременными HD-потоками на экран — это sweet spot, который мы видим в клинических и судебных развёртываниях.

Может ли AI-детектирование движения работать прямо на телефоне?

Для одного потока — да. TensorFlow Lite и ML Kit крутят детекторы класса YOLO-Nano на 5–10 fps на свежих чипсетах. Для флота камер запускайте инференс на мосту или в облаке.

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

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

Короткая версия: берите Media3 RTSP для работы в локальной сети, libwebrtc с мостом go2rtc или MediaMTX — для удалённого, ONVIF — только для обнаружения и PTZ, H.264 — как безопасную базовую линию по кодекам, и объявите тип foreground service на Android 14+. Закладывайте комплаенс с первого дня — хранение по GDPR, аудиты CCPA 2026, BIPA под любую биометрию — потому что прикрутить это потом стоит масштабов возврата средств.

Фора Софт выпускает ровно такой стек уже два десятилетия — через V.A.L.T. в залах суда и клиниках, через пересборку видеоплатформы более чем на 1 млн строк и десятки кастомных интеграций для регулируемых отраслей. Если вы оцениваете, аудируете или спасаете Android-проект с IP-камерами, мы сэкономим вам квартал боли и квартал runway.

Следующий шаг занимает 30 минут. Принесите список камер, цель по задержке, ограничения по комплаенсу — уйдёте с конкретным выбором протокола, планом по команде и честным графиком.