- Это будет обрабатывать потерю пакетов и последовательность, поэтому такой протокол, как RTP с RTCP, не используется. Это правильно?
AJAX и Fetch - это просто JavaScript API для выполнения HTTP-запросов. Web Socket - это просто API и протокол, расширенный с исходного HTTP-запроса. HTTP использует TCP. TCP заботится о том, чтобы пакеты приходили и приходили в порядке. Так что, да, вам не нужно беспокоиться о потере пакетов и тому подобном, но не из-за MSE.
Но это приведет к задержке, поэтому ее нельзя будет использовать для связи в реальном времени. Да?
Это полностью зависит от ваших целей. Это миф, что TCP не быстрый или что TCP увеличивает общую задержку для каждого пакета. То, что является верным, заключается в том, что первоначальное трехстороннее рукопожатие требует нескольких раундов. Также верно, что если пакет действительно отбрасывается, приложение видит внезапное резкое увеличение задержки до тех пор, пока пакет снова не будет запрошен и снова отправлен.
Если ваши цели являются чем-то вроде приложения телефонии, в котором потеря Пакет или два вообще не имеет смысла, тогда UDP более уместен. (В голосовой связи мы говорим достаточно медленно, поэтому, если пропущено несколько миллисекунд звука go, мы все равно можем расшифровать сказанное. Наш разговорный язык достаточно надежен, поэтому, если целые слова искажаются или молчат, мы можем выяснить, суть того, что говорилось из контекста.) Также важно сохранить непосредственную преемственность для голосовой связи. Компромисс в том, что в реальном времени лучше точности, чем точности в любой конкретный момент / пакет.
Однако, если вы что-то делаете, скажем, односторонний поток, вы можете выбрать протокол по TCP. В этом случае может быть важно быть в режиме реального времени, насколько это возможно, но более важно, чтобы аудио / видео не глючили. Рассмотрим Суперкубок или другое крупное спортивное событие. Это живое событие, и важно, чтобы оно оставалось в реальном времени. Тем не менее, если отсчет времени для зрителя задерживается на 3-5 секунд, он все еще достаточно "жив" для зрителя. Зритель был бы гораздо более злым, если бы видео вылетело, и они пропустили что-то происходящее в игре, а не если бы они отставали всего на несколько секунд. Так как это потоковая передача в одном направлении и отсутствует обратная связь по связи l oop, имеет смысл найти компромисс между надежностью и качеством при чрезвычайно низкой задержке.
Для MSE нет требований безопасности / шифрования, как в WebRT C (DTLS / SRTP). Да?
MSE не знает и не заботится о том, как вы получаете ваши данные.
Нельзя, например, смешивать удаленный источник звука из MSE с аудиосигналом mediaStreamTrack из RTCPeerConnection, поскольку у них нет общего параметра, такого как CNAME (RTCP), или они являются частью одного и того же медиапотока). Другими словами, мир MSE и WebRT C не может смешиваться, если синхронизация не важна. Правильно?
Микс, где? Синхронизация, где? Независимо от того, что вы делаете, если у вас есть потоки, приходящие из разных мест ... или даже с разных устройств без синхронизации / синхронизации, они не синхронизированы c. Однако, если вы можете определить точку отсчета, в которой вы считаете вещи «синхронизированными», то все это хорошо. Например, вы можете иметь независимые потоки, поступающие на сервер, и сервер использует свои текущие временные метки, чтобы все настроить и распределить вместе через WebRT C.
Как вы это делаете или что вы делаете, зависит на специфику вашей заявки.