Перейти к содержимому
Калькуляторы

Macroscop/trassir/axxon для загородного дома

10 часов назад, dr Tr0jan сказал:

А зачем её гарантировать в сетях, где нет потерь, т.к. где доставка априори гарантированна сетью???

Я лишь написал что по TCP камеры лучше работают, а вы пытаетесь перевести это в русло того, что и по UDP все должно быть нормально если сеть нормальная.

А не представляете вариант, когда камеры подключаются через чужие сети по туннелям, или с удаленных объектов. Что, для каждой камеры методом тыка выбирать по какому протоколу соединяться?

 

10 часов назад, dr Tr0jan сказал:

Ну если основной поток 10M, тады ой. На длинке вполне допускаю переполнение буфера.

Не работаю с такими большими потоками. Обычно с x265 меньше четырёх достаточно.

Я всегда говорю, что люди представляют мир таким, как они его видят. Если китайцы едят палочками, а у нас вилкой и ложкой, то попав в другую страну, они будут недоумевать, зачем такие сложности себе придумывать?

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

 

Так же и с камерами, когда мы ранее работали с 1М, 2М, то не заморачивались по поводу подключения, все и так работало. А уже 4М камеры начали преподносить непонятные сюрпризы при работе по UDP, поначалу на это не обращали внимание, но после заказчики начали спрашивать, а почему движение в кадре то быстрое, то рывками? И тут кому-то пришло в голову попробовать TCP и все проблемы ушли. После на всех камерах ставим только TCP в настройках.

 

И поэтому когда потоки большие, а даже камера, с настройкой в 10М потока жестко, без адаптивного битрейта, порой выплевывает его и на 8М, и на 12-13М, а сверху еще 1.5М второй поток, то есть суммарно рассчитываем на 15М потока с каждой камеры.

Тут приходится подключать камеры к портам гигабитного коммутатора, т.к. в соточном более 7 камер уже нормально не работают, порой упираются в 100М канала.

 

10 часов назад, dr Tr0jan сказал:

А нахера писать второй поток в 1.5M? Макроскоп прекрасно делает мультивид в записи из основного потока.

Как он его делает? Пережимает, на это тратятся ресурсы. Может на малых битрейтах еще возможно его как-то быстро пережимать, но из 10М основного потока, когда камер хотя бы 16 уже нормальная работоспособность теряется. Кроме всего загружается жесткий диск на чтение.

 

Я же говорю есть разница, одно дело писать поток 10М с 25 кадров в секунду, а другое поток 2М-4М с малым количеством кадров, сложность пересжатия растет нелинейно.

 

10 часов назад, dr Tr0jan сказал:

Я с Длинками не работаю уже 8 лет. Но вот прям сейчас (на загородном доме, кстати) на стареньком DES-1024 (выступает выключателем между двумя каталистами) нет никаких проблем с 10ю камерами с потоком 4 Mbps в работе по UDP.

Ну и с DGS 3120-24SC нет проблем с буферами, они еще старых серий где не экономили. И на них тоже по UDP картинка плавает, по TCP нормально, так что проблема совершенно не на сетевом транспорте.

 

10 часов назад, dr Tr0jan сказал:

Тогда откуда тогда берётся рассинхронизация???

Вы звук с камер не пробовали записывать? А потом просматривать? Или одновременно 2 потока смотреть маленький и большой, можно увидеть то порой нестыковка по 10-30 секунд при просмотре, если на UDP работать, а на TCP она есть тоже, но не такая большая, около 1-4 секунд.

 

10 часов назад, dr Tr0jan сказал:

Да ну! И оверхед у TCP меньше, и контроль соединения в памяти отсутствует, да? Полнейшая профнепригодность!

А по UDP что сервер камере ничего не сообщает? А она только поток выплевывает - вот отсюда синхронизация и убегает.

 

1 час назад, alibek сказал:

В нормальной сети ничего обрываться и теряться не будет.

Почему же в интернете браузер через TCP работает? А торренты по UDP качаются?

 

1 час назад, alibek сказал:

Но полтора мегабита избыточно, у меня 500 Кбит/с, для маленького экрана этого достаточно.

500кб слишком размазано все.

 

1 час назад, alibek сказал:

А можно лепить костыли в надежде переложить решение проблемы на протокольные возможности — добавить TCP, обернуть в EoIP, перейти на 10G.

От прогресса никуда не уйти, скоро все линки будут 10Г.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, Saab95 сказал:

Почему же в интернете браузер через TCP работает?

Потому что протокол HTTP работает по TCP.

 

1 час назад, Saab95 сказал:

От прогресса никуда не уйти, скоро все линки будут 10Г.

Это не прогресс, а ограниченность.

Когда линки будут 10G, любителям лепить кривые решения потребуется 100G.

 

1 час назад, Saab95 сказал:

500кб слишком размазано все.

А на альтернативном потоке детали рассматривать не нужно, для этого основной есть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, Saab95 сказал:

От прогресса никуда не уйти, скоро все линки будут 10Г.

Да ну, зачем во все щели 10 Гбит?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

18 hours ago, Saab95 said:

Я лишь написал что по TCP камеры лучше работают

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

18 hours ago, Saab95 said:

А не представляете вариант, когда камеры подключаются через чужие сети по туннелям, или с удаленных объектов.

Конечно не представляем. Зачем в загородном доме чужие сети с туннелями и удалённые объекты?

18 hours ago, Saab95 said:

А уже 4М камеры начали преподносить непонятные сюрпризы при работе по UDP, поначалу на это не обращали внимание, но после заказчики начали спрашивать, а почему движение в кадре то быстрое, то рывками?

Что же здесь непонятного? Всё изначально понятно для любого специалиста/инженера.

18 hours ago, Saab95 said:

Тут приходится подключать камеры к портам гигабитного коммутатора, т.к. в соточном более 7 камер уже нормально не работают, порой упираются в 100М канала.

Глупости какие-то. Нормальный (с нормальными буферами) стомегабитный коммутатор пережёвывает 48 потоков в 15M и выплёвывает в гигабитный аплинк.

18 hours ago, Saab95 said:

Вы звук с камер не пробовали записывать? А потом просматривать? Или одновременно 2 потока смотреть маленький и большой, можно увидеть то порой нестыковка по 10-30 секунд при просмотре, если на UDP работать

Можно сказать, это одна из основных обязанностей в работе. Вообще нет нестыковок, даже 300 мс нестыковок нет. Что по UDP, что по TCP.

Я думаю, у вас система видеонаблюдения неправильно спроектирована. В нормальных системах (eVidence, Panasonic, Milestone, Макроскоп) таких проблем не то что не может, не должно быть.

18 hours ago, Saab95 said:

А по UDP что сервер камере ничего не сообщает? А она только поток выплевывает - вот отсюда синхронизация и убегает.

Обычно, ничего не сообщает. А зачем синхронизировать поток, если он сам синхронизируется по времени RTC?

18 hours ago, Saab95 said:

Почему же в интернете браузер через TCP работает?

Наверное потому что изначально HTTP работает не только на 10 гигабитных езернет-каналах, но и в совершенно других физических средах.

А торренты изначально по TCP работали, когда накладные расходы TCP стали заметны, стали использовать в том числе и UDP.

18 hours ago, Saab95 said:

500кб слишком размазано все.

В сетке из 16-камер на 47" ТВ, да когда таких телевизоров шесть на одного оператора? Наверное, вы не умеете их готовить.

 

20 hours ago, alibek said:

Разве? Я тоже пишу оба потока, потому что без этого в мультивиде передается полный поток.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 06.06.2020 в 14:36, alibek сказал:

А на альтернативном потоке детали рассматривать не нужно, для этого основной есть.

Детектор движения работает именно на альтернативном потоке.

 

В 07.06.2020 в 07:55, dr Tr0jan сказал:

В сетке из 16-камер на 47" ТВ, да когда таких телевизоров шесть на одного оператора? Наверное, вы не умеете их готовить.

Да без разницы монитор или ТВ разрешение по сути одинаковое. Уже выше писал что детектор движения работает по второму потоку, если на нем мало деталей он упускает малые перемещения, особенно вдали.

 

В 07.06.2020 в 07:55, dr Tr0jan сказал:

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

Когда надо смотреть кто откуда пришел и куда пошел, нужен именно мультивид, и когда камер много, например 16, без записи со второго потока получается туго.

 

В 06.06.2020 в 15:05, Shurhenchik сказал:

Да ну, зачем во все щели 10 Гбит?

Потому что стоимость каналов что 1Г, что 10Г не сильно отличается.

 

В 07.06.2020 в 07:55, dr Tr0jan сказал:

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

Гарантированная доставка пакетов хотя бы.

 

В 07.06.2020 в 07:55, dr Tr0jan сказал:

Конечно не представляем. Зачем в загородном доме чужие сети с туннелями и удалённые объекты?

Что бы смотреть запись удаленно? Как вы представляете через медленный канал, допустим 10М, архив смотреть, когда второго потока нет?

 

В 07.06.2020 в 07:55, dr Tr0jan сказал:

Глупости какие-то. Нормальный (с нормальными буферами) стомегабитный коммутатор пережёвывает 48 потоков в 15M и выплёвывает в гигабитный аплинк.

Сейчас 100М коммутаторов уже и не выпускают с нормальными характеристиками, все на дешевых китайских чипах.

 

В 07.06.2020 в 07:55, dr Tr0jan сказал:

Можно сказать, это одна из основных обязанностей в работе. Вообще нет нестыковок, даже 300 мс нестыковок нет. Что по UDP, что по TCP.

Я думаю, у вас система видеонаблюдения неправильно спроектирована. В нормальных системах (eVidence, Panasonic, Milestone, Макроскоп) таких проблем не то что не может, не должно быть.

Спроектировано все нормально. Только выше уже писали что с большими потоками не работают 2-4М, а мы работаем с 10М потоками, настройте свои системы на такие камеры и скорости, потом будете рассказывать как все отлично работает и синхронизация не уходит.

 

В 07.06.2020 в 07:55, dr Tr0jan сказал:

Обычно, ничего не сообщает. А зачем синхронизировать поток, если он сам синхронизируется по времени RTC?

Вот представьте простую ситуацию. Есть детектор движения видео, который работает по второму потоку. А есть запись звука постоянно по третьему потоку. Ясно дело что звук пишется постоянно, а видео по движению. И когда случается событие записи видео его после надо состыковать со звуком. И не все так гладко на этом поле.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 hours ago, Saab95 said:

Детектор движения работает именно на альтернативном потоке.

Зачем? У меня работает на основном потоке.

3 hours ago, Saab95 said:

Когда надо смотреть кто откуда пришел и куда пошел, нужен именно мультивид

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

3 hours ago, Saab95 said:

Гарантированная доставка пакетов хотя бы.

Ещё раз. Зачем нужна гарантированная доставка пакетов в сети без потерь? В ней априори все пакеты будут доставлены. Аргументов, почему гарантированная доставка пакетов в сети без потерь - лучше, чем её отсутствие, я не услышал.

3 hours ago, Saab95 said:

Что бы смотреть запись удаленно? Как вы представляете через медленный канал, допустим 10М, архив смотреть, когда второго потока нет?

А зачем смотреть архив через UDP? Камеры вещают, а архив пишется в UDP. Архив смотрится через абсолютно любой канал в TCP. Это же video-on-demand, а не real-time. Эта цитата была вырвана из контекста про обсуждение UDP vs TCP.

Теперь про медленный канал. Может ты и прав, но я ещё не сталкивался с практической необходимостью транслировать 16 камер потоком 10M каждая через интернет. Повторюсь, 4k в x265 в 4M достаточно для мониторинга любых событий, если мы конечно не видео о живой природе через инет транслируем. Первую попавшуюся камеру 4k взял, так вот она закрывает территорию в 20 000 кв. м и передаёт картинку с битрейтом в 4M в x264. Затем подумал, что это нечестно и взял x265 камеру - там вообще битрейт 3.3M, а качество ещё выше (камера поновее и почище). Где большее качество нужно на загородном доме, не представляю.

3 hours ago, Saab95 said:

Сейчас 100М коммутаторов уже и не выпускают с нормальными характеристиками, все на дешевых китайских чипах.

Т.е. когда выпускались, всё было нормально? Может в таком случае не стоит применять эпитет "приходится"?

3 hours ago, Saab95 said:

настройте свои системы на такие камеры и скорости

1) А зачем? 2) А куда я архив буду складывать? 3) А как у меня пользователи будут это смотреть?

3 hours ago, Saab95 said:

Вот представьте простую ситуацию. Есть детектор движения видео, который работает по второму потоку.

Не могу представить. Не понимаю, зачем нужен детектор движения по второму потоку?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 часов назад, Saab95 сказал:

Потому что стоимость каналов что 1Г, что 10Г не сильно отличается.

Да ладно? А то что коммутатор с 10Г стоит немного не столько сколько с 1Г это ничего?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, dr Tr0jan сказал:

Не могу представить. Не понимаю, зачем нужен детектор движения по второму потоку?

меньше нагрузки CPU при одинаковом эффекте для многих типичных применений.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@LostSoul, видеонаблюдение на загородном доме на Пентиуме I гонять? У нас на четырёх загородных домах стоят специально рассчитанные (под задачу) сервера, на двух детектор движения камеры используется, на двух других - Макроскоп. Проблем с нагрузкой нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 минут назад, dr Tr0jan сказал:

специально рассчитанные (под задачу)

Это потому что специально рассчитанные под задачу, а не тупо комп +набор 6 Мп камер, а там как повезет :)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

57 минут назад, dr Tr0jan сказал:

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

ну и?  у кого то щи жидкие, а у кого-то жемчуг мелкий.

с точки зрения инженерной постановки задачи детектор движения на вторичном потоке дает меньше нагрузки .   А применяя детектор движения на потоке 6Мп, ваше ПО сначала делает downscale а затем обрабатывает картинку, так как будто это был вторичный поток.  то есть делает лишнюю работу и греет атмосферу.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 часов назад, Saab95 сказал:

Детектор движения работает именно на альтернативном потоке.

У вас часом раздвоения личности нет?

У вас в голове одновременно существует две концепции: 6МП вместо 2МП потому что "на 2МП ничего не видно" и использование низкокачественного потока для аналитики (детектора движения).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Только что, alibek сказал:

использование низкокачественного потока для аналитики (детектора движения).

во первых для большинства задач хватает, во вторых детектор движения который реально анализирует изменение каждого кадра на 6Мп в каждом пикселе без хаков  оптимизацией, потребует видимо что-то типа 16-ядерного процессора на каждую камеру.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Никогда не сталкивался с проблемами по аналитике.

Видимо потому, что не жду от нее слишком много, и не использую 6МП вместо 2МП там, где это не требуется.

 

Что касается качества работы детектора движения, то нужно рассматривать разные случаи.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

11 часов назад, dr Tr0jan сказал:

Зачем? У меня работает на основном потоке.

На высоких битрейтах детекция движения на основном потоке сильно нагружает процессор, порой даже 16 каналов не тянет. А если второго потока вообще нет, то их первого еще и маленькие картинки в мультивид выходят. Все это загружает оборудование еще больше.

 

11 часов назад, dr Tr0jan сказал:

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

И что на них смотреть? Наши типовые объекты в загородных домах это минимум 16 камер. Если вести разговор про входную группу, то обычно 1 или 2 камеры снимают ворота и калитку снаружи, 2 камеры с разных ракурсов внутренний двор, еще 2 камеры на стенах дома висят, по сути уже 5-6 только тех, в которые попадает входящий человек или машина. Добавляем сюда камеры внутри помещения, камеры с других сторон дома. И получается что смотреть 4 камеры на мониторе - это потерять для себя другие события. На мониторе нормальных размеров, хотя бы 32, или на телевизоре, вполне различимы детали и видно что за человек идет, свой или кто-то чужой.

 

Даже если посчитать 16 камер по 1.5М каждая, то это уже 25М трафика от сервера записи к просмотрщику.

 

11 часов назад, dr Tr0jan сказал:

Ещё раз. Зачем нужна гарантированная доставка пакетов в сети без потерь? В ней априори все пакеты будут доставлены. Аргументов, почему гарантированная доставка пакетов в сети без потерь - лучше, чем её отсутствие, я не услышал.

Это уже димагогия пошла. Если ваше оборудование не может TCP и не справляется, то наше вполне себе это позволяет, мы же по второму потоку работаем и нагрузки особой нет.

 

11 часов назад, dr Tr0jan сказал:

Теперь про медленный канал. Может ты и прав, но я ещё не сталкивался с практической необходимостью транслировать 16 камер потоком 10M каждая через интернет. Повторюсь, 4k в x265 в 4M достаточно для мониторинга любых событий, если мы конечно не видео о живой природе через инет транслируем. Первую попавшуюся камеру 4k взял, так вот она закрывает территорию в 20 000 кв. м и передаёт картинку с битрейтом в 4M в x264. Затем подумал, что это нечестно и взял x265 камеру - там вообще битрейт 3.3M, а качество ещё выше (камера поновее и почище). Где большее качество нужно на загородном доме, не представляю.

Когда мы сжатие выбирали, то по умолчанию оно для камер 6М стоит на уровне 8Мбит. Так вот на статичной картинке, например камера в помещении, где стены и все остальное не движется, а только объект в виде человека, там вроде как особой разницы нет, что 6Мбит, что 8, что 10. Но если это улица, и там газон на ветру колышется, или деревья - кусты качаются, то на все это тратиться ресурс сжатия, и на малых потоках 6Мбит уже теряются детали, а на 10Мбит они все еще видны.

Учитывая то, что сеть позволяет передавать 10М с каждой камеры, диски позволяют сохранять 10М со всех камер в течении месяца, зачем снижать качество картинки?

 

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

 

Если бы разрешение камер было меньше - то разглядеть столь малые детали не получилось бы, а на 6М со сжатием 10М, черная точка в руках явно просматривалась, но на экране телевизора, где разрешение было меньше, этой точки уже видно не было. И клиент этот был рад, т.к. восстановить брелок ему обходилось в довольно внушительную сумму денег.

 

11 часов назад, dr Tr0jan сказал:

1) А зачем? 2) А куда я архив буду складывать? 3) А как у меня пользователи будут это смотреть?

Вот тут сразу и получается так, что ваше оборудование это просто не потянет. А нашу систему пользователи могут хоть со смартфона смотреть, подключившись по VPN. Да да - все закрыто и извне на сервер записи с интернета никто не попадет и не взломает.

 

6 часов назад, Shurhenchik сказал:

Да ладно? А то что коммутатор с 10Г стоит немного не столько сколько с 1Г это ничего?

Посчитайте в комплексе, сейчас разница там порядка 5 тысяч, обычный простой с 1Г, или + еще 10Г порты. Учитывая то что все это ставится на будущее, почему бы и нет?

 

4 часа назад, alibek сказал:

У вас в голове одновременно существует две концепции: 6МП вместо 2МП потому что "на 2МП ничего не видно" и использование низкокачественного потока для аналитики (детектора движения).

Все оборудование именно так и анализирует картинку на движения, и в том числе даже тогда, когда это движение детектирует сама камера - уж ее ресурсов точно не хватит просматривать картинку 6М.

 

4 часа назад, alibek сказал:

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

Если брать реальное применение, то на картинке создается много групп на движение - ближние с меньшей чувствительностью и большим размерам объекта, дальние с высокой и меньшим размером объекта. А бывает еще где-то дерево или зелень какая-то колышется и попадает в детектор тоже. При наличии даже 16 камер, лазать на каждую что бы править настройки не удобно, гораздо проще управлять всем из единого места.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

14 минут назад, Saab95 сказал:

Все оборудование именно так и анализирует картинку на движения, и в том числе даже тогда, когда это движение детектирует сама камера - уж ее ресурсов точно не хватит просматривать картинку 6М.

Сегодня прямо конкурс юмора.

Значит на кодирование H.264/H.265 ее ресурсов хватает, а на обнаружение изменений (каковое является обязательной частью кодирования) ресурсов не хватает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 минуты назад, alibek сказал:

Значит на кодирование H.264/H.265 ее ресурсов хватает, а на обнаружение изменений (каковое является обязательной частью кодирования) ресурсов не хватает?

Это совершенно разные вещи. Картинку кодирует аппаратный кодер и на детекцию движения он никак не работает. Детекция движения производится уже процессором камеры программно как раз по второму потоку, который даже не обязательно специально включать, камера сама с него картинку берет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

58 минут назад, Saab95 сказал:

Посчитайте в комплексе, сейчас разница там порядка 5 тысяч, обычный простой с 1Г, или + еще 10Г порты. Учитывая то что все это ставится на будущее, почему бы и нет?

плиз какая модель имеется ввиду? Ну для примера?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

7 часов назад, Shurhenchik сказал:

плиз какая модель имеется ввиду? Ну для примера?

Mikrotik CRS326-24G-2S+RM, как один из хороших вариантов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, Saab95 сказал:

Mikrotik CRS326-24G-2S+RM, как один из хороших вариантов.

Как же я сразу не догадался :)

Теперь мне даже удивительно отчего циски\джуниперы не разорились до сих пор.

И вообще, наверное надо выкинуть наш Ericsson RedBack SE600 и заменить его на какой-нибудь Микротик.

Нуачё, тоже маршрутизаторы ведь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

20 hours ago, Saab95 said:

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

Я честно скажу, я не знаю, как именно работает алгоритм детекции движения. Но мне всегда казалось, что работа любой аналитики производится на несжатом изображении, в таком случае битрейт не имеет никакого значения. Если это не так, поправьте. У меня 60-камерные серваки на производстве нормально работают. На загородных домах 10-16 камер, всё летает, проблем нет.

20 hours ago, Saab95 said:

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

Зачем в мультивиде архива такое нагромождение? У нас всё так же, только трёх камер достаточно.

 

20 hours ago, Saab95 said:

И получается что смотреть 4 камеры на мониторе - это потерять для себя другие события. На мониторе нормальных размеров, хотя бы 32, или на телевизоре, вполне различимы детали и видно что за человек идет, свой или кто-то чужой.

Речь про архив мультивида. Причём здесь онлайн просмотр?

Для онлайн просмотра можно во втором потоке хоть 32, хоть 96 каналов смотреть, но зачем? МВД Великобритании (признанный авторитет в мире в видеонаблюдения) доказало, что один человек способен адекватно анализировать полиэкран из максимум 9 каналов. При 16 каналах внимание рассеивается - раз, разрешение ухудшается - два. Никак не можем доказать это своим безопасникам. Но повторюсь, что даже 16 каналов 4K не несёт проблем с производительностью, как в архиве, так и в онлайне.

20 hours ago, Saab95 said:

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

Это какое оборудование не умеет TCP???

Речь о том, что нет никакого смысла забивать гвозди микроскопом. Или Микротик не умеет UDP???

20 hours ago, Saab95 said:

Когда мы сжатие выбирали, то по умолчанию оно для камер 6М стоит на уровне 8Мбит. Так вот на статичной картинке, например камера в помещении, где стены и все остальное не движется, а только объект в виде человека, там вроде как особой разницы нет, что 6Мбит, что 8, что 10. Но если это улица, и там газон на ветру колышется, или деревья - кусты качаются

Ещё раз, на нормальных камерах 4K (в т.ч. Dahua, я уже не говорю про Honeywell и тем более Axis) при битрейте 4 Mbps качество картинки позволяет полноценно наблюдать за объектами в 20 000 кв. м, или за помещениями с 200 человека с возможностью немашинного распознавания лиц.

21 hours ago, Saab95 said:

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

Такие задачи регулярно (несколько раз в месяц) прекрасно решаем на FHD камерах (Panasonic, Dahua) с битрейтом даже меньше 4Mbps.

 

21 hours ago, Saab95 said:

Вот тут сразу и получается так, что ваше оборудование это просто не потянет.

И ваше тоже не потянет. А иначе расскажите, как сохранить месячный архив с 60 камер битрейтом 15 Mbps (вы же оба потока пишете + звук) в течение месяца? И как потом обеспечить одновременную работу с этим архивом 30 сотрудникам? 300 терабайт то. С рэйдом и возможностью горячей замены.

Ну а 16 камер - 80 терабайт, где всё это дело в загородном доме хранить и охлаждать?

21 hours ago, Saab95 said:

А нашу систему пользователи могут хоть со смартфона смотреть, подключившись по VPN. Да да - все закрыто и извне на сервер записи с интернета никто не попадет и не взломает.

Это щас к чему было?

21 hours ago, Saab95 said:

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

А это сейчас что было? Что на каждую камеру в отдельности зайти, что зайти в настройки детектора движения каждого канала в сервере. Или у вас все камеры абсолютно разные и вы их каждый местами меняете?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 10.06.2020 в 14:23, alibek сказал:

Значит на кодирование H.264/H.265 ее ресурсов хватает, а на обнаружение изменений (каковое является обязательной частью кодирования) ресурсов не хватает?

кодирование реализовано в чипе "в железе" ,  оно не выполняется обычными инструкциями.  Мощности CPU там в жизни не хватит видеопоток закодировать

 

 

7 часов назад, dr Tr0jan сказал:

Я честно скажу, я не знаю, как именно работает алгоритм детекции движения. Но мне всегда казалось, что работа любой аналитики производится на несжатом изображении

Разумеется это не так.   Там все работает по принципу очень жестких компромиссов.

Типа сначала ищем просто область где есть интенсивное изменение освещенности ( очень грубо кусками по 256*256 пикселей к примеру ) потом вглядываемся детальнее.

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

в общем все тщательно выверяется и оптимизируется, чтоб ресурсоемкими алгоритмами типа распознания лиц/номеров нагружать только очень маленькие кусочки изображения.

более того, даже такой поверхностный анализ может быть только например на 1-2 кадрах в секунду, а на остальных только сопровождение обнаруженных целей

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, LostSoul сказал:

кодирование реализовано в чипе "в железе" ,  оно не выполняется обычными инструкциями

И как же объяснить, что при изменении параметров видеопотока изменяется нагрузка на CPU?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 минут назад, alibek сказал:

И если это так, то ничего не мешает попутно использовать промежуточные результаты кодирования для детектора движения.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

C CMOS сенсора можно считывать в несколько потоков одновременно. Один поток в полном разрешении и FPS льется на аппаратный кодер as is, и с кодера в стрим отдается as is, никто в него не лезет с аналитикой в самой камере - ни CPU, ни памяти не хватит. Просто для аналитики с сенсора снимается еще один поток, с полным разрешением но раз в секунду или даже две, и вот он уже анализируется процом камеры на изменения. Что касается фирменной аналитики "камера+рег", то там еще тупее - камерой отдается на рег доп.поток в MJPEG спецом для аналитики, для MJPEG не надо много мощи разбирать сам поток.  

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.