А вот теперь смотри раскадровку того, что ты назвал - "на нормальных серверах можно писать хоть по какому дд".
Первое, то что ты назвал "бликами на машине", на самом деле с точки зрения ДД есть просто - медленно движущийся объект с размерами приблизительно 15 на 15 писклей (при Full-HD).
Ну а потому, второе см. на комиксах
Т.е. в течении 7 секунд ДД второго потока не привел к записи движущегося объекта в 15х15 пикс (хотя всего скорее и сработал).
Затем он (ДД-второго) всё же сделал запись в пару секунд потому что дельта между временем GOP-а в временем сработки тупо случайно совпала.
Ну а затем, запись по второму ДД, снова померла, аж на 12 секунд
Итого делаем не утешительный вывод:
- Для того чтобы, программный детектор движения по второму потоку, стал бы полностью эквивалентен программному детектору движения по первому, у которого при этом еще и отключена пред и пост запись и порожняка типа "нет", придется как минимум на канале с записью по ДД от второго потока, включать пред и пос запись по 15 сек каждая, что всего лишь после 120 сработок ДД, приведет к лишнему часу пустопорожней записи!!!
3600/(15+15)=120 сработок
PS
И заметь: - это ты еще не сравнил пустопорожность записи с двух программных ДД,, - с записью по нативному ДД от самой камеры.
