Комментарии 14
Спасибо, интересная статья! Еще очень интересен ваш доклад об использовании Janus www.youtube.com/watch?v=0BiE1Rt-bak.
Доводилось сталкиваться с кодом Janus, не очень понравилось именно что он сделан в виде готового сервера, реализацию некоторых специфичных задач через его систему плагинов было не очень удобно колхозить. Но вещь, конечно, очень и очень достойная! Основным пожеланием было чтобы в нем был выделен код для работы webrtc в отдельную библиотеку и уже поверх нее реализация сервера и плагинов. Лично для меня, подобная библиотека была бы удобнее готового сервера типа Janus, Kurento, licode, easyrtc и похожих. Также где-то год назад в них не было поддержки нескольких треков в рамках одного подключения. Многие из них сделаны поверх libnice. Было бы классно собрать минимальные webrtc демки поверх libnice и оставить на память в виде статьи/заметки, как-то эта библиотека слабо представлена статьями и примерами. Кстати, еще есть реализация webrtc в составе библиотек gstreamer, пробовал использовать и ее.
Также с самого начала проекта наблюдаю за реализацией webrtc на golang github.com/pions/webrtc Проект классный и активно развивается! Собирал pions для armv5, запускал на чипах hisilicon камер видеонаблюдения, заводилось и работало!) Сейчас уже можно работать с rtp и даже голыми h264 nal'ами. Надеюсь добавление/удаление треков в рантайме добавят в следующем релизе, как запланировано. Для онлайн школ, сервисов онлайн конференций возможно будет интересное решение. Немного расстраивает что это на golang, все же там GC и есть некоторый оверхед, а железко камер это 32-64 Мб оперативки на все про все + 8-16Мб spi флешки) Но это проблемы камер, на нормальном железе все отлично!
В 2019 уже хочется иметь возможность через p2p webrtc смотреть потоки с камер в браузерах/мобильном софте… если кому-то интересна эта область, то оставлю контакты нашего проекта с открытой прошивкой для камер видеонаблюдения на базе openwrt openipc.org/contacts там есть активный телеграм чат, есть некоторые наработки, репозитории, очень рады будем видеть всех заинтересованных! Тематика webrtc не основная в чате, но все же тема важна и актуальна для камер…
Доводилось сталкиваться с кодом Janus, не очень понравилось именно что он сделан в виде готового сервера, реализацию некоторых специфичных задач через его систему плагинов было не очень удобно колхозить. Но вещь, конечно, очень и очень достойная! Основным пожеланием было чтобы в нем был выделен код для работы webrtc в отдельную библиотеку и уже поверх нее реализация сервера и плагинов. Лично для меня, подобная библиотека была бы удобнее готового сервера типа Janus, Kurento, licode, easyrtc и похожих. Также где-то год назад в них не было поддержки нескольких треков в рамках одного подключения. Многие из них сделаны поверх libnice. Было бы классно собрать минимальные webrtc демки поверх libnice и оставить на память в виде статьи/заметки, как-то эта библиотека слабо представлена статьями и примерами. Кстати, еще есть реализация webrtc в составе библиотек gstreamer, пробовал использовать и ее.
Также с самого начала проекта наблюдаю за реализацией webrtc на golang github.com/pions/webrtc Проект классный и активно развивается! Собирал pions для armv5, запускал на чипах hisilicon камер видеонаблюдения, заводилось и работало!) Сейчас уже можно работать с rtp и даже голыми h264 nal'ами. Надеюсь добавление/удаление треков в рантайме добавят в следующем релизе, как запланировано. Для онлайн школ, сервисов онлайн конференций возможно будет интересное решение. Немного расстраивает что это на golang, все же там GC и есть некоторый оверхед, а железко камер это 32-64 Мб оперативки на все про все + 8-16Мб spi флешки) Но это проблемы камер, на нормальном железе все отлично!
В 2019 уже хочется иметь возможность через p2p webrtc смотреть потоки с камер в браузерах/мобильном софте… если кому-то интересна эта область, то оставлю контакты нашего проекта с открытой прошивкой для камер видеонаблюдения на базе openwrt openipc.org/contacts там есть активный телеграм чат, есть некоторые наработки, репозитории, очень рады будем видеть всех заинтересованных! Тематика webrtc не основная в чате, но все же тема важна и актуальна для камер…
Простому человеку в статье самое интересное — это альтернативы Скайпу. Я так понял, что всё сравнимое со Скайпом по пользовательским качествам (а уж лучшее, чем Скайп, и подавно) — платное. А фриварного нет?
По слухам, есть ещё какой-то Скайп-Про для бизнеса. Он вроде платный, но я не понял — платный повремённо или это разовая оплата при покупке клиентского софта. В статье про него ни слова.
По слухам, есть ещё какой-то Скайп-Про для бизнеса. Он вроде платный, но я не понял — платный повремённо или это разовая оплата при покупке клиентского софта. В статье про него ни слова.
Мы особо не рассматривали альтернативы, которые нельзя встроить в платформу.
Так-то есть Скайп, Hangouts (free), Hangouts Meet (paid), Zoom и все они хороши в плане качества. Про Скайп-Про ничего не слышал. :)
На WebRTC есть масса решений, от платных Voximplant и Tokbox до бесплатных Janus, Kurento, Jitsi, licode. А если устраивает базовый p2p и нет групповых звонков, то все еще проще.
Так-то есть Скайп, Hangouts (free), Hangouts Meet (paid), Zoom и все они хороши в плане качества. Про Скайп-Про ничего не слышал. :)
На WebRTC есть масса решений, от платных Voximplant и Tokbox до бесплатных Janus, Kurento, Jitsi, licode. А если устраивает базовый p2p и нет групповых звонков, то все еще проще.
А у вас за время работы обновления браузеров webrtc не ломало? ребята из trueconf часто к этой проблемы аппелируют…
А можете чуть подробнее про Janus, Twilio и S3 рассказать?
Правильно понимаю, что Janus выступает в качестве входной точки, дальше трафик идет через turn и параллельно заливается на s3?
еще вопросик — смотрели в сторону coturn в качестве своего turn/stun сервера вместо Twilio?
Правильно понимаю, что Janus выступает в качестве входной точки, дальше трафик идет через turn и параллельно заливается на s3?
еще вопросик — смотрели в сторону coturn в качестве своего turn/stun сервера вместо Twilio?
Не знаю их схемы, но Janus это поддерживает, поэтому логично использовать его возможности.
То-есть с turn и записью должно происходить примерно так:
1. Json API запрос на Janus для входа участника или смотрящего.
2. Создается новый ICE канал через libnice, работают turn сервера, что указаны в конфигурации, если напрямую клиента соединить нельзя.
3. Janus получает пакеты от libnice и может залогировать потоки на диск в mjr формате. Утилитой janus-pp-rec можно потом перекодировать.
Проблем с наличием реализации turn мне кажется нет, проблема что эти сервера надо где-то хостить и иметь хорошее географическое покрытие.
То-есть с turn и записью должно происходить примерно так:
1. Json API запрос на Janus для входа участника или смотрящего.
2. Создается новый ICE канал через libnice, работают turn сервера, что указаны в конфигурации, если напрямую клиента соединить нельзя.
3. Janus получает пакеты от libnice и может залогировать потоки на диск в mjr формате. Утилитой janus-pp-rec можно потом перекодировать.
Проблем с наличием реализации turn мне кажется нет, проблема что эти сервера надо где-то хостить и иметь хорошее географическое покрытие.
Janus — медиасервер в середине. Клиенты (браузеры) общаються только с ним, а он внутри пересылает пакеты партнеру.
Так как Janus — это публичный сервер без NAT, доля использования TURN у нас в районе 1% (против 30%+ в p2p варианте), поэтому не заморачиваемся с оптимизацией TURN.
Но опыт с coturn есть в рамках одного из экспериментов. Подняли быстро, сервер не падал — мы довольны. :)
Записи звонков пишутся на диск (встроенная фича Janus), а дальше отдельный daemon перекладывает их на S3 в сыром формате. По запросу бизнеса, на отдельной машине выкачиваем нужные записи, конвертируем их в mp4 и заливаем на S3 для последующего просмотра живыми людьми.
Сами Janus Gateway сервера хостим в Москве и Питере, т.к. это покрывают большую часть учеников.
Так как Janus — это публичный сервер без NAT, доля использования TURN у нас в районе 1% (против 30%+ в p2p варианте), поэтому не заморачиваемся с оптимизацией TURN.
Но опыт с coturn есть в рамках одного из экспериментов. Подняли быстро, сервер не падал — мы довольны. :)
Записи звонков пишутся на диск (встроенная фича Janus), а дальше отдельный daemon перекладывает их на S3 в сыром формате. По запросу бизнеса, на отдельной машине выкачиваем нужные записи, конвертируем их в mp4 и заливаем на S3 для последующего просмотра живыми людьми.
Сами Janus Gateway сервера хостим в Москве и Питере, т.к. это покрывают большую часть учеников.
В каких случаях используется TURN?
Использовать TURN или нет решает код WebRTC под капотом в браузере.
Могу ошибаться, но в нашем случае TURN используется только в случае злостных файрволов и NAT, из-за которых наш Janus сервер не может слать трафик клиенту.
Эта тема отлично раскрыта в докладе Александра Тоболя из Одноклассников — www.youtube.com/watch?v=MnEXuKHjIOU :)
Могу ошибаться, но в нашем случае TURN используется только в случае злостных файрволов и NAT, из-за которых наш Janus сервер не может слать трафик клиенту.
Эта тема отлично раскрыта в докладе Александра Тоболя из Одноклассников — www.youtube.com/watch?v=MnEXuKHjIOU :)
Насколько я понял, клиенты всегда устанавливают соединение к вашему серверу. Зачем в таком случае TURN?
Или клиенты устанавливают соединение одновременно и между собой (p2p), и через ваш сервер, чтобы записывать данные?
Или клиенты устанавливают соединение одновременно и между собой (p2p), и через ваш сервер, чтобы записывать данные?
Зачем в таком случае TURN?
В идеальном мире — незачем. Но в реальном находятся случаи, когда напрямую с сервером обмениваться данными не выходит.
Как я написал выше, это для сильно редкий случай и мы попросту не паримся. :)
Дополнительного p2p соединения между клиентами нет.
Вообще странно. Такого рода сервера используются для установления p2p. Изначально должен же кто-то инициализировать тот самый p2p. Когда же это ему не удается, он отправляет обоих клиентов на TURN — сервер и общение уже идет только через него. У нас примерно 30% таких «проблемных», которые заворачиваются на TURN. Что самое интересное, большинство проблем даже не на стороне клиента, а на стороне провайдера…
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
От Skype до WebRTC: как мы организовали видеосвязь через веб