Real svc что это
Пришло СМС от Realsvc: что это такое?
25.08.2021 3 Просмотры
При использовании мобильного устройства нередки странные звонки и СМС от Realsvc. Бывает, что список рассылки с кодом идентичен. Причин тому много. Чаще всего для конкретного абонента запускается автоматическая рассылка, на основании которой рассылается спам.
Есть много причин для рассылки спама. Иногда они безвредны, иногда они используются для получения информации о держателе и предоставления доступа к его кредитным картам.
Направления СМС от Realsvc:
По этому принципу формируется:
Как защитить себя и свои данные
Важно понимать, что в Интернете есть специальные программы, которые могут заменить номер звонящего на нужный вам. По этому принципу на номер потерпевшего поступает звонок с номера сотрудника банка, где сообщается, что с его карты списываются средства.
Как вариант, используйте несколько карт: для сетевого общения, для регистрации на сайтах. Если звонок осуществляется из банка, то в этом случае угадать несложно что это мошенники.
Пришло СМС с кодом подтверждения от mainsvc: что за сервис?
Пользователи в интернете стали жаловаться на получение СМС от непонятного отправителя Mainsvc. В сообщениях указаны короткие коды для подтверждения операций. Данные SMS могут поступать по несколько раз на дню. Что это такое и как реагировать на подобные письма?
Что такое Mainsvc
Поиск данного имени в интернете не даст подробной информации. С высокой долей вероятности его используют злоумышленники. С помощью специальных SMS-бомберов мошенники пытаются выманить личные данные пользователей и завладеть их аккаунтами в корыстных целях. 
Злоумышленники скидывают владельцу телефона сообщение с коротким кодом для подтверждения операции в социальной сети или на другой подобной площадке. Одна такая СМС насторожит пользователя, после чего он сменит пароль от аккаунта или просто удалит SMS. Но мошенническая атака выстроена по-другому.
С помощью бомбера мошенники отправляют сразу несколько сообщений от различных аккаунтов. Такой способ позволяет им сыграть на невнимательности человека. Среди массы поступивших писем можно не заметить нужное. 
Понять, что произошла мошенническая атака с использованием СМС-бомбера, легко. Нежелательные сообщения начинают приходить слишком часто. Причем каждый раз требуется подтвердить действия на разных площадках, в том числе и на тех, где нет и никогда не было учетных записей.
На заметку! СМС от Mainsvc могут приходить даже в ночное время суток. Так мошенники надеются, что смогут сбить столку невнимательных пользователей. 
Что делать
Остановить поток SMS, которые присылают злоумышленники, самостоятельно не удастся. Мошенники каким-то образом завладели мобильным номером и теперь шлют на него разные сообщения.
Есть несколько вещей, которые помогут пережить мошенническую атаку:
В любом случае не нужно попадаться на уловки мошенников и скидывать им личные данные. Нельзя переходить по сторонним ссылкам и передавать коды для подтверждения операций, которые приходят на телефон.
Пришло СМС с кодом от Bestsvc: что это такое?
В интернете появился новый вид мошенничества, суть которого заключается в осуществлении массовой рассылки SMS-кодов с подтверждением на мобильные номера людей.
Хочется отметить, что значительное количество сервисов, от которых приходят подобные смс, являются «однодневками» или вовсе не существуют на просторах интернета. 
Например, многие пользователи интернета жалуются, что им приходят сообщения от Bestsvc, в которых ничего кроме кода подтверждения не указывается.
Рассказываем ниже, в чем заключается суть подобного рода мошенничества, что такое Bestsvc, что делать, если вы получили от него SMS-сообщение.
Bestsvc: что это
Если коротко, то Bestsvc – сервис-«пустышка», «однодневка». Он используется для совершения смс-атак, так называемого «бомбинга» телефонного номера.
Вообще, этот онлайн-сервис как бы существует, но как бы нет. В чем суть: мошенники зарегистрировали данное доменное имя, но сайт под него не сделали. Таким образом, поиски какой-либо информации про него не закончатся успехом – вы просто ничего не найдете про этот сайт, так как формально, доменное имя – все, что у него есть.
Почему приходят SMS-сообщения от него
Как уже было сказано выше, Bestsvc используется мошенниками и хакерами только для рассылки спама на мобильные номера. Подобный вид мошенничества называет sms-бомбингом.
В интернете существуют специальные сайты, онлайн-сервисы, с помощью которых можно разослать на один и тот же номер мобильного телефона огромное количество смс, например, от 100 и больше.
Например, Text Blaster, SMS Blast и другие, имеющие аналогичный принцип работы. Все эти перечисленные сайты занимаются смс-атакой или бомбингом. Bestsvc – это всего лишь один из множества веб-ресурсов, которые SMS-бомберы используют для рассылки спама.
Сам по себе сайт ничего не представляет, как он не имеет даже собственной страницы в интернете, что говорит о том, что он является «пустышкой». 
Скорее всего, если вы получили сообщение от данного сервиса с кодом подтверждения, значит на ваш номер телефона пришло еще множество подобных SMS и от других онлайн-сервисов в том числе.
Это значит, что вы подверглись SMS-бомбингу, то есть кто-то (например, ваш недруг или человек, с которым вы недавно поругались) указал ваш номер в SMS-бомбере, и теперь вам приходит спам с кодами подтверждения.
Что делать, если вы получили сообщение от Bestsvc
Как правило, бомбинг не длится дольше суток. Единственное, что вы можете сделать в данном случае – блокировать номера, с которых приходят сообщения.
Также вы можете обратиться к сотрудникам оператора сотовой связи и описать проблему, они могут попытаться предотвратить спам-атаку.
Пришло СМС с кодом от Mainsvc: что это такое?
В последнее время в интернете появилось огромное количество мошеннических уловок и прочих манипуляций.
Интернет является особо благоприятной «почвой» для такого вида деятельности. Например, не так давно люди начали массово жаловаться, что им приходят сообщения на мобильный телефон с кодом подтверждения от неизвестного им сайта Mainsvc. Причем, SMS-сообщения приходят помногу раз на дню. Разбираемся ниже, что такое Mainsvc. А также что делать, если вы получили сообщение от данного сервиса. 
Mainsvc: что это
Если попробовать разузнать что-нибудь про этот сайт, то окажется, что информации про него нет от слова совсем. Из чего следует сделать вывод, что данный сайт служит в качестве мошеннической уловки, чтобы «сбить» внимание человека с толку. Дальше расскажем, как это работает.
Есть такое понятие в интернете, как «SMS bomber». Смс-бомберы служат прикрытием для мошенника и работают следующим образом: допустим, аферист каким-либо образом узнал ваш номер телефона и хочет взломать привязанные к нему аккаунты в социальных сетях путем сброса пароля учетной записи.
Однако он понимает, что если будет действовать без «прикрытия», то есть просто отправит смс-сообщение на ваш номер телефона о смене пароля, то с большей степенью вероятности вы его увидите и, возможно, смените текущий пароль или как минимум насторожитесь.
В общем, так действовать неэффективно. Поэтому аферисты делают следующим образом: подвергают ваш номер смс-атакам, так, что вам приходят сообщения с кодом подтверждения от разных сервисов, в том числе Mainsvc, а мошенник, тем временем, пытается заполучить доступ к вашим аккаунтам, так как среди массы сообщений с кодом подтверждения увеличивается вероятность, что вы пропустите нужное, вернее, не заметите его.
Понять, что вы подверглись смс-бомбингу, очень просто – в один день на ваш номер телефона обрушиваются сотни смс от разных сайтов, на которых вы даже не зарегистрированы. Причем, поток не прекращается ни днем, ни ночью. Опять же, это все делается для того, чтобы сбить вас с толку.
Что делать
Смс-бомбинг – ситуация, безусловно, крайне неприятная. Все дело в том, что вам вряд ли удастся самостоятельно остановить поток сообщений. Но есть пару вещей, которые помогут вам пережить бомбинг:
Mainsvc – это сервис-однодневка, который задействуется мошенниками, когда они запускают sms-бомбинг в попытках взломать ваши аккаунты в социальных сетях и на любых других интернет-ресурсах.
Видео в звонках ВКонтакте: 4К-скриншеринг и Quality on-demand для тысяч участников
Что нужно от картинки в видеозвонке? Базово — чтобы не пикселила, не замирала и не вешала весь звонок. Это основы real-time видео, и добиться этого не так трудно.
Всё самое интересное начинается, когда вы хотите, чтобы в одном звонке могли участвовать сколько угодно человек. И при этом все могли включать видео, а не просто смотреть; разрешение скриншеринга было бы 4К; шеринг оставался суперчётким при любом интернете и т. д. И чтобы звонки работали на любых платформах и устройствах на мобильном нестабильном интернете.
Как мы добиваемся всего этого в звонках ВКонтакте, какие хаки в настройках используем, как экономим трафик и CPU, как боремся за latency и где нам пришлось идти в обход WebRTC, читайте под катом.
Disclaimer 1. Выводы и заключения по конкурентам сделаны исключительно из общедоступной информации, общих наблюдений и измерений, поэтому могут быть ошибочными.
Disclaimer 2. Огромное влияние на качество передачи любых real-time данных оказывает сеть, но сетевой слой мы обсудим в отдельной статье. Здесь сосредоточимся только на том, что касается передачи качественного видео.
Приступая к любой задаче, нужно составить требования, исходя из которых вы будете строить своё техническое решение. Мы провели исследование, в котором выяснили, чего хотят пользователи, — и ориентировались на эти результаты. Люди называли важные им свойства звонков, и в топ вышли качество, наличие видео, поддержка десктопа и мобильных платформ. Плюс, конечно, отсутствие ограничений по длительности и возможность пользоваться сервисом бесплатно.
Если хотелки пользователей перевести в свойства решения, то получится следующее:
качество видеозвонков складывается из качества аудио (о котором говорим в этой статье), качества видео (разрешения и FPS), низких задержек и стабильной работы;
работа на десктопе и мобильных устройствах предполагает две вещи. Первое — что нужно поддержать WebRTC как стандарт для браузеров. И второе — следует быть очень бережливыми к клиентским ресурсам, чтобы средние смартфоны справлялись с нагрузкой и им хватало пропускной способности мобильной сети;
отсутствие платы и ограничений обязывает экономить и серверные ресурсы.
Вспомним теорию
Теперь, зная вводные, пробежимся по основным понятиям, чтобы лучше представлять проблематику.
Видео, которые мы смотрим в телефоне или ноутбуке, состоят из кадров. Кадры бывают трёх типов:
I-кадры — опорные, или keyframe-кадры, содержат картинку целиком и кодируются независимо от других кадров;
P-кадры кодируют только отличия от предыдущих кадров;
B-кадры кодируют diff от предыдущего и последующего кадров.
В последовательности кадров, из которых складывается видео, типы чередуются и опорные кадры встречаются не слишком часто, а без них хорошая картинка не получится. Для видеозвонков это означает следующее: новый подключившийся участник не может начать проигрывать видео, пока не получит опорный кадр.
Если новый участник просто будет ждать, пока наступит очередь опорника, то получится дополнительная задержка на подключение — она может длиться секунды. Чтобы не ждать и не мучиться с задержкой, можно запросить опорник с помощью full intra request (FIR) по требованию. Но это лишний трафик, потому что опорный кадр кодируется с меньшей степенью сжатия, чем diff.
Видеокодеки
Как фреймы с камеры будут закодированы, то есть какой будет последовательность опорных и остальных типов кадров, как они будут сжаты, сколько их будет в одной секунде и так далее — всё это определяет видеокодек. По сути это алгоритм, который может быть, например, довольно тупым, но очень быстрым, или суперэффективным по битрейту, но тяжёлым.
Кодирование видео и выбор кодека — это всегда компромисс.
Каждый раз в этом вопросе у нас две чаши весов: с одной стороны раскалённый телефон, который по узкому сетевому каналу передаёт отлично сжатое видео, с другой — сэкономленная батарейка и видео с более высоким битрейтом, для отправки которого нужна большая пропускная способность.
Разные кодеки лучше подходят для определённых случаев. Например, H.264 аппаратно ускоренный и поэтому экономит ресурсы, но сильно уступает VP9 по качеству сжатия на низких битрейтах. Ниже условные графики того, как растёт нагрузка на устройство и какое получается качество в зависимости от битрейта — для H.264 слева и для VP9 справа.
Поэтому у нас есть механизм адаптации и мы переключаемся между этими двумя кодеками (или откатываемся на что-то ещё, если они недоступны). Если битрейт выше порога, то используем H.264, если ниже — VP9.
В результате не превращаем телефон в сковородку на высоких битрейтах и вытягиваем качество на низких.
Второй компромисс, на который нужно пойти при выборе кодека, лежит между его современностью и распространённостью поддержки. Например, AV1 — очень классный кодек. По данным Facebook, AV1 позволяет уменьшить битрейт при одинаковом качестве на 50% относительно H.264 и на 30% по сравнению с VP9. Но он пока требует очень много вычислительных ресурсов и не поддерживается аппаратно — а значит, всё равно не будет доступен большинству наших пользователей. Даже если поддержать его, решения для качественной работы с другими кодеками будут необходимы.
Видео в групповом звонке
Вопросы экономии ресурсов и трафика становятся гораздо острее, когда мы переходим от звонков один на один к групповым.
В звонке тет-а-тет нужно закодировать и отдать, получить и декодировать для воспроизведения на клиенте всего одно видео. На это хватит сети в 1–2 Мбит/с, и можно использовать аппаратно ускоренное кодирование. В групповом звонке мы хотим видеть несколько видео — то есть, скорее всего, нужно больше энкодеров, а большинство устройств поддерживает аппаратно ускоренное кодирование только одного потока в один момент времени. Насколько увеличится трафик и будет ли он расти пропорционально числу участников, зависит от топологии.
Для звонков один на один мы всегда, когда это возможно, устанавливаем peer-to-peer соединение, которое выгоднее с точки зрения latency. Для групповых звонков теоретически есть три варианта: установить p2p-соединение каждого с каждым (Mesh), смиксовать на сервере все потоки в один (MCU) или использовать сервер по сути как ретранслятор пакетов (SFU).
Топология MCU — Multipoint Conferencing Unit — подходит для аудио (как мы его реализовали, смотрите в статье об аудиопайплайне звонков ВКонтакте), но не для видео. Ни один популярный сервис не пытается на сервере склеивать сетку из видео разных участников и посылать на клиент один поток. Интуитивно понятно, что это будет очень дорого, потому что потоки должны быть разными для всех участников (без собственного видео — и здесь это не сделать простым вычитанием, как в аудио). Например, при переключении режимов просмотра с окна с главным спикером на сетку надо перезапускать весь микс.
Поэтому для видео обычно используют SFU — прокидывают видео через сервер всем клиентам. Правда, реализации могут сильно отличаться.
В самом простом варианте сервер действительно только перекидывает пакеты, так что дорогое микширование входящих потоков ложится на клиента. Кроме этого, есть ещё два момента, от которых сильно страдает качество картинки:
Шторм опорных кадров (FIR storm). Когда новый подключившийся клиент не хочет ждать опорный кадр, он запрашивает его вне очереди. Из-за этого, во-первых, возникает лишняя нагрузка на отправителя для генерации опорника, во-вторых, его получают все участники звонка и тратят лишний трафик. То же самое с любыми перебоями сети — неполадки у одного получателя влияют на всех в звонке.
Исходящий поток нужно адаптировать, чтобы участник с самой слабой сетью мог его получить. Снова из-за одного страдают все: видят собеседников не чётко, а в крупный квадратик.
Второй вариант для forwarding — simulcast.
Идея заключается в том, чтобы отправляющий клиент на своей стороне кодировал видео сразу в нескольких разрешениях. Сервер при этом всё так же перекидывает видео, но уже может выбрать из нескольких вариантов: например, отправить клиенту с мощным девайсом и стабильной сетью хорошее качество, а клиенту со слабеньким 3G самое маленькое разрешение.
Simulcast частично решает проблему понижения качества для всех и частично шторма опорников, но требует очень много клиентских ресурсов: как CPU- и GPU-вычислений (чтобы батарейка улетала за час), так и гораздо большего сетевого канала на отдачу.
Более продвинутая технология SVC (Scalable Video Coding) делает примерно то же, но внутри кодека. В один закодированный поток укладывается несколько SVC-слоёв с разными качествами. Такой подход потребляет ресурсы немного скромнее и требует чуть меньшей ширины исходящего канала, чем simulcast, но не решает проблему шторма опорных кадров (поток-то в результате один). И главный недостаток SVC — нет поддержки в браузерах. Для нас это сразу делает его непригодным.
В итоге мы, как всегда, вынуждены идти своим путём. Мы знаем, что для наших пользователей важнее всего качество, поэтому понижение битрейта по любому поводу для нас не вариант. Также на примере работы со звуком мы выяснили, что любая дополнительная нагрузка на телефон не только делает из него сковородку, но и добавляет случайные задержки и вообще-то портит качество. Значит, нужно серверное транскодирование.
При серверном транскодировании клиент отправляет на сервер видео в лучшем качестве, которое может закодировать и передать по доступной сети. На сервере это исходное видео транскодируется в несколько качеств поменьше и раздаётся остальным участникам, кому какое подходит. Нет проблем с тем, чтобы подстроиться под сеть каждого участника группового видеозвонка: опорные кадры можно генерировать на сервере, когда надо, и это не влияет ни на отправляющего клиента, ни на остальных собеседников. Одна проблема — это дорого. Но с этим тоже можно бороться.
Качество по запросу
Вообще говоря, в групповом звонке с серверной топологией нетрудно узнать, как в интерфейсе показывается видео каждого участника. У нас есть два основных варианта раскладки:
один говорящий в большом окне по центру и рядом несколько человек в совсем маленьких окошках;
сетка с видео одинакового среднего размера.
Очевидно, что видео в хорошем качестве нужно только для главного спикерского окошка. А если вы пока молчите и ваше видео показывается в миниатюре, то не нужно ни кодировать его в высоком качестве, ни пересылать по сети и через сервер. А если участников много и мы знаем, что ваше видео вообще ни у кого не влезло на текущий экран звонка, то его можно и вовсе не передавать — так сэкономятся и ваши ресурсы, и серверные.
То есть сервер говорит клиенту: «Давай видео не больше, чем такого-то качества, лучше пока не нужно». Если раскладка изменится — например, участник станет спикером или просто кто-то захочет посмотреть его видео внимательнее и развернёт его у себя в приложении, — сервер запросит видео в большем разрешении.
Переключение качества по запросу в исходящем потоке выглядит в webrtc-internals вот так:
Сначала никто не смотрит видео этого клиента — ничего не посылаем. Потом видео попало в большое окошко — битрейт подскочил. Последний отрезок — видео где-то в сетке, битрейт и размер фрейма меньше.
Понятно, что на резких переключениях туда-сюда можно просадить всю выгоду: завалить клиента запросами и замучить кодек постоянным переключением, в том числе генерацией новых опорников. Поэтому не забываем о здравом смысле и тротлим резкие переключения на понижение качества. То есть если вы только что говорили, то мы немного подождём и попересылаем качественное видео — на случай, если вы скоро продолжите. С другой стороны, запрос на повышение качества стараемся выполнить сразу: если уж видео показывается в большом окошке, оно должно выглядеть хорошо.
Кодирование видео на клиенте по запросу помогло нам значительно сэкономить сеть и серверные и клиентские ресурсы:
на 62% меньше клиент-серверного трафика;
на 21% меньше нагрузки на клиентский CPU;
на 12% меньше использование серверного CPU.
И это в самом неоптимальном случае для трёх участников. Если их больше, то больше и вариантов показа. Плюс есть вероятность, что чьё-то видео вообще не потребуется. Соответственно, суммарная выгода будет выше.
Но и это ещё не всё. Допустим, у всех участников примерно одинаковая сеть и никто не смотрит видео от определённого клиента на главном экране. Значит, нам нужно раздать его только в одном исходном качестве — среднем. И только если подключится кто-то новый с худшей сетью, для кого понадобится понизить битрейт, мы запустим транскодирование на сервере и нарежем минимальное качество. По факту, у нас 40% видео не требует транскодирования и пересылается в исходном виде, как в чистом SFU.
Итого: топология и кодирование в групповом видеозвонке
Выбирая групповую топологию для работы с видео, сразу откажитесь от MCU и помните главные недостатки разных вариантов реализации SFU:
чистый SFU — много входящего трафика, шторм опорными кадрами и другие проблемы;
simulcast — лишний исходящий трафик и большая нагрузка на клиентские устройства;
SVC — лучше, чем simulcast, но не работает в браузерах;
Quality on-demand — наш подход бережёт ресурсы пользователей и перекладывает нагрузку на сервер.
Конкретный выбор зависит от ваших требований и возможностей. Простой SFU из коробки есть в open-source проектах и нормально сработает для небольшого числа участников. Но 50 человек в звонке для готового типового SFU — это предел. Браузер, использующий WebRTC для передачи видео, скорее всего, начнёт разваливаться ещё раньше.
Мы выбрали серверное транскодирование для того, чтобы не нагружать клиентов, но стараемся экономить и CPU сервера:
транскодируем видео на бэкенде по запросу. Когда можем, пересылаем оригинальный поток или не посылаем ничего, если видео никто не смотрит;
за счёт серверного транскодирования отдаём опорные кадры по запросу, не влияя на остальных участников звонка. Таким образом ускоряем подключение;
медиана passtrough latency для видео — 40 мс. Такую дополнительную задержку вносит серверное транскодирование, если оно потребовалось (но это бывает редко);
серверные ресурсы: 0,39 CPU на пользователя, из них 0,34 CPU на видео и 0,05 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 доедут до всех браузеров.
За счёт кастомного пайплайна мы поддерживаем демонстрацию экрана в 4K на мобильных платформах и в нативном десктопном клиенте. Скриншер на мобильных можно зумить пальцами, поэтому 4К тут не ради красивой цифры, а действительно приносит пользу. Можно подключиться к рабочему миту с телефона и спокойно рассмотреть графики — особенно если коллега шерит Retina-экран с нашего нового десктопного клиента (если захотите проверить качество скриншеринга — скачать клиент можно тут). На вебе можем показывать 4К, а шерить только 2К из-за ограничений браузеров. Здесь мы пока на уровне средних пользователей с мониторами Full HD. Но когда 4–8К будет более распространено, мы уже точно научимся его поддерживать.
Где мы относительно конкурентов
В нашей архитектуре групповых звонков участвует собственный conferencing-сервер, и мы выбрали серверное транскодирование. Нужно проверить, как это сказалось на latency — показателе, который сильно влияет на субъективное восприятие качества.
Задержку по видео измеряем с помощью уже отработанного приёма: снимаем секундомер, фотографируем вместе экран с исходящим видео и экран принимающего клиента, сравниваем.
Вот что получили по видеозвонкам на компьютере на хорошей сети, но по Wi-Fi (сеть по сервисам выровнена).
Отдельно посмотрели на сети, задушенной до 300 Кбит/с. Здесь как раз вступают в игру отработка сбоев, борьба со штормом опорников и ухищрения с кодеками.
С мобильными клиентами тоже особый разговор: там жёстче борьба за нагрузку, но есть аппаратное ускорение. И это нативный клиент, а не универсальная браузерная реализация.
Во всех измерениях у ВКонтакте задержка или на уровне сервисов-конкурентов, или минимальная среди них. Давайте разберёмся почему.
Синхронизация звука и видео
Референсные исследования показывают: если голос (звук) немного отстаёт от видео, это не так заметно, как когда он опережает картинку.
Человеческий мозг легко компенсирует задержку звука, а вот слышать раньше, чем видеть, ему некомфортно. Рассинхронизация звука и видео в диапазоне от −100 до +60 мс незаметна.
Попробуем воспользоваться этим знанием. Посмотрим, сколько занимает процессинг аудио и видео по перцентилям.
Понятно, что на клиентах всё может быть по-разному. Но задержки на нашем бэкенде как раз в тех порядках, что и диапазон незаметного рассинхрона.
Поэтому мы отказались от lipsync. Мы передаём с сервера аудио и видео независимо, и на клиенте они не синхронизируются каким-либо специальным образом — мы надеемся на то, что различия будут несущественными и пользователи их не заметят. Если узнаем, что это мешает пользователям, то сможем включить. Но пока и без lipsync получается хорошо, а главное — с меньшими задержками.
Пайплайн для работы с видео
В итоге наш пайплайн для работы с видео позволил поддержать 4К в том числе для скриншеринга, сэкономить более 60% клиент-серверного трафика и 10–20% CPU клиента и сервера. Так что скоро мы сможем полностью снять ограничение на число участников в звонке, и все они смогут подключаться с видео.
aдаптивный выбор кодека в зависимости от сети и устройства: используем VP9 для качественного видео на низких битрейтах, а на высоких — H.264 для меньшей нагрузки на устройство;
SFU-топологию для групповых звонков с серверным транскодированием видео в меньшие разрешения — это позволяет экономить клиентские ресурсы и бороться со штормом опорных кадров;
Quality on-demand, или кодирование исходящего видео в качество по запросу, — тоже для уменьшения нагрузки на клиентов и экономии трафика.
демонстрацию экрана в обход WebRTC — так понижаем FPS, но сохраняем чёткость изображения и поддерживаем 4К.
При этом пайплайн не включает синхронизацию аудио и видео, что позволяет нам иметь наименьшую задержку среди популярных сервисов видеоконференций.
В следующей статье соберём все знания о работе с real-time аудио и видео и построим архитектуру сервиса видеозвонков без ограничения на число участников.
Благодарности: собирать данные и готовить статью помогали Иван Григорьев (@Ivan_A), Андрей Петухов, Никита Ткаченко, Андрей Моржухин.
P. S. Сегодня важный день: мы выпускаем SDK наших звонков на рынок. В него мы упаковали все свои технологии для реализации групповых видеозвонков. Прежде эту библиотеку помимо ВКонтакте могли встроить только сервисы из Mail.ru Group: Учи.ру, «Сферум», Одноклассники и Звонки Mail.ru. Теперь, когда все возможности обкатаны на этих масштабных платформах, мы предлагаем их и другим IT-бизнесам.
Что есть внутри SDK, как получить тестовый доступ и интегрировать звонки в свой продукт (бесшовно, с собственным интерфейсом) — рассказываем на лендинге и в релизе.