P2p как настроить на компьютере
Обновлено: 05.07.2024
Надо сказать, что так называемая облачная технология далеко не нова, ее основы заложены еще в эру начала работы с распределенными вычислениями, и существует практически столько, сколько прошло времени с создания первых мейнфреймов, т.е. как минимум полвека. Но в последние лет так 5-10 облачные технологии активно пошли в народ и стали применяться в абсолютно бытовых областях. При помощи облаков дистанционно включают печки, выключают холодильники, управляют автомашинами и поездами, сохраняют семейные фотографии, и даже создают семьи (ведь большинство соцсетей и всевозможных мессенджеров активно используют облачные технологии).
Сегодня мы не будем углубляться в сами технологии Облака, благо вещь это многогранная и описывать облачные технологии можно очень долго. Поэтому остановимся на краткой информации.
Во-первых, такие системы хранения и передачи данных наиболее устойчивы от внешнего воздействия, при падении одного сервера не пропадает абсолютно вся информация (тем более, что она чаще всего дублируется). Во-вторых, для многих устройств, в таком случае, не потребуется иметь белый IP адрес (для удаленного доступа к нему) достаточно иметь соответствующую прошивку или предустановленное программное обеспечение, чтобы можно было получить доступ к устройству через облачные сервера.
Облачное видеонаблюдение
В случае с видеонаблюдением все достаточно просто:
- Начинка камер видеонаблюдения и видеорегистраторов прошивается таким образом, чтобы при включении функции облачного видеонаблюдения, данные поступали в сеть Интернет на конкретное Облако.
- На стороне клиента, в телефоне устанавливается программа, которая также осуществляет обмен данными через сервера в глобальной сети.
- Каждая камера и регистратор имеют (или получает во время соединения) свой идентификационный номер, который можно посмотреть в админ панели камеры или регистратора. Затем этот номер или QR код считывается приложением на телефоне, и, вуаля, мы смотрим на то что происходит у нас дома, находясь за тысячу километров. А уж если камера имеет микрофон, то даже и слышим.
Типы облачного видеонаблюдения.
Облачное видеонаблюдение подразделяется на два подтипа.
Первый тип облачного видеонаблюдения подразумевает (помимо просмотра) хранение данных в облаке. И используется он в основном для IP камер видеонаблюдения. Далее поэтапно.
Подключение облачного видеонаблюдения в IP камерах RF-LINK.
Этап 1-й.
Подключаем камеру к локальной сети (локальная сеть должна иметь доступ в Internet) или напрямую к сети Internet. Смотрим IP адрес камеры, указанный на корпусе. Запускаем IE и заводим этот адрес в верхнюю адресную строку.
Предварительно может понадобиться установка плагина, Internet Explorer может запросить эти действия. Скачиваем, устанавливаем предварительно закрыв IE. После этого запускаем IE заново и заводим логин admin, пароль 123456.
После входа в админ панель переключаемся во вкладку Конфигурация/ Сеть / P2P.
Ставим галочку P2P появляется надпись DANALE, это наше P2P облако, после чего нажимаем сохранить и обновить, иногда требуется перезайти в админ панель или пару минут подождать чтобы увидеть заветный QR код, который нам потребуется дальше.
Оставляем QR код на экране, либо распечатываем его. Переходим ко второму этапу.
Этап 2-й
Находим в маркете приложение DANALE
Для того чтобы добавить камеру нажимаем плюсик в правом верхнем углу. Появится меню настройки сети. Камера в этот момент должна находиться в локальной сети. Выбираем Далее для поиска камер в сети, либо жмем внизу на кнопочку считывания QR кода.
После чего, присвоив камере имя, попадаем в такое или похожее окно. Пиктограммы внизу означают запись видео на телефон, съемки скриншотов на телефон, аудио запись если есть. Кнопка облака обозначает подключение платного P2P облачного хранилища.
Непосредственно в окне самой камеры можно настроить запись изображения и видео, качество изображения, увеличить изображение и если камера с PTZ функциями –даже управлять движением вращения. Также можно посмотреть когда и в какое время срабатывал датчик движения, если же камера хранит данные на облаке, посмотреть эти моменты.
Таким образом всего в два этапа можно настроить облачное видеонаблюдение в IP камерах при помощи программы DANALE.
Второй тип облачного видеонаблюдения (используемый в основном для видеорегистраторов, причем как сетевых, так и цифровых) - это только наблюдение, и удаленное управление видеорегистратором и соответственно подключенными к нему камерами. В случае с Pan Tilt Zoom камерами: это могут быть вращение, увеличение, фокусировка. Для обычных камер это может быть: яркость, цветокоррекция, цифровое увеличение. В вариофокальных моторизованных камерах: оптическое увеличение и фокусировка, настройка баланса белого. В некоторых моделях, доступно удаленное включение и выключение датчиков движения. Для камер с микрофоном доступны функции интеркома. Обычно доступны еще и удаленный просмотр записей и скриншотов на экране телефона.
Данный тип облачного видеонаблюдения используется в большинстве видеорегистраторов различных производителей.
Итак, мы знаем, что второй тип не подразумевает хранения видеозаписей на облачных серверах. Встает вполне закономерный вопрос. Почему?
В основном по двум причинам. Первая причина – то что видеорегистратор имеет свое локальное и бесплатное хранилище: жесткий диск. Не всегда имеет смысл дублировать на облачное хранилище содержимое всего жесткого диска. Вторая причина – меркантильная, оплата на облачных серверах взимается за каждую камеру. Поэтому, если вы все-таки, хотите работать и с регистратором и облачным хранилищем, то либо ищем то оборудование, которое поддерживает данную функцию из коробки, на сегодняшний день таких производителей раз два и обчелся (правда платить все равно придется за каждую камеру). Либо используем всевозможные уловки, так, например, если вы подключите видеорегистратор к камерам не напрямую, а через коммутатор, в некоторых случаях у Вас получится сохранять данные на жесткий диск в видеорегистратор и подключать камеры при помощи облачной программы для камер, отдельно для сохранения каждой в облако. К сожалению подобная схема не везде и не всегда корректно работает. Также есть видеорегистраторы, которые позволяют делать подмену IP прямо в меню видеорегистратора, для того чтобы получить доступ напрямую к каждой камере. Но опять же в случае с облачным наблюдением подобная операция не всегда и не везде срабатывает.
Теперь опишем поэтапно подключение видеорегистратора RF-LINK к облачному видеонаблюдению.
Подключение облачного видеонаблюдение в видеорегистраторах RF-LINK.
Этап-1й
Включить видеорегистратор, подключенный к сети интернет.
Далее мы можем подключить регистратор к монитору, либо получить доступ к нему с компьютера. Названия меню практически те же самые. Главное посмотреть QR код.
Как настроить систему видеонаблюдения по протоколу P2P?
Р2Р (peer-to-peer) – пиринговый протокол связи, отличается более эффективным использованием полосы пропускания канала передачи сигнала и высокими показателями отказоустойчивости.
Основная область применения – это удаленное видеонаблюдение за различными объектами. Камеры видеонаблюдения с Р2Р технологией передачи изображения используются преимущественно в бытовых небольших и средних частных системах видеонаблюдения, выполняя некоторые функции систем безопасности и тревожной сигнализации.
Идентификация камеры в сети интернет осуществляется по уникальному ID коду, который присваивается устройству производителем. Поиск и использование производится при помощи специального программного обеспечения и облачных сервисов.
Не всегда начинающие пользователи знают, как осуществить подключение системы видеонаблюдения по протоколу P2P. В этой статье мы расскажем, как это делается.
У каждого производителя свой P2P сервер и своё приложение для подключения к серверу. Это значит, что IP камеры одних производителей не смогут подключиться к P2P серверу другого производителя оборудования для видеонаблюдения, т.к. не пройдет идентификацию. И наоборот.
Для настройки P2P необходимо:
1. Наличие интернета, т.к камера обращается через интернет к серверу.
2. Принять меры безопасности. Для этого нужно сменить логин и пароль, не оставляйте admin/admin по умолчанию, т.к. узнав ваш ID, злоумышленник сможет смотреть видео с ваших камер без вашего ведома. Подобрать ID посторонним лицам не так уж и сложно.
3. По умолчанию, мобильные приложения используют дополнительный поток для отображения, что в общем то логично, ведь экран смартфона маленький и отображать основной поток нереально.
Рекомендуемый битрейт для дополнительного потока это 256-512 Кбит при разрешении CIF, VGA, D1. Проверьте ваши настройки потока, т.к зачастую пропускной способности мобильного интернета не хватает, одно дело скачивать что либо, другое непрерывно получать видеопоток. Битрейт напрямую влияет на задержку и отображение картинки.
5. Если,на вашем объекте нет интернета, вы не сможете использовать P2P, но можете подключаться локально через Wi-Fi, для этого в мобильном приложении выберите вариант подключения по IP адресу.
6. Воспроизведение архива, при подключении через P2P. Как уже было сказано, мобильное приложение отображает дополнительный поток, Но в архив пишется основной поток высокого разрешения, это значит, что смартфону потребуется больше усилий и больше интернет трафика, чтоб выкачивать архив, что может сказываться на долгом отклике, и постоянной подкачке.
Ниже приведем несколько примеров подключения по P2P протоколу.
Оборудование OMNY PRO
IP камеры и видеорегистраторы NVR серии OMNY PRO поддерживают P2P подключение на мобильных платформах iOS и Android. Устройства поддерживаются в программе NetVideo для Windows, с подключением через P2P.
Для подключения с мобильного, нужно скачать и установить бесплатное приложение EasyLive.
Перейдя по этой ссылке, вы сможете просмотреть инструкцию на русском языке и другие программы для OMNY.
Но вернемся к настройкам. Приложением EasyLive отсканируйте QR код который находится на WEB странице устройства в превью (снизу значок QR).
QR код содержит в себе идентификатор, в поле логин/пароль введите реальный данные вашего устройства.
Убедитесь, что ваш смартфон и OMNY устройство имеют доступ в интернет, в настройках сети указаны работающие DNS.
Оборудование OMNY Base
IP камеры серии OMNY Base поддерживают P2P подключение только на мобильных платформах iOS и Android.
Для подключения требуется скачать и установить бесплатное приложение Danale. Далее в Danale отсканируйте QR код который находится в камере на WEB странице (Система/системная информация).
Оборудование Dahua
Устройства Dahua поддерживают P2P подключение как на мобильных платформах, так и на компьютере.
Для подключения на мобильном устройстве требуется скачать и установить приложение DMSS.
Есть различные версии приложения, DMSS Lite, DMSS plus, DMSS HD. Рекомендуем ставить DMSS Lite. Платная версия plus практически не отличается, версия HD для планшетов, но и Lite тоже с планшетом работает.
По ссылке есть подробная информация и другие программы для Dahua.
Настройка осуществляется по принципу, как показано на картинке.
Для настройки в первую очередь P2P нужно включить на устройстве. В зависимости от релиза, вкладка может находится в разных местах, но как правило она находится в настройках сети.
Для включения кликните Enable. Успешное соединение покажет статус online или connect success
Затем Приложением DMSS сканируйте QR код.
Для работы на компьютере: Установите программу Smart-PSS на вкладке добавления устройств нужно выбрать тип P2P и вручную ввести серийный номер, который находится в том же месте где QR код.
Для работы с P2P рекомендуется установить сетевые параметры устройства в режим DHCP.
Настройка P2P с компьютера
Для быстрого подключения к системе видеонаблюдения через Интернет по технологии P2P с ПК или ноутбука выполните 5 простых шагов:
При первом подключении в зависимости от версии используемой операционной системы компьютера может появиться всплывающее окно с предложением установить надстройку DevFetcher. Если такое предложение появилось, нажмите «Установить» («Разрешить») и установите ее.
3. На экране появится запрос на ввод данных для авторизации. При необходимости выберите в правом верхнем углу окна браузера язык интерфейса, после чего введите данные:
• Серийный номер – введите MAC-адрес (вводится без тире, посмотреть его можно на верхней панели рекордера под QR-кодом или в разделе «Главное меню→Информация→Сеть», например 0018AE5F168E);
• Введите логин – введите логин (по умолчанию admin);
• Введите пароль – введите пароль (по умолчанию 123456).
Пример заполнения полей:
Серийный номер: 0018AE5F168E
Введите логин: admin
Введите пароль: 123456
Если поля для ввода данных авторизации не отображаются, необходимо выполнить настройки браузера.
5. В окне браузера отобразится изображение с первой камеры в режиме онлайн. Для просмотра одновременно нескольких камер на экране выберите необходимый вариант с помощью кнопок настройки режима отображения расположенных под изображением с камеры.
Вы можете изменять параметры отображения камер, делать необходимые настройки системы, просматривать архивные записи и т.д. Работая через web-интерфейс системы, Вы получаете абсолютно все те же возможности, что и при прямом доступе к ней.
Автор: Александр Трищенко
Я расскажу о своем хобби — организации видеотрансляций в браузере по технологии WebRTC (Web Real-Time Communication — веб-коммуникация в режиме реального времени). Этот проект с открытым исходным кодом Google активно развивает с 2012 г., а первый стабильный релиз появился в 2013 г. Сейчас WebRTC уже хорошо поддерживается самыми распространенными современными браузерами, за исключением Safari.
Технология WebRTC позволяет устроить видеоконференцию между двумя или несколькими пользователями по принципу P2P. Таким образом, данные между пользователями передаются напрямую, а не через сервер. Впрочем, сервер нам все равно понадобится, но об этом скажу далее. Прежде всего, WebRTC рассчитана на работу в браузере, но есть и библиотеки для разных платформ, которые тоже позволяют использовать WebRTC-соединение.
Если мы используем WebRTC, мы решаем следующие проблемы:
- Снижаем расходы на содержание серверов. Серверы нужны только для инициализации соединения и чтобы пользователи обменялись сетевой информацией друг о друге. Также они используются для рассылки каких-то событий, например, оповещений о подключении и отключении пользователей (чтобы информация на каждом клиенте была актуальной).
- Увеличиваем скорость передачи данных и уменьшаем задержки при передачи видео и звука — ведь сервер для этого не нужен.
- Усиливаем приватность данных: нет третьей стороны, через которую шел бы поток данных (конечно, за исключением шлюзов, через которые проходят данные до выхода в сеть).
Инициализация соединения
JavaScript Session Establishment Protocol
Соединение инициализируется по протоколу JavaScript Session Establishment — сейчас есть только черновик, который описывает спецификацию этого решения. В нем описывается:
Как это работает? Есть уровень браузера, который позволяет клиентам непосредственно обмениваться медиаданными, и есть уровень сервера-маяка (signaling server), на котором происходит остальное взаимодействие между клиентами:
Session Description Protocol
Для протокола описания сессий (SDP — Session Description Protocol), который позволяет описать информацию о конкретном пользователе, есть уже утвержденная спецификация RFC 4556.
SDP описывает следующие параметры:
- v= (версия протокола; сейчас версия всегда 0);
- o= (идентификаторы создателя/владельца и сессии);
- s= (имя сессии, не может быть пустым);
- i=* (информация о сессии);
- u=* (URL-адрес, используемый WWW-клиентами, с дополнительной информацией о сессии);
- e=* (e-mail лица, ответственного за конференцию);
- p=* (номер телефона лица, ответственного за конференцию);
- c=* (информация для соединения — не требуется, если есть в описании всех медиаданных);
- b=* (информация о занимаемой полосе пропускания канала связи);
- одна и более строк с описанием параметров времени (пример см. ниже);
- z=* (установка для временной зоны);
- k=* (ключ шифрования);
- a=* (одна или несколько строк с описанием атрибутов сессии, см. ниже).
SDP-информация о каком-либо клиенте выглядит примерно так:
Interactive Connectivity Establishment (ICE)
Технология ICE позволяет подключиться пользователям, находящимся за межсетевым экраном. Она включает в себя четыре спецификации:
- RFC 5389: Session Traversal Utilities for NAT (STUN).
- RFC 5766: Traversal Using Relays around NAT (TURN): Relay Extensions to STUN.
- RFC 5245: Interactive Connectivity Establishment (ICE): A Protocol for NAT Traversal for Offer/Answer Protocols.
- RFC 6544: TCP Candidates with Interactive Connectivity Establishment (ICE)
STUN — клиент-серверный протокол, который активно применяется для VoIP. STUN-сервер здесь считается приоритетным: он позволяет маршрутизировать UDP-траффик. Если мы не сможем воспользоваться STUN-сервером, WebRTC попытается подключиться к серверу TURN. Также в списке есть RFC по самому ICE и RFC по TCP-кандидатам.
Реализация клиента для ICE-серверов в WebRTC уже предустановлена, так что мы можем просто указать несколько серверов STUN или TURN. Более того, для этого при инициализации достаточно просто передать объект с соответствующими параметрами (далее я приведу примеры).
GetUserMedia API
Одна из самых интересных частей WebRTC API — GetUserMedia API, который позволяет захватывать аудио- и видеоинформацию непосредственно с клиента и транслировать ее другим пирам. Этот API активно продвигает Google — так, с конца 2014 г. Hangouts работает полностью на WebRTC. Также GetUserMedia полноценно работает в Chrome, Firefox и Opera; есть также расширение, которое позволяет работать с WebRTC на IE. В Safari же эта технология не поддерживается.
Интересно, что раньше GetUserMedia API позволял транслировать экран, но сейчас этой возможности нету — есть только custom-решения с помощью дополнений, или же в Firefox можно включить соответствующий флаг на время разработки.
Сейчас у GetUserMedia есть следующие возможности:
- выбор минимального, “идеального” и максимального разрешения для видеопотока, что подразумевает возможность изменять разрешение видео в зависимости от скорости подключения;
- возможность выбрать любую из камер на телефоне;
- возможность указать частоту кадров.
Все это настраивается очень просто. Когда мы вызываем GetUserMedia API, мы передаем туда объект, имеющий два свойства — “audio” и “video”:
Где video, там также может стоять “true” — тогда настройки будут по умолчанию. Если будет стоять “false”, то аудио или видео будет отключено. Мы можем конфигурировать видео — указать ширину и высоту. Или же мы можем, например, установить минимальную, идеальную и максимальную ширину:
А вот так мы выбираем камеру, которую хотим использовать (“user” — фронтальная, “environment” — задняя):
Также мы можем указать минимальную, идеальную и максимальную частоту кадров, которая будет выбираться в зависимости от скорости подключения и ресурсов компьютера:
Таковы возможности GetUserMedia API. С другой стороны, в нем явно не хватает возможности определить битрейт видео- и аудиопотока и возможности как-либо работать с потоком до его фактической передачи. Также, конечно, не помешало бы вернуть возможность трансляции экрана, присутствовавшую ранее.
Особенности WebRTC
WebRTC позволяет нам менять аудио- и видеокодеки — их можно указать непосредственно в передаваемой информации SDP. Вообще, в WebRTC используются два аудиокодека, G711 и OPUS (выбираются автоматически в зависимости от браузера), а также видеоформат VP8 (WebM от Google, который отлично работает с HTML5-видео).
Технология WebRTC в той или иной степени поддерживается в Chromium 17+, Opera 12+, Firefox 22+. Для других браузеров можно использовать расширение webrtc4all, но лично мне не удалось его запустить на Safari. Есть также С++ библиотеки для поддержки WebRTC — скорее всего, это говорит о том, что в будущем мы сможем увидеть реализации WebRTC в виде настольных приложений.
Для обеспечения безопасности используется DTLS, протокол безопасности транспортного уровня, который описывается в RFC 6347. А для соединения пользователей, находящихся за NAT и межсетевыми экранами, как я уже говорил, используются TURN и STUN-серверы.
Маршрутизация
Теперь рассмотрим подробно, как осуществляется маршрутизация с помощью STUN и TURN.
Traversal Using Relay NAT (TURN) — это протокол, который позволяет узлу за NAT или межсетевым экраном получать входящие данные через TCP или UDP-соединения. Это уже старая технология, поэтому в приоритете стоит использование Session Traversal Utilities for NAT (STUN) — сетевого протокола, позволяющего установить только UDP-соединение.
Для обеспечения отказоустойчивости есть возможность выбрать несколько STUN-серверов, как это сделать, показано в инструкции. А протестировать подключение к STUN- и TURN-серверам можно здесь.
STUN- и TURN-серверы работают следующим образом. Допустим, есть два клиента с внутренними IP и с внешним выходом в сеть через межсетевые экраны:
Алгоритм работы с ICE-серверами
- Обеспечить доступ к STUN-серверу на момент инициализации RTCPeerConnection. Можно использовать публичные STUN-серверы (например, от Google).
- Слушать событие инициализации подключения и в случае успеха начинать передачу потока.
- В случае ошибки выполнить запрос к TURN-серверу и постараться соединить клиентов через него.
- Позаботиться о достаточной пропускной способности TURN-сервера.
Производительность и скорость передачи видеопотока
-
720p at 30 FPS: 1.0
Сильнее всего влияет на производительность WebRTC траффик, который нужно выделять на трансляцию видео. Если в трансляции участвуют всего два пользователя, то можно организовать без проблем хоть FullHD, в случае же видеоконференции на 20 человек у нас будут проблемы.
Вот, например, результаты, полученные с MacBook Air 2015 (4 Гб оперативной памяти, процессор Core i на 2 ГГц). Просто реализация GetUserMedia грузит процессор на 11 %. При инициализации соединения Chrome-Chrome процессор загружен уже на 50 %, если три Chrome — на 70 %, четыре — полная загрузка процессора, а пятый клиент приводит уже к тормозам, и WebRTC в итоге вылетает. На мобильных браузерах, конечно, еще хуже: мне удалось связать только двух пользователей, а при попытке подключения третьего все стало тормозить и соединение оборвалось.
Масштабирование и решение проблем
Итак, что мы имеем? На каждого пользователя конференции надо открывать свое UDP-соединение и передавать данные. В итоге на трансляцию 480p-видео со звуком одному пользователю нужно 1-2 мебагита, и 2-4 мегабита в случае двухсторонней связи. На железо транслирующего ложится большая нагрузка.
Проблема производительности решается путем использования прокси-сервера (ретранслятора), который будет получать данные от вещающего, если это конференция, и раздавать их всем остальным. Если нужно, для этого можно использовать не один сервер, а несколько.
Важно учесть программные ограничения — мы можем подключить не более 256 пиров к одному инстансу WebRTC. Это лишает нас возможности использовать, например, какой-нибудь громадный и дорогой инстанс на Amazon для масштабирования, т. ч. рано или поздно нам придется связывать между собой несколько серверов.
CreateOffer API
Как это все работает? Есть API CreateOffer(), который позволяет создать SDP-данные, которые мы будем отправлять:
CreateOffer — promise, который после создания offer позволяет получить непосредственно localDescription, поместить в него offer и использовать его далее как SDP-поле. sendToServer — абстрактная функция для запроса к серверу, где написано имя нашей машины (name), имя целевой машины (target), тип offer и SDP.
Хочу сказать пару слов о сервере: для данных целей очень удобно использовать WebSocket. Как только кто-то подключается, мы можем заэмитить событие и добавить на него слушателя. Также нам будет довольно просто эмитить свои события с клиентом.
GetUserMedia API в действии
В реальной жизни все можно сделать немного проще — мы можем обратиться к GetUserMedia API. Вот как тогда выглядит инициализация звонка:
Здесь мы хотим передать и видео и звук. На выходе получаем промис, который принимает в себя объект mediaStream (это и есть поток данных).
А вот так мы отвечаем на звонок:
Когда кто-то хочет ответить на звонок, он получает наш offer (getRemoteOffer— абстрактная функция, которая получает наши данные с сервера). Затем getUserMedia инициализирует потоковую передачу, а об onaddstream и addstream я уже сказал. setRemoteDescription — мы это инициализируем для нашего RTC и указываем его в качестве offer’а и передаем ответ (answer). send the answer… → тут мы просто описываем процесс передачи offer на сервер, после чего происходит установление связи между браузерами и начало трансляции.
Клиент-серверная архитектура для WebRTC
Как все это выглядит, если мы масштабируем через сервер? Как обычная клиент-серверная архитектура:
Здесь между транслирующим и веб-сервером, ретранслирующим поток, есть WebSocket-соединение и RTCPeerConnection. Остальные устанавливают RTCPeerConnections. Информацию о транслирующем можно получить пулингом, можно сэкономить на количестве WebSocket-соединений.
Способов масштабирования такой архитектуры пока не очень много, и все они похожи. Мы можем:
- Увеличить количество серверов.
- Разместить серверы в зонах наибольшего скопления целевой аудитории.
- Обеспечить избыточную производительность — ведь технология еще активно развивается, так что возможны сбои в работе.
Повышаем отказоусточивость
Во-первых, для повышения отказоустойчивости имеет смысл разделить сервер-маяк и сервер-ретранслятор. Мы можем использовать WebSocket-сервер, который будет раздавать сетевую информацию о клиентах. Сервер-ретранслятор будет общаться с WebSocket-сервером и транслировать через себя медиапоток.
Далее, мы можем организовать возможность быстрого переключения с одного транслирующего сервера на другой в случае отказа приоритетного
Для крайнего случая, можно предусмотреть и возможность установки прямого соединения между пользователями в случае отказа транслирующих серверов, но это годится только на тот случай, когда в нашей конференции участвует немного людей (точно меньше 10).
Отображение медиапотока
Вот пример, как мы можем отобразить поток, которым обменялись между клиентами:
onaddstream — мы добавляем слушателя. Когда добавляется слушатель, создаем элемент video, добавляем этот элемент на нашу страницу, а в качестве источника указываем поток. Т. е. чтобы увидеть все это в браузере, просто указываем source HTML5-видео как поток, который получили. Все очень просто.
В случае завершения звонка (метод endCall) мы проходим по элементам видео, останавливаем эти видео и закрываем peer connection, чтобы не было никаких артефактов и зависаний. В случае ошибки завершаем звонок так же.
Полезные библиотеки
Напоследок — некоторые библиотеки, которые вы можете использовать для работы с WebRTC. Они позволяют написать простой клиент в несколько десятков строк:
Возможности удаленного доступа сегодня безграничны, остается только выбрать способ подключения оборудования к интернету. Здесь, как вы догадались p2p сервис видеонаблюдения самый легкий способ добиться желаемого от видеокамер или видеорегистратора.
Достоинства P2P.
- Простота настройки. Нет необходимости покупать статические адреса или ddns и колдовать с пробросом портов, достаточно лишь задать ip адрес p2p камеры или видеорегистратора совпадающий с подсетью вашего маршрутизатора (шлюза).
- Работа с любыми платформами. Доступ к p2p видеонаблюдению осуществляется посредством специальных мобильных приложений, cms или vms клиентов для ПК, или просто через интернет браузер.
- Не требует затрат. Статические адреса или ddns требуют дополнительной ежемесячной оплаты, в то время как p2p cервера живут за счет производителей оборудования систем видеонаблюдения.
Недостатки.
Для p2p видеонаблюдения необходима хорошая исходящая скорость интернет соединения, так как связь с устройством происходит не напрямую, как в случае со статическим ip адресом, а через сервер, который сначала получает запрос на определенную команду, выгружает информацию с вашего устройства и только потом передает ее через клиент приложение.
P2P видеонаблюдение через 3g\4g сети.
P2P видеонаблюдение можно создать в любом месте, расположенном в зоне покрытия мобильного оператора. Для этого понадобится 3g\4g модем, роутер с поддержкой usb модема и внешняя антенна(усилитель) для улучшения сигнала.
Следующим шагом нам было необходимо задать регистратору подсеть роутера, по умолчанию роутер zyxel имеет внутренний ip адрес 192.168.1.1, значит регистратору присваиваем например 192.168.1.100.
Благодаря 4g усилителю сигнала мы получили 10 Mb\s исходящей скорости, чего в принципе достаточно для 14 видеокамер.
В конкретном примере мы подключали видеорегистратор по p2p серийному номеру, который позволяет нам просматривать устройство с любых мобильных платформ и интернет браузера. Минус заключается в том, что загрузка записанного материала происходит крайне медленно, поэтому для крупных систем p2p актуален только для онлайн просмотра c мобильных устройств.
Низкая скорость, но статика.
Как мы и говорили ранее статический адрес всегда выигрывает у p2p, при равных скоростях, так как здесь мы стучимся напрямую на web морду нашего устройства. Имея статический адрес работа с устройством возможна напрямую через интернет браузер, например если вбить его ip и порт 10.12.50.77:8888 или настроив специальный сms клиент на компьютере.
По статике в cms без проблем загрузились 11 видеокамер, возможен просмотр архива и его загрузка.
Через p2p приложение максимум, что удалось это вести просмотр 4-х видеокамер без торможения, просмотр видеоархива затруднителен и работает крайне не устойчиво.
При открытии всех видеокамер с сильным торможением открылось 6 потоков, просмотр нереален.
P2P IP камеры видеонаблюдения.
Все ip видеокамеры сегодня имеют встроенный p2p сервис, который может отличаться функционалом и адаптацией под различные платформы. Некоторые сервисы позволяют работать на всех типах платформ, например: мобильные приложения, сms для пк или через специальный клиент сайт, другие же поддерживают работу только на мобильных устройствах.
P2p камера может являться самостоятельной системой видеонаблюдения если у нее есть разъем под флэш-накопитель. Такая камера может вести видео запись, которая в свою очередь будет доступна через специальный мобильный p2p клиент.
Так же существуют мультимедийные ip камеры, имеющие на борту динамик и микрофон. Такое устройство может не только выводить звук с микрофона на клиент приложение, но и принимать звук из программы для выдачи его через динамик видеокамеры.
P2p облако.
Многие путают p2p сервис c p2p облаком, наивно полагая, что камера бесплатно может писать на облачный сервер. К сожалению это не так, p2p функционал поставляемый с камерами видеонаблюдения весьма ограничен, запись может вестись либо на жесткий диск видеорегистратора, либо на флэш-карту, к обоим накопителям возможно подключение через клиент приложение.
Для записи архива на надежный удаленный сервер существуют специализированные IT компании, например Ivideon, у которого можно заказать не только определенный объем хранилища, но и видеоаналитику. Ежемесячный платеж за облачное хранилище рассчитывается из количества видеокамер и необходимого архива.
Настройка.
Настройка P2P видеокамеры очень проста, главное понимать ключевые моменты:
›Видеокамера должна находиться в одной сети с маршрутизатором( роутером). Другими словами первые три значения ip адреса камеры и роутера должны совпадать. Пример: Роутер имеет адрес 192.168.0.1, значит видеокамера должна иметь например следующие значения 192.168.0. 10.
›Любая ip камера имеет уникальный cерийный номер, его так же следует указать в настройках программы при добавлении нового устройства.
Могут, если у этих устройств идентичный p2p сервис.
Да, если видеокамеры поддерживают протокол onvif.
Да, существуют p2p видеокамеры программные клиенты которых позволяют настроить push уведомления или рассылку писем на почту, например ivms 4500 от hikvision или idms lite от компании dahua.
Читайте также: