Nuevo protocolo RTP SMTPE2022-1

En las ultimas actualizaciones de las cámaras hemos visto evolucionar aspectos como el numero de dispositivos reconocible por las cámaras y otras mejoras, pero en le última actualización hemos perdido la codificación TCP (Protocol Control Transmisión) y ha sido reemplazado por la RTP (real time transport protocol), ambos protocolos son de empuje (Push) y su codificación esta basada en UDP, como siempre digo no soy un experto en  la materia pero a grandes rasgos podemos ver lo que se ha  perdido y ganado con el cambio.

Ha efectos prácticos el perdido protocolo TCP aportaba principalmente el control o la comunicación entre origen-destino, ya que si la información no se recibía correctamente en destino, el operador de cámara en origen obtenía una información en visor que le informaba que algo no funcionaba bien. (LIVE normalmente Rojo , se le añadía un interrogante "fallo momentáneo" o llegaba a ser amarillo si aparecía un problema grave). A efectos técnicos existía mayor retardo que en UDP

El Protocolo  RTP .

El protocolo RTP se ejecuta, normalmente, sobre UDP, y posee menor retardo que TCP. Por esta razón con UDP se gana velocidad a cambio del control que ofrece TCP. Como RTP trabaja sobre UDP no garantiza la entrega de todos los paquetes, ni la llegada de éstos en el momento adecuado.

La función básica de RTP es multiplexar varios flujos de datos en tiempo real en un solo flujo de paquetes UDP, se puede por tanto enviar a un solo destino (unicast) o múltiples destinos (multicast).

Otra característica muy importante para las aplicaciones de contenido multimedia en tiempo real, es el time-stamping (marcación del tiempo). Con el Time -Stamping la idea es permitir que el origen asocie una marca de tiempo con la primera muestra de cada paquete. Las marcas de tiempo son relativas al inicio del flujo, por tanto, solo importa las diferencias entre dichas marcas de tiempo. Con este planteamiento, el destino es capaz de almacenar en un pequeño buffer datagramas e ir reproduciendo cada muestra con el número exacto de milisegundos después del inicio del flujo reduciendo los efectos de la fluctuación y sincronizando con múltiples flujos entre sí.

Esto es útil para que se conozca en la recepción si ha fallado algún paquete en la transmisión. Si ha fallado, el receptor sabrá que ha existido un fallo e incluso cual pero al no tener un control de flujo, confirmación de recepción ni de solicitud de re-transmisión de paquetes no hay forma de recuperarlo a no se que se utilice un complemento adicional como es el SMPTE2022-1 FEC.

Las cámaras JVC con el nuevo protocolo RTP (basado en UDP) poden utilizar la opción de SMPTE2022-1 FEC (corrección de errores), donde la transmisión del vídeo principal RTP se envía por el puerto que determinamos en el menú de configuración de streaming, mientras que de forma simultanea se envía por dos puestos más información de corrección de errores por si tenemos perdidas de datos en el transporte.

En las cámaras JVC la información adicional de corrección de errores se envía de forma fija por los puertos +2 y +4 del que hayamos introducido en nuestra cámara que tiene que ser siempre un numero par. Es decir: si enviamos el streaming RTP por el puerto 6504 la información de corrección de errores se enviara automáticamente por los puertos 6506 y 6508, siempre que FEC este activado.

Nota. En las cámaras JVC y trabajando en RTP el puerto debe ser par, si introducimos en la cámara un puerto impar, la cámara mantendrá deshabilitado el "SET" para fijar el puerto (pasa a ser de color gris), solo si es un puerto es par "SET" queda habilitado (blanco) y deja fijar el puerto.

Dentro de la corrección de errores encontramos los ajuste de matriz FEC donde podemos ajustar los parámetros L y D, Si ajustamos la martriz a 10x10 la redundancia (repetición de datos por definirlo fácilmente) será baja 20% y si ajustamos la matriz a 4x4 la redundancia aumentará hasta el 50% . Hay que tener en cuenta que a mayor redundancia necesitaremos mayor ancho de banda.
El ajuste optimo de la matriz dependerá del ancho de banda y la calidad del enlace, por tanto la única opción de ajuste, es el ajuste-comprobación.

Si disponemos del decodificador BR-DE800 podremos usar el RTP SMPTE-2022-1 FEC en nuestra cámara, en el BR-DE800 el protocolo que deberemos seleccionar es el PRO-MPEG que es la opción 3 del menú de configuración, aunque en este caso deberemos introducir manualmente los puertos usados tanto el principal como el +2 y el ´4 mencionados anteriormente.

Nuevos adaptadores USB para streaming con camaras JVC.

En las ultimas actualizaciones de cámara con colectividad USB se han incorporado nuevos drivers para adaptadores USB, lo cual hace que las cámaras reconozcan un mayor numero de adaptadores.

Cada día el consumo de datos en telefonía es mayor y por tanto aparecen nuevas ofertas de dispositivos. Para evitar problemas de si un dispositivo dispone del driver correspondiente o si el usuario no sabe como configurar el modem, ha aparecido una nueva generación adaptadores USB/4G los cuales disponen de hardware interno el cual conecta nada mas recibir alimentación mediante el conector USB, de esta forma el dispositivo al cual conectamos el USB reconoce el dispositivo como dispositivo de Ehernet, es decir como una red informativa en donde ya se dispone de conexión a Internet sin necesidad de configurar nada.

Los nuevos modelos que están saliendo al mercado incorporan un motor Linux y se auto conectan con el APN entregando una conexión como si fuera de Ethernet, suelen estar asociados a compañías que ya tienen configurada su conexión.

Un ejemplo es el ZTE ME823 que según me han informado usa Movistar o el HUAWEI K5150 que ofrece Vodafone y que yo he podido comprobar personalmente.

Este tipo de adaptadores entiendo solo es útil para el envió de clip de vídeo vía FTP y para los modos de transmisión de vídeo (streaming) denominados push (empuje) como Zixi,TCP,UDP o RTMP, ya que es la cámara (JVC GY-HM200/300/660/850/890) que envía a una dirección concreta el streaming.

En caso de usar protocolo RTSP ,yo no he visto la forma de trabajar, ya que es un sistema Pull (tirar) y es necesario de conocer la dirección publica del router que esta conectado a la cámara, y en estos casos si miramos la dirección de la cámara nos muestra la IP interna del adaptador USB 192.168.0.1 la cual no nos sirve para capturar la transmisión en RTSP.

Si algún lector dispone de un dispositivo de este tipo y sabe como hacer o ver la IP para realizar un RTSP le agradeceré me lo haga saber.

Yo utilizo el HUAWEI E392, este es un 4G libre pero no sé si han cambiado firmware o si sigue estando en el mercado,Este es de la vieja usanza y hay que introducir los datos de configuración (ver blogs anteriores) pero si permite la transmisión en cualquier codificación. Si tiene que transmitir en RTSP le hará falta uno de este tipo ya que necesita conocer la IP Publica de la cámara, pero si emite en otro modo lo más sencillo es usar los de nueva generación con motor linux. 

Existen también en el mercado dispositivos de 3G/4G que son reconocidos por la cámara como Ethernet por su chip-set interno, pero si no llevan el motor Linux de conexión será imposible conectarnos. En el caso de que tenga motor linux como los mencionados en este articulo y disponga de tarjeta sera tan sencillo conectarlos como:

Menú

Sistema/Ajuste de Network/config,Conexión/Wizard / detecta Ethernet/ sigiente / DHCP/Sin Proxy/Fin. El indicador de conexión a red del visor se debe mostrar en Blanco (estamos conectados)

La nuevas actualizaciones de firmware de las cámaras permiten a las cámara reconocer dispositivos que antes no lo hacían , por ejemplo yo dispongo de un modem ZTE 3G MF680 que las primeras versiones no reconocían y que ahora puedo usar a la perfección, eso si,  sabiendo que es un 3G,

Al poder utilizar este viejo 3G he podido comprobar que en 3G y con los nuevos firmwares podemos controlar la cámara remotamente cosa que no consigo con el modem 4GLTE ya que el nodo telefónico no me permite acceder a ella.

El poder controlar la cámara remotamente aunque sea en 3G es ideal para poder dejar la cámara fija de forma autónoma mientras se controlarla y realiza streaming a distancia.

* estas son experiencias propias y declino cualquier responsabilidad de funcionamiento, ya que existen variaciones de firmware en los modems sin previo aviso. 

GY-HM660E IFB, Ya está disponible.

La nueva cámara de JVC GY-HM660E con todas las prestaciones y colectividad de su antecesora GY-HM650 ya esta disponible desde hace unos meses.

La GY-HM660E incorpora mejoras importantes, como la luminosidad F13 a 2000lux, su nueva pantalla LCD , novedades físicas que mejoran su operativa, y como no, mejoras evolutivas con la tecnología  en colectividad como el aumento del numero de dispositivos reconocibles por la cámara o la transmisión en MPEG2-TS/RTP SMPTE2022-FEC1 y matriz de corrector de errores.

Esta cámara apareció en la pasada edición del NAB 2016 con el compromiso de incorporar IFB. "IFB" Interruptible foldback traducido con google como "interrupción plegada", en definitiva expresado en puro español es un intercomunicador cámara-estudio/realización.

La intercomunicación a nivel mundial integrada en cámara vía IP es un avance muy importante, ya que se evita que los operadores tengan que hacer uso de otros dispositivos como teléfonos o codificadores externos haciendo el trabajo del reportero un poco más fácil.Ademas al ser vía IP los costes son prácticamente nulos puesto s¡que apenas ocupa ancho de banda y usa la misma conexión que nuestro streaming.

La GY-HM660E dispone de conexión IP para enviar una señal de video HD directamente a Internet o al centro de producción, y es ahí donde toma gran importancia el IFB, ya que nos permite que el realizador o presentador de un programa comunique con el operador de cámara por muy distante que este, ya que la conexión se hace mediante Internet, de esa forma se pueden realizar entrevistas o dar instrucciones de que planos necesitamos desde la realización. Esto ademas se puede realizar con varias cámaras a la vez.

Para poder realizar esto necesitamos codificar la señal de audio en los estudios o realización, para ello deberemos tener un codificador por hardware o bien por software,que codifique el audio que queremos enviar a la cámara o cámaras y que transmitiremos vía Internet.

Codificación por Hardware

Codificación por Software

En la cámara para realizar esta función "IFB" se ha integrado un decodificador de audio que se tiene que configurar (introduciendo IP/Puerto) para que decodifique la señal procedente del estudio. El operador de cámara recibe el audio procedente del estudio o realización por un canal de la salida de auriculares de la cámara, mientras mantiene el audio del entorno de grabación por el otro.

El canal de audio de cámara a realización es el propio audio de cámara que viaja junto con el vídeo en streaming, con lo cual los comentarios de trabajo del operador se tendrán que hacer fuera de plano o del directo. 

http://www.service.jvcpro.eu/public/document.cfm?prog=ProdSoft.cfm&Model=GY-HM660E