Alice es una desarrolladora de experiencia completa y es capaz de escribir un marco de proyecto SAAS en su marco favorito usando php en una semana. En la parte delantera, prefiere Vue.js.
Un cliente está llamando a un telegrama que, por todos los medios, necesita desarrollar un sitio web, que será el lugar de reunión del empleador y el empleado para realizar una entrevista en persona. Tiempo completo: significa contacto directo de video en tiempo real con video y voz.
"¿Por qué no Skype?" Usted pregunta. Dio la casualidad de que los proyectos serios, y cada startup, sin duda se considera a sí misma como tal, están tratando de ofrecer un servicio de comunicaciones internas por una variedad de razones, que incluyen:
1) No entregue a sus usuarios comunicadores de terceros (Skype,
lugares de reunión, etc.). Déjalos en el servicio.
2) Supervisar las comunicaciones: historial de llamadas, resultados de entrevistas.
3) Grabar llamadas (por supuesto, notificar a ambas partes de la grabación).
4) No dependa de políticas y actualizaciones de servicios de terceros. Todos conocen esta historia: Skype se actualizó y comenzó ...
La tarea parece simple. WebRTC es google sobre el tema y parece que puede organizar una conexión punto a punto entre dos navegadores, pero quedan preguntas:
1) Dónde obtener servidores STUN / TURN
2) ¿Es posible prescindir de ellos?
3) Cómo grabar una llamada WebRTC punto a punto
4) Qué sucederá si necesita agregar un tercero a la llamada, por ejemplo, un gerente de recursos humanos u otro especialista del empleador.
Resulta que solo WebRTC y peer-to-peer 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 todos estos puntos blancos, se utilizan soluciones de servidor y arquitectura de igual a igual. Web Call Server 5.2 WCS es una de las soluciones de servidor: 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 utiliza para desarrollar 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 un servidor (transmitir una 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, puede implementar no solo una aplicación web, sino también actualizaciones completas para Google Play y App Store con soporte para transmisión de video. Agregue SDK móviles a la imagen de nivel superior. Resultará así:
Transmisiones entrantes
El servidor de transmisión, que es WCS, comienza con las transmisiones entrantes. Para dar algo, necesitas tenerlo. Para distribuir transmisiones de video a los espectadores, es necesario que estas transmisiones ingresen al servidor, pasen por su RAM y salgan por la tarjeta de red. Por lo tanto, la primera pregunta que sería útil hacer al familiarizarse con un servidor de medios es: ¿para qué protocolos y formatos acepta este último las 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, a través de WebRTC, no solo puede ingresar una transmisión desde un navegador, sino también desde otro servidor. Mostramos las posibles fuentes de tráfico entrante en la tabla.
Si revisa las fuentes de tráfico entrante, puede agregar lo siguiente:
WebRTC entrante
Web SDK le permite capturar no solo la cámara y el micrófono, sino también usar las capacidades de la API del navegador para acceder a la pantalla: compartir pantalla. Además, puede capturar un elemento Canvas arbitrario y todo lo que se dibuja en él para su posterior transmisión es la transmisión de Canvas.
Android SDK y iOS SDK debido a los detalles móviles tienen la capacidad de cambiar entre la cámara frontal y trasera del dispositivo sobre la marcha. Esto le permite cambiar la fuente durante la transmisión sin detener la transmisión.
El flujo entrante de WebRTC también se puede obtener de otro servidor WCS por métodos: push, pull y CDN, que se analizarán un poco más adelante.
Rtmp entrante
El protocolo RTMP se usa ampliamente en los transmisores OBS favoritos y en otros codificadores: Wirecast, Adobe Media Ensourcer, ffmpeg, etc. Tomando uno de estos codificadores, puede capturar la transmisión y enviarla al servidor.
También puede recoger una transmisión RTMP de otro servidor de medios o servidor WCS de
utilizando métodos push y pull. En el caso de push, el iniciador es el servidor remoto. En el caso de pull, recurrimos al local para extraer el flujo 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 del hecho 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 del archivo por parte de los navegadores. En nuestro caso, esto está un poco mal. WCS traduce honestamente el 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 toma la transmisión y la reproduce desde el principio. Si no está limitado, 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 todos los demás (modo de transmisión de televisión pregrabada).
SIP / RTP entrante
Para recibir tráfico RTP entrante dentro de una sesión SIP, debe 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 en el servidor, puede replicar la transmisión recibida a uno o varios espectadores a pedido. El espectador solicita una transmisión del reproductor u otro dispositivo. Tales transmisiones se denominan salientes o "transmisiones de espectadores", porque 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, 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 su lugar
Se llama stream.publish (), stream.play () para la reproducción.
Un jugador también puede ser un servidor WCS de terceros, al que se le indicará que recoja una transmisión a través de WebRTC desde otro servidor utilizando el método pull o que recoja una 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. El hecho es que a pesar del hecho de que Flash dejó el navegador, dejó 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 para 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 proporciona datos de audio y video en 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 ha aparecido en el servidor, se genera una lista de reproducción HLS en formato .m3u8, que se entrega al reproductor en respuesta a una solicitud HTTP. La lista de reproducción describe qué segmentos del 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.
Bandeja de entrada y salida
Total tenemos 5 tipos de flujo entrantes y el mismo número de salientes. Listamos
ellos en la mesa:
Es decir podemos conducir transmisiones al servidor y podemos conectarnos a ellas y reproducir reproductores adecuados para este asunto. Para reproducir la transmisión WebRTC, use el SDK web. Para reproducir la 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 diremos qué acciones se pueden realizar con las transmisiones.
Manipulación de flujo entrante
Las transmisiones salientes en las que se sientan los espectadores no son particularmente manipuladoras. De hecho, si el espectador ha establecido una sesión con el servidor y ya está tomando 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 en transmisiones incluyen:
- grabar
- eliminación de instantáneas
- agregar corriente al mezclador
- transcodificación de flujo
- agregar marca de agua
- agregar filtro FPS
- rotación de imagen en 90, 180, 270 grados
Grabación de flujo entrante
Quizás la más comprensible y frecuente de las funciones. De hecho, las transmisiones requieren grabación en muchos casos: seminario web, lección de inglés, consulta, 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.
Eliminación de instantáneas
Una tarea igualmente común es tomar fotografías de la transmisión actual para mostrar iconos en el sitio. Por ejemplo, tiene 50 transmisiones en un sistema de videovigilancia, cada una de las cuales tiene una fuente de una cámara IP. 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 fotogramas por segundo y el ojo humano simplemente no aceptará esta frecuencia. Como solución, puede configurar instantáneas automáticas para cortar o comer a pedido, en este caso puede mostrar imágenes en un sitio con una frecuencia arbitraria, 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 siguiente método REST para eliminar instantáneas:
/stream/snapshot
Agregar corriente 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 para ahorrar recursos, en la que el resto se mezclan. 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
A veces se requiere que las secuencias se expriman 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, al ingresar 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 compañeros, 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 realmente tan 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 suba 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 todavía decida
agregue una marca de agua a la secuencia. Para no torcer la marca de agua en el servidor mediante transcodificación, es mejor agregarla directamente al codificador / transmisor, que
a menudo brindan esa oportunidad.
Agregar filtro FPS
En algunos casos, se requiere que la transmisión sea con un FPS uniforme (cuadros por segundo). Esto puede ser útil si transmitimos la transmisión a un recurso de terceros como Youtube o Facebook, o si la reproducimos con un reproductor HLS sensible. Filtrar nuevamente requiere transcodificación, así que calcule la potencia de su servidor y prepárese para la configuración más 2 núcleos por flujo si se planea dicha operación.
Gire la imagen 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, comenzaron a transmitir, sosteniendo el iPhone horizontalmente y luego se volvieron hacia un lado. De acuerdo con la especificación WebRTC, el navegador streamer del dispositivo móvil, y en este caso iOS Safari, debería indicar un giro al servidor. El servidor, a su vez, debe enviar este evento a todos los suscriptores. De lo contrario, habría resultado
para que el transmisor coloque el teléfono de lado, pero vea que su cámara aún está en posición vertical, mientras que los espectadores se apilan de lado. Para trabajar con giros en el lado del SDK, se incluye la extensión cvoExtension correspondiente.
¿Dónde está el control de las transmisiones entrantes?
Automático: la configuración generalmente se establece en el lado del servidor en
ajustes
Retransmisión corriente
La retransmisión también es una opción para manipular transmisiones que ingresan al servidor y consiste en forzar la transmisión a un servidor de terceros. Un sinónimo de retransmisión es palabras como: replicación, empuje, inyección.
El relé 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.
Relé 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 utilizando el 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
- El método REST utilizado.
Relé 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 le 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. Con el mismo éxito en RTMP, puede retransmitir cualquier otra transmisión que ingrese al servidor, por ejemplo, RTSP o VOD.
La transmisión de video se transmite a otro servidor RTMP mediante llamadas REST
/push/startup
- Llamada REST utilizada.
Relé SIP / RTP
Función raramente utilizada. Muy a menudo en la empresa. Por ejemplo, cuando desea configurar 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 contenido de video: "Por favor vea este video" o "Colegas, y ahora veamos la transmisión con IP cámaras del sitio de construcción ". Debe comprender que la conferencia en sí misma existe y se administra en este caso en un servidor VKS externo con soporte SIP (recientemente probamos la solución de Polycom DMA), simplemente 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
Un servidor generalmente tiene una cantidad limitada de recursos. Por lo tanto, para grandes transmisiones en línea, donde la cuenta de la audiencia llega a 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, Transcodificador. Servidores de tipo de origen: reciba tráfico y distribúyalo a los nodos de borde de los servidores de borde 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. Puede publicar (alimentar) transmisiones de video al servidor utilizando cinco protocolos: WebRTC, RTMP, RTSP, VOD, SIP / RTP. Desde el servidor, puede reproducir transmisiones con reproductores utilizando cinco protocolos: WebRTC, RTMP, RTSP, MSE, HLS. Las transmisiones se pueden controlar y realizar en operaciones tales como: grabar, cortar instantáneas, mezclar, transcodificar, agregar una marca de agua, filtrar FPS, 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 integrar 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. Equipos de este tipo en
La línea de comando no debe causar confusión:
tar -xvzf wcs5.2.tar.gz
cd wcs5.2
./install.sh
tail -f flashphoner.log
ps aux | grep WebCallServer
top
Vanilla JavaScript también debe ser capaz de desarrollar
Web
// session.createStream({name:'mystream'}).publish(); // session.createStream({name:'mystream'}).play();
La capacidad de trabajar con el backend también es útil.
WCS no solo puede recibir comandos de control a través de la API REST, sino también enviar ganchos, notificaciones sobre los eventos que ocurren en él.
Por ejemplo, cuando intente establecer una conexión desde un navegador o una aplicación móvil, WCS llamará al enlace / connect, y cuando intente reproducir una transmisión, llamará al enlace playStream. Por lo tanto, el desarrollador tendrá que mantenerse un poco en la zaga del back-end, que puede escribir tanto un cliente REST simple como un pequeño servidor REST para procesar ganchos.
Ejemplo de API REST
/rest-api/stream/find_all
- un ejemplo de una API REST para generar una lista de secuencias en un 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 son los tres elementos que
suficiente para desarrollar un servicio de producción en la plataforma WCS que funcione
con transmisiones de video.
El desarrollo de aplicaciones móviles requiere 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) Instale en su Centos7 o Ubuntu 16.x LTS o Ubuntu 18.x LTS, y
etc. guiado por un artículo de la documentación .
o
2) Tome la imagen terminada en Amazon EC2 .
o si no
3) Tome la imagen del servidor terminada en DigitalOcean .
Y comience un emocionante desarrollo de proyecto con funciones de transmisión de video.
El artículo de revisión resultó ser bastante voluminoso. Gracias por eso
leer paciencia
¡Que tengas una buena transmisión!
Referencias
WCS 5.2 - Servidor WebRTC
Instalación y lanzamiento
Instalar y ejecutar WCS
Lanzar una imagen precompilada en Amazon AWS
Lanzar la imagen terminada en DigitalOcean
SDK
Documentación del SDK web
Android SDK
iOS SDK
WebRTC CDN
La documentación
Web Call Server 5.2