Con este articulo quiero dar continuidad la serie Connected Cam explicando algunas cosas fundamentales para entender cómo funciona el sistema y conocer tanto los pros como los contras de una realización remota.
Se entiende como realización remota aquella donde el equipo de realización se encuentra sito en un lugar fijo y las cámaras que generan el contenido se encuentran desplazadas en los diferentes eventos que se deben cubrir, de esta forma solo se desplaza parte del equipo de producción tanto humano como tecnológico.
Existen muchas formulas pero quiero centrarme en la realización IP de bajo coste.
En una realización remota debe disponer de:
Control de cámara.
Comunicación con operadores.
Recepción de las señales de vídeo estable y si es posible sincronizadas.
Control de cámara.
El control de cámaras, depende del fabricante y del modelo, y este será fácil , difícil o imposible.
En el caso de JVC todas las cámaras que tienen USB Host tienen control y muchas cosas más ya sea en los modelos más económicos de menos de 2000€ o en los más caros como la GY-HC900. Con JVC es muy fácil y existen diferentes formas de control remoto (vía PC, con paneles remotos o incluso integrados en la realización como con "Connected Cam Studio" o "Streamstar").
En el control de cámara se deben tener muy en cuenta las latencias o retrasos de la señal hasta que llega a la realización , Si desde realización queremos operar la cámara lo que se modifica tardará un tiempo en llegar. Esto es viable y hay profesionales que tienen un control casi perfecto, que se consigue con horas de trabajo hasta coger el pulso al las cámaras y su respuesta remota.
JVC en sus cámaras tiene la previsualización IP bien independiente o generando un "Visor multipantalla* " con una latencia mínima que permite un rápido control a distancia, lamentablemente para poder hacer uso de esta magnífica característica se deben utilizar otros medios que no son la propia cámara para hacer streaming o enviar la señal vía IP, RF etc, ya que JVC en estos momento no permite la transmisión simultánea de dos calidades (streaming de alta calidad y proxy de baja).
Comunicación con operadores.
El tema de la comunicación con el operador de cámara existen diferentes fórmulas, mochilas con intercom, intercom vía teléfono, etc.. JVC además de las soluciones estándar del mercado dispone en algunos modelos de cámara con un canal de comunicación vía IP (IFB), donde el realizador puede dar instrucciones a los operadores de cámara y el operador no necesita nada más que tener el auricular, puesto que que la cámara dispone de un decodificador interno y no requiere equipos adicionales.
En la nueva generación de cámaras JVC "Connected Cam" además del IFB se dispone de la opción de recibir el video de retorno de programa como referencia a los operadores o incluso en la GY-HC900 se ver con Picture in Picture por visor y tambien se puede extraer a un monitor y hacer en cualquier lugar un "Set" de entrevistas con retorno, donde el entrevistado puede ver al entrevistador o comentar videos o imágenes que se lanzan desde la realización.
Recepción de las señales de vídeo estable y si es posible sincronizadas.
Recepción de las señales de vídeo estable y si es posible sincronizadas.
Finalmente nos queda el tema de la señal de video y la sincronización y aquí es donde se complica más la cosa ya que depende como se haga los resultados pueden cambiar radicalmente.
Debemos tener en cuenta que si utilizamos Internet para transmitir video, es imprescindible disponer de suficiente ancho de banda, si no, los datos se perderán en el camino o llegarán demasiado tarde i la imagen ya no se podrá recomponer provocando falta de señal, congelación de imágenes o drops (pérdida de información cuadrados).
El streaming es un flujo constante y tiene limitaciones importantes en la capacidad de reconstruir la pérdida de datos. La capacidad para soportar pérdida de datos varía dependiendo del protocolo de transmisión que se utilice, este margen es amplio y que yo conozca puede ir de 0,2% en UDP hasta superar el 30% en Zixi. Esto tiene un contra importante, y es que a mayor seguridad , mayor latencia o retraso.
En Live video streaming se muestran los fotogramas conforme van llegando y completan una imagen.con un tiempo de espera que si se supera se omite el frame o la imagen mostrando la siguiente completa. Internet provoca diversas latencias que pueden variar de forma continua ya que la información se divide , mueve y modifica su camino hasta el destino constantemente. Esto conlleva a que aunque se envíen varios videos que están sincronizados en origen, no estarán sincronizados al llegar a destino,
¿Como sincroniza el KM-IP4100 y KM-IP6000 las imágenes?.
Como he comentado gracias al NTP del streaming y simplemente, se le asigna un streaming de entrada como referencia y el resto como esclavos. Evidentemente los problemas de internet siguen estando y si recibimos el streaming de cámaras por canales separados unas llegarán antes y otras después, pero en este caso el KM-IP es el encargado de leer memorizar y corregir los desfases entre los diferentes streamings de forma que corrige el error y entrega las cámaras sincronizadas. Para los que como yo ya tienen muchas canas es nuestro antiguo TBC con una entrada de Black Burst que en este caso sería el NTP que llega por el propio streaming.
Además de la latencia o retraso provocado por la codificación y decodificación del video a IP, los live streaming sufrirán un desfase de tiempo entre ellos, ya que con seguridad seguirán caminos diferentes, perdemos algunos paquetes en el camino y se deberá esperar que lleguen de nuevo para componer las imágenes.
El siguiente link es muy gráfico y creo que puede ayudar a comprender mi explicación, lo pongo a partir del punto donde habla de cómo se desfragmenta la señal y se envía, aunque la visualización completa del video es recomendable si eres como yo y quieres tener una visión del funcionamiento de internet.
Video completo. https://www.youtube.com/watch?v=rw41W8crZ_Y
La latencia por viaje de los datos dentro de internet es totalmente incontrolable, por tanto encontrarnos que dos cámaras sincronizadas por genlock en origen, captando lo mismo, desde diferentes ángulos al llegar a destino las imagenes se muestran con dos tiempos diferentes que además fluctuaron en el transcurso de la transmisión.
Ejemplo: la cámara uno muestra el gol como entra la pelota y como la pelota está dentro y al cambiar a cámara 2 vemos que la pelota desde otro ángulo vuelve a entrar dando la sensación de que la pelota ha ido hacia atrás y ha vuelto a entrar.(Tongooo ja,ja,).
Este problema de las latencias diferentes no se puede eliminar si trabajamos con streamings diferentes (1 por cámara) que circulan libremente por internet hasta llegar al destino.
Crear un VPN (Virtual Private Network) que garantiza seguridad ante intrusiones pero no garantiza que los streamings o imágenes lleguen sincronizados y sin derivas en tiempo.
Trabajar con sistemas de transmisión con bounding (mochilas) que aseguran en gran medida la transmisión, pero no la sincronía ya que son streamings diferentes. (Ahora empieza a aparecer algún sistema que sincroniza en cloud pero son complejos con elevados precios ).
Este efecto lo podemos ver siempre que transmitimos vídeo de forma independiente con routers o mochilas (aunque estas utilizan más de un router) etc.. La razón, cada imagen desde el origen, (cámara, codificador o mochila), tiene un IP de origen y destino diferente por tanto el router se asegura de lanzarlo a Internet perfectamente etiquetado para que los datos que salieron de la cámara 1 IPX al mezclador IPX/Puerto lleguen sin error y si tiene que esperar para recuperar datos o ha elegido un camino más largo que la cámara 2 llegará más tarde produciendo el efecto comentado anteriormente en el ejemplo.
Es diferente cuando codificamos las cámaras en red local y la salida de esta red con todos los streamings se envía por un VPN y mejor si disponemos de tecnologías añadidas con¡mo SpeedFusion ,Balance y o bounding.
¿Por qué? Porque nuestro router no sabe si enviamos una imagen , un texto o una letra, el router coge la información y la trocea creando los datagramas o particiones etiquetadas de forma que tratara todo el bloque de imágenes individuales como una sola, etiquetando su orden para que llegue a destino de igual forma que entraron en el router, es decir como una única imagen, de esta forma cuando se completa el paquete de datos ya disponemos de todas las imágenes.
Yo he realizado pruebas de transmisión con el SFECAM en un lado (router de campo con Speed Fusion, Balance, encriptación, FEC (corrección de errores) y Bonding-Debonding y en el otro lado el BPL-2100 switch/router estacionario con bonding-debonding y cámaras JVC y los resultados para mi han sido espectaculares, ya que aunque he observado alguna diferencia en tiempos de algún frame estos se mantienen si las cámaras están sincronizadas. Puesto que la información es bidireccional hago mención de en un lado y otro y no de transmisión recepción
En el caso de utilizar cámaras JVC es muy simple hacer esto ya que las cámaras al codificar internamente solo tengo que mantenerlas en la misma red de datos que me proporciona el SFECAM.
Esta configuración es casi perfecta y yo me atrevería a hacer una realización estándar sin problemas pero como he comentado tiene pequeñas latencias y no me garantiza la sincronía entre las cámaras.
Como he dicho las cámaras de JVC codifican internamente la señal de streaming, pero además aportan un añadido altamente importante y es que introduce en el streaming información de tiempo NTP que podríamos decir es el Genlock o sincronismo de internet. Esta función es ideal para sincronizar grabaciones sin necesidad de genlock en las cámaras ya que si las referenciamos con NTP todas tendrán el mismo código de tiempos, estén a un metro de distancia o a kilómetros.
Enlace a Artículo NTP
La capacidad de las cámaras JVC de enviar dentro del streaming el código de tiempo ha permitido desarrollar los sistemas de producción "Connected Cam Studio" KM-IP4100 y KM-IP600. estos junto con las cámaras JVC permiten gracias al código de tiempos en streaming sincronizar las cámaras en streaming, y es indiferente si se envía el streaming de forma independiente y separada como se comento al comiezo del articulo o en bloque mediante un equipo como el SFECAM que he comentado anteriormente que aporta ventajas de transmisión y estabilidad en el flujo de datos.
 |
| https://www.cybervista.net/network-time-protocol/ |
Como he comentado gracias al NTP del streaming y simplemente, se le asigna un streaming de entrada como referencia y el resto como esclavos. Evidentemente los problemas de internet siguen estando y si recibimos el streaming de cámaras por canales separados unas llegarán antes y otras después, pero en este caso el KM-IP es el encargado de leer memorizar y corregir los desfases entre los diferentes streamings de forma que corrige el error y entrega las cámaras sincronizadas. Para los que como yo ya tienen muchas canas es nuestro antiguo TBC con una entrada de Black Burst que en este caso sería el NTP que llega por el propio streaming.
Si son cámaras muy separadas físicamente podemos encontrar dificultades iniciales por existir un diferencial de latencia grande entre una cámara y otra (ejemplo real, mezcla de cámaras en Granada y Barcelona) en ese caso el equipo nos permite actuar de forma sencilla con el tamaño del Buffer ( memoria interna) para poder compensar esta diferencia y que las cámaras se sincronicen. En este caso se tuvo que aumentar en Buffer las entradas de cámara de Granada (locales) y reducir el de las de Barcelona (estaban más lejanas) para conseguir una buena estabilidad de sincronización.
Si por alguna razón las cámaras se desincronizan el KM-IP4100/6000 advierten al realizador con una indicación clara en pantalla de previo con "NO SYNC" para que no realice un encadenado de imágenes que puedan mostrar ejemplos similares al mencionado al principio de la pelota que sale y entra de la portería.
Conclusiones personales.
En definitiva hacer una realización remota sin nada específico, es demasiado inestable y no lo doy como viable.
Si utilizamos un sistema como el SFECAM y el BPL-210 para transmisión y se hace que todos los streamings pasen a través del sistema, creo que da suficiente estabilidad para poder hacer realización remota en la mayoría de los casos, con pequeñas demoras aunque sin sincronía.
Por último la opción económicamente asequible que actualmente está en el mercado es la utilización de las cámaras JVC junto con los KM-IP que garantiza la sincronización entre cámaras, si a eso le añadimos el SFECAM que da estabilidad en el transporte y recepción de señal es la combinación perfecta para cualquier realización remota con costes asequibles.
El sistema de sincronización IP de los KM-IP se basa en la lectura del código de tiempo NTP introducido en el streaming que tienen las cámaras JVC.Otros streamings procedentes de otras cámaras o decodificadores pueden no ser compatibles o con la sincronización IP
Los PM-IP4100 y KM-IP600 permiten con cámaras JVC:
Control remoto de optica funciones y colorimetría.
Sincronizar el streaming de las cámaras.
Enviar órdenes de audio a los operadores de cámara IFB (Icecast).
Enviar retorno de vídeo vía IP a los cámaras (serie Connected Cam).
Espero que esto pueda haber aclarado algunas dudas sobre la viabilidad de la realización remota, ya que en la actualidad es una necesidad, pero esta tiene complicaciones importantes si no se dispone de equipos específicos para ello.
El conjunto de equipos de JVC "Connected Cam" están pensados y diseñados para realización remota ( realización KM-IP, cámaras GY-HC, transmisión SFECAM-BPL210) diseñados para un trabajo intenso, de rápida configuración y puesta en marcha sin complicaciones, donde se consiguen unos resultados altamente profesionales con una moderada infraestructura de personal, esto su calidad de imagen y prestaciones hacen de este conjunto una opción de mercado altamente rentable.
El KM-IP son realizaciones todo en uno con replay, gráficos,ingesta, logos, streaming multiplataforma, entradas multiformato, grabación , control cámara , sincronización y más,
Descarga catalogo aquí KM-IP4100 KM-IP600. o visita la web de JVC.es.jvc,es
El KM-IP son realizaciones todo en uno con replay, gráficos,ingesta, logos, streaming multiplataforma, entradas multiformato, grabación , control cámara , sincronización y más,
Descarga catalogo aquí KM-IP4100 KM-IP600. o visita la web de JVC.es.jvc,es
No hay comentarios:
Publicar un comentario