Alice es una desarrolladora de pila completa con experiencia, que es capaz de escribir un marco de proyecto SAAS en su marco favorito usando php en una semana. En cuanto a la interfaz, ella prefiere Vue.js.
Un cliente se comunica con usted a través de Telegram y le pide que desarrolle un sitio web que será el lugar de reunión para que el empleador y el empleado realicen una entrevista en persona. En persona significa cara a cara, un contacto de video directo en tiempo real con video y voz. “¿Por qué no usar Skype?” Algunos pueden preguntar. Dio la casualidad de que los proyectos serios, y cada startup sin duda se considera un proyecto serio, están tratando de ofrecer un servicio de comunicaciones internas por una variedad de razones, que incluyen:
1) No desean prestar a sus usuarios a comunicadores de terceros (Skype, Hangouts, etc.) y desean retenerlos en el servicio.
2) El deseo de monitorear sus comunicaciones, como el historial de llamadas y los resultados de la entrevista.
3) Grabar llamadas (naturalmente, notificando a ambas partes sobre la grabación).
4) No quieren depender de políticas y actualizaciones de servicios de terceros. Todos conocen esta historia: Skype se actualizó y todo se vuelve humo ...
Parece una tarea fácil. WebRTC aparece cuando buscas en Google sobre el tema, y parece que puedes organizar una conexión punto a punto entre dos navegadores, pero todavía hay algunas preguntas:
1) ¿Dónde obtener los servidores STUN / TURN?
2) ¿Podemos prescindir de ellos?
3) ¿Cómo grabar una llamada WebRTC punto a punto?
4) ¿Qué sucederá si necesitamos agregar un tercero a la llamada, por ejemplo, un gerente de recursos humanos u otro especialista del empleador?
Resulta que WebRTC y peer-to-peer por sí solos no son suficientes, y no está claro qué hacer con todo esto para iniciar las funciones de video requeridas del servicio.
Contenido del artículo
Servidor y API
Para cerrar estas brechas, se utilizan soluciones de servidor y arquitectura de igual a igual. Web Call Server 5.2 (en adelante, WCS) es una de las soluciones de servidor; es una plataforma de desarrollo que le permite agregar tales funciones de video al proyecto y no preocuparse por STUN / TURN y la estabilidad de la conexión peer-to-peer.
En el nivel más alto, WCS es una parte del servidor JavaScript API +. La API se usa para el desarrollo usando JavaScript normal en el lado del navegador, y el servidor procesa el tráfico de video, actuando como un Proxy con estado para el tráfico de medios.
Además de la API de JavaScript, también existe el SDK de Android y el SDK de iOS, que son necesarios para desarrollar aplicaciones móviles nativas para iOS y Android, respectivamente.
Por ejemplo, publicar una transmisión en el servidor (transmisión desde una cámara web hacia el servidor) tiene este aspecto:
SDK web
session.createStream({name:”stream123”}).publish();
SDK de Android
publishStream = session.createStream(streamOptions) publishStream.publish();
SDK de iOS
FPWCSApi2Stream *stream = [session createStream:options error:&error]; if(![stream publish:&error]) { //published without errors }
Como resultado, podemos implementar no solo una aplicación web, sino también actualizaciones completas para Google Play y App Store con soporte de transmisión de video. Si agregamos SDK móvil a la imagen de nivel superior, obtendremos esto:
Transmisiones entrantes
El servidor de transmisión, que es WCS, comienza con las transmisiones entrantes. Para distribuir algo, necesitamos tenerlo. Para distribuir transmisiones de video a los espectadores, es necesario que estas transmisiones ingresen al servidor, atraviesen su RAM y salgan a través de la tarjeta de red. Por lo tanto, la primera pregunta que debemos hacer al familiarizarnos con el servidor de medios es qué protocolos y formatos utiliza este último para aceptar transmisiones. En el caso de WCS, estas son las siguientes tecnologías: WebRTC, RTMP, RTSP, VOD, SIP / RTP.
Cada uno de los protocolos puede ser utilizado por diversos clientes. Por ejemplo, no solo la transmisión del navegador puede ingresar a través de WebRTC, sino también desde otro servidor. En la tabla a continuación se encuentran las posibles fuentes de tráfico entrante.
Si revisamos las fuentes de tráfico entrante, podemos agregar lo siguiente:
WebRTC entrante
Web SDK permite no solo capturar la cámara y el micrófono, sino también usar las capacidades de la API del navegador para acceder a la pantalla mediante el uso compartido de pantalla. Además, podemos capturar un elemento Canvas arbitrario, y todo lo que se dibuja para su posterior transmisión es la transmisión de Canvas:
Debido a los detalles móviles, el SDK de Android y el SDK de iOS tienen la capacidad de alternar entre las cámaras frontal y posterior del dispositivo sobre la marcha. Esto nos permite cambiar la fuente durante la transmisión sin tener que pausar la transmisión.
El flujo entrante de WebRTC también se puede obtener de otro servidor WCS utilizando los métodos push, pull y CDN, que se analizarán más adelante.
Rtmp entrante
El protocolo RTMP se usa ampliamente en los OBS favoritos de los streamers, así como en otros codificadores: Wirecast, Adobe Media Encoder, ffmpeg, etc. Usando uno de estos codificadores, podemos capturar la transmisión y enviarla al servidor.
También podemos recoger una transmisión RTMP de otro servidor de medios o servidor WCS utilizando los métodos push y pull. En el caso de push, el iniciador es el servidor remoto. En el caso de extracción, recurrimos al servidor local para extraer la transmisión del remoto.
Rtsp entrante
Las fuentes de tráfico RTSP suelen ser cámaras IP o servidores de medios de terceros que admiten el protocolo RTSP. A pesar de que al iniciar una conexión RTSP, el iniciador es WCS, el tráfico de audio y video en la dirección de la cámara IP se mueve hacia el servidor WCS. Por lo tanto, consideramos que la transmisión de la cámara es entrante.
Vod entrante
A primera vista, puede parecer que la función VOD (Video On Demand) está asociada exclusivamente con transmisiones salientes y con la reproducción de archivos por parte de los navegadores. Pero en nuestro caso, esto no es del todo cierto. WCS difunde un archivo mp4 del sistema de archivos a localhost; Como resultado, se crea una transmisión entrante, como si viniera de una fuente de terceros. Además, si restringimos un visor a un archivo mp4, obtenemos el VOD clásico, donde el espectador obtiene la transmisión y la reproduce desde el principio. Si no restringimos un visor a un archivo mp4, obtenemos VOD LIVE, una variación de VOD, en la que los espectadores pueden reproducir el mismo archivo como una transmisión, conectándose al punto de reproducción en el que se encuentran actualmente todos los demás (previo modo de transmisión de televisión grabada).
SIP / RTP entrante
Para recibir tráfico RTP entrante dentro de una sesión SIP, debemos configurar una llamada con una puerta de enlace SIP de terceros. Si la conexión se establece con éxito, el tráfico de audio y / o video irá desde la puerta de enlace SIP, que se envolverá en la transmisión entrante en el lado WCS.
Transmisiones salientes
Después de recibir la transmisión al servidor, podemos replicar la transmisión recibida a uno o varios espectadores a pedido. El espectador solicita una transmisión del reproductor u otro dispositivo. Dichas transmisiones se denominan transmisiones salientes o "transmisoras del espectador", ya que las sesiones de dichas transmisiones siempre se inician del lado del espectador / jugador. El conjunto de tecnologías de reproducción incluye los siguientes protocolos / formatos: WebRTC, RTMP, RTSP, MSE y HLS.
WebRTC saliente
En este caso, Web SDK, Android SDK y iOS SDK actúan como API para el reproductor. Un ejemplo de reproducción de transmisión WebRTC se ve así:
SDK web
session.createStream({name:”stream123”}).play();
SDK de Android
playStream = session.createStream(streamOptions); playStream.play();
SDK de iOS
FPWCSApi2Stream *stream = [session createStream:options error:nil]; if(![stream play:&error]) { //published without errors }
Esto es muy similar a la API de publicación, con la única diferencia de que en lugar de stream.publish (), se llama a stream.play () para jugar.
Un servidor de WCS de terceros puede ser el jugador, que recibirá instrucciones de recoger la transmisión a través de WebRTC desde otro servidor utilizando el método pull o recoger la transmisión dentro de CDN.
Rtmp saliente
Aquí habrá principalmente reproductores RTMP, tanto el conocido Flash Player como las aplicaciones de escritorio y móviles que usan el protocolo RTMP, reciben y reproducen una transmisión RTMP. A pesar de que Flash abandonó el navegador, mantuvo el protocolo RTMP, que se usa ampliamente para transmisiones de video, y la falta de soporte nativo en los navegadores no impide el uso de este protocolo bastante exitoso en otras aplicaciones cliente. Se sabe que RTMP se usa ampliamente en reproductores de realidad virtual para aplicaciones móviles en Android e iOS.
Rtsp saliente
El servidor WCS puede actuar como un servidor RTSP y distribuir la transmisión recibida a través de RTSP como una cámara IP normal. En este caso, el reproductor debe establecer una conexión RTSP con el servidor y recoger la transmisión para reproducirla, como si fuera una cámara IP.
MSE saliente
En este caso, el reproductor solicita una transmisión del servidor utilizando el protocolo Websocket. El servidor distribuye datos de audio y video a través de tomas web. Los datos llegan al navegador y se convierten en fragmentos que el navegador puede reproducir gracias a la extensión MSE nativa admitida de fábrica. El reproductor finalmente funciona sobre la base del elemento de video HTML5.
Hls salientes
Aquí, WCS actúa como un servidor HLS o servidor web que admite HLS (HTTP Live Streaming). Una vez que la transmisión entrante aparece en el servidor, se genera una lista de reproducción .m3u8 HLS, que se entrega al jugador en respuesta a una solicitud HTTP. La lista de reproducción describe qué segmentos de video debe descargar y mostrar el reproductor. El reproductor descarga segmentos de video y lo reproduce en la página del navegador, en el dispositivo móvil, en el escritorio, en el decodificador de Apple TV y en cualquier lugar donde se solicite soporte HLS.
Entrante y saliente
En total, tenemos 5 tipos de transmisión entrantes y salientes. Se enumeran en la tabla:
Es decir, podemos subir las transmisiones al servidor, conectarnos a ellas y reproducirlas con reproductores adecuados. Para reproducir una transmisión WebRTC, use el SDK web. Para reproducir una transmisión WebRTC como HLS, use un reproductor HLS, etc. Una transmisión puede ser reproducida por muchos espectadores. Las transmisiones de uno a muchos funcionan.
Ahora, describamos qué acciones se pueden realizar con las transmisiones.
Manipulación de flujo entrante
Las transmisiones salientes con espectadores no se manipulan fácilmente. De hecho, si el espectador ha establecido una sesión con el servidor y ya está recibiendo algún tipo de transmisión, no hay forma de hacer cambios sin interrumpir la sesión. Por esta razón, todas las manipulaciones y cambios tienen lugar en las transmisiones entrantes, en el punto donde aún no se ha producido su replicación. La transmisión que ha sufrido cambios se distribuye a todos los espectadores conectados.
Las operaciones de transmisión incluyen:
- grabación
- tomando una instantánea
- Agregar una secuencia al mezclador
- transcodificación de flujo
- agregar una marca de agua
- Agregar un filtro FPS
- rotación de imagen en 90, 180, 270 grados
Grabación de flujo entrante
Quizás la función más comprensible y más frecuente. De hecho, en muchos casos, las transmisiones requieren grabación: seminarios web, lecciones de inglés, consultas, etc.
La grabación se puede iniciar con el SDK web o la API REST con una solicitud especial:
/stream/startRecording {}
El resultado se guarda en el sistema de archivos como un archivo mp4.
Tomar una instantánea
Una tarea igualmente común es tomar fotografías de la transmisión actual para mostrar iconos en el sitio. Por ejemplo, tenemos 50 transmisiones en un sistema de videovigilancia, cada una de las cuales tiene una cámara IP como fuente. Mostrar los 50 hilos en una página no solo es problemático para los recursos del navegador, sino que también no tiene sentido. En el caso de 30 FPS, el FPS total de la imagen cambiante será de 1500, y el ojo humano simplemente no aceptará dicha frecuencia de visualización. Como solución, podemos configurar el corte automático o la toma de instantáneas a pedido; en este caso, las imágenes con una frecuencia arbitraria se pueden mostrar en el sitio, por ejemplo, 1 fotograma en 10 segundos. Las instantáneas se pueden eliminar del SDK a través de la API REST o se pueden cortar automáticamente.
El servidor WCS admite el método REST para recibir instantáneas:
/stream/snapshot
Agregar una secuencia al mezclador
Una imagen de dos o más fuentes se puede combinar en una para mostrarla a los espectadores finales. Este procedimiento se llama mezclar. Ejemplos básicos: 1) Videovigilancia de múltiples cámaras en la pantalla en una sola imagen. 2) Videoconferencia, donde cada usuario recibe una secuencia, en la que el resto se mezclan, para ahorrar recursos. El mezclador se controla a través de la API REST y tiene un modo de operación MCU para crear videoconferencias.
Comando REST para agregar una secuencia al mezclador:
/mixer/startup
Transcodificación de flujo
Las transmisiones a veces necesitan ser comprimidas para adaptarse a ciertos grupos de dispositivos cliente por resolución y velocidad de bits. Para esto, se usa la transcodificación. La transcodificación se puede habilitar en el lado del SDK web, a través de la API REST, o automáticamente a través de un nodo especial de transcodificación en el CDN. Por ejemplo, un video de 1280x720 se puede transcodificar a 640x360 para su distribución a clientes de una región geográfica con un ancho de banda tradicionalmente bajo. ¿Dónde están tus satélites, Elon Musk?
Método REST utilizado:
/transcoder/startup
Agregar una marca de agua
Se sabe que cualquier contenido puede ser robado y convertido en WebRip, sin importar la protección que tenga el reproductor. Si su contenido es valioso, puede incrustar una marca de agua o un logotipo en él que complicará en gran medida su uso posterior y su exhibición pública. Para agregar una marca de agua, simplemente cargue una imagen PNG y se insertará en la transmisión de video mediante transcodificación. Por lo tanto, tendrá que preparar un par de núcleos de CPU en el lado del servidor en caso de que aún decida agregar una marca de agua a la transmisión. Para no crear la marca de agua en el servidor mediante transcodificación, es mejor agregarla directamente en el codificador / transmisor, que a menudo brinda esa oportunidad.
Agregar un filtro FPS
En algunos casos, se requiere que la transmisión tenga un FPS uniforme (fotogramas por segundo). Esto puede ser útil si retransmitimos la transmisión a un recurso de terceros como Youtube o Facebook o la reproducimos con un reproductor HLS sensible. El filtrado también requiere transcodificación, así que asegúrese de evaluar adecuadamente la potencia de su servidor y prepare 2 núcleos por flujo si se planea dicha operación.
Rotación de imagen en 90, 180, 270 grados.
Los dispositivos móviles tienen la capacidad de cambiar la resolución de la transmisión publicada en función del ángulo de rotación. Por ejemplo, comenzó a transmitir, sosteniendo el iPhone horizontalmente y luego lo giró. De acuerdo con la especificación WebRTC, el navegador streamer del dispositivo móvil (en este caso iOS Safari) debería indicar la rotación al servidor. A su vez, el servidor debe enviar este evento a todos los suscriptores. De lo contrario, sería así: el transmisor coloca el teléfono de costado, pero aún ve su cámara verticalmente, mientras que los espectadores ven una imagen girada. Para trabajar con rotaciones en el lado del SDK, se incluye la extensión cvoExtension correspondiente.
Gestión de flujos entrantes
Automático: la configuración generalmente se establece en el lado del servidor en la configuración.
Transmisión de transmisión
La retransmisión también es una opción para manipular las secuencias que ingresan al servidor; Consiste en forzar la transmisión a un servidor de terceros. Retransmitir es sinónimo de palabras como republicar, empujar, inyectar.
La retransmisión se puede implementar utilizando uno de los siguientes protocolos: WebRTC, RTMP, SIP / RTP. La tabla muestra la dirección en la que se puede transmitir la transmisión.
Retransmisión de WebRTC
Una transmisión se puede retransmitir a otro servidor WCS si por alguna razón se requiere que la transmisión esté disponible en otro servidor. La retransmisión se realiza a través de la API REST a través del método / push. Al recibir dicha solicitud REST, WCS se conecta al servidor especificado y publica una secuencia de servidor a servidor. Después de eso, la transmisión está disponible para su reproducción en otra máquina.
/pull/push
- método REST utilizado
Retransmisión RTMP
Al igual que con la retransmisión WebRTC, también es posible la retransmisión RTMP a otro servidor. La diferencia solo estará en el protocolo de retransmisión. La retransmisión RTMP también se realiza a través de / push y permite transferir la transmisión tanto a servidores RTMP de terceros como a servicios que admiten RTMP Ingest: transmisión de Youtube, Facebook, etc. Por lo tanto, el flujo de WebRTC puede transmitirse a RTMP. También podríamos retransmitir cualquier otra transmisión que ingrese al servidor, por ejemplo RTSP o VOD, a RTMP.
La transmisión de video se transmite a otro servidor RTMP mediante llamadas REST.
/push/startup
- llamada REST utilizada
Retransmisión SIP / RTP
Raramente se utiliza la función. Muy a menudo, se utiliza en la empresa. Por ejemplo, cuando necesitamos establecer una llamada SIP con un servidor de conferencia SIP externo y redirigir la transmisión de audio o video a esta llamada para que la audiencia de la conferencia vea algún tipo de contenido de video: "Por favor, mire este video" o "Colegas , ahora veamos una transmisión de cámara IP desde el sitio de construcción ”. Debemos tener en cuenta que, en este caso, la conferencia en sí existe y se administra en un servidor VKS externo con soporte SIP (recientemente, hemos probado la solución de Polycom DMA), mientras que solo conectamos y transmitimos la transmisión existente a este servidor La función API REST se llama / inject y sirve solo para este caso.
Comando API REST:
/call/inject_stream/startup
Conexión de servidores a una red de procesamiento de contenido CDN
Por lo general, un servidor tiene una cantidad limitada de recursos. Por lo tanto, para grandes transmisiones en línea donde la audiencia cuenta con miles y decenas de miles, es necesario escalar. Se pueden combinar varios servidores WCS en una red de entrega de contenido CDN. Internamente, CDN trabajará a través de WebRTC para mantener una baja latencia durante la transmisión.
El servidor se puede configurar en una de las siguientes funciones: Origen, Edge o Transcodificador. Los servidores de tipo Origin reciben tráfico y lo distribuyen a los servidores Edge, que son responsables de entregar la transmisión a los espectadores. Si es necesario preparar una secuencia en varias resoluciones, los nodos de transcodificador se incluyen en el esquema, que asume la misión que consume recursos de transcodificar secuencias.
Para resumir
WCS 5.2 es un servidor para desarrollar aplicaciones con soporte de audio y video en tiempo real para navegadores y dispositivos móviles. Se proporcionan cuatro API para el desarrollo: Web SDK, iOS SDK, Android SDK, REST API. Podemos publicar (transmitir) transmisiones de video al servidor utilizando cinco protocolos: WebRTC, RTMP, RTSP, VOD, SIP / RTP. Desde el servidor, podemos reproducir transmisiones con reproductores utilizando cinco protocolos: WebRTC, RTMP, RTSP, MSE, HLS. Las transmisiones se pueden controlar y someterse a operaciones tales como grabar, cortar instantáneas, mezclar, transcodificar, agregar una marca de agua, filtrar FPS y transmitir video enciende dispositivos móviles. Las transmisiones pueden transmitirse a otros servidores a través de los protocolos WebRTC y RTMP, así como redirigirse a conferencias SIP. Los servidores se pueden combinar en una red de entrega de contenido y escalar para procesar una cantidad arbitraria de transmisiones de video.
Lo que Alice debe saber para trabajar con el servidor
El desarrollador necesita poder usar Linux. Los siguientes comandos en la línea de comando no deberían causar confusión:
tar -xvzf wcs5.2.tar.gz
cd wcs5.2
./install.sh
tail -f flashphoner.log
ps aux | grep WebCallServer
top
También se necesita saber Vanilla JavaScript cuando se trata de desarrollo web.
//publishing the stream session.createStream({name:'mystream'}).publish(); //playing the stream session.createStream({name:'mystream'}).play();
La capacidad de trabajar con el back-end también puede ser útil.
WCS no solo puede recibir comandos de control a través de la API REST, sino también enviar ganchos, es decir, notificaciones sobre eventos que ocurren en él. Por ejemplo, al intentar establecer una conexión desde un navegador o una aplicación móvil, WCS activará el enlace / connect, y cuando intente reproducir una transmisión, activará el enlace playStream. Por lo tanto, el desarrollador tendrá que caminar un poco en el camino del back end, que puede crear tanto un cliente REST simple como un pequeño servidor REST para procesar ganchos.
Ejemplo de API REST
/rest-api/stream/find_all
- ejemplo de API REST para enumerar transmisiones en el servidor
Ejemplo de gancho REST
https://myback-end.com/hook/connect
- REST enganchar / conectar el procesamiento en el lado del backend.
Linux, JavaScript, REST Client / Server: tres elementos que son suficientes para desarrollar un servicio de producción en la plataforma WCS que trabaje con transmisiones de video.
El desarrollo de aplicaciones móviles requerirá conocimiento de Java y Objective-C para Android e iOS, respectivamente.
Instalación y lanzamiento
Hay tres formas de iniciar rápidamente WCS hoy:
1) Instalar Ubuntu 16.x LTS o Ubuntu 18.x LTS, etc. en tu Centos7. o dejarse guiar por el artículo de la documentación .
o
2) Obtenga una imagen preparada en Amazon EC2 .
o
3) Obtenga una imagen preparada del servidor en Digital Ocean .
Y comience un emocionante desarrollo de proyecto con funciones de transmisión de video.
El artículo de revisión resultó ser bastante grande. Gracias por la paciencia para leerlo.
¡Que tengas una buena transmisión!
Enlaces
WCS 5.2 - Servidor WebRTC
Instalación y lanzamiento
Instalación y lanzamiento de WCS
Lanzar imagen preparada en Amazon EC2
Inicie la imagen preparada del servidor en DigitalOcean
SDK
Documentación SDK web
Documentación Android SDK
Documentación SDK de iOS
Casos
Transmisiones entrantes
Transmisiones salientes
Gestión de corrientes
Transmisión de transmisión
CDN para transmisión WebRTC de baja latencia
Documentación
Documentación Web Call Server 5.2