API Javascript расширения источника мультимедиа по сравнению с WebRTC. Некоторые вопросы

1. Это будет обрабатывать потерю пакетов и упорядочение, поэтому протокол, такой как RTP с RTCP, не используется. Это верно?

AJAX и Fetch - это просто API-интерфейсы JavaScript для выполнения HTTP-запросов. Web Socket - это просто API и протокол, расширенный из первоначального HTTP-запроса. HTTP использует TCP. TCP заботится о том, чтобы пакеты приходили и прибывали в правильном порядке. Итак, да, вам не нужно беспокоиться о потере пакетов и тому подобном, но не из-за MSE.

2. Но это приведет к задержке, поэтому его нельзя будет использовать для связи в реальном времени. Да?

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

Если ваши цели похожи на приложение телефонии, в котором потеря одного или двух пакетов в целом бессмысленна, тогда UDP более подходит. (При голосовой связи мы говорим достаточно медленно, чтобы, если пропадут несколько миллисекунд звука, мы все равно сможем расшифровать то, что мы говорим. Наш разговорный язык достаточно надежен, чтобы, если целые слова искажаются или молчат, мы можем понять суть того, что было сказано из контекста.) Также важно, чтобы для голосовой связи сохранялась немедленная непрерывность. Компромисс заключается в том, что точность в реальном времени лучше, чем точность в любой конкретный момент / пакет.

Однако, если вы что-то делаете, например, односторонний поток, вы можете выбрать протокол вместо TCP. В этом случае может быть важно работать в режиме реального времени, насколько это возможно, но более важно, чтобы аудио / видео не прерывалось. Рассмотрим Суперкубок или другое крупное спортивное мероприятие. Это прямое мероприятие, и важно, чтобы оно оставалось в реальном времени. Однако, если временная привязка для зрителя отстает от прямой трансляции всего на 3-5 секунд, для зрителя она по-прежнему остается «живой». Зритель был бы гораздо более зол, если бы видео выскочило из строя и они пропустили что-то происходящее в игре, а не если бы они отставали всего на несколько секунд. Поскольку это односторонняя потоковая передача и отсутствует петля обратной связи, компромисс между надежностью и качеством по сравнению с чрезвычайно низкой задержкой имеет смысл.

3. Для MSE нет требований к безопасности / шифрованию, как в WebRTC (DTLS / SRTP). Да?

MSE не знает и не заботится о том, как вы получаете свои данные.

4. Нельзя, например, смешивать удаленный источник звука из MSE с аудио mediaStreamTrack из RTCPeerConnection, поскольку они не имеют общего параметра, такого как CNAME (RTCP), или являются частью одного и того же медиапотока). Другими словами, мир MSE и WebRTC не может смешиваться, если синхронизация не важна. Верный?

Микс, где? Синхронизация, где? Независимо от того, что вы делаете, если у вас есть потоки, поступающие из разных мест ... или даже с разных устройств без синхронизации / генерации, они не синхронизированы. Однако, если вы можете определить точку отсчета, в которой вы считаете вещи «синхронизированными», тогда все будет хорошо. Например, у вас могут быть независимые потоки, идущие на сервер, и сервер использует свои текущие временные метки, чтобы настроить все и распространять вместе через WebRTC.

Как вы это делаете или что вы делаете, зависит от специфики вашего приложения.