Если при тестировании IP-камер не выкинули половину, то у клиента может развиться комплекс обманутых ожиданий
Дата публикации: 23.04.2018

И цена не определяет качество.


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

Сразу начнем со скандалов. К сожалению, мы находимся в конце пищевой цепочки (или к счастью), до нас доходит уже свершившийся факт того, что у клиента установлена наша система с какими-то камерами. Чем руководствовались при выборе камер и другого оборудования, мы не знаем. Но, т.к. у клиента появляется тяжелое недоумение в том, как всё это вместе работает, первое подозрение в неблагонадежности падает на российского разработчика. Это ведь только у нас руки не из того места растут.

недовольный клиент

Естественно, наша бригада наладчиков поднимается по тревоге, клиент стучит ногами и руками – требует должного качества. Попытки сказать ему «не наша вина» в этот момент не проходят, нужны веские доказательства. Тогда мы деинсталируем наше ПО, подключаем стандартные средства просмотра камер типа VLC или браузера и… И только при убедительной демонстрации на независимом оборудовании и совершенно чужом программном обеспечении можно начинать разговаривать с уже поставившим диагноз клиентом. Например, в этом проекте было крупное недовольство отсутствием синхронизации по времени видеопотоков. Как онлайн, так и в архиве часто шли сюжеты, где одни и те же люди на одном уже выходят из здания, а на другом еще только заходят. И так повсеместно. Рассинхронизация по времени доходила до минуты.

Причем, используются достаточно дорогие камеры фирмы «ACTi».

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

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

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

Большинство всех камер всех фирм плохо ли – хорошо обеспечивает объект видеонаблюдением, хоть это и нельзя сказать про их заявленные возможности. Но о последнем непривередливый заказчик никогда не узнает, если не будет вдаваться в подробности или пользоваться какими-то продвинутыми функциями. Например, если смотреть архив не по одной камере, а сразу скопом, то при использовании камер «Акти» (обещали не называть, но наболело!) сразу выявятся странные явления с переходом будущего в прошлое и наоборот.

Главное здесь – ожидания заказчика. При этом надо понимать, что большинство людей ассоциирует IP-камеры с аналоговым форматом из 20-го века, который по своим характеристикам (кроме конечно разрешения) до сих пор во многом превосходит сегодняшние цифровые. Ну, или хотя бы с телевизионной картинкой, которую они видят каждый день у себя на телевизоре. Для чего мы это сказали – довольно трудно объяснить человеку, что охранное IP-видеонаблюдение в реальности «здесь пишет, здесь не пишет, а здесь селедку заворачивали».

Итак, нужно определиться с ожиданиями заказчика. Сразу пугать его селедкой – может уйти, подумает, что вы тупо неопытный специалист. Но в какой-то момент лучше все-таки спросить его: как он относится к отставанию видео, несинхронным потокам, расхождению с картинкой звука, к периодическим переподключениям, к развалу кадров… Может, он всего этого и не заметит или не придаст значения, а может и потребует денежку обратно. Вот как тут поступить?

В общем, тонкости маркетинга – не наш конек. Факт в том, что некоторые клиенты все-таки придают значение характеристикам. И, по-правильному, нужно уточнить у клиента его ожидания, перечислив весь круг проблем, которые могут возникнуть, если просто поставить камеры – без их тщательного отбора и тестирования. А далее по списку:


1. Допустимо ли большое время рассинхронизации потоков видео?
В большинстве камер этот параметр не превышает нескольких секунд. Однако, не факт, что вы нарветесь на большинство, потому что оно в данном случае не зависит от цены. А расхождение времён может составлять минуты. Верхний ролик тому пример.

Что делаем? Тестируем сразу не менее 10 камер, которые направляем на один и тот же секундомер. Смотрим каждые два часа, какое время каждая показывает. И так в течение не менее двух дней - отставание может накопиться непредсказуемо. Почему 10? - Важно тестировать под нагрузкой – идеально сразу то число камер, которое будет установлено на объекте.


2. Допустима ли вообще рассинхронизация потоков видео?
Даже при одной-двух секундах несогласованности видеоканалов может попасться клиент, которого не удовлетворят объяснения: так ведут себя все IP-камеры.

Что делаем? С недавнего времени в протоколе RTP, да и не только, появились пакеты RTCP (Real-Time Transport Control Protocol). Для кого-то это игра аббревиатур, а для кого-то серьезный инструмент для синхронизации видеопотоков. Если камеры поддерживают RTCP, то по их временным меткам можно производить синхронизацию как в реальном времени, так и для записи в архив.

Только, к сожалению, некоторые фирмы эту фичу не поддерживают, даже такие распространенные в России как Hikvision, LTV, Evidance – официально ответили. И не факт, что те, кто заявляет поддержку (Beward, UBQT, Axis и другие), действительно её обеспечивают на микросекундном уровне или вообще имеют таковую. Что делать, такова реальность - всё надо тестировать! 

Что делаем? Нужно, во-первых, взять софт видеонаблюдения, который работает с RTCP (не путать с RTSP) и провести тесты с записью в архив показа камерами микросекундного таймера. Через пару дней выборочно проверить 10 разных временных точек – микросекунды на всех камерах должны совпадать!

Но здесь могут быть еще засады:

- RTCP работает только по протоколу UDP – самому нелюбимому у провайдеров, ибо по нему легче всего «ломать», не будем вдаваться в другую тему. Посему все IP-камеры должны быть в одной – своей – подсетке или надо как-то договариваться с провайдерами, через которых идет трафик.

- Если камеры находятся где-то далеко и(или) их трафик идет через массу сетевых устройств (хабов), то вы будете иметь дело с непредсказуемыми задержками, достигающими десятков секунд. Такое же может возникнуть, если какой-то маршрутизатор неправильно настроен или начинает «тупить» по прошествию лет или изначального брака. Если рассинхронизация достигает десятков секунд, то мало какой софт с компьютером способны удержать в своей памяти большое количество (к тому же часто многомегапиксельных кадров, к тому же с большого количества камер), чтобы нивелировать чье-то отставание.

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

Кардинальный выход для требовательного клиента – ставить не IP, а аналоговые камеры, например, HD-SDI или HD-TVI.


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

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

Что делать:

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

Естественно, микрофонам на IP-камерах нужен RTCP по UDP. Обязательная поддержка разработчиком софта такого протокола. Из положительных факторов: длинные линии связи и задержки по ним не особо влияют на качество синхронизации, потому что звук занимает значительно меньше места в кэше. И даже минуту можно подогнать, если на нее кто-то задержался.

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

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


4. Нужна ли синхронизация звука с видео?
Это еще один нелегкий вопрос, не смотря на то, что по отдельности видео- и аудиопотоки вы уже согласовали. Увы, клиенту может не понравится такое кино, где артикуляция губ не соответствует речи. Особенно, когда она идет вообще в видимой тишине. (Как, однако, красиво сказано!)

Тут четко нужно понимать, что онлайн просмотр-прослушивание всех камер и микрофонов будет идти со скоростью самого отсталого элемента. Это как в групповом забеге – оценивается по приходу последнего бегуна. Поэтому внимание следует уделить каждому микрофону, каждой камере. Уже пришедшие данные будут ждать последнего, чтобы выйди наружу синхронизированными. Производители софта обычно не делают каких-то указателей на тот плешивый элемент, который портит всё стадо электронных устройств. Хотя по логам это видно.

Здесь многое зависит от софта. Он может давать возможность синхронизации отдельный группы камер и микрофонов, что значительно снижает вероятность долгих задержек. Но, как правило, все ориентируются по последнему бойцу, и это в лучшем случае – в 90% программ для видеонаблюдения данного функционала вообще нет. Часто мы встречаем случаи, когда клиент без всякого тестирования подключил какой-то левый IP-микрофончик с запасом на будущее, и даже уже не помнит о нём. А вся структура камер и микрофонов ориентируется именно на эту овечку и тормозит.

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


5. Есть ли требования к разборчивости человеческой речи.
Народ насмотрелся шпионских фильмов и считает, что из любой помеховой галиматьи можно вычленить человеческий голос. А если заказчик сУрьезный, то у него уже есть и специальный софт для шумо-очистки, ну куда без этого?

Весь этот дорогой арсенал бесполезен, если звук сжат до уровня потоковых кодеков. Там уже нечего чистить – только удалять сам звук. Клиент покупает крутой микрофон, а в записи сплошные кваканья. И звонит телефон, кто говорит, заказчик? – Недоволен он!

99,99% всех потоковых аудиокодеков созданы для записи и прослушивания предобработанного звука – качественной музыки. В этот мелкий контейнер помещают уже то, что в чистке не нуждается. С записью человеческой речи на удалении такой вариант не пройдет. Там будет больше шумов, чем человеческих слов. Поэтому звук надо писать без сжатия в полном формате, пригодном для избирательного прослушивания, дальнейшей фильтрации шумов и помех. К счастью, он весит в сотни раз меньше видео, поэтому быстро не съест жесткий диск. Подробнее о качественной прослушке

Но на рынке большинство IP-микрофонов или IP-камер идет с встроенным сжатием на борту. Перед применением поинтересуйтесь спецификацией и ознакомьте с ней заказчика, чтобы у него не было иллюзий.


6. Будут ли использоваться сетевые рабочие места?
Выше мы говорим лишь о первичном сервере, куда приходят данные непосредственно с видеокамер и микрофонов, а ведь есть еще и сетевые клиенты у этого сервера. И чаще именно они являются рабочими местами «зрителей» и «слушателей». Т.е. надо не только принять, но и передать все пришедшие в разное время потоки. И так, чтобы у клиентских, как правило, более слабых компьютеров, не возникало проблем ни со слухом, ни со зрением. Туда все данные должны априори приходить предподготовленными, даже если используются аналоговые устройства. Это отдельная песня – как тестировать сетевое ПО видеонаблюдения, сегодня мы говорим лишь про оконечное и сетевое оборудование. К сожалению, эта тема и так длинна.

Кроме адекватного ПО, умеющего дробить аудио на кадры и передавать в каждом кадре аудио и видео еще и точное время оцифровки, нужно правильно рассчитать топологию сети. Это отдельная наука, посильная администраторам сетей, хотя и есть ряд ПО, позволяющего это сделать своими силами. В начале каждый проводок между любыми сетевыми устройствами должен быть помечен своей пропускной способностью согласно ТТХ этих сетевых устройств. Далее необходимо просчитать нагрузку на каждом таком участке согласно всему пути прохождения (в первую очередь, видеопотоков) от точки выдачи до точек приема. Естественно, с учетом всех ответвлений во все принимающие участие в видеонаблюдении рабочие места. Без топологии сети и расчета загрузки трафиком на каждом участке сетевая система может работать только на честном слове!

Вернее, работать она будет, но качество такой работы привязывается к претенциозности клиента. Обычно в госкомпаниях всем «по барабану», а в частных наоборот – будут считать каждый кадр. Здесь есть обманные маневры для привередливых, но тупых клиентов. На камерах можно включить адаптивный бит-рейт с приоритетом по скорости. Тогда видео пойдет с отличной скоростью, и даже с качеством. Но качество продержится только до тех пор, пока перед несколькими камерами не будет никакой активности. Как только начнется движуха по многим из них, изображение рассыплется. Так случилось в аэропорту Домодедово во время взрыва, где стояло супер дорогое оборудование, но на слабой сетке. Записать момент теракта удалось только одному банкомату, у которого была встроенная камера с кодеком MJPEG.

видео кодек mjpeg

Пусть не теракт, но происшествие на объекте заказчика тоже может случиться (иначе зачем ставится система видеонаблюдения?), и опять же вопрос – как заказчик отнесется к записи, сплошь состоящей из одних квадратиков вместо изображения? Может - с пониманием, а может – и с возмущением. Честнее все-таки предупредить! К тому же проблема с низкой пропускной способностью часто будет проявляться на уличных камерах, когда перед их «глазами» начнут колбасить деревья и трава от ветра или свалившийся с небес снега.

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

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

Но и правильная топология сети - не панацея, т.к. она предполагает учет лишь самих систем видеоконтроля. Часто эту же сеть использует предприятие для других целей. Поставил какой-нибудь охранник себе фильм из сети (порно в 4К) – и сетка подсела. Правильнее требовать от заказчика создания отдельной сети, причем не только путем программной маршрутизации, но и физически – проложить еще одну витую пару и поставить еще по сетевой карте в каждый компьютер.

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


7. Будет ли задействован элементарный видеодетектор?
Вопрос почти риторический – ну, не писать же пустые стены. Но решается он с разной степенью стоимости. Причем, оплата идет за глупость – самая дорогая часть любого проекта. Попробуйте запустить на компьютере два кинофильма высокого разрешения. Посмотрите, какие начинаются тормоза! А распаковать в реальном времени 3 или 300 (как рекламируется) потоков тяжеленного кодека H.264 сможет не каждый процессор. Хотя последняя фраза не совсем верна, и это тоже часть запудривания мозгов некоторых маркетологов. По факту процессоры распаковывать будут и 1000 потоков, так что судебных претензий не предъявишь. Но скорость может упасть до 0,… кадров в секунду. Вы ставите клиенту софт на кучу камер, а он еще и недоволен!

Компании, которые давно занимаются разработкой софта для видеонаблюдения, скорее всего, давно оптимизировали его под многопроцессорный код. Увы, чаще всего на рынке встречается лишь последовательное исполнение кода. Распараллеливание процессов – труд тяжкий и неблагодарный, требует особо сильных программистов и имеет массу подводных камней. Есть версии, что компьютерные железки и операционные системы сами этим занимаются. Но они все чаще разбиваются о выявление скрытых ошибок в своей архитектуре. Недавно Интел вслед за AMD официально признал эту пакость, заплатка для которой стоила порядка 40% производительности. Все-таки такую процедуру надо делать индивидуально для каждой программы, а не одну на всех. Т.е. лучше искать софт с параллельным кодом, который потянет распаковку хотя бы 10 - 16 видеопотоков высокого разрешения в риалтайме.

Но, в принципе, можно и не заморачиваться, опять же в зависимости от ожиданий клиента. Обычному видеодетектору не нужен полный кадр, можно с одной и той же камеры взять два потока: один большой (высокое разрешение) и сжатый – на запись (без пересжатия), другой маленький и несжатый – на видеодетекцию, ну, и другой анализ.

GOALcity изображение полное разрешение vss

Фраза «и другой анализ» подразумевает также работу видеоаналитики. Одно дело, что вам нужно писать или не писать – в зависимости от активности в кадре, другое дело, вам нужно анализировать поведение объектов - и тогда важно оценивать каждый пиксел самого высокого разрешения. Поэтому сами решайте, как обмануть клиента. Если Вы ему скажете, что ваша система больше 10 IP-камер не потянет на одном компе, то он, скорее всего, решит, что у вас слабая система. И выберет другого инсталлятора, который предложит 300 камер на один комп.

В общем, выбор у вас небольшой. Поэтому берем с каждой видеокамеры два потока, и отсюда сразу необходимость в тестировании двухпоточного режима: один большой и сжатый, обычно H.264, – на запись, другой маленький и несжатый, желательно MJPEG и где-то 320х240 или 640х480, – на видеодетекцию, ну, и другой анализ. Не всякая камера вообще поддерживает MJPEG или даже H.264 (что значительно реже). И все камеры, в которых задекларирована такая поддержка, работают по-разному. Опять же нужно длительное тестирование - смотрим, как они держат свою скорость на обоих потоках. По нашей практике, на этом тесте мы выкидываем 15 – 20% всех видеокамер, не взирая на титулы.

настройки Goal


8. Нужен ли высокоточный видеодетектор и (или) реальная видеоаналитика?
Как вы уже догадались, много камер мы проанализировать не сможем, если будем разжимать H.264 или тем более H.265. Естественно, что все презентации и втирание очков клиентам производятся при небольшом числе камер. Вот чел насмотрелся умных алгоритмов и, если решился купить, ожидает от них какой-то адекватной работы. И! Но! А как?!…

Выход есть, если в качестве второго потока все-таки брать полноразмерное разрешение, но только более-менее распакованное, чтобы сильно не задействовать процессоры, т.е. в кодеке сжатия MJPEG. Это позволит на правильной сетке прокачать уже камер 30, а то и 40 – в зависимости от мощности мощного компа (это не тавтология, слабомощный не потянет и 20). И снова проблема. У подавляющего числа многомегапиксельных камер нет возможности выдавать два полноразмерных потока – только один большой и один маленький. Ну, может и не у подавляющего – мы привыкли к Китаю у наших клиентов, поэтому так говорим, но во всех случаях надо смотреть спецификацию. И тут мы снова лукавим (ну, как уже вы понимаете, в этой теме сплошное лукавство), чаще производитель камер не указывает, что у него есть ограничение по выбору разрешающей способности в нескольких потоках. Поэтому выход одЫн – опять тестирование.

И тестирование непростое, а с пристрастием. Даже, если выставить полнокадровое разрешение на всех потоках удалось в настройках камеры, это совсем не факт, что вообще возможна такая работа в длительном режиме. Тут вы должны выкинуть еще 25% от купленных или полученных на предварительное тестирование камер. И не спорьте с нами! Мы на этом не одну собаку съели. Затыкающийся от перенапряжения процессор камеры начинает выдавать такие чудеса, что, если не увидите, не поверите. Проявлений может быть много от банального – через пару дней камера заткнется, пока не перезагрузишь, до экзотического – битые кадры, постоянные переподключения, застывшие картинки… В общем, тестирование и еще раз тестирование!

битые кадры видео



9. Как отнесется клиент к провалам в записи?
Наверное, самое сложное, чтобы объяснить. Мы называем это в шутку «скрытые возможности». Некоторые камеры периодически отказывают в доступе, и что они в это время делают – одному создателю известно. У нас, конечно, есть предположения, но это тема отдельной статьи. Похоже, что они по какой-то причине перезагружаются, видимо, чтобы исправить какой-то обнаруженный в себе недуг. Мы сами много лет производили подобные устройства и тоже грешили этим втихаря от клиента. Да что там мы, практически каждый чип имеет встроенную функцию автоматической перезагрузки. Т.е. даже производитель камер может не знать о том, что происходит. Ну, или настало время сеанса с ЦРУ, Моссад, Седьмым бюро и прочими заинтересованными организациями – всё может быть. 
 
Мы, хоть и с трудом верим в последнее, но такое  впечатление создается, потому что картина отказов серийная: за какой-то короткий промежуток времени – до нескольких часов – идет сразу множество перезагрузок, как будто кто-то что-то пытается передать. Ну, если оставить в покое теорию заговора, то такое поведение можно отнести и к ухудшению параметров электронных компонентов. Причиной может быть перегрев, переполнение памяти, зацикливание IP-стека при общении с компьютером и прочие непригодности. 

Отдельно отметим: Если IP-камера выходит в Интернет, то её периодически ломают электронные боты, здесь даже к доктору не ходи. 

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

Теперь, если в момент переподключения происходит следующая перезагрузка камеры, то ПО отрубает её и выжидает какой-то более длительный период до следующей попытки подключения. У всех разные тайм-ауты, но допустим, первое переподключение пойдет через минуту, тогда следующее уже через 5, и т.д.  Почему нельзя переподключаться постоянно? – Можно, и в наших настройках можно выставить любое время. Но этот процесс имеет определенную долю приоритета, он влияет на быстродействие всей системы. Если вы не хотите, чтобы из-за одной плохо работающей камеры тормозили все, то не уменьшайте периоды. 

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

Поэтому, чтобы не было неприятных терок с клиентом, всё тестируем. Естественно, без доступа к Интернету, чтобы исключить фактор влияния миллионов интернет-роботов, жаждущих переполнить ваш IP-стек. 

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

Если камера совсем дешевая, то перед её установкой надо предупредить заказчика о возможности выпадения записи: если не сразу, то после некоторого старения. Ну, явно там характеристики электронных компонентов специально не тестировались. Мы же много печатных плат в своё время заказывали и прекрасно знаем, что их можно сделать и подешевле, и подороже. В первом случае 30% будет идти с какими-нибудь полудохлыми кондёрами, которые накроются через год. Классика рынка!

Если камеры не из нижней ценовой категории, то, заплатив за бренд, клиент рассчитывает на приличное качество. Особенно, если много заплатив. Поэтому прежде чем поставить начинаем тестировать. Выявить некондицию проще всего на высоких температурах. Сразу скажем, тестировать на низких - мало смысла, как может кому-то показаться наоборот. В помещении или специальной камере нужно создать экстремальную обстановочку свыше 30 градусов по Цельсию и в ней погонять IP-камеры в полной нагрузке хотя бы пару дней. Что такое полная нагрузка? – Особо подчеркнем, чтоб не пропустили этот вопрос, нужно подключить как минимум два потока в самом высоком разрешении, что позволяет IP-камера. И, если она дорогая, то логичней будет подцепить сразу три и более клиентов на неё. Для этого не нужны специальные программы - описанные здесь методы доступны каждому – обычным браузером откройте три и более вкладок с адресом камеры на просмотр видео. 

Нет возможности создать высокую температуру – да просто подключите три и более клиентских просмотров видео, и так погоняйте пару дней. Если заметили хоть одно переподключение, находите любую записывающую программу – их полно бесплатных, у нас тоже на сайте можно взять – и включайте несколько потоков видеозаписи с одной камеры. Через пару дней проверяйте качество архива. Желательно, чтоб в программе был плеер, умеющий показывать неоднородность записей. 

поток запись видео

 
И сразу будет видно, где пустые пробелы, а также на каком конкретно потоке видео они проявляются. Таким образом, сразу понятно, какой кодек и(или) разрешение нельзя использовать вообще или можно лишь с учетом периодических выпадений в записи.  

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

_____________________________________________________________________________________


К сожалению, к нам часто приходит инсталлятор, когда все камеры уже установлены, вернуть или даже снять ничего нельзя - поможите за ради Бога! Естественно, клиент валит всё или на софт, или на кривые ручки инсталлятора. И в этой связи мы понаделали в своем софте массу костылей типа галок:
- разрешить работу с нестабильными параметрами,
- детектировать повторение картинки и переподключаться,
- отслеживать и выкидывать битые кадры
и т.д.

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

А при этом с нас еще требуют качественную видеоаналитику, а то и распознавание образов. Кроме того, что это процесс сильно зависит от естественных помех, надо еще обучать нейросети распознавать проблемы видеокамер. 

_____________________________________________________________________________________


Мы превысили все немыслимые квоты на количество слов для одной Интернет-статьи, поэтому оставшиеся 50% проблем опишем в следующей. Извините, если она получилось чересчур эмоциональной – всё описанное не просто тесты, а долгие и порой тяжелые терки с клиентами.

Напоследок только скажем, что не всё так плохо. По нашей практике 60% клиентов вообще не вникает в описанные проблемы, и их всё устраивает, еще 20% возмущается по первости, но со временем приходит в понимание. И есть всего лишь других 20% въедливых людей или фирм, с которыми приходится долго возиться, наглядно демонстрируя причину проблемы по каждому параметру.

Конечно, можно скидывать эту нудную двадцатку, просто возвращая деньги. Но уходить от технических проблем для разработчика – себя не уважать. В Интернет полно всякой информации про Спецлаб: некоторые, кто пишет что-то плохое, они не обязательно проклятые конкуренты, в новых постоянно развивающихся технологиях действительно может что-то пойти не так. Но невозможно найти такого человека, которого бы мы оставили наедине с его (или нашими) проблемами – мы добиваемся положительного результата до тех пор, пока клиент готов его получить. Обидно только, что мы не можем помочь клиенту, если проблема в камерах, микрофонах или сетевом оборудовании, которые он не может по административным причинам заменить. Но надо хотя бы четко показать суть проблемы, чтобы не было плохого осадка.

В следующей статье мы поговорим об основных засадах при выборе комплектующих ПК. 

DB query error.
Please try later.