Mientras los primeros adoptantes prueban nuestras nuevas videoconferencias (¡hasta 100 personas!) En sus proyectos, seguimos hablando de cosas interesantes del mundo de la transmisión de voz y video con un navegador. También hablaremos de videoconferencia, pero más tarde, cuando se acumule una masa crítica de usuarios y se recopilen estadísticas interesantes. Y ahora he traducido y adaptado para nosotros la historia del Dr. Alex sobre el lugar de los diferentes protocolos al transmitir video con baja latencia. La historia es esencialmente una respuesta a otro artículo, y el autor, junto con la historia, señala los errores e inexactitudes que cometieron sus colegas en el taller.
Datos de red: alarma por separado, video por separado
En los sistemas modernos, si ve video en un navegador, entonces la transmisión de video y la alarma probablemente serán procesadas por diferentes servidores. Si todo está claro con el video, entonces el "servidor de alarma" proporciona dos cosas: "descubrimiento" y "apretón de manos". El primero, "descubrimiento", es la elección del método de transferencia de datos: direcciones IP, un servidor intermedio (si es necesario). “Apretón de manos”: sobre la negociación entre los participantes en la transmisión de video y sonido: códecs, resolución, velocidad de cuadros, calidad. Curiosamente, en Flash antiguo, la señalización y la transmisión de medios no estaban separadas como en VoxIP o WebRTC y se proporcionaban mediante un protocolo: RTMP.
La diferencia entre el protocolo de señalización y el transporte de señalización.
El protocolo de señalización define el idioma con el que el navegador y otros participantes en la transmisión de video acordarán el descubrimiento y el apretón de manos. Puede ser SIP para descubrimiento en VoIP o WebRTC, y es con oferta / respuesta para apretón de manos. Hace mucho tiempo, Flash usaba
RTMP / AMF . Y si lo desea, para WebRTC, puede usar no SIP, sino JSEP inusual.
El protocolo de transporte de señalización desde la misma pila, pero inferior: así es como se transmitirán físicamente los paquetes del protocolo de señalización. Tradicionalmente, para Flash + SIP, se usaba TCP o UDP, pero ahora en el paquete WebRTC + SIP, se encuentran cada vez más WebSockets. El protocolo de transporte WebSockets ocupa el nicho TCP en los navegadores donde no se pueden usar sockets TCP y UDP "puros".
Una pila de señalización completa ahora se describe popularmente con frases como "SIP en la parte superior de los sockets web", "JSEP en la parte superior de los sockets web", obsoleto "SIP en la parte superior de TCP / UDP" o la antigua "parte de RTMP".
Anglicismo del programador: códec de medios
La mayoría de los protocolos de transmisión de video están vinculados a uno o más códecs. El video recibido de la cámara se procesa cuadro por cuadro. Y los problemas de red, como el ancho de banda reducido, la pérdida de paquetes o el retraso entre ellos, se resuelven mediante la configuración del códec para cada trama. Para conocer los problemas de la red a tiempo, utilizamos mecanismos de protocolo de transporte (RTP / RTCP) y mecanismos de estimación de ancho de banda (REMB, Transport-CC, TIMBR). Uno de los problemas fundamentales con el video Flash fue que RTMP tampoco podía hacerlo, por lo que el video simplemente dejó de reproducirse cuando el ancho de banda del canal se redujo.
Otro anglicismo: protocolo de transmisión de medios
Determina cómo dividir la transmisión de video en pequeños paquetes que se envían a través de la red mediante el protocolo de transporte. Por lo general, el protocolo de transmisión aún proporciona mecanismos para tratar problemas de red: pérdida de paquetes y retraso. Jitter buffer, retransmisión (RTC), redundancia (RED) y corrección de errores de reenvío (FEC).
Protocolo de transferencia de medios
Después de que el video recibido de la cámara se divide en pequeños paquetes, deben transmitirse a través de la red. El protocolo de transporte utilizado para esto es similar al de señalización, pero dado que la "carga útil" es completamente diferente, algunos protocolos son mejores que otros. Por ejemplo, TCP proporciona accesibilidad de paquetes, pero no agrega valor a la pila, porque mecanismos similares (RTX / RED / FEC) ya están en el protocolo de transmisión. Pero los retrasos en el reenvío a TCP es una falla clara que UDP no tiene. Pero existe la práctica de bloquear UDP como un "protocolo para torrentes".
La elección del protocolo y los puertos de red se decidió previamente mediante "codificación", pero ahora usamos protocolos como ICE en WebRTC, que nos permite acordar los puertos y el transporte en cada conexión específica. En el futuro cercano, es posible utilizar el protocolo QUIC (compatible con versiones anteriores de UDP), que es discutido activamente por el IETF y tiene ventajas sobre la velocidad y la confiabilidad sobre TCP y UDP. Finalmente, podemos mencionar protocolos de transmisión de medios como MPEG-DASH y HLS, que utilizan HTTP como transporte y se beneficiarán de la introducción de HTTP / 2.0.
Seguridad de transmisión de medios
Algunos motores protegen los datos durante la transmisión a través de la red: ya sea el flujo de medios en sí mismo o los paquetes de la capa de transporte. El proceso incluye la transferencia de claves de cifrado, para lo cual se utilizan protocolos separados: SDES en VoIP y DTLS en WebRTC. Este último tiene una ventaja, ya que además de los datos, también protege la transmisión de claves de cifrado.
Lo que me molesta de todo esto
Algunos desarrolladores, como los autores de
este artículo , colocan los protocolos puramente WebSocket y QUIC al mismo nivel que WebRTC, Flash o HLS. Para mí, esa agrupación parece extraña, porque los últimos tres protocolos son una historia sobre la transmisión de medios. La codificación y la paquetización ocurren antes de usar WebSocket o QUIC. La implementación de WebRTC de referencia de Google (libwebrtc / chrome) y el ORTC de Microsoft usan QUIC como protocolo de transporte.
Igualmente sorprendente es la falta de mención de HTTP / 2.0 como una optimización para protocolos basados en HTTP como HLS y MPEG-DASH. Y el CMAF mencionado no es más que un formato de archivo para HLS y MPEG-DASH, pero no es su reemplazo en absoluto.
Finalmente, SRT es solo un protocolo de transporte. Él, por supuesto, agrega una cantidad de chips en comparación con aquellos basados en archivos HLS y MPEG-DASH, pero todos estos chips ya están en un nivel de pila diferente y se implementan en RTMP o WebRTC. SRT también comparte la codificación del flujo de medios y las estadísticas, lo que no permite que el códec mantenga esta información lo más cerca posible entre sí. Tal decisión puede afectar negativamente la capacidad de adaptar el video transferido al ancho de banda de red cambiante.
Los protocolos basados en archivos, como HLS, codifican múltiples flujos y seleccionan los necesarios para adaptarse al ancho del canal. WebRTC le permite adaptar la codificación de cada cuadro en tiempo real: es mucho más rápido que seleccionar otro flujo en HLS, lo que requiere contar hasta 10 segundos de datos ya enviados.