Pull to refresh

Comments 19

На это кто-то ведется? Ведь от них отказались еще из-за помех. В статье кстати про это ни слова :)
На первом видео видно что изображение двоит даже на AHD-Н.
Как Вы настроили так IP камеру что получили такую задержку? (Я такое видел только на китайских камерах за 500 рублей). Ведь сжатие и отправка в современных камерах идет в реальном времени (для этого используются: FPGA(DSP), DMA, UDP).
Ну, помеха вещь устранимая (например, с помощью хорошо экранированного кабеля, алгоритмов усиления полезного сигнала и т.д.). И статья же эта не о помехах вовсе. Помехи — это отдельная большая тема. И простите, но никак не могу понять витиеватого полета ваших мыслей, как это организовать быстрый канал DMA от IP камеры к конечному устройству наблюдения?! Это невероятный технический трюк! Если вам это удалось, поделитесь опытом, буду премного благодарен! Ну и вам ли не знать, что протокол UDP использует отправку данных без подтверждения и гарантии доставки. Никакого контроля потока, никакого контроля ошибок, никакой повторной передачи после приема испорченного пакета. Результат — исчезающие в никуда кадры IP камер. О каком качестве видеонаблюдения тут вообще речь? А вы говорите помехи…
Видимо вы никогда не ставили аналоговые камеры на предприятиях. Где рядом может работать движок на пару мегаватт. Из всех аналоговых камер, что когда-то ставили все были с помехами. И похоже вы не знаете как работает IP камера:
  1. Матрица — получает сырой кадр и отправляет на сжатие в энкодер.
  2. Энкодер (FPGA или DSP) — сжимает в кадр и отправляет данные в процессору.
  3. Процессор — в зависимости от программы отправляет их посети (UDP) пробрасывая сжатый кадр через DMA.

Как видите нигде нет никаких задержек. Если и есть то не значительные.
И да пакеты UDP в локальной сети не теряются (при правильной настройке). Да и то можно потерять лишь часть кадра.
Ну, камеру же не обязательно размещать рядом с движком. И вместо внутренней камеры в пластиковом корпусе можно взять наружную камеру в металлическом корпусе, которой будут «страшны» только магнитные поля — а они даже от мощного движка не распространяются слишком далеко, в отличие от электрических. Я в принципе ничего не имею против IP камер, но мне кажется вы их слишком уж идеализируете… И все еще не просветили меня, как это IP камера научилась «пробрасывать» кадры по протоколу UTP сквозь всю сетевую инфраструктуру используя DMA…
На камерах, транслирующих MJPEG, задержки нет. Задержка есть только при MPEG кодировании.
Да и проблема 100 метров несколько преувеличена — на объектах обычно уже есть локалка, и камеры цепляются к ближайшему коммутатору.
Ну вот представьте ферму или большой склад. И на кой сдалась локалка в коровнике или на задворках склада, где кроме унылого забора и чахленькой растительности никого и ничего нет? И где, простите, мыши могут устроить уютное гнездышко у тепленького коммутатора, покусывая от нечего делать провода…
Я потому и написал, что она преувеличена, а не отсутствует вовсе.
Тогда задам еще задачку: сколько нужно 2МП IP камер вещающих в MJPEG, чтобы «положить» 100 Мбит/с сеть, если нужно наиболее качественное изображение? (Даю подсказку — в три раза меньше, чем IP камер, вещающих в Н.264 при сопоставимом качестве).
100 мегабит — только от камеры до свича. Дальше уже идёт гигабит.
Хорошая статья про AHD/AHD-H технологию.
И примеры работы AHD камер достаточно показательны.
Было бы еще лучше, если бы сравнения с IP технологиями были более корректными.
Скажем, для подключения IP камер на старые кабельные структуры есть не мало решений типа вот такого
www.mobotix.com/rus_RU/Продукты/Автоматизация/Mx2wire
Возможно расстояние до 500 метров расстояние по коаксиалу до камеры.
Опять же оптику через медиа конвертеры никто не отменял.
www.sonet-msk.ru/catalog/mediakonverteryi

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

Я бы сказал так — AHD решение имеет право на жизнь при наличии некоторых условий, которые существуют далеко не всегда.
Задержка IP-камеры никак не зависит от ценового диапазона. Она определяется видеокодеком.
MJPEG работает без задержки, MPEG с задержкой — но жмёт лучше.
Добавлю — жмет лучше, при этом сильно снижая нагрузку на локальную сеть. А вот MJPEG трафик быстро забивает сеть — ведь он по сути представляет собой непрерывную передачу последовательности jpeg фотографий. А при сильном сжатии (чтобы снизить нагрузку на сеть) качество изображения MJPEG заметно страдает — картинка мылится и обрастает артефактами (как при сильном сжатии обычного jpeg — а в общем-то).
Вы несколько упрощаете ситуацию.
Если я вас правильно понимаю, под 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
Я не упрощаю, а говорю как есть. Альтернативные способы сжатия существуют, но в массово доступных китайских IP камерах искать их можно долго и безрезультатно. И даже в дорогих IP камерах альтернатив H.264 и MJPEG обычно нет. И китайцев можно отчасти понять: во-первых матчасть камеры обходится дешевле, во-вторых «альтернативное» видео может банально не воспроизвестись на конечном устройстве из-за отсутствия необходимого декодера — а это уже не комильфо. И мы в данном случае обсуждаем экономные решения, с которыми 10G Ethernet не совсем вяжется…
Я понял — в данной статье обсуждаются «экономичные решени» с акцентом на дешевых китайских производителей.
Эта мысль не была для меня очевидной. Теперь все стало понятнее. Спасибо.
Безусловно, акцент на доступность решений важен. Не все готовы платить без оглядки на бюджет решения. А по сжатию, вот вам пример камеры: 2МП IP SpeedDome DH-SD6AL240-HNI от недешевого китайского производителя Dahua. И не абы какая камера, а дорогая SpeedDome. И что мы видим? H.264 и MJPEG. Это все. Может у IP камер Hikvision кодеков больше? Но достаточно взглянуть на спецификации устройств чтобы убедиться в обратном. И в любимых вами камерах Axis точно та же картина. Вот за Mobotix не скажу — не знаю.
Повторюсь — в современных локальных сетях проблемы нагрузки практически нет.
Гигабитные свичи стоят незначительно дороже стомегабитных. В ближайшие несколько лет, скорее всего, стомегабитные свичи начнут снимать с производства.
А для крупных объектов, где суммарная полоса MJPEG может упереться в гигабит, применение 10GE или объединение нескольких гигабитных каналов на некоторых участках сети (скорее всего — только между головным свичом и сервером) практически не скажется на общей цене решения.
Фишка в том, что AHD систему видеонаблюдения можно развернуть в тех же масштабах без использования уймы свичей, то есть дешевле и надежнее. Достаточно будет всего одного свича, чтобы объединить регистраторы с локалкой, и то если нужно просматривать/вести запись на компьютеры или мобильные гаджеты. Если для системы небольшого масштаба достаточно просмотра/записи на встроенный HDD регистратора, то и вообще без свичей обойтись можно.
Есть еще вопрос цены вопроса, простите за каламбур. Не стоит о нем забывать. Особенно во время кризиса. А нестандартных и уникальных решений действительно возможно море, но статья же не об этом.
Only those users with full accounts are able to leave comments. Log in, please.