Haz una videollamada contigo mismo
WebRTC, que lleva el nombre de Web Real-Time Communication (inglés: Web Real-Time Communication), es una API que admite conversaciones de voz o vídeo en tiempo real en un navegador web. Fue de código abierto el 1 de junio de 2011 y se incorporó a las recomendaciones W3C del World Wide Web Consortium con el apoyo de Google, Mozilla y Opera.
En primer lugar, es a la vez una API y un protocolo.
En segundo lugar, es la API del navegador para llamadas de audio y vídeo, que en realidad es lo que le gusta a Screen ****.
Finalmente, ahora es compatible con W3C y los principales proveedores de navegadores lo han hecho compatible.
Sin embargo, si queremos utilizar bien webrtc, primero debemos comprender websocket y estar familiarizados con websocket, como chat social, juegos multijugador, edición colaborativa, videoconferencias y aplicaciones basadas en ubicación. (Mapas) y otros escenarios de aplicaciones con altos requisitos en tiempo real. Nuestro WeChat, QQ y algunos programas de transmisión en vivo más utilizados también se basan en websocket para implementar el reenvío de mensajes y señales. Quizás hayas dudado sobre la señalización aquí, así que continúa leyendo.
webrtc es una tecnología P2P. Lo que es P2P es en realidad de extremo a extremo, lo que significa que sus transmisiones de audio y video se transmiten directamente de un extremo al otro sin ser retransmitidas por el servidor.
Sin pasar por el servidor, es decir, si el servidor falla repentinamente durante el proceso, ¿puede continuar la llamada?
¡Sí! Pero antes de enviar la transmisión de audio/video, debe establecer una conexión P2P, y antes de que se establezca esa conexión, debe reenviar la señalización desde el servidor que identifica ambos extremos de la llamada.
Si quieres realizar una llamada mediante webrtc, debes reenviar la señalización y establecer una conexión. La mejor manera de establecer una conexión es utilizar websockets para el reenvío de señales. Como todos sabemos, websocket es un canal y todos los extremos del canal pueden recibir un flujo de mensajes desde cualquier extremo, incluida la persona que envió el mensaje.
¿Por qué es posible obtener transmisiones de vídeo y audio desde el otro extremo sin pasar por el servidor? Debido a que se ha establecido un canal P2P, este P2P ya pasó al transmitir señales. ¿Qué tipo de servidor se necesita para transmitir transmisiones de video y audio? En este momento, algunos amigos deben haber expresado dudas. ¿No pueden pasar las transmisiones de audio y video a través del servidor? Sí, les mentí a todos. Necesitamos pasar por el servidor, pero solo debe ser reenviado por el servidor en la línea. Si reenviamos las transmisiones de audio y video de webrtc en dos o más extremos de la red de área local. Lo hacemos. No es necesario un servidor de tránsito, pero puede que sea necesario o no en la línea. Esto implica el concepto de agujero.
Por lo general, es posible que escuchemos vocabulario relativamente interesante, como perforación de agujeros, penetración de intranet, cruce de NAT y varias cosas de alto nivel, pero en realidad son bastante fáciles de entender. Todos sabemos que dos hosts en dos redes diferentes no pueden comunicarse directamente, sino que deben pasar por la red pública o sus respectivas puertas de enlace. Hole-in-a-hole, penetración de intranet y cruce de NAT en realidad significan lo mismo: usar UDP para interconectar dos hosts en diferentes redes sin tener que ir a la red pública para conectarse directamente. Los estudiantes que hayan jugado con cáscaras de maní definitivamente comprenderán el concepto de penetración de intranet.
Durante el desarrollo local, los dos hosts están en la misma LAN y pueden comunicarse directamente sin penetración en la intranet.
Para el desarrollo en línea, si la vulnerabilidad STUN se puede explotar con éxito, no hay necesidad de un servidor de tránsito. Pero existe una alta probabilidad de que un agujero falle. ¿Por qué, al no existir una red pública, no puede reportar beneficios a los operadores, pero sí costos de comunicación, que deben ser limitados? La probabilidad de éxito en el extranjero es del 70%, pero en China es inferior al 50%.
Por lo tanto, para evitar perforaciones fallidas, utilizamos servidores de retransmisión TURN para reenviar datos de transmisión para obtener la garantía final.
Además, existe un método de conexión inversa que también puede ayudarnos a establecer P2P. Su principio es que una parte debe ir a la red pública, lo que también tiene limitaciones.
El servidor de retransmisión coturn está compuesto por STUN y TURN. STUN nos ayuda a cavar agujeros y TURN nos ayuda a reenviar datos de transmisión.
##Proceso de conexión
Todas las siguientes API son las últimas versiones a partir del 2021.12.06
##Tengo un problema
Veamos el meollo de la cuestión de sdp en relación con sus propios medios y códecs
Una oferta, una respuesta, conocemos los medios y códecs de cada uno, por lo que ambos conocemos la situación del otro.
Una oferta, una respuesta, conocemos la información multimedia y los códecs de cada uno para que podamos negociar qué debo usar para decodificar y renderizar sus transmisiones de video y audio.
Este proceso es un poco tedioso, puedes leer este artículo sobre el protocolo WebRTC TURN y las prácticas de rotación del servidor.
Comprender la captura de audio/vídeo y la captura de escritorio de webrtc
Comprender todo el proceso de establecimiento de enlaces de websocket y webrtc
Implementar transmisión de texto 1V1, videollamadas; y llamadas de voz, disfrute de la pantalla****;
Capture capturas de pantalla, grabaciones, grabaciones de pantalla y capturas de pantalla, grabaciones, disfrute de la pantalla**** durante videollamadas, llamadas de voz, disfrute de la pantalla****.
Permite capturas de pantalla, grabaciones y reproducción y descarga en línea de capturas de pantalla, grabaciones y disfrute de la pantalla durante videollamadas, llamadas de voz y disfrute de la pantalla.
A continuación, dibujaremos un básico; Diagrama de flujo del proceso de creación de audio/vídeo.
Diagrama de flujo básico
Para toda esta señalización usamos websocket para el reenvío, aquí te preguntarás, ¿por qué no usar http?
Primero, la demostración que vamos a implementar inicialmente incluye la capacidad de enviar un mensaje de texto normal, que es lo que hacen los websockets. (Las encuestas cortas y las encuestas largas son demasiado antiguas y tienen un rendimiento deficiente).
En segundo lugar, la primera demostración que queremos implementar contiene la capacidad de enviar mensajes de texto normales, que es lo que websocket puede hacer.
En segundo lugar, el primer punto se puede ignorar: la solicitud http regresará de la manera original, A regresa al servidor, pero nunca B. Entonces, en el diagrama de flujo anterior, todas las pequeñas flechas son en realidad bidireccionales.
En este punto, podemos controlar la dirección de los mensajes push en el servicio del nodo o en el lado del cliente, y yo elegí controlarlo en el lado AB.
En segundo lugar, si estamos desarrollando localmente, si utilizamos una computadora y dos navegadores, los mensajes de texto de Websocket no son un problema. Pero las llamadas de audio y video no funcionarán porque existen conflictos entre el canal de transmisión y el equipo de audio y video (micrófono, parlantes, etc.). Por tanto, podemos solucionar este problema utilizando dos ordenadores en la misma LAN. Además, debido a las restricciones de seguridad de webrtc, debe usar https (en línea y local) y el nombre de dominio. Podemos resolver este problema configurando https y el nombre de dominio en línea, configurando el navegador para que ignore el https local y configurando la asignación de archivos del host. .
A continuación, usaremos vue y nodejs, que es la forma más rápida y sencilla de implementar la demostración.
Sin más, ¡comencemos!
Mostrar parte del código
Aquí, utilizo el paquete de software de terceros socket.io para inicializar mensajes y reenviar señales rápidamente. (Le recomendamos que utilice vue-socket.io). Puede enviar y recibir mensajes y señales en componentes.
Coloque el websocket de socket-io en vuex para establecer una conexión y recibir mensajes y señales.
Del mismo modo, estamos utilizando el paquete socket-io en el servicio de nodo.
El código para disfrutar de vídeo, audio y pantalla es similar. Por ejemplo, captura de vídeo.
Al utilizar getUserMedia, podemos capturar transmisiones de audio/vídeo de doble pista y pasar un parámetro: restricciones, que se pueden configurar (para controlar si se captura audio o vídeo).
Mediante Al asignar el flujo de medios dinámicos capturado a la etiqueta de video, podemos mostrar nuestra propia pantalla en la página web.
Del mismo modo, para la captura de audio, simplemente configure la restricción del parámetro de audio en falso.
Para realizar capturas de pantalla de computadora, simplemente reemplace la API getUserMedia con getDisplayMedia.
En este punto, el iniciador del vídeo necesita enviar una señal de aplicación al receptor después de capturar la transmisión. La señal pregunta al destinatario si desea recibir una videollamada.
Si se responde, el extremo receptor recopilará sus propios flujos de doble pista de audio y video, inicializará la conexión de igual a igual, colocará el flujo en la tubería, escuchará el flujo candidato de ICE y, si recopilado, enviarlo a la otra parte y responder con su señal de consentimiento al autor del video.
Si se rechaza la adquisición, el extremo receptor responderá con una señal de rechazo al emisor del vídeo.
En este momento, el extremo receptor recibe la señal de rechazo y cierra la colección de transmisiones de video y audio.
Cuando el extremo receptor recibe una señal de captación en este momento, inicializa la conexión entre pares, coloca su propio flujo de medios en la tubería, escucha los flujos candidatos de ICE y envía los flujos candidatos cuando se recopilan. entre sí. Crea una oferta (con sdp), coloca la oferta localmente y la envía al destinatario del video.
El receptor de video recibe la oferta, la coloca en el control remoto, crea una respuesta, coloca la respuesta localmente y la envía al autor del video.
El autor del vídeo recibe la respuesta y la coloca en el mando a distancia.
En este momento, tanto el receptor como el remitente están escuchando el contenido del candidato de ICE. Si se recopilan, se enviarán a la otra parte. Una vez que lo escuchan, el flujo de medios dinámicos de la otra parte se asigna a B y se reproduce.
Captura de pantalla: podemos usar el método getContext("2d").drawImage para tomar una captura de pantalla a nivel de red usando el lienzo.
Grabación de audio/vídeo/pantalla: utilice MediaRecorder para guardar nuestra transmisión multimedia o la transmisión multimedia de la otra parte en una matriz.
Simplemente asigne la transmisión de medios estáticos guardados a la etiqueta de video.
Del mismo modo, podemos descargar transmisiones de audio y video.
Hay dos requisitos importantes para implementar webrtc: nombre de dominio y https, que debemos configurar.
Además de https+nombre de dominio, nuestro servicio de nodo también necesita el protocolo wss más seguro para websockets. Necesitamos configurar nuestros websockets con wss.
Como mencionamos antes, la razón por la cual el desarrollo local es exitoso y efectivo es porque la intranet se comunica directamente en lugar de hacerlo con la red pública, lo que significa que no se logra la penetración de la intranet.
Si queremos lograr este objetivo online, debemos configurar un servidor de retransmisión coturn. Para el kernel centos, consulte este artículo; para el kernel ubuntu, consulte este artículo.
Después del desarrollo y el lanzamiento, descubrimos los siguientes problemas.
Retrasos causados por el entorno, el equipo, desbordamiento de señal, ruido causado por incompatibilidad de algoritmos, eco causado por la acústica y el cableado, congestión de la red y velocidades de transmisión de paquetes inestables.
Podemos acceder a algunos algoritmos y mejorar la calidad de los dispositivos hardware para reducir el eco y la latencia del ruido.
Para el ruido, puede configurar noiseSuppression:true al capturar audio para reducir parte del ruido ambiental y del dispositivo.
Para eco, configure echoCancellation: true al capturar audio para cancelar el eco.
El resto depende del algoritmo, dispositivo y red.
Esto concluye mi exploración en esta área. Puede continuar estudiando cómo el transporte WebRTC garantiza la calidad del servicio de audio y video, y cómo las aplicaciones maduras abordan estos tres desafíos.
Podrás utilizar varios efectos en tus videollamadas. Bellezas, stickers y más.
Sin embargo, en el campo de la red webrtc, el campo de los efectos especiales de vídeo está muy oculto. La razón radica en los problemas de rendimiento de js.
Un enfoque más simple sería usar un lienzo para agregar un filtro a nuestra imagen de video, pero esencialmente no cambia el flujo de medios. La transmisión al extremo remoto aún no tiene ningún efecto. Por supuesto, podemos controlar los efectos especiales de video remotos a través de websocket, pero como la transmisión no ha cambiado, si el otro extremo descarga la transmisión, aún no habrá efectos especiales durante la reproducción.
Otra solución es la siguiente, no entraré en detalles aquí, puedes considerar cómo implementarla (aquí hay algunos efectos especiales y pegatinas simples).
Necesitamos crear n-1 conexiones PeerConnection porque chatearemos por video con n-1 personas cada una. Pero la pregunta es quién iniciará la propuesta. Podríamos hacer que el nuevo miembro envíe una oferta a n-1 miembros más, o podríamos hacer que n-1 miembros envíen una oferta al nuevo miembro, y podríamos hacerlo de forma iterativa en PeerConnection y la oferta, por supuesto, depende. de si su servidor puede satisfacer las necesidades de muchas personas.
Aquí, sin saberlo, utilizamos un conocido esquema de comunicación multiterminal: Mesh, que es un esquema de comunicación que se comunica en pares para formar una estructura de malla. Además de las soluciones de comunicación como Mesh, también existe la solución MCU. La solución MCU mezcla principalmente las transmisiones de audio y video de todos los terminales en la misma sala y luego las envía a cada terminal, por lo que la presión sobre el servidor es realmente muy alta. enorme. Además, existe el esquema de comunicación SFU, donde el servidor de retransmisión recibe transmisiones de audio y vídeo desde un terminal y luego las reenvía a otros terminales.
Después de una serie de procesos como comprensión, pensamiento, construcción, desarrollo e implementación, tenemos algunos conocimientos y comprensión preliminares de webrtc. Para este tipo de investigación y exploración, debemos seguir profundizando. Esto es para satisfacer nuestra curiosidad y sed de conocimiento, mejorar nuestras habilidades en esta área y enriquecer nuestro cuerpo general de conocimientos.
Finalmente, todo el contenido anterior proviene de datos, experimentos personales y resúmenes personales. Si hay algún error en el artículo, corríjame.