* 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.