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

В апреле прошлого года по сети прокатился пресс-релиз о том, что Apple выкатывает поддержку WebRTC в браузерах Safari для Mac OS и iOS. С момента выхода пресс-релиза скоро пройдет ровно год, как Apple продолжает выкатывать WebRTC для Safari. Ждем.


Однако ждут не все. Кому-то требуется реал-тайм видео в Safari прямо сейчас и в этой статье мы расскажем как обходиться без WebRTC в браузере iOS Safari и Mac OS Safari и чем можно его заменить.

Аналоговое видеонаблюдение сегодня переходит от стандартного к высокому разрешению. Ведь нужно идти в ногу со временем! Когда мониторы и телевизоры уже давно преодолели «планку» Full HD, смотреть на них изображение с камер выдающих разрешение D1 (704х576) или даже 960H (960х576) просто моветон. Поэтому производители оборудования оперативно подсуетились и предложили пользователям сразу три стандарта аналогового видеонаблюдения высокой четкости: HDCVI, HDTVI и AHD.
Аналог остается в строю.

Я уже довольно давно хотел написать статью о скрипте для работы с камерой через DVRIP протокол, но обсуждение к недавней новости о Xiaomi побудило меня сначала рассказать о том, как я устроил видеонаблюдение у себя, а потом уже перейти к скриптам и прочему.

У нас было 2 пакета... Так, стоп, это не та история.
У нас было 2 роутера фирмы TP-LINK, выход в интернет за провайдерским NAT, камера наблюдения Partizan уже не помню какой модели (сойдет любая IP-камера, поддерживающая RTSP over TCP или DVRIP) и дешевый VPS за 4 евро с характеристиками: 2 core CPU 2.4GHz, 4GB RAM, 300 GB HDD, 100 Mbit/s port. А еще нежелание докупать к этому ничего, что стоило бы дороже патчкорда.

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

Так уж вышло, что с асинхронностью в мире серверного web ассоциируется все что угодно, но не PHP.

Ну потому что, ну вы знаете, вот эта умирающая модель, утечки памяти, да и вообще в PHP из коробки нет ничего, кроме stream_select() и stream_set_blocking().

Где-то там, на PECL, есть какой-то libuv, который в принципе всего лишь обертка для сишных функций оригинальной библиотеки, поэтому его использование как есть бросает вам некоторые вызовы. Да и вообще, кто в здравом уме будет этим заниматься?

Но если мы перестанем жить в мире PHP4 и немного вернемся в современные реалии, то увидим, что за последние годы дела несколько изменились. У нас появились такие интересные инструменты как ReactPHP и AmPHP, компоненты которых хорошо покрывают функционал Node.js, а наличие генераторов позволяет писать асинхронный код в удобном стиле, подобном async/await, избегая всех вот этих бесконечных коллбеков в коллбеках и километровых цепочек .then().then().then().

Так что поэтому сейчас, как мне кажется, практически нет тех задач из мира Node.js, которые не мог бы решить PHP. Но если таковые еще остались, то все упирется только в наличие каких-то отдельных библиотек, а не отсутствие возможностей как таковых.

It may surprise people to learn that the PHP standard library already has everything we need to write event-driven and non-blocking applications. We only reach the limits of native PHP’s functionality in this area when we ask it to poll thousands of file descriptors for IO activity at the same time. Even in this case, though, the fault is not with PHP but the underlying system select() call which is linear in its performance degradation as load increases.

amphp.org/amp/event-loop