Общие настройки

[Tm174 0]

Станислав, здравствуйте!

На объекте есть разных годов выпуска (2014-2016 в основном) ip камер Dahua. Походу китайцы. Некоторые из них работают нормально, на некоторых почему-то в архивах проскакивают кратковременные фризы, разрешение камер 1920х1080, 20 к/с, есть где 15 к/с. Запись в Линии установлена по детектору. Версия на сервере стояла 7.3.1, обновил до 7.4.0 Разницы особо не заметил. Суммарный поток с камер не превышает 35 мбит/с, нагрузка на процессор 20-35% в среднем. Установлены 2 HDD по 1 ТБ, 7200 rpm. Камеры распределены группами.  С железом проблем нет - всё стабильно.

Может есть какие-либо общие рекомендации или оптимальные настройки для этого семейства камер (типа настройки ключевых кадров - по умолчанию камера ставит так: если 20 к/с то ключевой кадр 40; потока cbr или vbr - что лучше для них?; и пр. или тут всё индивидуально нужно делать-и-смотреть как будет?) 

[Станислав 0]

Здравствуйте!

Как правило,  причина подобного поведения или в настройках/прошивках IP камер или в камерах (питание/перегрев) или в нестабильности сети/проблемах с сетевым оборудованием. Попробуйте CBR и увеличить количество опорных кадров. 
Попробуйте подключить RTSP ссылками (ссылки можно посмотреть на вкладке "Информация" в самой "Линии") . Если ситуация повторяется или появились рассыпания - проконтролируйте параллельно стабильность потока с этих же ссылок в VLC. VLC можно с этого сайта http://www.videolan.org/vlc/index.ru.html , после установки и запуска нажмите "Медиа" - "Открыть URL" - "Сеть" и вставив RTSP ссылку в поле нажать "Воспроизвести".

 

Если в VLC поток качественный, а в "Линии" разительно отличается,  нужен  удалённый доступ к серверу с помощью ПО TeamViewer 8|9 ( www.devline.ru/soft/ds.exe ) - укажите данные для подключения личным сообщением.

[unlifer 0]

Tm174, здравствуйте.

А какое кодирование на камерах используется MJPEG или H264?

Какое сетевое оборудование установлено на всём протяжении видеопотока (от камер до сервера)?

У меня, если я правильно понял, были такие случаи. Решалось двумя действиями: 1. переводом кодирования с MJPEG на H264 и \ или 2. заменой сетевого оборудования на более производительное.

Так, к примеру, стоял в одном месте вполне хороший и производительный для работы в офисной среде управляемый коммутатор серии Smart (модель сейчас не вспомню) через него проходили потоки с 12 камер с кодированием MJPEG с разрешением 1080p на 25 кадров на битрейт в 3000 с чем-то + до сервера ещё ряд коммутаторов стоял, более производительных D-Link и Evidence. К этому же коммутатора подключены были около 20 компьютеров + проходил поток он-лайн изображений от сервера до клиента (охранника). Так на камерах постоянно артефакты возникали (он-лайн и в архиве) + были большие потери пакетов при пинге, доходило до 10% + в итоге этот коммутатор приказал долго жить. При рестарте коммутатора пинг был хороший (видимо, пока Линия с камер не начинала потоки снимать), потом быстрыми темпами потери росли до 100%, и вся сеть в этом сегменте ложилась напрочь. При замене на подобный же коммутатор - те же потери в 5-10% и артефакты. Решилось тем, что пустил по оптике пассивным оборудованием (кроссирование патч-кордами) минуя данный коммутатор. Больше проблем нет. Тьфу-тьфу-тьфу

[Tm174 0]

Здравствуйте, коллеги,

спасибо за Ваши советы!

Сейчас прописал везде в Линии забирать потоки с rtsp, все камеры пишут в h.264 (есть ещё профили этого же кодека h.246b и h.264h - переключался между ними - особо разницы не заметил), в итоге вернул на обычный - без  приставок. Из сетевого оборудования: 2 свича L2 (D-link, расположены в разных зданиях), между ними оптика, 1Гб/с (через sfp), "медные" порты - на 100 мбит/с у обоих. Сервер подключен в первый такой коммутатор, камеры - во второй. До камер идёт экранированная уличная витая пара. Смотрел по потерям - пинг ровный, 1-2 ms в среднем. Помимо камер через эти коммутаторы включена локалка (ПК пользователей и пр.). Может нужен гигабит, сотки мало? Поток на камерах были 4 мбит/с, увеличил сегодня до 8 мбит/с - понаблюдаю как будет теперь. Также попробую ещё cbr. Сделал скрин того, как выставлено сейчас.      

unlifer, 

Как у Вас на объектах организовано питание до самих камер - по витой паре (по свободным жилам), по PoE или отдельный кабель?

[unlifer 0]

Цитата

Из сетевого оборудования: 2 свича L2 (D-link, расположены в разных зданиях)

L2 - это уровень функционала коммутатора, и он пока ни о чём не говорит, желательно бы модель.

Цитата

Смотрел по потерям - пинг ровный, 1-2 ms в среднем

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

Цитата

Может нужен гигабит, сотки мало?

Для камер сотки достаточно, а вот для сервера под вопросом - если камер порядка 20-25, то может и хватить, но гигабит всегда лучше. Если есть возможность задействовать ещё одну жилу оптики без дополнительных вложений (максимум обойтись покупкой 2 sfp-модулей), то лучше бы задействовать обе, включив соответствующие порты в транк.

Цитата

Как у Вас на объектах организовано питание до самих камер - по витой паре (по свободным жилам), по PoE или отдельный кабель?

В основном по PoE, ибо современным камерам достаточно питания и для работы, и для предпускового подогрева, и для ИК.

Есть старые уличные камеры с разборными термокожухами, к ним подходит и 220~ и PoE - от 220 питаются термокожухи, камеры от PoE. Сделал так, чтобы при косяках с электричеством, оборудованием или каналом связи потом камеры можно было перезапустить по PoE. Есть правда пара камер, на которых PoE-контроллер вышел из строя, поэтому питаются от блока питания термокожуха.

Есть несколько камер на первых домах микрорайона, к которым 12В подаётся по витой паре от БП 12В (как зарядки на телефон), расположенных в том же месте, что и коммутаторы. В подробности не вдавался, но, скорее всего, на них PoE-контроллеров и в помине нет. Пару таких камер заменил на почти аналогичные, но с PoE уже.

Есть камеры, которые питаются по витой с использованием PoE-инжекторов.

Короче говоря, какой подрядчик до чего додумался (на что горазд), то и ставит.

Я на строительных площадках ставлю уличные БП PV-DC2A+, так как камеры аналоговые, а на купольные камеры ставлю уличные БП Scat - VN24\27.

 

ПС. С утра у меня голова получше заработала Поэтому я тут подумал - а правильно ли я Вас понял!? Может я фризы с артефактами перепутал. Скриншот бы. Если под фризами понимается, например - едет машина, а за ней идёт след, как на картинке внизу, то это уже другое решение, не связанное с сетевым оборудованием. Обычно такое происходит ночью и \ или в местах с плохим освещением.

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

Шумоподавление 3DNR - ставим на минимум, выключать совсем не надо, хотя при очень сильных проблемах с освещением приходилось и полностью выключать.

Выдержка, и в ней либо максимальное усиление - играемся с ним, либо выбор приоритета (накопления заряда или частоты кадров - выбираем первое).

Расширенный динамический диапазон - выключаем.

[Tm174 0]

Идея что-то исключить из цепочки (для проверки хотя бы) и сделать схему проще уже приходила в голову. Хочу попробовать убрать один коммутатор, поставить вместо него медиаконвертер и sfp с гигабит lan, собрать все шнурки через обычный неупр. 8-16 портовый гигабитный свич. На др. конце также получить линк с медиаконвертера и подать сразу на одну из сетевых сервера. Сами фризы выражаены как мелкосрочное рассыпание картинки. Замедлил одну из записей в архиве средствами самой Линии. (Скрин - типа идёт человек). Настройками вроде играл всяко - не помогло особо. Происходит в разное время, не зависимо от освещения и пр. Проверю ещё всё таки сетевое оборудование. Если и с ним тоже всё норм. Значит камеры - ПО камер - раз китайцы, всего можно ожидать думаю. Модели коммутаторов D-Link DES-1228. Спасибо за ценные мысли!