Что делать с участниками видеоконференций с плохим интернетом или слабым железом?

  • Tutorial

В связи с пандемией видеоконференции всё более плотно входят в нашу жизнь, мы проводим встречи с коллегами, посещаем удалённые лекции или уроки или просто устраиваем сеансы связи с родными.

И в каждой видеоконференции обязательно найдётся кто-то, чьё видео будет отставать, зависать или вовсе будет показывать какое-то слайдшоу. Дайте угадаю, вы сразу же вспомнили такого участника вашей последней видеоконференции. :) Это люди, чей компьютер устарел, захламлён тысячей работающих в фоновом режиме процессов, или чей интернет оставляет желать лучшего.

В этой статье я хочу разобрать возможные решения столь частой проблемы видеоконференций.

Проблемы с зависающим/отстающим видео обычно связаны с тем, что видео одного качества с лёгкостью проходит через один канал интернета/устройство, но не проходит через другой.

Давайте на примере:

Есть три участника видеоконференции: A, B, C. У участников A и B очень хороший канал интернета и хорошее качество видео. А у участника C плохо ловящий 3G с постоянными потерями.

В итоге, если участник А будет отправлять видео в высоком качестве, которое способен принять участник B, то такое видео не пролезет в канал участника C. А если отправлять видео в качестве, которое беспроблемно работает для участника C, то участники A и B будут недовольны качеством связи. Как же быть?

Немного поразмыслив, мы в Voximplant сделали поддержку Simulcast для управления качеством видео в конференциях. Работает он так: участники с хорошим железом и широким каналом в интернет будут отправлять несколько потоков видео: в хорошем качестве для тех, кто может себе его позволить, и в качестве хуже для участников с плохим интернетом или железом. Какое качество кому отправлять, решает сервер.

Что происходит на стороне отправителя?

Для видео с веб-камер или стриминга мы управляем качеством с помощью изменения разрешения видео. Чем выше разрешение отправителя, тем больше слоёв он отправляет. Затем каждому участнику конференции отправляется видео в максимальном качестве, которое этот участник может принять.

Для шаринга экрана такой подход может оказаться неверным, потому что люди иногда хотят показать слайды, свой рабочий стол или даже исходный код. А при снижении разрешения мелкие элементы будет замыливать. Поэтому для таких случаев снижение качества происходит не уменьшением разрешения, а уменьшением частоты кадров в секунду.

А что на стороне получателя видео?

Серверная часть Voximplant сама анализирует канал принимающей стороны и подбирает подходящее качество видео для отправки. Дополнительно нагрузка снижается за счёт двух факторов:

  • Видео запрашивается разрешением не больше, чем размер видео элемента на экране

  • Выключается прием видео тех участников, которые нам не интересны (например не помещаются на экран или не говорят)

Мы проводим различные эксперименты для того, чтобы найти больше способов улучшения качества видео для участников с разными возможностями, так что вскоре к этим методам будут добавлены новые.

Как использовать?

Всё уже встроено в платформу Voximplant. Достаточно подключиться с включённым simulcast’ом, и всё вышеперечисленное будет работать. Вот пример на Web SDK:

const conference = VoxImplant.getInstance().callConference({
    number: 'foobar',
    simulcast: true
});

А дальше можно уже вручную включать или выключать определённые видеопотоки, менять разрешение, устанавливать битрейт и многое другое. Кому интересно, вот здесь можно почитать, как всё реализовать.

Качественной всем связи!

Voximplant
Облачная платформа голосовой и видеотелефонии

Комментарии 21

    +1
    Вы не думали видео отправлять в хорошем разрешении по udp? А если кому-то не пришел один кадр или несколько то он это может даже не заметить. Даже если у него будет всего несколько кадров в секунду то этого будет достаточно.
      +1
      а звук как синхронить? По udp звук то не пошлешь
        0
        Почему звук по udp не пошлешь? Я всегда думал, что звук и видео лучше стримить по udp.
          0
          вобщем-то да, при условии организации контроля ошибок на уровне приложения
          0

          Зачем вы пишите чепуху?!
          Практически все системы uc пересылают медиа-данные именно по udp/rtp.

            0
            согласен, поторопился, я как-то не ожидал что контроль пакетов не переложен на протокол, оказалось все сложнее.
          0
          WebRTC изначально работает по UDP
            0
            Я лучше буду 640×480 с частотой хотя бы 15 к/с смотреть, чем слайд-шоу в FullHD.
              0
              лучше вообще видео убирать, а то взяли привычку и картинка мыло и звук заикается)
            +2

            Перестать заниматься ерундой и оставлять один звук. Действительно, возможность видеть собеседника теоретически позволяет получать больше информации, но в реальности, особенно - при плохой связи или тонком канале, это практически бессмысленно.

              0
              А при невозможности звука оставлять лишь текст.
                +1
                транслитом
                  +1
                  предварительно обучить синтезатор голоса голосу собеседника и скармливать ему текст, который распознается на клиенте))
                    0
                    И требуя вычислительных ресурсов в пару топовых нейроных ускорителей :)
                      0
                      дану) обучить только нужно офлайн, а по готовой модели вреалтайме легко распознавать даже на телефоне.
                        0
                        Учим на стороне передающего, а воспроизводить нужно на стороне принимающего.
                        Учится нужно быстро и БДЗнанийОсобенностейГолоса должна быть небольшой, иначе каждый новый собеседник будет обладателем робо-голоса и нужен широкий и стабильный канал.
                        Да и телефон телефону рознь.
                          0
                          На стороне принимающего тоже можно подгрузить речевой движок заранее. Ну или взять готовый чей-то движок))) Пропадет только эмоциональная часть. Хотя и ее можно как нибудь закодировать в метаданных
                            0
                            Хочется посмотреть на сопряжение голосовых движков на разных технологиях и потока данных :)

                            На эту тему Гугл уже аудиокодек выкатил: Google Lyra

                            Мой старенький Samsung N8000 падает в коматоз от усердно пожатого opus'а, а такое вообще не переварит.
                              0
                              Так поток данных я предлагал организовать текстовый. Текст обрамлен в эмоциональные теги. На том распознавалка, на этом синтезатор))
                                0
                                Одними эмоциональными тэгами не обойдёшься.
                                А ведь есть языки, где тональность напрямую определяет смысловую нагрузку.
                                Поэтому современный синтез это несколько проходов и весьма большая вычислительная нагрузка. А универсальный метод потащит ещё и гигантскую базу данных обо всех языках мира.
                                Да и текст не образец экономичной передачи информации.
              +1

              По спецификации WebRTC фича Simulcast одна из удобнейших в реализации через SFU (Selective Forwarding Units). Об этом вы писали в одной из своих предыдущих статей - https://m.habr.com/ru/company/Voximplant/blog/432708

              Что у вас изменилось за эти 3 года?

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое