Ветклиника: камеры в стационаре для владельцев — трафик, хранение и цена вопроса

MAATRIX

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

Зачем это клинике, а не только владельцам

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

Во-первых, это снижает количество звонков на ресепшн «а как он там» — администратор просто присылает ссылку вместо разговора с пятью встревоженными владельцами подряд.

Во-вторых, запись — это страховка клиники в спорных ситуациях. Если владелец предъявляет претензию по уходу («животное было без воды», «никто не подходил три часа»), архив с меткой времени закрывает вопрос за минуту вместо разбирательства на репутацию.

В-третьих, это конкурентное отличие: пока одни клиники ограничиваются графиком посещений раз в день, другие дают доступ 24/7, и отзывы «мы видели, что за питомцем правда следят» продают лучше описания услуг на сайте.

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

Из чего на самом деле складывается нагрузка

Здесь часто путают две разные вещи, и путаница дорого стоит при выборе тарифа.

Запись на архив — это то, что камера постоянно пишет на диск, независимо от того, смотрит её кто-то в этот момент или нет. Нагрузка тут — это объём хранилища и, если камера пишет не локально, а на сервер, — постоянный исходящий поток от камеры к серверу.

Раздача владельцам — это когда кто-то открывает ссылку и смотрит трансляцию или архивный ролик. Нагрузка тут — исходящий трафик с сервера к зрителю, и она умножается на число одновременных зрителей.

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

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

Трафик передачи видео владельцам: как считать, а не гадать

Точную цифру в рублях или гигабайтах в месяц вам никто честно не назовёт заранее — она зависит от того, сколько животных в стационаре одновременно, сколько владельцев реально открывают ссылку и как долго смотрят. Но метод расчёта прозрачный, и его стоит проделать самим, прежде чем выбирать тариф.

Формула на одного зрителя:

Трафик на зрителя = битрейт потока × время просмотра

Например, поток с битрейтом 1,5 Мбит/с (ближе к 720p с разумным сжатием для статичной сцены бокса — картинка почти не двигается, кодек сжимает такие сцены сильно) за 10 минут просмотра — это примерно 110 МБ. Число условное: у вас будет свой битрейт из-за настроек камеры, разрешения или ИК-подсветки ночью (шум на видео при слабом свете повышает битрейт даже на статичной картинке) — это иллюстрация метода, а не гарантированная цифра.

Дальше — умножение на количество зрителей и на дни:

Трафик в месяц ≈ битрейт × среднее время просмотра на владельца
                × среднее число одновременных пациентов в стационаре
                × дни месяца

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

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

Хранение архива: сколько места съедает стационар

Здесь тоже работает арифметика, а не магия. Объём на один час записи с одной камеры:

Объём в час ≈ битрейт (Мбит/с) × 3600 / 8 (перевод бит в байты)

При условном битрейте 2 Мбит/с (H.264, статичная сцена бокса, дневной свет) это около 900 МБ в час, то есть порядка 21 ГБ в сутки на одну камеру. Ночью с ИК-подсветкой битрейт обычно выше из-за шума картинки, так что закладывайте с запасом, а не по нижней границе. Это опять иллюстрация метода на условных цифрах — у вашей камеры и настроек сжатия будет своё значение, проверяйте по факту первую неделю записи через du -sh.

Дальше — умножение на число камер и на срок хранения:

Общий объём ≈ объём в сутки на камеру × число камер × дни хранения

Тут встаёт вопрос: сколько дней реально хранить? Прямого требования закона хранить видео из ветеринарного стационара определённый срок нет — срок хранения клиника определяет сама, из практических соображений:

• Для владельцев — обычно нет смысла держать архив дольше, чем длится госпитализация плюс несколько дней: после выписки почти никто не пересматривает старые записи.
• Для споров и претензий — разумно держать 2-4 недели даже после выписки, чтобы закрыть возможную претензию с фактами на руках.
• Для внутреннего контроля качества — некоторые клиники держат дольше как материал для разбора работы персонала, но это уже решение главврача, а не техническое.

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

Не путайте хранение архива с раздачей владельцам по нагрузке на диск. Архив — это последовательная запись, диску это даётся легко даже на HDD. А одновременное чтение архивных роликов несколькими владельцами вперемешку с записью новых — уже случайный доступ, и здесь SSD под кэш и индексы выигрывает у голого HDD заметно.

Архитектура: одна точка приёма, много точек раздачи

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

Для этого подходит связка вроде MediaMTX (бывший rtsp-simple-server) — лёгкий медиасервер, который принимает RTSP-поток от IP-камеры и раздаёт его дальше по RTSP, HLS или WebRTC без перекодирования, если браузеру подходит исходный кодек. Пример конфига для одной камеры:

paths:
  box-12:
    source: rtsp://admin:pass@192.168.1.45:554/stream1
    sourceOnDemand: no

Дальше владелец получает ссылку на HLS-плейлист вида https://vet.example.com/box-12/index.m3u8, которая открывается прямо в браузере телефона без установки приложения — заставлять встревоженного владельца ставить незнакомое приложение вечером в 9 вечера плохо для опыта.

Нюанс с кодеками: современные камеры часто пишут в H.265 — он даёт заметно меньший битрейт при том же качестве, что хорошо для архива. Но поддержка H.265 в браузерах до сих пор неровная (уверенно работает в Safari, у остальных — через раз), поэтому для трансляции владельцам обычно настраивают у камеры второй, более лёгкий суб-поток в H.264 (он есть у большинства IP-камер) либо транскодируют на лету через ffmpeg. Второй вариант нагружает процессор — для десятка камер это не критично, но закладывайте пару ядер про запас.

Пример перекодирования одного потока в HLS через ffmpeg, если камера отдаёт только H.265:

ffmpeg -i rtsp://192.168.1.45:554/stream1 \
  -c:v libx264 -preset veryfast -b:v 1500k \
  -c:a aac -f hls -hls_time 4 -hls_list_size 6 \
  -hls_flags delete_segments \
  /var/www/hls/box-12/index.m3u8

Запись архива при этом можно вести отдельным процессом с исходным потоком без перекодирования (экономия ресурсов) — например, через тот же ffmpeg с записью в файлы по часу:

ffmpeg -i rtsp://192.168.1.45:554/stream1 -c copy \
  -f segment -segment_time 3600 -strftime 1 \
  /mnt/archive/box-12/%Y-%m-%d_%H.mp4

Ротацию старых файлов делает простой крон-скрипт по политике хранения:

#!/bin/bash
# удаляет записи старше 21 дня
find /mnt/archive -name "*.mp4" -mtime +21 -delete

Доступ владельцев: приватность, а не публичная трансляция

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

Практическая схема, которая работает без сложной авторизации:

• Каждому боксу — уникальный непредсказуемый токен в ссылке (/box-12/a3f9c1e7b2/index.m3u8), генерируемый при поступлении животного.
• Токен деактивируется автоматически при выписке — простой скрипт, который дёргает базу учёта пациентов клиники и закрывает доступ.
• Ссылка отправляется владельцу лично — в мессенджер или смс, не публикуется нигде на сайте.
• Ограничение через nginx по времени жизни ссылки (secure link module) — чтобы просроченная ссылка физически не открывалась, даже если её кто-то сохранил:

location /box-12/ {
    secure_link $arg_md5,$arg_expires;
    secure_link_md5 "$secure_link_expires$uri secret_key";

    if ($secure_link = "") { return 403; }
    if ($secure_link = "0") { return 410; }

    root /var/www/hls;
}

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

Свой сервер против облачного видеосервиса: на чём считать честно

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

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

Похожая логика уже разбиралась для камер на автомойке, где облачное видеонаблюдение упирается в тот же принцип «платишь за каждый гигабайт» — решение через свой сервер описано в статье про видеонаблюдение автомойки. Разбор ценообразования по числу камер — в статье про расчёт стоимости видеонаблюдения на 16 камер. А если не уверены, каких ресурсов сервера хватит именно вам, сверьтесь со сравнением конфигураций в статье про выделенный сервер для системы видеонаблюдения.

Частые вопросы