Потеря кадров 32ch регистратором NBD7024H-P

[bAG79]

дык NTP на камерах то выключен. Камеры время от рег получают

[Тюрин ВВ]

Несколько раз сталкивался с похожей проблемой в некоторых ШЗ-камерах и чаще всего это было связано с разницей числа fps на основном и второстепенном потоках что существенно увелиыивало нагрузку на ОЗУ и ЦП ШЗ-ВК.
Ну а судя по вашему скрину

в Вашем варианте настройки DVR именно так и есть.
Попробуйте для начала привести fps на обеих потоках к единому "знаменателю".
Ну а касаемо почему

Да и правда чем не нормальна половина от 30? Не пал, но нтсц, и что?

Тут причин несколько:
1) для предотвращения биений (т.н. flickering), кратность fps по отношению к частоте электро сети, должна быть целым числом без остатка.
2) опять же, для снижения нагрузки на ЦП и ОЗУ, желательно что бы величина gop так же была кратна целому числу относительно величины fps (в вашем же случае величина gop на основном потоке 15/2, gop на субпотоке 10/2).
3) самое банальное в том, что при длительной записи 15 fps, тупо "съедают" больше дискового пространства чем 12 fps.

Удачи.

[Тюрин ВВ]

дык NTP на камерах то выключен. Камеры время от рег получают

Ну а сам-то DVR, синхронизацию хоть с каким-либо NTP имеет? Или же он работает сам по себе, т.е. как Бог и батарейка на душу положат, ну а следовательно - и крутит время в камера так, как ему вздумается?
?(

[bAG79]

Нет ну не до такоей же степени) конечно, в регистраторе влючен соответствующий сервис и он имеет право общаться с инетом по udp/123 и udp/53 и более ничего.
??????????? КАКАЯ ЧАСТОТА ЭЛЕКТРОСЕТИ???????? у цифры....
Не думаю что полные прокисания камеры связаны с разным знаменателем на опорных кадрах. Но прикола ради попробую сменить

[Тюрин ВВ]

Нет ну не до такоей же степени) конечно, в регистраторе влючен соответствующий сервис и он имеет право общаться с инетом по udp/123 и udp/53 и более ничего.

Тогда стоит последить именно за точностью хода часов самого регистратора (в моей практике были случае при которых DVR при дохлой батарей синхронизируясь раз в сутки, успевал в течении суток поменять время в синхронизируемых камерах.

??????????? КАКАЯ ЧАСТОТА ЭЛЕКТРОСЕТИ???????? у цифры....

Ну видимо аналоговая, величиной в полста Герц

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

Возможно что и не связанно, но подобные инциденты, как я уже сказал выше, бывали в моей практике.
Правда бывали еще и проблемы с тем, что в браузерном окне поток с камер принимался в TCP без пропусков дельта кадров, а вот в DVR по UDP с потерями и чаще всего с потерями ключевых.

[bAG79]

Это как это у вас DVR по UDP заработал?

[S@rge]

Тут причин несколько:
1) для предотвращения биений (т.н. flickering), кратность fps по отношению к частоте электро сети, должна быть целым числом без остатка.
2) опять же, для снижения нагрузки на ЦП и ОЗУ, желательно что бы величина gop так же была кратна целому числу относительно величины fps (в вашем же случае величина gop на основном потоке 15/2, gop на субпотоке 10/2).
3) самое банальное в том, что при длительной записи 15 fps, тупо "съедают" больше дискового пространства чем 12 fps.

Удачи.

Допустим, но разве 50Гц делятся на предложенные VirtualLink 12fps без остатка?

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

Так это ж суть UDP - во избежание задержек не контролировать порядок и целостность пакетов, а отображать как есть то что пришло. Видимо, канал между DVR и ПК хреновый.

[Тюрин ВВ]

Это как это у вас DVR по UDP заработал?

Да как-то вот так


Другой вопрос что это не Ваша модель и даже не Ваш бренд DVR.

[Тюрин ВВ]

Тут причин несколько:
1) для предотвращения биений (т.н. flickering), кратность fps по отношению к частоте электро сети, должна быть целым числом без остатка.

Допустим, но разве 50Гц делятся на предложенные VirtualLink 12fps без остатка?

А с какой частотой по вашему мнению, мерцают электролампы запитанные от электросети в 50 Гц?

https://www.youtube.com/watch?v=XkeccjB1sA8

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

Так это ж суть UDP - во избежание задержек не контролировать порядок и целостность пакетов, а отображать как есть то что пришло. Видимо, канал между DVR и ПК хреновый.

1) UDP, никак не влияет на возникновение задержек (если конечно под задержками не Вы не имеете ввиду джитер, который вообщем то на передачу видеопотока никак особо не повлияет).
2) А вот потери UDP не гарантирующих доставку пакетов, будут даже на не хреновой сети между DVR и ПК в том случае, если ваш DVR входящий UDP поток от IP камер, принимает по ОДНОЙ единственной сетевой карте, а вот исходящий поток будет передавать по средствам всё того же единственного лан порта, НО (!!!) на большое количество УРМ в TCP. И вот тут Вам без внешнего стриминга исходящего потока - никак не обойтись.

Удачи.

[S@rge]

А с какой частотой по вашему мнению, мерцают электролампы запитанные от электросети в 50 Гц?

Люминесцентные лампы мягко говоря не везде установлены.

1)Я про задержки на установление соединения и запросы на повторную отправку недошедших/битых пакетов.
2)Это проблема железа, а не протокола. Если оно не тянет, при TCP тем более плавной картинки не получить - на видео будут задержки/замирания.

[Тюрин ВВ]

Люминесцентные лампы мягко говоря не везде установлены.

Ok, базара ноль, с какой частотой мерцает лампа накаливания?
https://cloud.mail.ru/public/Ghdf/Ck5CVoQ27
Ну а теперь, в свете пары просмотренных роликов, то:
- А как бы Вы теперь прокомментировали работу, ну скажем банального детектора движения камер у которых fps=15? И это, даже не затрагивая проблем сжатия, проблем увеличения объема хранилища и всего лишь при 15fps НО (!!!) при искусственном освещении на европейской части суши.

2)Это проблема железа, а не протокола. Если оно не тянет, при TCP тем более плавной картинки не получить - на видео будут задержки/замирания.

Касательно "железа" - ну а много ли Вам известно железа, имеющего на борту два честных лан-порта? Только не надо приводить в прим разные убожества типа два в одном (двр+хаб в одном флаконе).
Касаемо протокола - то как раз, если ваш входящий будет UTP-юникас, но и исходящий трафик с одного единственного лан-порта двр будет так же UDP, то множественное количество исходящих подключений будет в меньшей степени влиять на качество входящего подключения.
Ну а если Вам ко всему прочему, каким-либо чудодейственным образом удастся организовать с "двр железяки" еще и исходящий UDP-мультикаст, то сколько бы у вас не было подключенно УРМ - но исходящий трафик уже влиять на входящий не будет от слова ни как.
Ну и касательно "задержек": - а откуда у вас возьмутся повторные запросы TCP, если сеть у вас как вы говорите "не хреновая"?
Т.ч. удачи всем, в нелегком деле познания тонкостей "цифрового" ССТV.

[GenaSPB]

Диоды с хреновыми драйверами тоже мерцают ой как.