Битрейт — скорость передачи битов за определенный период времени (объём информации измеряют в байтах, а скорость в битах).
В случае с облачным видеонаблюдением от битрейта напрямую зависит расход трафика. Если услугу облачного видеонаблюдения оказывает интернет-провайдер, то трафик от облачной камеры не тарифицируется, если Ivideon, то тарифицируется.
Рекомендуемый компанией Hikvision битрейт для камер видеонаблюдения (25 кадров в секунду).
Примеры видеозаписей с камеры DS-2CD2232-I5 с различным битрейтом (6, 2, 0.8 мегабит).
В предыдущих видео записано со скоростью 25 кадров в секунду, в нижнем 4 кадра в секунду.
Для того, чтобы рассчитать сколько трафика будет «кушать» одна IP видеокамера с разрешением 1280х720 можно воспользоваться калькулятором, или ориентировочно расcчитать по таблице:
| Битрейт, мегабит | Вес 1 часа видеозаписи, мегабайт |
| 0,5 | 228 |
| 1 | 459 |
| 2 | 922 |
| 3 | 1 380 |
| 4 | 1 842 |
| 5 | 2 303 |
| 6 | 2 763 |
| 7 | 3 223 |
| 8 | 3 685 |
Пример, камера в офисе пишет 6 часов в сутки, ограничение по битрейту — 1 мегабит. В месяц расход трафика составит 6 часов х 459 мегабайт х 30 дней = 82 620 мегабайт (~82 гигабайта).
Таблица оторвана от реальности, т.к. не указано кол-во кадров, относительно которого приведена информация. Посему необходимо пользоваться калькулятором, но как показывает практика, калькулятор тоже привирает, но примерные данные мы получим и для расчета ширины канала и размера архива их в принципе будет достаточно. Ваш калькулятор, который по ссылке в этой статье, имеет странную зависимость: каким образом поток с камеры так сильно зависит от интенсивности движения? Поток с камеры в реальности при отображении стандартной картинки (т.е. при нормальном освещении) без движения и с движением меняется максимум в пределах 20%, но не больше. Из практики, как пример, имеем камеру Hikvision DS-2CD2132-I (разрешение 2048 x 1536 (т.е. максимальное), скорость 12 кс, качество: highest (т.е. максимальное)) — без движения камера формирует поток от 2.7 до 3.1 Мбит/с, при движении в кадре поток возрастает до 3.5, в пиках до 4.2-4.5 (но пики в минуту занимают максимум до 10% времени), т.е. в среднем по факту примерно 3.6-3.7 Мбит/с, что собственно и подтверждает поток на сервере CMS ПО Hikvision iVMS-5200: при подключенных 35 камерах (используются Hikvision DS-2CD2132-I, DS-2CD2032-I, DS-2CD2532F-I) с одинаковыми настройками (указаны выше) имеем средний входящий поток 120 Мбит/с, в пиках до 135 Мбит/с. При таких настройках и интенсивности движения примерно 40% массив 14Тб (4HDD x 4Тб) хранит видеоархив для 16 каналов примерно 35-37 дней.
Таблица взята у Hikvision, 25 кадров в секунду. Добавил пояснение. За замечание — спасибо.
Исходные данные в калькуляторе в свое время были взяты из программы IP Video System Design Tool.
Практика лучше теории. Ваша информация по битрейту более чем полезная.
Для полноты картины в статье еще желательно указать кодек. Я так понимаю, что речь, конечно же, идет о кодеке Н.264, т.к. при использовании других кодеков поток будет совсем другой и явно не в меньшую сторону. Я хотел это упомянуть еще в первом своем посте но в процессе написания упустил этот момент.
Из практики пример на эту тему: заказчик решил сэкономить на компьютерах АРМ мониторинга, так как посчитал конфигурацию предложенных мной в проекте для этих целей компьютеров избыточной и сказал, что не собирается за это переплачивать и сошлись на том, что он самостоятельно подберет и закупит для этой задачи компьютеры, а от нас только установка и настройка. В итоге мы получили 4 машины, которые не тянут по 16 камер с кодеком Н.264 в качестве 2Мрх — 12 кс: процессор загружается на 100% и все начинает жутко тормозить (Н.264 достаточно требователен к мощности процессора при просмотре, особенно если система видеонаблюдения не предусматривает технологию двухпоточности для мониторинга — это еще одна тема для отдельной статьи ;). Пришлось выкручиваться из этой ситуации, так как заказчик естественно был не готов закупить еще 4 более мощные машины да и как это оправдать перед собственным руководством?! Вышли из положения путем перевода всех камер в кодек MPEG4 и естественно столкнулись с другой проблемой, а именно с резко возросшей нагрузкой на сеть, потому как MPEG4 транслирует практически несжатый сигнал и каналов по 100 Мбит/с, предполагаемых мной в проекте на каждый операторский компьютер, стало не хватать. Пришлось закупать еще один общий коммутатор со всеми гигабитными портами для объединения на такой скорости всех конечных устройств видеонаблюдения, а именно PoE-коммутаторов, видеосерверов и АРМ операторов. Гигабитных портов на закупленных проектных PoE-коммутаторах хватало ровно для подключения видеосерверов и ап-линков между самими коммутаторами, а подключение операторских машин от этих же коммутаторов предполагалось на скорости 100 Мбит/с.
Такой вот пример мнимой экономии, которая по итогу еще и вышла «боком» для заказчика.
Да, кодек H.264. Про другие кодеки здесь.
Forgot, скажите а что за сервер вы используете? От Hika??
Просто мы уже давно ставим себе Экзак Вижн (спецом по русски пишу, рекламировать лишний раз не хочется).
Так вот при достаточно приличной стоимости ПО, он очень не требователен к ресурсам + ставлю все под Linux.
Так вот загрузка процессора с 11 камерами составляет примерно 20-23% с процессором Celeron® G1840 и постоянно подключен клиент и смотрит 7 основных потоков.
Есть сервера и с 20 камерами (правда проц там получше i3-4130), но тут клиентов постоянных больше 5, по 10, 8, 2, 5 и 11 потоков соответственно. И еще перманентно подключаются отдельные клиенты для просмотра. Так вот загрузка тут уже побольше от 25-30% CPU и памяти использовано 500 Мб. Сетевых карт две по 1000 Мбит/с. объединены с балансировкой нагрузки.
Да камеры пишутся с разрешением 1920х1080, 8 к/с, качество максимум, но я ограничиваю битрейт до 3-2 Kbps.
В общем меня устраивают такие настройки:
Разрешение: 1920х1080
Тип битрейта: переменный
Качество видео: Максимальный
Частота кадров: 8
Максимальный битрейт: 2048 или 3072
Интервал I кадра: 50
Тут конечно каждый выбирает сам, что ему нужно смотреть и в каком качестве.
Не ответил сразу, т.к. не думал, что тут будет такие активные комментарии и не заглядывал сюда. Вставляю свой, так сказать, отчет о использовании ПО Hikvision iVMS 5200 Pro, который я ранее размещал на другом форуме. Вставляю без каких либо правок и изменений, т.к. особо что-то добавить нечего даже с учетом того, что сейчас использую более новую версию, а именно iVMS-5200_P_V3.02.010_20150618.
«Все же я вернулся на iVMS-5200! В пользовании уже почти месяц, с ключем разобрались. Вероятно была проблема, что я попытался полученым ключем активировать версию 3.2.0 с вражеского сайта и ключ попал в бан. Новый ключ нормально активировал российскую лицензию. Все же могу сказать, что по прошествии месяца использования iVMS-5200 тестовой версии 3.2.0 и потом вынужденный переход на iVMS-4200 (см. мои посты выше в этой ветке форума) ни чего хорошего не дал. После iVMS-5200 старая версия iVMS-4200 выглядит очень печально, все кажется каким-то не таким, не правильным и т.д. (я ведь начал использовать ПО Hikvision именно с версии iVMS-5200 v.3.2.0) и связался вновь с представительством Хиков в России, запросил новый тестовый ключик на российскую версию.
Далее не большая, так сказать, зарисовка по использованию ПО iVMS-5200 с российского сайта Hikvision, версия 3.1.0.
Сразу могу сказать, что все работает и все вполне устраивает. Система на данный момент состоит из сервера CMS, на котором еще крутиться SMS (машина: MB ASUS Z97-K, CPU Core i5-4460, RAM 16 Gb, Win 8.1 Pro x64), 2 одинаковых сервера хранения (StorageServer) (машина: MB AT4NM10T-I с впаянным CPU Atom D425 с пассивным охлаждением, RAM 4 Gb, 4 HDD WD40PURX-64GVNY, Win 7 Pro x64, рековый корпус 2U), подключено на данный момент 26 камер Hikvision серии Raptor разных моделей и одна DS-2CD6362F. Все камеры Raptor настроены на максимальное разрешение 2048х1536, 12 кс, макс. битрет 4096. В данный момент загрузка процессора сервера CMS, SMS составляет 35-40%, загрузка оперативки 2,5Гб, трафик Ethernet: прием 35-50 Мбитс; передача 35-70 Мбитс в зависимости о кол-ва подключенных клиентов. Подключение одного клиента через ПО iVMS когда добавляет в передачу трафика от 5 до 15 МБитс, когда вообще ничего не добавляет, не понял зависимости. Подключение клиента через web-морду не добавляет ничего за счет SMS-сервера. На загрузке процессора сервера CMS кол-во подключенных клиентов по моему ни как не сказывается, по крайней мере я ничего такого не заметил. Загрузка серверов хранилищ вообще мизерная: CPU — 4%, RAM — 28%, трафик Ethernet 20-25 Мбитс (эту инфу об использовании ресурсов привожу из диспетчера задач Windows). Камеры распределены равномерно по серверам. Система в дальнейшем будет расширяться, еще штук 20 камер ждут на складе своего часа, на следующей неделе добавлю еще около 10 камер, чуть позже еще добавлю сервер хранения, отпишусь позже по поводу загрузки оборудования и т.д. Со временем расширимся до 64 каналов, ну а там дальше видно будет.
Теперь по поводу минусов и разных непоняток:
— нет в этом ПО групп, как в iVMS-4200, но есть зоны, которые можно создавать и добавлять туда камеры. Но почему-то на эти зоны создаются с каналом виде, тревожными входом и выходом. Зону необходимо создавать заранее, до добавления в эту зону камер, т.к. потом переместить камеру из зоны в зону нельзя, такой функционал вроде как есть, но поле смены зоны для камеры не активно. Эти зоны очень выручают при просмотре через web-клиент (я об этом пишу ниже), так же группировка такими зонами очень помогает при настройке прав пользователей (не приходиться каждую камеру щелкать мышкой, а включаем сразу группой). Не забывайте при добавлении новых камер в уже работающую систему давать разрешения на просмотр и т.д. существующим пользователям системы;
— периодически в «Расписание записи» в колонке «Статус записи» по разным каналам появляются красные надписи «Исключение записи сервера хранения», так же потом исчезают. От чего появляется такое сообщение не понятно, появляются когда по одному каналу или сразу по нескольким или постепенно по разным каналам, исчезают как правило сразу все по одному из серверов хранения. Запись архива в это время ведется без каких либо проблем (отслеживал специально по на разных каналах) и просматривается в это время архив такого канала так же без проблем. Тех.поддержка пока ничего не сказала, не давно отправил логи с сервера хранения, пока изучают;
— при добавлении новых камер очень не удобно, что нет какой либо галочки, которая бы скрывала в поле «Онлайн устройства» уже подключенные камеры. Приходится выискивать новые IP-адреса среди многих других, которые уже подключены. Так же хочу отметить, что был замечен глюк после добавления 5 новых камер в систему: камеры сначала настроил через web-морду, затем добавил в систему, везде все подобавлял и т.д., но архив не начал писаться по этим каналам до тех пор, пока не перезагрузил все на CMS-сервере, хотя детекция движения отображалась в клиенте iVMS, но записи не было. Хочу обратить внимание, что желательно до добавления камер в систему желательно прописать через браузер им имена в настройках «Расшир конфигурация» — «изображение» — вкладка «Параметры OSD», т.к. в настройках сервера в «Логическое представление» и «Расписание записи» отображаются именно имена камер, которые прописаны в самой камере. Можно присваивать имена и на русском языке, но тогда шрифт на картинке самой камеры выглядит очень коряво, так что я подписываю латиницей;
— при использовании web-просмотра нет сохранения видов, т.е наборов камер. Даже при переходе на просмотр архива и возврате обратно на живое видео приходиться набирать камеры снова. Спасает то, что созданные перед добавлением новых камер зоны (я писал об этом выше) отображаются в web-клиенте и двойной клик по этой зоне сразу запускает эту группу на просмотр. Так же в клиенте очень раздражает отображение зеленой сетки детекции движения и со слов техподдержки, пока ее никак нельзя отключить. От этой сетки больше вреда, чем пользы, т.к. реально вместо движения все наше внимание сосредотачивается на сетке, да и саму картинку эта сетка здорово закрывает, что полезная информация изображения камеры сокращается в разы;
— не очень понятное создание видов в клиентском ПО iVMS: сначала создаем вид, затем выбираем конфигурацию раскладки камер, затем добавляем в окна конфигурации камеры. Если камеры подвигать из окна в окно конфигурации, то кнопка сохранения вида становиться не активной и приходиться начинать все сначала (сам вид вверху справа при этом пересоздавать не обязательно), так что имейте это ввиду при создании новой конфигурации;
— периодически появляются сообщения в окнах камер клиентского ПО iVMS об ошибка и переподключении камеры, как правило через какое-то время изображение появляется. Если же во время такого сообщения переключится на другой вид, где есть этот же канал, то вероятнее всего он сразу же отобразиться, так что проблема в самом отображении конкретного вида;
— не совсем корректно и не верно отображается информация в окне «Физическое представление», колонка «Сетевой статус» о камере и о серверах хранения: камера в сети и с нее есть картинка через ПО iVMS, но в сетевом статусе светится красная надпись «Не в сети», так же, только наоборот, было с сервером хранения (сервер давно не в сети, я его отключил по необходимости, а система сообщает, что все хорошо и все сервера в сети). Так же заметил еще такую странность с CMS-сервером: после полной перезагрузки машины с сервером CMS в мониториге через ПО iVMS CMS-сервер светиться красным, т.е. как исключение, до тех пор, пока не залогинился на сервере через rdp. При этом все работает (просмотр работает, архив пишется и просматривается, web-менеджер сервера доступен);
— не нравится, что при просмотре архива через клиента ПО iVMS, т.е. через «Воспроизведение записей» при выборе даты нет в календаре отображения, по каким датам есть записи, а по каким нет. Да, под шкалой времени есть даты прошлых 7 дней и там видно, когда была запись в архиве, а когда нет, но в самом календаре это ни как не отображается, не очень удобно и наглядно.
Возможно, что я здесь не все глюки и непонятки перечислил, которые заметил за месяц использования, но это то, что отложилось в памяти, а значит самое основное. Скажем так, совсем не мало, но не критичные и на функционале системы в целом по большому счету не сказываются.
Сегодня сделал заявку на постоянную бессрочную лицензию. »
Если есть какие-то вопросы, спрашивайте, буду сюда почаще заглядывать.
Для информации: информация о потоке с камеры получена с управляемого коммутатора (TFortis, HP, D-Link), где можно наблюдать реальную картину потоков по каждому из портов, к которым подключены вкамеры.
TFortis в плане проектирования оборудование хорошее. Заказчикам тоже нравится.
Ну в плане дальнейшей эксплуатации тоже достаточно неплохо. Кольцо из оптики нормально работает, вот на последнем объекте хочу попробовать поиграться с настройками для уменьшения времени восстановления канала после обрыва кольца.
Я списывался с производителем, обещали поправить в новой прошивке возможность более точной установки битрейта для отслеживания зависания камер (может даже уже поправили). Существующая дискретность установки битрейта не позволяет сделать правильную настройку, т.к. в ночное время при слабом освещении Hikvision DS-2CD2032-I дает еще меньший поток, чем у TFortis минимально возможное значение битрейта. Если воспользоваться функцией watchdog в текущей прошивке (отслеживание битрейта с вкамеры), то в ночное время камеры будут в постоянном ребуте. У них есть еще возможность watchdog-а по ping-у, но бывает, что камера подвисает, скажем так, не полностью и ping проходит, а вот изображения нет.
Если кому интересно, могу здесь отписаться или же может Денис сделает отдельную тему по вопросам TFortis.
Tfortis заслуживает отдельной статьи. И коммутаторы и термокожухи и сайт — tfortis.ru. В плане проектирования видеонаблюдения в свое время открытие для меня было. Думаю не совру, что в Беларуси я первый их в проекты начал закладывать.
Нашел по рекламе Яндекса и потом понеслось — красивые, простые, работающие решения по вменяемым ценам.
А можно поподробнее изложить тему зависания IP-камер или отдельную статью об этом написать? Очень интересует этот вопрос, потому что у нас в филиале стоит IP-видеонаблюдение и периодически одна камера как «паршивая овца» то потухнет, то опять включится…
Статью точно писать не буду, т.к. с проблемой близко не знаком. В проектах для видеонаблюдения применяю коммутаторы Tfotris с модулем контроля зависания видеокамер, грозозащитой по питанию 220В и Ethernet портам.
В управляемых коммутаторах TFortis (ТОЛЬКО в управляемых коммутаторах!!!) есть возможность через web-интерфейс коммутатора включить отслеживание зависания вкамер и в случае детектирования зависания камеры коммутатором будет произведено передергивание питания PoE конкретного порта. Детектирование возможно по одному из трех критериев, а именно:
— контроль потока с вкамеры (при потоке ниже настраиваемого порога будет произведена перезагрузка);
— контроль наличия сигнала с вкамеры (при отсутствии линка с камерой будет произведена перезагрузка);
— постоянный пинг вкамеры (при отсутствии пинга будет произведена перезагрузка).
На сайте в информации о неуправляемом TFortis PSW-1-45 указано — модуль контроля зависания видеокамер.
Спасибо, полезная статья.
Спасибо, смотрим п.2.4 правил комментирования 😉
У Ivideon , если не использовать облако в качестве хранилища расход трафика — только непосредственно при просмотре живого видео/архива с видеокамеры/регистратора. Если ничего не просматриваешь расход трафика не ведётся. Проверено.
Тестирую сейчас две их камеры. Сейчас в мобильном приложении появилась история в которой даже на бесплатном тарифе можно просматривать короткие видео которые попадают в историю при появлении движения в кадре.
Так, что пуст немного, но тем не менее за счет этой фишки расход трафика будет даже если ничего не просматриваешь.
Здравствуйте Денис у меня вопрос по ivideon.Существует насколько я знаю два сайта под этим облачным названием.Если можно подскажите в чем разница.У которого я зарегистрировался еще три года назад две камеры подключение бесплатно.С уважением Шамиль
Есть ru.ivideon.com — это один. Второй, подозреваю — это английская его версия ivideon.com. Если, что-то другое имеете в виду, то говорите. Будем смотреть в чем разница.
По поводу видеонаблюдения через интернет у меня в 2009 году был интересный случай (возможно кому-то пригодиться): заказчику на строящийся объект срочно понадобились камеры для удаленного отслеживания этапов строительства. Поставили на двух кранах по speeddom-у AXIS (модель уже не помню), сделали связь через WiFi на Ubiquiti с прорабской, а вот с удаленным доступом к камерам возникла проблема. Интернет-канал у них на стройке был не специально для стройки, а от рядом существующего здания и они там конечно были на «птичьих правах», в общем вот этот владелец интернета давал им доступ в интернет изнутри, т.е. со стройки, а снаружи доступ ни в какую и сказал, что бы даже не подходили с таким вопросом (админы просто не захотели заморачиваться с пробросом канала). Выручил фунционал прошивки AXIS-ов: у них есть возможность выкладывать снимки на с установленным интервалом на ftp-сервер, чем мы и воспользовались (отправляли снимок каждые 3 секунды, что бы не нагружать канал). У заказчика в офисе подняли ftp-сервер для этих изображений и админы заказчика настроили доступ для руководства к этим изображениям. Не реальное видео, конечно, но картину стройки позволяло отслеживать, а большего им и не надо было.
Тоже решение. В идеале технические условия на прокладку оптики от стройки до офиса или от интернет-оператора до стройки и организация качественного канала связи.
Потом обзорные камеры, камеры с оптическим увеличением, мобильные установки с видеокамерами, камеры на кранах, архивирование с прореживание всего процесса стройки :).
Это в идеале, а по факту все надо было срочно, т.е. еще вчера! Ну все как обычно. Мы могли это реализовать очень быстро и поэтому мы и делали эту работу, а вот на реальный объект с огромным бюджетом и кучей разных интересных систем нас не пустили чисто по политическим соображениям. Зачастую именно так и происходит и заказчика не интересует ни цена реализации, ни сама техническая реализация и подход того или иного инсталлятора, потому как решают личные знакомства, политические мотивы и т.д.
Согласен, так оно и есть.
P.S. к предыдущему моему комментарию: у IP-камер Hikvision по моему тоже есть возможность выкладывать на ftp, что-то такое я там вроде бы видел. Сейчас точно не скажу, сейчас нет возможности проверить, но на следующей неделе смогу посмотреть настройки камеры и отвечу, если это кому-то интересно.
Есть в прошивках Hikvision возможность выкладывать на FTP. Интересует каким образом на монитор заказчика выводилась последняя картинка.
Заказчик все время ручками выбирал последний кадр или существует (была написана) небольшая программка реализующая данный функционал?
Админы заказчика настроили подгрузку изображений с ftp в закрытый для общего доступа раздел сайта заказчика и руководство смотрело все это через браузер. На веб-страничке настроили возможность выбора скорости обновления. Вообще эту часть работы делали уже админы самого заказчика, по этому тонкостей настроек не скажу, нас туда конечно же никто не пустил.
Можно собрать такую схему : LTE модем(при отсутствии — 3G, но нежелательно), точка доступа(или свитч) с поддержкой этого модема и камеры с поддержкой сервиса Ivideon. Все, ни от кого не зависим, живое видео, хоть на сайт выкладывай по продаже будущей недвижимости. А был объект на котором работало вот так : видеокамера Микродиджитал 4240i (с usb портом на борту + 4G usb модем + micro SD 32 gb. Почти автономная система видеонаблюдения.
Можно, тестировал такой вариант здесь.
Челентано напомнил )))
Улыбнуло :).
ЕВГЕНИЙ:
Интервал I кадра равный 50 конечно дает хорошую длительность записи на диск. Зато если в кадре двигающиеся объекты, особенно если они занимают площадь более 15_20% то все они в записи смазаны.
Причем этот смаз не устраняется изменением затвора в более короткие значения выдержек.
Да, смазывание есть при I=50, но вы попробуйте выставить Качество Видео на «Максимум» и вы увидите что смазывание будет гораздо меньше.
И снова повторюсь: настраивать необходимо каждую камеру под конкретную задачу. Если камера обзорная или смотрит статические объекты, то к качеству картинки одни требование, а вот если нужно смотреть лица «четко», то конечно уже другие.
Мне в 90% случаев необходима общая картина, в которой перемещение объекта не так сильно критична.
Доброго времени суток!
Приостановил случайным образом просмотр образцов записи с различным битрейтом и был удивлен получившейся картинкой — как будто картинка образца с низким битрейтом получилась менее смазанная, чем с высоким:
https://yadi.sk/i/hEsoSkQ-3iVZZg
https://yadi.sk/i/jbf3JPB5qAJC0A
Отсюда вопрос — это ютуб вносит какие то свои дополнительные искажения или действительно качество картинки так сильно зависит от движения?
И то и другое влияет на качество стоп-кадра.