Comments 19
На это кто-то ведется? Ведь от них отказались еще из-за помех. В статье кстати про это ни слова :)
На первом видео видно что изображение двоит даже на AHD-Н.
Как Вы настроили так IP камеру что получили такую задержку? (Я такое видел только на китайских камерах за 500 рублей). Ведь сжатие и отправка в современных камерах идет в реальном времени (для этого используются: FPGA(DSP), DMA, UDP).
На первом видео видно что изображение двоит даже на AHD-Н.
Как Вы настроили так IP камеру что получили такую задержку? (Я такое видел только на китайских камерах за 500 рублей). Ведь сжатие и отправка в современных камерах идет в реальном времени (для этого используются: FPGA(DSP), DMA, UDP).
+1
Ну, помеха вещь устранимая (например, с помощью хорошо экранированного кабеля, алгоритмов усиления полезного сигнала и т.д.). И статья же эта не о помехах вовсе. Помехи — это отдельная большая тема. И простите, но никак не могу понять витиеватого полета ваших мыслей, как это организовать быстрый канал DMA от IP камеры к конечному устройству наблюдения?! Это невероятный технический трюк! Если вам это удалось, поделитесь опытом, буду премного благодарен! Ну и вам ли не знать, что протокол UDP использует отправку данных без подтверждения и гарантии доставки. Никакого контроля потока, никакого контроля ошибок, никакой повторной передачи после приема испорченного пакета. Результат — исчезающие в никуда кадры IP камер. О каком качестве видеонаблюдения тут вообще речь? А вы говорите помехи…
+1
Видимо вы никогда не ставили аналоговые камеры на предприятиях. Где рядом может работать движок на пару мегаватт. Из всех аналоговых камер, что когда-то ставили все были с помехами. И похоже вы не знаете как работает IP камера:
Как видите нигде нет никаких задержек. Если и есть то не значительные.
И да пакеты UDP в локальной сети не теряются (при правильной настройке). Да и то можно потерять лишь часть кадра.
- Матрица — получает сырой кадр и отправляет на сжатие в энкодер.
- Энкодер (FPGA или DSP) — сжимает в кадр и отправляет данные в процессору.
- Процессор — в зависимости от программы отправляет их посети (UDP) пробрасывая сжатый кадр через DMA.
Как видите нигде нет никаких задержек. Если и есть то не значительные.
И да пакеты UDP в локальной сети не теряются (при правильной настройке). Да и то можно потерять лишь часть кадра.
+1
Ну, камеру же не обязательно размещать рядом с движком. И вместо внутренней камеры в пластиковом корпусе можно взять наружную камеру в металлическом корпусе, которой будут «страшны» только магнитные поля — а они даже от мощного движка не распространяются слишком далеко, в отличие от электрических. Я в принципе ничего не имею против IP камер, но мне кажется вы их слишком уж идеализируете… И все еще не просветили меня, как это IP камера научилась «пробрасывать» кадры по протоколу UTP сквозь всю сетевую инфраструктуру используя DMA…
0
На камерах, транслирующих MJPEG, задержки нет. Задержка есть только при MPEG кодировании.
Да и проблема 100 метров несколько преувеличена — на объектах обычно уже есть локалка, и камеры цепляются к ближайшему коммутатору.
Да и проблема 100 метров несколько преувеличена — на объектах обычно уже есть локалка, и камеры цепляются к ближайшему коммутатору.
0
Ну вот представьте ферму или большой склад. И на кой сдалась локалка в коровнике или на задворках склада, где кроме унылого забора и чахленькой растительности никого и ничего нет? И где, простите, мыши могут устроить уютное гнездышко у тепленького коммутатора, покусывая от нечего делать провода…
0
Я потому и написал, что она преувеличена, а не отсутствует вовсе.
0
Тогда задам еще задачку: сколько нужно 2МП IP камер вещающих в MJPEG, чтобы «положить» 100 Мбит/с сеть, если нужно наиболее качественное изображение? (Даю подсказку — в три раза меньше, чем IP камер, вещающих в Н.264 при сопоставимом качестве).
0
Хорошая статья про AHD/AHD-H технологию.
И примеры работы AHD камер достаточно показательны.
Было бы еще лучше, если бы сравнения с IP технологиями были более корректными.
Скажем, для подключения IP камер на старые кабельные структуры есть не мало решений типа вот такого
www.mobotix.com/rus_RU/Продукты/Автоматизация/Mx2wire
Возможно расстояние до 500 метров расстояние по коаксиалу до камеры.
Опять же оптику через медиа конвертеры никто не отменял.
www.sonet-msk.ru/catalog/mediakonverteryi
Что касается задержек на IP камерах — надо взять очень плохую и дешевую камеру, чтобы это стало проблемой. На камерах хотя бы среднего ценового диапазона эти задержки не превышают доли секунды.
Я бы сказал так — AHD решение имеет право на жизнь при наличии некоторых условий, которые существуют далеко не всегда.
И примеры работы AHD камер достаточно показательны.
Было бы еще лучше, если бы сравнения с IP технологиями были более корректными.
Скажем, для подключения IP камер на старые кабельные структуры есть не мало решений типа вот такого
www.mobotix.com/rus_RU/Продукты/Автоматизация/Mx2wire
Возможно расстояние до 500 метров расстояние по коаксиалу до камеры.
Опять же оптику через медиа конвертеры никто не отменял.
www.sonet-msk.ru/catalog/mediakonverteryi
Что касается задержек на IP камерах — надо взять очень плохую и дешевую камеру, чтобы это стало проблемой. На камерах хотя бы среднего ценового диапазона эти задержки не превышают доли секунды.
Я бы сказал так — AHD решение имеет право на жизнь при наличии некоторых условий, которые существуют далеко не всегда.
+1
Задержка IP-камеры никак не зависит от ценового диапазона. Она определяется видеокодеком.
MJPEG работает без задержки, MPEG с задержкой — но жмёт лучше.
MJPEG работает без задержки, MPEG с задержкой — но жмёт лучше.
0
Добавлю — жмет лучше, при этом сильно снижая нагрузку на локальную сеть. А вот MJPEG трафик быстро забивает сеть — ведь он по сути представляет собой непрерывную передачу последовательности jpeg фотографий. А при сильном сжатии (чтобы снизить нагрузку на сеть) качество изображения MJPEG заметно страдает — картинка мылится и обрастает артефактами (как при сильном сжатии обычного jpeg — а в общем-то).
0
Вы несколько упрощаете ситуацию.
Если я вас правильно понимаю, под MPEG вы имеете в виду H.264.
Он более интенсивно использует мощность процессора камеры, и дает меньший поток при том же качестве картинки. Да, я в курсе про способ сжатия, ключевые кадры и т.д. Но по моей практике (камеры Axis, Mobotix) время задержки отображения картинки не было критичным для H.264.
Опять же — есть альтернативные способы сжатия типа MxPEG, которые специально предназначены для видеонаблюдения, и сочетают в себе и низкие задержки, и высокое качество картинки, и сравнительно небольшой генерируемый поток данных.
Что же до пропускной полосы, 100 мегабит (обычный Fast Ethernet) достаточно даже для 4k камеры. А дальше все эти потоки попадают в гигабитные коммутаторы и вопрос с недостатком производительности сети просто не возникает. По крайней мере даже в системах на 200-300 камер это именно так. Система на 200 с небольшим камер генерировала поток около 250 мегабайт в секунду и прекрасно «пролезала» через 4хGigabitEthenet trunk, не говоря уже о 10G Ethernet, который мы порой и в домашних системах ставим
habrahabr.ru/post/245993
Если я вас правильно понимаю, под MPEG вы имеете в виду H.264.
Он более интенсивно использует мощность процессора камеры, и дает меньший поток при том же качестве картинки. Да, я в курсе про способ сжатия, ключевые кадры и т.д. Но по моей практике (камеры Axis, Mobotix) время задержки отображения картинки не было критичным для H.264.
Опять же — есть альтернативные способы сжатия типа MxPEG, которые специально предназначены для видеонаблюдения, и сочетают в себе и низкие задержки, и высокое качество картинки, и сравнительно небольшой генерируемый поток данных.
Что же до пропускной полосы, 100 мегабит (обычный Fast Ethernet) достаточно даже для 4k камеры. А дальше все эти потоки попадают в гигабитные коммутаторы и вопрос с недостатком производительности сети просто не возникает. По крайней мере даже в системах на 200-300 камер это именно так. Система на 200 с небольшим камер генерировала поток около 250 мегабайт в секунду и прекрасно «пролезала» через 4хGigabitEthenet trunk, не говоря уже о 10G Ethernet, который мы порой и в домашних системах ставим
habrahabr.ru/post/245993
0
Я не упрощаю, а говорю как есть. Альтернативные способы сжатия существуют, но в массово доступных китайских IP камерах искать их можно долго и безрезультатно. И даже в дорогих IP камерах альтернатив H.264 и MJPEG обычно нет. И китайцев можно отчасти понять: во-первых матчасть камеры обходится дешевле, во-вторых «альтернативное» видео может банально не воспроизвестись на конечном устройстве из-за отсутствия необходимого декодера — а это уже не комильфо. И мы в данном случае обсуждаем экономные решения, с которыми 10G Ethernet не совсем вяжется…
0
Я понял — в данной статье обсуждаются «экономичные решени» с акцентом на дешевых китайских производителей.
Эта мысль не была для меня очевидной. Теперь все стало понятнее. Спасибо.
Эта мысль не была для меня очевидной. Теперь все стало понятнее. Спасибо.
0
Безусловно, акцент на доступность решений важен. Не все готовы платить без оглядки на бюджет решения. А по сжатию, вот вам пример камеры: 2МП IP SpeedDome DH-SD6AL240-HNI от недешевого китайского производителя Dahua. И не абы какая камера, а дорогая SpeedDome. И что мы видим? H.264 и MJPEG. Это все. Может у IP камер Hikvision кодеков больше? Но достаточно взглянуть на спецификации устройств чтобы убедиться в обратном. И в любимых вами камерах Axis точно та же картина. Вот за Mobotix не скажу — не знаю.
0
Повторюсь — в современных локальных сетях проблемы нагрузки практически нет.
Гигабитные свичи стоят незначительно дороже стомегабитных. В ближайшие несколько лет, скорее всего, стомегабитные свичи начнут снимать с производства.
А для крупных объектов, где суммарная полоса MJPEG может упереться в гигабит, применение 10GE или объединение нескольких гигабитных каналов на некоторых участках сети (скорее всего — только между головным свичом и сервером) практически не скажется на общей цене решения.
Гигабитные свичи стоят незначительно дороже стомегабитных. В ближайшие несколько лет, скорее всего, стомегабитные свичи начнут снимать с производства.
А для крупных объектов, где суммарная полоса MJPEG может упереться в гигабит, применение 10GE или объединение нескольких гигабитных каналов на некоторых участках сети (скорее всего — только между головным свичом и сервером) практически не скажется на общей цене решения.
0
Фишка в том, что AHD систему видеонаблюдения можно развернуть в тех же масштабах без использования уймы свичей, то есть дешевле и надежнее. Достаточно будет всего одного свича, чтобы объединить регистраторы с локалкой, и то если нужно просматривать/вести запись на компьютеры или мобильные гаджеты. Если для системы небольшого масштаба достаточно просмотра/записи на встроенный HDD регистратора, то и вообще без свичей обойтись можно.
0
Есть еще вопрос цены вопроса, простите за каламбур. Не стоит о нем забывать. Особенно во время кризиса. А нестандартных и уникальных решений действительно возможно море, но статья же не об этом.
0
Sign up to leave a comment.
AHD видеонаблюдение – есть ли смысл переходить на AHD-Н?