Комментарии 20
Хотя и с ним до недавнего времени было не все гладко на iOS-устройствах: когда пользователи запускают в Chrome видеосвязь с мобильного устройства, iOS ругается и требует открывать Safari. А Safari только недавно получил поддержку WebRTC, и не все в нем работает так как надо.
сторонние браузеры на iOS не поддерживают WebRTC. это реальность, данная нам
А Safari только недавно получил поддержку WebRTC, и не все в нем работает так как надо. Например, его не устраивает маленькое разрешение для камеры (для экономии трафика мы передаем картинку 640 на 480), и он требует установить более качественную видеосвязь.
с таким не приходилось сталкиваться. на MacOS Safari 14 перестал транслировать 4:3 c камеры FacetimeHD, только 16:9. обходится просто: публикуешь 640x360, например.
И еще один сюрприз: на iOS-устройствах ученикам нельзя одновременно быть на связи и воспроизводить видеофайл с заданием.
да, но вторую сессию WebRTC на той же странице играть можно.
Добрый день. Спасибо за статью!
Несколько вопросов:
- Какие основные проблемы у вас сейчас остались с Janus, если не секрет? Или всё устраивает после починки эстиматоров?
- Вы используете Simulcast? Если да, то ловили с ним каких-нибудь проблем?
- В каком разрешении, с каким битрейтом и на каких кодеках вы в итоге работаете и почему?
- Зачем вам вообще сервер нужен? У вас же наверняка в большинстве случаев (1 учитель – 1 ученик) можно обойтись P2P?
- Чем обусловлена проблема с 200 мбит/сек на сервер? На дворе 2021 год, и эта цифра что-то совсем не впечатляет :)
НЛО прилетело и опубликовало эту надпись здесь
Добрый день!
Основная проблема — это ошибка «User ID… already exists». Возникает, когда один и тот же пользователь пытается зайти в комнату одновременно с двух вкладок браузера или двух разных устройств. Janus не дропает автоматически старое подключение пользователя, если он повторно заходит в комнату. Приходится на уровне приложения обрабатывать эту ошибку.
Используем. Проблем нет.
640x480, 256 Кбит/с. Подобрали на глаз, чтобы картинка норм была и записи не все пространство на серверах выжирали. Кодеки в основном vp9, т.к. чисто субъективно кажется, что при одинаковом битрейте качество картинке лучше, чем у vp8. Для Safari используем h264.
Для уроков 1 на 1 нужен по двум причинам. Во-первых, некоторые ученики хотят послушать себя. Во-вторых, чтобы внутренний отдел контроля качествам мог проверять, как преподаватели проводят уроки.
Не копали эту тему в глубь, просто закидали проблему железом :))
Какие основные проблемы у вас сейчас остались с Janus, если не секрет?
Основная проблема — это ошибка «User ID… already exists». Возникает, когда один и тот же пользователь пытается зайти в комнату одновременно с двух вкладок браузера или двух разных устройств. Janus не дропает автоматически старое подключение пользователя, если он повторно заходит в комнату. Приходится на уровне приложения обрабатывать эту ошибку.
Вы используете Simulcast? Если да, то ловили с ним каких-нибудь проблем?
Используем. Проблем нет.
В каком разрешении, с каким битрейтом и на каких кодеках вы в итоге работаете и почему?
640x480, 256 Кбит/с. Подобрали на глаз, чтобы картинка норм была и записи не все пространство на серверах выжирали. Кодеки в основном vp9, т.к. чисто субъективно кажется, что при одинаковом битрейте качество картинке лучше, чем у vp8. Для Safari используем h264.
Зачем вам вообще сервер нужен? У вас же наверняка в большинстве случаев (1 учитель – 1 ученик) можно обойтись P2P?
Для уроков 1 на 1 нужен по двум причинам. Во-первых, некоторые ученики хотят послушать себя. Во-вторых, чтобы внутренний отдел контроля качествам мог проверять, как преподаватели проводят уроки.
Чем обусловлена проблема с 200 мбит/сек на сервер? На дворе 2021 год, и эта цифра что-то совсем не впечатляет :)
Не копали эту тему в глубь, просто закидали проблему железом :))
Основная проблема — это ошибка «User ID… already exists».
Если я правильно понимаю, то вы в теле `join` запроса указываете один и тот же `id`? Как вариант, это можно решить через флаг `string_ids`, доступный в последних версиях Janus, и задавать id составным вида `<user_id>-<random_string>`. Но тогда вопрос переходит в другую плоскость — нужен механизм для остановки/удаления сессии на неактивной вкладке…
Я правильно понимаю что вы меняли код Janus? А дальше как? Pull Request или живете со своим отдельным репозиторием?
Интересен был ваш опыт работы с WebRTC, а на деле просто рассказали про возникшие проблемы без технических деталей(
Планируете подробнее раскрыть тему?
Планируете подробнее раскрыть тему?
Приходите на онлайн-доклад через субботу, там можно будет @bkston (один из разработчиков в команде видео) задать вопрос текстом или голосом. Плюс будем благодарны, если напишете, что интересует — чтобы мы могли подумать, как об этом лучше рассказать.
Вопросов на самом деле много, часть из них перечислю:
— как вы определяете с технической стороны корректный видеозвонок?
— собираете ли вы статистику по звонкам, корректный поток у пользователя и у репетитора?
— допустим у пользователя заблокирована камера, возникают ли проблемы при соединению?
— вы как нибудь технически определяете успешность звонка или полагаетесь на отклик пользователя/репетитора? я как помню мне сразу предлагали в skype)) в обход вашего решения
— вы думали в сторону jitsi?
— как поступаете если ошибки на стороне медиасервера? есть какие-нибудь технические примеры, например реконнекта?
— собираете статистику WebRTC? rtt, jitter и другие метрики для определения состояния соединения?
— как вы определяете с технической стороны корректный видеозвонок?
— собираете ли вы статистику по звонкам, корректный поток у пользователя и у репетитора?
— допустим у пользователя заблокирована камера, возникают ли проблемы при соединению?
— вы как нибудь технически определяете успешность звонка или полагаетесь на отклик пользователя/репетитора? я как помню мне сразу предлагали в skype)) в обход вашего решения
— вы думали в сторону jitsi?
— как поступаете если ошибки на стороне медиасервера? есть какие-нибудь технические примеры, например реконнекта?
— собираете статистику WebRTC? rtt, jitter и другие метрики для определения состояния соединения?
При ваших бюджетах и размерах команды не проще ли было сделать своё нативное приложение под macOS, отдельно под Windows+Linux на каком-нибудь Qt, как вы это делаете для iOS и Android, чтобы не заниматься вознёй с кучей браузеров, которые меняются каждый день?
И протоколы можно стандартные тюнинговать под каждую систему, или свои изобретать, и кодеки практически какие угодно, и доступ ко всем устройствам без особых проблем.
И протоколы можно стандартные тюнинговать под каждую систему, или свои изобретать, и кодеки практически какие угодно, и доступ ко всем устройствам без особых проблем.
При ваших бюджетах и размерах команды
Приятно, когда о тебе настолько хорошо думают, но Skyeng это независимый игрок на рынке образования, у нас нет бюджетов корпораций за спиной) Команда сейчас — это 5 человек, включая продакта, QA и аналитика, — а начиналась вообще с двух человек.
С продактом видеокоманды (у него крутой технический бэкграунд, с WebRTC работает с 13-го года) сейчас как раз думаем о тезисах доклада на HighLoad на тему, как пилить видеосвязь с небольшой командой и скромным по меркам, например, соцсетей, бюджетом.
Правильно понимаю, что бутылочным горлышком является пропускная способность сервера, а не CPU, RAM, IOPS? И учитывая битрейт в 256 кбит, на одном сервере у вас может транслироваться одновременно 800 потоков? (на самом деле наверное чуть меньше из-за оверхеда, но порядок должен быть примерно такой)
Вы решили, что поддерживать свое приложение под iOS будет труднее, чем разбираться с причудами Safari?
Кстати, UC Browser раньше был прекрасен, несколько лет назад. Умел кэшировать содержимое вкладок, не перегружая при нехватке памяти, как когда то Opera Mini. Работал быстро.
Сейчас это нечто медленно работающее, с кучей постоянно выскакивающей рекламы.
Сейчас это нечто медленно работающее, с кучей постоянно выскакивающей рекламы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Грабли WebRTC: как мы допиливали чужой велосипед