![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 1 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 1](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi.jpg)
По некоторым данным, на сегодняшний день, в мире установлены сотни миллионов IP-камер для видеонаблюдения. Однако далеко не для всех из них критична задержка в воспроизведении видео. Видеонаблюдение, как правило, происходит «статично» — поток записывается в хранилище и может быть проанализирован на движение. Для видеонаблюдения разработано множество программных и аппаратных решений, которые хорошо делают свою работу.
В данной статье мы рассмотрим немного другое применение IP-камеры, а именно применение в онлайн-трансляциях, где требуется низкая коммуникационная задержка.
Прежде всего давайте устраним возможное недопонимание в терминологии про вебкамеры и IP-камеры.
Вебкамера — это устройство захвата видео, не имеющее собственного процессора и сетевого интерфейса. Вебкамера требует подключения к компьютеру, смартфону, либо другому устройству, имеющему сетевую карту и процессор.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 2 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 2](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-2.jpg)
IP-камера — это автономное устройство, имеющее собственную сетевую карту и процессор для сжатия захваченного видео и отправки в сеть. Таким образом, IP-камера представляет собой автономный мини-компьютер, который полноценно соединяется с сетью и не требует подключения к другому устройству, и может напрямую вещать в сеть.
Низкая задержка (low latency) — это достаточно редкое требование для IP-камер и онлайн-трансляций. Необходимость работы с низкой задержкой появляется, например, в том случае, если источник видеопотока активно взаимодействует со зрителями этого потока.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 3 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 3](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-3.png)
Чаще всего низкая задержка необходима в игровых сценариях использования. В качестве таких примеров можно привести: видео-аукцион в реальном времени, видео-казино с живым дилером, интерактивное онлайн-тв шоу с ведущим, удалённое управление квадрокоптером, и т.д.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 4 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 4](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-4.png)
Дилер живого интернет-казино за работой.
Обычная RTSP IP камера, как правило жмёт видео в H.264 кодек и может работать в двух режимах транспортировки данных: interleaved и non-interleaved.
Режим interleaved наиболее популярный и удобный, т.к. в этом режиме видео данные передаются по протоколу TCP внутри сетевого подключения к камере. Для того чтобы раздавать с IP-камеры в interleaved нужно всего лишь открыть / пробросить один RTSP-порт камеры (например 554) наружу. Плееру остаётся лишь подключиться к камере по TCP и забрать поток уже внутри этого соединения.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 5 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 5](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-5.jpg)
Вторым режимом работы камеры является non-interleaved. В этом случае соединение устанавливается по протоколу RTSP / TCP, а трафик идёт уже отдельно, по протоколу RTP / UDP вне созданного TCP-канала.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 6 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 6](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-6.jpg)
Режим non-interleaved более благоприятен для трансляции видео с минимальной задержкой, так как использует протокол RTP / UDP, но в то же время является более проблемным, если плеер расположен за NAT.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 7 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 7](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-7.jpg)
При подключении к IP-камере плеера, который находится за NAT, плеер должен знать — какие внешние IP-адреса и порты он может использовать для приема аудио и видео трафика. Эти порты указываются в текстовом SDP-конфиге, который передается камере при установке RTSP-соединения. Если NAT был вскрыт правильно и определены корректные IP-адреса и порты, то все будет работать.
Итак, для того чтобы забрать видео с камеры с минимальной задержкой, нужно использовать non-interleave mode и получать видеотрафик по UDP.
Браузеры не поддерживают стек протоколов RTSP / UDP напрямую, но поддерживают стек протоколов встроенной технологии WebRTC.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 8 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 8](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-8.jpg)
Технологии браузера и камеры очень похожи, в частности SRTP это шифрованное RTP. Но для корректной раздачи на браузеры, IP камере бы потребовалась частичная поддержка WebRTC-стека.
Чтобы устранить эту несовместимость требуется промежуточный сервер-ретранслятор, который будет являться мостом между протоколами IP-камеры и протоколами браузера.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 9 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 9](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-9.jpg)
Сервер забирает поток с IP-камеры на себя по RTP / UDP и отдаёт подключившимся браузерам по WebRTC.
Технология WebRTC работает по протоколу UDP и тем самым обеспечивает низкую задержку по направлению Сервер > Браузер. IP-камера также работает по протоколу RTP / UDP и обеспечивает низкую задержку по направлению Камера > Сервер.
Камера может отдать ограниченное количество потоков, в силу ограниченных ресурсов и полосы пропускания. Использование промежуточного сервера позволяет масштабировать трансляцию с IP камеры на большое число зрителей.
С другой стороны, при использовании сервера, включаются две коммуникационных ноги:
1) Между зрителями и сервером
2) Между сервером и камерой
Такая топология имеет ряд «особенностей» или «подводных камней». Перечислим их ниже.
Подводный камень #1 — Кодеки
Препятствием для работы с низкой задержкой и причинами ухудшения общей производительности системы могут стать используемые кодеки.
Например, если камера отдает 720p видеопоток в H.264, а подключается Chrome-браузер на смартфоне Android с поддержкой только VP8.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 10 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 10](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-10.jpg)
При включении транскодинга, для каждой из подключенных IP-камер должна быть создана транскодинг-сессия, которая декодирует H.264 и кодирует в VP8. В этом случае 16 ядерный двухпроцессорный сервер сможет обслужить только 10-15 IP камер, из примерного расчета 1 камера на физическое ядро.
Поэтому если серверные мощности не позволяют транскодировать планируемое количество камер, то транскодинга нужно избегать. Например обслуживать только браузеры с поддержкой H.264, а остальным предлагать использовать нативное мобильное приложение для iOS или Android, где есть поддержка кодека H.264.
Как вариант для обхода транскодинга в мобильном браузере, можно использовать HLS. Но стриминг по HTTP совсем не обладает низкой задержкой и в настоящий момент не может быть использован для интерактивных трансляций.
Подводный камень #2 — Битрейт камеры и потери
UDP протокол помогает справиться с задержкой, но допускает потери видеопакетов. Поэтому несмотря на низкую задержку, при больших потерях в сети между камерой и сервером, картинка может быть испорчена.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 12 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 12](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-12.jpg)
Для того чтобы исключить потери, нужно убедиться, что генерируемый камерой видеопоток имеет битрейт, который помещается в выделенную полосу между камерой и сервером.
Подводный камень #3 — Битрейт зрителей и потери
Каждый подключившийся к серверу зритель трансляции также имеет определенную пропускную способность на Download.
Если IP-камера отправляет поток, превышающий возможности канала зрителя (например камера отправляет 1 Mbps, а зритель может принять только 500 Kbps), то на этом канале будут большие потери и, как следствие фризы видео или сильные артефакты.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 13 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 13](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-13.jpg)
В этом случае есть три варианта:
- Транскодировать видеопоток индивидуально под каждого зрителя под требуемый битрейт.
- Транскодировать потоки не для каждого подключившегося, а для группы группы зрителей.
- Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах.
Первый вариант с транскодингом под каждого зрителя не подходит, так как израсходует ресурсы CPU уже при 10-15 подключившихся зрителей. Хотя нужно отметить, что именно этот вариант дает максимальную гибкость при максимальной загрузке CPU. Т.е. это идеальный вариант например в том случае, если вы транслируете потоки всего на 10 географически распределенных человек, каждый из них получает динамический битрейт и каждому из них нужна минимальная задержка.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 14 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 14](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-14.jpg)
Второй вариант заключается в уменьшении нагрузки на CPU сервера с помощью групп транскодирования. Сервер создает несколько групп по битрейту, например две:
- 200 Kbps
- 1 Mbps
В случае, если зрителю не хватает пропускной полосы, он переключается в ту группу, в которой он сможет комфортно получать видеопоток. Таким образом, количество транскодинг-сессий не равно количеству зрителей как в первом случае, а является фиксированным числом, например 2, если групп транскодинга две.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 15 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 15](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-15.jpg)
Третий вариант предполагает полный отказ от транскодинга на стороне сервера и использование уже подготовленных видеопотоков в различных разрешениях и битрейтах. В этом случае камера настраивается на отдачу двух или трех потоков с разными разрешениями и битрейтами, а зрители переключаются между этими потоками в зависимости от своей пропускной способности.
В этом случае транскодинговая нагрузка на сервер уходит и смещается на саму камеру, т.к. камера теперь вынуждена кодировать два и более потоков вместо одного.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 16 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 16](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-16.jpg)
В результате мы рассмотрели три варианта подстройки под полосу пропускания зрителей. Если предположить, что одна транскодинг-сессия забирает 1 ядро сервера, то получаются следующая таблица нагрузки на CPU:
Способ подстройки | Количество ядер на сервере | |
1 | Транскодировать видеопоток под каждого зрителя под требуемый битрейт | N — количество зрителей |
2 | Транскодировать видеопотоки по группам пользователям | G — количество групп зрителей |
3 | Подготовить потоки с камеры заранее в нескольких разрешениях и битрейтах | 0 |
Из таблицы видно, что мы можем сместить транскодинговую нагрузку на камеру либо отдать транскодирование на сервер. Варианты 2 и 3 при этом выглядят наиболее оптимальными.
Тестирование RTSP как WebRTC
Пришла пора провести несколько тестов для выявления действительной картины происходящего. Возьмем реальную IP-камеру и проведем тестирование с целью измерения задержки при трансляции.
Для тестирования возьмем древнюю IP-камеру D-link DCS-2103 с поддержкой RTSP и кодеков H.264 и G.711.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 17 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 17](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-17.jpg)
Так как камера долго пролежала в шкафу с другими полезными девайсами и проводами, пришлось отправить ее в Reset, нажав и подержав кнопку на задней стороне камеры 10 секунд.
После подключения к сети, на камере загорелась зеленая лампочка и роутер увидел еще одно устройство в локальной сети с IP адресом 192.168.1.37.
Заходим в веб-интерфейс камеры и выставляем кодеки и разрешение для тестирования:
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 18 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 18](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-18.jpg)
Далее заходим в сетевые настройки и узнаем RTSP адрес камеры. В данном случае RTSP-адрес live1.sdp, т.е. Камера доступна по адресу rtsp://192.168.1.37/live1.sdp
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 19 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 19](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-19.jpg)
Доступность камеры легко проверить с помощью VLC плеера. Media — Open Network Stream.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 20 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 20](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-20.jpg)
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 21 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 21](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-21.jpg)
Мы убедились, что камера работает и отдает видео по RTSP.
В качестве сервера для тестирования будем использовать Web Call Server 5. Это стриминг сервер с поддержкой RTSP и WebRTC протоколов. Он будет подключаться к IP-камере по RTSP и забирать видеопоток. Далее раздавать поток по WebRTC.
Вы можете установить Web Call Server на свой хост либо запустить готовый инстанс Amazon EC2.
После установки необходимо переключить сервер в режим RTSP non-interleaved, который мы обсуждали выше. Это можно сделать добавлением настройки
rtsp_interleaved_mode=false
Эта настройка добавляется в конфиг flashphoner.properties и требует перезагрузки сервера:
service webcallserver restart
Таким образом, у нас есть сервер, который работает по схеме non-interleaved, принимает пакеты от IP-камеры по UDP, и далее раздаёт по WebRTC (UDP).
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 22 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 22](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-22.jpg)
Тестовый сервер находится на VPS-сервере, расположенном в датацентре Франкфурта, имеет 2 ядра и 2 гигабайта RAM.
Камера находится в локальной сети по адресу 192.168.1.37.
Поэтому первое что мы должны сделать — это пробросить порт 554 на адрес 192.168.1.37 для входящих TCP / RTSP соединений, чтобы сервер мог установить подключение к нашей IP-камере. Для этого в настройках роутера добавляем всего одно правило:
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 23 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 23](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-23.jpg)
Правило говорит роутеру перенаправлять весь входящий на порт 554 трафик, на 37 — IP адрес.
Далее осталось узнать свой внешний IP-адрес. Это можно сделать за 5-15 секунд, погуглив по слову whatismyip
Если у вас дружелюбный NAT и вы знаете внешний IP-адрес, то можно начинать тесты с сервером.
Стандартный демо плеер в браузере Google Chrome выглядит так:
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 24 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 24](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-24.jpg)
Чтобы начать играть RTSP поток, нужно просто ввести его адрес в поле Stream.
В данном случае адрес потока: rtsp://ip-cam/live1.sdp
Здесь ip-cam это внешний IP адрес вашей камеры. Сервер будет пытаться установить соединение именно по этому адресу.
Тестирование задержек VLC vs WebRTC
После того, как мы настроили IP камеру и протестировали в VLC, настроили сервер и протестировали RTSP поток через сервер с раздачей по WebRTC, мы наконец-то можем сравнить задержки.
Для этого будем использовать таймер, который будет показывать на экране монитора доли секунды. Включаем таймер и воспроизводим видеопоток одновременно на VLC локально и на браузере Firefox через удалённый сервер.
Пинг до сервера 100 ms.
Пинг локально 1 ms.
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 25 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 25](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-25.png)
Первый тест с использованием таймера выглядит так:
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 26 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 26](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-26.png)
На черном фоне расположен исходный таймер, который показывает нулевую задержку. Слева VLC, справа Firefox, получающий WebRTC поток с удаленного сервера.
Zero | VLC | Firefox, WCS | |
Time | 50.559 | 49.791 | 50.238 |
Latency ms | 0 | 768 | 321 |
На этом тесте видим задержку на VLC в два раза больше чем задержку на Firefox + Web Call Server, не смотря на то, что видео в VLC воспроизводится в локальной сети, а видео, которое отображается в Firefox проходит через сервер в датацентре в Германии и возвращается обратно. Такое расхождение может быть вызвано тем, что VLC работает по TCP (interleaved mode) и включает какие-то дополнительные буферы для плавного воспроизведения видео.
Мы сделали несколько снимков чтобы зафиксировать значения задержки:
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 27 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 27](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-27.png)
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 28 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 28](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-28.png)
Результаты измерений выглядят так:
Metric | Zero | VLC | Firefox, WCS | |
Test1 | Time | 50.559 | 49.791 | 50.238 |
Latency | 0 | 768 | 321 | |
Test2 | Time | 50.331 | 49.565 | 49.951 |
Latency | 0 | 766 | 380 | |
Test3 | Time | 23.870 | 23.101 | 23.548 |
Latency | 0 | 769 | 322 | |
Average | 768 | 341 |
Таким образом, средняя задержка при тестировании с VLC в локальной сети составила 768 миллисекунд. В то время, как средняя задержка при проходе видео через удаленный сервер составила 341 миллисекунду, т.е. была в 2 раза ниже при использовании UDP и WebRTC.
Тестирование задержек RTMP vs WebRTC
Проведем похожие тесты с RTMP- плеером через Wowza сервер и одновременный тест с WebRTC-плеером через Web Call Server.
Слева забираем видеопоток с Wowza в RTMP-подключении. Справа забираем поток по WebRTC. Сверху абсолютное время (нулевая задержка).
Тест — 1
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 29 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 29](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-29.png)
Тест — 2
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 30 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 30](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-30.png)
Тест — 3
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 31 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 31](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-31.png)
Тест — 4
![Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 32 Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой - 32](https://www.pvsm.ru/images/2017/03/20/brauzernaya-WebRTC-translyaciya-s-RTSP-IP-kamery-s-nizkoi-zaderjkoi-32.png)
Результаты тестирования можно вывести в уже знакомую таблицу:
Metric | Zero | RTMP | WebRTC | |
Test1 | Time | 37.277 | 35.288 | 36.836 |
Latency | 0 | 1989 | 441 | |
Test2 | Time | 02.623 | 00.382 | 02.238 |
Latency | 0 | 2241 | 385 | |
Test3 | Time | 29.119 | 27.966 | 28.796 |
Latency | 0 | 1153 | 323 | |
Test4 | Time | 50.051 | 48.702 | 49.664 |
Latency | 1349 | 387 | ||
Average | 1683 | 384 |
Таким образом, средняя задержка при воспроизведении RTSP потока в Flash Player по RTMP составила 1683 миллисекунд. Средняя задержка по WebRTC 384 миллисекунды. Т.е. WebRTC оказалась в среднем в 4 раза лучше по задержке.
Ссылки
Технология WebRTC
RTSP — RFC
RTSP interleaved — RFC, 10.12 Embedded (Interleaved) Binary Data
RTMP — спецификация
Web Call Server — WebRTC медиасервер с поддержкой RTSP
VLC — плеер для воспроизведения RTSP
Автор: 2030andme