Pull to refresh

Comments 17

По поводу Kurento как обстоят дела с производительносттью? В интернет есть несколько статей которые утверждают что это на уровне десятков коннектов для довольно мощного железа? (на тот случай если нужны сотни тысяч коннектов)

У нас kurento дает пару сотен коннектов на 20-25% загрузки CPU. Железо нормальное — Intel® Xeon® CPU D-1541 @ 2.10GHz, не слабое, но и не мощное.
Kurento — не стабильная, не развивающаяся (https://www.kurento.org/blog/kurento-67-moving-forward) платформа, склонная к зависаниям на ровном месте при низких (от 100 пользователей) нагрузках.
Чего стоит баг (https://github.com/Kurento/bugtracker/issues/247), который правили больше года и так до сих пор и не исправили.
Что порекомендуете взамен?
Рекомендую не связываться с webrtc.
Хорошо. Тогда какие предлагаете использовать инструменты для организации видео/аудио связи в рамках телемедицинских консультаций врач-врач и врач-пациент? С учетом того, что система сделана на web.
Можно попробовать использовать TrueConf — у них есть возможность создания «комнат» врач-пациент через API, и встраивание WebRTC-плагина (через iframe) на страницу вашего сервиса.
Также у них на сайте есть целый раздел посвященный телемедицине — trueconf.ru/telemedicina.html
Как мне кажется лучше всего использовать websocket и fmp4/lhls.
Как раз будет обеспечена минимальная задержка и контролируемое соединение.
У нас это отлично работает в большинстве браузеров.

По поводу минимальной задержки — hls это до 1-й минуты. lhls вроде бы должен этот недостаток преодолевать, на насколько? Это 10 секунд? 5 секунд?
Нам же нужен связный диалог.

В случае с hls, мы делаем чанки по 2 секунды и плейлист из 10 чанков.
Получается средняя задержка около 4-х секунд. Максимальная задержка может доходить до 20 секунд из-за необходимости обработать rtmp, играть с ключевых кадров и т.п.

В случае lhls, мы делаем чанки (frames) по 0,1 секунды. Средняя задержка около 1-й секунды. Максимальная задержка может доходить до 6 секунд по вышеуказанным причинам.
У вас HLS работает в обе стороны? Т.е. и на прием и на отправку? Тут человеку надо двустороннее общение с врачом…
Для двухстороннего общения раньше использовался flash и rtmp.
hls не рилтайм формат, его не стоит использовать для общения людей.

Сейчас для двухстороннего общения можно использовать webrtc или websocket/lhls/fmp4.

А не пробовали кейс переключения сетей? Как вебсокеты к этому отнесутся, особенно на мобилах?

Всё как обычно, соединение рвётся и подключается.
С http было бы точно также, если бы соединение порвалось в середине передачи чанка.

С моей точки зрения зависит от объемов потока и мощности разработчика.


Как наиболее простой вариант это купить готовый сервис — правда сразу возникает вопрос а какой именно.
При заведомо не очень больших объемах — coturn. Из опыта разработки и эксплуатации одного приложения на coturn столкнулся с двумя проблемами: 1) нет простого способа горизонтального масштабирования, поэтому рано или поздно будет перегрузка без возможности масштабировать сервис 2) мобильным разработчикам сложно реализовать надежную логику реконнектов
Ну и, наконец, если Вы мощная компания (Google, Яндекс) — то вы просто пилите что-то свое и выкладываете в общий доступ для всеобщего пользования.

В своем проекте использую OpenVidu от тех же разработчиков. Так же они предлагают использовать COTURN как выше упоминалось. OpenVidu я доволен
Sign up to leave a comment.