Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой. Rtsp в браузере

Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой

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

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

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

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

Низкая задержка (low latency) — это достаточно редкое требование для IP-камер и онлайн-трансляций. Необходимость работы с низкой задержкой появляется, например, в том случае, если источник видеопотока активно взаимодействует со зрителями этого потока.

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

Дилер живого интернет-казино за работой.

Обычная RTSP IP камера, как правило жмёт видео в H.264 кодек и может работать в двух режимах транспортировки данных: interleaved и non-interleaved.

Режим interleaved наиболее популярный и удобный, т.к. в этом режиме видео данные передаются по протоколу TCP внутри сетевого подключения к камере. Для того чтобы раздавать с IP-камеры в interleaved нужно всего лишь открыть / пробросить один RTSP-порт камеры (например 554) наружу. Плееру остаётся лишь подключиться к камере по TCP и забрать поток уже внутри этого соединения.

Вторым режимом работы камеры является non-interleaved. В этом случае соединение устанавливается по протоколу RTSP / TCP, а трафик идёт уже отдельно, по протоколу RTP / UDP вне созданного TCP-канала.

Режим non-interleaved более благоприятен для трансляции видео с минимальной задержкой, так как использует протокол RTP / UDP, но в то же время является более проблемным, если плеер расположен за NAT.

При подключении к IP-камере плеера, который находится за NAT, плеер должен знать — какие внешние IP-адреса и порты он может использовать для приема аудио и видео трафика. Эти порты указываются в текстовом SDP-конфиге, который передается камере при установке RTSP-соединения. Если NAT был вскрыт правильно и определены корректные IP-адреса и порты, то все будет работать.

Итак, для того чтобы забрать видео с камеры с минимальной задержкой, нужно использовать non-interleave mode и получать видеотрафик по UDP.

Браузеры не поддерживают стек протоколов RTSP / UDP напрямую, но поддерживают стек протоколов встроенной технологии WebRTC.

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

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

Сервер забирает поток с IP-камеры на себя по RTP / UDP и отдаёт подключившимся браузерам по WebRTC.

Технология WebRTC работает по протоколу UDP и тем самым обеспечивает низкую задержку по направлению Сервер > Браузер. IP-камера также работает по протоколу RTP / UDP и обеспечивает низкую задержку по направлению Камера > Сервер.

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

С другой стороны, при использовании сервера, включаются две коммуникационных ноги:1) Между зрителями и сервером2) Между сервером и камеройТакая топология имеет ряд «особенностей» или «подводных камней». Перечислим их ниже.

Подводный камень #1 — Кодеки

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

Например, если камера отдает 720p видеопоток в H.264, а подключается Chrome-браузер на смартфоне Android с поддержкой только VP8.

При включении транскодинга, для каждой из подключенных IP-камер должна быть создана транскодинг-сессия, которая декодирует H.264 и кодирует в VP8. В этом случае 16 ядерный двухпроцессорный сервер сможет обслужить только 10-15 IP камер, из примерного расчета 1 камера на физическое ядро.

Поэтому если серверные мощности не позволяют транскодировать планируемое количество камер, то транскодинга нужно избегать. Например обслуживать только браузеры с поддержкой H.264, а остальным предлагать использовать нативное мобильное приложение для iOS или Android, где есть поддержка кодека H.264.

Как вариант для обхода транскодинга в мобильном браузере, можно использовать HLS. Но стриминг по HTTP совсем не обладает низкой задержкой и в настоящий момент не может быть использован для интерактивных трансляций.

Подводный камень #2 — Битрейт камеры и потери

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

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

Подводный камень #3 — Битрейт зрителей и потери

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

Если IP-камера отправляет поток, превышающий возможности канала зрителя (например камера отправляет 1 Mbps, а зритель может принять только 500 Kbps), то на этом канале будут большие потери и, как следствие фризы видео или сильные артефакты.

В этом случае есть три варианта:

1. Транскодировать видеопоток индивидуально под каждого зрителя под требуемый битрейт.
2. Транскодировать потоки не для каждого подключившегося, а для группы группы зрителей.
3. Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах.

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

Второй вариант заключается в уменьшении нагрузки на CPU сервера с помощью групп транскодирования. Сервер создает несколько групп по битрейту, например две:

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

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

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

В результате мы рассмотрели три варианта подстройки под полосу пропускания зрителей. Если предположить, что одна транскодинг-сессия забирает 1 ядро сервера, то получаются следующая таблица нагрузки на CPU:

Из таблицы видно, что мы можем сместить транскодинговую нагрузку на камеру либо отдать транскодирование на сервер. Варианты 2 и 3 при этом выглядят наиболее оптимальными.

Тестирование RTSP как WebRTC

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

Для тестирования возьмем древнюю IP-камеру D-link DCS-2103 с поддержкой RTSP и кодеков H.264 и G.711.

Так как камера долго пролежала в шкафу с другими полезными девайсами и проводами, пришлось отправить ее в Reset, нажав и подержав кнопку на задней стороне камеры 10 секунд.

После подключения к сети, на камере загорелась зеленая лампочка и роутер увидел еще одно устройство в локальной сети с IP адресом 192.168.1.37.

Заходим в веб-интерфейс камеры и выставляем кодеки и разрешение для тестирования:

Далее заходим в сетевые настройки и узнаем RTSP адрес камеры. В данном случае RTSP-адрес live1.sdp, т.е. Камера доступна по адресу rtsp://192.168.1.37/live1.sdp

Доступность камеры легко проверить с помощью VLC плеера. Media — Open Network Stream.

Мы убедились, что камера работает и отдает видео по RTSP.

В качестве сервера для тестирования будем использовать Web Call Server 5. Это стриминг сервер с поддержкой RTSP и WebRTC протоколов. Он будет подключаться к IP-камере по RTSP и забирать видеопоток. Далее раздавать поток по WebRTC.

Вы можете установить Web Call Server на свой хост либо запустить готовый инстанс Amazon EC2.

После установки необходимо переключить сервер в режим RTSP non-interleaved, который мы обсуждали выше. Это можно сделать добавлением настройки

Эта настройка добавляется в конфиг flashphoner.properties и требует перезагрузки сервера:

Таким образом, у нас есть сервер, который работает по схеме non-interleaved, принимает пакеты от IP-камеры по UDP, и далее раздаёт по WebRTC (UDP).

Тестовый сервер находится на VPS-сервере, расположенном в датацентре Франкфурта, имеет 2 ядра и 2 гигабайта RAM.

Камера находится в локальной сети по адресу 192.168.1.37.

Поэтому первое что мы должны сделать — это пробросить порт 554 на адрес 192.168.1.37 для входящих TCP / RTSP соединений, чтобы сервер мог установить подключение к нашей IP-камере. Для этого в настройках роутера добавляем всего одно правило:

Правило говорит роутеру перенаправлять весь входящий на порт 554 трафик, на 37 — IP адрес.

Далее осталось узнать свой внешний IP-адрес. Это можно сделать за 5-15 секунд, погуглив по слову whatismyip

Если у вас дружелюбный NAT и вы знаете внешний IP-адрес, то можно начинать тесты с сервером.

Стандартный демо плеер в браузере Google Chrome выглядит так:

Чтобы начать играть RTSP поток, нужно просто ввести его адрес в поле Stream.В данном случае адрес потока: rtsp://ip-cam/live1.sdpЗдесь ip-cam это внешний IP адрес вашей камеры. Сервер будет пытаться установить соединение именно по этому адресу.

Тестирование задержек VLC vs WebRTC

После того, как мы настроили IP камеру и протестировали в VLC, настроили сервер и протестировали RTSP поток через сервер с раздачей по WebRTC, мы наконец-то можем сравнить задержки.

Для этого будем использовать таймер, который будет показывать на экране монитора доли секунды. Включаем таймер и воспроизводим видеопоток одновременно на VLC локально и на браузере Firefox через удалённый сервер.

Пинг до сервера 100 ms.Пинг локально 1 ms.

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

На черном фоне расположен исходный таймер, который показывает нулевую задержку. Слева VLC, справа Firefox, получающий WebRTC поток с удаленного сервера.

На этом тесте видим задержку на VLC в два раза больше чем задержку на Firefox + Web Call Server, не смотря на то, что видео в VLC воспроизводится в локальной сети, а видео, которое отображается в Firefox проходит через сервер в датацентре в Германии и возвращается обратно. Такое расхождение может быть вызвано тем, что VLC работает по TCP (interleaved mode) и включает какие-то дополнительные буферы для плавного воспроизведения видео.

Мы сделали несколько снимков чтобы зафиксировать значения задержки:

Результаты измерений выглядят так:

Таким образом, средняя задержка при тестировании с VLC в локальной сети составила 768 миллисекунд. В то время, как средняя задержка при проходе видео через удаленный сервер составила 341 миллисекунду, т.е. была в 2 раза ниже при использовании UDP и WebRTC.

Тестирование задержек RTMP vs WebRTC

Проведем похожие тесты с RTMP- плеером через Wowza сервер и одновременный тест с WebRTC-плеером через Web Call Server.

Слева забираем видеопоток с Wowza в RTMP-подключении. Справа забираем поток по WebRTC. Сверху абсолютное время (нулевая задержка).

Тест — 1

Тест — 2

Тест — 3

Тест — 4

Результаты тестирования можно вывести в уже знакомую таблицу:

Таким образом, средняя задержка при воспроизведении RTSP потока в Flash Player по RTMP составила 1683 миллисекунд. Средняя задержка по WebRTC 384 миллисекунды. Т.е. WebRTC оказалась в среднем в 4 раза лучше по задержке.

Ссылки

Технология WebRTCRTSP — RFCRTSP interleaved — RFC, 10.12 Embedded (Interleaved) Binary DataRTMP — спецификацияWeb Call Server — WebRTC медиасервер с поддержкой RTSPVLC — плеер для воспроизведения RTSP

Автор: 2030andme

Источник

www.pvsm.ru

Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой / Хабрахабр

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

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

Низкая задержка (low latency) — это достаточно редкое требование для IP-камер и онлайн-трансляций. Необходимость работы с низкой задержкой появляется, например, в том случае, если источник видеопотока активно взаимодействует со зрителями этого потока.

Обычная RTSP IP камера, как правило жмёт видео в H.264 кодек и может работать в двух режимах транспортировки данных: interleaved и non-interleaved.

Режим interleaved наиболее популярный и удобный, т.к. в этом режиме видео данные передаются по протоколу TCP внутри сетевого подключения к камере. Для того чтобы раздавать с IP-камеры в interleaved нужно всего лишь открыть / пробросить один RTSP-порт камеры (например 554) наружу. Плееру остаётся лишь подключиться к камере по TCP и забрать поток уже внутри этого соединения.

Итак, для того чтобы забрать видео с камеры с минимальной задержкой, нужно использовать non-interleave mode и получать видеотрафик по UDP.

Браузеры не поддерживают стек протоколов RTSP / UDP напрямую, но поддерживают стек протоколов встроенной технологии WebRTC.

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

Технология WebRTC работает по протоколу UDP и тем самым обеспечивает низкую задержку по направлению Сервер > Браузер. IP-камера также работает по протоколу RTP / UDP и обеспечивает низкую задержку по направлению Камера > Сервер.

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

С другой стороны, при использовании сервера, включаются две коммуникационных ноги: 1) Между зрителями и сервером 2) Между сервером и камерой Такая топология имеет ряд «особенностей» или «подводных камней». Перечислим их ниже.

Подводный камень #1 — Кодеки

Например, если камера отдает 720p видеопоток в H.264, а подключается Chrome-браузер на смартфоне Android с поддержкой только VP8.

Поэтому если серверные мощности не позволяют транскодировать планируемое количество камер, то транскодинга нужно избегать. Например обслуживать только браузеры с поддержкой H.264, а остальным предлагать использовать нативное мобильное приложение для iOS или Android, где есть поддержка кодека H.264.

Как вариант для обхода транскодинга в мобильном браузере, можно использовать HLS. Но стриминг по HTTP совсем не обладает низкой задержкой и в настоящий момент не может быть использован для интерактивных трансляций.

Подводный камень #2 — Битрейт камеры и потери

Подводный камень #3 — Битрейт зрителей и потери

Если IP-камера отправляет поток, превышающий возможности канала зрителя (например камера отправляет 1 Mbps, а зритель может принять только 500 Kbps), то на этом канале будут большие потери и, как следствие фризы видео или сильные артефакты.

1. Транскодировать видеопоток индивидуально под каждого зрителя под требуемый битрейт.
2. Транскодировать потоки не для каждого подключившегося, а для группы группы зрителей.
3. Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах.

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

Тестирование RTSP как WebRTC

Для тестирования возьмем древнюю IP-камеру D-link DCS-2103 с поддержкой RTSP и кодеков H.264 и G.711.

После подключения к сети, на камере загорелась зеленая лампочка и роутер увидел еще одно устройство в локальной сети с IP адресом 192.168.1.37.

Заходим в веб-интерфейс камеры и выставляем кодеки и разрешение для тестирования:

В качестве сервера для тестирования будем использовать Web Call Server 5. Это стриминг сервер с поддержкой RTSP и WebRTC протоколов. Он будет подключаться к IP-камере по RTSP и забирать видеопоток. Далее раздавать поток по WebRTC.

Вы можете установить Web Call Server на свой хост либо запустить готовый инстанс Amazon EC2.

После установки необходимо переключить сервер в режим RTSP non-interleaved, который мы обсуждали выше. Это можно сделать добавлением настройки

Камера находится в локальной сети по адресу 192.168.1.37.

Поэтому первое что мы должны сделать — это пробросить порт 554 на адрес 192.168.1.37 для входящих TCP / RTSP соединений, чтобы сервер мог установить подключение к нашей IP-камере. Для этого в настройках роутера добавляем всего одно правило:

Далее осталось узнать свой внешний IP-адрес. Это можно сделать за 5-15 секунд, погуглив по слову whatismyip

Если у вас дружелюбный NAT и вы знаете внешний IP-адрес, то можно начинать тесты с сервером.

Стандартный демо плеер в браузере Google Chrome выглядит так:

Тестирование задержек VLC vs WebRTC

Для этого будем использовать таймер, который будет показывать на экране монитора доли секунды. Включаем таймер и воспроизводим видеопоток одновременно на VLC локально и на браузере Firefox через удалённый сервер.

Пинг до сервера 100 ms. Пинг локально 1 ms.

Мы сделали несколько снимков чтобы зафиксировать значения задержки:

Тестирование задержек RTMP vs WebRTC

Слева забираем видеопоток с Wowza в RTMP-подключении. Справа забираем поток по WebRTC. Сверху абсолютное время (нулевая задержка).

Тест — 1

Ссылки

habrahabr.ru

RTSP поток через VLC

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

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

Применение

Большинство современных моделей камер видеонаблюдения, а также видеорегистраторов оснащены поддержкой описываемого протокола. Добавив к этим аппаратным составляющим такой надежный программный инструмент, как VideoLAN Client можно осуществить организацию системы для просмотра и сохранения видеоинформации без привлечения профессионалов в этой сфере.

Real Time Streaming Protocol – это прикладной потоковый протокол, описывающий команды, которые служат, чтобы управлять видеопотоком. Команды могут указать IP-камере либо серверу совершать различные действия, к примеру, начать транслировать поток, либо остановить передачу видеоданных.

В параметрах IP-камер может встречаться различное обозначение потокового варианта передачи информации. RTSP, как было сказано выше, является, по сути набором команд, с помощью которого осуществляется управление потоком. Аббревиатуры UDP и RTP указывают на транспортный механизм, применяемый при передаче видео.

Открытие RTSP-потока в VLC.

Чтобы поток с камеры отображался в окне проигрывателя, требуется предварительная настройка ВЛЦ. Выполняем ниже перечисленные пункты инструкции.

1. Запускаем VLC и заходим в меню «Инструменты», а затем выбираем «Настройки».
2. Переходим на вкладку «Ввод/кодеки», кликнув по соответствующему значку.
3. Переводим переключатель «Транспорт потока Live 555» раздела «Сеть» в положение «Использовать RTP поверх RTSP (TCP)» и нажимаем кнопку «Сохранить».
4. Открываем меню «Медиа» и заходим в пункт «Открыть URL…». В открывшемся окне добавляем ссылку на поток в поле «Введите сетевой адрес». IP-адресацию и другие параметры, из которых состоит адрес можно выяснить, обратившись к документации IP-камеры или видеорегистратора.
5. Воспроизведение RTSP-потока начнется вслед за нажатием на кнопку «Воспроизвести».

Таким простым способом может осуществляться организация просмотра камер в системах видеонаблюдения.

vlc-mediaplayer.ru

Browser-based WebRTC stream from RTSP IP camera with low latency

Reportedly, today there are hundreds of millions of installed video surveillance IP cameras. Surely, not all of them require low latency video playback. Video surveillance is typically static – the stream records to the storage and is analyzed to detect motion. There are plenty of software and hardware video surveillance solutions that do their job pretty well.

In this article we will introduce a slightly different usage of an IP camera, namely – online broadcasting in applications where low latency communication is required.

First of all, let’s deal with common misunderstanding of terminology when it comes to webcams and IP cameras.

Webcam is a video capturing device that does not have its own CPU and network interface. A web camera needs to be connected to a computer, a smartphone or any other device to use its network capabilities and CPU.

IP camera is a standalone device with its own network interface and a CPU to compress captured video and send it to the network. Therefore, an IP camera is a standalone mini-computer that can connect to the network and does not need any other devices for that. That is, it broadcasts directly to the Internet.

Low latency is a rare requirement to IP cameras and online broadcasts. The need for low latency connections arises when the source of a video signal interacts with viewers of this stream.

Low latency is often a requirement in various gaming usage scenarios. For example: real time video auction, live dealer video casinos, interactive online TV shows with an anchorman, remote quadcopter control and so on.

Live-casino dealer at work.

A typical RTSP IP camera usually compresses video to the H.264 codec and can work in two transport modes: interleaved and non-interleaved.

The interleaved mode is more popular and convenient, because in this mode video data are sent via the TCP protocol encapsulated inside the network connection to the camera. To broadcast a stream, from the IP camera in the interleaved mode you only need to open or redirect one RTSP port of the camera (for instance, 554). Then, a player simply connects to the camera via TCP and fetches the video stream already encapsulated to this connection.

The second mode of operation of a camera is non-interleaved. In this case, a connection is established via RTSP / TCP, and the traffic goes independently via the RTP / UDP protocol outside of the created TCP channel.

The non-interleaved mode is more suitable for low latency video broadcasting, because it uses the RTP / UDP protocol, but at the same time it causes more problems if the player is behind NAT.

When a player behind NAT connects to the IP camera, the player needs to know external IP addresses and ports it can use to receive audio and video traffic. These ports are specified in the text SDP config file passed to the camera when the RTSP connection is established. If NAT is correct and IP addresses and ports are identified correctly, everything will work just fine.

So to fetch a video from the camera with minimum latency we need to use the non-interleave mode and receive video traffic via the UDP protocol.

Browsers do not support the stack of RTSP / UDP protocols directly, but they do support the stack of protocols of the embedded WebRTC technology.

Technologies of browsers and cameras are very similar. In particular, SRTP is encrypted RTP. But to correctly broadcast video directly to browsers, an IP camera would require partial support for the WebRTC stack.

To eliminate this incompatibility we need an intermediate rebroadcasting server that will bridge the gap between protocols of the IP camera and browsers.

The server takes the stream from the IP camera via RTP / UDP and shares it to all connected browsers via WebRTC.

The WebRTC technology works via the UDP protocol and therefore allows low latency transmission in the Server > Browser direction. The IP camera also works via RTP / UDP and delivers low latency transmission in the Camera > Server direction.

The camera can handle only a limited number of streams due to its limited resources and bandwidth. Using a proxy allows to scale up broadcasting from the IP camera to a large number of viewers.

On the other side, when using the server we have two communication bridges:

1. between viewers and the server;
2. between the server and the camera.

Such topology has its own advantages and caveats. Let’s take a closer look at them.

Caveat #1 – Codecs

Codecs are one of obstacles that may result in reduced performance and jeopardized low latency operation.

For instance, the camera sends an H.264 video stream in 720p, while the viewer is the Chrome browser on the Android device with VP8 support only.

If transcoding is enabled, each connected IP camera require a transcoding session that decodes H.264 and encodes it to VP8. In this case, a 16-core 2-CPU server can handle just 10-15 IP cameras, approximately one camera per core.

That is why transcoding should be avoided if capabilities of a server do not allow to transcode signal from the required number of cameras. For instance, we can serve only H.264 compatible browsers and suggest to install a native application for iOS or Android that provides support for the H.264 codec.

As an option to bypass transcoding in a mobile browser we can also use HLS. But streaming via HTTP does not feature low latency capabilities and currently cannot be used for interactive broadcasts.

Caveat #2 – Bitrate of the camera and lost packets

The UDP protocol help fighting latency, but allows lost packets. Therefore, in spite of low latency, serious losses between the camera and the server may result in a damaged picture.

To prevent lost packets, make sure the stream generated by the camera has bitrate that fits the dedicated band between the camera and the server.

Caveat #3 – Bitrate of viewers and losses

Each viewer connected to the broadcast has its own download bandwidth.

If the IP camera sends a stream that exceeds resources of the viewer (for example, the camera sends 1 Mbps, and the viewer can only receive 500 Kbps), the channel will experience significant losses and as a result – many freezes and artifacts in the video.

In this case we have three options:

1. Transcode the video stream individually for each viewer for the requested bitrate.
2. Transcode streams for groups of viewers, not individually.
3. Preliminarily prepare streams from the camera in multiple resolutions and bitrates.

The first option with transcoding may not suit some viewers, because CPU resources will deplete after 10-15 of connected viewers. It is worth mentioning though that it is this option that results in maximum flexibility with maximum CPU usage. This is ideal when you broadcast streams to about 10 people geographically apart, each one receiving dynamic bitrate and low latency.

The second option reduces CPU load by enabling transcoding groups. The server creates several groups by bitrate, for example:

If a viewer lacks the required bandwidth, it automatically switches to the group where it can comfortably receive the video stream. Therefore, the number of transcoding sessions is not equal to the number of viewers like this is in the first option, but is fixed. For instance, 2 if there are two transcoding groups.

The third option suggests total refusal from transcoding on the server side and usage of preliminarily prepared video streams with varying resolutions and bitrates. In this case the camera is configured to send two or three streams with different resolutions and bitrates, and viewers switch to a particular stream depending on their bandwidths.

In this case, the burden of transcoding shifts from the server to the camera, because the camera has to encode two or more streams instead of just one.

So, we have reviewed all three options to match the broadcast to viewers’ bandwidth. Assuming one transcoding session takes one core of the server, we get the following CPU load comparison table:

The table makes it evident that we can delegate transcoding either to the camera or to the server. Options 2 and 3 looks optimal.

Testing RTSP as WebRTC

Now, let’s conduct some tests to see what is really going on in the above scenarios. We took an IP camera and tested it to measure broadcasting latency.

For the test we took an aged IP camera D-link DCS-2103 with the support for RTSP and H.264 and G.711 codecs.

The camera waited for action in a closet for a long time, so we had to Reset it by pressing and holding the button on the backside of the camera for 10 seconds.

As soon as the camera connected to the network, the green light lit and the router detected one more device in the network with the IP 192.168.1.37.

Then, we entered the web interface of the camera and specified codecs and allowed testing:

We needed the RTSP address of the camera, so we opened the network settings. In our case the RTSP-address was live1.sdp, that is the camera is available at rtsp://192.168.1.37/live1.sdp

Availability of the camera can be easily checked using VLC Player. Media – Open Network Stream.

So, we made sure the camera worked and output the video via RTSP.

As the test server we will use Web Call Server 5. This is a streaming server that supports RTSP and WebRTC protocols. It should connect to the IP camera via RTSP and fetch the video stream. Then, the stream is broadcast via WebRTC.

You can install Web Call Server to your own host or run a preconfigured instance at Amazon EC2.

After installing, switch the server to the RTSP non-interleaved mode discussed earlier. You can do this by adding the following parameter

This setting is added to the end of the flashphoner.properties config and requires server restart:

Therefore, we have got a non-interleaved server that accepts packets from the IP camera via UDP and then shares the stream via WebRTC (UDP).

The test server is deployed on the VPS server located in the Frankfurt data-center. It has 2 cores and 2 gigabytes of RAM.

The camera is located in the local framework at 192.168.1.37.

Giving the above, the first thing we need to do is to redirect the port 554 to the IP address 192.168.1.37 for incoming TCP / RTSP connections to allow the server establishing connection to our IP camera. To do this, we add just one rule in the settings of the router:

This rule tells the router to translate all inbound traffic from the port 554 to the specified IP address.

Finally, we need to know our external IP address. It takes like 5 to 15 seconds and only needs some gogleing on whatismyip

If you have a friendly NAT in possession and know your external IP address, you can run tests with the server.

The standard demo player in Google Chrome look as follows:

To start playing the RTSP stream, simply enter its address to the Stream field.

In our case, the address of the stream is: rtsp://ip-cam/live1.sdp

Here, ip-cam is the external IP address of your camera. It is this address that the server will attempt to establish connection to.

Testing latencies VLC vs WebRTC

After we installed and configured the IP camera and tested it in VLC, configured the server and tested an RTSP stream sent through the server and cast via WebRTC, we finally can compare latencies.

We use a timer for that. The timer displays fractions of seconds on the screen. We turn on the timer and run the playback simultaneously on the local VLC and in the Firefox browser through the remote server.

Server ping 100 ms.Local ping1 ms.

The first test with the timer look like this:

Here, on the black background there is a reference timer. It shows zero latency. On the left, there is VLC, and on the right there is Firefox that receives a WebRTC stream from the remote server.

This test demonstrates twice as big latency of VLC compared to Firefox + Web Call Server, even though the video in МДС is played in the local network, while the video played in Firefox routes to the data-center in Germany and returns back. The difference can be caused by the fact that VLC works over TCP (interleaved mode) and uses some buffering to ensure smooth playback of the video.

We took several photos to log the latency values:

Here are the measurement results:

Therefore, average latency when testing with VLC in the local network is 768 milliseconds. At the same time, average latency of the video routed via the remote server is 341 milliseconds, that is it is 2 times lower thanks to usage of UDP and WebRTC.

Testing latencies RTMP vs WebRTC

Now, we conducts similar measurements with an RTMP player via the Wowza server and a simultaneous test with a WebRTC player using Web Call Server.

The left part is fetching the video stream with Wowza and the RTMP connection. The right part is fetching using WebRTC. The reference time is above (zero latency).

Test – 1

Test – 2

Test – 3

Test – 4

The results of the test compiled to the same table as before:

Therefore, average latency during playback of an RTSP stream in Flash Player via RTMP was 1683 milliseconds. Average latency via WebRTC was 384 milliseconds. Therefore WebRTC turned out to be 4 times better in terms of latency.

References

WebRTC technologyRTSP – RFCRTSP interleaved – RFC, 10.12 Embedded (Interleaved) Binary DataRTMP – specificationWeb Call Server – WebRTC media server with the support for RTSPVLC – the player to play RTSP

Related articles

iOS Safari 11 now supports WebRTC

Embedding a WebRTC player for live broadcasts to a website

7 ways to stream RTSP on the page

Related features

RTSP HTML5 web player

flashphoner.com

Смотрите также

• 
  Vpn через браузер
• 
  Очистить журнал браузера
• 
  Браузер сжимающий трафик
• 
  Некорректно работает браузер
• 
  Выключить яндекс браузер
• 
  Windows phone браузер
• 
  Закрой вкладки браузера
• 
  Регистрация в браузере
• 
  Браузер режим инкогнито
• 
  Браузер инкогнито режим
• 
  Очистить история браузера