gop потока больше рекомендуемого securos как исправить
Форум по системам видеонаблюдения и безопасности.
Форум по системам видеонаблюдения, безопасности, пожарным и охранным сигнализациям, контролю доступа.
Оптимальные настройки для IP камеры
Оптимальные настройки для IP камеры
Сообщение ThreeLeaf » 09 апр 2015, 07:29
Здравствуйте. Подскажите пожалуйста, мне бы хотелось как можно более правильнее задать её параметры, дабы снизить нагрузку на ПК и сеть, но при этом не сильно потерять в качестве картинки.
На данный момент у меня возникают вопросы по следующим пунктам:
-Тип битрейта
-Максимальный битрейт
-Интервал I кадра
-SVC
Из того что мне удалось найти в интернете я пришёл к выводу что Тип битрейта лучше выбирать переменный (во всяком случае исходя из того что движений на камерах у меня не много), но при этом нужно оставить запас пропускной способности в сети на случай резкой активности сразу на нескольких камерах. Что можете сказать по этому поводу?
Максимальный битрейт, если я правильно понимаю является неизменным и фактическим если ставить постоянный тип битрейта и является максимальным (видимо во время записи) если выбирать переменный, но какой какой битрейт задаётся (видимо автоматически) и исходя из чего при потоке с переменным, но без записи? Какой вы обычно ставите битрейт? У меня камера позволяет выбрать 256-12588. Разрешение меня интересует FHD. И возможно глупый вопрос, но нагрузку на сеть рассчитывать исходя из суммарного битрейта всех камер?
Про интервал 1 кадра к сожалению вообще нечего не знаю. По умолчанию стоит 50. За что этот параметр отвечает и какое значение по вашему мнению лучше выставить?
SVC. Интернет говорит что это некое сжатие. Помогает судя по всему экономить место на жестком диске. Это всё хорошо, но есть ли минусы у этого параметра или лучше его всегда включать?
И ещё вопрос, возможно глупый. Я ошибаюсь или можно настраивать показ через доп.поток, а запись через основной?
Опорный кадр в H.264. Маленький параметр с большими последствиями
Структура кодека H.264
Прежде чем говорить об опорном кадре, нужно понимать структуру потока и принципы работы кодека H.264. Для начала немного теории.
Спецификация H.264 была опубликована еще в 2003 году. Кодек стал настоящей революцией в телевидении высокой четкости. Он позволил хранить и передавать изображение высокого разрешения с высоким качеством и битрейтом в несколько раз меньшим, чем другие форматы сжатия. Давайте рассмотрим структуру потока формата H.264.
IP-камера передает полные кадры (JPEG)а, между ними передаются только кодированные изменения изображения относительно опорного кадра. В этом и заключается суть межкадрового сжатия. Полные кадры получили название I-кадры. Далее следуют P и B-кадры. P-кадры содержат информацию об изменениях относительно I-кадра. B-кадры связаны как с I-кадрами, так и с P-кадрами. Все это нацелено на более эффективное сжатие и низкий поток с высоким качеством, но за это приходится расплачиваться высокими затратами на вычислительные мощности и оперативную память сервера при декодировании.
Из схемы структуры потока можно также заметить, что при декодировании невозможно восстановить изображение из B-кадра пока не будет получен P-кадр. В связи с этим мы и видим задержку в отображении потока с IP-камеры в H.264.
Существуют различные профили H.264, которые отличаются возможностями по кодированию. Чтобы не углубляться в теорию стоит отметить, что чем выше спецификация профиля, тем выше степень сжатия с сохранением высокого качества, но тем больше нагрузка на процессор камеры для кодирования и на ресурсы сервера по декодированию потоков. Так же, у старших профайлов больше упомянутая задержка в отображении потока с IP-устройства. Современные камеры в большинстве своем поддерживают Baseline Profile и Main Profile. Профессиональным IP-камерам доступен High Profile.
Что такое «опорный кадр»?
Оптимальная частота следования опорных кадров
Оптимальное значение периода следования опорных кадров средней сцены и типовых задач видеонаблюдения выбирает производитель IP-камеры и выставляет по умолчанию в настройках кодека. Встречаются IP-камеры со значением GOP length от 32 до 120 и более. В то же время, значение частоты опорного кадра (GOP length) оказывает значительное влияние на работу систем видеоанализа, и об этом мало кто задумывается, а точнее никто и не знает. Вот об этом поговорим подробно.
Значение опорного кадра для видеонаблюдения
Это связано с тем, что для восстановления дополнительных кадров из потока H.264 для работы видеоаналитики пришлось бы задействовать значительные вычислительные ресурсы ПЭВМ.
А вот теперь представьте себе, что для темпа видеоввода 25 к/с и значения GOP=100 мы получаем опорный кадр для работы видеоаналитики каждые 4 секунды. Какая точность и задержка у нас будет, хотя бы в детекции движения? За 4 секунды может произойти многое, а алгоритмы видеоанализа этого могут и не заметить, т.к. опорные кадры до возникновения происшествия и после будут одинаковыми. Для проверки этой теории мы даже сняли видеоролик и разместили его на нашем канале в YOUTUBE:
Как это ни странно, но об этом практически никто не говорит. В редких рекомендациях на форумах техподдержки можно встретить совет по уменьшению частоты следования опорных кадров (уменьшения GOP) в IP-камере для решения проблем с детекцией движения.
Самое опасное в этой ситуации, что проблемы в детекции характерны на быстродвижущихся объектах и при определенном стечении обстоятельств. А по всеми известному закону эти обстоятельства возникнут в самый неподходящий момент, и в архиве не будет информации о том, кто поцарапал директорскую машину или куда пропал портфель важного гостя. И разобраться в первоисточнике проблемы практически невозможно. Проще сказать, что это глюк ПО видеонаблюдения, хотя заказчику от этого не легче.
Некоторые производители решают эту проблему через изменение настроек IP-устройств при их подключении к VMS. Семейство продуктов ITV|AxxonSoft (Интеллект, AxxonNext) автоматически меняет значение частоты следования опорных кадров в IP-камере и устанавливает GOP=8, но это возможно только в том случае, если камера качественно интегрирована. Если же мы подключаемся по RTSP или Onvif, то этого не происходит, и в детекции возможны проблемы и пропуски. При этом следует помнить, что изменение «опорника» сильно сказывается на потоке с IP-устройства и увеличивает размер видеоархива. Как решить эту проблему мы рассказывали в статье Настройка детектора движения в ПО Интеллект.
Другие производители восстанавливают недостающие кадры путем частичной декомпрессии H.264 и получения промежуточных кадров для работы видеоаналитики. Так делает, например, Macroscop. Но, как мы уже заметили, это не дается даром и приходится расплачиваться высокой нагрузкой на видеосервер. Об этом рассказывается в статье Особенности работы ПО IP-видеонаблюдения.
Резюме
Внимательно изучая значение и влияние различных параметров IP-устройств, открываешь для себя много интересного, а порой и крайне важного для работы систем видеонаблюдения. Кто бы мог подумать, что незаметный GOP в IP-камере может оказывать столь существенное влияние на такие базовые функции системы видеонаблюдения, как запись видеоархива по детекции движения.
В построении систем видеонаблюдения нет несущественных параметров. В определенных ситуациях любая функция или настройка может стать определяющей. Специалисты компании Видеомакс постоянно изучают возможности программных продуктов и функционал современных IP-камер на реальных стендах, изучая спецификации производителей и опираясь на фундаментальные принципы и знания, полученные в лучших технических вузах страны.
Результатами этих исследований мы делимся со своими партнерами, помогая создавать эффективные системы видеонаблюдения, которые не подведут и будут долгие годы решать поставленные заказчиком задачи. Линейка оборудования VIDEOMAX вобрала в себя все последние достижения в компьютерной индустрии и оптимизирована для обработки видеопотоков с IP-камер в системах видеонаблюдения.
Впереди еще много полезного для инженеров и проектировщиков систем видеонаблюдения. Зарегистрируйтесь на нашем сайте, чтобы оперативно получать новости о всем самом важном, что происходит на рынке систем безопасности.
Gop потока больше рекомендуемого securos как исправить
Участники! Насколько я слышал существует масса незапароленных IP-камер по всему миру. И есть возможность подключатся и даже управлять(. ) ими через некий софт, а не просто смотреть в инете. Какие предложения? Поделитесь советом!
Может помочь вам в оказании следующих услуг:
1. Монтаж и техническое обслуживание автоматической системы охранно-пожарной сигнализации (АСПС);
2. Монтаж и техническое обслуживание автоматической системы пожаротушения (АСПТ);
3. Монтаж и техническое обслуживание системы внутреннего противопожарного водопровода (ВППВ);
4. Техническое обслуживание системы дымоудаления (ДУ);
5. Монтаж и техническое обслуживание системы оповещения и управления эвакуацией людей при пожаре (СОУЭ);
6. Монтаж и техническое обслуживание системы контроля и управления доступом (СКУД);
7. Монтаж и техническое обслуживание домофонов;
8. Монтаж и техническое обслуживание шлагбаумов и автоматики ворот;
9. Монтаж и техническое обслуживание системы видеонаблюдения;
10. Изготовление планов эвакуации;
11. Изготовление исполнительной документации;
12. Определение категории помещения по взрывопожарной и пожарной опасности;
SecurOS Lite — Бесплатная полнофункциональная редакция системы видеонаблюдения на 32 IP-камеры с неограниченной глубиной архива
SecurOS Lite – лучшее решение для организации видеонаблюдения в небольших офисах, в розничных магазинах, в детских и образовательных учреждениях, в частных домах и квартирах. Система, созданная с использованием ПО SecurOS Lite, может быть легко расширена до уровня систем SecurOS Xpress, SecurOS Professional, SecurOS Premium.
Скачиваем дистрибутивы установки SecurOS Lite
securos-lite-9.6-r2.zip SecurOSLite_10.0_R1_ISS
SecurOS_WebView_10.0_R1_ISS WebConnect новый веб-клиент с поддержкой воспроизведения H.264 видео средствами HTML5
SecurOS_EvidenceManager_10.0_R1 плеер экспортированного видео
ONVIF Device Manager is a Network Video Client (NVC) to manage Network Video Transmitters (NVT), Network Video Storage (NVS) and Network Video Analytics (NVA) devices. Implements Discovery, Device, Media, Imaging, Analytics, Events and PTZ services. https://sourceforge.net/projects/onvifdm/
1) конфигурирование сетевого интерфейса; 2) обнаружение устройств по протоколу WS-Discovery; 3) управление профилями работы камеры; 4) настройка поточной передачи медиа-данных; 5) обработка событий; 6) управление приводом купольной камеры (PTZ); 7) видеоаналитика (видеоанализ); 8) защита (управление доступом, шифрование).
Ролью сервера securos или места оператора монитора securos, язык
Настроить с помощью Мастера первого запуска Securos 
Просмотр лицензий Securos 
Супер пользователь системы securos root 
Создание пользователей в Securos 
Укажите доступные диски для записи архива Securos (одна ip камера в среднем создаёт 30-40Гб видео за 24 часа при режиме full hd 1080,цветной и вечером ч/б) 
Добавление и конфигурирование ip Устройств — добавляем камеры 
Добавление рабочего места оператора Securos 
4)После запуска зажимаем клавишу CTRL наводим курсором в верхний правый угол экрана и нажимаем кнопку параметры как указано на изображении ниже. В выпадающем меню выбираем создать устройство видео захвата. 
В параметрах создаваемого объекта указываем, название устройства, тип ONVIF, Модель default. (или Generic RTSP, iss и ссылку на видео поток берем из ONVIF device manager)
На камере можно создать Световой детектор\Детектор расфокусировки
Создание пользователя для места оператора
Панель управления\Система и безопасность\Брандмауэр Защитника Windows — выключить или добавить video.exe в разрешенные
Неплохие Китайские камеры KingCam 4MP Security Audio IP Camera Metal Anti-vandal 48V POE Wide Angle 1080P ONVIF CCTV Surveillance Dome Microphone IP Cam
Пример: необходимо вычислить объём HDD для записи видео в течение 2-х недель с 3-х камер с разрешением 1280×960 px и частотой 25 кадров в секунду. При этом, запись будет осуществляться по 10 часов в сутки. Делим объём архива с камеры за сутки на 24 часа и умножаем на 10 часов: 31 Гб/24 часа*10 часов=12,9 Гб. Получается почти 13 Гб в сутки. Затем умножаем 13 Гб на количество дней (14 дней) и на количество камер (3 шт.). Получилось 546 Гб. Соответственно, в нашем примере понадобится HDD на 1000 Гб.Следует учитывать, что реальный объём HDD немного меньше заявленного производителем 10Тб = 9313Гб ;
raid calc https://planetcalc.ru/4215/
Средняя цена диска 10Тб на 2019г 24900руб
| Разрешение, px | 1 кадр/сек | 5 кадров/сек | 10 кадров/сек | 15 кадров/сек | 20 кадров/сек | 25 кадров/сек |
| 352*288 (CIF) | 0.2 Гб | 0.8 Гб | 1.3 Гб | 1.7 Гб | 2.3 Гб | 2.7 Гб |
| 704*576 (D1) | 0.8 Гб | 3 Гб | 5.1 Гб | 7 Гб | 8.8 Гб | 10.4 Гб |
| 960*576 (960H) | 1.1 Гб | 4.1 Гб | 7 Гб | 9.7 Гб | 12 Гб | 14.2 Гб |
| 1280*720 (HD 720p) | 1.8 Гб | 6.6 Гб | 11.5 Гб | 15.9 Гб | 19.5 Гб | 24.3 Гб |
| 1280*960 (1.22 Мп) | 2.4 Гб | 8.8 Гб | 15.9 Гб | 21.2 Гб | 26.5 Гб | 31 Гб |
| 1920*1080 (HD 1080p) | 4.1 Гб | 15 Гб | 26.5 Гб | 35.8 Гб | 46 Гб | 53.1 Гб |
| 2048*1536 (3 Мп) | 6.2 Гб | 23 Гб | 39.8 Гб | 54.4 Гб | 69 Гб | 81.8 Гб |
SecurOS Lite — Бесплатная полнофункциональная редакция системы видеонаблюдения на 32 IP-камеры с неограниченной глубиной архива : 2 комментария
Приветствую! Есть ли возможность расписать, как настроить рабочее место? Установил на компе, через расширенную установку, рабочее место, но при попытке подключиться по IP к компу, где стоит сам сервер видеонаблюдения, пишет что Ошибка подключения. Комп в сети видится.
Добрый день. Полгода назад установил и настроил себе SecurOS Lite, все работало стабильно, но недавно при запуске появилась проверка лицензии и соответственно ошибка после того. Есть какой-то период действия или для SecurOS Lite тоже нужна лицензия?!
Как ускорить работу микросервиса с помощью многопоточности, асинхронности и кэша: пошаговая инструкция (FastApi, Redis)
To Destination by BisBiswas
Микросервисная архитектура звучит неплохо само по себе, но еще лучше — быстрый микросервис, который эффективно использует ресурсы сервера.
Я покажу, как последовательно применять к простому без затей микросервису методы ускорения его работы, попутно рассматривая плюсы и минусы каждого из них.
Посмотрим, как можно распараллелить работу микросервиса, распределив нагрузку в несколько потоков, увеличить производительность с помощью асинхронного исполнения и ускорить работу при помощи кэша.
Перечисленные способы подходят только для программ, написанных на Python 3 + FastApi, это не универсальные способы ускорения любых микросервисов. И, конечно, здесь описаны основные методы, выбор лучшего варианта — за разработчиком в зависимости от ситуации.
Статья подготовлена командой облачной платформы Mail.ru Cloud Solutions.
Что я буду использовать
Для корректной работы микросервисов, о которых я говорю, нужен только Docker Compose — они уже упакованы в Docker-контейнеры. Благодаря этому любой микросервис можно легко развернуть не только на локальной машине, но и в облаке на VPS/VDS. Клиент для проверки скорости работы написан на Python 3 с использованием asyncio и HTTPX. В качестве данных для примера я использовал прогноз погоды с pogoda.mail.ru.
Примечание: можно было бы не парсить данные, а использовать открытый API, например openweathermap.org. Но тогда бы пришлось проходить регистрацию и получать API-ключ. В текущей реализации это не требуется — все будет работать сразу.
Для проверки скорости работы микросервисов я использую клиент, который асинхронно отправляет запросы для трех различных городов, а в конце выводит общее время работы и среднее время на один запрос. Он будет посылать 18 запросов: сервер pogoda.mail.ru банит на 10-20 секунд, если отправить больше 20 запросов подряд.
Для проверки 18-ти запросов нам хватит. Но даже если бы мы использовали API openweathermap.org, то не смогли бы послать более 60 запросов в минуту (см. Free Subscription). То есть числа вполне сопоставимые.
Шаг 1. Разворачиваю простой микросервис
Все файлы простого микросервиса находятся в папке 1-simple-microservice. Исходный код микросервиса — в файле simple-microservice.py, он построен на веб-фреймворке FastApi.
На вход микросервис принимает название города, в главном потоке делает запрос на внешний ресурс, парсит температуру в городе и возвращает результат работы. Это базовый микросервис, который мы будем дальше ускорять.
Результат работы клиента:
Итого получаем, что простой микросервис отработал в общей сложности 1.22 секунды, а на один запрос потратил в среднем 0.07 секунд.
Шаг 2. Добавляю в микросервис многопоточность
Примечание: еще можно было бы использовать Nginx-балансировщик, пример — здесь.
К плюсам данного подхода можно отнести простое внедрение, к минусам — линейный рост потребления ресурсов. Например, если один микросервис потреблял 100 MB памяти, то, работая в три потока, он задействует не менее 300 MB. Потребление можно снизить, если расшарить ресурсы между потоками, например как показано ниже, использовать общий для всех потоков кэш.
Результат работы клиента:
Прирост скорости по сравнению с простым микросервисом есть: общее время работы — 1.15 секунд, среднее время одного запроса — 0.06 секунд. Тут нужно уточнить, что на работу балансировщика требуется время, и если микросервис сам по себе быстрый, то выигрыш будет небольшой. Но если микросервис тяжелый, прирост скорости будет заметнее.
Шаг 3. Добавляю асинхронное исполнение
В обычной программе, когда процесс в исполняющем потоке доходит до места, где требуются внешние ресурсы, он блокирует исполнение, ожидая ответа. При асинхронном исполнении программы исполняющий поток занят другим процессом — за счет этого и увеличивается производительность.
Исходные файлы микросервиса — в папке 3-async-few-threads-microservice. Для создания микросервиса мы изначально взяли веб-фреймворк FastApi и веб-сервер Gunicorn, который использует ASGI-воркер Uvicorn. Значит, для асинхронного исполнения достаточно пометить асинхронные методы ключевым словом async и реализовать в них операции, требующие ожидания await.
В нашем случае мы обращаемся за прогнозом погоды — это наша await операция. Основной плюс этого подхода в том, что он позволяет эффективнее использовать ресурсы, к минусам можно было бы отнести бóльшую сложность реализации, но с FastApi это не так.
Результат работы клиента:
Скорость работы снова выросла: общее время выполнения — 0.88 секунд, среднее время выполнения одного запроса — 0.05 секунд. Асинхронное исполнение в связке с FastApi дает хороший прирост производительности при минимальных затратах. Этот подход следует использовать везде, где есть обращение к внешним по отношению к потоку исполнения ресурсам, например к внешним API и базам данных.
Шаг 4. Добавляю к микросервису кэш
При использовании общего ресурса в многопоточном приложении резонно возникает вопрос синхронизации доступа к данным. Начиная с версии 4 Redis стал более многопоточным, не говоря уже о более свежем Redis 6. Из-за этого не сразу понятно, можно ли посылать в кэш несинхронизированные запросы.
На самом деле, интерфейс доступа к данным внутри ядра Redis остался однопоточным (пруфы здесь). Значит, сколько бы команд на запись/чтение мы не послали, они выполнятся строго последовательно.
Redis — in-memory data structure store, он хранит данные в оперативной памяти. И благодаря этому имеет колоссальную производительность (даже на сервере начального уровня от 100 тысяч get/set запросов в секунду, подробнее — здесь) и часто используется для реализации кэша.
Как и все вариации микросервисов, я сконфигурировал Redis для работы в качестве кэша и упаковал его в Docker-контейнер. Рассмотрим подробнее настройки, которые я добавил в файл redis.conf:
Примечание: скачать дефолтный пример redis.conf можно отсюда, там же есть рекомендации по настройке Redis в качестве кэша.
Тут нужна оговорка: хотя кэш может сильно ускорить работу микросервиса, в некоторых случаях его невозможно применять, например если при каждом запросе нужны только актуальные данные. В данном примере реализована схема, при которой прогноз погоды (температура в городе) будет храниться в кэше 1 час. Для подобных данных это нормально, так как они не сильно меняются за это время.
Файлы микросервиса — в папке 4-cache-async-few-threads-microservice. В реализации ничего сложного нет: сперва читаем кэш из памяти, если он есть — отправляем данные, если нет — делаем внешний запрос и обработку ответа. Затем кладем полученные данные в кэш на 1 час и возвращаем ответ. Имплементация запросов на чтение и запись — асинхронная. Как говорилось выше, в данном случае кэш — это внешний ресурс.
Dockerfile (добавил только aioredis для асинхронного чтения/записи в Redis):