
14.10.2020
Отличия Стрим-сервера от систем видео мониторинга и аналитики
Во-первых,
он для очень большого числа видеокамер…

08.10.2019
Узкое горлышко видеотрансляций
Распределенный Стрим-сервер устраняет принцип «все на одного»

15.11.2018
Зачем этот убийственный триплекс?
Стрим-сервер. Показывать, писать, проигрывать архив, да еще и анализировать – всё вместе делать сложно, лучше «по-разделенности».
Стрим-сервер
Напомним, в классическом видеонаблюдении надо писать на диск, просматривать на мониторе, проигрывать видеозаписи, и не так давно присоединилась к классике видеоаналитика. На всё это нужны ресурсы.
Когда задачи на одном ПК выполняются одновременно, ресурсы расходуются намного больше, т.к. все они часто спотыкаются об одну головку жесткого диска, к которой всегда стоит очередь, об одни и те же участки памяти, занятые разными задачами, об одно и тоже ядро процессора, которых всего несколько компьютере и т.д. Естественно, такая архитектура и менее устойчива, велика вероятность ошибок, особенно на фоне действий пользователя. О какой надежности может идти речь?
Под большое количество камер люди ставят много компьютеров, навешивая на каждый весь функционал. Обычно люди подключают на один компьютер по 25 – 50 камер. Причем, двумя потоками: мелким кадром в MJPEG – для отображения на мониторе и для работы видеоаналитики и крупным кадром в кодеке H.264 без распаковки для записи на диск.
Предположим, у вас 50 камер, вы ставите для них 2 компьютера по 25 камер на каждый со всеми этими проблемами. Но математика позволяет разделить эти задачи и другим способом: на один из компьютеров вы только пишите все 50 камер, а на другом – только просматриваете и анализируете эти же 50 камер.
При этом АРМ оператора избавляется от тугодумной операции записи-считывания диска. Каждый раз, когда нужно что-то закэшировать или считать с диска, задача вставала в очередь ожидания свободного такта постоянной записи 25 камер. Теперь видеоаналитика одна пользуется ресурсами диска, эффективность повышается в разы. Ну, как минимум, теперь можно повесить и 50 камер на один ПК.
А мы ведь ничего нигде не прибавили, лишних денег не потратили. Как было 50 камер на два компьютера, так и осталось. Только на один мы завели все 50 камер на просмотр и видеоанализ, а на другой – для записи. Сорри, при этом второй компьютер можно взять на порядок дешевле, т.е. мы еще и сэкономили.
А, если камеры вторым потоком могут отдавать MJPEG, то при такой концепции мы тянем еще больше – 70 камер. Простая перестановка мест слагаемых, а на выходе ресурсов требуется меньше. И многократно возрастает надежность.
Здесь сразу надо сказать про очередной идиотизм, закрепившийся в системах видеонаблюдения. Народ проповедует некую клиент-серверную архитектуру, где есть отдельный видеосервер и отдельное автоматизированное рабочее место (АРМ). Кто-нибудь вообще знает, зачем их разделяют? На одном ставится полная система с видеозаписью и видеоаналитикой, а на другом – только просмотр и видеоаналитика. Вообще, глупость несусветная, т.к. и на том, и на другом, надо разжимать видео, т.е. использовать мощные процессоры. Мы специально провели опрос среди тех, у кого встречали такую архитектуру – ну, ЗАЧЕМ?
Вменяемым оказался только один ответ – для надежности, чтобы оператор не мог повлиять на видеозапись! Что ж, в нашей новой концепции видеопотоки тоже пишутся на отдельный компьютер, оператор тоже не имеет к ним прямого доступа, но мы еще добавили надежности, т.к. ограничили задачи этому записывающему устройству. Плюс уменьшили цену. Осталось только перенастроить мозги клиенту – предложить ему совместить понятия видеосервер и АРМ в одном ПК.
Тем более, если камер очень много. Например, для 100 камер обычно ставят 5 компьютеров (по 20) со всем функционалом на каждый. А с нашей арифметикой мы выделяем:
один ПК на постоянную видеозапись ста камер и два ПК на просмотр и анализ этих же 100 камер.
В более крупных системах типа Безопасного города это выглядит так:
Но ведь это же логично: оператору надо смотреть, а значит ему нужный мощный проц на распаковку видео, простому же видеомагнитофону нужны только диски.
Когда задачи на одном ПК выполняются одновременно, ресурсы расходуются намного больше, т.к. все они часто спотыкаются об одну головку жесткого диска, к которой всегда стоит очередь, об одни и те же участки памяти, занятые разными задачами, об одно и тоже ядро процессора, которых всего несколько компьютере и т.д. Естественно, такая архитектура и менее устойчива, велика вероятность ошибок, особенно на фоне действий пользователя. О какой надежности может идти речь?
Под большое количество камер люди ставят много компьютеров, навешивая на каждый весь функционал. Обычно люди подключают на один компьютер по 25 – 50 камер. Причем, двумя потоками: мелким кадром в MJPEG – для отображения на мониторе и для работы видеоаналитики и крупным кадром в кодеке H.264 без распаковки для записи на диск.
Предположим, у вас 50 камер, вы ставите для них 2 компьютера по 25 камер на каждый со всеми этими проблемами. Но математика позволяет разделить эти задачи и другим способом: на один из компьютеров вы только пишите все 50 камер, а на другом – только просматриваете и анализируете эти же 50 камер.
При этом АРМ оператора избавляется от тугодумной операции записи-считывания диска. Каждый раз, когда нужно что-то закэшировать или считать с диска, задача вставала в очередь ожидания свободного такта постоянной записи 25 камер. Теперь видеоаналитика одна пользуется ресурсами диска, эффективность повышается в разы. Ну, как минимум, теперь можно повесить и 50 камер на один ПК.
А мы ведь ничего нигде не прибавили, лишних денег не потратили. Как было 50 камер на два компьютера, так и осталось. Только на один мы завели все 50 камер на просмотр и видеоанализ, а на другой – для записи. Сорри, при этом второй компьютер можно взять на порядок дешевле, т.е. мы еще и сэкономили.
А, если камеры вторым потоком могут отдавать MJPEG, то при такой концепции мы тянем еще больше – 70 камер. Простая перестановка мест слагаемых, а на выходе ресурсов требуется меньше. И многократно возрастает надежность.
Здесь сразу надо сказать про очередной идиотизм, закрепившийся в системах видеонаблюдения. Народ проповедует некую клиент-серверную архитектуру, где есть отдельный видеосервер и отдельное автоматизированное рабочее место (АРМ). Кто-нибудь вообще знает, зачем их разделяют? На одном ставится полная система с видеозаписью и видеоаналитикой, а на другом – только просмотр и видеоаналитика. Вообще, глупость несусветная, т.к. и на том, и на другом, надо разжимать видео, т.е. использовать мощные процессоры. Мы специально провели опрос среди тех, у кого встречали такую архитектуру – ну, ЗАЧЕМ?
Вменяемым оказался только один ответ – для надежности, чтобы оператор не мог повлиять на видеозапись! Что ж, в нашей новой концепции видеопотоки тоже пишутся на отдельный компьютер, оператор тоже не имеет к ним прямого доступа, но мы еще добавили надежности, т.к. ограничили задачи этому записывающему устройству. Плюс уменьшили цену. Осталось только перенастроить мозги клиенту – предложить ему совместить понятия видеосервер и АРМ в одном ПК.
Тем более, если камер очень много. Например, для 100 камер обычно ставят 5 компьютеров (по 20) со всем функционалом на каждый. А с нашей арифметикой мы выделяем:
один ПК на постоянную видеозапись ста камер и два ПК на просмотр и анализ этих же 100 камер.
В более крупных системах типа Безопасного города это выглядит так:
Но ведь это же логично: оператору надо смотреть, а значит ему нужный мощный проц на распаковку видео, простому же видеомагнитофону нужны только диски.
Cпециализированные GOAL-центры:
Астана
Москва
Санкт-Петербург
Белгород
Екатеринбург
Иваново
Минск
Брест
Киев
Донецк
Одесса
Клайпеда
пос. Кибрай
Казань
Калининград
Кемерово
Киров
Кострома
Краснодар
Красноярск
Курск
Нижний Новгород
Новосибирск
Пенза
Петропавловск-Камчатский
Ростов-на-Дону
Тольятти
Ногинск
Уфа
Южно-Сахалинск
Челябинск
Ярославль
Мадрид
Владивосток
Владимир
Калуга
Набережные Челны
Брянск
Раменское
San Mateo
Баку
Ульяновск
Иркутск
Orry la Ville
Актобе
Дмитров
Новгород Великий
Днепропетровск
Кишинев
Самара
Смоленск
Новокузнецк
Оренбург
Омск
Коломна
Светлоград
Алматы
Темиртау
Липецк
Ижевск