Эта статья составлена на основе выступления Чена Гуна на конференции RTC «Архитектура и практика аудио- и видеосервисов реального времени на веб-страницах». Добро пожаловать в гостиСообщество разработчиков RTC, обмениваться опытом с другими разработчиками и участвовать в технических мероприятиях.
陈功
负责网页端音视频通信技术架构。毕业于中国科学技术大学，Ph.D。原英特尔服务器事业部多媒体架构师，主导基于WebRTC的视频会议解决方案搭建。曾任职Marvell视频事业部，研究多媒体系统框架，参与Google TV, OTT等项目
Каковы характеристики общения в режиме реального времени в Интернете
Прежде всего, на стороне браузера это зависит от способности браузера получать аудио и видео, а также от мощных возможностей рендеринга на веб-страницах, поэтому он может заложить основу для общения в высоком разрешении. В то же время, по сравнению с мобильным терминалом, экран больше, а выбор окна более гибкий.
Во-вторых, кроссплатформенность. Все знают особенности браузеров для каждого терминала: браузеры есть не только на ПК и мобильных терминалах, но даже в некоторых известных социальных приложениях есть встроенные браузеры. Для этого требуется кроссплатформенный опыт, и сейчас все больше и больше браузеров поддерживают WebRTC, что также является функцией общения в реальном времени на веб-страницах.
В-третьих, бесплатная установка и легкий доступ. Благодаря популярности WebRTC он может осуществлять общение в режиме реального времени на веб-странице без установки каких-либо плагинов.
К каким сценариям можно применить общение в реальном времени на веб-странице?
Первый - это живая трансляция, которая очень популярна. Хозяин Live Broadcast будет иметь спрос, и трансляция будет запущена на веб-странице, потому что экран веб-страницы относительно велик, видео относительно понятно, а мощность обработки относительно сильна. В то же время это также очень интересно. Один из наших клиентов также использует SDK на нашей веб-странице, чтобы отслеживать живую трансляцию. Как мы все знаем, есть много комнат для прямых вещаний. Вы можете контролировать 40-50 номеров на веб-странице, чтобы быть инспекторами живой трансляции. Удобнее использовать аудио и видео SDK в режиме реального времени веб-страница.
Другой - это онлайн-образование. Учителя онлайн-образования, как правило, на ПК. Если вы хотите установить приложение, некоторые учителя не понимают компьютерные технологии очень хорошо, и это более неприятно настроить. Если в Интернете есть решение без установки, если они его используют, пользовательский опыт будет лучше. В дополнение к аудио и видео, онлайн-образование также требует совместного использования экрана и доска. Поскольку они являются всеми технологиями H5, это будет очень удобно интегрировать с SDK на веб-стороне.
Последнее - видеоконференция. Если вы использовали браузерную видеоконференцию в компании, у вас будет опыт. HR пришлет ссылку. В определенное время вы нажмете на ссылку. Кроме того, есть некоторые инструкции, что делать вы хотите установить, это будет сложнее. Теперь, когда WebRTC не требует установки, опыт проведения видеоконференций также поднимется на более высокий уровень. Вот типичные сценарии, перечисленные здесь.На самом деле, есть телемедицина, корпоративная совместная работа и тому подобное.
С технической точки зрения, является ли коммуникация в режиме реального времени на веб-странице зрелой? Вы готовы?
Когда речь заходит об обмене данными между веб-страницами и браузерами в режиме реального времени, первое, что приходит на ум, это Webex.У него очень хороший опыт, и он также привлек большую группу целевых пользователей, так что пользователи могут понять, что видео может выполняться в браузере.общение открыло рынок. Однако у него есть недостаток в том, что он должен устанавливать плагины и расширения для браузера, что то же самое, что и GoToMeeting, что очень неудобно. Другой способ — установить прикладную программу на ПК и использовать эту программу для получения и обработки аудио- и видеопотоков в качестве прокси, а веб-страница только выполняет рендеринг и отображение.
В течение долгого времени пользователи этих веб-страниц чувствовали, что эта технология такая, опыт такой, и его нельзя улучшить. До 2011 года появилась технология WebRTC, которую продвигал Google. Опыт WebRTC привлек внимание из-за отсутствия установки. Теперь, когда время разработки составляет почти 6 лет, на самом деле есть много сомнений, например, будет ли проект Google заброшен на полпути, и не поддержат ли основные производители браузеров эту идею открытия экосистемы браузера.
##Является ли WebRTC зрелым и готовым к эксплуатации?
Во-первых, давайте взглянем на текущие знания о браузерах и платформах WebRTC.
Самой ранней поддержкой WebRTC были Firefox и Chrome, за которыми последовала Opera, а последующий хром поддерживает WebRTC, и их ядра одинаковы. Два года назад Microsoft предложила протокол ORTC, который чем-то похож на WebRTC. ORTC не развивался гладко, и теперь поддерживает WebRTC в периферии. После того, как Apple недавно обновила систему IOS, Safari 11 также стал поддерживать WebRTC. На платформе Android поддержка WebRTC началась очень рано.
Давайте посмотрим на рыночную долю этих браузеров, нетрудно заметить, что кроме IE, на долю которого приходится несколько процентов, он его не поддерживает, другие браузеры фактически уже поддерживаются.
Давайте посмотрим на это с точки зрения стека протоколов. Спецификация WebRTC 1.0 в основном доработана, за исключением некоторых более подробных вопросов, которые не были доработаны. Поддержка стандартов также становится все лучше и лучше в разных браузерах. В то время как сама Google продвигает эту технологию, собственный браузер Google, Chrome, не очень хорошо поддерживает WebRTC 1.0, потому что Google делает много экспериментальных вещей с WebRTC внутри. Команда Chrome утверждает, что к концу этого года она будет полностью соответствовать стандарту WebRTC 1.0.
С другой стороны, посмотрите на сообщество открытого исходного кода. Чтобы назвать несколько типичных проектов с открытым исходным кодом, одним из них является Kurento, который представляет собой мощную среду обработки мультимедиа, поддерживающую стек протоколов WebRTC. Его можно использовать в качестве медиа-сервера с возможностями транскодирования в фоновом режиме и возможностями обработки OpenCV. Licode можно использовать в качестве облегченной коммуникационной платформы для WebRTC, который представляет собой чистый режим обработки сервера пересылки. Janus можно использовать в качестве коммуникационного шлюза WebRTC, который является относительно легким. Стоит обратить внимание на React-Native-WebRTC. Сейчас все больше и больше разработчиков обращаются к фронтенду, JS. Такая ситуация более распространена за границей. В сообществе с открытым исходным кодом есть такой проект, который инкапсулирует модуль WebRTC, и разработчики могут легко реализовать приложения с возможностями связи в реальном времени и совместимыми с WebRTC на мобильных телефонах.
Наконец, посмотрите на экосистему. На уровне CPaas вносят свой вклад такие компании, как AudioNet, Twilio и Tokbox.
Анализ рынка очень оптимистичен в отношении WebRTC, и ожидается, что к 2022 году объем рынка достигнет 6,49 млрд долларов США. В целом, технология WebRTC сейчас переживает лучшие времена.
Для разработчиков, как использовать эту технологию и как построить систему WebRTC? На самом деле путь есть.
Мы знаем, что нижний уровень WebRTC основан на P2P-соединении, то есть на двухточечной связи. Когда многие разработчики начинают работу, они проводят проверку качества P2P. Например, менеджер по продукту компании сказал разработчикам: «Теперь WebRTC очень популярен, дайте мне целую систему WebRTC».
Итак, каковы характеристики архитектуры, полностью основанной на одноранговой связи? Задержка будет меньше. Однако есть большой недостаток. В этом виде передачи аудио- и видеопотока «точка-точка» каждый пользователь должен передавать свой собственный видеопоток другому пользователю, что оказывает большое давление на его пропускную способность в восходящем направлении. Кроме того, каждый видеопоток захватывается и кодируется независимо, что является серьезной проблемой для кодирования со стороны браузера. Некоторые люди спросят, а можно ли захватить код только один раз, а затем отправить этот поток на разные получатели терминалов? К сожалению, это невозможно. Поскольку протокол WebRTC предназначен для оптимизации сквозной политики качества, он имеет некоторые корректировки политики, которые реализуются сквозным RTCP, который необходимо многократно кодировать, а затем передавать на разные получатели.
В таблице в правом нижнем углу указана системная архитектура, использующая WebRTC в настоящее время в Интернете согласно статистике авторитетной отраслевой организации, на чистый P2P приходится всего 19%.
Если разработчик поставит продукт в соответствии с только что представленной архитектурой, он обязательно перезвонит, потому что все знают, что пропускная способность восходящего потока очень ценна и очень ограничена. Чтобы решить эту проблему, разработчики проведут углубленное исследование и обнаружат, что архитектура WebRTC в этой области фактически добавляет точку посередине.Эта точка — сервер.Типичный медиа-сервер выполняет только многопотоковую пересылку и не не делать фоновую обработку мультимедиа и транскодирование.
Упомянутые выше проекты с открытым исходным кодом Janus и Licode могут реализовать функцию переадресации медиасерверов. Его характеристика заключается в том, что каждому конечному пользователю нужно только полностью загрузить данные на промежуточный сервер, что экономит полосу пропускания. В то же время SFU выполняет только пересылку, поэтому влияние на задержку относительно невелико. Недостатком является то, что если есть два получателя, пропускная способность нисходящего потока различна, один составляет 500 КБ, другой - 2 м. Поскольку отправитель-источник отправляет только один поток, его трудно адаптировать к нескольким терминалам.
После перехода на чистый форвардный медиасервер он все же имеет некоторые недостатки, и разработчики найдут способ сказать, что я добавляю функцию микширования потоков на средний узел. Вы также можете видеть из этой архитектуры, что после того, как сервер получит два разных видеопотока, он будет декодировать, склеивать, синтезировать и кодировать соответственно. В зависимости от пропускной способности разных приемников видеопотоки с разными профилями отправляются соответственно разным получателям. Это решает проблему: при наличии нескольких пользователей приемника адаптация полосы пропускания невозможна. Этот недостаток также очевиден: транскодирование в середине неизбежно приводит к задержкам, а затем и к высокой стоимости сервера транскодирования, однако позволяет экономить полосу пропускания на нисходящем канале.
После представления нескольких типичных системных архитектур WebRTC разработчики могут легко создавать на основе только что упомянутых проектов с открытым исходным кодом или создавать такую демонстрационную систему, не занимая слишком много времени.Разве это не конец истории? На самом деле до него еще далеко, и здесь еще много скрытых ям.
Технические трудности позади
На приведенном выше рисунке показаны ямки, с которыми придется столкнуться при превращении демоверсии в относительно стабильный продукт.
Первое — это доступность. WebRTC основан на P2P, и удобство использования и успешность соединения P2P также критикуются всеми, не только пробиванием дыр и обходом этих технологий.
Совместимость платформ: время для выхода WebRTC все еще ограничено. Компании во многих областях имеют свои собственные протоколы связи, разработанные ими самими. Эти протоколы обычно используются на собственной стороне, мобильных телефонах, ПК, Mac и Windows. Это также приносит какой-то Вопрос, как можно добиться совместимости платформ между протоколом собственной разработки и протоколом WebRTC? В нем тоже много ям. Я просто сказал, что это сквозная оптимизированная стратегия передачи.Если разобрать сквозную передачу, ваш восходящий поток — это WebRTC, ваш отправитель — WebRTC, а получатель — саморазработанный конец. стратегии, соответствующие работе, должны быть выполнены.
Выбор кодировщика: кодирование аудио и видео очень важно при общении в реальном времени. Видео WebRTC, поддерживает VP8/9, H.264. Некоторые люди могут выбрать H.264, думая, что его можно адаптировать для мобильных устройств. Тем не менее, H.264 не очень развит в Chrome, поэтому многие коммерческие продукты все еще используют VP8, но когда дело доходит до совместимости мобильных терминалов, необходимо учитывать выбор кодировщика.
Слабая сетевая конфронтация: WebRTC имеет собственный набор стратегий передачи, таких как повторная передача потерянных пакетов, FEC, определение пропускной способности и динамическая регулировка скорости передачи данных. Однако с точки зрения слабой сетевой конфронтации на предыдущей архитектурной диаграмме также упоминалось, что мы добавим узел пересылки посередине, так что сквозной канал передачи не может быть достигнут. Поэтому слабая сетевая конфронтация является более хлопотной проблемой. Как оптимизировать аплинк и даунлинк отдельно в браузере и на сервере форвардинга, тут тоже много проблем которые нужно преодолеть.
Многопользовательская сцена: как и в типичной небольшой сцене прямого эфира, есть много получателей, отправитель. Если используется политика передачи чистого WebRTC, потому что пропускная способность нисходящего канала, оцененная между несколькими получателями, различна, корректировка скорости кода, отправляемая отправителю, отличается. Если у вас есть опыт тестирования, вы обнаружите, что WebRTC — это многопользовательская сцена.Если количество получателей превышает 4, 5, кодовая скорость, которую он отправляет, будет очень низкой, поэтому увиденное изображение будет очень пастозным.
Хотя основные браузеры начали поддерживать WebRTC, на самом деле в так называемой поддержке WebRTC все еще остается много проблем с совместимостью. Желтый цвет на картинке выше означает частичную совместимость, и только Firefox поддерживает его здесь лучше. В настоящее время самым популярным является Safari.Здесь вы можете увидеть различные технические трудности.При работе с WebRTC мы должны столкнуться с этим, когда Demo будет коммерциализировано.
Интеллектуальная маршрутизация: оптимизирована передача между браузером и сервером, но период передачи между сервером и распределенным сервером все еще существует. Это требует от производителей, предоставляющих услуги WebRTC, очень хорошей интеллектуальной маршрутизации и оптимизации передачи между внутренними серверами, такими как межоператорские и многонациональные. Эксплуатация и техническое обслуживание с высокой доступностью обсуждаться не будут.Чтобы обеспечить доступность сервиса, нельзя приостанавливать процесс обслуживания. Массивная параллельная архитектура, обычно предоставляемая производителями WebRTC, представляет собой форму расширения по запросу, но она также требует, чтобы архитектура, которую вы проектируете, поддерживала массовое параллельное расширение. Также есть глобальная система мониторинга, вы можете следить за данными стабильности качества обслуживания, работающего в режиме онлайн. Другим очень важным вопросом является инструмент опроса.После того, как вы обеспечите связь в реальном времени по WebRTC, у вас должна быть возможность исследовать проблемы. Например, если есть зависание или задержка в общении, в чем причина и какие факторы вызывают плохое общение, для этого требуется полный набор инструментов для исследования проблем.
Сказав так много, резюмируя два момента, чтобы перейти от демо-версии, разработанной WebRTC, к действительно зрелому сервису продукта, у нас сначала должна быть профессиональная команда. Эта профессиональная команда должна включать в себя профессионалов и экспертов в области аудио- и видеосвязи, а также экспертов в области аудио- и видеосвязи и передачи видео, и требует большого опыта работы в отрасли.Эксплуатация и техническое обслуживание с высокой доступностью, мониторинг в реальном времени и инструменты расследования требуют настоящих инженеров и специалисты накопили опыт в наработанной работе.
Наконец, давайте представим SDK SoundNet WebRTC. Он также представлен с нескольких аспектов: качество ядра, простота интеграции, гибкое расширение функций, стабильность обслуживания и возможности глобального мониторинга.
-
Основное качество: SoundNet имеет большую сеть SD-RTN™, которая может гарантировать глобальную передачу. Web SDK использует архитектуру распределенного шлюза, которая развертывается на границе большой сети, что может повысить доступность.
-
Сосредоточьтесь на функциональной совместимости: только потому, что звуковая сеть имеет такую архитектуру распределенного шлюза, мы можем получать информацию об адаптации, отправленную с разных терминалов, и можем гибко настраивать стратегии каждой платформы. Поэтому в мониторинге каждого браузера мы тоже можем относительно неплохо.
-
Гибкая конфигурация стратегии передачи: мы трансформируем весь сквозной канал передачи WebRTC от сквозного до шлюза и от шлюза до конца. В этом мы также настроили много FEC и немного оптимизировали стратегию. В то же время мы также можем отправлять несколько потоков. Дифференцированный выбор кодировщика: мы можем выбирать разные кодировщики, адаптировать их в соответствии с возможностями терминала и учитывать, есть ли на терминале аппаратное кодирование и декодирование, а также программное кодирование и декодирование. Эти пункты в сумме гарантируют, что SDK нашей звуковой сети может быть обновлен до высококачественной службы передачи.
-
Быстрая интеграция: Это очень удобно, для доступа к нашему каналу видеосвязи требуется всего четыре строчки кода, это очень удобно, в целом апплет аудио- и видеочата можно сделать за 4-5 минут. В то же время у нас также есть полная документация и очень легко читаемая демонстрация. Гибкое расширение функций: для сценариев связи используется традиционный WebRTC, а наш Web SDK в настоящее время поддерживает сценарии прямой трансляции, обходной потоковой передачи и записи на сервер.
- Возможности глобального мониторинга: в настоящее время мы предоставляем панель инструментов и отчеты о качестве обслуживания, и вы можете видеть различные данные, такие как качество передачи, эффект передачи и доступ пользователей к каналу. Кроме того, у нас также есть глобальные сетевые метрики, включая информацию о потере пакетов, задержке и джиттере. Тот, что справа, является частью системы диагностики проблем. Почему важна система диагностики проблем? Когда пользователь обращается к связи в режиме реального времени, и у вас возникают задержки и дрожание, мы можем знать, где проблема.Объединяя эту информацию, мы должны четко знать, что не так с каналом передачи определенного канала на линии. быть настроенным.
Предварительный просмотр курса: «Построение видеозвонка в реальном времени на веб-странице с нуля»
-
Время: 29 ноября (среда) 16:00-17:00
-
содержание:
- Необходимые базовые знания для общения и прямых трансляций
- Логика вызова Agora SDK API
- среда разработки
- Интерпретация исходного кода демо. Демонстрационные функции включают в себя: создание канала, присоединение к каналу, выход из канала, переключение камеры, отключение звука, как проверить.
- Как протестировать. Какие тесты нужны для видеозвонков и прямых трансляций и как проводить простые тесты.
-
способ участия
Этот курс проходит в форме онлайн-класса в прямом эфире.
- Сначала перейдите по ссылке ниже или нажмите, чтобы прочитать оригинал, чтобы зарегистрироваться и дождаться начала курса.
- 29 ноября в 15:45 перейдите по ссылке ниже, чтобы принять участие в курсе.
-
Ссылка для регистрации