You are on page 1of 233

CANAL DE TELEVISION A TRAVES DE REDES IP

Por:
Marcelo Eduardo Ziem Corts









Trabajo de Ttulo presentado a la
Facultad de Ciencias de la Universidad Catlica de Temuco
Para Optar al Ttulo de Ingeniero en Ejecucin en Informtica.



-Temuco, 2005-
2
UNIVERSIDAD CATOLICA DE TEMUCO
FACULTAD DE INGENIERIA




COMISION EXEMEN DE TITULO


Este Examen de Titulo ha sido realizado en la Escuela de Informtica.


Presidente Comisin: ..............................................................
Sr. Oriel Herrera Gamboa
Director de Escuela de
Ingeniera Informtica




Profesor Gua: ..............................................................
Sr. Alejandro Mellado Gatica
Ingeniero de Ejecucin en Informtica
Magister en Telecomunicaciones




Profesor Informante: ..............................................................
Sr. Luis Alberto Caro Saldivia
Ingeniero Civil en Informtica.




Secretario Acadmico ..............................................................
de la Escuela de Informtica:
Sr. Luis Alberto Caro Saldivia
Ingeniero Civil en Informtica.




Temuco, Octubre de 2005.
3




INFORME TRABAJO DE TTULO




TTULO : CANAL DE TELEVISION A TRAVES DE REDES IP
ALUMNO : Marcelo Eduardo Ziem Corts


En mi condicin de profesor gua de este trabajo puedo efectuar las siguientes
observaciones:


El trabajo realizado presenta un detallado estudio de las tecnologas de streaming de
audio/video y denota esmero y dedicacin.

Se aprecia dominio terico avanzado en el tema.

Se ha hecho un adecuado uso de la ingeniera de sistemas multimediales, modelando
una solucin integral multiplataforma.

El logro alcanzado se ha realizado optimizando al mximo los recursos disponibles.



De acuerdo a estas consideraciones califico este trabajo con 7.0 (Siete coma cero).




________________________________
Alejandro Mauricio Mellado Gatica
Profesor Gua




Temuco, 24 de Octubre de 2005
4




INFORME TRABAJO DE TTULO




TTULO : CANAL DE TELEVISION A TRAVES DE REDES IP
ALUMNO : Marcelo Eduardo Ziem Corts


En mi condicin de profesor informante de este trabajo puedo efectuar las siguientes
observaciones:


El trabajo esta ordenado y bien estructurado y se han usado herramientas metodolgicas
adecuadas.

Se aprecia un buen nivel de dedicacin y claridad en los objetivos planteados.

Se aprecia un anlisis detallado de las distintas tecnologas asociadas al tema en
desarrollo.

La propuesta es atractiva, muy til e innovadora.



De acuerdo a estas consideraciones califico este trabajo con 7.0 (Siete coma cero).




________________________________
Luis Alberto Caro Saldivia
Profesor Informante




Temuco, 24 de Octubre de 2005

5
NDICE

NDICE DE CONTENIDOS......6
NDICE DE FIGURAS.....10
NDICE DE TABLAS..16
NDICE DE ANEXOS..17
RESUMEN18
















6
NDICE DE CONTENIDOS.
CAPITULO I
1. Introduccin a los Sistemas de Streaming.20
1.1. Contenidos Multimedia 24
1.1.1. Codificacin del Contenido Multimedia..25
1.1.1.1. Codificacin de Audio...25
1.1.1.2. Codificacin de Video...31
1.1.1.3. CODEC`s utilizados por los Sistemas de Streaming.34
1.2. Tipos de Servicios de Streaming...41
1.2.1. Transmisiones En directo (live)...41
1.2.2. Transmisiones Bajo Demanda (on-demand)....41
1.2.3. Transmisiones en falso-directo (casi bajo demanda)...42
1.3. Componentes de un Sistema de Streaming...43
1.3.1. Servidor Streaming..44
1.3.2. Red de Comunicaciones..45
1.3.3. Clientes de Contenidos Multimedia.46
1.4. Requisitos de un Sistema de Streaming47
1.5. Formatos de los Archivos de Streaming...51
1.5.1. Meta-files (Meta-archivos)...51
1.5.2. Archivos de audio.52
1.5.3. Archivos de Video54

7

CAPITULO II
2. Polticas de Gestin de los Servidores de Streaming60
2.1. Control de recursos62
2.2. Planificadores62
2.3. Polticas de Servicio..64
2.4. Sistemas de Almacenamiento68

CAPITULO III
3. Tecnologas de Red...70
3.1. Red de Usuarios70
3.2. Red Principal.72

CAPITULO IV
4. Arquitecturas utilizadas en los Sistemas de Streaming.79
4.1. Arquitecturas Centralizadas..79
4.2. Arquitecturas de Servidores Independientes.74
4.3. Arquitecturas basadas en servidores-Proxy..85
4.4. Arquitecturas distribuidas a nivel de los usuarios.89

CAPITULO V
5. Arquitecturas de Streaming a Gran Escala93
5.1. Requisitos de las arquitecturas de Streaming a Gran Escala.93
8
5.1.1. Escalabilidad del Sistema de Streaming...93
5.1.2. Tolerancia a Fallos...94
5.1.3. Costo del Sistema de Streaming...96
5.1.4. Balanceo de la Carga97
5.1.5. Comrpaticin de Recursos...97
5.2. Alternativas actuales para los sistemas de Streaming a Gran Escala98

CAPITULO VI
6. Estructura de una Estacin de Radio y un Canal de Televisin..104
6.1. Proceso de Transmisin de una Estacin de Radio105
6.2. Proceso de Transmisin de un Canal de Televisin...109
6.2.1. Modelo de Transmisin General....109
6.2.2. Modelo de Transmisin Reducido.114
6.3. Requerimientos de Hardware y Software de un Sistema de Streaming.....117
6.3.1. Sistemas Operativos y Hardware Soportados....117
6.3.2. Requisitos de la Red de Comunicacin.120

CAPITULO VII
7. Configuracin de Real Server para la Transmisin de Contenidos Multimedia.125
7.1. Server Setup127
7.2. Security...135
7.3. Logging & Monitoring139
7.4. Broadcasting143
9
7.5. Broadcast Distribution....151
7.6. Content Management..162
7.7. Advertising..166
CAPITULO VIII
8. Codificacin de Contenidos Multimedia con Real Producer..174
8.1. Conversin de archivos...175
8.2. La Digitalizacin Directa182
8.3. Transmisiones en Falso-Directo..185
8.4. Transmisiones en Directo....187
8.5. Opciones Adicionales..189

CAPITULO IX
9. Codificacin de Contenidos Multimedia con Windows Media Encoder....199
9.1. Conversin de archivos...202
9.2. La Digitalizacin Directa202
9.3. Capturacin de Pantalla...207
9.4. Transmisiones en Directo212
9.5. Transmisiones en Falso-Directo..214

CONCLUSION..225
REFERENCIAS230


10
NDICE DE FIGURAS.
CAPITULO I
Figura 1.1.: Comunicacin entre el Servidor y los Clientes..22
Figura 1.2.: Diferencia entre Streaming y Transferencia Clsica..24
Figura 1.3.: Transformacin de ondas de presin a seal discretizada..26
Figura 1.4.: Nivelacin del error de cuantizacin..27
Figura 1.5.: Proceso de transformacin de las ondas de presin a paquetes..27
Figura 1.6.: Proceso de transformacin de paquetes a las ondas de presin..28
Figura 1.7.: Ejemplo de una seal con silencio..28
Figura 1.8.: Ejemplo de modulacin ADPCM...29
Figura 1.9.: Esquema de el almacenamiento en buffer..30
Figura 1.10.: Esquema de la entrega desde el buffer al player..31
Figura 1.11.: Proceso de Codificacin por parte del Receptor..31
Figura 1.12.: Proceso de Decodificacin por parte del Transmisor...32
Figura 1.13.: Proceso de Codificacin del Video..32
Figura 1.14.: Proceso de Eliminacin de Redundancia de la Imagen33
Figura 1.15.: Proceso de Compresin de cada Imagen del Video.33
Figura 1.16.: Agrupacin en Cuadros de una Imagen a Comprimir..34
Figura 1.17.: Envo sucesivo de Paquetes Comprimidos de una Imagen..35
Figura 1.18.: Proceso de una Emisin en Directo..41
Figura 1.19.: Clasificacin de Seales en Vivo segn su Fuente...41
Figura 1.20.: Clasificacin de Seales en Vivo segn el Tipo de Transmisin.42
Figura 1.21.: Proceso de Transmisin Bajo Demanda...43
Figura 1.22.: Proceso de Transmisin Casi Bajo Demanda...44
Figura 1.23.: Componentes de un Sistema de Streaming...44

CAPITULO II
Figura 2.1.: Mdulos que Componen un Sistema de Streaming...59
11
CAPITULO III
Figura 3.1.: Ejemplo aplicaciones de un ADSL.70
Figura 3.2.: Ejemplo de Red con Cable Coaxial71
Figura 3.3.: Relacin entre Protocolos Modelo OSI y Protocolos de Tiempo Real...75

CAPITULO IV
Figura 4.1.: Esquema de Arquitecturas Centralizadas...78
Figura 4.2.: Esquema Servidores paralelos array de servidores.80
Figura 4.3.: Esquema Cluster de Servidores..82
Figura 4.4.: Esquema Arquitecturas de servidores independientes83
Figura 4.5.: Esquema Arquitecturas basados en un servidor principal centralizado.86
Figura 4.6.: Esquema Arquitecturas Servidor Principal paralelo / jerrquico...87

CAPITULO VI
Figura 6.1.: Estructura de una estacin de radio..104
Figura 6.2.: Imagen del productor de la estacin de radio..105
Figura 6.3.: Estructura del Canal de Televisin (Modo General)....108
Figura 6.4.: Imagen del Reproductor de Video110
Figura 6.5.: Esquema del Multiplexor de Video..111
Figura 6.6.: Estructura del Canal de Televisin (Modo Reducido).....113

CAPITULO VII
Figura 7.1.: Ventana de Configuracin de Real Server...123
Figura 7.2.: Configuracin de los Puertos de Real Server..124
Figura 7.3.: Configuracin de las interfaces de Real Server...125
Figura 7.4: Configuracin de las extensiones de archivo de Real Server...126
Figura 7.5.: Configuracin de las Restricciones de Real Server.127
Figura 7.6.: Configuracin de los servidores Redundantes128
12
Figura 7.7.: Configuracin de los Puntos de Montaje de Real Server129
Figura 7.8.: Configuracin de los Alias de Real Server..130
Figura 7.9.: Configuracin del Servicio Http de Real Server..130
Figura 7.10.: Configuracin del Cache de Real Server130
Figura 7.11.: Configuracin de las Reglas de Acceso de Real Server133
Figura 7.12.: Configuracin de las Bases de Datos de Real Server.134
Figura 7.13.: Configuracin de los Usuarios de Real Server..135
Figura 7.14.: Configuracin de las Reglas de Autentificacin de Real Server...136
Figura 7.15.: Monitor de Rendimiento del Sistema.137
Figura 7.16.: Configuracin del Monitor de Real Server.138
Figura 7.17.: Opcin Conexiones Entrantes del monitor de Sistema...138
Figura 7.18.: Opcin Archivos Utilizados del monitor de Sistema..139
Figura 7.19.: Configuracin de los archivos log de Real Server..139
Figura 7.20.: Configuracin de los archivos de Salida log de Real Server..140
Figura 7.21.: Configuracin de las retransmisiones de Real Producer141
Figura 7.22.: Configuracin de las retransmisiones para Quicktime...143
Figura 7.23.: Configuracin de las retransmisiones de Windows Media Encoder.144
Figura 7.24.: Configuracin de archiving de Real Server....145
Figura 7.25.: Configuracin de Codificadores Redundantes...146
Figura 7.26.: Esquema de la Arquitectura de Splitting....148
Figura 7.27.: Configuracin de los Receptores de Splitting150
Figura 7.28.: Configuracin de los Transmisores de Splitting....154
Figura 7.29.: Configuracin del Multicasting Escalable.156
Figura 7.30.: Configuracin del Back Channel Multicast de Real Server..157
Figura 7.31.: Configuracin de Multicasting para Windows Media..158
Figura 7.32.: Configuracin del Host Multicasting para Windows Media159
Figura 7.33.: Configuracin de los Servidores Espejo160
Figura 7.34.: Configuracin de los Servicios de Streaming Hosting..160
Figura 7.35.: Configuracin de Publicacin de Medios..161
Figura 7.36.: Configuracin del Comportamiento de Real Server..162
13
Figura 7.37.: Configuracin de los Servicios de Publicidad de Real Server..164
Figura 7.38.: Ejemplo de Archivo SMIL.165
Figura 7.39.: Configuracin de la Generacin Automtica de Archivos SMIL166
Figura 7.40.: Ejemplo de una llamada a un Contenido Multimedia...168
Figura 7.41.: Configuracin Tiempos de Espera del Servidor de Publicidad.169

CAPITULO VIII
Figura 8.1.: Ventana Principal de Real Producer171
Figura 8.2.: Seleccin de la Fuente de Contenidos Multimedia.173
Figura 8.3.: Seleccin de la Salida del Contenido Multimedia..173
Figura 8.4.: Ingreso de los Datos del Contenido Multimedia174
Figura 8.5.: Seleccin de las Audiencias (ancho de Banda)...175
Figura 8.6.: Configuracin de la Ventana de Video de Real Producer...178
Figura 8.7.: Configuracin del Dispositivo de Audio.179
Figura 8.8.: Ejemplo de Seleccin de los Dispositivos de Entrada.180
Figura 8.9.: Configuracin de la Salida a Archivo..181
Figura 8.10.: Seleccin de la Entrada de Archivo...182
Figura 8.11.: Seleccin de la Salida a Servidor..............183
Figura 8.12.: Configuracin de la Conexin con el Servidor.183
Figura 8.13.: Seleccin de la Fuente de Contenidos Multimedia...184
Figura 8.14.: Seleccin de la Salida a Servidor..185
Figura 8.15.: Configuracin de la Conexin con el Servidor.185
Figura 8.16.: Configuracin de una Audiencia en Particular..187
Figura 8.17.: Configuracin de la Velocidad de Muestreo de Frames...187
Figura 8.18.: Configuracin Ancho de Banda de cada Audiencia......188
Figura 8.19.: Configuracin de la Calidad de Compresin del CODEC188
Figura 8.20.: Configuracin Avanzada del Video..189
Figura 8.21.: Configuracin del CODEC de audio para solo Voz.189

14
CAPITULO IX
Figura 9.1.: Ventana Principal de Windows Media Encoder...192
Figura 9.2.: Seleccin de las Fuentes de Entrada.194
Figura 9.3.: Seleccin del Mtodo de Distribucin.194
Figura 9.4.: Seleccin de las Audiencias.195
Figura 9.5.: Ingreso de la Informacin del Contenido Multimedia.195
Figura 9.6.: Seleccin de los Dispositivos de Entrada196
Figura 9.7.: Seleccin del Archivo de Salida...197
Figura 9.8.: Seleccin del Mtodo de Distribucin.197
Figura 9.9.: Seleccin de la Audiencia198
Figura 9.10.: Ingreso de la Informacin del Contenido Multimedia...198
Figura 9.11.: Seleccin del Mtodo de Captura..199
Figura 9.12.: Seleccin de la Ventana a Capturar200
Figura 9.13.: Seleccin de la Regin de la Pantalla a Capturar...200
Figura 9.14.: Seleccin de la Salida.201
Figura 9.15.: Configurar la Calidad de Captura...202
Figura 9.16.: Ingreso de la Informacin del Contenido Multimedia202
Figura 9.17.: Seleccin de las Fuentes de Entrada...203
Figura 9.18.: Seleccin del mtodo de Distribucin....204
Figura 9.19.: Ingreso de los Datos de Autentificacin con el Servidor...205
Figura 9.20.: Seleccin de las Audiencias...206
Figura 9.21.: Seleccin de Salida a Archivo....206
Figura 9.22.: Ingreso de la Informacin del Contenido Multimedia....207
Figura 9.23.: Ventana de Autentificacin con el Servidor...208
Figura 9.24.: Seleccin de la Entrada en el Panel Principal.210
Figura 9.25.: Ingreso de los Datos del Servidor...211
Figura 9.26.: Seleccin de las Audiencias en el Panel Principal.211
Figura 9.27.: Configuracin avanzada del Video212
Figura 9.28.: Ingreso de la Informacin del Contenido en el Panel Principal.212
Figura 9.29.: Ingreso de los Datos de Autentificacin con el Servidor...213
15
ANEXO
Figura A.1.: Ingreso de los Datos de Autentificacin para acceder al Servidor.217
Figura A.2.: Resumen de la Configuracin de los Puertos.218




















16
NDICE DE TABLAS.
CAPITULO III
Tabla 3.1.: Tabla de Mximos Flujos que pueden soportar Redes ATM...72

CAPITULO V
Tabla 5.1.: Tabla de las principales caractersticas de las arquitecturas100

CAPITULO VI
Tabla 6.1.: Requisitos del Real Server......116
Tabla 6.2.: Requisitos del Real Producer...116
Tabla 6.3.: Requisitos del Windows Media Encoder.117
Tabla 6.4.: Requisitos del Sam Broadcaster...117
Tabla 6.5.: Requisitos del Estudio de Televisin...118
Tabla 6.6.: Ancho de Banda Necesario del Sistema de Streaming............120

CAPITULO VII
Tabla 7.1.: Tabla del valor TTL de una Red Multicast151

CAPITULO VII
Tabla 8.1.: Valores de Frame Rate para la Norma de Video PAL..188



17
NDICE DE ANEXOS.

A. Instalacin del Servidor...217


















18
RESUMEN.
Hoy en da es ms comn que las personas estn interesadas por recibir informacin
por Internet de la mejor forma posible, esto quiere decir, de forma clara y entendible. Esto
se debe al gran crecimiento de Internet en los hogares, y de que los precios de conexin han
bajado considerablemente en los ltimos aos. Es por ello que la transmisin de un canal de
televisin y una estacin de radio por Internet se hace hoy en da indispensable para la
difusin de informacin a todas las personas de forma eficiente y clara.
Como dicha transmisin en vivo necesita que la informacin llegue lo mas rpido
posible a los usuarios, se creo la tecnologa de streaming, que no es ms que la transmisin
de archivos multimedia en tiempo real, los cuales pueden ser reproducidos a medida que
llegan los paquetes a los usuarios, por lo que no deben ser descargados por completo para
realizar dicha accin.
Para poder transmitir los contenidos multimedia, se necesita un servidor de
streaming que se encarga de enviar la informacin a los usuarios. Dicha informacin es
recibida de los distintos productores de contenidos multimedia, que son los encargados de
generar la informacin a transmitir.
Hoy en da son tres las grandes empresas que lideran la transmisin de contenidos
multimedia, tanto para la televisin, como para las estaciones de radio. Estas se detallan a
continuacin:
- Realnetworks: Con su Servidor de streaming Real Server, con su Productor Real
Producer Plus, y su Reproductor Real Player.
19
- Microsoft: con su servidor Windows Media Server, con su Productor Windows
Media Encoder, y su Reproductor Windows Media Player.
- Apple: con su servidor QuickTime Streaming Server, con su Productor QTSS
Publisher, y su Reproductor QuickTime.
La comunicacin entre dichos productores y el servidor es distinta para cada uno de los
descritos anteriormente. La diferencia radica en que el servidor de Realnetworks emula el
funcionamiento de los otros dos, por lo que con solo contar con el servidor Real Server, se
puede prestar los servicios, tanto para los usuarios de Real Player, Windows Media Player y
Quicktime Player.
Es por ello que se describir el funcionamiento y configuracin de los servidores de
streaming para la correcta transmisin de nuestro canal de televisin y estacin de radio,
adems de los distintos productores que generan la informacin a transmitir.










20











CAPITULO I











21
1. Introduccin a los sistemas de Streaming.
El trmino Streaming (del ingls stream que significa corriente, arroyo, flujo, fluir)
es una tecnologa que permite la recepcin instantnea, sin esperas, de informacin que
fluye desde un servidor [1]. Lgicamente sta tecnologa, que muchos pensarn que es de
reciente aparicin, est muy experimentada en el campo de Internet y surge de la necesidad
de acceder a tipos de informacin voluminosa que generan amplios tiempos de espera
usando la tradicional descarga de archivos. Esta informacin es, fundamentalmente, de tipo
audiovisual aunque puede ser slo audio (Radios en la Red) o vdeo (Canal de Televisin).
Desde su creacin, los archivos de audio y vdeo han sido (y seguirn siendo a pesar de las
compresiones) muy grandes. Los tamaos de los vdeos o de cualquier elemento
multimedia pueden superar los MB y llegar a los GB lo que es impensable para un sistema
que an funciona demasiado lento como puede ser Internet. En definitiva, para concretar,
muchos mega bytes para poder ser transmitidos con facilidad.

22
Figura 1.1.: Comunicacin entre el Servidor y los Clientes.
El trmino Streaming hace referencia a servicios en los cuales los usuarios son
capaces de pedir contenidos multimedia (videos) en cualquier instante de tiempo. Esta
tecnologa es de vital importancia para diversas aplicaciones multimedia como por ejemplo,
aprendizaje a distancia, bibliotecas digitales, videoconferencias, internet, televisin
sistemas de video bajo demanda.
En los ltimos aos, los sistemas de video bajo demanda han sido una de las reas
ms activas en la investigacin debido a la convergencia de dos factores: el creciente
inters de la industria de diversos sectores en desarrollar estos sistemas y su elevada
complejidad de diseo e implementacin. Gracias a la reduccin de costos de los
componentes que integran un sistema de Streaming y lo avances de la tecnologa, los
servicios de Streaming han alcanzado la madurez necesaria de forma que su
implementacin y comercializacin ya son viables. Esta nueva tecnologa ha provocado una
revolucin en la industria del entretenimiento, atrayendo el inters de las empresas de cable
(deseosas de aumentar su oferta mediante servicios de valor agregado), la implicacin de
las compaas tradicionales de hardware (IBM, etc.) y software (Microsoft, etc.) y la
aparicin de nuevas empresas enfocadas explcitamente hacia el diseo y la venta de
sistemas de Streaming. Respecto a la investigacin, los servicios de Streaming y su
implementacin han aportado nuevos retos a la comunidad cientfica. El diseo de estos
sistemas involucran diferentes reas: psicologa (estudio del comportamiento de los
usuarios), sistemas de tiempo real, sistemas de archivo de altas prestaciones, calidad de
servicio , protocolos de comunicaciones, formatos de compresin, criptografa, sistemas de
procesamiento jerrquicos, paralelos distribuidos, etc. Hoy en da y gracias a las
23
comunicaciones de banda ancha disponibles (ya sea DSL, Cable, Satlite) y a los sistemas
de compresin de audio y vdeo con calidad (mp3, mpeg-4, divx, etc.) se ha hecho mucho
ms fcil descargarse grandes cantidades de informacin. Por eso, hace aos, se pens en
una manera, tecnolgicamente posible, de retransmitir con facilidad esa informacin y el
resultado es la tecnologa del Streaming. Como se menciono anteriormente, hoy en da, se
sigue usando la tradicional descarga de archivos, para compartir contenidos multimedia,
siendo el Streaming una gran revolucin, ya que permite reproducir los contenidos, a
medida que se recibe la informacin [2]. Es por ello que existen distintos tipos de acceso a
medios multimedia:
- Streaming: El cliente reproduce la informacin segn llega a travs de la red y luego la
descarta.
- Descarga: Se descarga toda la informacin al disco local; una vez descargada toda la
informacin, se reproduce.
- Pseudo-Streaming: Descarga tradicional, pero segn se va almacenando todo el objeto
de medio en un fichero, este es ledo secuencialmente y se reproduce su contenido.

24

Figura 1.2.: Diferencia entre Streaming y Transferencia Clsica.

1.1. Contenidos Multimedia:
La mayora de la funcionalidad especfica de los sistemas de Streaming
deriva de las caractersticas particulares del tipo de informacin (contenidos
multimedia) gestionada por estos sistemas. A diferencia de los tipos de datos
tradicionales, los contenidos multimedia tienen una dimensin temporal explcita, y
entonces deben ser presentados mediante una frecuencia especfica durante un tiempo
determinado de lo contrario la integridad de la informacin se perder [2]. De todos
los contenidos multimedia, el ms significativo por sus requisitos y caractersticas es
el video. Un video consiste en una secuencia de imgenes que son visualizadas a una
frecuencia preestablecida (play rate), que normalmente suele ser alrededor de 30
imgenes por segundo. Los contenidos multimedia tienen una naturaleza analgica y
para que esta informacin pueda ser gestionada y almacenada en un ordenador debe
ser digitalizada. Sin embargo, su digitalizacin genera un volumen de informacin
25
demasiado grande para ser almacenada trasmitida eficientemente por la red. Para
reducir los requisitos de los videos, stos se codifican guardando solo la informacin
correspondiente a los pxeles lneas de informacin consecutivas que son diferentes.
En cuanto al sonido, se eliminan los silencios y redundantes, para as alivianar la
informacin gestionada. Las tcnicas de codificacin / compresin explotan las
redundancias espaciales y temporales del video, las cuales pueden variar de una
escena a otra. A continuacin se dar a conocer el proceso de codificacin del
contenido multimedia.


1.1.1. Codificacin del contenido Multimedia:
El contenido multimedia debe ser codificado y comprimido para que el
volumen de la informacin sea ms liviano, y genere menos consumo del ancho
de banda, sobre todo cuando se utiliza la tcnica Unicast la cual entrega un
stream distinto a cada usuario. Por ello hay que tener en claro su funcionamiento y
los aspectos tcnicos de la codificacin del sonido y el video en un contenido
multimedia [3].

1.1.1.1. Codificacin de Audio:
El sonido es una onda generada por la perturbacin de la presin en el
ambiente (onda de presin). Los humanos omos sonidos entre 8 y 20 [Khz.].
26
Hay que tener en cuenta que el micrfono es el traductor de sonido a seal
elctrica, cuya seal es discretizada en tiempo y en amplitud.

Figura 1.3.: Transformacin de ondas de presin a seal discretizada.

Podemos reducir datos si el muestreo reduce: para voz basta 8KHz, para
nuestro rango audible se usa 44.1KHz. Manejamos slo valores discretos para
amplitud. Para una buena calidad de voz 8.192 niveles (2
13
) son suficientes. Si
el salto discreto lo hacemos pequeo para valores pequeos y grande para
mayores, el nmero de niveles se puede reducir a 256 niveles (8 bits) por
muestra. Se consigue as un error de cuantizacin parejo para todo el rango
[4].

Figura 1.4.: Nivelacin del error de cuantizacin.

27
A continuacin se muestra el proceso de transformacin de ondas de
presin a paquetes. ste proceso es importante, ya que se debe entender la
estructura que adopta la informacin de audio, que posteriormente ser
decodificada y descomprimida a travs de un CODEC.

Figura 1.5.: Proceso de transformacin de las ondas de presin a paquetes.
El proceso inverso, el paso de paquetes a ondas de presin se mencionar,
para as tener en claro el funcionamiento de la descodificacin de los paquetes,
generando el sonido en la tarjeta de sonido.
28

Figura 1.6.: Proceso de transformacin de paquetes a las ondas de presin.

Una vez que cada muestra de sonido es digitalizada, se acumula entre 20 a
40 ms de voz (160 a 320 muestras), se comprimen y estructura un paquete
para su transmisin. La compresin es la eliminacin de redundancia y
eventualmente informacin poco relevante. El objetivo de ste proceso es el
de reducir el consumo de ancho de banda o almacenamiento. El silencio es
redundancia por lo que no se transmite.

Figura 1.7.: Ejemplo de una seal con silencio.

Como se ve en la figura, en el patrn de sonido, se ve grandes cantidades
de silencio, ocupando una gran cantidad de datos adicionales en la
29
digitalizacin del sonido, por lo que es fundamental que en el proceso de
codificacin y compresin sea eliminada.
Existen ideas usadas en compresin, de las cuales dos estrategias son
principalmente utilizadas en el Streaming: codificar la forma de onda y
modelar el tracto bucal. En lugar de enviar cada muestra codificada, enviar
slo las diferencias que al ser menores se pueden representar con menos bits.
Usando las muestras previas predecir la siguiente y enviar la diferencia entre
la prediccin y la seal real (ADPCM Adaptive Differential Pulse Code
Modulation).

Figura 1.8.: Ejemplo de modulacin ADPCM.

Descomponer la seal como la suma de un conjunto de frecuencias
preestablecidas y enviar la amplitud de cada una de ellas (Sub-Band Adaptive
Differential Pulse Code Modulation o SB-ADPCM). Modelar analticamente
el tracto bucal y enviar los parmetros que mejor se ajustan el modelo al trozo
de seal. Similar al anterior enviando tambin la seal de error entre lo
obtenido con el modelo y lo real. Como se menciono anteriormente, en el
proceso de codificacin, se elimina el silencio en las tramas de audio, lo que
conlleva a una perdida en la continuidad en el tiempo y perdida en la sincrona
con el video. Es por ello que existen marcas de tiempo en la codificacin. Es
30
decir que el sonido es una seal continua, por lo que si cada muestra es
recibida podremos mantener la relacin temporal del contenido. Sin embargo,
la eliminacin del silencio, la prdida de paquetes y la necesidad de
sincronizacin con otros medios obligan incorporar marcas de tiempo en cada
paquete para su posterior reproduccin en forma sincronizada. Las marcas de
tiempo permiten tambin estimar las variaciones de retardo en la red y ajustar
el retardo de reproduccin.
Como es habitual en las redes pueden producirse colisiones de los
paquetes que llevan el contenido multimedia, o se puede generar un retardo de
los paquetes para que lleguen a su destino. Para hacer frente a las pedidas y
retardos, se iguala la carga usando un buffer con informacin redundante,
utilizndolo como colchn. Bsicamente se disminuye la carencia, al agregar
redundancia inteligentemente. Tambin se realizan retransmisiones (TCP) que
slo son posibles en casos no interactivos ya que en la mayora de los casos
usamos UDP. Adicionalmente se podra usar cdigos correctores por ejemplo
cada n paquetes enviar uno de paridad de los n primeros y en cada paquete
enviar una versin de menor calidad del anterior.

Figura 1.9.: Esquema de el almacenamiento en buffer.
31


Figura 1.10.: Esquema de la entrega desde el buffer al player.

Para entender el proceso de codificacin, se deben tener en claro las
funciones que realiza el protocolo RTP (ser explicado en profundidad ms
adelante). RTP es un protocolo que estandariza el formato de los paquetes de
contenido multimedia en Internet (audio, video y otros). Adems ofrece
servicio, como los de identificacin del tipo de contenido de los paquetes,
indicar nmeros de secuencia, marcas de tiempo entre otras. El proceso de
codificacin del audio es realmente importante para aminorar la utilizacin de
ancho de banda innecesario, por lo que hay que tenerlo bien en claro. A
continuacin se mostrara a modo de resumen el proceso de codificacin de
audio, tanto en el emisor como en el receptor.

32
Figura 1.11.: Proceso de Codificacin por parte del Receptor.

Figura 1.12.: Proceso de Decodificacin por parte del Transmisor.

1.1.1.2. Codificacin de Video:
Los humanos vemos en forma continua la luz reflejada por los
objetos, crendose los colores segn la forma que stos tengan para reflejarla.
El video realiza algo parecido, pero captando secuencias discretas de
imgenes, las cuales observndolas una tras la otra en forma rpida, producen
la sensacin de movimiento. Si proviene de una cmara grabadora (No
webcam), sta genera 30 cuadros por segundo en formato NTSC. La tarjeta
muestrea y obtiene las componentes de luminancia y crominancia para cada
pxel. Las resoluciones son tpicamente mltiplos o sub-mltiplos de 320x240
para NTSC.
33

Figura 1.13.: Proceso de Codificacin del Video.
El proceso de codificacin es parecido a la codificacin del audio, ya que
las imgenes que son capturadas son convertidas a otro formato, siendo
digitalizadas para su compresin y armado de paquetes, para su posterior
transmisin. El ojo humano distingue mejor la intensidad de la luz o brillo que
el color, por ello cada cuadro es almacenado con 1/4 de la resolucin para
cada componente de color.

Figura 1.14.: Proceso de Eliminacin de Redundancia de la Imagen del
Video.

Para poder comprimir las imgenes, se trata de eliminar la redundancia y
aquello imperceptible para el ojo. Los tipo de redundancia existentes son
Espacial: como con imgenes hay zonas regulares, Temporal: cuadros
34
seguidos son parecidos y Psicovisual: no vemos los detalles. Los pasos en la
compresin son los siguientes:

Figura 1.15.: Proceso de Compresin de cada Imagen del Video.

No necesitamos 30 frames por segundo por lo que 10 puede bastar. En
muchos casos resoluciones de 320*240 basta. Cada cuadro o frame se
subdivide en cuadrados de 8x8 pxeles. Como notamos mas los valores
promedios que los detalles, stos son codificados con mayor precisin, los
detalles con menor precisin son eliminados. Se toman diferencias del
cuadrado con respecto al cuadro anterior. Como la imagen se pudo correr, se
busca el cuadro en un entorno (prediccin del movimiento). Cada cuadro no
cabe en un paquete, entonces se agrupan varios rectngulos autnomos.
35

Figura 1.16.: Agrupacin en Cuadros de una Imagen a Comprimir.

Como hay prdida de paquetes debemos enviar cada cierto tiempo cuadros
comprimidos como imgenes.

Figura 1.17.: Envo sucesivo de Paquetes Comprimidos de una Imagen.

36
El Receptor bsicamente hace la operacin inversa del proceso de
codificacin descrito anteriormente. El despliegue se hace en el monitor
(RGB) por ello se ocupa mucha CPU en la descompresin y el cambio de
formato de cada pxel. Hay alto movimiento de datos en los buses internos del
computador que pueden frenar el sistema. El audio generalmente debe esperar
al video para reproduccin sincrnica [5].

1.1.1.3. CODECs utilizados por los Sistemas de Streaming:
El audio y el video se almacenan en las computadoras en forma de
archivos. Debido a que la informacin digital audiovisual es un gran negocio,
hoy se torna una necesidad almacenar cada minuto de audio y video en
diferentes soportes; desde discos duros hasta CD-ROMs. Este almacenamiento
debe ser inteligente. Como vimos en los tems anteriores no se trata nada
ms de copiar/capturar el material desde una unidad reproductora o emisora de
seal (video casetera, lectora de DVD, lectora de CD, videocmara): tambin
necesitamos "comprimir".
Un archivo de audio consiste en un "array" de nmeros. Un array es una
matriz de datos, todos del mismo tipo, posicionados desde cero por un entero.
Cada uno de estos nmeros representa el volumen y la frecuencia de sonido en
un instante de tiempo. Puestos todos estos nmeros juntos y ejecutados por el
reproductor apropiado, generarn un flujo cambiante de frecuencias y
volmenes que sern entonces voz, msica o efectos de sonido. Los archivos
37
de video se comportan de manera similar, aunque utilizan los nmeros para
definir colores, brillo, contraste o coordenadas de cada parte de la cambiante
serie de cuadros (frames) que componen una pelcula o secuencia de
imgenes.
La compresin digital del audio y del video se realiza de diferentes
maneras. Al almacenar o leer un archivo de 'media' se aplican frmulas
matemticas. Parte de estas frmulas resuelven la compresin o
descompresin de un archivo. Precisamente al software desarrollado en base a
estas frmulas matemticas de compresin se le denomina CODEC (por
COmpresor y DECompresor) [6].
Regularmente un CODEC es asociado a un formato de archivo en
particular, pero un formato de archivo puede trabajar con ms de un tipo de
CODEC.
Mientras que algunos CODECs se basan en frmulas matemticas
estndar, otros nuevos son creados en base a nuevos conceptos de compresin.
Es importante conocer qu CODEC tiene instalado en su PC para poder
reproducir archivos de audio y video comprimidos. Es posible que en alguna
ocasin Usted haya intentado leer un archivo y su sistema operativo haya
respondido con un error o con un aviso de que el CODEC necesario para leer
ese archivo est ausente. Ms adelante veremos las caractersticas tcnicas de
los CODECs ms populares.
Los programadores experimentan constantemente con nuevas frmulas y
tcnicas de compresin de audio y de video. En particular es interesante la
38
compresin del audio, porque varias frecuencias de la msica pueden ser
eliminadas sin que el oyente lo tome en cuenta. Por ejemplo, si en una pieza
de msica predominan los tambores y tonos bajos se pueden recortar las
frecuencias altas y nunca se sabr lo que se est perdiendo; o si un pasaje en
particular posee en su mayora notas altas, Usted puede eliminar las
frecuencias ms bajas. Como regla general se eliminan aquellas frecuencias
que el sistema auditivo humano no puede captar.
En el video el desarrollo de las frmulas de compresin se enfoca en
optimizar la reduccin de la cantidad de colores. El ojo humano es ms fcil
de complacer que el odo: nuestra visin puede contentarse con una imagen de
escasos 256 colores. Esta dosis de color es suficiente para delinear formas,
contrastes, brillos y gamas con una definicin que es aceptada de buen grado
por nuestra interpretacin visual. Ms an: por ejemplo, un silencio o
distorsin en un sonido es detectado con facilidad, mientras que nuestra vista,
ante una secuencia de imgenes incompleta o distorsionada en alguna de sus
reas, suele auto completar las piezas de informacin visual perdidas.
As es que analizando un sonido o una secuencia de imgenes
cuidadosamente la frmula de un CODEC puede ser muy eficiente al reducir
el tamao de un archivo.
Los CODECs se actualizan con el tiempo y utilizan una variedad de
tcnicas para obtener la mejor compresin posible de un archivo. A modo de
introduccin se da a conocer algunos aspectos relevantes [6]:
39
- Las tarjetas para captura de video aparecen desde hace ms de una dcada, los
primeros formatos fueron: Mov, Avi, Tga, Fli, entre otros. El formato AVI se
convierte en el estndar pero al igual que los dems formatos requiere de
grandes volmenes de almacenamiento (utilizan codecs Intel-Indeo, Cinepak).
- MOV se convierte en el formato compatible para diversas plataformas (Mac,
Windows, Linux).
- Ms tarde aparece el formato MPEG original, usado para Video-CD que
aportan una duracin de 60 minutos de video en 650 MB.
- MPEG-2 se utiliza principalmente para los DVDs (archivos con extensin
VOB), y alcanza el doble de resolucin, as como un mayor nivel de
compresin.
- Surge el MPEG-1 Layer 3 o MP3, que es lo mismo pero aplicado al sonido,
comprimindolo de tal manera que un minuto de audio de alta calidad ocupa
aproximadamente 1 Mb.
- Microsoft crea el cdec MPEG-4, que con la misma calidad de MPEG-2
comprime el video de forma sorprendente. Desde hardware (capturadoras,
cmaras digitales) se puede alcanzar 1 hora de video en 64 MB. Existen 4
versiones de MPEG-4.
- En la comunidad Linux, dos programadores de Francia, derribaron la
proteccin del cdec MPEG-4 y lo mejoran apropiadamente para que
cualquier tipo de usuario pueda disponer de l (licencia GNU). El nombre de
esta remake del MPEG-4 se conoce como: Div-X.
40
- Div-X se compone de dos cdecs: Fast-Motion y Low-Motion. El cdec
Fast ofrece mayor compresin pero menor calidad de imagen (muy
aceptable). Fast-Motion permite grabar hasta 200 minutos de video de muy
buena calidad (320x240 pxeles, 32 bits de color, 25 fps, audio dolby digital)
en un slo CD. Enfocado para animaciones por computadora. Low-Motion es
el propio para grabar pelculas.
- Div-X (MPEG-4) parte de la siguiente idea: de un cuadro a otro, la diferencia
es mnima. A la hora de capturar los frames, Div-X distingue dos tipos de
ellos: keyframes, y delta frames. Los keyframes son fotos o cuadros completos
que se seleccionan en funcin de un intervalo de tiempo. A partir de cada
keyframe, los cuadros que se graban a continuacin no se capturan completos,
slo se capturan aquellos pxel que cambian, logrando ocupar menos espacio.
- Compresin para Web, con formatos WMV y ASF (visibles slo para Media
Player) se logra rebasar la barrera del MB: 1 minuto de video en
aproximadamente 1 MB. Propiedades Video: 320x240, 16 bits de color, 15
fps; Audio: 16 SS, mono, 8 bits.
- RealNetworks RealAudio y RealVideo, son los codecs utilizados por
los programas entregados por RealNetworks, entre las extensiones que utilizan
sus archivos son .ra, .ram, .rm, .rmm . stos son creados con una alta taza
de comprensin y algoritmos especiales que reducen considerablemente el
tamao de de los archivos de sonido y video. No tan famoso como el MP3 su
capacidad de streaming lo hace ideal para trasmitirse en vivo a travs de la
red.
41
1.2. Tipos de servicios de Streaming.
Los sistemas de Streaming se pueden clasificar en funcin del tipo de servicio que
ofrecen a los usuarios. La principal caracterstica que distingue al servicio de
Streaming, es la capacidad de interaccin y eleccin de los usuarios a la hora de
escoger qu contenido y cundo lo quiere reproducir, aunque para la emisin de
un canal de televisin en vivo, sta afirmacin no se aplica. Teniendo en cuenta ste
parmetro los posibles servicios que puede ofrecer un sistema de Streaming son: En
directo (live) similar a un canal de televisin, bajo demanda (on-demand) similar a
un reproductor de vdeo y casi bajo demanda, que simula el funcionamiento de un
servicio bajo demanda con flujos de vdeo en directo. El tipo de servicio ofrecido es
un parmetro importante en el diseo, ya que a medida que se aumenta la
interactividad del usuario tambin se incrementa la complejidad del sistema de
Streaming y por lo tanto, el valor agregado del servicio ofrecido a los usuarios.

1.2.1. En directo (live):
Est orientado a la multidifusin, siendo ste tipo de servicio el primordial
para la emisin en directo de un canal de televisin. El servidor comienza a transmitir
en un instante dado y los usuarios se conectan y ven la informacin que se est
emitiendo en ese instante. En este tipo de servicio no existe interactividad, o sea que
el usuario no puede adelantar o rebobinar, nicamente est permitido realizar pausas y
cuando el usuario recupere la reproduccin podr ver la informacin que se est
42
transmitiendo en ese instante [7]. A continuacin se ejemplifica el proceso de emisin
en directo:

Figura 1.18.: Proceso de una Emisin en Directo.

Las seales en vivo se pueden clasificar funcin de la fuente:
i. Segn el origen de las seales de A/V: La transmisin puede ser con informacin
en vivo, o con informacin almacenada:

Figura 1.19.: Clasificacin de Seales en Vivo segn su Fuente.
43

ii. Segn el tipo de transmisin: La transmisin puede ser orientada a uno o a
muchos usuarios, existiendo 3 tipos de transmisin:
- Transmisin Unicast: Consiste en la transmisin dedicada a cada usuario, o sea que
se envan distintos flujos de streams a distintos usuarios por igual, dividiendo el ancho
de banda entre ellos.
- Transmisin Multicast: Consiste en la transmisin por igual a un grupo usuarios,
enviando el stream por la red a todos los usuarios que pertenezcan a aquel grupo y
que deseen tomarla.
- Transmisin Broadcast: Consiste en la transmisin por igual a todos los usuarios,
enviando el stream por la red a todos los usuarios que pertenezcan a aquel a la red y
que deseen tomarla.

Figura 1.20.: Clasificacin de Seales en Vivo segn el Tipo de Transmisin.

Estos tipos de transmisin sern detallados en captulos posteriores.
1.2.2. Bajo demanda (on-demand):
En tipo de servicio los usuarios solicitan el envo de informacin en el
instante que lo deseen, siendo sta informacin personalizada para cada usuario,
44
siendo la base de la televisin interactiva [7]. Existen diversos tipos de
interacciones:
i. Pausas: Despus de la pausa la reproduccin se retoma en el punto donde se
dej.
ii. Saltos hacia delante: Es posible posicionarse en una zona ms adelantada
de la localizacin actual.
iii. Saltos hacia atrs: Es posible volver a visualizar zonas anteriores.

Figura 1.21.: Proceso de Transmisin Bajo Demanda.

1.2.3. Casi bajo demanda:
ste servicio simula el funcionamiento del vdeo bajo demanda mediante
flujos de vdeo en directo, siempre con informacin almacenada. Cuando llega un
cliente, se le incorpora al flujo que comienza (posiblemente tenga que esperar un
pequeo intervalo de tiempo). Cuando realiza una interaccin, se le incorpora al
flujo que emite en la posicin ms cercana a la que solicita, cuando los flujos
45
acaban la emisin, comienzan a transmitir otra vez por el principio (se realiza una
emisin continua). Se utiliza para tratar de aprovechar las caractersticas de una
emisin multicast [7].

Figura 1.22.: Proceso de Transmisin Casi Bajo Demanda.

1.3. Componentes de un sistema de Streaming.
Los sistema de Streaming estn compuestos por tres componentes bsicos: el
servidor, la red de transmisin y los usuarios del sistema .A continuacin
describiremos la funcionalidad de cada uno de estos componentes [8].

Figura 1.23.: Componentes de un Sistema de Streaming.

1.3.1. Servidor de Streaming:
46
El servidor de video almacena los contenidos que pueden ser solicitados por
los usuarios. Es el encargado de gestionar el servicio a los clientes, garantizando
una cierta calidad de servicio a lo largo del camino que tiene que seguir la
informacin desde el disco hasta los usuarios. Un servidor de Streaming est
compuesto por tres subsistemas: El subsistema de control, el subsistema de
almacenamiento y el subsistema de comunicacin.
i. Subsistema de control: El subsistema de control es el encargado de
recibir las peticiones de los usuarios y ordenar las acciones que se tienen que
llevar a cabo para poder atenderlas. Este mdulo debe decidir si la nueva
peticin puede ser servida por el sistema sin que ello implique un deterioro de
las peticiones activas. Estas decisiones son tomadas por la poltica de control
de admisin en funcin de los recursos disponibles en el sistema y de los
requisitos de la nueva peticin. Otras funciones del mdulo de control son la
gestin de las estadsticas de utilizacin del sistema (contabilidad y
facturacin) y realizacin de tareas de optimizacin para incrementar la
eficiencia del sistema.
ii. El subsistema de almacenamiento: Este mdulo es el responsable de
almacenar y recuperar la informacin multimedia desde los dispositivos de
almacenamiento. Las principales dificultades a la hora de conseguir este
objetivo estriban en el volumen de informacin que se debe gestionar y que
sta debe ser entregada de acuerdo a las estrictas especificaciones de la calidad
de servicio Streaming requeridas por las aplicaciones de video bajo demanda.
47
iii. El subsistema de entrega de comunicacin: Es el encargado de planificar
la inyeccin de los contenidos multimedia en la red de transmisin. Este
mdulo se encarga de gestionar las distintas polticas de servicio que permiten
optimizar los recursos de ancho de banda de la red y del servidor.


1.3.2. Red de comunicacin:
Uno de los principales factores que ms han influenciado en el crecimiento
de las aplicaciones multimedia es el crecimiento de la red de interconexin. Para
permitir a los usuarios acceder a los contenidos multimedia, las redes deben
satisfacer al menos dos requisitos: Disponer de mecanismos de transporte para
enviar las peticiones y los datos y permitir que la informacin sea transmitida
respetando niveles mnimos de rendimiento (calidad de servicio).
La red de comunicacin de un sistema de Streaming se caracteriza por unos
elevados requisitos de ancho de banda (capacidad de transferencia de grandes
volmenes de datos) y grandes velocidades de transmisin. En un sistema
Streaming, podemos llegar a encontrar tres niveles de red diferentes: la red
principal, la red troncal y las redes locales. Ahora bien, dependiendo de la
arquitectura del sistema dos niveles (red principal y red troncal) [9].
La red principal es aquella a la cual se conectan los servidores de Streaming y
sirve punto de conexin de stos con la red de distribucin (red troncal) de los
contenidos multimedia a los usuarios. La red troncal ( backbone) permite
48
interconectar la red principal con cada una de las redes de distribucin locales (en
caso de que stas existan) bien directamente con los usuarios.
Su objetivo es transportar, tan rpido como sea posible, la informacin generada
por los servidores desde la red principal a los usuarios.
Las redes locales son las responsables de la conexin final de los usuarios al
sistema de Streaming. Esta red requiere un ancho de banda inferior respecto a los
otros niveles. El trfico soportado por las redes de usuario tiene una naturaleza
asimtrica, lo cual significa que se necesita un ancho de banda de entrada
considerablemente mayor al trfico de salida.

1.3.3. Clientes:
Los usuarios deben soportar la recepcin y la visualizacin sin cortes de los
contenidos multimedia, as como soportar los comandos VCR. La interfase entre
los usuarios y el sistema de Streaming se realiza mediante el Player. Este mdulo
es el encargado de recibir los comandos del usuario y enviar la seal al servidor a
travs de la interfase de red.
El Player almacena los contenidos recibidos desde el servidor en unos buffers
locales, decodifica los contenidos recibidos en tiempo real y enva las imgenes
obtenidas a la pantalla de visualizacin, con la temporizacin correcta.
En general los Streaming constan de 4 componentes principales: Interfase de red,
decodificador, buffer y hardware de sincronizacin.
49
i. Interfase de red: Permite al cliente recibir y enviar informacin desde
hacia los servidores.
ii. Decodificador: Para reducir los requisitos de almacenamiento, ancho de
banda de disco y ancho de banda de red, los contenidos multimedia suelen
estar codificados. As se necesita un decodificador en el lugar del cliente para
decodificar el video antes de ser presentado al usuario.
iii. Buffer: Debido a los retrasos introducidos por la red, el tiempo de llegada
de la informacin (video) no puede ser determinado con exactitud. Para
conseguir una reproduccin sin cortes, el servidor debe garantizar que el
siguiente trozo del video que se va a visualizar, est disponible antes que el
usuario lo requiera. Para lograr este objetivo, el servidor enva datos al usuario
en adelanto, de forma que se asegure un margen de tiempo que minimice los
posibles retardos inesperados introducidos por la red de comunicacin. Como
el usuario no va a consumir inmediatamente estos datos, estos se tienen que
almacenar temporalmente en un buffer hasta que sean requeridos.
iv. Hardware de sincronizacin: Los videos estn compuestos por un stream
de video y un stream de audio independientes. Para poder realizar un
reproduccin correcta, ambos tipos de informacin deben ser sincronizados
entre si antes de que puedan ser reproducidos.
El desarrollo de los Player mantiene una continua evolucin, no solo enfocada
a reducir su costo sino tambin a incrementar su potencia debido al rpido
desarrollo tecnolgico de la industria de ordenadores. Mientras las recientes
generaciones de Player estn bastante limitadas con respeto a la funcionalidad
50
y a la capacidad, la actual tendencia intenta sobrepasar el mero rol de receptor
y decodificador de video, convirtindolo en un verdadero centro de
entretenimiento familiar, e incrementando su capacidad de almacenamiento y
de procesamiento.

1.4. Requisitos de un Sistema de Streaming.
La funcionalidad requerida de un sistema de Streaming as como las
caractersticas de la informacin gestionada por stos, imposibilita la utilizacin
de servidores genricos. Por lo tanto, los servidores de Streaming deben ser
diseados teniendo en cuenta una serie de requisitos especficos del tipo de
informacin gestionada. El servicio de una peticin para un contenido multimedia
requiere un elevado volumen de informacin, con requerimientos de tiempo real,
mantenimiento de la calidad de servicio (QoS) y grandes anchos de banda de
transferencia del sistema de almacenamiento y la red de comunicaciones [9]. El
conjunto de todos estos requisitos complica el diseo e implementacin de los
sistemas de Streaming y limita considerablemente el nmero de usuarios que
puede soportar un servidor de Streaming. A continuacin se describen brevemente
cada uno de estos requisitos.
i. Gran capacidad de almacenamiento: Dada la naturaleza intensiva en
almacenamiento de la informacin multimedia, los requisitos de
almacenamiento globales de cientos de contenidos multimedia puede exceder
fcilmente un requisito de disco de decenas de Terabytes. Por ejemplo, un
51
video en formato de televisin de alta definicin (HDTV) de dos horas de
duracin puede requerir hasta 18 Gigabytes. Por lo tanto, un sistema de
Streaming compuesto de 200 videos puede requerir aproximadamente unos
3.6 Terabytes de almacenamiento.
ii. Servicio en tiempo real: Para garantizar la reproduccin continua de los
contenidos multimedia, no es suficiente con que el servidor de Streaming
enve los datos al usuario y ste los reciba correctamente; sino que esta
recepcin se debe producir dentro un intervalo de tiempo especfico. Esto
implica que todos los componentes del sistema deben tener un control del
tiempo mximo permitido para poder realizar cada uno de las operaciones que
intervienen en la entrega de informacin a los usuarios. Adems, los distintos
componentes que intervienen en el sistema se tienen que sincronizar entre s
para no violar estos requisitos de tiempo. Si esta sincronizacin no se lleva a
cabo es imposible garantizar una calidad de servicio al usuario final. Es
posible suavizar los requisitos en tiempo real de los sistemas de Streaming
mediante la utilizacin de buffers intermedios tanto en el servidor como en el
cliente y el envo en adelanto de un fragmento del contenido multimedia.
iii. Calidad de servicio (QoS): Un aspecto clave en cualquier servicio de
vdeo es proporcionar una calidad de servicio (QoS) aceptable al usuario.
Debido a la naturaleza continua e independiente del tiempo de los contenidos
de audio y video, su reproduccin requiere un estricto control del momento y
la secuencia de recepcin de la informacin por parte del usuario. Esta calidad
de servicio generalmente implica varios aspectos tales como: calidad de la
52
imagen, frecuencia de perdida de imgenes, sincronizacin audio y vdeo,
entre otros. Algunos de estos parmetros no son fcilmente cuantificables
porque dependen de la percepcin subjetiva del observador. La calidad de
servicio a nivel del usuario refleja como se suministra el flujo de vdeo
original desde un servidor de vdeo remoto. Estos servicios requieren
restricciones especficas en el flujo de informacin desde el servidor al cliente.
Por lo tanto, una cuestin importante en Streaming es como lograr una
correspondencia entre la QoS especfica requerida por el cliente con la
especificacin de una QoS para el servidor de vdeo y la red de transmisin.
Con el objetivo de conseguir unas prestaciones en el sistema que garanticen
una QoS aceptable se requiere una fuerte coordinacin entre todos los
componentes del sistema, desde los servidores de ficheros a los dispositivos de
visualizacin pasando por las componentes de red. No es suficiente un anlisis
individual de los componentes del sistema sino que se requiere un diseo
unificado que tenga en cuenta todos los componentes. La QoS basada en el
anlisis de los componentes individuales tropieza con el problema de que los
componentes no son independientes entre si. La solucin ptima para una
componente no garantiza la mejor solucin para todo el sistema y por lo tanto,
se requiere un anlisis integrado.
iv. Grandes anchos de banda: Los contenidos multimedia requieren el
procesamiento de un gran volumen de informacin de forma peridica y
durante grandes periodos de tiempo. Este volumen de informacin exige
grandes anchos de banda en la red de transmisin. Los requisitos de ancho de
53
banda no se circunscriben exclusivamente a la red de comunicaciones entre el
servidor de Streaming y los usuarios finales, sino que tambin involucran al
sistema de almacenamiento. Esto implica la utilizacin de sistemas de
almacenamiento complejos basados en sistemas de almacenamiento
jerrquicos bien la utilizacin de un conjunto de discos en configuracin
RAID. Es importante hacer notar que si no se tiene en cuenta este parmetro
en el diseo del sistema de Streaming, un incremento en el nmero de
peticiones a gestionar por el sistema, puede aumentar los requisitos de ancho
de banda hasta llegar a saturar el sistema de Streaming.



1.5. Formatos de Archivos de Streaming.
Vamos a ver cuales son las caractersticas de diferentes formatos de "meta
archivos" y de archivos de audio y video, la lista de formatos no es exhaustiva.
Solo trataremos los formatos de uso ms populares en los servicios de Streaming y
en aplicaciones multimedia [10].

1.5.1. Metafiles Metaarchivos:
META es una palabra griega que significa "prximo" o "cercano". Un meta-
archivo o meta-file es un tipo especial de archivo que describe o brinda ms
informacin acerca de otro archivo. Los METAARCHIVOS o METAFILES son
54
archivos de texto que utilizan XML (Extended Markup Language) para definir
tipos de informacin especficos. Los metafiles proveen varias maneras de hacer
ms eficiente el funcionamiento de un Player. Algunas de las extensiones ms
populares:
i. Windows Media:
- ASX: Contienen informacin acerca de archivos ASF. La extensin ASF fue
usada para archivos de audio y video por versiones anteriores a la actual de
Windows Media.
- WAX: Contienen informacin acerca de archivos de audio. Cuando Usted
graba una lista de ejecucin de archivos de audio (playlist) Windows Media
Player utiliza este formato.
- WVX: Contienen informacin acerca de archivos de video. Cuando Usted
graba una lista de ejecucin de archivos de video (playlist) Windows Media
Player utiliza este formato.
ii. Real:
- RAM/RPM: Contienen informacin acerca de archivos RM que pueden ser
tanto de audio como de video o ambos.
El uso ms corriente de los metafiles es el de archivo para lectura y escritura
de "playlists" en el disco duro. Un archivo PLAYLIST contiene una lista de
directivas que el reproductor de audio/video debe ejecutar en el orden y forma que
55
este archivo (playlist) le indique. Las acciones o aplicaciones ms comunes de un
playlist son:
- Vincular contenidos multimedia para enriquecer una presentacin.
- Insertar publicidad (grficos, audio, video) en la pantalla principal del
reproductor, entre los archivos de contenido principales (como si se tratara de
cortes comerciales de televisin); o insertar publicidad en reas especficas de la
pantalla del reproductor o pgina Web -si el archivo estuviera incrustado en el
documento HTML- mientras se ejecuta el archivo de audio / video (los
comerciales pueden contener enlaces hacia pginas Web o direcciones de
email).
- Titular o subtitular archivos de video: til para la traduccin del contenido
audiovisual (un meta-file puede incluso permitirle al usuario seleccionar el
idioma), para personas con discapacidad auditiva o para resaltar secciones en un
archivo de audio o destacar escenas en un archivo de video.
- Enviar notificaciones o comunicados en streaming media: por ejemplo, en un
evento que ser transmitido en vivo, un meta-file puede especificar cuando y en
que canal tomar lugar la transmisin; as el reproductor puede comenzar a
recibirla en el momento debido.
Un playlist puede ser enviado por email o estar alojado en un servidor para
descargarlo a pedido.
1.5.2. Archivos de Audio:
56
i. Windows Media:
- ASF: Este formato fue usado en versiones previas de Windows Media.
- WMA
Ambos formatos poseen informacin idntica excepto que el segundo
formato es solo de audio, mientras que el primero puede contener informacin
de audio y de video.
ii. Real:
- RM
- RA: Este formato fue usado en versiones previas de Real.
Ambos formatos poseen informacin idntica excepto que el segundo
formato es solo de audio, mientras que el primero puede contener informacin
de audio y de video.
iii. Microsoft Windows:
- WAV: Formato nativo de ese sistema operativo.
iv. Apple Macintosh:
- AIFF: El formato de intercambio de audio o "Audio Interchange File
Format" es uno de los ms populares de Apple Macintosh. Este formato utiliza
las extensiones .AIF, .AIFC y .AIFF
57
v. Unix:
- AU: Este formato utiliza la extensin .AU. El formato .SND es muy similar.
Ambos son populares en UNIX y computadores tipo Unix.
vi. Audio MPEG:
- MP3: Los archivos MP3 son creados de acuerdo con el estndar del Grupo
de Expertos en Imgenes en Movimiento o "Moving Picture Experts Group"
(MPEG), conocido como LAYER 3. Este formato utiliza las extensiones .MP3
o .M3U.


1.5.3. Archivos de Video:
i. Windows Media:
- ASF: Este formato fue usado en versiones previas de Windows Media.
- WMV
Ambos formatos poseen informacin idntica excepto que el segundo
formato es solo de video, mientras que el primero puede contener informacin
de audio y de video.
58
ii. Real:
- RM
iii. Microsoft Windows:
- AVI: Formato nativo de ese sistema operativo. Contiene informacin de
audio y de video.
iv. Video MPEG:
El video creado bajo las especificaciones del Grupo de Expertos en
Imgenes en Movimiento o Moving Picture Experts Group (MPEG) puede
tener las siguientes extensiones de archivo:
- MPG
- MPEG
- MPE
- M1V
- MP2
- MPA
- MPE
v. Apple Macintosh:
- MOV: Es uno de los ms populares de Apple Macintosh. Este formato
utiliza tambin las extensiones .MOV, .QT.
59
vi. Indeo:
- IVF: Indeo ha sido adquirido recientemente por Ligos Technology.



















60









CAPITULO II













61
2. Polticas de gestin de los Servidores de Streaming.
Para que un servidor pueda efectuar sus funciones, ste debe realizar una secuencia
de tareas peridicas cada una de ellas sujetas a una estricta temporizacin de forma que se
garantice un flujo de informacin continuo a lo largo de todo el camino de servicio que
debe seguir la peticin. Este camino de servicio se inicia en el subsistema de
almacenamiento, pasando por el subsistema de inyeccin en la red que se encarga de enviar
los contenidos multimedia a los clientes a travs de la red de comunicacin.
A continuacin se muestran los distintos mdulos que componen un servidor de
Streaming: el mdulo de control de admisin, los planificadores de disco y de red y el
gestor del almacenamiento. Las funciones realizadas por cada uno de estos mdulos y
algunas de sus polticas ms significativas se comentan en los siguientes apartados.

62
Figura 2.1.: Mdulos que Componen un Sistema de Streaming.
2.1. Control de Recursos:
Para garantizar que los nuevos clientes disponen de un servicio continuo y
asegurar que la calidad de servicio asignada a las conexiones existentes se mantiene, el
servidor debe garantizar que dispone de suficientes recursos (ancho de banda de E/S de
disco, buffers de memoria, ancho de banda de procesamiento y ancho de banda de red)
antes de admitir una nueva peticin. La toma de la decisin de si una peticin se puede
no servir con los recursos actualmente disponibles, recae bajo la responsabilidad del
mdulo de control de admisin del servidor.
Antes de admitir una nueva peticin, un conjunto de parmetros de QoS son
transmitidos por el usuario para que sean comprobados por el servidor. Si esta calidad
de servicio pedida no puede ser soportada, la peticin ser denegada alternativamente,
se establecer un proceso de negociacin entre el servidor y el usuario para reducir los
requisitos solicitados.
El algoritmo de control de admisin debe disponer de conocimientos sobre la
capacidad del subsistema de almacenamiento y la poltica de servicio activa de forma
que se pueda evaluar adecuadamente el volumen de recursos requeridos para atender la
nueva peticin (en el caso de que se puedan utilizar polticas de multicast que permitan
reducir el consumo de recursos).
2.2. Planificadores:
En un modelo genrico, el servidor de video se compone de un planificador de
disco y de un planificador de red. El planificador de disco determina cmo y cundo se
63
tienen que transferir desde el subsistema de almacenamiento hasta los buffers
intermedios de memoria. El planificador de red determina cmo y cundo la
informacin se transfiere desde los buffers de memoria a la red, para su transmisin a
los clientes.
i. Planificador de disco:
Para una eficiente utilizacin del ancho de banda de disco, el planificador de
disco se suele organizar en ciclos. En su forma ms sencilla, el esquema basado en
ciclos consiste en que en cada ciclo se planifican y se leen los datos que necesita
transmitir el planificador de red en el siguiente ciclo. El principal motivo para esta
organizacin en ciclos es que permite desligar el orden de transmisin de los datos a
los usuarios del orden de lectura desde los dispositivos de almacenamiento. Al
poder leer los bloques del disco en cualquier orden se puede minimizar los tiempos
de bsqueda (seek) en el disco. El orden de lectura de cada uno de los bloques del
disco en cada uno de los ciclos depender de la poltica concreta que se aplique. Se
pueden utilizar polticas genricas como el SCAN, EDF SCAN-EDF, bien
polticas especficas orientadas a sistemas de tiempo real como GSS (Grouped
Sweeping Scheme).
ii. Planificador de red:
Los dos principales objetivos de las polticas de planificacin
(presuponiendo la correcta recepcin de los usuarios) son simplificar la gestin del
sistema de Streaming (suavizando los requisitos de tiempo real la variabilidad de
la frecuencia de compresin de los contenidos Multimedia) y reducir los recursos
requeridos para servir las peticiones.
64
Una de las tcnicas ms conocidas que permite reducir los requisitos de
ancho de banda, es el smoothing (suavizado). Esta tcnica utiliza el buffer del
cliente para enviarle datos (trozo del video) por adelantado, minimizando la
posibilidad de que el usuario perciba un retardo. El objetivo de estos datos enviados
por adelantado, es permitir que el planificador de red pueda minimizar la
fluctuacin en los requisitos de ancho de banda de red de los contenidos
multimedia.
El prefetching es otra tcnica que intenta enviar datos por adelantado al
servidor, pero en este caso, con el objetivo de reducir los requisitos de tiempo real
del sistema y optimizar los recursos del sistema, aprovechando los periodos de
tiempo en los cuales el sistema est inutilizado.
Para reducir los requisitos de ancho de banda del sistema, el planificador
suele implementar distintas polticas de servicio, algunas de las cuales, comentamos
en el siguiente apartado.

2.3. Polticas de servicio:
Las polticas de servicio son las encargadas de decidir como se deben gestionar
las peticiones de los usuarios y el tipo de servicio que finalmente ofrece el sistema.
Existen tres tipos de categoras de polticas de servicio, en funcin del tipo de
comunicacin utilizada: Unicast (1 a 1), Broadcast (1 a todos) y multicast (1 a n) [11]:

65
i. Unicast: Es la poltica de servicio ms sencilla, ya que se basa en enviar un flujo
de informacin independiente (mediante una transmisin Unicast) para cada una de
las peticiones. La principal ventaja de esta tcnica estriba en que soporta Streaming
verdadero y los comandos del usuario. En el lado negativo, podemos destacar su
poca eficiencia con respecto a la utilizacin de los recursos del sistema y a los
grandes anchos de banda requeridos para servir a un nmero elevado de usuarios.

ii. Broadcast: Esta poltica intenta maximizar la eficiencia de los recursos del
sistema a costa de la interactividad de los usuarios. Se utiliza principalmente para
ofrecer servicios Streaming de bajo costo. Las polticas de Broadcast se basan en las
comunicaciones con el mismo nombre, en las cuales se permite enviar un mismo
flujo de datos a todos los usuarios de una red, de forma indiscriminada. Los
receptores deben decidir si la informacin les interesa o no. Si no es as, entonces
sencillamente descartan la informacin recibida. Lo cual implica que los streams
utilicen ancho de banda de la red, tanto si van a ser utilizados por usuarios como si
ningn usuario los utiliza. Esta caracterstica condiciona la utilizacin de estas
polticas ya que requieren que la informacin que se esta transmitiendo tenga una
alta frecuencia de acceso para obtener un rendimiento acorde con el ancho de banda
utilizado. sta es la principal razn por la cual esta tcnica solo se emplea con
videos cuya popularidad es muy alta. Existen diversas tcnicas de Broadcast, las
cuales se diferencian principalmente en la forma en que se fracciona y se transmite
el contenido multimedia. Los principales parmetros con los que juegan estas
tcnicas son el nmero de streams utilizados en el Broadcast de la pelcula y la
66
frecuencia de transmisin de cada uno de los trozos. La tcnica de Broadcast
Pyramid se basa en la existencia de buffers en los clientes, de forma que puedan
recibir y guardar algunos segmentos del video mientras se visualizan los primeros.
Se transmiten segmentos cada vez ms largos de cada video por canales diferentes.
De esta forma, se divide el ancho de banda del servidor en N canales lgicos y la
pelcula en N segmentos con un tamao que se incrementa geomtricamente.
Debido a que el primer segmento es el ms pequeo su frecuencia de transmisin
ser mayor, lo cual asegura un tiempo de espera considerablemente ms reducido.
El esquema de broadcasting Skyscraper intenta reducir los requerimientos de
ancho de banda y el tamao del buffer del cliente de la tcnica anterior. Se basa en
dividir el ancho de banda disponible en B canales lgicos los cuales se distribuyen
equitativamente entre los M videos. Para transmitir un video sobre sus K canales
dedicados, ste es partido en K fragmentos, los tamaos de los cuales siguen una
determinada serie. Adems de las tcnicas descritas, existen otras alternativas como
Broadcast pagoda Broadcast armnico. Las ltimas tendencias intentan utilizar
conjuntamente tcnicas de broadcast y Unicast para proporcionar servicios de
Streaming verdadero.
iii. Multicast: Mediante las tcnicas de multicast el flujo de informacin solo se
enva (de forma discriminada) a un grupo de usuarios que han pedido los mismos
contenidos. De esta forma, un stream de multicast siempre tiene por lo menos un
destinatario y nunca se malgasta ancho de banda. Esta es la principal razn por la
cual estas tcnicas suelen tener rendimiento ms eficiente que las tcnicas de
67
broadcast. A continuacin vamos a describir algunas de las polticas multicast ms
significativas.
La poltica de batching se basa en retrasar las respuestas (transmisin de los
contenidos) a los usuarios de forma que varias peticiones a un mismo video se
puedan servir utilizando un nico flujo de informacin. La principal ventaja de esta
tcnica estriba en que se permite un considerable ahorro de recursos del sistema
Streaming y que no requiere que el Player del usuario disponga de unas
caractersticas especficas. En su contra est que no puede ofrecer un servicio de
Streaming verdadero y que puede causar la cancelacin de la peticin por parte del
usuario si ste no esta dispuesto a esperar durante ms tiempo por el servicio
solicitado.
La poltica de patching es una de las primeras polticas de multicast que
soporta servicios de Streaming verdadero. Esta poltica se basa en aprovechar los
flujos de informacin que se estn transmitiendo a otros usuarios para reducir los
requisitos de las nuevas peticiones. Cuando el servidor recibe una nueva peticin se
comprueba si existe algn stream que est transmitiendo el mismo contenido y que
est dentro de la ventana de tiempo del buffer del nuevo usuario (el minuto X de la
informacin que se est transmitiendo no tiene que ser mayor que la capacidad del
buffer). Si esta condicin se cumple, el nuevo usuario se aade al canal de
transmisin activo (con lo cual se asegura la recepcin de todo el resto del video, a
partir del minuto X-120, mediante un multicast) y se crea un canal especifico para el
trozo de video que falta (canal de patch parche) de forma que se pueda empezar
inmediatamente la reproduccin del video.
68
Esta poltica tiene una serie de ventajas: el mnimo tiempo de respuesta a los
clientes, que permite expandir el canal de multicast para servir a nuevas peticiones y
que la mayora de los canales de patch son de corta duracin. En contraposicin,
esta tcnica requiere que el Player del usuario disponga de un buffer para guardar
alrededor de 5 minutos de video (tamao normalmente utilizado mediante esta
tcnica) y adems debe poder soportar la recepcin simultanea de al menos dos
canales de transmisin de entrada (canal de patch + canal multicast).
Existen otras tcnicas multicast que permiten crear una estructura jerrquica
de multicast (poltica de merging); que logran la fusin de las peticiones de los
usuarios en un canal multicast incrementando el volumen de informacin enviada al
usuario (piggybacking) bien incrementado el ratio de compresin de los
contenidos enviados (skimming). Con respecto a las polticas de servicio multicast,
otra importante lnea de investigacin actual analiza la influencia de los comandos
de los Player sobre la efectividad de esta poltica.

2.4. Sistema de almacenamiento:
Debido al volumen de informacin gestionado en un sistema de Streaming, el
sistema de almacenamiento puede resultar muy costoso si exclusivamente se utilizan
discos magnticos. Para construir un sistema de Streaming con una buena relacin costo
/ prestaciones resulta lgica la utilizacin de sistemas de almacenamiento hbridos que
combinan dos ms tipos de dispositivos de almacenamiento. Este esquema configura
un sistema jerrquico de almacenamiento constituido por distintos niveles: memoria
69
(formado por los buffers internos del servidor), discos magnticos (para almacenar los
videos con una popularidad media-alta) y los discos pticos (para aquellos contenidos
con la frecuencia de acceso ms bajas). El nmero de peticiones concurrentes que puede
ser gestionado por un nico disco est limitado por su rendimiento, es decir por el
ancho de banda del disco requerido para servir un contenido multimedia. Una
aproximacin que se puede utilizar para solucionar esta limitacin consiste en mantener
mltiples copias de un contenido en diferentes discos, sin embargo esta solucin resulta
cara. Una mejor aproximacin consiste en fraccionar los ficheros multimedia entre
mltiples discos utilizando las tcnicas de striping, interleaving una combinacin de
ambas. La tcnica de striping utiliza la tecnologa RAID (Rendundant Array of
Inexpensive Disks) que permite realizar accesos en paralelo a un array de discos.
Mediante el interleaving, los bloques de un fichero multimedia son almacenados de
forma intercalada a lo largo de un conjunto de discos.










70










CAPITULO III











71
3. Tecnologas de red.
Dado que un sistema de Streaming requiere la transferencia de enormes volmenes
de datos a muy altas velocidades, varios protocolos de comunicacin y arquitecturas de red
han sido propuestos para conectar los distintos componentes del sistema.
Las tecnologas utilizadas varan considerablemente segn el nivel de red que se
considere: red principal y/o red de conexin final con los clientes. Mientras que la red
principal requiere una gran cantidad de ancho de banda, la conexin con los clientes finales
tiene requisitos individuales ms pequeos (con un ancho de banda de red de 1.5 Mb/s es
suficiente para soportar la transmisin de un video en formato MPEG-2).
El criterio ms importante para la seleccin de la tecnologa de la red principal es el
ancho de banda y el soporte de la gestin de la QoS (Calidad de servicio). En este caso,
ATM emerge como la tecnologa ms importante. Otra alternativa, que permite reutilizar la
infraestructura de Internet actual, se basa en la utilizacin de protocolos especficos (RTP,
RTCP, RTSP, RSVP, etc.) para soportar la gestin de la calidad de servicio por encima del
protocolo TCP/IP sobre redes Ethernet.
A continuacin, se describen las distintas alternativas utilizadas en la conexin de
los usuarios y en la red troncal y principal [12].

3.1. Red de usuarios:
La infraestructura de comunicaciones entre el usuario y la red principal del
sistema de Streaming se denomina red de los usuarios. Esta red sirve de lazo de unin
entre el servidor de Streaming y el Player de usuario.
72
Las principales tecnologas que se utilizan en la conexin de los usuarios a la
red troncal de los sistemas de Streaming son ADSL y la fibra ptica / cable.
i. Asymmetrical Digital Subscriber Loop (ADSL): ADSL se basa en la
utilizacin de redes de cables de cobre. Permite la recepcin de datos a altas
velocidades, utilizando la infraestructura telefnica actual y con pocas
distorsiones.
La instalacin de ADSL se compone de un par de unidades, una instalada
en el cliente y la otra en la oficina central de telefnica. ADSL puede proporcionar
al usuario final un ancho de banda de entrada de ms 1.5 Mb/s y un ancho de
banda de salida de 16 Kb/s para control. Extensiones de ADSL (HDSL) pueden
alcanzar un mayor ancho de banda, llegando a los 6 Mb/s. Estas caractersticas
son suficientes para satisfacer los requisitos de ancho de banda y comunicacin
bidireccional de los servicios de Streaming.

Figura 3.1.: Ejemplo aplicaciones de un ADSL.

73
ii. Cable: La distribucin de informacin a travs del cable se basa en la
utilizacin de la tecnologa HCF (Hbybrid Fiber Coaxial) que combina el uso de
fibra ptica junto a cables coaxiales. Estas redes de cable han sido utilizadas
tradicionalmente para la transmisin de seales analgicas por las compaas de
cable de televisin (CATV), pero mediante la utilizacin de mdems tambin
permiten la transmisin de seales digitales.
La topologa utilizada para estos sistemas suele basarse en rboles basados
en fibra, con ramas de cable coaxial, a las cuales se conectan los subscriptores.
El ancho de banda total disponible en las ramas suele ser alrededor de
3482 Mb/s, los cuales se dividen entre los canales de entrada (3480 Mb/s) y
canales de salida (2 Mb/s).

Figura 3.2.: Ejemplo de Red con Cable Coaxial.

74
3.2. Red Principal:
Las principales tecnologas utilizadas en la red principal son redes ATM y redes
basadas en switches fast-ethernet sobre el protocolo TCP/IP.
A continuacin mostramos el nmero mximo de flujos de video que pueden
soportar las distintas tecnologas de red ATM y Ethernet, para los siguientes formatos
de video: Televisin de alta definicin (HDTV), calidad DVD, estndar de televisin
americano y japons (NTSC, Nacional Televisin System Committe), MPEG-1 y
MPEG-4 ( DivX).


Tabla 3.1.: Tabla de Mximos Flujos que pueden soportar Redes ATM.

A partir de la informacin de la figura, se puede deducir que el ancho de banda
de las redes de transmisin es uno de los factores ms importantes a la hora de disear
un sistema de Streaming.
75
Un sistema de Streaming medio, capaz de dar servicio a miles de usuarios
requiere la utilizacin de una infraestructura de red compuesta por varios switches
Ethernet ATM. Hoy en da, las alternativas que ofrecen una mejor relacin
costo/prestaciones son los switches Fast-Ethernet ATM. A continuacin
describimos las caractersticas ms relevantes de cada una de estas tecnologas.
i. Red ATM: ATM es una tcnica de conmutacin y una tecnologa de
multiplexacin que combina los beneficios de la conmutacin de paquetes
(garanta de capacidad y retardo de transmisin constante) con los beneficios de la
multiplexacin de paquetes (flexibilidad y eficiencia para el trfico intermitente).
Esta tcnica de transmisin, est diseada para ser un modo de transferencia
orientada a conexin, de propsito general, para un rango amplio de servicios. La
tcnica de multiplexacin es por divisin asincrnica en el tiempo (ATD). Estas
particulares caractersticas facilitan una solucin razonable para los problemas
propuestos por las restricciones asociado con el trfico de video en tiempo real.
ATM dispone de ciertas caractersticas que la hace especialmente interesante para
los sistemas de Streaming. Es por ello que el objetivo de montar un Sistema de
Streaming con una red ATM, es el de disponer de un mayor ancho de banda para
que los Contenidos Multimedia puedan ser codificados con una mayor calidad (a
distintos niveles de compresin). La utilizacin de una red ATM, se realiza a nivel
local, para as facilitar la comunicacin entre los codificadores y el servidor, sobre
todo cuando las estaciones de radio y televisin estn distribuidas en sucursales
separadas por una distancia considerable (Red WAN).
76
ii. Ethernet: La tecnologa ATM es costosa, por lo que muchas instalaciones de
Streaming han preferido la utilizacin de la infraestructura ms econmica como
la utilizada en las redes de rea local basadas en switches fast-ethernet. El
protocolo de comunicaciones ms ampliamente utilizado hoy en da en las redes
de rea local en Internet es el protocolo TCP/IP. Este protocolo fue diseado
como protocolo de conmutacin de paquetes, cuyo objetivo principal era la
entrega de paquetes libres de error desde un remitente a un receptor sin importar
cuando lleguen al destinatario.
El IP (Internet protocol) es un protocolo situado en la capa de red del
modelo OSI, basado en la conmutacin de paquetes y que no est orientado a
conexin. Sobre el protocolo IP normalmente son utilizados dos protocolos de
trasporte: el protocolo de control de transmisin (TCP) y el protocolo de
datagramas (UDP).
El protocolo TCP/IP no permite garantizar una calidad de servicio a los
usuarios finales, ni permite la reserva de ancho de banda que garantice la
transmisin del flujo de datos durante el periodo de visualizacin de los
contenidos multimedia. Estas caractersticas limitan considerablemente la
aplicacin de este protocolo para soportar servicios de Streaming. Para subsanar
estas limitaciones se han propuesto un conjunto de protocolos (RTP, RTCP,
RSVP y RTSP) soportados encima de TCP/IP que permita soportar el trfico
requerido por las aplicaciones de Streaming. A continuacin mostramos la
relacin de estos protocolos con los protocolos TCP/IP y UDP.
77

Figura 3.3.: Relacin entre los protocolos del Modelo OSI y los Protocolos de
Tiempo Real.

- Protocolo RTP (Real-Time Transport Protocol): Proporciona un mecanismo
para el transporte de datos en tiempo real a travs de Internet. RTP ofrece
servicios de entrega extremo a extremo para datos con caractersticas de tiempo
real que son adecuados para aplicaciones distribuidas que transmiten datos a
tiempo real. El protocolo ofrece caractersticas importantes para las aplicaciones
multimedia tales como marca de tiempo y numeracin de secuencia de los
mensajes e identificacin del tipo de datos transmitidos, que permite un
tratamiento adecuado por parte de la red [13].

78
- RTCP (Real-Time Control Protocol): Debido a que el protocolo RTP no
garantiza la calidad de servicio para las comunicaciones en tiempo real, se
requiere un protocolo complementario para controlar la calidad de los datos
entregados y control de flujo y congestin. Este protocolo genera la transmisin
de informes estadsticos entre el transmisor y receptor en el protocolo RTP,
mediante los cuales se identifican el estado de congestin de la red y que
consiguen limitar el nmero de paquetes perdidos (ajuste automtico de ancho de
banda).
- RTSP (Real-Time Streaming Protocol): Es un protocolo de nivel de aplicacin
que ofrece control sobre la entrega de datos a tiempo real. El protocolo se aplica
para el control de flujos continuos sincronizados en el tiempo, tanto de audio
como de video, y acta como control remoto de red para los servidores
multimedia. RTSP controla los flujos trasmitidos por un protocolo de trasporte
(RTP por ejemplo) [14] [15].
- RSVP (Resource ReServation Protocol): Protocolo que se encuentra situado
encima de la capa de Internet, dentro de la estructura del protocolo TCP/IP,
ocupando el lugar de los protocolos de transporte. RSVP proporciona un
mecanismo para configurar y gestionar la reserva de ancho de banda en Internet,
permitiendo la adaptacin de una transmisin a las fluctuaciones de trfico de las
redes [16].



79










CAPITULO IV











80
4. Arquitecturas utilizadas en los Sistemas de Streaming.
En los apartados anteriores hemos descrito los principales componentes y polticas
que integran un sistema de video bajo demanda. Sin embargo, a la hora de implementar un
sistema de estas caractersticas se pueden adoptar diversas arquitecturas. En este apartado
describiremos la organizacin y caractersticas de las principales arquitecturas utilizadas
para el diseo e implementacin de los sistemas Streaming.

4.1. Arquitecturas centralizadas:
Estos sistemas se basan en la conexin de todas las redes de usuarios del sistema
a una red principal a la cual se conecta un servidor un conjunto de servidores.


Figura 4.1.: Esquema de Arquitecturas Centralizadas.

Las principales caractersticas que definen las configuraciones centralizadas son la
gestin centralizada de todas las peticiones de los usuarios y la utilizacin de una red
81
principal que es compartida por todos los flujos de informacin del sistema. Existen dos
categoras de sistemas centralizados en funcin del nmero de servidores utilizados:
arquitecturas con un nico servidor y arquitecturas basadas en mltiples nodos de
servicio ( arquitectura de servidor distribuida).
En la primera configuracin con un nico servidor, la gestin de los clientes se
basa en un nico nodo de servicio que centraliza la atencin de todas las peticiones. En
estas arquitecturas, el servidor de video utilizado puede variar desde un PC estndar
(para sistemas de pequea escala) hasta supercomputadoras con cientos de procesadores
(sistemas de gran escala). Sin embargo esta aproximacin, en general, tiene diversas
limitaciones con respecto a la escalabilidad, tolerancia a fallos y disponibilidad del
servicio. Para evitar los inconvenientes asociados con la utilizacin de un nico
servidor en la literatura se ha propuesto la utilizacin de mltiples nodos de servicio, de
forma que se logre un servidor escalable (mediante la inclusin de nuevos nodos de
servicio), tolerante a fallos (ya no se depende de un nico punto de fallo) y que puede
alcanzar una mayor capacidad de servicio. Dentro de las arquitecturas centralizadas
basadas en mltiples nodos de servicio podemos encontrar dos configuraciones
diferentes en funcin de cmo se organizan los distintos nodos: servidores paralelos (
array de servidores) formando un cluster.
En general los servidores centralizados obtienen mejores rendimientos con respecto
a la probabilidad de bloqueo de las peticiones siempre que ambas configuraciones
dispongan del mismo ancho de banda de E/S. Sin embargo los servidores distribuidos
tienen una mejor escalabilidad, una alta disponibilidad, un mejor costo y pueden
82
alcanzar el mismo rendimiento que los servidores centralizados incrementando su
capacidad de almacenamiento de E/S.
El principal problema que sufren las arquitecturas centralizadas es el cuello de
botella que representa la red principal. La escalabilidad futura del sistema queda
limitada por el ancho disponible en esta red.
i. Servidores paralelos array de servidores: Esta arquitectura consiste en un
array de servidores, que trabajan de forma similar a un array de discos. Los
distintos nodos de servicio no almacenan videos completos, sino que los videos
son divididos en trozos y stos son distribuidos entre los diferentes nodos para
lograr una distribucin de la carga ms homognea entre todos los servidores [17].
A continuacin se muestra la configuracin de una arquitectura de
servidores paralelos compuesta por 5 servidores, todos ellos conectados con los
usuarios a travs de una red de interconexin. Cada uno de los servidores
almacenan un subconjunto de segmentos (v1,v2,....,vn) de los videos del catlogo
del sistema.

83

Figura 4.2.: Esquema Servidores paralelos array de servidores.

Cuando se produce una peticin cada nodo de servicio es el responsable de
transmitir al usuario los fragmentos de video solicitado que se encuentran en sus
discos. El cliente tiene la responsabilidad tanto de fraccionar su peticin en las
distintas solicitudes a cada uno de los nodos de servicio, como de posteriormente
recombinar y sincronizar los distintos flujos de informacin recibidos, para poder
reproducir el contenido multimedia. Esta arquitectura permite escalar la capacidad
del sistema aadiendo nuevos nodos, aunque se requiere realizar una nueva
redistribucin de los videos que tenga en cuenta los nuevos servidores aadidos.
Otras ventajas asociadas con esta configuracin son que permite un balanceo
automtico de la carga del sistema y que aumenta la tolerancia a fallos respecto a
las arquitecturas basadas en un nico nodo de servicio. La principal desventaja de
estas aproximaciones es que incrementan los requisitos de los Player de los
usuarios y complica considerablemente su diseo. Para evitar la utilizacin de
84
Players demasiados complejos se ha propuesto la utilizacin de proxies entre los
servidores y los clientes [18]. En estos sistemas, el trmino proxy hace referencia
al mdulo del sistema encargado de re-secuenciar y fusionar los datos procedentes
de los distintos servidores en un flujo de informacin coherente para entregrselo
al usuario final. El proxy puede tambin utilizar informacin redundante para
enmascarar posibles fallos en los servidores.
Adems, al no existir un nexo comn en la gestin de las peticiones de los
usuarios, la utilizacin de polticas de comparicin de recursos se complica
considerablemente.
ii. Cluster de servidores: Una arquitectura basada en cluster consiste en un grupo
de nodos conectados entre si por una red de interconexin. Cada nodo dispone de
un disco local conectado a l [19].

Figura 4.3.: Esquema Cluster de Servidores.
Los nodos del cluster se pueden dividir en tres categoras: nodos de
transmisin y nodos de almacenamiento y un nodo de control. El nodo control
admite las peticiones de la red externa basndose en una estrategia de control de
admisin predefinida dinmica. Los nodos de almacenamiento, guardan los
85
contenidos de forma similar a los servidores paralelos (i.e. cada objeto multimedia
es dividido en bloques y distribuido entre todos los discos del sistema),
proporcionndolos cuando son requeridos a los nodos de transmisin. Los nodos
de transmisin son los encargados de unir los distintos bloques correspondientes a
un video, antes de su transmisin al usuario en forma de un nico flujo de
informacin.




4.2. Arquitecturas de servidores independientes:
Una de las soluciones que se ha propuesto para incrementar la escalabilidad de
los sistemas de Streaming, es la conexin de los usuarios mediante servidores
independientes [20]. En estos sistemas, tal y como se muestra a continuacin, los
usuarios estn agrupados en segmentos de red cuyo trfico es independiente entre si,
denominados redes locales, de forma que el ancho de banda del sistema pueda llegar a
ser el ancho de banda acumulado de cada una de las redes individuales.
86

Figura 4.4.: Esquema Arquitecturas de servidores independientes.

Sin embargo, para incrementar el ancho de banda de estos sistemas no es
suficiente con nicamente agrupar los usuarios en redes independientes ya que si todos
acaban accediendo al mismo servidor y a su red, stos se convierten en el cuello de
botella del sistema, con la consiguiente saturacin de todo el sistema. La clave para que
estos sistemas con redes independientes funcionen y obtengan un mejor rendimiento,
estriba en que las peticiones se puedan servir localmente sin la necesidad de acceder a
un servidor centralizado. Este objetivo se puede lograr colocando servidores de
Streaming cerca de las redes locales de los usuarios y replicando todos los contenidos,
de forma que stos no tengan que acceder al servidor central, creando un sistema de
servidores independientes autnomos.
Las principales ventajas de esta arquitectura es que permite una escalabilidad
ilimitada mediante la inclusin de nuevos servidores a los cuales se conectarn los
nuevos usuarios y que no requiere servidores muy complejos. Por el contrario, los
sistemas de Streaming basados en servidores independientes tienen unos elevados
87
costos asociados con el subsistema de almacenamiento debido a que todos los
servidores deben replicar los contenidos del catlogo del sistema. Una alternativa para
reducir estos costos consiste en interconectar los servidores entre si y permitir que los
servidores slo almacenen un subconjunto de los videos del sistema, redirigiendo las
peticiones que no se puedan servir localmente hacia los otros servidores del sistema. De
todas formas, para no saturar la red de interconexin entre los servidores, estos an
necesitan almacenar un porcentaje considerable de los contenidos del sistema.

4.3. Arquitecturas basadas en servidores-proxy:
La arquitectura de servidores independientes implica un elevado costo, y por lo
tanto, algunas propuestas han optado por reducir el tamao de los servidores locales, de
forma que no almacenen una copia completa de las pelculas del sistema, sino
nicamente los contenidos ms populares. Estos servidores locales se denominan
servidores-proxy, al igual que sus homlogos de Internet y se comportan como una
cach del catlogo de contenidos almacenado en un servidor principal, el cual contiene
todos los videos disponibles en el sistema. Los sistemas basados en servidores-proxy de
un nivel, identifican a una arquitectura en la cual los servidores-proxy no estn
interconectados entre si. Esta arquitectura surge como un compromiso entre las
arquitecturas centralizadas (no escalables pero con menores requisitos de
almacenamiento) y las arquitecturas de servidores independientes (escalables, pero con
elevados costos de almacenamiento) [21]. Los servidores-proxy son los encargados de
gestionar inicialmente todas las peticiones generadas por los usuarios conectados a sus
88
redes (redes locales), en el caso que la peticin no pueda ser atendida localmente debido
a que el contenido requerido no se encuentra en la cach, entonces se redirige la
peticin hacia el servidor principal. Existen diversas polticas para gestionar el
contenido de los servidores-proxy en funcin de si almacenan los contenidos completos
solo un fragmento: prefix-caching basado en almacenar en la cach el fragmento
inicial (prefijo) de los contenidos de video ms populares y segment-caching que
archivan en la cach los fragmentos del video ms populares [22].
Existen dos configuraciones bsicas que se pueden utilizar a la hora de disear
un sistema Streaming basado en servidores-proxy. Ambos difieren en la arquitectura
utilizada para el servidor principal a la cual se conectan los distintos servidores-proxy.
Tenemos la arquitectura de servidores-proxy basados en un servidor centralizado y las
arquitecturas de servidores-proxy basadas en un servidor paralelo jerrquico.

i. Basados en un servidor principal centralizado: La topologa general de un
sistema basado en servidores-proxy se compone de un servidor principal al cual se
conectan directamente y a travs de una red principal, un conjunto de redes
locales con su proxy. Debido a que solo hay un nivel de servidores-proxy en la
arquitectura, este sistema se suele denominar, sistema basados en servidores-
proxy de un nivel (en contraposicin a otras arquitecturas que pueden utilizar
diferentes niveles jerrquicos de servidores-proxy dentro del sistema).

89

Figura 4.5.: Esquema Arquitecturas basados en un servidor principal
centralizado.

Como se muestra en la figura tambin se pueden ver los dos tipos de peticiones
que tienen estos sistemas: peticiones servidas localmente y las peticiones
atendidas por el servidor principal. Las peticiones locales (trazo continuo) son
aquellas que se pueden servir desde los contenidos almacenados en la cach de los
servidores-proxy. Cuando el servidor-proxy no dispone del contenido requerido
por la peticin, sta se redirige hacia el servidor principal que se encargar de su
servicio. Este tipo de peticiones requieren el doble de ancho de banda de red para
ser atendidas. El principal problema que se encuentran estos sistemas es la
escalabilidad limitada derivada de la dependencia de unos componentes
centralizados como son el servidor y la red principal. La capacidad de crecimiento
del sistema depender en ltima instancia de la capacidad de estos componentes
90
centralizados. De todas formas, siempre disponen de un mayor margen de
maniobra comparado con los sistemas centralizados.

ii. Basados en un servidor principal paralelo / jerrquico:
Esta aproximacin trata de solventar los problemas de escalabilidad del
servidor principal centralizado en la arquitectura de servidores-proxy de un nivel.
En esta arquitectura, de la cual la figura que se muestra a continuacin muestra
una posible configuracin, el servidor principal esta diseado basndose en una
red jerrquica en rbol, con servidores de Streaming en los nodos y enlaces de
red en las ramas de la jerarqua [23]. Los nodos de servicio situados en las hojas
de la jerarqua son los puntos de acceso para el sistema. Todos los nodos del
sistema solo almacenan un subconjunto de los contenidos del sistema.

Figura 4.6.: Esquema Arquitecturas basados en un servidor principal paralelo /
jerrquico.
91
Cuando una peticin para un contenido llega a un nodo hoja, si el
contenido est disponible en su almacenamiento local, el servidor atiende el
mismo al cliente. En caso contrario, la peticin se reenva hacia los niveles
superiores de la jerarqua para que sea atendida por otro nodo de servicio de la
arquitectura que disponga del contenido requerido. El rendimiento de esta
arquitectura es similar a las basadas en servidores-proxy de un nivel conectadas a
un servidor centralizado, pero reduce la probabilidad de saturacin del servidor
principal e incrementa la capacidad de servicio del sistema.

4.4. Arquitecturas distribuidas a nivel de los usuarios:
Las ltimas tendencias a la hora de disear sistemas de Streaming se orientan
hacia la adopcin de arquitecturas distribuidas, en las cuales la gestin de las peticiones,
as como los contenidos multimedia se distribuyen entre todos los componentes del
sistema. En estos sistemas, los distintos nodos de servicio tienen que colaborar entre si
para poder atender a los usuarios. Existen diferentes categoras de sistemas distribuidos
en funcin de si existen no un nodo maestro encargado de centralizar la gestin del
sistema y mantener una copia completa de los contenidos del sistema (arquitecturas de
servidores-proxy de un nivel, por ejemplo). Una de las primeras propuestas en este
sentido es la poltica de servicio de Chiang (encadenamiento) [24]. Esta poltica utiliza
el contenido de los buffers internos de los Players de los usuarios para a su vez servir
peticiones de otros usuarios hacia el mismo contenido. De esta forma, se crea una
cadena de servicio (cada eslabn de la cadena consiste de un usuario que reenva los
92
contenidos almacenados en su buffer hacia el siguiente eslabn) entre los propios
usuarios del sistema que permite reducir la carga del servidor de Streaming del sistema.
Recientes propuestas intentan utilizar el concepto peer-to-peer (aparecido originalmente
en la distribucin de ficheros de msica en Internet) para crear un sistema de
almacenamiento distribuido de contenidos multimedia que se puede utilizar para
implementar un sistema de Streaming totalmente distribuido. En estas arquitecturas, al
igual que ocurre con las tcnicas de Chaining, los Players de los usuarios realizan
funciones de servidor de contenidos para las peticiones de otros usuarios del sistema.















93










CAPITULO V











94
5. Arquitecturas de Streaming a gran escala.
A pesar del atractivo de los servicios de Streaming para el pblico en general, su
implementacin hasta el momento no ha sido tan grande como se pudiese esperar, debido a
la dificultad de disear y construir sistemas de Streaming de gran escala capaz de atender a
decenas de miles de peticiones simultneas.
La construccin de sistemas de video bajo demanda de gran escala est actualmente
limitada por dos factores: la capacidad de transmisin simultanea de videos (capacidad de
streaming) que puede soportar el servidor y la red de comunicacin, y por otro lado, los
elevados costos requeridos para su construccin.
Para proveer servicios de Streaming capaz de atender a decenas de miles de usuarios
es imprescindible el diseo de sistemas de Streaming a gran escala eficientes y con un costo
asumible.

5.1. Requisitos de las arquitecturas de Streaming a gran escala:
A la hora de realizar el diseo de un sistema Streaming a gran escala, adems de
tener que proporcionar una alta capacidad de streaming, tambin son de vital
importancia considerar los conceptos de escalabilidad, tolerancia a fallos, costo,
balanceo de la carga y comparicin de recursos, que describimos a continuacin:

5.1.1. Escalabilidad del Sistema de Streaming:
95
En trminos generales, la escalabilidad hace referencia a la capacidad del
sistema para mantener, sino mejorar, su rendimiento a medida que aumenta el
nmero de clientes.
Ninguna instalacin de Streaming puede crecer desde 0 a un milln de usuarios
de un da para otro. Por lo tanto, sobredimensionar el sistema de Streaming teniendo
en cuenta los posibles usuarios futuros, puede dar a lugar a que cuando una
capacidad adicional se requiera el sistema ya resulte obsoleto debido a los avances
en la tecnologa.
Los sistemas de Streaming deben permitir ajustar su capacidad inicial a los
requerimientos de los usuarios para as reducir la inversin inicial. Pero al mismo
tiempo deben conservar intacta la capacidad de crecimiento futuro.
La escalabilidad es una de las caractersticas ms importantes para un sistema
Streaming, permitiendo que se pueda ajustar el tamao inicial del sistema a los
requerimientos de los usuarios, pero manteniendo la posibilidad de un fcil
crecimiento para poder soportar ms usuarios nuevos servicios.
En general, en los sistemas distribuidos existen dos tipos de escalabilidad: la
vertical y la horizontal. Al hablar de escalabilidad vertical nos referimos a
incrementar el nmero de recursos en la misma mquina para conseguir atender a
un mayor nmero de usuarios. La escalabilidad horizontal consiste en incrementar
el nmero de mquinas que integran el sistema.

5.1.2. Tolerancia a fallos:
96
Los sistemas de Streaming tienen que continuar dando servicio a los usuarios,
incluso si uno ms componentes de la arquitectura fallan.
En sistemas de gran escala, normalmente enfocados a un pblico que paga por
unos servicios, no es asumible una interrupcin del servicio debido a un fallo de
alguno de los componentes. Estas interrupciones de servicio, en caso de producirse,
pueden producir un grave perjuicio econmico y de imagen.
Los sistemas de gran escala son ms susceptibles de sufrir algn fallo debido al
gran nmero de componentes (servidores, redes, discos duros) que los forman. Por
lo tanto, es importante tener en cuenta la tolerancia a fallos en el diseo de estos
sistemas. Una de las tcnicas utilizadas para aumentar la tolerancia a fallos, es la
replicacin de los componentes ms crticos del sistema. Aunque reduce la
posibilidad de interrupcin del servicio, esta tcnica implica una gran inversin en
componentes que no estarn en funcionamiento durante la mayor parte del tiempo
de vida del componente, y que pueden llegar a quedarse obsoletos incluso antes de
ser utilizados. La utilizacin de componentes de respaldo es muy costoso, por lo
cual se suele utilizar cuando no hay ms remedio, por ejemplo en sistemas
centralizados.
Una alternativa mejor y menos costosa consiste en que los componentes de
respaldo formen parte de la propia arquitectura. De esta forma, el posible respaldo
para un servidor del sistema es otro servidor de la misma arquitectura. La mejor
forma de implementar esta poltica es logrando que la atencin de los usuarios no
dependan de un nico servidor, sino que puedan ser atendidos por distintos
componentes del sistema, en funcin de las necesidades. La utilizacin de una
97
arquitectura totalmente distribuida, en la cual la gestin de las peticiones se realiza
de forma descentralizada, es la forma ms fcil de obtener la tolerancia a fallos sin
necesitar componentes de respaldo [25].


5.1.3. Costo del Sistema de Streaming:
El Streaming a gran escala en el mbito empresarial est mayormente enfocado
a ofrecer servicios de entretenimiento y multimedia a grandes ciudades (si no a
pases enteros). Este tipo de instalaciones requieren de una gran inversin y, por lo
tanto, es imprescindible un control muy estricto de los costos de la arquitectura de
Streaming.
Desde el punto de vista de la arquitectura de Streaming, los componentes que
requieren una mayor inversin son las redes de comunicacin y los servidores de
video.
El costo de las redes de transmisin depende bsicamente del ancho de banda
requerido y de la tecnologa utilizada. El costo asociado con una red individual se
puede incrementar exponencialmente si el ancho de banda requerido es muy grande.
Para reducir el costo del sistema de comunicaciones es recomendable que la
arquitectura de Streaming a gran escala no requiera la utilizacin de redes con
anchos de banda muy grandes.
Con respecto a los servidores, los componentes que ms influyen en su costo son
los asociados con el ancho de banda servicio y el sistema de almacenamiento
98
requerido para soportar el catlogo de contenidos del sistema. El costo del servidor,
al igual que ocurre con la redes, depende de la capacidad de servicio deseada. Un
servidor ms potente necesitar la utilizacin de tcnicas de clustering y discos
RAID para poder soportar el ancho de banda requerido, aumentado el costo
considerablemente.
En general, parece lgico pensar que se obtiene la mejor relacin
costo/rendimiento utilizando componentes pequeos y cuyo uso est generalizado
en el mercado. Se deben evitar requisitos que necesiten la utilizacin de
componentes demasiado complejos que requieran de las ltimas tecnologas
disponibles en el mercado.

5.1.4. Balanceo de la Carga:
La distribucin de la carga entre los distintos servidores del sistema, es
importante debido a que las peticiones de los usuarios siguen una distribucin no
uniforme. Esta caracterstica puede provocar un desbalanceo en el volumen de
trabajo de los servidores y una pobre utilizacin de los recursos globales del sistema
El sistema de Streaming debera permitir que parte de la carga de los
componentes (servidores redes) ms saturados, se pueda desviar a otros
componentes menos cargados. Una correcta redistribucin de la carga en el sistema,
permite reducir la probabilidad de rechazo de servicio a los usuarios [26].

5.1.5. Comparticin de Recursos:
99
Hoy en da, la posibilidad de poder compartir de recursos entre los usuarios
(mediante tcnicas de broadcast, multicast, etc.) es la clave para el diseo e
implementacin de sistemas de Streaming eficientes y con una buena relacin
costo/prestaciones.
La eficiencia de las tcnicas de multicast depende, entre otros factores, del
volumen de peticiones que recibe un servidor. Un mayor volumen de peticiones,
implica una mayor probabilidad de que las nuevas peticiones puedan compartir
recursos con las peticiones activas. De esta forma, el nmero de usuarios
gestionados por un servidor puede aumentar la eficiencia de las polticas de
multicast y por tanto la eficiencia del sistema.

5.2. Alternativas actuales para los sistemas de Streaming a Gran
Escala:
La construccin de un sistema de Streaming a gran est actualmente limitada tanto
por la capacidad del servidor (ancho de banda de servicio) como por la capacidad de
transmisiones simultaneas que puede soportar una red de comunicaciones (ancho de
banda de la red).
Actualmente, la implementacin de un sistema de Streaming a gran escala que
pueda soportar un gran nmero de streams concurrentes, requiere la disposicin de
varios servidores, que ofrecen la transmisin de video y los servicios de reproduccin
bajo la forma de un sistema distribuido.
100
Sin embargo, las distintas aproximaciones para crear esta infraestructura pueden
varar desde sistemas completamente centralizados (mediante un cluster de servidores)
que utilizan hardware dedicado en la capa de red sin almacenamiento intermedio, hasta
sistemas completamente descentralizados que replican todo el catlogo de contenidos
en servidores cercanos al usuario final.
Al disear un sistema Streaming a gran escala nos podemos basar en las
arquitecturas disponibles hoy en da, ya vistas en el apartado anterior. Cada una de estas
arquitecturas tiene sus ventajas e inconvenientes dentro de un entorno de servicio a gran
escala que comentamos a continuacin:
- Sistemas centralizados: Un sistema de Streaming a gran escala centralizado
requiere un servidor y una red principal capaces de soportar un gran ancho de
banda. Un servidor con estas caractersticas puede llegar a ser muy costoso y
complejo de disear / construir. La disponibilidad de redes capaces de soportar estos
volmenes de trfico puede estar limitada por la tecnologa disponible. Adems el
sistema resultante no es tolerante a fallos, ni escalable ya que el crecimiento del
sistema esta limitado por la red y el servidor principal.
La nica ventaja de esta arquitectura es la alta eficiencia que pueden obtener de
las polticas multicast. Al estar todos los usuarios conectados a la misma red, la
probabilidad de comparticin de streams es la ms alta de todas las arquitecturas de
Streaming.
Estos sistemas adolecen de una serie de problemas que dificulta su candidatura a
una instalacin de gran escala
101
- Servidores independientes: Esta arquitectura no requiere ni redes grandes, ni
servidores complejos para lograr la alta capacidad de streaming requerida por los
sistemas de gran escala. Estos sistemas permiten una escalabilidad ilimitada ya que
para aumentar la capacidad del sistema nicamente se necesita aadir nuevas redes
locales (ms los servidores correspondientes) al sistema.
La principal desventaja de esta arquitectura en un entorno de gran escala son los
requerimientos de almacenamiento en los servidores (cada servidor necesita una
copia entera del catlogo de contenidos), la comparticin de recursos esta
restringida exclusivamente a los usuarios locales y el balanceo de carga es casi
imposible a no ser que las redes independientes estn interconectadas.
- Sistemas basados en servidores-proxy de un nivel: Como ya hemos visto, uno
de los problemas de estos sistemas estriba en la escalabilidad limitada derivada de la
dependencia de unos componentes centralizados como son el servidor y la red
principal. La capacidad de crecimiento del sistema depender de la capacidad de
estos componentes centralizados. De todas formas, disponen de un mayor margen
de crecimiento comparado con los sistemas centralizados.
Los requisitos globales de ancho de banda de red en estos sistemas, son mayores
debido a que las peticiones que no pueden ser atendidas desde la cache de los
servidores-proxy, requieren el doble de recursos de red (red principal + red local)
para poder ser atendidas desde el servidor principal.
Por otro lado, al gestionarse la mayora de las peticiones en los servidores-
proxy, tambin se reduce la probabilidad de comparticin de recursos entre usuarios
con respecto a los sistemas centralizados.
102
- Servidores basados en servidores-proxy paralelos/jerrquicos: Bsicamente
estas arquitecturas tienen los mismos parmetros de rendimiento que los sistemas
basados en servidores-proxy de un nivel. La nica diferencia estriba en la
utilizacin de un servidor paralelo que aporta mltiples puntos de entrada al
servidor y permite reducir el cuello de botella que representa la red principal en los
sistemas de servidores-proxy de un nivel.
En ltima instancia, la escalabilidad de estas arquitecturas depende de la
escalabilidad asociada con el servidor paralelo/jerrquico. Por otro lado, parte del
ahorro de los costos obtenidos al reducir los requerimientos de almacenamiento se
compensan con el costo asociado con el servidor paralelo.
- Sistemas distribuidos a nivel de usuario: La principal desventaja con la que se
tropiezan estos sistemas es el incremento de la complejidad y costo de los
componentes de los usuarios, al tener que incorporar buffers ms grandes y requerir
anchos de bandas de red capaces de soportar ms de un stream simultneo. Adems,
la eficiencia de las tcnicas basadas en Chiang peer-to-peer depende de la
existencia de una alta conectividad entre los usuarios del sistema, lo cual puede
exigir la utilizacin de topologas muy costosas (malla, crossbar, etc.) en la
conexin de los usuarios al sistema.

A continuacin mostramos las principales caractersticas de las distintas
arquitecturas de Streaming a gran escala. A pesar de que todas estas arquitecturas son
capaces de conseguir una capacidad alta de streaming, ninguna de ellas alcanza a
103
cumplir con todos los caractersticas deseables para un sistema de Streaming a gran
escala.

Tabla 5.1.: Tabla de las principales caractersticas de las arquitecturas.
Los principales inconvenientes que tienen estas arquitecturas son la insuficiente
escalabilidad y el elevado costo requerido para el sistema. Por lo tanto, existe la necesidad
de una nueva arquitectura, especficamente diseada para un sistema de Streaming a gran
escala.








104










CAPITULO VI











105

6. Estructura de una Estacin de Radio y un Canal de Televisin.
El montar una estacin de radio y un canal de televisin, para llevar la seal que
sta emite hacia los usuarios, conlleva una amplia demanda tanto de hardware como de
presupuesto, adems de un amplio conocimiento del funcionamiento de las redes y de lo
servicios necesarios para su correcto funcionamiento. A modo de resumen, cabe destacar,
que llevar la seal al espectador (usuario) involucra una arquitectura tradicional
cliente/servidor: la computadora del cliente pide una seal y el servidor enva al cliente un
flujo de datos conteniendo dicha seal. El proveedor de la seal de radio y televisin
necesita enviar a cada usuario un flujo individual, ya que la transmisin se realiza a travs
de la transmisin Unicast (la cual fue descrita en captulos anteriores). Cuando se est
transmitiendo en vivo a travs de Internet, los proveedores estn literalmente enviando
miles de veces flujos idnticos del servidor a los computadores de los espectadores.
Uno de los objetivos de la investigacin es el de lograr transmitir programas radiales
y televisivos a los usuarios, minimizando el costo de operacin, pero sin descuidar la
eficiencia del sistema. Es por ello que la solucin que se plantear a continuacin, conlleva
un presupuesto no tan elevado, pero que satisface dichos objetivos planteados.
Como se desea transmitir a usuarios que tengan reproductores que hoy en da se
encuentran en la mayora de las maquinas, se ha optado por transmitir con los servidores de
Streaming Windows Media Server y Real Server. Al realizar un estudio profundo de
las dos tecnologas, se ha descubierto que Real Server puede comportarse como el servidor
de Microsoft, Windows Media Server, emulndolo a la perfeccin, sin la necesidad de tener
106
que instalarlo. Es por ello que solo se ocupar el servidor de RealNetworks, pero
igualmente se darn servicios para los dos grandes grupos de usuarios, como son aquellos
con los reproductores Windows Media Player y Real Player. El servidor de streaming se
comunicar con los usuarios, entregndoles un flujo de datos, con la informacin
perteneciente a la seal que se esta emitiendo desde la estacin de radio.
Cabe destacar que el servidor solo se encarga de la comunicacin con los usuarios,
pero se necesita de un Codificador o Encoder, el cual se encarga de la codificacin o
digitalizacin de la Seal de Radio proveniente de la produccin radiodifusora, adems de
entregarlos al servidor de streaming para su posterior difusin. Como se requiere entregar
servicios a usuarios tanto de Microsoft como de RealNetworks, se necesitara de dos
codificadores especialistas para cada tecnologa. El codificador que se encargar de crear el
flujo de Microsoft se llama Windows Media Encoder, y el encargado de generar el flujo
para RealNetworks se llama Real Producer o Helix Producer.
Otra parte importante del sistema que conformar la estacin de radio y el canal de
televisin es el modulo de produccin, que es el encargado de administrar y generar la
seal que se transmitir (tanto audio y video).

6.1. Proceso de Transmisin de una Estacin de Radio.
El sistema que permitir a la estacin de radio transmitir a nuestros usuarios, est
compuesto por tres mdulos claramente definidos: Produccin que es el encargado de
generar y emitir la seal de audio, Codificacin que es el encargado de digitalizar la
informacin analgica generada por la produccin y Transmisin el cual es el
107
encargado de entregar el flujo de datos generados por la estacin de radio a los clientes.
Estos mdulos estn representados en la siguiente figura:


Figura 6.1.: Estructura de una estacin de radio.
Como se menciono anteriormente el proceso de emisin de la estacin de radio
esta dividido en mdulos, los cuales se explican con ms detalle:
i. Produccin: En la etapa de produccin, se debe generar la seal de audio que se
quiere entregar a los usuarios. Para ello se debe contar con algn servicio que nos
permita automatizar ste proceso, adems de entregarnos las distintas opciones
fundamentales para el correcto funcionamiento, como son: mezcla de archivos de
audio en tiempo real, automatizacin (programacin) de la reproduccin de los
108
archivos, locucin en vivo a travs de un micrfono, etc. Para ello se ha optado por
un software que posee todas estas caractersticas llamado SAM Broadcaster, que
es especializado para las transmisiones de una estacin de radio. En la figura se
observa la ventana principal de ste software [27]:

Figura 6.2.: Imagen del productor de la estacin de radio.

Como se puede observar, SAM Broadcaster cuenta con dos ventanas de
reproduccin que nos permite mezclar audio segn sea nuestro gusto (subventana
Deck A" y Deck B) y programar el listado de archivos de acuerdo la hora y la
duracin del archivo anterior (subventana Queue). Otra caracterstica fundamental
es el de poder hacer comentarios en vivo mientras se reproduce una cancin (o una
cortina), ideal para los momentos en los que el locutor debe intervenir (subventana
Voice FX). Adems se permite emitir efectos especiales o eslganes previamente
gravados en formato wav, los cuales pueden crearse con cualquier editor de
sonido (subventana Sound FX). Entre otras caractersticas generales, SAM
109
Broadcaster nos permite tener configuradas dos tarjetas de audio, una para la
reproduccin directa, y una para realizar pruebas, es por ello que en la subventana
Volume, se puede ajustar el volumen de stas dos salidas independientes, otra
caracterstica fundamental, es que el software puede realizar mezclados en directo y
en forma automtica cada vez que se termina la reproduccin de un archivo de
audio.
Una vez instalado y configurado el software de produccin, se toma la salida
de audio de la tarjeta de sonido que emite la seal de la estacin de radio,
conectndole un cable con dos salidas, una directamente al codificador Windows
Media Encoder y la otra directamente al codificador Real Producer.
ii. Codificacin: Una vez configurado y conectada la salida del productor de la
estacin de radio que es el encargado de generar la seal analgica a emitir, se
realiza el proceso de codificado. Tanto Real Producer como Windows Media
encoder, deben generar el flujo de datos con la seal digitalizada de nuestra estacin
de radio, y entregarlos al servidor para su posterior difusin, El proceso es sencillo,
los codificadores toman la seal proveniente de la tarjeta de sonido, la codifican
segn el CODEC seleccionado, y se comunican con el servidor por un puerto
especifico para entregarle el stream o flujo al servidor. Para ello el servidor debe
estar debidamente configurado. No se adentrar mas en ste tema, ya que el proceso
de codificacin tanto del Windows Media Encoder, como del Real Producer sern
explicados con mayor profundidad en captulos posteriores.
iii. Transmisin: Cuando cada uno de los codificadores entregan el flujo de
informacin al servidor, ste es el encargado de difundirlo a cada uno de los
110
usuarios que lo solicitan. Para ello entrega un flujo distinto a cada usuario en el
mismo instante, pero con la misma informacin (Transmisin en directo), utilizando
la tecnologa de transmisin UDP/Unicast, la cual fue explicada con mayor detalle
en captulos anteriores. Para ello el servidor debe contar con los permisos adecuados
para que acepte la entrada de flujos desde el Codificador.
6.2. Proceso de Transmisin de un Canal de Televisin.
Los sistemas con los cuales los canales de televisin actuales cuentan, conllevan un
gran consumo de recursos, tanto humanos, como de hardware y software. Es por ello,
que se propone 2 estructuras o modelos de un sistema de Streaming para un canal de
televisin, los cuales se diferencian por un ahorro considerable de hardware y por
consecuencia una disminucin considerable en los costos. A continuacin se explican
los dos modelos [28]:

6.2.1. Modelo de Transmisin General:
Al igual que la estacin de radio, el sistema que permitir al canal de
televisin transmitir a nuestros usuarios, est compuesto por tres mdulos
claramente definidos: Produccin que es el encargado de generar y emitir la seal
tanto de audio como video, Codificacin que es el encargado de digitalizar la
informacin analgica generada por la produccin y Transmisin el cual es el
encargado de entregar el flujo de datos generados por el canal de televisin a los
clientes. Estos mdulos estn representados en la siguiente figura:
111

Figura 6.3.: Estructura del Canal de Televisin (Modelo General).

En la mayora de los canales de televisin que operan hoy en da, cuentan
con departamentos claramente diferenciados, especialistas en cada uno de los
aspectos principales de produccin, como lo son el departamento de edicin,
departamento de Periodismo, departamento de Transmisin Satelital, departamento
de Broadcasting, etc., para lo cual cuentan con una amplia gama de recursos en
cuanto a infraestructura, insumos, recursos humanos, capital y sistemas de
112
automatizacin tipo WAN. Es por ello que se debe estudiar muy enfticamente los
objetivos que se desean lograr al desear montar un canal de televisin, y analizar, de
acuerdo a stos objetivos, si es factible y rentable realizar el proyecto. Es por ello
que se ha diseado el sistema actual con un balance entre los factores
eficiencia/costos sin descuidar el correcto funcionamiento de nuestro canal de
televisin (igualmente para la estacin de radio).
Como se menciono anteriormente el proceso de emisin de un canal de
televisin esta dividido en mdulos, los cuales se explican con ms detalle:
i. Produccin: Al igual que una estacin de radio, el canal de televisin tambin
necesita de una produccin eficiente, que entregue videos de buena calidad, y de la
forma mas transparente posible para el usuario. En la figura se muestra que el
proceso de produccin, que como se puede observar, consta de dos estudios
claramente diferenciados, los cuales son detallados a continuacin:
- Estudio de Video: La tarea del Estudio de Video es simple, debe de reproducir
archivos de video, que ya han sido grabados y editados con anterioridad, y que se
quieren entregar en diferido a los usuarios. Para ello se puede utilizar cualquier
Reproductor de Video que posea la caracterstica de leer los videos con formato
Windows Media, Real Media y cualquier otro formato. Una recomendacin es
el de utilizar un reproductor, que adems de poseer stas caractersticas, reproduzca
adems clips en formato DVD, VCD, DviX, etc., ya que en algn momento se
podra emitir una pelcula o algn documental proveniente de un dispositivo
especial. En lo particular, se ocupara el reproductor WinDVD que permite
realizar lo antes descrito.
113


Figura 6.4.: Imagen del Reproductor de Video.

Para ello el estudio de video debe contar con una tarjeta de sonido y dos tarjetas
de video, de las cuales una debe tener una salida de televisin la cual deber ir
conectada, junto con la salida de la tarjeta de sonido, al multiplexor de video. La
idea de esto, es que el reproductor es manejado desde uno de los escritorios
(monitores) y la previsualizacin del video debe ir en el otro escritorio a travs de la
tarjeta de video que contiene la salida de televisin, es as como solo la seal de
video sale del estudio de video hacia el multiplexor.
- Estudio de Transmisin en Vivo: Su funcin principal es de capturar la seal
proveniente de las cmaras filmadoras de video y transmitirlas a los codificadores.
Para ello se pude utilizar cualquier software capturador de video, aunque se
recomienda utilizar el software por defecto que trae el CD de instalacin de la
114
capturadota de video, ya que ste es creado para dicha tarjeta capturadota en
especial, y con los otros software correramos el riesgo de que el sistema se caiga
por alguna razn inesperada.

La salida proveniente de los dos estudios anteriormente mencionados, va
dirigida un Multiplexor de Video, el cual se encarga de seleccionar cual de las
entradas de video es la entregada a los codificadores de video. El diseo de un
multiplexor se muestra en la siguiente figura:

Figura 6.5.: Esquema del Multiplexor de Video.
Su funcin principal es el de elegir cual de las dos entradas de video van
dirigidas a los codificadores de video. Como se puede observar en la figura, existen
dos entradas de video provenientes de dos fuentes distintas, las cuales son
canalizadas a la salida de video segn sea el inters del administrador. Por lo tanto
115
el multiplexor de video cuenta con un Switch que selecciona una de ellas como
salida.
ii. Codificacin: Cuando la seal sale del multiplexor de video, independientemente
de su estudio de procedencia, debe ingresar a los codificadores, para que stos
entreguen la seal digitalizada al servidor de Streaming. Su funcionamiento es
similar al de la estacin de radio, con la diferencia que la seal es una transmisin
de video, la cual ingresa al codificador por una tarjeta capturadora. En cuanto a la
comunicacin de ste con el servidor, se debe especificar el tipo de compresin
tanto de video como de sonido, dependiendo del CODEC seleccionado. Como se
menciono en el tem anterior, en los siguientes captulos abordaremos en
profundidad sta etapa del proceso, adems de las distintas opciones de
codificacin.
iii. Transmisin: ste proceso es exactamente igual al de una estacin de radio, el
servidor de Streaming, recibe el flujo de datos digitalizado por el codificador, y lo
retransmite a los usuarios con la calidad configurada en el tem anterior. La
descripcin completa de ste proceso ser explicado en captulos posteriores, por lo
que no profundizaremos mas en ste tema.

6.2.2. Modelo de Transmisin Reducido:
Como se puede apreciar, en el modelo anterior se necesita contar con
hardware especifico que realice la tarea de generar la seal transmitida, a partir de
un estudio especializado en la edicin y reproduccin de material almacenado, y a
116
partir tambin de un estudio encargado de recoger la seal en vivo trasmitida de
cualquier lugar geogrfico. Por lo tanto, para lograr que el canal de televisin sea
factible de realizar, se debe contar con un modelo reducido, que cuente con lo
esencial, pero sin perjudicar la calidad de transmisin. Al igual que en el modelo
anterior, el proceso de transmisin esta dividido en mdulos claramente
diferenciados, los cuales estn representados en la siguiente figura:

Figura 6.6.: Estructura del Canal de Televisin (Modelo Reducido).

117
Cabe destacar, que el modelo que se plantea es una solucin lo ms
reducida, para ahorra recursos y as abaratar el costo total del sistema, sin descuidar
el objetivo principal, el cual es entregar un medio audiovisual a los usuarios de
buena calidad y de forma eficiente. Como se menciono anteriormente el proceso de
emisin de un canal de televisin esta dividido en mdulos, los cuales se explican
con ms detalle:
i. Produccin: A diferencia del modelo anterior, el mdulo de produccin cuenta
con la Estacin de TV y la Estacin Mvil. La Estacin de TV es la
encargada de automatizar el proceso de transmisin, seleccionando un video
almacenado en disco o simplemente mostrando una transmisin en vivo realizada
desde cualquier lugar del mundo (Estacin Mvil), a travs de un codificador de
Streaming (Real Producer o Windows Media Encoder). Para ello la Estacin
Mvil debe contar con cualquier computador con tarjeta capturadora y que tenga
acceso al servidor (Real Server), para que le enve la seal en vivo. Dicha seal en
vivo ser tomada por la Estacin de TV desde el servidor y ser retransmitida a
los usuarios.
Una vez que la seal es generada por la Estacin de TV, la salida de su
tarjeta de video (salida analgica) es dirigida a los codificadores los cuales son lo
encargados de digitalizar la seal.
ii. Codificacin: Cuando la seal sale de la Estacin de TV, debe ingresar a los
codificadores, para que stos entreguen la seal digitalizada al servidor de
Streaming. Su funcionamiento es similar al del mtodo anterior, por lo que la seal
entregada por la Estacin de TV pasa directamente a los codificadores Windows
118
Media Encoder y al Real Producer. En cuanto a la comunicacin de ste con el
servidor, se debe especificar el tipo de compresin tanto de video como de sonido,
dependiendo del CODEC seleccionado. Como se menciono en el tem anterior, en
los siguientes captulos abordaremos en profundidad sta etapa del proceso, adems
de las distintas opciones de codificacin.
iii. Transmisin: ste proceso es exactamente igual al de una estacin de radio y al
mtodo anterior, el servidor de Streaming, recibe el flujo de datos digitalizado por el
codificador, y lo retransmite a los usuarios, con la calidad configurada en el tem
anterior. La descripcin completa de ste proceso ser explicado en captulos
posteriores, por lo que no profundizaremos mas en ste tema.

6.3. Requerimientos de Hardware y Software de un Sistema de
Streaming.
Para que nuestro sistema de Streaming cumpla con los requisitos descritos en el
apartado 1.4 del Capitulo I, nuestro hardware debe contar con un mnimo de
caractersticas y requisitos en cuanto a calidad y principalmente en cuanto a velocidad.
Adems cada uno de los componentes del sistema debe contar tambin con el software
apropiado para que dicho sistema funcione en forma eficiente. A continuacin se muestra
los requerimientos de hardware y software para que cada uno de los componentes
funcione correctamente, basndonos en los componentes principales del sistema:

6.3.1. Sistemas Operativos y Hardware Soportados:
119
Los componentes principales que conforman el sistema son el servidor de Streaming
llamado Real Server, los codificadores Real Producer y Windows Media
Encoder, adems de los estudios de produccin, Sam Broadcaster y el Estudio de
Televisin. A continuacin detallaremos los requisitos de cada uno de estos
componentes:

i. Real Server:
Procesador Sistemas Operativos
- Intel Pentium III 1GHz o Superior.
- Xeon 1 Ghz o Superior.
- AMD Athlon MP 1 Ghz o Superior
- Windows NT 4.0.
- Windows 2000 (profesional o Server).
- Linux Kernel V.2.4.18 (gLibC 2.2.4).
- FreeBSD V.4.0 o V.4.5
- Sun Ultra SPARC II 400 MHz o
Superior.
- Sun Solaris V.2.7 o V.2.8 de 32 bits.
- Motorilla Power PC 375 MHz o
Superior.
- IBM AIX V.4.3 o V.5.L.
- PA-Risc 2.0 440 MHz o Superior. - HP UX V.11.0 o V.11.i de 32 bits.
- Alpha 500 MHz o Superior. - Compaq Tru64 UNIX V.5.1 o V.5.11.
Memoria RAM: 256 MB mnimo.
Tabla 6.1.: Requisitos del Real Server.

ii. Real Producer:
Procesador Sistemas Operativos
- Intel Pentium IV 2.4 GHz o Superior.
- Xeon 2.0 Ghz o Superior.
- AMD Athlon MP 2.8 Ghz o Superior
- Windows NT 4.0.
- Windows 2000 (profesional o Server).
- Windows XP (SP2).
120
- Linux Kernel V.2.4 (gLibC 2.1).
Memoria RAM: 128 MB mnimo 512 MB Recomendado.
Tarjeta de Video: Tarjeta que soporte resolucin 1024x768 o Superior.
Tarjeta Capturadora: Tarjeta que soporte compresin MPEG.
Software (Windows):
DirectX 8.1 o Superior.
QuickTime 6.5.
DirectShow MPEG-2 Decoder.
Tabla 6.2.: Requisitos del Real Producer.
iii. Windows Media Encoder:
Procesador Sistemas Operativos
- Intel Pentium III 1 GHz o Superior.
- Xeon 1 Ghz o Superior.
- AMD Athlon MP 1 Ghz o Superior
- Windows 2000 (profesional o Server).
- Windows XP (SP2).
- Windows 2003 Server.
Memoria RAM: 256 MB o Superior.
Tarjeta de Video: Tarjeta que soporte resolucin 1024x768 o Superior.
Tarjeta Capturadora: Tarjeta que soporte compresin MPEG.
Software (Windows): DirectX 9.0 o Superior.
Tabla 6.3.: Requisitos del Windows Media Encoder.

iv. Sam Brodcaster:
Procesador Sistemas Operativos
- Intel Pentium II 350 MHz o Superior.
- Xeon 300 Mhz o Superior.
- AMD Athlon MP 350 Mhz o Superior.
- Windows 2000 (Profesional o Server).
- Windows XP (SP2).
- Windows 2003 Server.
- Windows 98 (No recomendado).
- Windows ME (No Recomendado).
Memoria RAM: 256 MB o Superior.
121
Tarjeta de Sonido: Con salida estereo de buena calidad.
Software: Motor de base de datos a eleccin:
FireBird.
MySQL.
MS SQL.
PostgreSQL.
Tabla 6.4.: Requisitos del Sam Broadcaster.



v. Estudio de Televisin:
Procesador Sistemas Operativos
- Intel Pentium III 1 GHz o Superior.
- Xeon 1 Ghz o Superior.
- AMD Athlon MP 1 Ghz o Superior
- Windows 2000 (profesional o
Server).
- Windows XP (SP2).
- Windows 2003 Server.
Memoria RAM: 512 MB o Superior.
Tarjetas de Video:
- Tarjeta que soporte resolucin 1024x768 o Superior con Salida de Televisin.
- Tarjeta que soporte resolucin 1024x768 o Superior.
Software (Windows): DirectX 9.0 o Superior.
Tabla 6.5.: Requisitos del Estudio de Televisin.

6.3.2. Requisitos de la Red de Comunicacin:
Para que un sistema de Streaming funcione de forma eficiente, debemos calcular el
ancho de banda necesario tanto para la comunicacin entre los codificadores y el
122
servidor, como para la comunicacin entre el servidor y los usuarios. En el caso de la
comunicacin entre los codificadores y el servidor, por lo general stos se encuentran
en la red local, por lo que se cuenta con un ancho de banda suficiente para dicha
transmisin. En el caso de la comunicacin entre el servidor y los usuarios, lo normal
es no disponer de suficiente ancho de banda para la retransmisin en directo con alta
calidad. Es por ello que se debe usar una formula sencilla que permite calcular el tipo
de conexin necesaria (ancho de banda) para la realizacin de eventos en directo.
Cabe destacar que los codificadores de Streaming pueden crear un Contenido
Multimedia con distintos niveles de compresin en un mismo archivo, por lo que el
codificador lo enviar por la red consumiendo la sumatoria de stos anchos de banda.
La formula que permite calcular el ancho de banda necesarios es el siguiente:
Ancho de Banda Requerido = Sumatoria (kbps) x 1,5
Por lo tanto, si se quiere realizar una transmisin en directo de un evento en
vivo usando varios ancho de banda diferentes, por ejemplo, para las siguientes
conexiones: ADSL (225 kbps) RDSI (45 kbps) y mdem (34 kbps), necesitaremos:
Ancho de Banda Requerido = (225 + 45 + 34) * 1,5
Ancho de Banda Requerido = 456 kbps.
Entonces se necesitar una conexin al servidor que permita, desde el
codificador mantener un flujo de datos de 456 kbps mnimos. Si la codificacin se
realiza en la red interna como es el caso del Estudio de TV, contamos con el ancho
123
de banda necesario, pero si se quiere realizar una codificacin desde la Estacin
Mvil desde otro lugar por Internet, debemos calcular una configuracin (del
codificador) que nos permita transmitir sin problemas.
Cabe destacar que una vez entregados estos flujos al servidor, ste evala la
capacidad del cliente para recibir el contenido multimedia, y transmite el video y/o
sonido a la calidad de compresin segn el ancho de banda disponible entre el
servidor y el usuario. A continuacin se muestra como ejemplo la configuracin
utilizada al montar el sistema de Streaming y colocarlo en funcionamiento:

Canal de Televisin:
Real Producer Se codifica con calidad:
- 282 kbps.
- 148 kbps.
Windows Media Encoder Se codifica con calidad:
- 282 kbps.
- 148 kbps.
Estacin de Radio:
Real Producer Se codifica con calidad:
- 36 kbps.
- 28 kbps.
- 20 kbps.
Windows Media Encoder Se codifica con calidad:
- 36 kbps.
- 28 kbps.
- 20 kbps.
ShoutCast Se codifica con calidad:
- 34 kbps.
Total: 1062 kbps.
Tabla 6.6.: Ancho de Banda Necesario del Sistema de Streaming.

124
El clculo necesario, para determinar si nuestra red cumple con los requisitos de
ancho de banda sera:
Ancho de Banda Requerido = 1062 * 1,5
Ancho de Banda Requerido = 1592 Kbps.
Ancho de Banda Requerido = 1.6 Mbps.
Por lo tanto, como nuestro Sistema de Streaming esta montado sobre una red local
LAN, en el cual el ancho de banda es 100 Mbps, contamos con el ancho de banda
necesario para realizar una correcta comunicacin entre los codificadores y el servidor
y el Real Server.











125










CAPITULO VII










126
7. Configuracin de Real Server para Transmisiones de Contenidos
Multimedia.
Para implementar un canal de televisin y una estacin de radio, se necesita del
servidor de contenidos multimedia, que se encarga de las negociaciones y trafico, tanto de
los clientes como de los productores generadores de las transmisiones en directo. Hoy en
da el mercado de Streaming se ve dominado por tres servidores claramente diferenciados:
Real Server o tambin conocido como Helix Server de Realnetworks, Windows Media
Server de Microsoft y el Quicktime Server de Apple. Para la implementacin de los
servicios de Streaming se ha optado por el servidor de Realnetwoks (Real Server V.9.0.5),
el cual puede gestionar los contenidos de Microsoft y Apple, emulando el comportamiento
de sus respectivos servidores. Con esto se logra abarcar un campo ms amplio al momento
de publicarlos a los usuarios, por la gran diversidad de reproductores que hoy en da
existen, siendo los productos de stas empresas las ms comunes y que se encuentran
presentes en la mayora de los sistemas operativos [29].
La administracin de Real Server se basa en una aplicacin Web (programacin
javascript y java) desde donde se configuran todos los parmetros necesarios para el
correcto funcionamiento del sistema, dependiendo de los servicios que se deseen prestar a
los usuarios. Para acceder por primera vez al servidor, el proceso de instalacin ha asignado
un puerto TCP aleatorio, que luego podremos cambiar si es necesario. Para que quede mas
claro, pondremos el siguiente ejemplo: mediante un navegador Web accedemos a la
direccin http://127.0.0.1:20333/admin/index.html, donde 20333 es el puerto de
administracin asignado automticamente en el proceso de administracin (mas adelante
127
veremos como cambiarlo para ajustarlo a nuestras necesidades y configurar el servidor de
manera correcta). Una vez se ha conectado con el servidor nos encontramos con la pgina
de inicio.

Figura 7.1.: Ventana de Configuracin de Real Server.

En sta pgina, a parte del mensaje de bienvenida y una serie de enlaces a paginas
tiles para contar con documentacin y consejos prcticos, podemos ver el men de acceso
a los distintos puntos de configuracin, administracin y ayuda del servidor, la direccin ip
(o DNS) del servidor actual (tras Current Real Server) y, en la parte superior, tres enlaces
comunes en toda la administracin:
i. Restart Server: Se utiliza siempre que se modifican parmetros fundamentales del
servidor (muy importantes si queremos que todo funcione correctamente).
ii. Reload Pages: Realiza una recarga de la pagina actual.
iii. Logo Real: Un enlace a la direccin de Internet http://www.realnetworks.com

128
A continuacin se mostrar la configuracin de cada uno de los parmetros para que
el canal de televisin y la estacin de radio puedan funcionar de forma correcta, abordando
los aspectos ms relevantes [30].
7.1. Server Setup:
En sta seccin se deben de establecer todos los parmetros necesarios para
que el servidor preste la funcionalidad requerida, adems de configurar todos los
servicios que ste nos entrega. A continuacin se explicar brevemente cada una de
las opciones de Server Setup.
i. Ports: Aqu se configuran los diferentes puertos TCP de los servicios de
archivos y sus protocolos de transmisin.

Figura 7.2.: Configuracin de los Puertos de Real Server.

A continuacin se detallan los protocolos y sus puertos que se deben
configurar:
129
- PNA (Progressive Networks Audio): Es el protocolo que se usaba para
las transmisiones de audio hasta la versin 5 de Real.
- HTTP (Hyper Text Transport Protocol): ste protocolo es el asociado a
los servicio Web del servidor.
- RTSP (Real Time Streaming Protocol): Es el protocolo que se utiliza
para las retransmisiones de archivos creados con Real G2 o superior (v7 y
v8). Es totalmente compatible con SMIL, Flash, etc.
- Monitor Port: Es el puerto que se utiliza para configurar y utilizar el
monitor de sistema.
- Admin Port: Es el puerto que se utiliza para administrar el sistema. Aqu
es donde se puede adecuar el puerto de administracin si es necesario.
Tambin, a la hora de implementar una poltica de seguridad, stos son los
puertos que se ha de tener en cuenta para abrir los firewalls de salida. Dentro
de ste apartado, la opcin Enable Ramgen Port Hinting URLs (por
defecto estar en yes) sirve para que los meta-archivos de tipo .ram se
comporten como si fueran aportados desde un servidor de Web en vez que
desde el servidor de Real. Los meta-archivos .ram son ficheros que
contienen diferentes llamadas al Real Server son normalmente servidos
desde servidores Web.
ii. Ip Binding: Aqu se indican las direcciones IP que el servidor Real podr
usar (interfaces).
130

Figura 7.3.: Configuracin de las interfaces de Real Server.
Esto es til si el servidor, adems de estar conectado a Internet (de aqu
obtenemos su direccin IP publica) lo est dentro de una o varias redes locales.
Por lo que introduciremos en sta pagina de configuracin todas aquellas
direcciones IP a las que el servidor responder. Es caso de que el administrador
del sistema requiere que el servidor responda a todas las interfaces disponibles,
se indicar la direccin 0.0.0.0. Sin embargo, desde Internet, no es posible (los
hackers estn al acecho) y se tendrn que limitar los posibles accesos mediante
corta fuegos y otros sistemas de seguridad. Como vemos indicado en rojo en la
parte inferior de la pgina, ser necesario reiniciar el servidor una vez que
introduzcamos las IPs de referencia. Para eso utilizaremos el enlace descrito al
principio.
iii. MIME Types: Los Multipurpose Internet Mail Extensions (MIME Types)
son las extensiones de archivo a las que el servidor Web har referencia.

131
Figura 7.4.: Configuracin de las extensiones de archivo de Real Server.
Ya que el servidor Real tambin incluye un servidor Web, como vimos
antes, deberemos indicarle los tipos de archivos que ste deber servir, de la
misma manera que si configuramos un servidor Web.
iv. Connection Control: sta es una pgina de configuracin de restricciones.
El servidor Real funciona mediante licencias, las que se adquieren mediante el
pago de las mismas a Realnetworks o sus distribuidores.

Figura 7.5.: Configuracin de las Restricciones de Real Server.

E sta pagina podemos limitar, tanto por numero de conexiones concurrentes
como por ancho de banda utilizado por el servidor. Esto es muy til a la hora de
ajustar el consumo en un servidor. Hay que tener en cuenta que es servicio de
Streaming es uno de los que ms ancho de banda utiliza. Por lo tanto, si tenemos
limitaciones en el ancho de banda que podemos consumir, aqu podemos hacer
dicha restriccin, independiente o no del numero de usuarios concurrentes que
aceptemos. Si no se desea limitar el ancho de banda se deja el valor en 0. La
132
opcin Real Player Plus Only hace referencia a si los archivos se pueden
visualizar con el reproductor Real Player gratuito.
v. Redundant Servers: Desde la versin 9.0 y posterior del Real Player, ste
detecta en el servidor, si existen otros servidores redundantes con los mismos
contenidos multimedia, a los cuales automticamente se reconecta en caso que
se efecte un error en la Red o el Servidor no responda.

Figura 7.6.: Configuracin de los servidores Redundantes.

En Alternative Servers se debe indicar la direccin IP del servidor
redundante o su direccin DNS, adems del puerto al cual el servidor responde.
En Redirect Rules se debe indicar cual es el Path (punto de montaje que
veremos mas adelante) del contenido multimedia que se desea relacionar. En
Exclude Paths se debe indicar que Path o punto de montaje dentro del
ingresado anteriormente que se quiere ignorar.
133
vi. Mount Points: sta pagina de configuracin es realmente importante, ya que
en ellos se almacenan los contenidos multimedia y a los cuales el usuario har
referencia (como directorios) para acceder a dichos contenidos multimedia. Los
Mount Points o Puntos Base podran ser descritos como directorios virtuales.
Para la emisin de contenidos en directo desde nuestro servidor o para videos
bajo demanda, ofreceremos diferentes tipos de contenidos, es por esto que
existen los puntos base, para clasificar la informacin (carpetas virtuales) y
organizarla en forma ordenada. Crearemos tantos puntos base como alias a
directorios reales del sistema, queramos hacer referencia. De sta manera, no
solo podemos separar los contenidos por tipo (o por cliente, en el caso que
queramos presentar servicios de ISP), sino que nos permite la utilizacin de
mltiples discos duros o volmenes sin complejidad alguna.

Figura 7.7.: Configuracin de los Puntos de Montaje de Real Server.

134
Al agregar un punto base (o punto de montaje) nuevo, debemos indicar el
nombre (alias) que va a tener dicho punto base (en primer casi es solo / para
indicar la raz la instalacin de Real Server lo pone por omisin en el
directorio Content, el cual puede ser cambiado), por ejemplo, queremos crear
un punto de montaje /audio video/. Indicaremos esto en el nombre del punto
base. Podemos asignarle una descripcin, por ejemplo: Contenidos Multimedia
de Marcelo Ziem, y en el Base Path le indicaremos la ruta real donde estarn
los archivos, por ejemplo D:\Real_Ziem. Notemos que el nombre del alias
empieza y termina por / al contrario que el Base Path. ste es un detalle
importante, ya que una vez creado el punto base y a su vez es reseteado el
servidor, los usuarios podrn llamar a los archivos all contenidos mediante una
llamada RTSP del tipo rtsp://servidor.dominio.com/audiovideo/archivo.rm.
vii. URL Aliasing: En sta opcin se puede asignar un alias a una direccin
dentro del servidor, lo cual implica cambiar el nombre de una llamada especfica
a un archivo al servidor a travs de un alias.

Figura 7.8.: Configuracin de los Alias de Real Server.

Se debe indicar una descripcin del alias, el alias y la direccin completa que
se quiere redireccionar.
135
viii. HTTP Delivery: Real Server, permite la difusin de contenidos multimedia
a travs de una va http (usando el puerto que se configur anteriormente), el
cual ser usado por el servidor como directorio virtual.

Figura 7.9.: Configuracin del Servicio Http de Real Server.

Se puede utilizar como servidor Web alternativo para servir paginas Web
con informacin confidencial (por ejemplo, para consultar externamente los
archivos log), para servir contenidos audiovisuales va http o para cualquier otro
servicio Web que se le ocurra. Hay que tener en cuenta que los directorios a los
que hace referencia HTTP delibery deben estar relacionados con el raz que
tenga resignado en Mount Points.
ix. Cache Directives: Cuando se desarrolla un sistema con Real Server, ste
sirve los contenidos multimedia cada vez que se le solicita, consumiendo tiempo
y recursos para realizar la peticin. Es por ello que Realnetworks cre una
aplicacin llamada Real Proxy que permite almacenar archivos de Streaming.
Aunque no forma parte del Real Server propiamente tal, puede trabajar con el
para compartir o repartir contenidos bajo demanda (por su infraestructura) de
forma que los usuarios puedan acceder al servidor ms cercano a ellos. Su
136
funcionamiento consiste en atrapar las peticiones de los usuarios y redirigir
esa peticin al servidor ms cercano. Adems se puede configurar para que
almacene los contenidos multimedia ms solicitados y reenviarlos a usuarios
que lo soliciten.

Figura 7.10.: Configuracin del cache de Real Server.

Para configurar adecuadamente los parmetros de Cache se debe introducir
lo siguiente: si no se desea que algn archivo o directorio (punto de montaje)
sean Cacheados se debe introducir el Edit Path una vez que se presiono el
botn agregar. De lo contrario, si se quiere que ningn contenido multimedia sea
Cacheado, se debe seleccionar Yes en Deny All Cache Request.
x. Media Samples: En ste apartado se muestran distintos ejemplos de servicio
que Real Server ofrece, sta opcin sirve para comprobar si se cuenta con todos
los CODECs necesarios para el funcionamiento del servidor. Entre los ejemplos
que se muestran, es la reproduccin de un archivo con CODEC Real Video 9,
la reproduccin de una animacin flash, la publicacin de medios a travs de
lenguaje SMIL, la reproduccin de contenidos de Microsoft a travs de
Windows Media Player.
137

7.2. Security:
En sta opcin se configuran tanto las opciones de identificacin de usuarios
para comunicarse con el servidor, como las reglas y restricciones asociadas a ellos.
Por defecto se crea el usuario administrador con los datos ingresados en la
instalacin. Se darn a conocer cada una de las opciones asociadas a la seguridad.
i. Access Control: Esta caracterstica es muy importante no solo para impedir el
acceso a los contenidos multimedia por parte de usuarios no deseados, sino que
mediante la reglas de acceso, se puede configurar qu servidores de
redundancia, tienen la posibilidad de comunicarse con nuestro servidor.

Figura 7.11.: Configuracin de las Reglas de Acceso de Real Server.

Primero se debe crear la regla (pulsando sobre +) e introducir el permiso o la
denegacin de acceso y las direcciones IPs de cliente, servidor y los puertos a
138
los que se aplica la regla. En caso que se requiera denegar o habilitar la regla a
cualquier direccin IP, se debe ingresar ANY. Para los puertos igualmente se
pueden reemplazar por ANY, para denegar o habilitar todos los puertos.
ii. User Databases: Real Server, por defecto, crea dos bases de datos de
usuarios autentificados para administracin y la codificacin de contenidos
multimedia. Estos usuarios son los que tienen privilegios de administracin del
sistema (automticamente se crea el usuario administrador en todas las bases de
datos) y los que pueden codificar contenidos en directo contra el servidor. Se
pueden comprar licencias que permitan la creacin de contenidos Pay-Per-
View (commerce) o protegidos mediante contrasea. Para ste tipo de
contenidos, debern existir bases de datos que autentifiquen a los usuarios que
han pagado para poder verlos.

Figura 7.12..: Configuracin de las Bases de Real Server.

Puede crear diferentes bases de datos que contengan informacin de los
usuarios. Para ello, debe asignarle un nombre, y se le informar al sistema que
tipo de base de datos es (Real Server permite 4 tipos diferentes de estructuras de
139
datos: Texto Plano, ODBC, MySQL y RN5 DB Wrapper) y el nombre del
archivo que contendr la base de datos. En caso que se opte por una base de
datos MySQL, se deben ingresar los datos necesarios para dicha conexin.
iii. Authentication: Para editar, crear o eliminar usuarios existe una pantalla
llamada Authentication en la que se puede acceder a la base de datos disponibles
en el servidor.
Existen seis bases de datos de autentificacin por defecto, de las cuales 3
son las ms relevantes: SecureAdmin que contiene la lista de usuarios con
permiso de administracin del sistema, SecureRBSEncoder que contiene la
lista de usuarios con acceso a la retransmisin de eventos en directo desde Real
Producer (o Helix Producer), y SecureWMEncoder que contiene la lista de
usuarios con acceso a la retransmisin de eventos en directo desde Windows
Media Encoder.

Figura 7.13.: Configuracin de los Usuarios de Real Server.

Como se mencion aqu puede crear usuarios con permiso a cada una de las
bases de dato mencionadas con anterioridad, pulsando sobre Add User. En
140
Change User Password se podr cambiar su contrasea. En Remove User
from Realm se eliminar un usuario especifico. Por ultimo en Browse User in
Realm se obtiene un listado de los usuarios de la base de datos seleccionada.
iv. Commerce: Esta opcin permite una serie de reglas de autentificacin y se
basa en una nueva base de datos que almacena permisos sobre contenidos bajo
demanda concretos, protegiendo directorios. Las caractersticas opcionales de
sta opcin de configuracin permiten: evaluar permisos, que los usuarios vean
o no contenidos desde IPs diferentes, tambin validar los contenidos desde el
Player y trabajar con archivos SMIL.

Figura 7.14.: Configuracin de las Reglas de Autentificacin de Real Server.

Con todas stas caractersticas se fijan las diferentes posibilidades de
proteccin de acceso a los contenidos multimedia. Esto es muy til, sobre todo,
para Streaming Pay-Per-View y Streaming de contenidos protegidos.

141
7.3. Logging & Minitoring:
Real Server nos da la posibilidad de monitorear lo que ocurre en el servidor,
las conexiones y archivos que se estn negociando en cada instante. Adems nos da
la posibilidad de crear archivos Log los que almacenen los errores o estados, para
el posterior anlisis de estadstica y reporte de errores, segn sea el gusto del
administrador del sistema. Estas opciones se analizaran a continuacin:
i. Server Monitor: Esta es la opcin que mas se usar tras tener los dems
aspectos del servidor configurados. Como su propio nombre indica, Monitor
sirve para mostrar datos relativos al trafico, las conexiones o archivos, que el
Server est manteniendo de forma activa (estn funcionando). Es muy
importante saber, sobre todo para los administradores de Firewalls o seguridad
en la red, que el monitor del Real Server utiliza un puerto distinto al de
administracin, por lo tanto, para configuraciones remotas se deber tener en
cuenta y abrirlo si queremos dar ste servicio a Internet.
Dentro de sta misma opcin, existen otras opciones adicionales que
mencionaremos a continuacin:
- Performance: Cuando se realiza un clic sobre la opcin Monitor, se abre
una pgina, que por defecto mostrar el rendimiento (performance) del
servidor.
142

Figura 7.15.: Monitor de Rendimiento del Sistema.

Se pueden apreciar diferentes aspectos, tales como utilizacin de
CPU (CPU Usage), memoria utilizada (Memory usage), ancho de banda
utilizado (Bandwidth Usage), nmero de Players o usuarios conectados
(Players Connected) y el nmero de archivos utilizados (File Usage). Como
se podr suponer, esta informacin es muy til para el administrador del
sistema y puede ser utilizada para generar alarmas cuando el rendimiento sea
bajo, estadsticas de consumo, estadsticas de archivos, etc., ya que toda la
informacin mostrada se guarda en archivos .log que luego podrn ser
analizados.
- Opcion Key: La opcin Key nos muestra una leyenda de colores
utilizados para mostrar la informacin anteriormente descrita. Estos colores
pueden ser seleccionados segn los gustos personales.
143

Figura 7.16.: Configuracin del Monitor de Real Server.
- Opcin Connections: La opcin Connections muestra una a una todas
las conexiones activas en el servidor. Ofrece informacin de la IP del cliente
conectado, el tipo de conexin (Player o Encoder), la duracin de esa
conexin y el archivo al que est conectado.

Figura 7.17.: OpcinConexiones Entrantes del monitor de Sistema.

- Opcin Files: La opcin Files muestra informacin de las conexiones
por archivos, indicando el nmero de conexiones actuales a un archivo, el
nmero total de conexiones y el pico mximo de conexiones concurrentes.
Esta informacin es muy valiosa para estadsticas y adems para saber si
estamos obrando sobradamente o en forma deficiente, dependiendo del
ancho de banda asignado a ste servicio.
144

Figura 7.18.: Opcin Archivos Utilizados del monitor de Sistema.
ii. Access & Error Logging: Evidentemente desde sta pgina se configuran
todos los parmetros relativos al almacenamiento de informacin de logs o
archivos de registro de actividad, generando la informacin de estadsticas,
acceso, utilizacin, consumo, etc., que se deseen obtener.

Figura 7.19.: Configuracin de los archivos log de Real Server.
Adems permite al administrador del sistema configurar las alarmas
necesarias en caso de cada de recursos o memoria. Cada punto de esta
configuracin se describe por si mismo y ser el administrador del sistema el
que decida cual es la mejor opcin en cada caso.
iii. Custom Logging: En sta opcin se configuran todos los archivos de
registro que se van a entregar al administrador. En ste tem, se puede agregar
145
los archivos asociados a distintos eventos en el servidor y con distintos
formatos. Para ello debe seleccionar el evento que desea registrar y adems dar
la ruta del archivo de salida y el formato del nombre que lo identificar.

Figura 7.20.: Configuracin de los archivos de Salida log de Real Server.

7.4. Broadcasting:
Siguiendo dentro de la configuracin del servidor, se encuentra la parte de
broadcasting, que define todos los parmetros necesario para la distribucin de
contenidos en directo (tanto con la tcnica de Broadcast, Multicast y Unicast). En
General Setup, se vio cmo definir los parmetros generales del sistema. All,
fueron definidos los puntos de montaje necesarios para la distribucin de contenidos
bajo demanda, pero Real Server tambin permite la retransmisin de contenidos en
directo (live). Esto es lo que define Broadcasting, y que necesitaremos para nuestro
canal de televisin y estacin de radio. Pulsando sobre Broadcasting se despliega un
146
men en que es posible configurar los siguientes puntos que se detallan a
continuacin.
i. Realnetworks Encoding: Esta pantalla de configuracin permite definir tanto
el punto de montaje desde donde las retransmisiones sern distribuidas, como el
puerto de comunicaciones y el time out tras el cual el servidor enviar un error
al codificador si ha existido problemas de comunicacin.
Evidentemente, si se decide, como se ver ms adelante, guardar los
contenidos que se retransmitan en directo (se debe tener en cuenta que los
archivos ocupan mucho espacio y, probablemente se podrn editar y darles ms
calidad y eliminar aquellas partes no significativas del mismo), el punto de
montaje deber existir.


Figura 7.21.: Configuracin de las retransmisiones de Real Producer.
De esta forma, si se escoge el directorio raz de sus puntos de montaje, para
visualizar la transmisin en directo se deber acceder desde una direccin URL
de la siguiente forma: rtsp://servidor.com/broadcast/directo.rm, donde el
147
punto de montaje predeterminado del servidor para realizar dichas transmisiones
se llama broadcast. En sta pantalla de configuracin tambin se indica qu
usuarios tienen derecho a realizar retransmisiones en directo. Como se vio con
anterioridad, en el apartado anterior de seguridad, se pueden definir usuarios y
aplicarles derechos dentro de la administracin y utilizacin del servidor. Ya
que se habla de seguridad, hay que tener en cuenta (los administradores de
sistemas, de comunicaciones, etc.) que stas retransmisiones utilizan un puerto
para comunicarse (4040, aunque puede ser otro), por lo que se debe abrir los
permisos necesarios en el Firewall para que la seal llegue a destino. La versin
9.05 de Real Server, que es la que se describe, ofrece la posibilidad de que
codificadores anteriores a la versin G2 del Real Producer tambin puedan
codificar eventos en vivo. Es una forma de mantener la compatibilidad con
versiones pasadas. Los parmetros de sta pantalla de configuracin deben
mantenerse por defecto (es lo ptimo, auque se puede adecuar a las necesidades
del administrador) para as obtener de forma eficiente dicha compatibilidad. Por
lo tanto, lo nico realmente importante de sta configuracin es la introduccin
de la contrasea (password) que permita la retransmisin.
ii. QT & RTP Encoding: Tras el acuerdo entre RealNetworks y Apple, Real
Server 8 y posteriores, son capaces de servir streams de Quicktime tanto en vivo
como en diferido. Para el servicio de archivos on-demand, el proceso es
completamente transparente.
148

Figura 7.22.: Configuracin de las retransmisiones para QuickTime.

Los archivos .mov, preparados para streaming son servidos desde los
directorios o puntos de montaje del servidor. Debido a que Apple usa la
tecnologa RTSP para el Streaming de los contenidos codificados con su
tecnologa, Realnetworks la ha implementado con facilidad en su servidor. Cabe
destacar que en cuanto a la transmisin en directo, la cosa va ms all. Real ha
implementado una seccin especial para la configuracin de ste tipo de
contenidos, ya que QuickTime usa archivos y configuraciones especiales para el
acceso a sus contenidos en directo. En la pantalla de configuracin se deben
introducir los siguientes parmetros:
- Mount Point (punto de montaje): Desde donde los live events en
QuickTime sern servidos.
- Base Mount Point (punto de montaje base): Es donde se almacenan los
archivos SDP, necesarios n la comunicacin entre el Encoder de QuickTime
(codificador) y el propio servidor.
- Connection Timeout: Se indica el tiempo de espera del servidor.
149
- Enable SDP Directory Scan: sta opcin debe estar activada, y no es ms
que habilitar la exploracin de los archivos SDP.
Para las retransmisiones en vivo para QuickTime, los contenidos multimedia
deben ser entregadas por un codificador o Encoder (Sorenson Broadcaster, por
ejemplo) , el cual debe comunicarse con el servidor para entregarle el stream del
contenido multimedia y adems entregarle un archivo SDP que establece los
parmetros de codificacin y servicio entre ambos extremos del evento. Real
Server 9.05 proporciona un acceso transparente de forma que el evento es como
si se estuviese realizando desde un QuickTime Server.
Para acceder a los archivos de QuickTime (tanto en directo como bajo
demanda) se debe utilizar el QuickTime Player o un plug-in para e navegador,
de manera completamente transparente con la direccin de tipo
rtsp://servidor.dominio.com/archivo.mov.
iii. Windows Media Encoding: En sta seccin se deben configurar los
parmetros para que Real Server se comporte y entregue servicios como si se
tratara de un Windows Media Server, para que reciba retransmisiones en directo
desde el codificador de Microsoft, Windows Media Encoder, o simplemente
entregar contenidos bajo demanda en formato Windows Media.
150

Figura 7.23.: Configuracin de las retransmisiones de Windows Media Encoder.

Como se menciono en secciones anteriores debe existir un usuario registrado
en la base de datos SecureWMEncoder, ya que al intentar publicar un medio
se necesita de autentificacin en el servidor. En general se debe ingresar el
punto de montaje que por defecto es /wmtencoder/, el puerto por donde se
realizar la comunicacin, el modo de autentificacin (SecureWMEncoder
por defecto). Conjuntamente con esto se debe especificar los datos del archivo y
la direccin IP del host que tiene acceso a la publicacin (en caso que se quiera
restringir el acceso a usuarios especficos).
iv. Live archiving: Como se ha comentado, Real Server ofrece la posibilidad de
guardar los contenidos ofrecidos en directo para su posterior utilizacin bajo
demanda. En sta opcin se puede activar el almacenamiento de dichos
contenidos multimedia.
151

Figura 7.24.: Configuracin de archiving de Real Server.

Para ello, debe indicar la ruta (path) donde se almacenarn los live events,
adems de realizar limitaciones de tamao y tiempo para as tener los archivos
de alguna manera organizados. No hay mucho ms que decir sobre sta
configuracin, salvo que la experiencia indica que aunque sta opcin puede
resultar til en determinadas ocasiones lo recomendable es tener para los
eventos en vivo, al menos un dispositivo de grabacin tradicional (VHS o
superior) para poder editar ese contenido y ponerlo a disposicin de los usuarios
de forma on-demand. Ciertamente lo mejor es pensar en TV, aunque para la
estacin de radio, al ser solo voz, no es tan necesaria la post-edicin. Por lo que
para eventos en vivo en un canal de televisin hay que contar con todos los
implementos televisivos disponibles: iluminacin, sonorizacin, mezcladores,
cmaras, editores, etc. Dependiendo del evento. Para un telediario no es
necesaria tanta infraestructura (aunque si se dispone de ella, la transmisin ser
eficiente). La manera correcta de pensar es que si se dispone de materia
152
profesional, se obtendr una mayor calidad y los objetivos quedarn mejor
cubiertos.
v. Broadcast Redundancy: sta opcin es una de las novedades ms
significativas de la versin 9.05 de Real Server. Mediante la configuracin de
codificadores redundantes podemos asegurarnos de que no va a haber cortes
en una retransmisin en directo.

Figura 7.25.: Configuracin de Codificadores Redundantes.
En sta pantalla de configuracin se activa la opcin de redundancia. Si se
habilita, se debe introducir los parmetros necesarios para su correcto
funcionamiento en caso de fallas, y que se detallan a continuacin:
- Timeout: Tiempo de espera (por defecto, muy bien dejado en 5 segundos).
- Delimeter: ste carcter indica la separacin entre el nombre del stream y
el numero de orden de reproduccin, en caso que se corte la retransmisin.
Por ejemplo, en el productor principal el stream se llamar por ejemplo,
live.rm.1y en el productor de redundancia se llamar live.rm.2.
- Reconnect: Se elige entre reconexin automtica o manual.
153
- Mount Point: Se debe indicar el punto de montaje donde se est
produciendo la redundancia. Esto significa debe existir tantos Encoders a un
evento en vivo como se desee (con el consiguiente consumo de ancho de
banda y contratacin de lneas).
- Error Message: Se debe ingresar el texto que mostrar el servidor al
momento de realizar la reconexin.
El proceso es sencillo, para analizar ste punto vamos a poner un ejemplo.
Supongamos que se esta generando una retransmisin en vivo con dos Encoders
(codificadores). Uno es el principal y el segundo es el de redundancia. Si por
cualquier motivo que sea se corta la comunicacin entre el codificador y el
servidor, los usuarios conectados saltan automticamente (si se ha
configurado el salto como automtico) al stream redundante. De esta forma no
se les corta la retransmisin. Para el usuario el proceso es completamente
transparente si usan un Player RTSP. Si usan un Player PNM (Real Player 5 o
anterior) se les mostrar un mensaje de retransmisin. Esto evita muchos
problemas a cambio de un gasto en comunicaciones e infraestructura mayor.
Evidentemente, si un error de ste tipo ocurre, el administrador del sistema
encontrar en el archivo log un mensaje indicativo del suceso. Por supuesto, este
tipo de caracterstica solo puede ser aplicado en eventos en vivo (directo).

7.5. Broadcast Distribution:
154
En sta seccin se va a proceder a explicar todo el proceso de configuracin
de la tcnica de splitting y multicasting. La tcnica de splitting permite configurar
los servidores de Real como transmisores o espejos de los contenidos en directo, de
forma que los usuarios se conecten con ms garanta a os contenidos y se descarga
el ancho de banda necesario en el servidor central y en cada uno de los incluidos en
la infraestructura.

Figura 7.26.: Esquema de la Arquitectura de Splitting.
En la imagen se puede ver como seria una arquitectura ejemplo, en la que
desde un servidor principal (contra el que se est realizando una retransmisor en
vivo) reparte la seal a un segundo Splitter que, a su vez, la reparte a otros tres y, al
mismo tiempo, a otros tres y, al mismo tiempo, a otros tres ms individuales. De
sta forma tendramos 6 servidores de borde (edge servers) a los que se conectaran
los usuarios directamente usando Internet. Evidentemente, ste acceso no se
produce de forma automtica.
155
En las pginas de acceso a ste contenido habr que indicar a qu servidor se
tiene que acceder. Una forma, la ms obvia, es que existan pginas diferentes
dependiendo de la regin donde se acceda. Pero otra solucin posible y fcil es
programar un filtrado de la direccin IP del usuario para as encaminarlo a su
servidor ms cercano.
sta tcnica es valida solo para retransmisiones en directo. Para los
contenidos bajo demanda (on-demand) es necesario programar algn servicio de
caching que reparta dichos contenidos por nuestra infraestructura. Esto no lo hace
Real Server por si mismo. Para interconectar mediante splitting los servidores se
pueden usar tres tipos distintos de protocolos: UDP Unicast, UDP Multicast y TCP.
UDP Multicast es la ms eficaz, pero se debe conocer la arquitectura de red para
saber cual de ellas es factible de utilizar.
Real Server est preparado para poder interconectar los servidores usando
cualquier red IP. As que se podra utilizar Internet para ste propsito. Es posible
que esto suene a inseguro, pero si contamos con buenas comunicaciones sta
configuracin funciona. Otro tema crtico es el de las licencias. Si vamos a usar los
servidores de cabecera (head servers) solo como servidores principales de splitting,
estos solo consumirn las licencias de los servidores de borde que les conectemos.
Ser en los servidores de borde (donde se conectan los usuarios) donde deberemos
tener las licencias instaladas.
En Real Server 8 o G2, en la configuracin de los splitters existen dos
mtodos de comunicacin: Pull y Push. Esto ha desaparecido en la versin 9.05
debido a que RealNetworks ha decidido automatizar las comunicaciones entre
156
servidores haciendo principal al transmisor (Transmitter) y dejando que el/los
receptores (Receiver) funcionen como secundarios, configurando todo en un nico
sitio. Por consiguiente y debido a todos estos cambios tanto en el transmisor como
en el receptor debe existir un servidor Real Server 9.05, perdiendo as la
compatibilidad con las versiones anteriores. Comenzaremos a ver como son las
pantallas de configuracin de los dos tipos de configuracin de los splitters.
i. Opcin Transmiter: En esta pantalla se realizan los procesos de
configuracin de cada uno de los receptores que estarn conectados al
transmisor.

Figura 7.27.: Configuracin de los Receptores de Splitting.
En su primer paso, solo debe darle nombre al transmisor (lo normal es darle
el mismo nombre que tiene como maquina en si). En un segundo paso, se debe
157
proceder a configurar cada uno de los receptores que estarn conectados a su
transmisor. Debe comenzar por ponerle nombre al receptor. Se debe indicar que
punto de montaje del mismo ser el origen de las retransmisiones. Se incluye la
direccin IP del receptor y el mtodo de transmisin de datos, por defecto es
UDP Unicast, pero se puede cambiar (por UDP Multicast o TCP dependiendo
de las necesidades). Las comunicaciones UDP son mucho ms estables y
seguras por su propia arquitectura. Esto es importante para los administradores
de Firewalls, ya que se tendr que indicarles el puerto o rango de puertos que
vamos a utilizar para las retransmisiones de forma que nos dejen abiertas las
reglas de entrada/salida de datos entre los servidores. Real recomienda no usar
TCP a no ser que sea estrictamente necesario o disponga de una red de absoluta
confianza. Si utiliza Multicast debe rellenar el valor TTL (Time To Live) del
Multicasting. TTL significa que cada vez que un paquete de datos es enviado a
travs del router multicast, el valor se decrementa en 1 hasta llegar a cero. En
ese momento el router descarga el paquete. El valor por defecto es 16 y es
valido para la mayora de configuraciones. Puede guiarse por la siguiente tabla:
Valor TTL Rango de Paquetes
0 Localhost
1 Red local (subnet)
32 Site
64 Regin
128 Continente
255 Mundo
Tabla 7.1.: Tabla del valor TTL de una Red Multicast.
Los siguientes parmetros opcionales indican lo siguiente:
158
- Error Correction Rate: Es el porcentaje de correcciones en los paquetes
enviados. Un valor alto de ms garanta de transmisin a cambio de un
consumo mayor de ancho de banda. En una red local podra ajustarse a cero
e ir subiendo hasta ver cuanta correccin de errores es necesaria.
- Metadata Transmit Rate: Es una frecuencia en segundos en los paquetes
especiales son transmitidos al receptor. Estos paquetes especiales describen
el stream que est siendo retransmitido y que es requerido por el receptor
para procesar dicho stream. Un nmero pequeo da como resultado un
menor tiempo de espera a cambio de consumo de ancho de banda. Lo
normal es usar un rango entre 1 a 60 segundos dependiendo de los tiempos
de latencia de la red usadas para las transmisiones de datos.
- Honor Resend Requests: Sirve para mejorar la calidad del servicio
haciendo que los receptores resoliciten los paquetes que hayan llegado en
malas condiciones. Si activamos esta caracterstica deber tener un back-
channel entre el transmisor y el receptar lo que implica un pequeo aumento
en el consumo de ancho de banda.
- Port Range: Indique el rango de puertos que va a ser usado en las
comunicaciones entre ambos servidores. Este rango debe ser de, al menos,
20 puertos.
- Security Type: La siguiente casilla indica si se quiere dar seguridad bsica
a stas conexiones. En caso afirmativo, se debe introducir la contrasea que
permite el acceso. En la parte del receptor se debe conocer los siguientes
datos:
159
a. Nombre del transmisor y direccin IP del mismo.
b. Tipo de transporte.
c. Rango de puertos.
d. Seguridad.
e. Contrasea.

- Pull Transmiter: Entramos en la tercera parte de la configuracin donde
se debe introducir el nombre del stream (en Edit Source Name) que quiere
que se retransmita en modo Pull, la ruta origen desde donde se va a servir
el stream, el puerto por el que nuestro transmisor debe escuchar, la seguridad
y contrasea de acceso al contenido.

ii. Opcion Receiver: En la otra parte, en las recepcin de los streams emitidos
por el transmisor, debe tambin introducir los parmetros necesarios que
permitan la comunicacin entre ambos. As como un transmisor puede
transmitir streams a varios receptores, un receptor puede recibir live streams.
Los clientes accedern al contenido de la forma:
rtsp://servidor.dominio.com/punto_montaje/nombre_stream.rm
160

Figura 7.28.: Configuracin de los Transmisores de Splitting.

En la parte del Broadcast Transmiters tiene que ir configurando cada uno
de los retransmisores de los que desea recibir su seal. Usando los datos que
debe conocer del transmisor introduciremos su nombre, su direccin IP o
hostname. Se incluir un Netmask (Mascara de Red) si quiere indicar un
rango de direcciones IPs de transmisiones y el tipo de protocolo de
comunicaciones (incluyendo la direccin Multicast si es el protocolo elegido).
Es posible activar el reenvo de paquetes (esto no tendr efecto si no est
activado tambin en el transmisor). Por ultimo, el tipo de seguridad y la
contrasea para acceder al contenido.
161
En la tercera parte de la configuracin se puede activar el Pull Splitting. Se
introduce el punto de montaje que usar en los enlaces al contenido. Adems de
rellenar la informacin de los campos anteriores, se puede usar los campos
opcionales:
- Error Correction Rate: Es la cantidad de paquetes corregidos enviados.
Un nmero alto ofrece mayor calidad a cambio de mayor consumo.
- Metadata Transmit Rate: Al igual que el transmisor, es la frecuencia en
segundos en la que los paquetes especiales son transmitidos al receptor.
Estos paquetes especiales describen es stream que est siendo retransmitido
y que es requerido por el receptor para procesar dicho stream. Un numero
pequeo da como resultado un menor tiempo de espera a cambio de
consumo de ancho de banda. Lo normal es usar un rango entre 1 a 60
segundos dependiendo de los tiempos de latencia de la red usadas para la
transmisin de datos.
- Pull Splitting Backchannel Transport: Si se desea el envo de paquetes
especiales o de control, se debe utilizar TCP, ser necesario usar un
backchannel para estas comunicaciones y una red de datos de alta seguridad.
El splitting es una tcnica que permite la distribucin automtica de
contenidos en directo usando toda la arquitectura de servidores. Si se cuenta
con una RPV (Red Privada Virtual) se podr ajustar al mximo todos los
parmetros descritos. Si no, se debe utilizar los valores Standard para ofrecer
a sus usuarios a travs de Internet el acercamiento de los contenidos.
162
iii. Scalable Multicasting: En el multicasting escalable, no existe un control del
canal entre el Player y el servidor. Por esta razn, el nmero de clientes que
pueden recibir un multicasting escalables es ilimitado. Se debe usar sta opcin
cuando la audiencia es demasiado extensa y cuando la opcin de multicasting
est habilitada.

Figura 7.29.: Configuracin del Multicasting Escalable.

Para calcular el nmero de direcciones IP y puertos que necesitemos,
debemos basarnos en el nmero de streams de nuestro broadcast. El Broadcast
Escalable requiere un nmero continuo de puertos, y que estn libres y
accesibles a travs del Firewall. El numero de puertos requeridos depende del
163
tipo de archivo y el numero de bit rates del productor de medios. Es por ello
que necesitamos reservar el rango de puertos.
iv. Back Channel: Back Channel Multicast mantiene un control TCP entre el
Real Server y los clientes, pudiendo ser stos Players o Receivers. Mientras
que los streams se emiten usando UDP (generalmente) los datos de control,
como vimos antes, se transmiten mediante TCP a travs de ste Back Channel
Multicast. Esto es til cuando se desea la autentificacin de usuarios o cuando se
retransmite a un nmero limitado de clientes.

Figura 7.30.: Configuracin del Back Channel Multicast de Real Server.

164
En pantalla de configuracin debe indicar si desea o no activar el Back
Channel y el SAP (Session Announcement Protocol) o Protocolo de Anuncio de
Sesin que sirve para anunciar a los programas de escucha la emisin de un
evento Multicast. Se debe indicar los puertos PNA (para clientes antiguos) y
RTSP por donde se van a retransmitir los eventos, el rango de IPs para el back-
channel, el TTL (Time To Live) que debe ser el mismo que el especificado en el
router Multicast, si se producen o no reenvo de datos y si los datos solo se
envan o hay comunicacin bidireccional.
v. Windows Media Multicasting: La tcnica de Multicasting es una opcin
alternativa al tradicional Broadcast para que mltiples usuarios se conecten y
reproduzcan contenidos en vivo conservando el ancho de banda, ya que el flujo
de streams va dirigido a un grupo de usuarios. Real Server se puede configurar
para transmitir a travs de la tcnica de Multicast a Windows Media Player. El
estilo de multicasting se puede configurar en el apartado donde se configuro la
tradicional transmisin unicast.
165

Figura 7.31.: Configuracin de Multicasting para Windows Media.

vi. Session Announcement: Si se decide anunciar los eventos Multicast se debe
introducir en sta pantalla todos los parmetros necesarios, como son: Direccin
IP del servidor (de su servidor) y si sta informacin ser publicada bajo SAP o
quiere escuchar otras publicaciones bajo SAP de la red.

Figura 7.32.: Configuracin del Host Multicasting para Windows Media.

7.6. Content Management:
166
Real Server permite la configuracin de puntos de montaje a disposicin de
clientes, para lo cual se necesita una configuracin especial, con los permisos
pertinentes. En ste apartado se mencionarn los aspectos mas importantes para que
los posibles clientes puedan servir sus contenidos multimedia en forma transparente,
sin necesidad de complejas configuraciones.
i. Content Caching: En sta opcin se configura y habilita la transferencia de
contenidos multimedia entre dos o ms Real Server, si se quiere tener otros
servidores que sirvan como espejo del contenido de nuestro servidor en caso que
se corte la transmisin, o en caso que se est utilizando la tcnica de splitting.
Para ello se debe ingresar los datos del otro servidor quien publicar los
contenidos, con su respectivo nombre de usuario y contrasea, adems del
puerto por el cual se establecer la comunicacin. En caso que falle la conexin
se redirecciona el cliente al servidor que publicar los medios. Adems se debe
configurar la regla de acceso con la cual se comunicarn.

167
Figura 7.33.: Configuracin de los Servidores Espejo.

ii. ISP Hosting: Como se menciono anteriormente, Real Server se puede
configurar para prestar servicios de Streaming a clientes. Por lo tanto, si se
quiere rentabilizar el servidor y las licencias ofreciendo el servicio a terceros
(posibles clientes), deber acceder a sta parte de la configuracin e introducir la
informacin necesaria para que stos puedan servir sus archivos de Streaming
con total transparencia.

Figura 7.34.: Configuracin de los Servicios de Streaming Hosting.
De sta forma, se puede ofrecer a nuestros clientes un acceso FTP exclusivo
para que puedan subir sus archivos y servirlos con total transparencia (solo para
video bajo demanda). Esto se debe a que ISP Hosting permite realizar la
relacin entre el punto de montaje y el nombre del cliente (o usuario) de la
forma rtsp://servidor.dominio.com/~nombre_cliente/archivo.rm. La
informacin necesaria que se tiene que introducir es la siguiente:
168
- User List Files Names: Describe la estructura de la cuenta del cliente
(usuario) y los clips de video disponibles para cada cuenta. Esta
configuracin se guarda en archivos de texto (localizados en el directorio
asignado a cada cuenta) que debe contener lo siguiente:
a. Nombre de la cuenta.
b. Path virtual desde donde se servirn los archivos.
c. Nmero mximo de conexiones simultaneas.
- Translation Mounts: Indica el punto de montaje y descripcin desde
donde se van a servir los archivos.
iii. Content Browsing: En la imagen se aprecia la pantalla de configuracin de
acceso a contenidos. Esta parte es solo accesible bajo autentificacin.

Figura 7.35.: Configuracin de Publicacin de Medios.

Es prctico ya que se obtiene inmediatamente una relacin de contenidos
directorio a directorio. Se debe indicar los puntos de montaje a los que se quiere
tener acceso y las extensiones que se quieran mostrar. Dicha pantalla se obtiene
169
tambin al seleccionar Browse Content. La informacin que se muestra en
sta opcin es importante para la posterior conexin entre grupos de servidores.
iv. View Source: En la imagen se puede ver la pantalla de configuracin general
para sta parte.

Figura 7.36.: Configuracin del Comportamiento de Real Server.

En el nivel inferior se ve, que se puede establecer un comportamiento
general del servidor haciendo que el cdigo fuente sea visible (o lo contrario) en
todos los directorios y puntos de montaje. Pero se permite usar configuraciones
especficas para cada directorio individual.



7.7. Advertising:
Una de las caractersticas poco conocidas de Real Server es la posibilidad de
establecer una conexin con servidores de publicidad (ad-servers) para insertar
170
banners, otros videos o flash de manera automtica y ajustndose a campaas
predefinidas en cada contenido multimedia que sea solicitado por los usuarios. Esto
es realmente practico ya que el administrador de las campaas de publicidad y el
administrador de Real Server no tienen por que interferirse. Por un lado se disearn
las campaas de publicidad y por el otro se dar servicio a travs de Real Server.
Mediante programacin SMIL se generarn las llamadas, tanto al propio contenido
audiovisual a mostrar en el Real Player como a la publicidad a insertar. El proceso
de funcionamiento del Adversiting con Real Server se divide en:
a. El usuario accede a la informacin audiovisual y lanza el Real Player que
solicita el contenido multimedia al Real Server.
b. El Real Server toma el contenido del Host Server. El archivo SMIL con el
contenido incluye la peticin de un banner.
c. El Real Server toma la informacin del banner desde el Server.
d. El Real Server busca los banners en el Host Server.
e. El Real Server compila los SMIL del contenido y los banners en un solo
archivo SMIL con la informacin del contenido que el usuario va a ver.
f. El archivo SMIL resultante es ejecutado y su contenido enviado al usuario.
Aunque aparentemente pueda resultar complicado, el proceso es transparente
al usuario y los administradores tanto de las campaas de publicidad como del Real
Server solo debern manejar informacin homognea para que el resultado sea el
esperado. Veamos ahora como son y para qu sirven las distintas pantallas de
configuracin del Real Server.
171
i. Ad Serving: La opcin Ad Serving es una de las partes principales de la
configuracin de los servicios de publicidad con Real Server. Previamente a lo
que aqu se comenta, la campaa de publicidad deber ser creada en su servidor
ya que se har referencia directa a ellas.

Figura 7.37.: Configuracin de los Servicios de Publicidad de Real Server.

Como se ve en la imagen lo primero que se hace es crear un punto de
montaje (Mount Point) y darle una descripcin. El campo target HTML se
complementa con la URL de la campaa de publicidad (la llamada normal, con
http://direccion, etc.). Tras esto, se debe seleccionar el tipo de servidor de
Advertising y adems indicar SI o NO en Resolver Relatives URLs,
dependiendo si estamos usando o no enlaces relativos (lo normal es que si).Otra
caracterstica es que la publicidad puede ser mostrada en forma rotativa, es
decir, que se puede configurar si se van a abrir banners secuenciales en el
tiempo o se va a servir solo uno. Por lo tanto, se debe indicar en sta pantalla si
se activa o no la opcin antes mencionada y cada cuanto tiempo debera cambiar
172
el banner. Adems se debe indicar el bitrate con el cual ser enviado y la
primera imagen que ser servida.
De sta manera ya se contar con un Punto de montaje para servir la
publicidad creada en la campaa indicada. Ahora solo falta enlazar la publicidad
con los contenidos audiovisuales reales. Esto se hace mediante Programacin
SMIL. A continuacin se muestra un pequeo ejemplo de cmo realizar sta
tarea para as tener una idea clara del funcionamiento de sta configuracin.
- Ejemplo de archivo SMIL: El siguiente ejemplo muestra un archivo
SMIL que servir un banner en la parte superior y un video en la parte
inferior de la ventana de visualizacin. Para integrar el banner en la
presentacin audiovisual, se podr crear una regin SMIL en donde se
muestre el banner o banners rotativos. El archivo SMIL del ejemplo crea una
regin para el banner sobre la regin del video, la cual tiene unas
dimensiones de 320 pxeles de ancho por 240 pxeles de alto. La regin del
banner es de 468 pxeles de ancho por 60 pxeles de alto:
<smil>
<head>
<!-- Presentacin con video clip y ad banner
<layout>
<root-layout width=488 height=330 background-color=black/>
<region id=ad_banner top=10 left=10 width=468height=60/>
<region id=video_region top=80 left=84 width=320height=240/>
</layout>
</head>
173
<body>
<par>
<RealAdInsert region=ad_banner dur=9:00:0 fill=freeze/>
<videosrc=rtsp://servidor.com/videos/archivo.rmregion=video_region/>
</par>
</body>
</smil>

Figura 7.38.: Ejemplo de Archivo SMIL

De sta manera muy sencilla y prctica el administrador de
publicidad podr insertar publicidad en video, audio y flash.
ii. Ad SMIL Generador: Otra posibilidad es la creacin dinmica y automtica
de archivos SMIL para su integracin con publicidad. Por ejemplo si se tiene
una gran cantidad de archivos con un mismo tipo de contenido, se puede usar
sta caracterstica para insertar un pre-roll, banner o video de presentacin.

Figura 7.39.: Configuracin de la Generacin Automtica de Archivos SMIL
174

En la imagen se puede ver el tipo de parmetros que se deben configurar. En
la configuracin predeterminada, ya se cuenta con tres tipos (distintos) de Ad
SMIL Insertion que se pueden crear. En sta pantalla de configuracin se
puede bien cambiar los parmetros ofrecidos o crear los nuestros propios. Se
basarn los ejemplos con los que vienen predeterminados.
Hay algunas limitaciones con ste tipo de inserciones. Por ejemplo no estn
soportadas las inserciones publicitarias entre medio de una transmisin en
directo (intersticiales), lo cual se podra lograr si el administrador creara sus
propios cdigos de insercin de publicidad. Por otra parte, con ste tipo de
inserciones solo se puede activar una a la vez. Adems se puede crear una
insercin de banner rotativo, pero no dos banner simultneos de cualquier
tipo. Para los banners de posicionamiento del clip desaparecer del Player. Una
vez visto esto, se deben configurar los parmetros. Como en el punto anterior, se
debe configurar los puntos de montaje precisos. Tres son los tipos de inserciones
que se pueden realizar, pero es posible que necesite organizarlos de alguna otra
manera y por eso podemos crear los puntos de montaje necesarios aqu. De
hecho, para organizar los diferentes tipos de banners, ya sea por tamao o la
posicin en el Player, se necesitar crear ms puntos de montaje que los agrupe
por tipo, para que as nuestros contenidos multimedia queden ordenados.
- Tipo de Contenido a Servir: A continuacin se indicar el tipo de
contenido a servir. Banner (para imgenes estadsticas), Lead-In (para
entradas) y Rotating Banner (para banners rotatorios). Se indica la
175
posicin en la que ser servido, su tamao los mrgenes en pxeles que se
desea darle y el color de fondo. Si se fija en los parmetros que se ha creado,
la manera de usarlos ser la siguiente:
<a
href=http://servidor.dominio.com/ramgen/adtag/general/smilgen/banner/
video/video.rm>.

Figura 7.40.: Ejemplo de una llamada a un Contenido Multimedia.

Donde /ramgem/ significa que el servidor debe activarse para
generar algn tipo de archivo (.ram o .smi), /adtag/general/ determina el
tipo de anuncio que se va a usar video.rm tal y como quedo definido en el
punto anterior (Ad Serving) y /smilgen/banner/ indica es streaming mount
point en el propio enlace. Como se ve, las llamadas se hacen mediante
enlaces TCP y no RTSP (que el servidor no encontrara). Ya se encarga el
propio servidor de realizar las llamadas adecuadas mediante SMIL generado
automticamente.
- Generacin Automtica de Cdigos: Como ya se ha visto Real Server
permite la generacin de cdigo automticamente. ste cdigo, as como el
que se le introduzca para mostrar los contenidos, puede o no ser ocultado a
ojos extraos. En fase de pruebas se puede dejar activada sta posibilidad,
para chequear el cdigo generado o ver como se ejecuta el cdigo
176
introducido por nosotros. Obviamente una vez que se est trabajando en
produccin, lo razonable ser desactivar toda visualizacin de cdigo fuente.
iii. Ad Timeouts: En sta pantalla se le indica al Real Server los tiempos de
espera que deber tener con el servidor de publicidad. Esto es importante para
limitar dicho tiempo de espera en caso de problemas de conexin. El valor
predeterminado de 10 segundos es el adecuado en la mayora de los casos,
aunque en sta opcin se permite cambiar a gusto del administrador.

Figura 7.41.: Configuracin de los Tiempos de Espera del Servidor de
Publicidad.









177










CAPITULO VIII












178
8. Codificacin de Contenidos Multimedia con Real Producer.
La empresa propietaria del sistema de Streaming RealNetworks pone a dispocisin
de los usuarios varias herramientas para la creacin de contenidos audiovisuales. Real
Producer es una poderosa herramienta que permite la creacin de contenidos audiovisuales
en directo y en diferido.

Figura 8.1.: Ventana Principal de Real Producer.

En la figura se ve la pantalla principal de ste programa, en la que se pueden
descartar las dos ventanas de video donde, una vez en produccin, se ver tanto la fuente de
video original (izquierda) como la comprimida (derecha) adems de poder introducir
determinados parmetros como el titulo del clip, los bitrates a los que ser codificado, el
tipo de imagen que contiene etc.
Las posibilidades de entrada son dos: Devices que permite seleccionar
dispositivos de entrada de audio o video del sistema o conversin de archivo Input File
179
que permite seleccionar el archivo (avi, mov, mpeg, etc.) de entrada que se desea convertir.
En la salida (Output) se debe indicar si grabar la conversin en un archivo RealMedia o
realizar la transmisin en directo desde las tarjetas de captura hacia el servidor de
Streaming. Para ello se debe introducir los datos necesarios relativos al servidor. Tal y
como se puede apreciar en la pantalla de entrada del Real Producer, se ofrece la posibilidad
de seleccionar qu tipo de trabajo es el que se desea efectuar.
Una vez que se ha seleccionado el tipo de trabajo que se va a realizar (esto es
posible hacerlo siempre abriendo una nueva sesin) pasar directamente a la pantalla
principal del programa, que se describe en las siguientes lneas.
Adems de los mens habituales de los que consta el programa, la pantalla principal
muestra, en la parte superior, dos ventanas de video y un nivel de audio. Cuando el
programa est en funcionamiento (codificando), stas ventanas muestran la entrada de
video (izquierda) y la salida codificada (derecha). En el centro, se puede ver el nivel de
entrada de la fuente de sonido.
Para la creacin de archivos .rm se pueden hacer dos cosas, convertir un archivo
ya montado con algn programa de edicin (Premiere, VideoStudio, etc.) o digitalizar
directamente con Real Producer material en cinta. Para eventos live se usar Real
Producer directamente. Por lo tanto existen tres tipos de producciones diferentes [31]:

8.1. Conversin de Archivos:
La conversin de archivos es aquella en la cual se transforma un archivo audiovisual
que no es de formato Real Media a un formato que si lo es (.rm, .ra, etc.), adems de
180
codificarlo para distintas audiencias, para su posterior publicacin bajo demanda o en
falso-directo (Ver el apartado 1.2 del Capitulo I). Para realizar una conversin de
archivos, los pasos que se deben seguir son los siguientes:
i. Seleccionar la Fuente: Contando con que el sistema ya dispone del archivo a
convertir, el primer paso es seleccionar dicho archivo. Se puede convertir archivos
de diferentes formatos (.avi, .mov, .qt, .wav, .au, .mpeg, .mpg).

Figura 8.2.: Seleccin de la Fuente de Contenidos Multimedia.

ii. Seleccionar la Salida: Conjuntamente con esto se debe seleccionar el directorio
de salida del archivo convertido. El programa, por defecto selecciona el directorio
del programa.

Figura 8.3.: Seleccin de la Salida del Contenido Multimedia.

181
iii. Datos del Clip: Al pulsar sobre el botn Clip Information se debe introducir
la informacin acerca del clip. sta informacin ser mostrada posteriormente por el
Real Player de los Usuarios.

Figura 8.4.: Ingreso de los Datos del Contenido Multimedia.

Estos datos se mostrarn en el reproductor del cliente (usuario) de manera
informativa y siempre pueden servir, tanto al usuario como al creador, de referencia
o informacin adicional a la hora de elaborar y difundir sus trabajos. Los campos
Description y Keywords funcionan de la misma manera que los campos meta-
tag de una pgina Web y sirven para introducir una descripcin textual del
contenido del Clip y una lista de palabras clave para su localizacin en buscadores
multimedia, por poner un ejemplo sencillo. ste paso es similar para la
Digitalizacin Directa a un Archivo, Retransmisiones en Falso-Directo y
Retransmisiones en Directo que se vern mas adelante.

iv. Seleccionar Audiencias: Tras pulsar el botn Audiences se debe indicar las
diferentes tasas de transferencia a los que el archivo ser codificado, ya que puede
182
ser transmitido a distinta calidad dependiendo del estado de la red. Adems se
puede seleccionar el tipo de audio y calidad del video del archivo.

Figura 8.5.: Seleccin de las Audiencias (ancho de Banda).

En la parte superior, adems se encuentra la opcin de ajustar el audio y el
video. Se dispone de cinco diferentes posibilidades de configuracin de la calidad
de audio y otras para video. La calidad tanto del audio y el video estn basadas en
un balanceo entre el consumo de ancho de banda para uno y otro. Por ejemplo, si se
quiere retransmitir o crear un archivo para usuarios que poseen un modem de
56Kbps, se dispone de un ancho de banda limitado para hacerlo (lo normal es entre
34 y 37 kbps). Por lo tanto, no ser factible superar ste consumo en la creacin del
archivo o la retransmisin. As, lo nico que se puede hacer es balancear el gasto de
ancho de banda que se tiene que asignar para el audio y el video. A ms ancho de
183
banda asignado para audio, menor calidad de video (que se podr resolver
disminuyendo el tamao del mismo). Entonces, dependiendo del tipo de contenido
que tenga el Clip que se elabore y de la necesidad de una mayor o peor calidad de
sonido o audio se podr ajustar ese balanceo. Las posibilidades para ajustar la carga
de audio son:
- Voice Only (solo voz): Est pensado para Clips del tipo solo voz (con
video) o audio de bajas necesidades (solo audio).
- Music: Pensado para ofrecer mas calidad de audio que de video.
- No Audio: Obviamente, podemos crear Clips sin sonido. De esta manera
damos todo el ancho de banda al video.
Con el video ocurre lo mismo y existen otras cinco posibles configuraciones:
- Normal Motion Video: Diseado para la mayora de los Clips.
- Sharpest Image: Se aplicar un realce de la imagen. Pensado para secuencias
de poca luz que necesiten un ajuste del contraste.
- Smoothest Motion: Aplicar un suavizado a la imagen para lograr una mayor
claridad. Est pensado para videos con alto movimiento que necesitan ser
suavizados.
- Slide Show: Esta opcin est pensada para mostrar imgenes estticas en
secuencia.
- No Video: Como en el apartado de voz, se puede indicar al programa que se va
a crear una secuencia con audio solamente.

184
Real Producer permite seleccionar el CODEC de compresin de video a
utilizar. Evidentemente la utilizacin de la ltima versin de CODEC es adecuada.
Esto tiene sus pros y sus contras. Para la creacin del canal de televisin y la
estacin de radio nos estamos basando en la versin 9 del Real Producer y la
versin 9.05 del Real Server. Evidentemente cuando se produce un cambio de
versin tan drstico como el del CODEC, la primera vez que un usuario accede a un
contenido realizado con ste, deber actualizar su sistema para poder
descomprimirlo adecuadamente (de otra manera no podr verlo). Real hace esto de
forma automtica. Lo que quiere decir, que conecta el player con un centro de
descargas para su actualizacin en lnea.
El programa ofrece tres opciones: Real Video 8, Real Video G2, que
mantiene la compatibilidad con las versiones anteriores del Player y Real Video G2
con SVG (Scalable Video Technology) que ofrece ajustes automticos del tiempo
de muestreo de los fotogramas, tamao del fotograma y perdida de paquetes,
ofreciendo la mxima calidad a usuarios de la versin anterior del Player.
Se pueden configurar otras opciones ms del CODEC:
- 2-pass encoding: Como su nombre indica, realiza dos pasadas, una de anlisis
y otra de codificacin al origen de video para ajustar el CODEC al mximo (sta
opcin se deshabilita automticamente en retransmisiones en directo).
ste paso es similar para la Digitalizacin Directa a Archivo,
Retransmisiones en Falso Directo y Retransmisiones en Directo que se vern
ms adelante.
185
v. Opciones de Video: Real Producer incluye unos sencillos y eficaces filtros de
video que permiten mejorar la calidad de las secuencias creadas.

Figura 8.6.: Configuracin de la Ventana de Video de Real Producer.

En Video Noise Reduction (reduccin del ruido en el video) se puede
mejorar la calidad de las secuencias de la siguiente manera:
- Low: Es la opcin que se debe mantener siempre seleccionada por tratarse de
la ms adecuada. Significa que se aplicar un ajuste de niveles moderado al
origen de video sin casi afectar a la calidad. A no ser que el origen de video sea
de excelente calidad o ya est pre-procesado, se debe aplicar ste filtro.
- High: Aplica un ajuste de niveles ms severo y est indicado para retocar
orgenes de video ms defectuosos, con ruido u otros problemas.
Las otras dos opciones de filtrado disponibles son:
- Inverse-Telecine: Est indicada para los casos en los cuales se codifica
material a 30 fps y lo convierte a 25fps. ste filtro elimina los fotogramas
redundantes.
186
- De-interlance Filter: Elimina artificialidades generadas en PAL o NTSC. No
es aplicable a videos menores de 240 pxeles o a videos no entrelazados.
vi. Comienzo de la Codificacin: Una vez configurado los parmetros anteriores
en la pantalla principal del programa, al pulsar el botn Encode comenzar la
conversin.

8.2. Digitalizacin Directa:
Adems se permite crear un archivo .rm directamente desde las fuentes de audio y
video disponibles en el sistema. Los pasos que se debe seguir para la correcta
digitalizacin de nuestros contenidos multimedia son los siguientes:
i. Especificar Origen: En el caso del canal de televisin se debe especificar el
origen del audio y el origen del video, pudindose configurar el dispositivo (tanto de
video como de audio) presionando sobre el botn Settings. Cuando se estn
codificando entradas por los dispositivos externos y no mediante archivos
audiovisuales, la mejor manera de ajustar el volumen de entrada es desde ste
punto. Evidentemente para el ajuste y control de las entradas de video se podr
acceder directamente desde el programa al controlador, como ms adelante se ver.
187

Figura 8.7.: Configuracin del Dispositivo de Audio.

Tambin se puede usar otros programas externos que muestren el estado del
volumen en tiempo real, para saber si estos ajustes estn bien hechos pues, el estado
del volumen en Real Producer, no se activa hasta que se comience con la
codificacin.
En Settings de la tarjeta capturadota de video se accede a su controlador
(driver), para realizar los cambios en su configuracin, dependiendo de los
resultados que se busquen.
Dependiendo del modelo que se disponga se obtendr pantallas de
configuracin diferentes. Se tiene que ajustar la entrada de video, el tamao y la
compresin de la entrada, entre otros parmetros. Lo mejor ser consultar la
documentacin de la capturadota para obtener toda la informacin (muchas veces
sta informacin se puede encontrar en la Web del fabricante).
Obviamente en caso de una estacin de radio, se debe seleccionar solamente
el audio y en Video se debe seleccionar None. Para el caso del canal de
188
televisin se debe seleccionar el dispositivo de entrada para el audio, y el
dispositivo de entrada de video (como muestra la figura):

Figura 8.8.: Ejemplo de Seleccin de los Dispositivos de Entrada.

Como se puede apreciar, la nica diferencia del primer tem, es en la
configuracin de la entrada, en la que en lugar de seleccionar el archivo de origen a
convertir, se tiene que seleccionar los orgenes del audio y video de los dispositivos
del sistema.
ii. Seleccionar la Salida: El resto de los pasos son idnticos a los realizados en el
tem Conversin de Archivos (por lo que no se profundizar ms en el tema), en
el cual se debe seleccionar el directorio, con el nombre del archivo de salida que
ser codificado. Conjuntamente con esto se debe configurar las Audiencias a las
cuales el contenido multimedia codificado ser transmitido, los filtros especiales
que se quieran aplicar al Video, y la informacin referente al Clip resultante.

189
Figura 8.9.: Configuracin de la Salida a Archivo.

iii. Comienzo de la Codificacin: Una vez configurado los parmetros anteriores
en la pantalla principal del programa, al pulsar el botn Encode comenzar la
conversin, generndose el archivo .rm en el directorio especificado.
ste sistema es til para digitalizar directamente un Clip de una cinta de
video, VCD o DVD. El formato de archivo de Real no es editable con facilidad y,
aunque existen medios para arreglar los posibles defectos de la captura, es preferible
trabajar capturando en un formato editable (.avi), generar el montaje necesario y
convertir el archivo resultante usando el primer apartado.

8.3. Retransmisin en Falso-Directo:
Las retransmisiones en falso-directo transmiten un video almacenado en disco a
todos los usuarios por igual, simulando una transmisin en vivo (ya que la fuente de
transmisin no proviene de los dispositivos de captura). Los pasos a seguir para una
correcta transmisin son los siguientes.
i. Seleccionar la Fuente: El proceso comienza de la misma manera que en el
primer tem, donde se debe seleccionar el archivo en disco que se quiere entregar al
cliente.
190

Figura 8.10.: Seleccin de la Entrada de Archivo.

ii. Parmetros de Conexin con el Servidor: A continuacin se deben introducir
los parmetros que conecten el Real Producer con el Real Server, para que ste
entregue los contenidos multimedia a los usuarios.

Figura 8.11.: Seleccin de la Salida a Servidor.

Para ello se debe borrar la salida a fichero y presionar el botn Add Server
Destination e ingresar el Nombre DNS o direccin IP del Servidor, Puerto de
Codificacin, Nombre del Archivo, Usuario y Contrasea.
191

Figura 8.12.: Configuracin de la Conexin con el Servidor.

Cabe destacar, que los parmetros como el puerto y el usuario de
codificacin estarn de acuerdo con los configurados en el servidor Real Server, tal
y como se vio en el capitulo Transmisin de Contenidos Multimedia con Real
Server.
En cuanto a la configuracin de la salida, las Audiencias, la Informacin del
Clip y el Filtro de Video es similar a la descrita en el primer tem.
iii. Comienzo de la Codificacin: Una vez configurado los parmetros anteriores
en la pantalla principal del programa, al pulsar el botn Encode, el Real Producer
se pondr en contacto con el Real Server especificado para comenzar la
retransmisin en falso-directo.

192
8.4. Retransmisin en Directo:
Real Producer ofrece la posibilidad de efectuar la retransmisin de eventos en
directo llamado Live Streaming (lo que nos interesa para el canal de televisin y
estacin de radio). A continuacin se darn a conocer los pasos a realizar para la
correcta retransmisin en directo:
i. Seleccionar la Fuente: El proceso comienza por seleccionar los orgenes de
audio y/o video de los dispositivos conectados y que estn disponible en el sistema,
segn sea el inters del administrador.

Figura 8.13.: Seleccin de la Fuente de Contenidos Multimedia.
.
ii. Parmetros de Conexin con el Servidor: Adems se deben introducir los
parmetros que conecten al Real Producer con el servidor de Streaming Real Server,
que es el encargado de realizar la retransmisin en directo.

193
Figura 8.14.: Seleccin de la Salida a Servidor.

Para ello se debe borrar la salida a archivo y presionar el botn Add Server
Destination e ingresar el DNS o direccin IP del servidor, Puerto de
codificacin, Nombre del archivo, Usuario y Contrasea.

Figura 8.15.: Configuracin de la Conexin con el Servidor.

Los parmetros como el puerto y el usuario de codificacin estarn de
acuerdo con los configurados en el servidor.
En cuanto a la configuracin de la salida, las audiencias, la Informacin del
Clip y el Filtro de Video es similar a la descrita en el primer tem.
iii. Guardar Transmisin a Archivo: Cuando se realizan retransmisiones en
directo usando Real Producer, tambin se cuenta con la posibilidad de guardar el
archivo .rm de la propia retransmisin agregando una salida a archivo como se
194
explico en el tem anterior. Esto como ya se haba mencionado, es muy til para
poder colocar ste nuevo contenido en diferido en el servidor, una vez que se
termine la retransmisin en directo.
iv. Comienzo de la Codificacin: Una vez configurado los parmetros anteriores
en la pantalla principal del programa, al pulsar el botn Encode, el Real Producer
se pondr en contacto con el Real Server especificado para comenzar la
retransmisin en directo.

8.5. Opciones Adicionales:
En conjunto con todas las opciones de codificacin anteriormente mencionadas,
existen otras, las cuales nos permiten configurar Real Producer segn nuestras
necesidades. Estas opciones deben ser modificadas con cuidado, una mala utilizacin
podr dar como resultado un comportamiento errneo.
Dentro de la ventana Audiences se puede configurar cada uno de los parmetros
de dichas audiencias, para personalizar su comportamiento segn las necesidades de los
usuarios. Para ello se debe presionar sobre el botn Edit Adience Job . sta
opcin nos va a permitir ajustar los parmetros de consumo de ancho de banda para
clips de audio y de video. sta es la opcin a la que se hacia referencia anteriormente y
que permite ajustar al milmetro los parmetros de codificacin para que los archivos
tengan la mxima calidad.
195

Figura 8.16.: Configuracin de una Audiencia en Particular.

Existen dos tipo de ajustes de archivos los cuales se mencionan a continuacin:
a. Audio/Video Encoding: Aqu se deben configurar los parmetros adecuados,
cuando se codifica tanto el audio como el video, maximizando el consumo de ancho
de banda. Se tiene que asignar el nmero mximo de fotogramas por segundo
(Target frame rate) para cada audiencia.

Figura 8.17.: Configuracin de la Velocidad de Muestreo de Frames.
Tal vez en sta pantalla sea recomendable cambiar los parmetros por
defecto del programa, ya que estn pensados para la norma NTSC de video. La
siguiente tabla muestra unos valores adecuados para la norma PAL.
196
Target Audience Max. Framerate
28K Modem 8 fps
56K Modem 12.5 fps
Single RDSI 12.5 fps
Dual RDSI 15 fps
Corporate LAN 25 fps
ADSL (todos) 25 fps
Tabla 8.1.: Valores de Frame Rate para la norma de Video PAL.

La opcin Target Bitrate permite ajustar el consumo total del ancho de
banda de cada audiencia.

Figura 8.18.: Configuracin del Consumo de Ancho de Banda de cada Audiencia.

Adems se deben indicar la calidad de compresin tanto para el CODEC de
audio como de video.

Figura 8.19.: Configuracin de la Calidad de Compresin del CODEC.

Conjuntamente con esto existe otra opcin adicional llamada Advance
Video Options, cuyos valores avanzados se pueden cambiar segn sea la
experiencia del usuario, Maximum startup latency, permite cambiar el tiempo de
197
recuperacin, en segundos, de un stream codificado. Maximum time between key
frames permite especificar el tiempo mximo entre fotogramas clave (keyframes)
en milisegundos.

Figura 8.20.: Configuracin Avanzada del Video.

Los parmetros por defecto se ajustan al 99,9% y solo se deben cambiar
cuando se est muy seguro de lo que se quiere conseguir.
b. Audio Only Encoding: Para la configuracin de los parmetros de audiencia de
audio, se ofrecen distintas opciones para ajustar las diferentes calidades de solo
audio. As, si se desea dar una mayor o menor calidad a una determinada opcin
(por ejemplo Stereo Music) se podr ajustar aqu.

Figura 8.21.: Configuracin del CODEC de audio para solo Voz.

198
Al igual que en el tem anterior, se puede ajustar la calidad de compresin
del CODEC de audio, para retransmisiones de solo voz, como lo es la transmisin
de una estacin de radio.
Una vez configurados todos los parmetros, si el usuario estima que stos
parmetros sern definitivos para cada transmisin con sta audiencia, se debe
guardar los cambios efectuados presionando el botn Save As Template.
















199










CAPITULO IX











200
9. Codificacin de Contenidos Multimedia con Windows Media Encoder.
El Windows Media Encoder (desde ahora lo llamaremos WME) es una herramienta
que permite a la arquitectura de Streaming producir la informacin bsica para los distintos
servicios que ofrecen los Servidores de Streaming de Microsoft. WME permite convertir
imgenes, audio y videos, ya sea en vivo o grabado, en el formato de Windows Media, para
que puedan ser vistos mediante la tecnologa de Streaming o simplemente para ser bajados
[32].

Figura 9.1.: Ventana Principal de Windows Media Encoder.

Como se puede ver en la imagen, al igual que el codificador de RealNetworks,
WME cuenta con una ventana principal con distintos paneles segn la tarea a realizar, la
imagen muestra la codificacin de un archivo de video a otro con formato Windows
201
Media, stos paneles se muestran o esconden en forma automtica segn el trabajo de
codificacin.
Como habamos visto en tems anteriores, el WME se comunica con el servidor de
Streaming de Microsoft llamado Windows Media Server el cual se ocupa del traspaso de
informacin con los usuarios, adems de las negociaciones de sesin con ellos,
transmitiendo los contenidos multimedia producidos/codificados por el WME a travs de
dicho servidor. Es por ello que RealNetwoks ha compatibilizado su servidor de Streaming
Real Server con aquellos usuarios que trabajan con WME, sin necesidad de instalar el
servidor de Microsoft, comportndose ste de igual forma, comunicndose con el WME y
Windows Media Player sin ningn problema, abarcando un trozo enorme del mercado
actual.
WME posee la capacidad de transmitir archivos variando los bits del contenido
dependiendo de las necesidades, lo cual garantiza la mejor compresin del medio
transmitido.
Existen dos formas de codificar Contenido Multimedia, a travs de unos asistentes o
en forma manual. Primero veremos la primera opcin, en el apartado Opciones del
Programa veremos los aspectos ms importantes de la configuracin manual, ya que de
sta forma se pueden agregar ms detalles que los asistentes no entregan. Bsicamente con
el WME, podemos utilizar cinco modos de captura y codificacin, los cuales sern
explicados a continuacin.

9.1. Conversin de Archivos:
202
sta opcin permite convertir un archivo multimedia de formato .avi o .mpeg a
un formato Windows Media, ya sea .wmv, .wma, .wav y almacenarlo local o
remotamente a travs de un directorio virtual (punto de montaje). Los pasos a seguir para
convertir archivos audiovisuales son los siguientes:
i. Seleccionar la Fuente: Se debe indicar el archivo de entrada, el cual ser codificado,
y adems se debe indicar la ruta y el nombre del archivo de destino.

Figura 9.2.: Seleccin de las Fuentes de Entrada.
ii. Mtodo de Distribucin: Se debe especificar de una manera ms natural el mtodo
de distribucin, segn los formatos de codificacin y de acuerdo al tipo de aplicacin
que se quiera utilizar.
203

Figura 9.3.: Seleccin del Mtodo de Distribucin.
iii. Seleccionar Audiencias: Se debe especificar las opciones de codificacin,
indicando el tipo de audiencia que recibir el medio, que puede ser desde alta calidad
hasta velocidad MODEM. Conjuntamente con esto se puede personalizar los CODECs
a utilizar, pudindose codificar a una nica velocidad o a mltiples velocidades (a
distintas Audiencias).

Figura 9.4.: Seleccin de las Audiencias.
204
iv. Informacin del Clip: Se debe indicar la informacin de meta-datos del medio, o
mejor dicho se debe indicar la informacin tanto del autor, como del contenido
multimedia mismo.

Figura 9.5.: Ingreso de la Informacin del Contenido Multimedia.
v. Resumen del Proceso: Al presionar Siguiente se muestra un resumen de la tarea a
codificar, estando listos todos los parmetros necesarios para la conversin. Al
presionar sobre el botn Finalizar se activaran en la ventana central de la aplicacin
los paneles necesarios de la codificacin.
vi. Codificacin: Si todos los parmetros ingresados anteriormente estn correctos, se
habilitar el botn Start Encoding. Una vez que se presione sobre l, comenzar la
conversin del archivo.

9.2. Digitalizacin Directa:
WME adems nos permite capturar, codificar y almacenar local o remotamente
(Capture Audio or Video). Esto quiere decir, que podemos capturar directamente de nuestra
205
tarjeta de sonido o tarjeta capturadota, y convertir la informacin proveniente de stos
dispositivos en un archivo con formato Windows Media. Los pasos del asistente para
realizar el proceso de digitalizacin directa son los siguientes:
i. Seleccionar la Fuente: Se debe indicar los dispositivos de captura disponibles en el
sistema, tanto de video como de audio, dependiendo si se trata de la estacin de radio o
del canal de televisin.

Figura 9.6.: Seleccin de los Dispositivos de Entrada.
Otra opcin adicional en sta pantalla es la de configuracin del dispositivo. Para
ello, basta con presionar sobre el botn Configure y se abrir la ventana de
configuracin, que es especfico para cada dispositivo.
ii. Seleccionar la Salida: Se debe indicar el nombre del archivo de salida, adems de la
ruta (path) especifica donde se quiera guardar.
206

Figura 9.7.: Seleccin del Archivo de Salida.
ii. Mtodo de Distribucin: Se debe especificar de una manera ms natural el mtodo
de distribucin, segn los formatos de codificacin y de acuerdo al tipo de aplicacin
que se quiera utilizar.

Figura 9.8.: Seleccin del Mtodo de Distribucin.
iii. Seleccionar Audiencias: Se debe especificar las opciones de codificacin,
indicando el tipo de audiencia que recibir el medio, que puede ser desde alta calidad
hasta velocidad MODEM. Conjuntamente con esto se puede personalizar los CODECs
207
a utilizar, pudindose codificar a una nica velocidad o a mltiples velocidades (a
distintas Audiencias).

Figura 9.9.: Seleccin de la Audiencia.
iv. Informacin del Clip: Se debe indicar la informacin de meta-datos del medio, o
mejor dicho se debe indicar la informacin tanto del autor, como del contenido
multimedia mismo.

Figura 9.10.: Ingreso de la Informacin del Contenido Multimedia.
v. Resumen del Proceso: Al presionar Siguiente se muestra un resumen de la tarea a
codificar, estando listos todos los parmetros necesarios para la conversin. Al
208
presionar sobre el botn Finalizar se activaran en la ventana central de la aplicacin
los paneles necesarios de la codificacin.
vi. Codificacin: Si todos los parmetros ingresados anteriormente estn correctos, se
habilitar el botn Start Encoding. Una vez que se presione sobre l, comenzar la
digitalizacin del archivo.

9.3. Capturacin de Pantalla:
Otra novedosa funcin que se puede efectuar con el WME es la de capturar la
pantalla del computador (Capture Screen) y convertir dicha informacin capturada a un
archivo multimedia. Esto es til para transmitirla a un servidor de Streaming para su
posterior difusin a los usuarios a travs del mtodo de falso-directo. Dentro de los pasos
que se deben efectuar desde el asistente son los siguientes:
i. Seleccionar el Mtodo de Captura: Lo primero que se debe realizar es seleccionar
el modo con el cual se capturar la pantalla, existiendo tres mtodos u opciones:

Figura 9.11.: Seleccin del Mtodo de Captura.
A continuacin se detallan cada una de stas opciones:
209
a. Capturar una Ventana Especfica (Specific Windows): Se puede elegir el
capturar desde una aplicacin que se este ejecutando en el momento, para ello se
muestra una lista de todos los procesos en primer plano o aplicaciones del usuario
disponibles.

Figura 9.12.: Seleccin de la Ventana a Capturar.
Como se ve en la imagen, se ha seleccionado capturar la informacin
proveniente de la ventana asociada a la ejecucin de un documento de Word.
b. Regin de la Pantalla (Region of the Screen): Otra opcin es la de capturar a
partir de una regin especifica de la pantalla.

Figura 9.13.: Seleccin de la Regin de la Pantalla a Capturar.
210
Se debe indicar desde qu coordenada se quiere capturar, el ancho y largo en
pxeles de dicha captura. Una opcin adicional muy til, es la de poder seleccionar
con el Mouse el rango de la pantalla que se quiere capturar, calculando
automticamente los valores tanto de coordenadas, como las dimensiones de la
captura.
c. Toda la Pantalla (Entire Screen): Se puede capturar la pantalla en su totalidad,
til para demostraciones y tutoriales va Streaming. Es por ello que se pasa
inmediatamente a la segunda etapa.
ii. Seleccionar Salida: Despus de seleccionar el modo de captura de pantalla, se debe
indicar la ruta y el nombre del archivo a generar.

Figura 9.14.: Seleccin de la Salida.
iii. Seleccionar Calidad: El proceso de capturar pantalla, demanda un alto consumo de
recursos de hardware del sistema, por lo que existe la posibilidad de indicar el nivel de
calidad de captura deseado.
211

Figura 9.15.: Configurar la Calidad de Captura.
iv. Informacin del Clip: Al igual que en los tems anteriores, se debe indicar la
informacin de meta-datos del medio, o mejor dicho se debe indicar la informacin
tanto del autor, como del contenido multimedia mismo.

Figura 9.16.: Ingreso de la Informacin del Contenido Multimedia.

v. Resumen del Proceso: Al presionar Siguiente se muestra un resumen de la tarea a
codificar, estando listos todos los parmetros necesarios para la conversin. Al
212
presionar sobre el botn Finalizar se activaran en la ventana central de la aplicacin
los paneles necesarios de la codificacin.
vi. Codificacin: Si todos los parmetros ingresados anteriormente estn correctos, se
habilitar el botn Start Encoding. Una vez que se presione sobre l, comenzar la
captura de pantalla.

9.4. Retransmisin en Directo:
Las retransmisiones en directo, son esencialmente las que ocuparemos con mayor
nfasis en la creacin de nuestro canal de televisin y estacin de radio, ya que permite la
captura, codificacin y transmisin en tiempo real de nuestros contenidos multimedia a los
usuarios (Broadcast a Live Event). Estos contenidos provienen de nuestros dispositivos
capturadotes y de edicin, permitindose opcionalmente el almacenar el medio, en un
archivo para su posterior difusin. Los pasos a seguir para transmisiones en vivo son los
siguientes:
i. Seleccionar la Fuente: Se debe indicar los dispositivos de captura disponibles en el
sistema, tanto de video como de audio, en caso que se quiera configurar la transmisin
en directo para el canal de televisin. Para el caso de la estacin de radio, obviamente se
seleccionar solo el dispositivo de audio.
213

Figura 9.17.: Seleccin de las Fuentes de Entrada.
Como ya se menciono anteriormente, al seleccionar un dispositivo de entrada,
adicionalmente se puede configurar cada uno de stos, presionando en el botn
Configure.
ii. Seleccionar el Mtodo de Transmisin (Broadcast): Para la retransmisin en
directo, el WME se debe poner en contacto con el servidor de streaming, para entregarle
el contenido multimedia codificado.

Figura 9.18.: Seleccin del mtodo de Distribucin.
Existen dos mtodos de comunicacin:
214
a. Push: Se debe seleccionar sta opcin, cuando el codificador (WME),
explcitamente identifica al servidor e inicia la transmisin, se requiere conocer el
servidor y de autentificacin.
b. Pull: Se debe seleccionar sta opcin, cuando el servidor o un Player
(Reproductor) inician la transmisin.
iii. Configurar Conexin: Posteriormente se debe ingresar todos los datos referentes a
la configuracin del servidor, los cuales fueron adecuados para la correcta
comunicacin entre el codificador (WME) y el servidor (Real Server).

Figura 9.19.: Ingreso de los Datos de Autentificacin con el Servidor.

Los datos que se deben ingresar en ste apartado, fueron configurados en el tem
Windows Media Encoding donde se explic la configuracin del servidor. En
Server Name, se debe indicar la direccin IP del servidor, adems del puerto por el
215
que el WME se comunica con dicho servidor. En Publish Point se indica el punto de
montaje configurado en el servidor, el cual ocupa el WME para alojar el stream.
Adems se debe indicar el nombre del stream multimedia al que el usuario querr
acceder. En Copy settings from se indica el punto de montaje predeterminado del
servidor.
iv. Seleccionar Audiencias: Se debe especificar las opciones de codificacin,
indicando el tipo de audiencia que recibir el medio, que puede ser desde alta calidad
hasta velocidad MODEM. Conjuntamente con esto se puede personalizar los CODECs
a utilizar, pudindose codificar a una nica velocidad o a mltiples velocidades (a
distintas Audiencias).

Figura 9.20.: Seleccin de las Audiencias.
v. Seleccionar Salida a Archivo: WME al igual que su homologo Real Producer,
permite almacenar el contenido multimedia en disco, para que este disponible
posteriormente y as transmitirlo a los usuarios por diferido (bajo demanda).
216

Figura 9.21.: Seleccin de Salida a Archivo.
Esto es realmente til cuando se quiere editar el contenido multimedia que se
transmiti en vivo, y presentarlo posteriormente como un resumen o repeticin de lo
presentado.
vi. Informacin del Clip: Se debe indicar la informacin de meta-datos del medio, o
mejor dicho se debe indicar la informacin tanto del autor, como del contenido
multimedia mismo.

217
Figura 9.22.: Ingreso de la Informacin del Contenido Multimedia.

vii. Resumen del Proceso: Al presionar Siguiente se muestra un resumen de la tarea
a codificar, estando listos todos los parmetros necesarios para la conversin. Al
presionar sobre el botn Finalizar se activaran en la ventana central de la aplicacin
los paneles necesarios de la codificacin.
viii. Autentificacin: Al activarse los paneles principales, el WME se comunicar con
el servidor de Streaming para realizar la autentificacin del usuario, que desea
transmitir a travs de l. Es por ello que el codificador pedir ingresar el nombre de
usuario y contrasea, que nos validan como un usuario con los permisos necesarios para
realizar dicha transmisin.

Figura 9.23.: Ventana de Autentificacin con el Servidor.

Cabe destacar, que los datos asociados a los usuarios con permisos de transmitir en
vivo, fueron configurados en el servidor, en la base de datos SecureWMEncoder (en
el apartado Authentification del capitulo de configuracin del servidor).
218
ix. Codificacin: Si todos los parmetros ingresados anteriormente estn correctos, se
habilitar el botn Start Encoding. Una vez que se presione sobre l, comenzar la
retransmisin en directo. Para acceder a ellos se encontrarn disponibles a travs de un
enlace Web del tipo: http://direccion:puerto/punto_montaje/archivo.vmx, por
ejemplo: http://localhost:8080/wmtencoder/tv.wmv. Otra opcin es la de conectarse
directamente desde el reproductor multimedia, abriendo la direccin del tipo:
mms://direccion/punto_montaje/archivo.wmx, por ejemplo:
mms://localhost/wmtencoder/tv.wmv.

9.5. Retransmisin en Falso-Directo:
Las retransmisiones en falso-directo, son transmisiones en vivo de un archivo
almacenado en disco. Esto quiere decir que si varios usuarios se conectan en cualquier
momento, vern el mismo contenido al mismo tiempo. En el caso del canal de televisin,
esto es ms til, ya que en la mayora de los casos, los videos son editados para su posterior
transmisin.
Las retransmisiones en falso-directo pueden verse confundidas con la difusin de
contenidos bajo demanda (on-demand), ya que ste mtodo igualmente ocupa un archivo
multimedia para la transmisin, pero con la diferencia, que las retrasmisiones en falso-
directo son producidas por el codificador hacia el servidor para su posterior difusin, en
cambio las transmisiones bajo demanda, son archivos montados en el servidor y no
producidos por el codificador en el instante que son transmitidos hacia los usuarios. Cabe
destacar, como se menciono anteriormente, que la diferencia principal radica en la manera
219
en la que el servidor entrega los contenidos multimedia a los usuarios. Las retransmisiones
en falso-directo entregan la misma informacin a los usuarios a cada instante, en cambio la
difusin bajo demanda, entrega un flujo distinto de informacin a cada usuario en un
instante dado.
En los tems anteriores, se ocupo los asistentes para las distintas
transmisiones/codificaciones, pero en el caso de retransmisiones en falso-directo, el WME
no cuenta con un asistente para ello, por lo que debemos hacerlo manualmente. Cabe
destacar, que la forma de generar un contenido multimedia, que se explicar a continuacin
abarca la configuracin general del sistema sin asistentes, por lo que lo explicado en tems
anteriores, tambin lo puede generar de sta forma, solo cambiando algunos parmetros.
Los pasos a seguir para las retransmisiones en falso-directo son los siguientes:
i. Abrir Nueva Sesin: Se debe abrir una nueva sesin y seleccionar una tarea en
blanco (Custom Session), esto quiere decir, sin ninguna configuracin predeterminada.
Al realizar esto se nos abrir y activar el panel de propiedades en la pantalla principal.
ii. Seleccionar la Entrada: En la pestaa Source se debe seleccionar: el tipo de
entrada por el que se capturar el contenido multimedia a codificar, el nombre de la
sesin, y la accin que efectuar el codificador (WME) al llegar al final de la
codificacin.
220

Figura 9.24.: Seleccin de la Entrada en el Panel Principal.
Como se ve en la figura, se muestran los distintos tipos de entradas posibles, por lo
que seleccionaremos en Source from la opcin file. Despus de ello, debemos
indicar la ruta completa del archivo que se quiere difundir a los usuarios.
iii. Seleccionar la Salida: Una vez configurada la opcin anterior, se selecciona la
pestaa Output, en donde se debe configurar el tipo de salida y los datos pertinentes a
ellas.
221

Figura 9.25.: Ingreso de los Datos del Servidor.
Al igual que en las retransmisiones en directo se debe indicar que el codificador
debe entregar los streams al servidor (metodo Push) e ingresar los datos configurados
en el Real Server para la correcta comunicacin entre ste y el WME (que fueron
explicados con ms detalle en el tem retransmisiones en directo).
iv. Seleccionar Audiencias: Como es habitual, se debe indicar hacia que audiencias
est destinada la retransmisin. La eleccin de las tasas de transferencia, se efecta de
acuerdo a los tipos de usuarios a los que esta destinada la transmisin y el ancho de
banda disponible.
222

Figura 9.26.: Seleccin de las Audiencias en el Panel Principal.
v. Opciones de Concl: Cuando se est transmitiendo video, como es el caso del canal
de televisin, existe la posibilidad de disminuir las dimensiones del video, agregndole
un borde con las dimensiones deseadas.

Figura 9.27.: Configuracin avanzada del Concl.
Se debe indicar el mtodo con el cual se va ha efectuar el redimensionado del video,
adems de las coordenadas que stas abarcarn. sta opcin no es usada con mucha
frecuencia, por lo que se elige dependiendo del objetivo que se quiera lograr.
223
vi. Informacin del Clip: Se debe indicar la informacin de meta-datos del medio, o
mejor dicho se debe indicar la informacin tanto del autor, como del contenido
multimedia mismo.

Figura 9.28.: Ingreso de la Informacin del Contenido en el Panel Principal.
vii. Autentificacin: Una vez presionado el botn Apply, el WME se comunicar
con el servidor, por lo que pedir el nombre de usuario y contrasea, que nos validan
como un usuario con permisos para transmitir. Cabe destacar que los datos de usuarios
fueron configurados en el servidor, en la base de datos SecureWMEncoder (en el
apartado Authentication del capitulo de configuracin del servidor).

Figura 9.29.: Ingreso de los Datos de Autentificacin con el Servidor.
224
viii. Codificacin: Una vez terminado el paso anterior, estar lista la configuracin
necesaria para comenzar la retransmisin en falso-directo, por lo que solo hay que
presionar Concl Encoding. Al igual que en las retransmisiones en directo, para
acceder a ellos se encontrarn disponibles a travs de un enlace Web del tipo:
http://direccion:puerto/punto_montaje/archivo.vmx, por ejemplo:
http://localhost:8080/wmtencoder/tv.wmv. Otra opcin es la de conectarse
directamente desde el reproductor multimedia, abriendo la direccin del tipo:
mms://direccion/punto_montaje/archivo.wmx, por ejemplo:
mms://localhost/wmtencoder/tv.wmv.













225
Conclusin.
Luego de terminar la investigacin sobre la tecnologa de Streaming para la creacin
del Canal de Televisin y la Estacin de Radio, y adems evaluar cada uno de los puntos
que conforman su arquitectura se puede concluir lo siguiente. La tecnologa de Streaming
es un avance tecnolgico muy sofisticado que nos permite compartir nuestros archivos
audiovisuales de forma inmediata, sin necesidad de bajar el archivo antes de reproducirlo.
Es por ello que sta tecnologa nos permite entregar nuestra emisin de forma instantnea a
nuestros usuarios, asegurando una cierta calidad de servicio, que depende principalmente
del ancho de banda disponible, tanto por el usuario, como del servidor que se ha instalado.
Para realizar ste cometido, se debe contar con tres mdulos claramente
diferenciados y que forman una parte esencial de nuestro sistema. En primer lugar se
necesita un servidor de Streaming que se encargue de entregar los flujos de datos
provenientes de nuestras estaciones emisoras a los usuarios y de maximizar el ancho de
banda disponible. Para ello es factible utilizar el servidor de Streaming perteneciente a la
empresa RealNetworks, que adems de entregar el servidor, nos entrega los dems
componentes necesarios para la estructura del sistema. Otro componente o mdulo
importante, es el de los codificadores que se encargan de digitalizar la informacin o seal
analgica, comprimirla (de acuerdo a complejos algoritmos matemticos) y entregarla al
servidor. Entre los codificadores con los que se realizo el sistema, son Real Producer
perteneciente a la empresa RealNetworks y el Windows Media Encoder perteneciente a
la empresa Microsoft. Por ultimo, se debe contar con el mdulo de Produccin, que es el
encargado de generar la seal analgica para emitir a travs de nuestro servidor. Para la
226
Estacin de Radio, se debe contar con un sistema capaz de generar la seal de audio,
adems de automatizar todo el proceso de difusin. En cuanto al Canal de Televisin, se
necesita dos mdulos de Produccin, uno que se encargue de la emisin de videos pre-
grabados, y otro que se encargue de las transmisiones desde dispositivos en directo.
Cabe destacar que la solucin planteada, fue pensada para lograr un equilibrio entre
la relacin costo/eficiencia, por lo que el sistema cuenta con los mdulos indispensables
para su correcto funcionamiento.













ANEXOS
227





A. Instalacin del Servidor:
Realnetworks ofrece diferentes versiones del servidor para los sistemas operativos:
Sun Solaris, OpenBSD y Windows. En todos los casos, el servidor es un servicio que se
instala muy fcilmente siguiendo las instrucciones de instalacin. A continuacin
vamos a mostrar en forma general la instalacin del servidor en Windows, aunque en
Linux y los dems sistemas operativos la instalacin es similar, diferencindose en que
en los sistemas UNIX, se debe descomprimir el paquete de instalacin y ejecutar el
archivo de configuracin en un terminal(con los respectivos permisos de ejecucin).
En Windows aparecen una serie de dilogos que permitirn instalar el servidor de
streaming con unas opciones bsicas de configuracin. Los dos primeros dilogos dan
la bienvenida al usuario y permiten seleccionar la carpeta de instalacin
predeterminada. El siguiente dialogo permite seleccionar un nombre de usuario y una
228
contrasea para administrar el servidor una vez instalado. La administracin se realiza
mediante una interfaz Web.

Figura A.1.: Ingreso de los Datos de Autentificacin para acceder al Servidor.

Los siguientes dilogos piden los puertos para las conexiones que utilicen el
protocolo PNM (Protocol Progressive Networks Media, que usa el puerto 7070 por
omisin), el protocolo RTSP (554 por defecto) y el protocolo http (puerto 80
predeterminado). Si alguno de stos puertos estuviese reservado por algn otro
programa, debera ser cambiado pues, auque el instalador no advirtiese el problema, al
ejecutar el servidor de streaming ste finalizar con un mensaje de error.
Posteriormente, se muestra un dialogo en el que se pide el puerto en el que residir
la pagina Web de administracin del servidor. ste puerto es elegido de forma aleatoria
en cada instalacin para hacer mas difcil accesos no deseados al servicio de
administracin.
El penltimo dialogo ofrece la posibilidad de instalar el servidor como un servicio
de Windows, lo cual es altamente recomendable. Finalmente, aparece un dialogo de
resumen con la informacin introducida a lo largo del proceso de instalacin.
229

Figura A.2.: Resumen de la Configuracin de los Puertos.

Se puede observar que aparece tambin un puerto cuyo valor no ha sido pedido
durante el proceso de instalacin: el puerto para servir peticiones a travs del protocolo
MMS (Microsoft Media Server). ste puerto es siempre configurado con su valor
predeterminado (17755). Los puertos predeterminados asociados a los distintos
protocolos son gestionados por IANA (Internet Assigned Numbers Authority). Una ve
finalizada la instalacin en Windows, el servidor puede ser iniciado desde un icono de
acceso directo desde el men de inicio, desde el administrador de servicios de
Windows, o al reiniciar el ordenador ste se iniciar automticamente. En los sistemas
operativos UNIX, se debe ejecutar desde el directorio de instalacin, o crear un script
que ejecute ste comando cada vez que se inicia el sistema.






230
Referencias.

[1] Qu es Streaming?
Miguel lvarez
http://www.desarrolloweb.com/articulos/482.php?manual=15

[2] La Informacin Multimedia
Escuela Politcnica Superior de Ingeniera de Gijn
http://www.atc.uniovi.es/teleco/5tm/archives/leccion2.pdf

[3] Captura y Grabacin de Audio y Videos.
Escuela Politcnica Superior de Ingeniera de Gijn
http://www.atc.uniovi.es/teleco/5tm/archives/practica1.html

[4] Compresin de Audio y Video.
Escuela Politcnica Superior de Ingeniera de Gijn
http://www.atc.uniovi.es/teleco/5tm/archives/practica3.html

[5] Compresin de Texto e Imgenes.
Escuela Politcnica Superior de Ingeniera de Gijn
http://www.atc.uniovi.es/teleco/5tm/archives/practica2.html

[6] Streaming Systems.
Universidad Juan Carlo Rey.
http://gsyc.escet.urjc.es/docencia/asignaturas/tsai/transpas/node8.html

[6] Distributing Streaming Media Content Using Cooperative Networking.
Philip A. Chou.
http://research.microsoft.com/~helenw/papers/msr-tr-2002-37.pdf

[7] Servicios Basados en Streaming
Escuela Politcnica Superior de Ingeniera de Gijn
http://www.atc.uniovi.es/teleco/5tm/archives/5tm-Practica8.pdf

[8] Basic Streaming Technology and RTSP Protocol.
Califirnia Software Corporation.
http://www.cswl.com/whiteppr/tech/StreamingTechnology.html

[9] Transferring real-time video on the Internet.
Helsinki University of Technology.
http://www.tml.tkk.fi/Opinnot/Tik-110.551/1997/iwsem.html

[10] File Format List.
The Sonic Spots.
231
http://www.sonicspot.com/guide/fileformatlist.html

[11] Configuring Broadcast/Multicast Suppression.
Sysco Systems.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_2/config/bcastsup.htm
#xtocid116020

[12] Curso de Protocolos TCP/IP.
Saulo Barajas.
http://www.saulo.net/pub/tcpip/index.html#2-7

[13] IETF RFC 1889. Real Time Protocol (RTP), January 1996.
http://www.cs.columbia.edu/~hgs/rtp/

[14] IETF draft. Real Time Streaming Protocol (RTSP), March 27, 1997.
http://www.cs.columbia.edu/~hgs/rtsp/

[15] Real Time Streaming Protocol.
Rtsp.org
http://www.rtsp.org

[16] IETF draft. Resource ReSerVation Protocol (RSVP).
http://info.internet.isi.edu/0/in-drafts /files/draft-ietf-rsvp-spec-14.txt

[17] The server array: A scalable video server architecture.
Christoph Bernhardt
http://citeseer.ist.psu.edu/cache/papers/cs/5673/ftp:zSzzSzftp.eurecom.frzSzATMzSzpapers
EURECOMzSzPAPERSzSzDistrMM.pdf/bernhardt95server.pdf

[18] Parallel Video Servers: A tutorial.
J.Y.B Lee.
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/7035/18943/00875095.pdf?tp=&arnum
ber=875095&isnumber=18943

[19] Design and performance tradeoffs in clustered video servers.
Renu Tewari.
http://citeseer.ist.psu.edu/cache/papers/cs/2391/http:zSzzSzwww.cs.utexas.eduzSzuserszSz
dmclzSzprojectszSztrelliszSzpaperszSzpszSzICMCS96.pdf/tewari96design.pdf


[20] Integrating distributed multimedia systems and interactive television networks.
Alex Shvartsman.
http://theory.lcs.mit.edu/~alex/spie-d.pdf

[21] Caching schemes for distributed video services.
232
Fouguad Tobagi.
http://citeseer.ist.psu.edu/cache/papers/cs/2896/http:zSzzSzwww.cs.ucdavis.eduzSz~chanz
SzpaperszSzicc_dsa-head.pdf/chan99caching.pdf

[22] Segment-based proxy caching of multimedia streams.
Wu Kung-Lung , Yu Philips y Joel Wolf.
http://www10.org/cdrom/papers/183/

[23] Decentralized Resource management for a distributed continuous media server.
Cyrus Shahabi y Farnoush Banaei-Kashani.
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/71/21941/01019860.pdf?tp=&arnumbe
r=1019860&isnumber=21941

[24] Chaining: A generalized Batching Technique for Video-On-Demand Systems.
Simon Sheu, Kien A. Hua y Wallapak Tavanapong.
http://ieeexplore.ieee.org/iel3/4835/13368/00609583.pdf?arnumber=609583

[25] Design of fault-tolerant large-scale VOD servers: With emphasis on high-performance
and low-cost.
Golubchik L., Muntz R.R., Cheng-Fu Chou y Berson S.
http://ieeexplore.ieee.org/iel5/71/19906/00920587.pdf?tp=&arnumber=920587&isnumber=
19906

[26] An efficient algorithm for the video server selection problem.
Chor Ping Low, Hongtao Yu y Qingping Lin.
http://ieeexplore.ieee.org/iel5/7153/19254/00891846.pdf?arnumber=891846

[27] SAM Technical Documentation.
Spacialaudio.
http://www.spacialaudio.com/products/sambroadcaster/help/sambroadcaster/

[28] Hardata hdxVideo Video Automation.
Hardata.
http://www.hardata.com/hdxvideo.asp

[29] Real Business Products Customer Support.
RealNetworks.
http://real.custhelp.com/cgi-bin/real.cfg/php/enduser/std_alp.php?tabName=tab5

[30] Real Server Administration Guide.
RealNetworks.
http://docs.real.com/docs/serveradminguide8.pdf

[31] RealNetworks Production Guide.
RealNetworks.
233
http://service.real.com/help/library/guides/ProductionGuide/prodguide/realpgd.htm

[32] Creating Streaming Video Using WME.
Nam Thai.
http://www.irc.gmu.edu/resources/findingaid/streaming/streaming_WME.pdf

[33] Windows Media Support.
Microsoft.
http://www.microsoft.com/windows/windowsmedia/support.aspx

[34] Helix Community.
Helix.
https://helix-server.helixcommunity.org/

You might also like