WebRTC призван решить проблему передачи аудио и видео в реальном времени и стремится обеспечить эффективную и удобную потоковую передачу мультимедиа в реальном времени, не требующую установки, подключаемых модулей и патентных сборов.
1. Сравнение 3-х реализаций потокового мультимедиа в реальном времени
В настоящее время существует три основных метода реализации потоковой передачи в реальном времени: WebRTC, HLS, RTMP.Когда вы смотрите живые веб-сайты, вы обнаружите, что многие используют HLS (HTTP Live Streaming, http live), который является методом разделения потоковой передачи. мультимедиа на несколько. Технология независимых небольших файлов запрашивает разные файлы в зависимости от времени воспроизведения, демультиплексирует файлы hls, извлекает аудио- и видеоданные, а затем передает их в видео для воспроизведения (Safari и Chrome для Android могут воспроизводить hls напрямую ). Его преимущества: он использует традиционный протокол http, поэтому совместимость и стабильность очень хорошие, сервер может загрузить hls-файл на cdn, и тогда он может справиться с прямой трансляцией миллионов зрителей. задержка относительно велика, обычно в 10 секунд. Вышеупомянутое подходит для сценариев, в которых нет взаимодействия между аудиторией и якорем. Поскольку длина hls-файла обычно превышает 10 секунд, в сочетании со временем на создание файла задержка получается очень большой.
Это стандарт, запущенный Apple, в то время как другой RTMP запущен Adobe.Он использует длинное соединение и представляет собой полный набор протоколов передачи потокового мультимедиа.Он использует видеоконтейнеры flv, которые не поддерживаются нативными браузерами (поддерживается flash plug). -ins), но можно использовать метод websocket + MSE, связанная библиотека классов относительно мала, а прямую трансляцию на клиенте Android/IOS следует использовать чаще. По сравнению с формой фрагментации запроса HLS, RTMP использует длинное соединение для получения непрерывных потоков данных, и его задержка намного меньше, чем у HLS, обычно от 1 до 3 секунд, поэтому, если между зрителем и хост, задержка таким образом приемлема.
Третий WebRTC (Web Real Time Communication) был запущен Google в 2012 году и находился в разработке 6 лет. В марте 2018 года WebRTC 1.0 был официально завершен и поддерживается всеми основными браузерами, включая Safari (Edge получил ORTC).WebRTC стремится к эффективной аудио- и видеосвязи в реальном времени, обеспечивая более низкую задержку, чем RTMP, и меньшую скорость буферизации. Официальный также предоставляет поддержку собственной библиотеки Andorid/IOS, но фактическая реализация может состоять в том, чтобы установить веб-просмотр, запустить webrtc из веб-просмотра, а затем отобразить данные на собственном уровне.
Давайте сначала представим состав WebRTC.
2. Состав WebRTC
WebRTC состоит из трех блоков, как показано на следующем рисунке:
(1) getUserMedia отвечает за получение локальных мультимедийных данных пользователя, таких как вызов камеры для записи и так далее.
(2) RTCPeerConnection отвечает за установление одноранговых соединений и передачу мультимедийных данных.
(3) RTCDataChannel — это предоставленный канал сигнализации.В игре сигнализация является важным элементом для реализации взаимодействия.
3. getUserMedia
getUserMedia отвечает за получение локальных мультимедийных данных пользователя, включая три типа записи микрофона, видео, снятое камерой, и запись экрана.Как реализовать функцию фронтальной записи«Использовал этот API — запись с помощью WebRTC’овского getUserMedia. Настройка камеры для записи видео аналогична, метод очень прост, как показано в следующем коде:
window.navigator.mediaDevices
.getUserMedia({video: true})
.then(mediaStream => {
// 画到一个video元素上面
$('video')[0].srcObject = mediaStream;
});Если вы хотите добиться записи экрана (демонстрации экрана), вам необходимо изменить параметры для получения медиа.Следующий код изменяет параметры с камеры по умолчанию на экран:
navigator.mediaDevices
.getUserMedia({video: {mediaSource: 'screen'}})
.then(stream => {
videoElement.srcObject = stream;
});Затем появится окно с вопросом, какое окно приложения следует записывать, как показано ниже:
Например, вы можете выбрать приложение PPT и начать речь. В настоящее время это поддерживается только firefox.Edge имеет аналогичный getDisplayMedia.Chrome все еще находится в стадии разработки, но можно установить официальный плагин для браузера. видеть этоdemo.
После вызова через getUserMedia получите объект потока mediaStream, этот поток может быть отрендерен локально, и может быть передан другой стороне через RTCPeerConnection.
4. RTCPeerConnection
Чтобы реализовать двухточечное соединение клиента (данные не нужно пересылать сервером), RTCPeerConnection проделал большую работу. Первая проблема, которую необходимо решить, это проникновение в локальную сеть.
(1) NAT пробивает дыры в стенах
Чтобы установить соединение, вам необходимо знать IP-адрес и номер порта другой стороны.В локальной сети маршрутизатор может быть подключен ко многим устройствам.Например, когда домашний маршрутизатор получает доступ к широкополосному доступу, поставщик услуг широкополосного доступа назначьте IP-адрес общедоступной сети.Все устройства на этом маршрутизаторе используют этот общедоступный IP-адрес. Если оба устройства используют один и тот же номер порта для создания сокета для подключения к службе, возникнет конфликт, поскольку внешний IP-адрес одинаков. Поэтому маршрутизатору необходимо переписать IP-адрес/номер порта, чтобы различать их, как показано на следующем рисунке:
Существуют два устройства, которые используют один и тот же номер порта для установления соединения соответственно, которые преобразуются маршрутизатором в разные порты и отображаются во внешней сети как один и тот же IP-адрес и разные номера портов. соответствующий хост.
Таким образом, когда вы прослушиваете порт с номером 55020 локально, но номер внешнего порта не соответствует этому, другая сторона не может подключиться к вам, используя номер порта 55020. В настоящее время есть два решения.Первое — настроить сопоставление портов на маршрутизаторе, как показано на следующем рисунке:
Конфигурация на приведенном выше рисунке предназначена для отправки всех пакетов, отправленных на порт 8123, на устройство, идущее по адресу 192.168.123.20.
Но мы не можем просить каждого пользователя настроить свои маршрутизаторы таким образом, поэтому мы должны пробить дыры в стене.Основной метод заключается в том, чтобы сначала установить соединение между сервером и одним из них (Peer). Маршрутизатор установит номер порта для интрасети, а отношение сопоставления внешней сети будет сохранено.Например, внешняя сеть 1091, указанная выше, может вызываться приложением компьютера 55020, поэтому делается дыра.В это время сервер добавляет порт 1091 к IP-адресу и сообщает другой стороне (равному узлу): пусть он подключается, используя этот дырявый адрес. Это принцип установления P2P-соединения через перфорацию стены, который возник в онлайн-играх.Поскольку онлайн-игры часто требуют подключения к сети, WebRTC стандартизировал перфорацию NAT.
Действительность этого зависит от топологии сети пользователя, потому что, если отношение сопоставления маршрутизатора зависит как от IP + номера порта интрасети, так и от IP плюс номера порта сервера, в это время не будет дыр. , так как сервер вызывает Отверстие не может быть использовано другим внешним сетевым приложением (будет установлено другое отношение отображения). Напротив, это возможно, если таблица сопоставления адресов зависит только от IP-адреса и номера порта машины в интрасети. WebRTC также предоставляет решение, когда дыру сделать невозможно, то есть для пересылки мультимедийных данных используется сервер.
Этот механизм пробивки отверстий называется ICE (установление интерактивного соединения), сервер, который помогает пробивать отверстия, называется службой TURN, а сервер, пересылающий мультимедийные данные, называется службой STUN. Google предоставляетturn server, под своей домашней сетью я могу получить только адрес локальной сети:
(2) Установите соединение P2P
Для этого автор написал демо, которое можно открытьэта ссылкаПопробуйте P2P-чат (вы можете использовать две вкладки или два компьютера), эффект будет таким, как показано ниже:
В дополнение к службе TURN, предоставляемой по умолчанию, также требуется служба веб-сокетов для обмена информацией между двумя взаимосвязанными сторонами. Итак, мне нужно написать службу веб-сокетов, я просто написал ее с помощью Node.js, и код был загружен на github:webrtc-server-client-demo, включая код на стороне браузера.
Процесс показан ниже:
Сначала откройте камеру, чтобы получить локальный медиапоток, добавьте его в объект RTCPeerConnection, а затем создайте локальное предложение, которое в основном описывает некоторую сетевую и мультимедийную информацию машины в формате SDP (протокол описания сеанса), как показано ниже:
v=0
o=- 4809135116782128887 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 6ReMVBFmnh4JhjzqjNO2AVBc26Ktg0R5jCFB
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
...Затем отправьте предложение другой стороне для подключения через службу веб-сокетов, и другая сторона создаст ответ после его получения. Когда одна из сторон получает информацию sdp другой стороны, она вызывает setRemoteDescription для ее записи. После получения информации о кандидате на пробивку отверстий, отправленной ледяным сервером по умолчанию, отправьте кандидата другой стороне (после setRemoteDesc) и позвольте другой стороне инициировать соединение.В случае успеха будет запущено событие onaddstream и событие. поток в событии будет нарисован на Вы можете получить видео другого участника на видео.
Вот и весь процесс подключения.
В случае успешного подключения мультимедийные данные будут переданы, и здесь WebRTC проделал большую работу.
(3) Передача WebRTC P2P
Общая архитектура WebRTC показана на рисунке ниже (видимаяОфициальный сайт):
Основная работа включает в себя:
(1) Кодек аудио и видео (VP8/VP9/AV1)
(2) Защита от потери пакетов и контроль перегрузки
(3) Подавление эха и шума
Здесь отражена большая роль WebRTC — для обеспечения надежной передачи, качественного кодека и устранения проблем с эхом автор однажды использовал для проекта пакет под названием h323 plus, который также является P2P-соединением. Теперь эта функция передачи мультимедиа в реальном времени встроена непосредственно в браузер, что, несомненно, значительно повышает эффективность разработки для разработчиков.
В реальном онлайн-проекте, поскольку скорость и стабильность соединения P2P не особенно оптимистичны, больше используется архитектура P2SP, а S означает сервер, как показано на следующем рисунке:
С одной стороны, это может повысить стабильность, а с другой — решить проблему видеочата «один ко многим» и «многие ко многим». Поскольку WebRTC больше подходит для один-к-одному, в сценарии «один-ко-многим» передача потока пользователя нескольким пользователям может привести к проблемам с производительностью и пропускной способностью загрузки.
Вы можете создать совместимое решение и переключиться на P2SP, когда P2P не работает.
Здесь нет обсуждения RTCDataChannel, и реальная сцена по-прежнему больше использует WebSocket.
5. Будущее WebRTC
WebRTC был выпущен W3C как стандарт 1.0, но он еще не стал стандартом RFC. WebRTC также постепенно развивается, в том числе:
(1) Chrome 69 использует новый алгоритм эхоподавления AEC3.
(2) Кодировка VP9 улучшила качество на 35%, а новую кодировку AV1 можно использовать в Chrome.
(3) Расширенный API для управления, включая RTCRtpSender.
Будущие RTC будут предоставлять больше возможностей:
(1) Возможность напрямую манипулировать данными медиапотока (теперь косвенно через CaptureStream)
(2) Возможность настройки параметров кодека RTCRtpEncodeingParameters (Chrome 70)
и т.п.
Я считаю, что будущее WebRTC очень светлое.
[Ренрен набирает среднего и старшего фронтенда]
1. Предыстория проекта: мы разрабатываем зарубежный продукт SAAS CRM (система управления клиентами) корпоративного уровня, и перед ним стоят очень большие технические задачи, такие как предоставление клиентам возможности совершать прямые интернет-звонки (прямые звонки на мобильные телефоны) на наш веб-сайт и отправлять электронные письма, автоматически обрабатывать бизнес в соответствии с пользовательскими сценариями и т. д.
2. История стека технологий: он также принимает более популярные фреймворки, такие как vue и vuex.Связь - WebRTC, а система распространения сообщений использует FCM Google и APN Apple. Сервисы развернуты на Amazon или Google Cloud. Обслуживайте клиентов по всему миру.
3. Кроме того, поскольку продукт является пользовательским продуктом корпоративного уровня, к нему предъявляются относительно высокие требования (такие как производительность, безопасность, многозадачность и т. д.). Поэтому технические требования к кандидатам относительно высокие.Если вас особенно волнует технология, то наши вакансии дают хорошую возможность талантам развиваться и расти.
Пожалуйста, отправьте свое резюме наshanshan.zhu@renren-inc.com