Расчет пропускной способности видеонаблюдения: потоки, каналы и запас

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

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

Какие параметры определяют сетевую нагрузку

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

• CBR стремится удерживать заданный постоянный битрейт. Такой поток удобнее прогнозировать, но фактическая скорость все равно может немного колебаться.
• VBR изменяет скорость в зависимости от сцены. Для расчета следует брать установленный максимум, а не спокойное среднее значение.
• Основной поток обычно идет на запись и создает большую часть нагрузки.
• Дополнительный поток используется для мультиэкрана или мобильного просмотра, но тоже учитывается, если передается одновременно.
• Аудио, метаданные и управление добавляют небольшой, но ненулевой объем данных.

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

Базовая формула расчета

Для группы камер расчетная полезная нагрузка определяется суммой одновременно проходящих потоков:

B_video = B₁ + B₂ + … + B_n

Затем вводят коэффициент запаса:

B_required = B_video × K

Для устойчивого проекта коэффициент K обычно принимают не ниже 1,2–1,3. Больший запас нужен при VBR, неясных настройках камер, наличии другого трафика в том же сегменте или вероятном расширении системы. Это не универсальная константа: коэффициент выбирают после анализа условий.

Пример для одного коммутатора

Допустим, к коммутатору подключены 12 камер. Максимальный основной поток каждой камеры равен 6 Мбит/с, дополнительный поток — 0,5 Мбит/с. Оба потока одновременно передаются на сервер:

12 × (6 + 0,5) = 78 Мбит/с.

При запасе 30% расчетная потребность магистрального порта составит:

78 × 1,3 = 101,4 Мбит/с.

Интерфейс Fast Ethernet 100 Мбит/с здесь не подходит: расчет уже превышает его номинал, а полезная производительность реальной линии ниже паспортной. Гигабитное подключение обеспечит нормальный резерв. При этом каждый отдельный порт камеры может работать на 100 Мбит/с, поскольку через него проходит поток только одной камеры.

Считать нужно каждый участок сети

Особое внимание требуется интерфейсу записи. Если 80 камер передают по 8 Мбит/с, сервер принимает 640 Мбит/с до учета дополнительных потоков и запаса. Один гигабитный интерфейс формально может пропустить такой объем, но его резерв быстро уменьшится при воспроизведении, копировании записей, синхронизации или работе других сервисов.

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

Диагностический алгоритм

1. Составьте схему маршрутов. Укажите камеры, коммутаторы, uplink-порты, серверы, рабочие места и межплощадочные соединения.
2. Зафиксируйте настройки потоков. Для каждой камеры запишите кодек, разрешение, кадровую частоту, CBR или VBR, заданный и максимальный битрейт.
3. Определите одновременность. Уточните, какие потоки постоянно идут на запись, какие открываются оператором и где используется субпоток.
4. Суммируйте трафик по каждому направлению. Один поток учитывайте на каждом участке его маршрута, но не дублируйте без причины.
5. Добавьте запас. Учтите пики VBR, протокольные накладные расходы, служебный и посторонний сетевой трафик.
6. Сравните результат с возможностями оборудования. Проверяйте не только скорость порта, но и производительность коммутации, ограничения регистратора и фактический режим линка.
7. Проведите измерение. Снимите статистику в обычный период и во время активной сцены, одновременного просмотра и выгрузки записей.

Проверяемые критерии после расчета

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

• Фактическая загрузка uplink-портов не подходит вплотную к их полезному пределу.
• На интерфейсах не растут счетчики ошибок, отброшенных пакетов и повторных передач.
• Согласованы ожидаемая скорость и полный дуплекс; нет случайного перехода на 100 Мбит/с вместо 1 Гбит/с.
• При одновременном открытии нескольких камер запись не получает пропуски и не увеличивает задержку.
• Пиковый битрейт активных сцен укладывается в принятый резерв.
• Добавление пользовательского трафика не приводит к конкуренции, влияющей на видео.

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

Типовые ошибки

Расчет по среднему VBR

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

Игнорирование субпотоков и просмотров

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

Оценка только гигабитного uplink

Наличие порта 1 Гбит/с не гарантирует такую же производительность всей цепочки. Ограничением могут стать следующий коммутатор, радиомост, межсетевой экран, интерфейс сервера или внутренняя производительность регистратора.

Сравнение с номинальной скоростью без резерва

Нельзя проектировать постоянную видеонагрузку ровно на паспортный предел интерфейса. Помимо видео передаются заголовки протоколов, широковещательные и управляющие пакеты, а загрузка камер меняется во времени.

Границы метода

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

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

Итог

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

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