Тонкости проектирования систем IP-видеонаблюдения

Ноль не в рекомендациях. Нулевой КПД - самих рекомендации!

В частности, в последнем ролике про якобы простое и в тоже время весьма не простое построение сети.

Знаете как это называется?!

Это даже не тавтология, это - фуфлология!

А знаете почему!

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

Затык будет на так называемой "последней мили", т.е на приемо-передающей стороне.

А в нашем варианте - это будет дырдочка у сетевой карты вашего видеорегистратора, видеосервера - как хотите называйте.

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

А вот теперь и посчитайте (если конечно сможете) входящи-исходящий трафик всей вашей IP системы, ну скажем состоящей из 16 ip ВК, одного сервера с одногетарной сетевой картой на борту, ну и скажем с парочкой сетевых уделенных АРМ.

Вот когда поймете, что вам не светит в этом случае даже возможность установить битрей камеры в размере 30-40% пропускной способности сетевой карты регистратора, деленной на количество камер но при этом помноженное на количество потоков от этих камер, да к тому же еще и деленной на количество уделенных АРМ умноженное на количество камер (ведь мы же можем дать возможность видеть и одному и второму оператору все наши 16 камер) - то выяснится что на все наши "дутые мегапикселы" мы дай Бог при скорости отображения 25 кадров в секунду можем отвести не более 1-3 мегабита (причем заметьте - мегабит, это не мегабайт, и он(мегабит) в 8 раз меньше).

Ну а после таких прикидок, можете сами дать оценку - пользительны рекомендации от авторов семинара, или это всего лишь еще одни способ убедить населении в том что все круто и качественное видеонаблюдение возможно только на принципах "все через IP".

Еще одна засада - освещение периметра:

olestas

Еще одна засада - освещение периметра:

Да-самая главная ЗАСАДА, - это 100 метров!

Да! Решение построения периметральной сети на ВОЛС - это по сути единственное решение подобных задач!

Но! Вот только параллельно с решением задач по постройки ВОЛС вдоль периметра, - придется решать не только задачи сохранности "дешевого" оборудования "IP to ВОЛС" и проблемы прокладывания самой ВОЛС.

Но еще и придется решать вопросы с удаленным питанием, а так же с удаленным резервирование и не только самих IP ВК зачастую работающих от 12В - НО И ВСЕХ СЕГМЕНТОВ СЕТИ "IP to ВОЛС" ПРИЧЕМ ИМЕЮЩИХ ВЕСЬМА РАЗНОШЕРСТНОЕ ЭЛЕКТРОПИТАНИЕ!

Ну а в остальном!

"Да"!

При построении периметрального видеоконтроля - "всё" действительно упирается в слишком маленькую чувствительность CMOS сенсоров мегапиксельных IP!

А всё остальное "решается" "просто"!

И главное "очень дешево" !

Гигабитная сетевая карта, берем 40% - это 400Мбит нам доступно.

16 камер 2Мп, рекомендованный битрейт(к примеру у хиквижна) 4,5Мбит главный поток, второй поток ставим CIF 512Кбит.

Считаем 16*(4,5+0,5) = 80Мбит идет от камер.

Теперь клиенты - если они смотрят в мультикартинке все 16 камер, то трафик до каждого 0,5*16=8 Мбит. Итого могут подключиться 320/8 = 40 клиентов, которые будут смотреть ВСЕ камеры на втором потоке CIF разрешения.

Если клиент смотрит 1 камеру на весь экран то к нему поток 4,5 Мбит, что еще меньше.

И никто не запрещает ставить 2 сетевых карты в сервер, одну для камер и одну для клиентов. Если подсчитать то к одному серверу можно подрубить 400/5 = 80 камер с выше описаными параметрами.

Сейчас с пропускной способностью нет никаких проблем!

И никто не запрещает ставить 2 сетевых карты в сервер, одну для камер и одну для клиентов. Если подсчитать то к одному серверу можно подрубить 400/5 = 80 камер с выше описаными параметрами.

Анатолий!

А много ли Вам известно "железных" DVR имеющих хотя бы одну гигабитную сетевую карту, ну или Вам известны "железные" DVR имеющие возможность установить хотя бы вторую 100 мегабитную сетевую карту?! - Это первое!

Ну а второе, - Вам что нибудь известно о таком понятии как:

Критерий избыточности информации

В общем виде критерий избыточности информации, передаваемой по каналу связи, запишем в виде:

где Q - общий объем информации (байт), предназначенный для передачи по каналу связи за заданное время; AQ - объем служебной (избыточной) информации (байт), которая необходима для организации передачи по каналу связи.

Соответственно значение Q - ?Q характеризует объем целевой (исходной) информации, передаваемой за заданное время. Значение ?q Є[0, 1], и чем эффективнее канал связи, тем ?q ближе к 1.

Передача информации в IP-сети осуществляется путем формирования IP-пакетов с их последующей инкапсуляцией по правилам протоколов, принятых на канальном и физическом уровнях. Предполагается, что длительности IP-сегментов при формировании IP-пакетов и размер "ТСР-ок-на" при их приеме выбраны оптимально, поэтому особенности этих настроек при оптимизации IP-канала в данной статье не рассматриваются. Объем информации, содержащийся в IP-пакетах на сетевом уровне, будем считать исходным и обозначим его Qip (именно этот объем учитывается в тарифных планах операторов). В процессе инкапсуляции этой информации на канальном уровне и на уровне физического соединения происходит наращивание служебной информации в объемах AQS и AQh соответственно. В этом случае - применительно к IP-сети - критерий избыточности информации (1) перепишем в виде:

где ?_s = Qjp/(Qip + ?Qg) - эффективность инкапсуляции IP-пакетов в кадры (ячейки, пакеты) протокола канального уровня;

?h = (Qip + ?Qs)/(Qip + ?Qs + ?Qh) -эффективность передачи информации при соединении на физическом уровне (к этому уровню условно отнесем протоколы многостанционного доступа на основе разделения каналов физической среды). Как следует из (2), для выполнения сравнительного анализа необходимо отдельно оценить эффективность инкапсуляции IP-пакетов T|s применительно к протоколам канального уровня и эффективность организации соединения на физическом уровне % при формировании обратных TDMA-спутниковых каналов.

Ну а для того чтобы понять - что же есть <битрейт качества сжатия>;;;;; в 4,5 Мбит и чем же его объем отличается от <сетевого трафика>;;;;;, - необходимого представлять не только физическую структуру IP пакета:

Но еще и понимать что такое MTU и почему в современных сетях MTU не может быть больше чем 1492 бита.

Ну а вот после всего этого, - можно уже прикидывать реально-необходимый трафик!

Для передачи видеопотока сжатого до величины битрейта 4.5 Мбит/сек - данный объем информации будет передан в виде физических пакетов МTU по 1492 бита, но при этом каждый пакет буде дополнен избыточной информацией в 192 бита.

А вот теперь можно уже более "точней" прикинут сетевой трафик - от одной камеры:

4 500 000 бита информации дефрагментируем на 1492 частей MTU, - получаем приблизительно 3017 физических пакета, каждый из которых будет иметь 192 бита избыточной информации =>;;;;;;;;;;;;; в общей сложности составит 579 264 бита избыточной информации.

Т.е. 4.5 Мбит - вдруг "чудесным" образом приблизительно превратятся в 5 79 264 бит сетевого трафика (5,79 Мбит).

Ну а теперь можете сами "посчитать" систему - на 16 камер, но вот только имейте в виду что:

Эффективность критерия избыточности - тем выше чем больше объем передаваемой информации, ну а для второго потока, имеющего меньший битрейт - коэффициент избыточности будет больше (ну так уж устроены формализированные физические пакеты, что их минимальный размер не может быть меньше - чем 32 бита данных + 192 заголовок, т.ч для передачи всего 1 бита данных по сети придется передать пакет в 224 бита ).

Ну а еще не забывайте что помимо второго ("маленького") видеопотока - IP ВК умеет передавать еще более "меньший" - поток метеоданных от детекторов движения, ну а еще она может передать к тому же и звук.

И весь этот трафик, от всех 16 камер - вам необходимо иметь возможность ретранслировать на два сетевых рабочих места.

Гм, Вадим, со многими вашими темами-постами согласен, но по поводу пропускной способности в ракурсе ИП видеонаблюдения всеж не совсем корректно.Практически никогда не использовал железные реги ИП, а в основном сервера, на которых как минимум всегда установлено 2 сет интерфейса 1гиг (один камеры, и один на УРМы). При недостаточности пропускной способности с любого из "концов" добавлялась еще одна (две, три) сетевуха и агрегировалась с нужнным портом. Еже ли использовать рег. ИП с одним сет интерфейсом 100мб и обвешать его кучей 2-3-х мп камер и подключить вереницу УРМов - стоит усомниться в компентенции специалиста в данной области.

То бишь, я это к чему? - не стоит рассматривать только железные DVR-ы.

в современных сетях MTU не может быть больше чем 1492 бита.

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

Для стандартного Ethernet-кадра MTU = 1500 байт (подавляющее большинство действующих сетей IP over Ethernet используют его).

Для Jumbo-frame Ethernet MTU может достигать 16000 байт, но, как правило, все работающие в настоящее время реализации (в том числе VOCORD NetCam4) используют в режиме Jumbo-frame MTU=9000 байт.

А размер заголовка IP-пакетов измеряется в битах, поэтому не превышает 192 бита = 24 байта.

т.о.: [эффективность IP over Ethernet] = (1500-24)/1500 >;; 98%

т.о.: [эффективность IP over Ethernet] = (1500-24)/1500 >;;;; 98%

Наш ответ "Чемберлену":

Я конечно в "пылу" и могу попутать четыре бита с одним полубайтом, - вот только дефрагментация пакетов сети и размер MTU от этого не возрастает больше чем даже 1500-24=1476 байта!

И MTU не может стать "толще и длинее" - даже у "солидной конторы" торгующей h2s: