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

[a1ien_n3t]

VLC все равно большие задержки дает. А если ставить очень маленькое время кеширование то видео смотреть становится невозможно.
На gstreamer получается гораздо лучше. Особенно это заметно когда гонишь чистый rtp поток.
Если в VLC поставить задержку на RTP менее 300ms то начинаются дикие лаги на видио.

[a1ien_n3t]

Сложно засинхронить время у железки которая делает аппаратное сжатие и запихивает это все в rtp.
А вообще мы для своих задач отказались от rtp, перешли на mpegts и даже удобнее стало. И вполне задержка получилась 250-300 мс для fullhd. Просто hd где-то 200-250мс. Ну у нас своя специфика.
Просто раньше мы смотрели все на vlc пытались на нем или на ffmpeg получить маленькую задержку.
Но все равно как ни крути gstreamer выдает немного меньшую задержку.

[a1ien_n3t]

А что именно интересно?
Так просто берем сжимаем аппаратно в h.264 gstreamer заворачивает все в mpegts дальши пихаем все в udp(получается по 7 mpgts фреймов в одном upd пакете). И дальше передаем.

[barker]

Увидел заголовок и даже не сомневался, что снова будет реклама вне блога компании про Web Call Server. За последний месяц уже по-моему пятый раз.

[HurrTheDurr]

Это вы VLC с дефолтными настройками испытывали, а не RTSP… Советую провести повторное тестирование, используя более приспособленные к поставленной задаче плееры.
Я выставляю на соревнование «mplayer -benchmark -framedrop -nosound», sdp он понимает. Решал с его помощью схожую задачу, задержка при стриме full hd видео была на уровне 100 мс, чего вполне достаточно для игр в аркадные гоночки без монитора.

[a1ien_n3t]

А сколько у вас кадров в секунду? Если у вас 30фпс то я в жизни не поверю в задержку в 100мс.
Если 60фпс, то в принципе 100мс вполне реально.

[HurrTheDurr]

Только что проверил. На 30 fps — около 80-90 мс, на 60 fps — ровно 100 мс. Сеть — обычная локалка через обычный домашний роутер, ноутбук подключен по wi-fi.

Слева — ноутбук (TN+Film), принимает стрим. Справа — ПК (IPS + f.lux), отдает стрим.

30 fps, 80-90 ms

60 fps, 100 ms

Но! Это голый MPEG-TS через UDP. Если добавить промежуточный сервер, который будет заворачивать все в RTSP — задержка, очевидно, увеличится, но не думаю, что она дорастет даже до «лучшего» результата топикстартера в 323 мс.

[2030andme]

Как отобразить голый MPEG-TS через UDP в браузере? Без плагинов?

В статье описаны тесты трансляции RTSP на браузер. Понятно, что используя MPEG-TS и десктопный софт, можно добиться задержки в 1-2 RTT.

[a1ien_n3t]

Аааа у вас не с камеры, а захват с экрана и mpegts тогда да. Это более реально. Просто если с камеры сжимать то у вас +время одного кадра минимум добавляется(так-как вам нужно целеком кадр принять и только потом его передавать).
То есть в среднем 3 кадра задержка.
1)Принять
2) сжать-передать-разжать(если у нас энкодер, декодер и сеть успевает за время кадра)+ всякие буфера
3) отобразить. (хотя тут зависит тоже от многих факторов)

З.Ы. Промазал с ответом.

[HurrTheDurr]

Безусловно. С другой стороны, у камеры гарантированное аппаратное кодирование и картинку она получает сразу, а не добывает неведомыми окольными путями. Но VLC, в тех же условиях, получая такой же стрим, даже с выставленным в 0 кешем, иногда теряя изображение, выдает задержку почти 900 мс. Почему — не знаю, использую mplayer дальше…

[Merkat0r]

А, есть такой же «Web Call Server» только не хотящий "$75 subscribe per month per instance"? :)

[Areso]

А если камера расположена на чем-нибудь мобильном и потому прокинуть порты нет технической возможности?
Можно ли наоборот, настроить IP камеру или веб-камеру+Raspberry для отправки видеопотока на удаленный сервер, чтобы уже он раздавал видео дальше?

[jazzl0ver]

можно, например, через ssh-тоннель. т.е. что-то из локальной сети с камерой подключается к серверу по ssh и открывает на сервере порт, по которому доступна камера. софт на сервере уже подключается к камере через этот порт и раздает желающим.

[RSATom]

Как раз сейчас пилю велосипед на эту тему, дай бог получится что-то работоспособное…
Но неужели нет конкурентов?

[Paul_Nice]

Если камер много, имеет смысл кастомизировать прошивку камеры.
Что-то вроде этого с логичным развитием в вот такое.

[Emin]

Не очень понятно, что с чем сравнивают. И о чём спор.

1. RTSP и RTMP сделаны на основе TCP. WebRTC сделан на основе UDP. Сюрприз! Сюрприз! Задержка при UDP меньше, чем при TCP!

Такое расхождение может быть вызвано тем, что VLC работает по TCP (interleaved mode) и включает какие-то дополнительные буферы для плавного воспроизведения видео.

Не «может», а именно, что вызвано. Аналогично и для FlashPlayer-а

2. Как и в случае с VLC, во FlashPlayer-е для проигрывания потока можно выставить буфер. Поэтому для чистоты эксперимента надо удостовериться, что bufferTime = 0.

3. Если уж и сравнивать, то WebRTC на UDP с RTMFP.

[2030andme]

Сюрприз! Сюрприз! Задержка при UDP меньше, чем при TCP!

Была некоторая неожиданность в том, что в локальной сети задержка RTSP при воспроизведении в VLC оказалась больше, чем через удалённый сервер при использовании WebRTC. Скажем так, было совсем неочевидно, что тест даст такие результаты.

Более того, использование UDP не гарантирует задержку ниже чем TCP. Зависит от протокола, который работает поверх UDP. Например, в WebRTC активно используется TCP-like досылка видеопакетов и по этой причине нельзя сказать, будет все без задержек или нет. Зависит от реализации.

Поэтому для чистоты эксперимента надо удостовериться, что bufferTime = 0

Netstream.bufferTime был 0

Если уж и сравнивать, то WebRTC на UDP с RTMFP.

RTMP был выбран по двум причинам:
1. Как реалтаймовый протокол (по сравнению с HLS, где задержка 15 и более секунд).
2. Как самый распространенный реалтаймовый протокол, для которого есть много решений RTSP-RTMP.

Протокол RTMFP менее распространен и мне известны буквально единицы решений, конвертирующие RTSP-RTMFP. Кстати, Web Call Server поддерживает такую конвертацию.

На самом деле, тесты RTSP-RTMFP проводились. По результатам, RTMFP отстает примерно на 100-200ms от WebRTC. Возможно добавлю скриншоты в статью с результатами по RTMFP.

[Paul_Nice]

Мне вот интересно, раз уж статья о технологии, использованной в этом продукте, то для конкретных задач (а-ля камхоринг) чем данный продукт лучше чем https://github.com/jitsi ?

И если у меня уже есть вовза или флюссоник, то зачем мне вообще "webcallserver"?
Оба стримера умеют в webrtc.

[barker]

А скажите, jitsi этот — это что, там про коммуникатор какой-то же? Или речь про jitsi-videobridge? Но там тоже видеороутер какой-то под xmpp, как я понял.
А флюссоник разве искаробки умеет webrtc? Прямо как медиасервер работает, только webrtc может на входе и выходе??

[Paul_Nice]

Jitsi meet+videobridge
во флюссонике роль meet предлагается написать самому судя по документации.
Опять-таки есть и проигрывание.
Но движение в сторону использования MSE вероятно обладает при проигрывании большим числом преимуществ чем webrtc.
Флюссоник по сути аналог вовзы, но с архивом.