Комментарии 23
НЛО прилетело и опубликовало эту надпись здесь
VLC все равно большие задержки дает. А если ставить очень маленькое время кеширование то видео смотреть становится невозможно.
На gstreamer получается гораздо лучше. Особенно это заметно когда гонишь чистый rtp поток.
Если в VLC поставить задержку на RTP менее 300ms то начинаются дикие лаги на видио.
На gstreamer получается гораздо лучше. Особенно это заметно когда гонишь чистый rtp поток.
Если в VLC поставить задержку на RTP менее 300ms то начинаются дикие лаги на видио.
НЛО прилетело и опубликовало эту надпись здесь
Сложно засинхронить время у железки которая делает аппаратное сжатие и запихивает это все в rtp.
А вообще мы для своих задач отказались от rtp, перешли на mpegts и даже удобнее стало. И вполне задержка получилась 250-300 мс для fullhd. Просто hd где-то 200-250мс. Ну у нас своя специфика.
Просто раньше мы смотрели все на vlc пытались на нем или на ffmpeg получить маленькую задержку.
Но все равно как ни крути gstreamer выдает немного меньшую задержку.
А вообще мы для своих задач отказались от rtp, перешли на mpegts и даже удобнее стало. И вполне задержка получилась 250-300 мс для fullhd. Просто hd где-то 200-250мс. Ну у нас своя специфика.
Просто раньше мы смотрели все на vlc пытались на нем или на ffmpeg получить маленькую задержку.
Но все равно как ни крути gstreamer выдает немного меньшую задержку.
Увидел заголовок и даже не сомневался, что снова будет реклама вне блога компании про Web Call Server. За последний месяц уже по-моему пятый раз.
Это вы VLC с дефолтными настройками испытывали, а не RTSP… Советую провести повторное тестирование, используя более приспособленные к поставленной задаче плееры.
Я выставляю на соревнование «mplayer -benchmark -framedrop -nosound», sdp он понимает. Решал с его помощью схожую задачу, задержка при стриме full hd видео была на уровне 100 мс, чего вполне достаточно для игр в аркадные гоночки без монитора.
Я выставляю на соревнование «mplayer -benchmark -framedrop -nosound», sdp он понимает. Решал с его помощью схожую задачу, задержка при стриме full hd видео была на уровне 100 мс, чего вполне достаточно для игр в аркадные гоночки без монитора.
А сколько у вас кадров в секунду? Если у вас 30фпс то я в жизни не поверю в задержку в 100мс.
Если 60фпс, то в принципе 100мс вполне реально.
Если 60фпс, то в принципе 100мс вполне реально.
Только что проверил. На 30 fps — около 80-90 мс, на 60 fps — ровно 100 мс. Сеть — обычная локалка через обычный домашний роутер, ноутбук подключен по wi-fi.
Слева — ноутбук (TN+Film), принимает стрим. Справа — ПК (IPS + f.lux), отдает стрим.
Но! Это голый MPEG-TS через UDP. Если добавить промежуточный сервер, который будет заворачивать все в RTSP — задержка, очевидно, увеличится, но не думаю, что она дорастет даже до «лучшего» результата топикстартера в 323 мс.
Слева — ноутбук (TN+Film), принимает стрим. Справа — ПК (IPS + f.lux), отдает стрим.
30 fps, 80-90 ms
60 fps, 100 ms
Но! Это голый MPEG-TS через UDP. Если добавить промежуточный сервер, который будет заворачивать все в RTSP — задержка, очевидно, увеличится, но не думаю, что она дорастет даже до «лучшего» результата топикстартера в 323 мс.
Аааа у вас не с камеры, а захват с экрана и mpegts тогда да. Это более реально. Просто если с камеры сжимать то у вас +время одного кадра минимум добавляется(так-как вам нужно целеком кадр принять и только потом его передавать).
То есть в среднем 3 кадра задержка.
1)Принять
2) сжать-передать-разжать(если у нас энкодер, декодер и сеть успевает за время кадра)+ всякие буфера
3) отобразить. (хотя тут зависит тоже от многих факторов)
З.Ы. Промазал с ответом.
То есть в среднем 3 кадра задержка.
1)Принять
2) сжать-передать-разжать(если у нас энкодер, декодер и сеть успевает за время кадра)+ всякие буфера
3) отобразить. (хотя тут зависит тоже от многих факторов)
З.Ы. Промазал с ответом.
Безусловно. С другой стороны, у камеры гарантированное аппаратное кодирование и картинку она получает сразу, а не добывает неведомыми окольными путями. Но VLC, в тех же условиях, получая такой же стрим, даже с выставленным в 0 кешем, иногда теряя изображение, выдает задержку почти 900 мс. Почему — не знаю, использую mplayer дальше…
А, есть такой же «Web Call Server» только не хотящий "$75 subscribe per month per instance"? :)
А если камера расположена на чем-нибудь мобильном и потому прокинуть порты нет технической возможности?
Можно ли наоборот, настроить IP камеру или веб-камеру+Raspberry для отправки видеопотока на удаленный сервер, чтобы уже он раздавал видео дальше?
Можно ли наоборот, настроить IP камеру или веб-камеру+Raspberry для отправки видеопотока на удаленный сервер, чтобы уже он раздавал видео дальше?
можно, например, через ssh-тоннель. т.е. что-то из локальной сети с камерой подключается к серверу по ssh и открывает на сервере порт, по которому доступна камера. софт на сервере уже подключается к камере через этот порт и раздает желающим.
Как раз сейчас пилю велосипед на эту тему, дай бог получится что-то работоспособное…
Но неужели нет конкурентов?
Но неужели нет конкурентов?
Не очень понятно, что с чем сравнивают. И о чём спор.
1. RTSP и RTMP сделаны на основе TCP. WebRTC сделан на основе UDP. Сюрприз! Сюрприз! Задержка при UDP меньше, чем при TCP!
Не «может», а именно, что вызвано. Аналогично и для FlashPlayer-а
2. Как и в случае с VLC, во FlashPlayer-е для проигрывания потока можно выставить буфер. Поэтому для чистоты эксперимента надо удостовериться, что bufferTime = 0.
3. Если уж и сравнивать, то WebRTC на UDP с RTMFP.
1. RTSP и RTMP сделаны на основе TCP. WebRTC сделан на основе UDP. Сюрприз! Сюрприз! Задержка при UDP меньше, чем при TCP!
Такое расхождение может быть вызвано тем, что VLC работает по TCP (interleaved mode) и включает какие-то дополнительные буферы для плавного воспроизведения видео.
Не «может», а именно, что вызвано. Аналогично и для FlashPlayer-а
2. Как и в случае с VLC, во FlashPlayer-е для проигрывания потока можно выставить буфер. Поэтому для чистоты эксперимента надо удостовериться, что bufferTime = 0.
3. Если уж и сравнивать, то WebRTC на UDP с RTMFP.
Сюрприз! Сюрприз! Задержка при 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.
Мне вот интересно, раз уж статья о технологии, использованной в этом продукте, то для конкретных задач (а-ля камхоринг) чем данный продукт лучше чем https://github.com/jitsi ?
И если у меня уже есть вовза или флюссоник, то зачем мне вообще "webcallserver"?
Оба стримера умеют в webrtc.
Jitsi meet+videobridge
во флюссонике роль meet предлагается написать самому судя по документации.
Опять-таки есть и проигрывание.
Но движение в сторону использования MSE вероятно обладает при проигрывании большим числом преимуществ чем webrtc.
Флюссоник по сути аналог вовзы, но с архивом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Браузерная WebRTC трансляция с RTSP IP-камеры с низкой задержкой