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.

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