"Дубовый" датчик движения - что делать?

[Tюрин BB]

Писать надо все ...

Согласен.

Бля, как же вы достали с вашими качественными оценками ваших таймлапс шоу - которые вы постоянно выдает за "качественное видео" наблюдение.
Кому нах нужны ваши статичные Н265+ при разборке полетов?
Какой толк от ваших мегапикселей и терабайтов статичных фотографии без каких-либо происшествие, если вы при этом обещали своему заказчику сделать систему ОХРАННОГО ВИДЕО, да еще и тем более даже не просто видеонаблюдения, а ВИДЕО-ЗАПИСИ, при которой, когда доходит до дела - то выясняется что, кроме кубизма, да еще и с тремя фазами движения за секунду, ваша система ничего другого и не записала?!!!!!

[AlienP666]

Как бы не настраивали движение на улице, ложных сработок будет очень много. ИМХО на улице лучше делать одновременную запись на движение и на постоянную.

[Tюрин BB]

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

[Рустам]

Какой толк от ваших мегапикселей и терабайтов статичных фотографии без каких-либо происшествие, ...

Редкий ДД замечает перемещение объектов меньше 8 пикселей диаметром. Многие ДД не замечают движение даже объекта в сотню пикселей при его маленьком контрасте. Так что это не только "статичные фотографии" пишутся ...

[Tюрин BB]

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

[kROOT]

При наличии движения 265+ дает нормальный битрейт без всяких кубиков. Если будет постоянное движение, то и ДД будет постоянно писать и не сэкономишь место на диске.
На статике трафик идет примерно 90 Мб в час или 65 Гиг в месяц, это плата за то, чтобы быть уверенным, что мы ничего не пропустим. 65 гиг это много?

[Tюрин BB]

При наличии движения 265+ дает нормальный битрейт без всяких кубиков. Если будет постоянное движение, то и ДД будет постоянно писать и не сэкономишь место на диске.

Что в твоем понятии означают вообщем-то пустые слова: - "нормальный битрей", "хорошее качество", "достаточное число fps" и т.д.?

Ты "нормальный битрейт", у БЫТОВОГО 1080Р диска - сколько знаешь?
От 18 Мбит/с и выше!!!
И это всего лишь бытовые 1080-25Р, которые в реальности невозможно даже посмотреть в покадровом режиме, т.к. на всех более менее быстрых фазах движения - будет одна сплошная мазня!
Ну а по поводу ДД, так вот он и не должен ничего экономить, ДД должен как раз при малейшем подозрении на движение абсолютно все качественные параметры записи - задирать до максимума, чтобы затем была возможность ну хоть что-то рассмотреть в записи в том же самом покадровм просмотре и поймать скажем рожу или ГРЗ - пригодные для идентификации и доказательства причастности!!!

На статике трафик идет примерно 90 Мб в час или 65 Гиг в месяц, это плата за то, чтобы быть уверенным, что мы ничего не пропустим. 65 гиг это много?

Ну так помнож на тобой же обещанные 32 канала, а затем ответь - много 65гиг на канал, или мало, да еще и при том битрейте постоянной записи, который ты постоянно называешь "нормальным" с "нормальным" качеством.

[Игорь_Я]

Поковырял я работу ДД на Hi 3518 HD и вот что выяснил, MDU это отдельная программа загружающаяся при включении, использующая общий регистр прерываний, выделяющая пространство памяти в DDR2 и по сути являющаяся компрессором т.е. кодеком, но не для получения картинки, а для фиксации изменений и сравнения их с данными заложенными в регистрах.
Имеет два режима работы:
0: background algorithm
1: frame reference algorithm
Работает с Y компонентой обрезая её снизу на 4 бита, т.е. YCbCr4:2:2
Кодек использует алгоритм Компенсации движения используя при этом Вычисление SAD (суммы абсолютных разностей) о чём уже написано не один десяток статей.
На выходе мета данные которые мы видим в виде разноцветных квадратиков прыгающих по экрану.

[kROOT]

При наличии движения 265+ дает нормальный битрейт без всяких кубиков. Если будет постоянное движение, то и ДД будет постоянно писать и не сэкономишь место на диске.

Что в твоем понятии означают вообщем-то пустые слова: - "нормальный битрей", "хорошее качество", "достаточное число fps" и т.д.?

Ты "нормальный битрейт", у БЫТОВОГО 1080Р диска - сколько знаешь?
От 18 Мбит/с и выше!!!
И это всего лишь бытовые 1080-25Р, которые в реальности невозможно даже посмотреть в покадровом режиме, т.к. на всех более менее быстрых фазах движения - будет одна сплошная мазня!
Ну а по поводу ДД, так вот он и не должен ничего экономить, ДД должен как раз при малейшем подозрении на движение абсолютно все качественные параметры записи - задирать до максимума, чтобы затем была возможность ну хоть что-то рассмотреть в записи в том же самом покадровм просмотре и поймать скажем рожу или ГРЗ - пригодные для идентификации и доказательства причастности!!!

На статике трафик идет примерно 90 Мб в час или 65 Гиг в месяц, это плата за то, чтобы быть уверенным, что мы ничего не пропустим. 65 гиг это много?

Ну так помнож на тобой же обещанные 32 канала, а затем ответь - много 65гиг на канал, или мало, да еще и при том битрейте постоянной записи, который ты постоянно называешь "нормальным" с "нормальным" качеством.

Не ставил камеры на новых процессорах в местах с активным движением, но вот пример самой дешевой 1.3 мп камеры на бюджетном ХМ510 https://youtu.be/zpl9Qc19ye0" onclick="window.open(this.href);return false; (камеру давно не протирали) битрейт исходника 2000-3500 кбит. Много там кубиков? Может у нас разные понятия кубиков и шлейфов?
65 Гб на месяц для любого числа камер мало, хоть на тысячу, поскольку этот объем сравнивается с объемом Н.264 кодека за аналогичное время.

[Tюрин BB]

Поковырял я работу ДД на Hi 3518 HD и вот что выяснил, MDU это отдельная программа загружающаяся при включении, использующая общий регистр прерываний, выделяющая пространство памяти в DDR2 и по сути являющаяся компрессором т.е. кодеком, но не для получения картинки, а для фиксации изменений и сравнения их с данными заложенными в регистрах.

Ну и вывод из всего этого какой?
А вывод простой и озвучил я вам еще "неделю назад" viewtopic.php?p=109919#p109919

PS
И Игорь, небольшой совет: - чтобы Вам было легче разбираться и постоянно не отождествлять квантование амплитуд с пиксельной дискретизацией, т.е. не путать высоту (8-бит минус 4 бита снизу) с шириной (4:2:2), Вам нужно разобраться в чем основные различия цветовых пространств и в том что 4:2:2 это всего лишь снижение частоты дискретизации для цветоразностной компонент (для Y частота выборки - не меняется).
Про все эти нюансы преобразования одного цветового пространства в другое - очень не плохо описаны в доках на фреймсервер avisynth.
Причем у avisynth, есть неплохой плагин, позволяющие как раз таки наглядно визуализировать вектора движения при SAD алгоритмах.

[Tюрин BB]

но вот пример самой дешевой 1.3 мп камеры на бюджетном ХМ510 https://youtu.be/zpl9Qc19ye0" onclick="window.open(this.href);return false; (камеру давно не протирали) битрейт исходника 2000-3500 кбит. Много там кубиков? Может у нас разные понятия кубиков и шлейфов?

Найди в этом видео хоть один кадр и сделай с него скриншот, на котором бы НЕ БЫЛ РАЗМАЗАН и ОДНОЗНАЧНО-бы читался номер хотя бы одного из нескольких автобусов, даже при том, что они останавливаются на остановке.
Вот это и будет критерий качества, поддающегося однозначному показателю с двумя устойчивыми состояниями "качества", читается номер = качество истина, не читается = качество лож.

[kROOT]

читается номер = качество истина, не читается = качество лож.

Прям в любой ситуации? Не зависимо от разрешения, угла обзора, дальности и тд.? Камера ставилась чтобы контролировать вход в магазин, а не автобусы учитывать.