"Zoom, Skype и другие нативные приложения справляются с этой проблемой, просто игнорируя потерю пакетов — потеря нескольких кадров на видео, обычно некритична для пользователей"
А Google Meet (и не только) как справляется, ведь он только в браузере?
Дело в том, что нам необходимо синхронизировать не только видео/аудио, а саму доску, её объекты и перемещение юзеров по ней (причем как друг с другом, так и с сервером). Причем важно это делать непрерывно и с высокой скоростью, поэтому мы всё прогоняли через TCP (отчасти решение было сделано по неопытности + у всей команды оказался стабильный интернет и проблема не сразу была замечена). Теперь разделяем - видеосвязь и процесс подключения на webRTC (исключительно через UDP с допустимой потерей пакетов) будет "жить" отдельно от state остальной части приложения, которое уже по TCP передается (при обрыве соединения state просто будет подвисать не надолго - что уже совсем некритично).
Если у вас ест опыт в работе с webRTC и вы готовы обменяться с нами экспертизой было бы круто 🙂
"Zoom, Skype и другие нативные приложения справляются с этой проблемой, просто игнорируя потерю пакетов — потеря нескольких кадров на видео, обычно некритична для пользователей"
А Google Meet (и не только) как справляется, ведь он только в браузере?
Вроде бы есть исследования по WebRTC and packet loss - https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41611.pdf
Спасибо за вопрос!
Дело в том, что нам необходимо синхронизировать не только видео/аудио, а саму доску, её объекты и перемещение юзеров по ней (причем как друг с другом, так и с сервером).
Причем важно это делать непрерывно и с высокой скоростью, поэтому мы всё прогоняли через TCP (отчасти решение было сделано по неопытности + у всей команды оказался стабильный интернет и проблема не сразу была замечена).
Теперь разделяем - видеосвязь и процесс подключения на webRTC (исключительно через UDP с допустимой потерей пакетов) будет "жить" отдельно от state остальной части приложения, которое уже по TCP передается (при обрыве соединения state просто будет подвисать не надолго - что уже совсем некритично).
Если у вас ест опыт в работе с webRTC и вы готовы обменяться с нами экспертизой было бы круто 🙂