VK Звонки это звонки друзьям из списка контактов или звонок по ссылке. Также есть возможность для организаторов онлайн-мероприятий: от масштабных форумов и конференций до вебинаров и корпоративных собраний на тысячи сотрудников.
Пользователи ВКонтакте теперь могут создавать трансляции своих видеозвонков, а благодаря новой роли администратора — качественнее модерировать общение.
Новые функции позволят эффективнее проводить лекции, конференции и другие мероприятия, привлекать внимание более широкой аудитории и при этом хорошо контролировать онлайн-встречи.
ВКонтакте представила раздел «Звонки» — в нём собраны все функции платформы для видеоконференций. Они доступны бесплатно, без ограничений по количеству участников и времени.
Рассмотрим, что представляет из себя новая платформа и какие есть полезные инструменты.
Оглавление
Раздел «Звонки» ВКонтакте
Все функции платформы VK Звонки вы найдёте в единой вкладке «Звонки». В версии для компьютера он появился в меню слева, а в мобильном приложении — во вкладке «Сервисы».
Функции для управления звонками в ВК
Управлять большими онлайн-конференциями, можно с помощью инструментов для модерации, их целый набор.
И ещё комплект функций — для качества картинки, звука, продуктивности и хорошего настроения:
Раздел «Звонки» уже доступен в десктопной версии ВКонтакте и в приложении для iOS и Android.
Кроме того, на компьютеры с Windows, macOS и Linux можно установить отдельное приложение VK Звонков — vk.com/video-calls. В нём стабильность связи, качество аудио- и видеопотока ещё выше, чем в браузере. Оно достигается за счёт оптимизации нагрузки и нативных возможностей операционных систем.
Для бизнеса и разработчиков IT-сервисов есть SDK VK Звонков — набор инструментов, в котором мы упаковали свои технологии для реализации групповых видеоконференций.
Ранее ВКонтакте сделал раздел с промокодами для Магазинов 2.0.
Что нужно от картинки в видеозвонке? Базово — чтобы не пикселила, не замирала и не вешала весь звонок. Это основы real-time видео, и добиться этого не так трудно.
Всё самое интересное начинается, когда вы хотите, чтобы в одном звонке могли участвовать сколько угодно человек. И при этом все могли включать видео, а не просто смотреть; разрешение скриншеринга было бы 4К; шеринг оставался суперчётким при любом интернете и т. д. И чтобы звонки работали на любых платформах и устройствах на мобильном нестабильном интернете.
Как мы добиваемся всего этого в звонках ВКонтакте, какие хаки в настройках используем, как экономим трафик и CPU, как боремся за latency и где нам пришлось идти в обход WebRTC, читайте под катом.
Disclaimer 1. Выводы и заключения по конкурентам сделаны исключительно из общедоступной информации, общих наблюдений и измерений, поэтому могут быть ошибочными.
Disclaimer 2. Огромное влияние на качество передачи любых real-time данных оказывает сеть, но сетевой слой мы обсудим в отдельной статье. Здесь сосредоточимся только на том, что касается передачи качественного видео.
Приступая к любой задаче, нужно составить требования, исходя из которых вы будете строить своё техническое решение. Мы провели исследование, в котором выяснили, чего хотят пользователи, — и ориентировались на эти результаты. Люди называли важные им свойства звонков, и в топ вышли качество, наличие видео, поддержка десктопа и мобильных платформ. Плюс, конечно, отсутствие ограничений по длительности и возможность пользоваться сервисом бесплатно.
Если хотелки пользователей перевести в свойства решения, то получится следующее:
Вспомним теорию
Теперь, зная вводные, пробежимся по основным понятиям, чтобы лучше представлять проблематику.
Видео, которые мы смотрим в телефоне или ноутбуке, состоят из кадров. Кадры бывают трёх типов:
В последовательности кадров, из которых складывается видео, типы чередуются и опорные кадры встречаются не слишком часто, а без них хорошая картинка не получится. Для видеозвонков это означает следующее: новый подключившийся участник не может начать проигрывать видео, пока не получит опорный кадр.
Если новый участник просто будет ждать, пока наступит очередь опорника, то получится дополнительная задержка на подключение — она может длиться секунды. Чтобы не ждать и не мучиться с задержкой, можно запросить опорник с помощью full intra request (FIR) по требованию. Но это лишний трафик, потому что опорный кадр кодируется с меньшей степенью сжатия, чем diff.
Как фреймы с камеры будут закодированы, то есть какой будет последовательность опорных и остальных типов кадров, как они будут сжаты, сколько их будет в одной секунде и так далее — всё это определяет видеокодек. По сути это алгоритм, который может быть, например, довольно тупым, но очень быстрым, или суперэффективным по битрейту, но тяжёлым.
Кодирование видео и выбор кодека — это всегда компромисс.
Каждый раз в этом вопросе у нас две чаши весов: с одной стороны раскалённый телефон, который по узкому сетевому каналу передаёт отлично сжатое видео, с другой — сэкономленная батарейка и видео с более высоким битрейтом, для отправки которого нужна большая пропускная способность.
Разные кодеки лучше подходят для определённых случаев. Например, H.264 аппаратно ускоренный и поэтому экономит ресурсы, но сильно уступает VP9 по качеству сжатия на низких битрейтах. Ниже условные графики того, как растёт нагрузка на устройство и какое получается качество в зависимости от битрейта — для H.264 слева и для VP9 справа.
Поэтому у нас есть механизм адаптации и мы переключаемся между этими двумя кодеками (или откатываемся на что-то ещё, если они недоступны). Если битрейт выше порога, то используем H.264, если ниже — VP9.
В результате не превращаем телефон в сковородку на высоких битрейтах и вытягиваем качество на низких.
Видео в групповом звонке
Вопросы экономии ресурсов и трафика становятся гораздо острее, когда мы переходим от звонков один на один к групповым.
В звонке тет-а-тет нужно закодировать и отдать, получить и декодировать для воспроизведения на клиенте всего одно видео. На это хватит сети в 1–2 Мбит/с, и можно использовать аппаратно ускоренное кодирование. В групповом звонке мы хотим видеть несколько видео — то есть, скорее всего, нужно больше энкодеров, а большинство устройств поддерживает аппаратно ускоренное кодирование только одного потока в один момент времени. Насколько увеличится трафик и будет ли он расти пропорционально числу участников, зависит от топологии.
Для звонков один на один мы всегда, когда это возможно, устанавливаем peer-to-peer соединение, которое выгоднее с точки зрения latency. Для групповых звонков теоретически есть три варианта: установить p2p-соединение каждого с каждым (Mesh), смиксовать на сервере все потоки в один (MCU) или использовать сервер по сути как ретранслятор пакетов (SFU).
Топология MCU — Multipoint Conferencing Unit — подходит для аудио (как мы его реализовали, смотрите в статье об аудиопайплайне звонков ВКонтакте), но не для видео. Ни один популярный сервис не пытается на сервере склеивать сетку из видео разных участников и посылать на клиент один поток. Интуитивно понятно, что это будет очень дорого, потому что потоки должны быть разными для всех участников (без собственного видео — и здесь это не сделать простым вычитанием, как в аудио). Например, при переключении режимов просмотра с окна с главным спикером на сетку надо перезапускать весь микс.
Поэтому для видео обычно используют SFU — прокидывают видео через сервер всем клиентам. Правда, реализации могут сильно отличаться.
В самом простом варианте сервер действительно только перекидывает пакеты, так что дорогое микширование входящих потоков ложится на клиента. Кроме этого, есть ещё два момента, от которых сильно страдает качество картинки:
Второй вариант для forwarding — simulcast.
Идея заключается в том, чтобы отправляющий клиент на своей стороне кодировал видео сразу в нескольких разрешениях. Сервер при этом всё так же перекидывает видео, но уже может выбрать из нескольких вариантов: например, отправить клиенту с мощным девайсом и стабильной сетью хорошее качество, а клиенту со слабеньким 3G самое маленькое разрешение.
Simulcast частично решает проблему понижения качества для всех и частично шторма опорников, но требует очень много клиентских ресурсов: как CPU- и GPU-вычислений (чтобы батарейка улетала за час), так и гораздо большего сетевого канала на отдачу.
Более продвинутая технология SVC (Scalable Video Coding) делает примерно то же, но внутри кодека. В один закодированный поток укладывается несколько SVC-слоёв с разными качествами. Такой подход потребляет ресурсы немного скромнее и требует чуть меньшей ширины исходящего канала, чем simulcast, но не решает проблему шторма опорных кадров (поток-то в результате один). И главный недостаток SVC — нет поддержки в браузерах. Для нас это сразу делает его непригодным.
В итоге мы, как всегда, вынуждены идти своим путём. Мы знаем, что для наших пользователей важнее всего качество, поэтому понижение битрейта по любому поводу для нас не вариант. Также на примере работы со звуком мы выяснили, что любая дополнительная нагрузка на телефон не только делает из него сковородку, но и добавляет случайные задержки и вообще-то портит качество. Значит, нужно серверное транскодирование.
При серверном транскодировании клиент отправляет на сервер видео в лучшем качестве, которое может закодировать и передать по доступной сети. На сервере это исходное видео транскодируется в несколько качеств поменьше и раздаётся остальным участникам, кому какое подходит. Нет проблем с тем, чтобы подстроиться под сеть каждого участника группового видеозвонка: опорные кадры можно генерировать на сервере, когда надо, и это не влияет ни на отправляющего клиента, ни на остальных собеседников. Одна проблема — это дорого. Но с этим тоже можно бороться.
Качество по запросу
Вообще говоря, в групповом звонке с серверной топологией нетрудно узнать, как в интерфейсе показывается видео каждого участника. У нас есть два основных варианта раскладки:
Очевидно, что видео в хорошем качестве нужно только для главного спикерского окошка. А если вы пока молчите и ваше видео показывается в миниатюре, то не нужно ни кодировать его в высоком качестве, ни пересылать по сети и через сервер. А если участников много и мы знаем, что ваше видео вообще ни у кого не влезло на текущий экран звонка, то его можно и вовсе не передавать — так сэкономятся и ваши ресурсы, и серверные.
То есть сервер говорит клиенту: «Давай видео не больше, чем такого-то качества, лучше пока не нужно». Если раскладка изменится — например, участник станет спикером или просто кто-то захочет посмотреть его видео внимательнее и развернёт его у себя в приложении, — сервер запросит видео в большем разрешении.
Переключение качества по запросу в исходящем потоке выглядит в webrtc-internals вот так:
Сначала никто не смотрит видео этого клиента — ничего не посылаем. Потом видео попало в большое окошко — битрейт подскочил. Последний отрезок — видео где-то в сетке, битрейт и размер фрейма меньше.
Понятно, что на резких переключениях туда-сюда можно просадить всю выгоду: завалить клиента запросами и замучить кодек постоянным переключением, в том числе генерацией новых опорников. Поэтому не забываем о здравом смысле и тротлим резкие переключения на понижение качества. То есть если вы только что говорили, то мы немного подождём и попересылаем качественное видео — на случай, если вы скоро продолжите. С другой стороны, запрос на повышение качества стараемся выполнить сразу: если уж видео показывается в большом окошке, оно должно выглядеть хорошо.
Кодирование видео на клиенте по запросу помогло нам значительно сэкономить сеть и серверные и клиентские ресурсы:
И это в самом неоптимальном случае для трёх участников. Если их больше, то больше и вариантов показа. Плюс есть вероятность, что чьё-то видео вообще не потребуется. Соответственно, суммарная выгода будет выше.
Но и это ещё не всё. Допустим, у всех участников примерно одинаковая сеть и никто не смотрит видео от определённого клиента на главном экране. Значит, нам нужно раздать его только в одном исходном качестве — среднем. И только если подключится кто-то новый с худшей сетью, для кого понадобится понизить битрейт, мы запустим транскодирование на сервере и нарежем минимальное качество. По факту, у нас 40% видео не требует транскодирования и пересылается в исходном виде, как в чистом SFU.
Итого: топология и кодирование в групповом видеозвонке
Выбирая групповую топологию для работы с видео, сразу откажитесь от MCU и помните главные недостатки разных вариантов реализации SFU:
Конкретный выбор зависит от ваших требований и возможностей. Простой SFU из коробки есть в open-source проектах и нормально сработает для небольшого числа участников. Но 50 человек в звонке для готового типового SFU — это предел. Браузер, использующий WebRTC для передачи видео, скорее всего, начнёт разваливаться ещё раньше.
Мы выбрали серверное транскодирование для того, чтобы не нагружать клиентов, но стараемся экономить и CPU сервера:
Демонстрация экрана
Демонстрация экрана — необходимая функция, если говорить о сервисе для рабочих и учебных видеоконференций. Но сейчас она есть и у большинства мессенджеров для личного общения — и ВКонтакте не исключение.
Казалось бы, демонстрация экрана — то же видео, только не с камеры. Это так, но сценарий использования и требования к воспроизведению отличаются. Рассмотрим отличия на графиках исходящего трафика из webrtc-internals.
Слева видео с камеры: каждый следующий кадр не сильно отличается от предыдущего, кодек кодирует видео примерно с константным битрейтом без существенных изменений качества.
Справа видео с экрана: большинство кадров ничем (или почти ничем) не отличаются от предыдущих, кодек кодирует их с очень низким битрейтом. Потом переключили окно, перелистнули слайд, быстро проскроллили — и новый кадр резко отличается от прошлого. Соответственно, нужно передать гораздо больше бит, так что получаются большие спайки битрейта.
В WebRTC эту проблему предлагается решать следующим образом: указываем, что отправляем текстовый контент (contentHint=text, degradationPreference=maintain-resolution); WebRTC оптимизирует кодирование под текст и вместо понижения разрешения сокращает фреймрейт.
Но кодек, чтобы уложиться в заданный битрейт при быстром скроллинге, повышает quantization parameter (QP). QP влияет на то, что предпочтёт кодек: повысить битрейт или получить искажения. Чем больше QP, тем выше уровень сжатия и сильнее искажения.
Вот как это выглядит на графиках webrtc-internals (кстати, доступно каждому: открываете chrome://webrtc-internals/ во время видеозвонка и следите, как сервис переключает битрейты и реагирует на изменения в звонке).
QP на левом графике резко вырастает именно тогда, когда начинаешь скроллить расшаренное окно, при этом падает качество. В это же время FPS на правом графике падает до 1 кадра в секунду — так себе плавность.
Google Meet, используя стандартный WebRTC, одновременно повышает quantization parameter, понижает FPS и повышает битрейт. Получается мыло, как на скриншоте ниже.
Когда спикер прекратит скроллить, текст постепенно восстановится и всё опять будет вполне читаемо. Но это «постепенно» может занять секунды, а тем временем будет пора листать дальше и показывать следующий слайд.
Мы не хотим, чтобы текст смазывался, и стремимся адаптироваться к условиям сети, понижая фреймрейт вместо повышения QP. WebRTC не даёт достаточного доступа к настройкам кодека, чтобы этого добиться. Поэтому для демонстрации экрана мы сделали отдельный пайплайн в обход WebRTC.
Adaptation controller смотрит на количество неотправленных данных в исходящем буфере и, если оно превышает порог, выбрасывает фрейм до кодирования.
Video encoder сконфигурирован с ограничением параметра maxQP — чтобы не разрешать ему размазывать текст, даже если битрейт не вписывается в заданный target. В такой конфигурации в связке с adaptation controller даже при недостаточной пропускной способности сети текст остаётся чётким, но снижается FPS.
Отдельно хочется отметить вопрос кодирования видео в браузерах. В них пока не везде есть низкоуровневый API видеокодирования. Но есть экспериментальный WebCodecs API, который доступен только в Chrome в рамках origin trial.
Мы записались в origin trial и в Chrome используем WebCodecs, а для остальных браузеров в качестве фолбэка берём libvpx-библиотеку, скомпилированную под WebAssembly. Плюс решения с WebAssembly — широкая поддержка в браузерах, минус — ниже производительность. Zoom тоже использует WebAssembly для кодирования видео, поэтому даже в веб-версии Zoom, в отличие от Google Meet, при скроллинге вы не увидите таких расплывшихся букв. Так что ждём, когда WebCodecs доедут до всех браузеров.
Где мы относительно конкурентов
В нашей архитектуре групповых звонков участвует собственный conferencing-сервер, и мы выбрали серверное транскодирование. Нужно проверить, как это сказалось на latency — показателе, который сильно влияет на субъективное восприятие качества.
Задержку по видео измеряем с помощью уже отработанного приёма: снимаем секундомер, фотографируем вместе экран с исходящим видео и экран принимающего клиента, сравниваем.
Вот что получили по видеозвонкам на компьютере на хорошей сети, но по Wi-Fi (сеть по сервисам выровнена).
Отдельно посмотрели на сети, задушенной до 300 Кбит/с. Здесь как раз вступают в игру отработка сбоев, борьба со штормом опорников и ухищрения с кодеками.
С мобильными клиентами тоже особый разговор: там жёстче борьба за нагрузку, но есть аппаратное ускорение. И это нативный клиент, а не универсальная браузерная реализация.
Во всех измерениях у ВКонтакте задержка или на уровне сервисов-конкурентов, или минимальная среди них. Давайте разберёмся почему.
Синхронизация звука и видео
Референсные исследования показывают: если голос (звук) немного отстаёт от видео, это не так заметно, как когда он опережает картинку.
Человеческий мозг легко компенсирует задержку звука, а вот слышать раньше, чем видеть, ему некомфортно. Рассинхронизация звука и видео в диапазоне от −100 до +60 мс незаметна.
Попробуем воспользоваться этим знанием. Посмотрим, сколько занимает процессинг аудио и видео по перцентилям.
Понятно, что на клиентах всё может быть по-разному. Но задержки на нашем бэкенде как раз в тех порядках, что и диапазон незаметного рассинхрона.
Поэтому мы отказались от lipsync. Мы передаём с сервера аудио и видео независимо, и на клиенте они не синхронизируются каким-либо специальным образом — мы надеемся на то, что различия будут несущественными и пользователи их не заметят. Если узнаем, что это мешает пользователям, то сможем включить. Но пока и без lipsync получается хорошо, а главное — с меньшими задержками.
Пайплайн для работы с видео
В итоге наш пайплайн для работы с видео позволил поддержать 4К в том числе для скриншеринга, сэкономить более 60% клиент-серверного трафика и 10–20% CPU клиента и сервера. Так что скоро мы сможем полностью снять ограничение на число участников в звонке, и все они смогут подключаться с видео.
При этом пайплайн не включает синхронизацию аудио и видео, что позволяет нам иметь наименьшую задержку среди популярных сервисов видеоконференций.
В следующей статье соберём все знания о работе с real-time аудио и видео и построим архитектуру сервиса видеозвонков без ограничения на число участников.
P. S. Сегодня важный день: мы выпускаем SDK наших звонков на рынок. В него мы упаковали все свои технологии для реализации групповых видеозвонков. Прежде эту библиотеку помимо ВКонтакте могли встроить только сервисы из Mail.ru Group: Учи.ру, «Сферум», Одноклассники и Звонки Mail.ru. Теперь, когда все возможности обкатаны на этих масштабных платформах, мы предлагаем их и другим IT-бизнесам.
Что есть внутри SDK, как получить тестовый доступ и интегрировать звонки в свой продукт (бесшовно, с собственным интерфейсом) — рассказываем на лендинге и в релизе.
Сколько стоит платная версия?
Платной версии нет, всё бесплатно.
Возможно ли запланировать видеоконференцию?
Да, можно будет создать конференцию заранее, поставить напоминание в календарь и отправить ссылку участникам по почте или в любом мессенджере.
Ранее ВКонтакте запустила автоматический определитель номеров на основе интеллектуальных алгоритмов и Big Data. Социальная сеть начала предупреждать о нежелательных телефонных звонках, чтобы оградить пользователей от спама, попыток мошенничества и других сомнительных вызовов. Сервис автоматического определения номера разработала команда VK Звонков — платформа укрепляет безопасность общения и расширяет её за пределы социальной сети.
Возможно ли участвовать в видеоконференции без аккаунта в VK?
Для создания конференции аккаунт необходим, подключиться к созданной конференции можно без аккаунта по ссылке.
Какая максимальная длительность видеоконференции?
Длительность видеоконференции не ограничена.
Сколько максимальное количество участников в видеоконференции?
Число участников неограниченно.
Как установить или запустить приложение VK Звонки
Организовать встречу есть возможность как от личной страницы, так и от имени сообщества. Необходимо авторизоваться и Нажать кнопку Создать видеовстречу или Запланировать.
Можно ли добавить виртуальный фон?
Да, вы можете настроить фон по своему желанию.
Есть ли в конференции чат?
Да, участники могут обмениваться сообщениями и полезными файлами в отдельном чате, который остаётся доступен и после завершения конференции.
Работает ли демонстрация экрана?
Да, во время видеоконференции Вы можете включить демонстрацию экрана в 4К.
Возможно ли сохранить запись?
Для любого видеозвонка можно запустить трансляцию, которая затем сохранится в разделе Видео. Для этого нажмите на шестерёнку на экране со звонком, а затем на кнопку Трансляция звонка. Опубликовать трансляцию можно как в профиле, так и в сообществе. Организатор трансляции может настроить её приватность.
Как сделать трансляцию видеозвонка ВКонтакте
Трансляцию звонка можно запустить с компьютера и из новой версии мобильного приложения ВКонтакте. Она доступна для любого видеозвонка — будь там два участника или все 128. Однако благодаря прямому эфиру получится привлечь к общению ещё больше людей, ведь смотреть и комментировать его может неограниченное количество зрителей.
Функцию удобно использовать для проведения конференций, мастер-классов, концертов, фан-встреч и других событий. Например, можно добавить в звонок тех, кто оплатил участие или победил в конкурсе, и предложить лично задавать вопросы спикерам или звёздным гостям. Другие зрители смогут наблюдать за мероприятием и обсуждать его в комментариях. Так эфир будет содержательным и интерактивным.
Выйти в эфир втайне от собеседников не получится — на их экранах появится значок Live. Организатор управляет настройками приватности и выбирает, кто увидит трансляцию: только участники звонка, ещё и его друзья или все пользователи ВКонтакте. Чтобы больше зрителей присоединилось к эфиру, создать трансляцию и сделать анонс можно заранее. Запись трансляции сохраняется в разделе «Видео», поэтому посмотреть её смогут даже те, кто пропустил прямой эфир.
Новые возможности для управления звонками в ВК
Видеозвонки ВКонтакте хорошо подходят для учёбы или работы: продолжительность не ограничена, есть демонстрация экрана, а присоединиться к звонку могут до 128 участников — причём даже без профиля в соцсети, просто по ссылке.
Чтобы поддерживать эффективность встреч было проще, в звонках ВКонтакте появилась роль администратора. Это собеседник, которому доступны те же настройки, что и создателю звонка. Назначает администраторов именно организатор общения, причём это может быть сколько угодно человек — очевидно, что одному ответственному будет нелегко уследить за сотней людей, которые хотят задать вопрос.
Модерировать онлайн-мероприятие с режимом администратора удобнее, чем очную встречу: для тишины «в зале» теперь достаточно выключить микрофоны у всех участников и выбрать, смогут ли они включить их обратно. Если участник захочет задать вопрос, он сможет написать его в чате или «поднять руку» — тогда администратор предоставит ему возможность высказаться. Кроме того, теперь видео спикера можно закрепить на главном экране — это поможет избежать случайных переключений между экранами участников и контролировать, что идёт в эфире.
Ранее ВКонтакте запустил партнёрскую программу, а также сделал редактирование рекламных объявлений в один клик.
