Что такое rps видео

Что такое rps видео

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

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

Почему так произошло? Основной протокол интернета IPv4 имеет в своем распоряжении 4,22 миллиарда адресов и случилось то что в 2011 году эти адреса закончились. Но количество пользователей растет, раньше в интернет мог выйти только компьютер. А сейчас? Для выхода из сложившейся ситуации основная часть пользователей интернета были подключены на так называемые NAT-сервера. Этот сервер имеет снаружи нормальный публичный адрес, к нему подключены абоненты, которые имеют уже не «белый», а «серый» IP-адреса. Абонент свободно может получить доступ к ресурсам интернета имея 2серый»-IP, но вот получить доступ со стороны сети интернет к абоненту уже проблема. Адрес абонента мы уже не видим.

Что из себя представляет «облако»?

Как работает удаленное видеонаблюдение через интернет

Начнем с описания серверов:

Для просмотра будет доступен только второй поток.

Давайте разберемся в работе этой системы на живом примере.

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

Задействуем DSS

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

Источник

Как получить RTSP поток с IP-камеры

Установка IP камеры — удобный способ получения картинки в любом месте, где присутствует подключение к интернету. Но для работы с видеопотоком необходим соответствующий инструментарий. Существуют различные варианты поддерживаемых IP камерами протоколов трансляции, и один из самых удобных среди них — RTSP.

Что такое RTSP

Аббревиатура расшифровывается как Real Time Streaming Protocol, или потоковый протокол реального времени. Это решение прикладного уровня для работающих с мультимедийным контентом систем. Оно позволяет удаленно контролировать поток информации с медиасервера (которым может выступать IP камера), отправлять команды управления этим потоком. Также, если на сервере хранятся файлы записей, RTSP обеспечивает к ним доступ.

Сжатие в рамках RTSP не выполняется. Транспортные протоколы и способ инкапсуляции передаваемой информации он тоже не устанавливает. Упрощенно процесс выглядит следующим образом:

По умолчанию сервер RTSP работает на порту 544. Захват видео и звука можно выполнять с помощью таких программ, как плееры VLC или Windows Media Player, и иных клиентов с поддержкой протокола. Существуют также веб-приложения и программные решения для трансляции потока в интернет (например, стриминга на YouTube).

Как получить поток RTSP с камеры

Чтобы просматривать видео и захватывать звук посредством этой технологии, необходима поддержка RTSP на стороне камеры. Этот протокол поддерживают многие образцы имеющихся на рынке устройств, но в документации возможность описана не всегда.

Если поддержка заявлена, то в инструкции будут прописаны настройки для доступа к трансляции. Они представляют собой ссылку для подключения в следующем формате:

Здесь rtsp — указание на протокол подключения, addr — IP-адрес камеры. Через двоеточие указан порт. Последний может отличаться, если в настройках указан отличный от «дефолтного».

Перед выполнением дальнейших инструкций рекомендуем прочитать как узнать IP камеры видеонаблюдения.

Далее следуют user и password — логин пользователя и пароль для подключения (их может и не быть). После них указываются дополнительные параметры, который у разных камер могут отличаться.

Как узнать RTSP адрес

Ссылка может находиться в документации или явно указываться в веб-интерфейсе устройства. Если известно, что камера точно поддерживает RTSP, но параметры нигде явно не указаны, их придется выяснять:

Для последнего потребуется ПО Onvif Device Manager, компьютер под управлением Windows и сама камера.

Важно: она и ПК должны находиться в одной сети.

Device Manager умеет конфигурировать видеосервер, захватывать видео и так далее, но самая важная функция этой программы в данном случае — WS-Discovery, обнаружение устройств в сети.

Когда вы скачали и поставили программу, нужно сделать следующее:

Смотрим видео через RTSP

Самый простой способ получить rtsp поток с ip камеры — использовать проигрыватель VLC. В нем достаточно пройти в пункт меню «Медиа — Открыть URL…», перейти в появившемся диалоге на вкладку «Сеть» и вставить в строку сетевого адреса rtsp-ссылку.

Для стриминга в интернет, существуют различные способы. Один из самых доступных — использовать связку VLC и программы OBS Studio, это бесплатное и достаточно простого решения.

Существуют также онлайн-сервисы вывода изображения в интернет, например, webcam.io, и прочие. Спецификации протокола открыты, поэтому специалисты могут написать и собственный проигрыватель RTSP.

Где купить IP-видеокамеру

Видео по теме

Источник

7 способов отобразить видео с RTSP IP-камеры на веб-странице и 2 в мобильном приложении

В этой статье покажем 7 технологически разных способов отображения видеопотока с IP-камеры с поддержкой RTSP на web-странице браузера.

Браузеры, как правило, не поддерживают RTSP, поэтому поток будет конвертироваться для браузера через промежуточный сервер.

Способ 1 — RTMP

RTMP протокол браузеры не поддерживают, но его поддерживает старый добрый Flash Player, который работает неплохо, хоть и не во всех браузерах, и может отобразить видеопоток.

Код плеера в этом случае будет построен на Action Script 3 и выглядеть примерно так:

rtmp://192.168.88.59/live — это адрес промежуточного сервера, который заберет RTSP видеопоток с камеры и конвертирует его в RTMP

rtsp://192.168.88.5/live.sdp — это RTSP адрес самой камеры.

Немного избыточный вариант кода плеера на Flex и AS3 доступен здесь.

Способ 2 — RTMP с оберткой HTML5

Желающих кодить на Action Script 3 все меньше. Специально для этого придуман способ с HTML5 оберткой, которая позволяет управлять RTMP-плеером из JavaScript. В этом случае флэшка подгружается на HTML-страницу только для того чтобы отобразить картинку и выдать в динамики звук.

Полный код плеера находится здесь. А выглядит это так:

Способ 3 — RTMFP

Протокол RTMFP также работает внутри флэш плеера. Разница с RTMP в том, что RTMFP работает поверх протокола UDP и тем самым является более пригодным для получения трансляции с низкой задержкой.

Код плеера на AS3 в этом случае полностью идентичен используемому в RTMP, добавлена одна буква F в строке протокола подключения к серверу.

Для порядка дадим скриншот с RTMFP

Способ 4 — RTMFP c оберткой HTML5

Этот способ идентичен пункту 2, с той разницей, что мы при инициализации в JavaScript устанавливаем RTMFP протокол для использования в нижележащей флэшке (swf-объекте).

Способ 5 — WebRTC

В данном случае Flash не используется совсем и видеопоток проигрывается средствами самого браузера, без использования сторонних плагинов. Это работает и в Android Chrome и Android Firefox — мобильных браузерах, где Flash не установлен. WebRTC дает самую низкую задержку — менее 0.5 секунды.

Автоматически определяется поддержка WebRTC, и если поддерживается то поток играет по WebRTC.

Способ 6 — Websockets

WebRTC и Flash не покрывают все браузеры и платформы. Например, в браузере iOS Safari эти технологии не поддерживаются.

На iOS Safari можно доставить видеопоток по транспорту Websocket (TCP соединению между браузером и сервером). В этот туннель можно завернуть сконвертированный с RTSP видеопоток. После того, как бинарные данные придут их можно декодировать с помощью JavaScript и отрисовать на Canvas HTML5-элементе.

Именно этим занимается Websocket — плеер при работе в браузере iOS Safari, а его код снаружи выглядит также:

Это чем-то похоже на подход с флэшкой, когда под HTML5 лежит swf-элемент. В данном случае, под HTML5-страницей лежит не swf-объект, а JavaScript-приложение, которое тянет данные по вебсокетам, декодирует и отрисовывает на Canvas в нескольких потоках.

Так выглядит RTSP поток на Canvas в браузере iOS Safari

Способ 7 — HLS

При конвертации RTSP в HLS, видеопоток разбивается на сегменты, которые благополучно скачиваются с сервера и отображаются в HLS-плеере.

В качестве HLS-плеера мы используем video.js. Код плеера можно скачать здесь.

Как выглядит плеер:

Способ 8 — Android приложение, WebRTC

Приложение забирает поток с сервера по WebRTC. Задача сервера в этом случае — сконвертировать RTSP в WebRTC и скормить мобильному приложению.

Java-код плеера для Android находится здесь и выглядит так:

Тестовое мобильное приложение плеера можно установить из Google Play, а исходники приложения скачать здесь.

Так выглядит воспроизведение RTSP потока по WebRTC на планшете Asus под Android:

Способ 9 — iOS приложение, WebRTC

Приложение также как и в случае Android забирает поток с сервера по WebRTC.

Скачать исходный код плеера для iOS можно здесь.

А из App Store можно установить тестовое приложение, которое использует показанные выше куски кода. Его работа с RTSP-потоком выглядит так:

Результаты

Подведем итоги и объединим полученные результаты в табличку:

Для тестирования мы использовали сервер Web Call Server 5, который конвертирует RTSP поток для раздачи в 9 перечисленных направлениях.

Ссылки

Web Call Server 5 — сервер для раздачи RTSP потока
Flash Streaming — пример swf приложения, проигрывающего потоки по RTMP и RTMFP. Способы 1 и 3.
Source — исходный код swf приложения на Flex / AS3.

Player — пример web-приложения, которое воспроизводит RTSP поток по RTMP, RTMFP, WebRTC, Websocket. Способы 2,4,5,6.
Source — исходный код веб-плеера.

HLS плеер — пример web-плеера, играющего HLS. Способ 7.
Source — исходный код HLS плеера.

Android плеер WebRTC — пример мобильного приложения, которое играет поток по WebRTC. Способ 8.
Source — исходный код мобильного приложения.

iOS плеер WebRTC — пример мобильного приложения, которое играет WebRTC поток. Способ 9.
Source — исходный код мобильного приложения.

Источник

Как оценить ёмкость сервиса и не упасть под нагрузкой

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

Ответы можно получить аналитическим путём, адресовав вопросы опытному разработчику/DevOps/SRE/админу. Достоверность оценки зависит от огромного числа факторов: начиная с темпов наполнения системы функциональностью и графа взаимосвязей между компонентами и заканчивая временем, которое эксперт с утра провёл в пробке. Чем сложнее система — тем больше сомнений в адекватности аналитической оценки.

Меня зовут Максим Куприянов, вот уже пять лет я работаю в Яндекс.Маркете. Сегодня я расскажу читателям Хабра, как мы учились оценивать ёмкость наших сервисов и что из этого вышло.

Выходим на позицию

Структура компонентов Маркета довольно сложна, так что мы решили оценить ёмкость только самых крупных и дорогих в масштабировании сервисов. При этом ежедневное количество запросов на них должно явно зависеть от размера дневной аудитории Маркета (daily active users, DAU). Почему именно от DAU? Да потому что аналитики, строя прогнозы на месяцы и годы вперёд, всегда подсчитывают будущий размер аудитории, а мы этим приятным обстоятельством как раз и воспользуемся.

Теперь поговорим о том, без чего точно не построить объективные оценки: о метриках работы сервиса. Если число запросов на сервис зависит от DAU — значит, нам точно понадобится метрика «число запросов в секунду» (requests per second, RPS). Кроме того, чтобы оценить качество работы сервиса, нужно знать процент ошибок и времён ответа (таймингов запросов). Ошибкой будем считать ответ с HTTP-кодом от 500 и выше. Ошибки из диапазона 4xx клиентские и в нормально работающей системе обычно ничего не говорят о проблемах сервиса. Что касается таймингов, то тут у нас принято рассчитывать и хранить 80-й, 95-й, 99-й и 99,9-й перцентили времён ответа, но конкретный набор может немного отличаться от сервиса к сервису.

Итак, у нас есть метрики частоты запросов, процента ошибок и набор перцентилей времени ответа. А ещё мы знаем DAU сервиса на каждый день и на будущие периоды (в виде прогноза). Учитывая, что усреднённые паттерны поведения пользователей не слишком меняются день от дня, допустим следующее: зная RPS в наиболее активный период рабочего дня (пиковое RPS), мы можем спрогнозировать пиковое RPS на будущие периоды, при условии, что у нас есть прогноз DAU. И наоборот: если мы знаем, сколько запросов в секунду выдерживает система, не нарушая договорённости по времени ответа и проценту ошибок, то можем оценить, какой объём аудитории сможем обслужить, т. е. знаем ёмкость системы.

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

Стреляем по мишени

Вот классический подход к решению задачи: собираем тестовый полигон, берём access-логи системы из production-окружения, делаем из них патроны и обстреливаем систему, повышая частоту запросов, пока полигон не покажет значимую деградацию по таймингам ответа и/или ошибкам. В этот момент останавливаемся и фиксируем частоту запросов (то самое RPS). Победа? Как бы не так. И вот почему:

Имитируем реальность

Общая идея такова: скопируем часть трафика с балансеров на площадку, где соберём полный аналог production-окружения в миниатюре и, регулируя объём копируемого трафика, станем искать точку деградации. Идея красивая, и мы в Маркете так делаем, чтобы протестировать новую функциональность и сравнить поведение новых версий со старыми. Мой коллега Евгений в подробностях рассказывал об этом — см. раздел о теневом кластере. Но тут тоже есть очевидные сложности:

Тестируем прямо в production

И вот мы наконец добрались до вкусного. Для каждого тестируемого компонента мы поднимаем в production отдельный экземпляр, частоту запросов на который регулируем с балансировщика с высокой точностью. В прошлый раз читатели нас спрашивали: «Хватает ли возможностей HAProxy? Не возникала ли необходимость писать что-то своё?». Так вот, это тот самый редкий случай, когда не хватило и пришлось писать.

При этом есть отдельный сервис, который пристально наблюдает за метриками нагружаемого экземпляра и, когда показатели приближаются к критическим величинам, прикрывает вентиль на балансировщике, уменьшая частоту запросов. Если же сервис работает в допустимых границах — вентиль, наоборот, открывается. Конечно, пороги таймингов и ошибок при нагрузке живого сервиса заметно более консервативны (обычно на 5–10%), чем на полигоне, ведь мы не хотим ухудшать взаимодействие с пользователями. Таким образом, нагружаемый экземпляр всегда работает на пределе возможностей. Эти показатели мы фиксируем. А дальше уже арифметика: мы знаем количество ядер сервиса под нагрузкой на каждый момент, знаем DAU за вчерашний день. Из этого считаем утилизацию, резервы по ёмкости и варианты поведения системы при отключении той или другой локации. Всё это ложится в базу, откуда строятся красивые графики. На основании этих данных при снижении ёмкости ниже заложенного порога срабатывают алерты.

Давайте посмотрим на графики

Вот так мы регулируем подачу трафика на тестируемый инстанс. Шаг может быть любым кратным 1 RPS. На графике для иллюстрации смоделирован подъём с трёхминутным интервалом: сначала от 650 до 1K RPS с шагом 50, а потом от 200 до 1K с шагом 100. Напомню, это настоящий пользовательский трафик, на который клиенты получали ответы.

Здесь показано RPS на три инстанса: один под нагрузкой и два контрольных. Для испытуемого искусственно задали верхний предел — 600 RPS. Сервис может и больше, но становится слишком неустойчивым и зависимым от внешних воздействий. Хорошо видно, что в первой половине дня запросы на сервис в среднем более тяжёлые и инстанс не может на приемлемых условиях достичь пиковой ёмкости, но ближе к вечеру всё приходит в норму. Всплески и пропуски на графике — это рестарты инстансов для выкладки релизов и прочих обновлений (все они под балансировкой, никто не пострадал). А ступенчатые корректировки RPS на испытуемом — как раз работа алгоритма, который ищет предел возможностей.

Хорошо видна частота запросов на сервис и нагрузка, которую может выдержать один инстанс.

А тут мы пересчитываем всё в проценты утилизации. На графике видно, что сервис был довольно сильно нагружен и при отключении одной из локаций возникли риски уйти за SLA. Но сейчас уже всё в порядке: в сервис добавили ресурсы, утилизация вернулась в приемлемые границы.

Таким образом, нагрузочное тестирование в production позволяет быстро оценить ёмкость системы и спрогнозировать потребление ресурсов на будущие периоды. При этом система фактически не добавляет заметных расходов и можно спокойно работать со stateful-сервисами, так как мы не порождаем новый трафик, а лишь аккуратно перераспределяем тот, что есть. Ну и напоследок: для работы, как правило, не требуется изменять код само́й подопытной системы, что позволяет тестировать даже legacy-приложения.

Рефлексируем

В Маркете эта методика работает уже не первый год, и мы можем поделиться наблюдениями и рекомендациями:

Источник