Videoconferencia.
* Codificación de audio.
Primero vamos a digitalizar el audio, que en principio es analógico, para ello se muestrea (se cogen muestras de la señal) y despues se codifica (se asigna un valor binario a esa muestra). Se empezó con coger la voz como el ancho de banda de un Canal Vocal Telefónico, de 300 a 3100 Hz, aunque hay bandas de guarda (separación), de manera que se ocupa de 0 a 4 KHz. Para recuperar la información con la calidad original, hay un teorema que dice que hay que tomar muestras de la señal al menos al doble de la frecuencia máxima, es decir, si la f. max. que tenemos aquí es 4 KHz, debemos tomar el valor de la señal a 8 KHz, es decir, 8000 veces por segundo.
Ya tenemos la muestra de la señal, a ese valor de la muestra se le asigna un código, es decir, se codifica. En este caso el código es de 8 bits, lo que implica 256 posibles valores de la muestra. También implica que 8000 muestras/segundo x 8 bits/muestra son 64 Kbps. Por tanto, la voz analógica, de 0 a 4 KHz, la hemos pasado a un chorro de bits digital, de velocidad 64 Kbps.
Esto hasta aquí se llama modulación por impulsos codificados, MIC en español (PCM en ingles). Está en la G.711 de ITU.
Otra posibilidad es en vez de codificar el valor de la muestra, codificar *la diferencia con el valor anterior* de la muestra. Como la voz es una señal analógica continua, entre un valor y el siguiente habrá muy poca diferencia y la podremos codificar con menos bits, consiguiendo una mejora. Si en vez de muestrear a 8 KHz (en realidad 7.1 KHz, que es audio de alta calidad) muestreo a 16 KHz, y codifico con 4 bits, tengo 16 niveles de cuantificación (valores posibles de la muestra), y sigo teniendo 64 Kbps, en este caso con mayor calidad. Esto se llama codificación adaptativa, y es la norma ITU G.722.
Ahora imaginad la voz en el dominio de la frecuencia. La voz tiene un espectro (suena a coña, pero es así como se llama :-)). Es la forma que tiene la señal entre esos límites de 0 a 4KHz, p.e. una persona con la voz aguda tendrá un espectro con más componentes, o mayor cantidad de energia, en frecuencias altas. Un tio con la voz grave tendrá el espectro más desplazado a frecuencias bajas. ¿Pillais? Bueno, pues ese espectro puede ser modelado, aproximado, o reproducido, mediante fórmulas matemáticas conocidas, sólo cambiando unos parámetros (los 'predictores') más p.e. ganancias y frecuencias. Codificar estos parámetros es más sencillo que en casos anteriores, asi que me hacen falta menos bits que antes. La frec. de muestreo sigue siendo de 8 KHz, como en G.711, pero ahora el bits por muestra es de 2 (4 de niveles de cuantificación). Esto da un regimen binario de 16 Kbps, que ya es mejora sobre los anteriores. Esto es ITU G.728.
* Codificación de vídeo.
El video tambien es una señal analógica que habrá que muestrear y codificar, para pasarla a bits.
Tenemos dos formatos, PAL y NTSC. Fundamentalmente las diferencias son que PAL son 25 cuadros o tramas o fotogramas por segundo (fps), 30 en NTSC, y que PAL son 625 líneas por 525 en NTSC.
Para poder 'meter' estas señales en un sistema de videoconferencia, se normalizaron dos formatos intermedios: CIF y QCIF (Common Intermediate Format y Quarter CIF). CIF es 352x288 y QCIF 176x144 (resolucion horizontal x vertical)
Problema: imaginaos una videoconferencia a 15 fps, y codificación RGB, con 8 bits por color. Eso obliga a un canuto de la siguiente velocidad, pe. en CIF: 352 x 288 x 15 x (8+8+8)= 36.495.360 bps. Algo más de 36 Mbps para nada espectacular. :-).
Así que de nuevo toca reducir la cantidad de información a transmitir, mediante compresiones y codificaciones.
Se emplean técnicas de codificación estadística (de longitud variable). Imaginaos un texto cualquiera, pe. este mensaje. En él, hay símbolos (letras) que se repiten más que otras, seguramente las vocales, la 's', la 'n', el ' ', la 'c', etc.. y otras que aparecen mucho menos, como la 'x', la 'ñ' (es una pena, co'ñ'o :-)), la 'w', etc. Si para transmitir este texto asigno a cada letra la misma codificación, pierdo eficiencia (así es como es el ASCII, 8 bits por letra/símbolo). Sin embargo, si codifico las letras más frecuentes con el menor número de bits posibles, p.e. al ' ' le asigno el código binario '1', a la 'a' el código binario '011', a la 'e' el binario '010', a la 'r' el '00010', y a la 'w' el '0000000111101', ahorro espacio al transmitir. ¿Ok?
Imaginaos ahora un fotograma estático. Pe. un paisaje de montaña. Si cojo al azar un punto del cielo, será azul. Casi seguro al 100% que los puntos de alrededor también son azules, lo que implica que si transmito la información del punto central, me puedo ahorrar la de los puntos de alrededor. Esto es redundancia espacial, y se hace cogiendo el fotograma, diviendolo en bloques de 8x8 puntos, hallando su transformada discreta del coseno (DCT en ingles, para pasarlo a frecuencias), aprovechando que el ojo humano es más sensible a las frecuencias bajas codifico con mayor precisión estas frente a las altas, y despues lo codifico utilizando un código de longitud variable, segun lo que cuento arriba. Os suena, no? Igual que una imagen JPG.
Imaginaos ahora dos fotogramas de ese paisaje seguidos. Muy seguramente, los cambios entre ellos sean mínimos, cuando no sean la misma imagen. Con lo cual, transmitiendo la primera imagen, *y sólo las diferencias de la segunda con la primera*, vuelvo a reducir la cantidad de información a transmitir. Esto es redundancia temporal. ¿Cómo se reduce? Pues coges la imagen, la divides en bloques de 8x8, haces 'macrobloques' de 4x4 bloques, en la imagen siguiente, buscas a dónde ha ido a parar el macrobloque, en un área de 16 puntos alrededor de la situación original, esa diferencia se llama vector de movimiento que se vuelve a codificar en un código de longitud variable.
Cuando juntas todas estas técnicas, obtienes la recomendación H.261, que es codificación de video para velocidades entre 40 Kbps y 2 Mbps. Un equipo que cumpla H.261 ha de soportar QCIF de forma obligada, CIF de forma opcional y la estimación de movimiento también opcionalemnte.
Parece que ya hemos hablado de todo lo que deben cumplir un aparato para decir que tenemos videoconferencia, no?. Audio, video... Pues apenas hemos empezado.
* H.320.
Esta es una recomendación ITU sobre videoconferencia. Suele ser la que cumplen los equipos o la que deberían cumplir como mínimo. Se compone de lo siguiente:
Empezando con el vídeo, la H.320 obliga a que la codificación de video se haga según la H.261. De esta manera, podremos ver al interlocutor.
Sobre el audio, se obliga a que se cumpla la G.711. Las recomendaciones G.722 y G.728 son opcionales, pero si el equipo las cumple tendré más calidad de audio (G.722) ó menor requirimiento de ancho de banda (G.728).
Como normalmente la codificación de audio es más sencilla que la de vídeo, hay un retardo de canal para sincronizar ambas señales.
Poniendo un poco de orden está la H.242, que establece la coordinación ('handshaking') entre terminales, durante el establecimiento de la sesión de videoconferencia. Como las características y recomendaciones que soporta cada terminal son distintas, se encarga de negociar las mejores características que se deben mantener durante la videoconf.
Si tenemos una multivideoconferencia, quien pone orden es H.230, que establece la manera de realizar el refresco de las imagenes, la conmutación entre audio y video, etc.
Los datos de usuario, como compartición de aplicaciones, pizarra electronica, etc., van de acuerdo a la recomendación T.120.
Todos estos flujos de información (audio, video, control, datos de usuario, etc.) entran en la H.221, que la encargada del interfaz con la red. Establece la multiplexación de los distintos flujos de información sobre la trama de salida, que pueden ser 1 o varios (hasta 30) canales de datos (usualmente de RDSI!!) de 64 Kbps.
* H.323
Eso está muy bien, pero en mi empresa tenemos videoconferencia sobre red de área local, o sobre Internet, qué pasa?
Bueno, la H.320 está bien para determinados medios (RDSI, líneas punto a punto, que ofrecen un caudal garantizado y un retardo constante). Para videoconf. sobre LAN o Internet, que es un medio que no garantiza un ancho de banda (aunque suele ser mayor, desde 28K8 hasta pe. 155 Mbps) ni un retardo fijo, no es válida. Y lso retardos y el ancho de banda son importantes en una videoconf.
Por eso surge la H.323, que se diferencia de la H.320 en que se implementan nuevas codificaciones de audio y video, y las correspondientes al control de llamada (pasan a ser H.245 y H.225) y medio de transporte (H.225 frente a la H.221).
Como nuevas recomendaciones de vídeo, está la H.263, que es un superconjunto de la H.261. Contempla más formatos de imagen, a saber: 16CIF (1408x1152), 4CIF (704x506), CIF y QCIF, ya vistos, y Sub-QCIF, que es de 128x64. Además, la reducción de la redundancia temporal tiene en cuenta no sólo los fotogramas pasados si no también los futuros (los llamados cuadros B, evidentemente por medio de un buffer, todavía no se ha inventado la máquina del tiempo :-)). También aumenta el tamaño de la región a explorar para encontrar el macrobloque de un fotograma a otro, pasando a ser de 32 puntos frente a los 16 anteriores, por tanto con mayor posibilidad de éxito.
En audio, aparece la G.723, que es codificación adaptativa como la G.722, pero quedando en 4.3 o 5.3 Kbps, y la G.729, equivalente a la G.728 pero reduciendo el régimen binario de 16 a 8 Kbps.
Bueno, ya hemos avanzado algo, vamos a retroceder ahora :-), sobre el estandar T.120. Es el de conferencias de datos, para aplicaciones de usuario. Compartición de aplicaciones, pizarra electrónica, etc... Si tu software o máquina no tiene o soporta este estandar, tírala. :-)
T.120 surge de la necesidad, en una videoconferencia, de trabajo colaborativo. Pasarse una hoja de cálculo, hacer un dibujo estilo pizarra, y que sea compartido entre ambos conferenciantes, etc. Mucho más todavía cuando en vez de una videoconferencia de dos, tenemos una multivideoconferecia. Y en realidad, no está asociada a muerte a 'Videoconferencia', aun siendo su entorno natural, si no que es un estandar de compartición de datos.
¿Qué obtengo si uso T.120? Pues los datos pueden ser distribuidos en tiempo real a cada uno de los participantes, existe interoperabilidad entre equipos de distintos fabricantes, se asegura la integridad de los datos, es independiente de la red (RTC, LAN, RDSI, etc..), de la plataforma (Unix, PC, MAc...), etc....
En este tipo de conferencias siempre hay uno que manda :-), es el 'proveedor principal', que es el que ofrece los servicios de MCS (Multipoint Conference Services). La conexión (lógica, eh!) de los terminales a este puede ser en estrella, en cadena, en cascada, etc. Si el proveedor se cae, la conferencia (de datos, ojo!, no tiene por qué caerse la videoconf.) se va al garete.
En las conferencias de datos hay un 'dominio', que basicamnte es la conferencia en sí, y 'canales' dentro del dominio, que pueden ser públicos (para difusión, broadcast) o privados entre usuarios.
Estos canales son los siguientes:
1. Canal de errores de control. Prioridad máxima.
2. Canal de anotaciones. Prioridad alta.
3. Canal de Imagenes de Mapa de bits. Prioridad media.
4. Canal de transferencia de ficheros. Prioridad baja.
Agarraos al asiento :-). La T.120 no es tan sencilla, tiene 'trocitos'. De 'abajo' a 'arriba':
T.123: Protocolos de transporte de red. Presenta al nivel superior un interfaz común, e independiente del medio de transporte.
T.122: Servicio de datos genérico orientado a conexión que junta varias comunicaciones punto a punto para formar un dominio multipunto. Entre otras cosas, proporciona difusión de datos con control de flujo, direccionamiento multipunto, busca el camino más corto entre estaciones, etc. Los problemas de reserva y resolución de recursos se solucionan mediante testigos.
T.125: Protocolo de servicio de comunicación multipunto. Especifica los mensajes de protocolo necesarios según T.122
T.124: Control Genéricode Conferencia (GCC). Establece y libera las conexiones, maneja la lista de participantes, listas de aplicaciones y funcionalidades de las mismas, etc..
Aquí va, con caracter opcional, T.121: Plantilla General de Aplicaciones (GAT, General Aplication Template). Define una plantilla con la funcionalidad de una aplicación. Permite que quien se enfrente a programar algo de esto, se asegure de ajustarse a la recomendación.
T.126: Protocolo de intercambio de imágenes fijas y anotaciones. Está claro.
T.127: Transferencia multipunto de ficheros binarios. Permite la difusión de varios ficheros de forma simultanea, transmisiónprivada de ficheros entre grupos de participantes, etc..
T.128: Control audiovisual para sistemas multimedia multipunto. Esto controla el manejo de canales de audio y video en tiempo real dentro de una videoconferencia.
Las aplicaciones de usuario podrían utilizar los servicios de T.126, 127 y 128, ir directamente sobre T.124 ó sobre T.122/125, utilizar T.121...
Todo lo de antes está muy bien, ¿pero yo qué compro?
Tú compras un terminal de videoconferencia. Tienes de mayor a menor, sistemas de sala, rollabout, sistemas de sobremesa/videotelefonos, sistemas para PC (u ordenador en general), y para los de PC, sistemas en red de área local o Internet.
Un sistema de sala suele consistir en un CODEC (COdificador/DECodificador) con el hard/soft necesario para todo lo expuesto en los anteriores mensajes, conectado a una o varias pantallas de TV o monitores. Suelen utilizar líneas punto a punto o varios accesos RDSI (con un multiplexor inverso). Suele haber varias cámaras, de sala, de documentos (para enfocar papeles), magnetoscopios, fuentes externas de video, varios microfonos, etc.
Un sistema rollabout suele ser un CODEC con una única pantalla más o menos grande, integrado en un único mueble y con caracter más o menos portátil. 2 o 3 entradas y salidas auxiliares, y como medio de comunicaciones 1 o varios (hasta 3 normalemtne) accesos RDSI, para velocidades de 64 hasta 384 Kbps. Si no tiene conexión RDSI, el interfaz de salida es serie, V.35, X.21 o RS.449, de 64 Kbps hasta 2 Mbps.
Los equipos de sobremesa o videotelefonos suelen ser pequeños aparatos con una pantalla integrada, un auricular estilo teléfono, 1 o ninguna entradas/salidas auxiliares, y conexión a 1 acceso básico RDSI (por tanto, hasta 128 Kbps)
¿Para PC? Docenas de fabricantes hacen tarjetas para videoconferencia. P.e. el Intel ProShare. Suelen tener las mismas o menos características que los sistemas anteriores. Como pantalla, la del PC.
* ¿Qué se ha de mirar al adquirir un sistema de videoconferencia?
Aquí un pequeño apunte. Esto es VIDEOCONFERENCIA, así, con mayúsculas. Lo que todo el mundo hace vía Internet, ni es videoconferencia ni es ná :-). Para andar por casa, pues vale, pero ya está. Así que todo el rollo hasta aquí vale como culturilla general, como curiosidad, o por si alguien trabaja en alguna empresa y le preguntan sobre esto. Estamos hablando de sistemas y aparatos de, hmm, unas 200.000 hasta varios millones.
Un sistema de videoconferencia, un BUEN sistema de videocnferencia, ya sea para una sala como 1 tarjeta para PC, debería tener lo siguiente: Codificar resolución CIF, decodificar resolución CIF, hacerlo por hardware, no por software, tener salida de video compuesto, tener varias entradas auxiliares de video, codificar audio G.728 y G.729, tener entradas/salidas auxiliares de audio, tener un cancelador de eco full duplex (permite audio simultaneo bidireccional, no confundir con limitador de eco, que corta la comunicación de audio en un sentido cuando hablan en el otro!), ha de soportar T.120, interesa que sea ya compatible con H.323, que disponga de interfaz MVIP (para conexión con tarjetas de otros fabricantes), que disponga de kit de desarrollo de aplicaciones, etc.....
Todo esto son estandars, pero os podeis encontrar que hay fabricantes que además del estandar, soportan modos propietarios de codificación de audio y/o vídeo (p.e. SG4 en PictureTel). Estos algoritmos propietarios suelen dar mayor calidad que los estandar, pero obligan a que en el otro extremo haya un equipo del mismo fabricante. Además, suelen estar en equipos de gama medio-alta.
* Multivideoconferencia.
Para poder hacer una videoconferencia entre varios participantes a la vez, es necesario una Unidad de Control Multipunto o de Multiconferencia (MCU). A esta unidad se conectan (o llaman, si es vía RDSI) los participantes, y es la responsable de enviar a los participantes las señales de audio y video. Normalmente el audio es reenviado a todos los participantes, y para saber qué imagen es la que se envía a los participantes, hay dos maneras:
Conmutación manual: Hay un control manual por parte de uno de los participantes de qué imagen se recibe en el resto de monitores. Esto está en la H.243.
Conmutación automática. El que tenga un nivel de audio más alto es quien impone su imagen a los demas. Puede ser muy gracioso :)
Si comprais una MCU (un par de milloncejos, p.e.), interesa que:
El número de usuarios conectados sea el mayor posible. 4, 16, 48, hasta 256 son números de equipos comerciales. 255 es un número muy, muy alto, alcanzable con la conexión de MCU en cascada.
Ancho de banda por usuario. No es lo mismo una multivideoconferencia con 64 Kbps por usuario que con 384 Kbps. A mayor ancho de banda, mayor 'potencia' habrá de tener la MCU, (y mayor número de accesos si es vía RDSI)
Llamadas salientes. Puede ser interesante que sea la MCU quien llame al usuario, en vez de sólo recibir llamadas.
Facilidad de gestión. Programar videoconferencias futuras, reservando recursos para evitar su uso indeseado cuando de verdad necesite utilizarse.
Transcodificación. Normalmente en una multivideoconferencia habrá participantes a 64, a 128, a 384 Kbps, etc. PAra evitar problemas se suele ir a la velocidad del menor, lo que suele joder al que se ha gastado la pasta para ir a 384. Esta facilidad permite que cada usuario aproveche al máximo sus capacidades, auqnue otros participantes no puedan soportarlas.
Por supuesto, que soporte compartición de datos con T.120.
Saludos......JAAP
Datos del autor/a:
Nombre: Jose.Antonio Alonso
[Indice general] - [Sexo] - [linux] - [humor] - Chat entre usuarios - [miscelanea] - [Novedades] -
