Оптимизация и практика архитектуры WebRTC

WebRTC — это в первую очередь стандарт, на данный момент запущен w3c стандарт WebRTC 1.0, версия 2.0 тоже находится в процессе продвижения (пока не время речи). Второй — это протокол, разработчики могут следовать этому протоколу для достижения совместимости с WebRTC. Кроме того, это еще и движок, потому что его предшественником является движок GIPS, обрабатывающий аудио и видео. Кроме того, под этим движком существует большое количество аудио- и видеоалгоритмов, так что WebRTC тоже можно назвать алгоритмом.

Как было сказано выше, предшественником WebRTC является GIPS, а развитие GIPS фактически делится на два этапа, первый этап — Global IP Sound, а второй этап — Global IP Solution. Он используется в качестве механизма аудиосвязи в различных встроенных системных устройствах на сцене Global IP Sound и в основном отвечает за основные функции, такие как эхоподавление, шумоподавление и кодек.

После этого к видеосервису добавили аудиосервис, то есть этап Global IP Solution.Позже в общении с клиентами продолжили добавлять протоколы IP-коммуникаций, протоколы RTP и т. д. для реализации возможности соединения с сеть. Однако из-за неразумного ведения бизнеса и провала стратегии продаж он в конечном итоге был приобретен Google более чем за 60 миллионов долларов США.

С точки зрения технологической эволюции, от GIPS к WebRTC, он фактически инкапсулирует слой Engine и, кстати, также добавляет сетевые модули, отсутствовавшие в оригинальном GIPS. Как правило, для предоставления аудио- и видеоуслуг требуется сервер, чтобы избежать этого режима, WebRTC использует режим связи P2P.

Лично я считаю, что более 99% приложений, связанных с общением в реальном времени, все более и более неотделимы от WebRTC.Даже если структура кода приложения отличается, в WebRTC все еще есть много классических алгоритмов, на которых стоит учиться.

Обычно мы можем использовать WebRTC в качестве кода входа для обучения и трансплантации алгоритмов или абстрагировать его аудио- и видеодвижок, а также можем использовать его как услугу PaaS или SaaS.

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

WebRTC действительно можно использовать для предоставления услуг SaaS, но вам нужно подумать, какой тип услуг SaaS вы хотите использовать в первую очередь. Например, для служб аудио- и видеосвязи, которые не основаны на Интернете, клиент также должен учитывать возможность взаимодействия.

Различные отрасли предъявляют к этому разные требования, например, колл-центры и образовательные учреждения, которые обычно используют Интернет непосредственно для предоставления услуг. Однако совместимость WebRTC в нескольких браузерах оставляет желать лучшего, да и поддержка видеокодеков тоже разная.

При использовании мы должны гибко использовать p2p в соответствии с требованиями к качеству обслуживания и характеристиками пользователя.Например, p2p может быть лучшим выбором, когда большинство пользователей находятся в среде WiFi, но эффект p2p в сетях 4G будет хуже.

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

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

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

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

В сервисах SaaS мы можем анализировать поведение пользователей и оптимизировать сценарии использования пользователей. Однако в сервисе Paas пользователи сильно различаются и могут включать различные области, такие как IoT, образование и игры.Первоначального движка WebRTC определенно недостаточно.

Следовательно, в дополнение к различным базовым услугам, включая SaaS, необходимо абстрагировать набор API, а затем адаптировать их к каждому мобильному устройству, а также предоставить различные дополнительные функции в соответствии со сценариями приложений, а также обеспечить специальную оптимизацию и упаковку. пошив по сценариям.Подождите.

Поскольку WebRTC по сути ближе к аудио- и видеодвижку, будет удобнее, если его использовать как AV SDK.

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

Аудиочасть инкапсулирует в общей сложности 4 модуля в WebRTC, ANM (сетевой модуль), APM, ACM (модуль кодека), ADM, и соответствующее видео также имеет те же 4 модуля, так что всего модулей 8. Лично я думаю, что основное внимание в WebRTC уделяется самим 8 модулям и настройке параметров между ними.

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

Только изучив алгоритм WebRTC, мы сможем четко объяснить клиентам, почему принимается текущее решение и почему другие решения не используются на разных уровнях. Суть WebRTC заключается в базовой части движка, но если вы хотите получить глубокое понимание этой части, вы должны сначала изучить алгоритм.

Как упоминалось ранее, в WebRTC есть 8 модулей и 2 основных движка: звуковой модуль включает APM, ACM и ADM, а видеомодуль включает VNM, VPM и VCM.

APM

Алгоритмический NLP, охватывающий AGC, ANS, DE и подавление эха в APM. Далее давайте пошагово рассмотрим, что же внутри.

Обычно существует два алгоритма эхоподавления: адаптивная фильтрация и NLP. На самом деле, до WebRTC адаптивная фильтрация была сделана достаточно хорошо, сейчас исследования в этой области в основном застопорились, и может быть некоторая исследовательская ценность в многоканальном и стерео эхоподавлении. НЛП отличается.Есть много деталей, которые стоит обсудить.Это связано с тем, что звуковой дизайн каждого резонатора отличается, что приводит к различиям в нелинейных частях.

В WebRTC есть два модуля эхоподавления, AEC и ANS.Алгоритм NLP AEC учитывает множество деталей.Если вы хотите изучить его алгоритм, вы можете внимательно изучить его патентное описание.

DE — это модуль оценки задержки, и этот набор алгоритмов сейчас используется почти всеми модулями оценки задержки. Основная задача AGC состоит в том, чтобы настроить нешумовую часть вверх и шумовую часть вниз.Фокус здесь заключается в том, как отличить шум, что равносильно проблеме шумоподавления.

AGC в WebRTC ставится вместе с VAD.VAD использует модель GMM, которая определяет, является ли текущий голос голосом с помощью статистических методов, а затем объединяет его с AGC.Хотя все параметры в AGC все равно нужно Настроил, алгоритм все еще хорош, можно использовать напрямую.

ACM

Кодеки WebRTC — ILBC, ISAC и Opus: ILBC — узкополосный кодировщик, ISAC — широкополосный кодер, а Opus — полнополосный унифицированный кодировщик аудио и голоса. Opus может работать очень хорошо, когда производительность процессора высока и он может работать с высокой пропускной способностью.

ANM

Что делает ANM, так это оценивает пропускную способность и контролирует перегрузку.Из-за большой пропускной способности в настоящее время немногие люди делают оценку пропускной способности для аудио, а видео все еще относительно распространено. Интересно, что оценки пропускной способности звука записываются в код ISAC.

Мы знаем, что потеря пакетов обычно делится на два типа: случайная потеря пакетов и потеря связанных пакетов.Перегрузка относится к категории потери связанных пакетов.Например, непрерывная потеря нескольких пакетов или сбой отправки пакетов считается перегрузкой.

ПЛК в ANM — это алгоритм, который растягивает ускоренную перемотку вперед и замедление.Например, если вы хотите сохранить 200-миллисекундные данные в 100-миллисекундном пакете, ПЛК замедлит пакет для достижения эффекта 200-миллисекундного , Способ борьбы с потерей сетевых пакетов. Преимущество ПЛК в том, что переменная скорость не меняется.

видео

По сравнению с аудиомодулем, в видео части еще много места для раскопок, и легко провести дифференциацию.

К видео предъявляются более высокие требования в сети, а прямая трансляция и общение являются обычными сценариями. В прямом эфире упор делается на ясность, а в общении больше внимания уделяется беглости. Разница в фокусе приносит больше настроек параметров. Например, рассмотрите защиту от потери пакетов в сочетании с кодеками, рассмотрите кодеки в сочетании с шумоподавлением и аппаратной адаптацией.