Рандомные зависания картинок при онлайн-просмотре

[HerrWankel 0]

Сервер ubuntu 20.04. 50 камер. 2 интерфейса по гигабит в разные сети, 2 xeon, 64 RAM ,Raid 5. Загрузка сервера меньше 30%,  дисков почти нулевая, канала не более 150мегабит.

Это установлено взамен железного сервера keno на 128 каналов, сразу скажу подобных проблем не наблюдали, чтобы не валить на камеры или сеть.

Клиенты виндовс.

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

Независимо от аппаратной части рабочего места или количества открытых камер.

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

Здравствуйте!
Убедитесь, что в настройках подключения IP-камеры к каналу «Линии» используется опция «TCP». 

 

Цитата

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

 

При постоянной записи в архив описанная ситуация так-же наблюдается? 

[HerrWankel 0]

Прошла неделя. 

Абсолюно точно на постоянных потоках есть замирания и при просмотре и воспроизведении.

Это конечно никуда не годится.

Руководство уже на грани хочет вернуть эту поделку.

Сервер не нагружен вообще, сети тоже - и везде гигабит

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

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

Хорошо, прошу Вас ответить подробно по каждому пункту отдельно: 

1.) Проблема только на клиентских рабочих места, как указанно в первом сообщении, или на сервере тоже? 

2.) Проблема при просмотре онлайн или в архиве при постоянной записи тоже? 

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

 

Если  на сервере в «Линии» проблема наблюдается, а в VLC нет - необходимо будет обеспечить удалённый доступ к серверу. 

Так-же прошу Вас прислать сбор сведений о системе с сервера (sudo /opt/line/bin/sysinfo) личным сообщением . 

[HerrWankel 0]

1) проблема на нескольких рабочих местах. Посмотреть на самом сервере нет возможности. Там минимальный интерфейс и воткнуть его некуда.

2) Просмотрел сейчас эпизоды которые пометил у себя начохраны - на записи скачков нет.  (Достаточно сложно добывать информацию когда люди в на эмоциях). Скачки только на клиентах и рандомно - может быть долго всё плавно и неожиданно замереть  - на одной камере - на остальных нормально. То же самое если увеличить одну камеру - не факт что сразу заморозится, можно долго в неё глядеть до этого.

3) собстенно ответ выше -на записи ок. 

 

Upd: по записи мне не подтвердили и лично не нашёл.

А при онлайн просмотре - даже если одну камеру вывести - замирание на секунды - потом картинка резко перепрыгивает.

Основной поток в том числе, и при постоянной записи. 

Не имею возможности лично сидеть на охране и включать эти потоки. Но на записи видимо ровно, я доказательств не нашёл. 

 

 

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

Спасибо за уточнения!

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

Из лога ядра «Линии»:     

Oct 24 02:45:09 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.226/H264?ch=1&subtype=1&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 02:45:23 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.227/H264?ch=1&subtype=0&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 02:47:02 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.49/H264?ch=1&subtype=0&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 02:47:24 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.49/H264?ch=1&subtype=1&proto=Onvif: Нет маршрута до узла (0xffffff8f)
Oct 24 02:47:48 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.22.60/H264?ch=1&subtype=1&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 02:49:01 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.59/H264?ch=1&subtype=0&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 02:50:05 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.30/H264?ch=1&subtype=0&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 02:50:18 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.30/H264?ch=1&subtype=0&proto=Onvif: Нет маршрута до узла (0xffffff8f)
Oct 24 02:50:58 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.22.19/H264?ch=1&subtype=1&proto=Onvif: В соединении отказано (0xffffff91))
Oct 24 02:51:17 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.22.19/H264?ch=1&subtype=0&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 02:51:29 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.225/H264?ch=1&subtype=1&proto=Onvif: В соединении отказано (0xffffff91)
Oct 24 03:53:47 newvideo kernel[1013086]: [outer_source] failed to open avformat input for rtsp://192.168.25.214/H264?ch=1&subtype=1&proto=Onvif: В соединении отказано (0xffffff91)

Лог забит подобными сообщениями. При этом, для получения описанной Вами ситуации достаточно потери одного опорного кадра, тем более если используется H.265 или, что ещё хуже,  H.265+ H.265 smart и тому подобные "оптимизации". 

 

Сейчас потребуется  следующее: 

1.) Запись видео с экрана рабочего места (что-то типа Bandicam достаточно), на котором видно: саму проблему + время/дата + пинг до сервера + загрузку процессора/сети/оперативной памяти/GPU. 

2.) Сбор сведений о системе, сделанный позже обнаружения проблемы,  с этого клиентского места и с сервера. 

3.) Экспорт с архива этого фрагмента в «Оригинал» 

4.) При провалах в пинге в время возникновения проблемы: потребуются подробные комментарии системного администратора + попробовать отключить одну сетевую карту на сервере и повторить без неё. 

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

[HerrWankel 0]

16 часов назад, Станислав сказал:

достаточно потери одного опорного кадра

Мы прекрасно знаем, что при потере опорного кадра совсем другая картина. Размазанное инкрементарное видео до следующего опроного.

А тут конкретно потеря 50-60 кадров, а в логах единицы и не подряд. Что я могу сделать - увеличить частоту опорных кадров на камерах и пусть мониторят что вышло. Могу сделать h264 на них и без плюсов.

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

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

 

Что мне говорят - проблемы могут быть на всех камерах независимо от качества потока в настройках.

Можно ещё попробовать сделать рабочее место под убунтой - есть смысл?

UPD: то что в логах вы увидели - это 2:50 - перезагрузки камер по расписанию

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

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

Мне нужна информация по пунктам, описанным выше. 

Гадать сейчас ни к чему, я вижу что проблема  есть и хочу её локализовать. 

 

Цитата

Можно ещё попробовать сделать рабочее место под убунтой - есть смысл?

 

Это никак не поможет решить вопрос стабильности потоков с IP камер. 

 

Цитата

UPD: то что в логах вы увидели - это 2:50 - перезагрузки камер по расписанию

 

Возможно, я поэтому и хочу уточнить и по 02:50 и по 02:45 и по 03:53

[HerrWankel 0]

Я тоже пытаюсь её решить, поскольку на меня кажут пальцем что я это купил.

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

02:50 и по 02:45 и по 03:53 - это совершенно точно перезагрузки камер по расписанию. 

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

Удивило кстати, что при выставленных у на камерах 20к/с в админке сервера написано захват 25 кадров. - Ладно, я тоже выставил 25 и на камерах чтобы отмести вероятные проблемы.

 

 

[HerrWankel 0]

Так, должен отрапортоваться - после того как подключил сервер к zabbix и получил полную статистику загрузки - обнаружил что один из интерфейсов, торчащих в 48-портовую poe-циску стал на 100 мегабит. Там загрузка была 90%. Пересадил в гигабит, плюс перевёл всё что можно на h265 . В итоге ситуация значительно улучшилась. Есть подтормаживания но не критично короткие и редкие. Клиенты же сидели на другом свободном гигабите.

Охранюги свыклись и уже довольны.

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

 

Есть другой вопрос, напишу его тут чтобы ветки не плодить:

 

Странным образом 2 раза откатывались системные настройки. Просто пропал созданный работавший пользователь и вдруг изменился адрес у одной камеры на старый (заменняли недавно). Похоже это связано как-то скэшем админского приложения или с запущенным рабместом с админскими правами (в просмотре) на другом месте. Есть над чем поработать. И не нашёл резервирования настроек - наверняка где-то есть - подскажете? (сервер linux)