Post on 12-Mar-2020
ESCUELA SUPERIOR POLITÉCNICA DE CHIMBORAZO
FACULTAD DE INFORMÁTICA Y ELECTRÓNICA
ESCUELA DE INGENIERÍA EN SISTEMAS
“EVALUACIÓN DE CODECS DE VIDEO SOBRE TRÁFICO MULTICAST EN
IPV6 PARA EL DESARROLLO DE UN PROTOTIPO EN EL LABORATORIO
LIRSI – FIE”
“TESIS DE GRADO PREVIO A LA OBTENCIÓN DEL TÍTULO DE
INGENIERO EN SISTEMAS INFORMÁTICOS”
PRESENTADO POR:
EVELYN PAMELA CHAVEZ PAREDES
DIEGO ARMANDO CASTRO ARROBO
RIOBAMBA – ECUADOR
- 2014 -
El fin de una meta ha llegado, el sentimiento de alegría y gratitud en mi corazón es
inmenso, por ello mi más sincero agradecimiento a Dios, por ser mi guía y compañero
siempre; A toda mi familia por la confianza depositada en mí; A mi querida madre por
su ternura, amor y comprensión internacional; A la ESPOCH por permitirme crecer
intelectual y profesionalmente; A mis amigos por la motivación y cariño; A ti Diego por
tu paciencia y tolerancia; Y una gratitud especial a los Ingenieros: Diego Ávila y
Alberto Arellano, por sus consejos y apoyo necesario para culminar con éxito la
presente tesis.
Evelyn Pamela Chavez Paredes
Para mí, es un verdadero placer utilizar este medio para expresar mi agradecimiento; A
ti Dios, por darme la oportunidad de vivir, por estar conmigo en cada paso que doy, por
fortalecer mi corazón e iluminar mi mente; A ti Marco, por tu incondicional apoyo,
tanto al inicio como al final de mi carrera; A ti mami Betty, que tienes algo de Dios por
la inmensidad de tu amor, y mucho de ángel por ser mi guarda y por tus incansables
cuidados, porque si hay alguien que está detrás de todo este trabajo, eres tú mami, que
has sido, eres y serás el pilar de mi vida; A todos mis amigos y en especial a ti Pamela
por ser la persona que me ha apoyado siempre, por ser tolerante, comprensiva, paciente
y por ayudarme a hacer realidad nuestro sueño; Agradecer al Ing. Diego Ávila e Ing.
Alberto Arellano por sus importantes aportes y disponibilidad para llevar a cabo el
desarrollo de ésta tesis.
Diego Armando Castro Arrobo
Sin sacrificio no existe la victoria, dedico este trabajo de tesis con todo mi corazón,
admiración y respeto a Dios por cuidar de mí y a mi familia de manera incondicional;
En especial a mi madre Noemí por el sacrificio y esfuerzo que realiza día a día para
brindarme la oportunidad de tener una carrera profesional; A mi hermano Cristian por
su infinito amor; A mi abuelita Enriqueta por sus bendiciones y abrazos de confianza;
Y a mis amigos Diego, Lorena, Jessica, Aníbal, Luis por su amistad y compañía estos
años juntos en la carrera.
Evelyn Pamela Chavez Paredes
El presente trabajo realizado con mucha paciencia y esmero, se lo dedico a Dios, por ser
quien me dio la fortaleza, fe, salud y esperanza para alcanzar este anhelo que se vuelve
una realidad tangible; A Marco, porque gracias a él, sé que la responsabilidad se la debe
vivir como un compromiso de dedicación y esfuerzo; A mi mami Betty, cuyo vivir me
ha demostrado que en el camino hacia la meta se necesita de la dulce fortaleza para
aceptar las derrotas y del sutil coraje para derribar miedos; A mis hermanos María José
y Mateo por ser mi inspiración día tras día, los que nunca dudaron que lograría este
triunfo y los que me motivan para empezar nuevas búsquedas; A mis familiares, en
especial a mi mami Digna y mi papi Pepe porque de una u otra forma, con su apoyo
moral me han incentivado a seguir adelante, a lo largo de toda mi vida.
Diego Armando Castro Arrobo
FIRMAS RESPONSABLES Y NOTAS
NOMBRE FIRMA FECHA
Ing. Iván Menes Camejo
DECANO DE LA FACULTAD DE
INFORMÁTICA Y ELECTRÓNICA
Ing. Jorge Huilca Palacios
DIRECTOR DE LA ESCUELA DE
INGENIERÍA EN SISTEMAS
Ing. Diego Ávila Pesantez
DIRECTOR DE TESIS
Ing. Alberto Arellano
MIEMBRO DEL TRIBUNAL
Ing. Eduardo Tenelanda
DIRECTOR DEL CENTRO DE
DOCUMENTACIÓN
NOTA:
RESPONSABILIDAD DEL AUTOR
“Nosotros: EVELYN PAMELA CHAVEZ PAREDES y DIEGO
ARMANDO CASTRO ARROBO, somos responsables de las ideas, doctrinas
y resultados expuestos en ésta Tesis de Grado; y, el patrimonio intelectual de la
misma pertenece a la ESCUELA SUPERIOR POLITÉCNICA DE
CHIMBORAZO”.
Evelyn Pamela Chavez Paredes
Diego Armando Castro Arrobo
ÍNDICE DE ABREVIATURAS
ARTS Advanced Real Time Streaming - Tiempo Real Avanzado de
Streaming
AS Simple Avance - Avance Simple
AVC Advanced Video CODEC – CODEC de Video Avanzado
AVS Audio Video Standard - Audio de Video Estándar
BP Baseline Profile – Perfil Básico
Bps Bytes Per Second - Bits Por Segundo
CBP Constrained Baseline Profile – Perfil Básico Limitado
CD Compact Disc – Disco Compacto
CODEC Codificador – Decodificador
CPU Central Processing Unit - Unidad Central De Proceso
CSS Cascading Style Sheets - Hojas de Estilo en Cascada
DHCP Dynamic Host Configuration Protocol - Protocolo de Asignación
Dinámica de Direcciones
DNS Domain Name System – Sistema de Nombres de Dominio
DVB Digital Video Broadcasting – Broadcast de Video Digital
DVD Digital Versatile Disc – Disco de Almacenamiento de Datos
ESPOCH Escuela Superior Politécnica de Chimborazo
E3 34.368Mbits/Second
FIE Facultad de Informática y Electrónica
FMS Flash Media Server – Servidor de Medios Flash
FMO Flexible Macroblock Ordering – Orden Flexible de Macroblock
FTP File Transfer Protocol - Protocolo de Transferencia de Archivos
GPL General Public License - Licencia Pública General
H0 Hipótesis Nula
H1 Hipótesis Alternativa
HD High Definition – Alta Definición
HiP High Profile – Alto Perfil
Hi10P High 10 Profile – Alto Perfil 10
Hi422P High 4:2:2 Profile – Alto Perfil 4:2:2
Hi444PP High 4:4:4 Predictive Profile – Alto Perfil Predictivo 4:4:4
HTML HyperText Markup Language – Lenguaje de Marcas de Hipertexto
HTTP Hypertext Transfer Protocol - Protocolo de Transferencia de
Hipertexto
IANA Internet Assigned Numbers Authority - Autoridad de Asignación de
Números de Internet.
ICMP Internet Control Message Protocol – Protocolo de Mensajes de
Control de Internet.
ID Identificador
IEEE Institute of Electrical and Electronics Engineers - Instituto de
Ingenieros Eléctricos y Electrónicos
IETF Internet Engineering Task Force - Grupo de Trabajo de Ingeniería
de Internet
IGMPv3 Internet Group Management Protocol - Protocolo de Administración
de Grupos de Internet Versión Tres
IOS Internetworking Operating System - Sistema Operativo de
Interconexión
IP Internet Protocol – Protocolo de Internet
IPv4 Internet Protocol Version 4 - Protocolo de Internet Versión 4
IPv6 Internet Protocol Version 6 - Protocolo de Internet Versión 6
INEC Instituto Nacional de Estadísticas y Censos
ISP Internet Service Provider - Proveedor de Servicios de Internet
ITU International Telecommunication Union - Unión Internacional de
Telecomunicaciones
JVT Joint Video Team - Equipo de Video Conjunto
Kbps Kilobits Per Second - Kilobits Por Segundo
LAN Local Área Network – Red de Área Local
LIRSI Laboratorio de Investigación, Redes y Seguridades Informáticas.
MAC Media Access Control - Control de Acceso al Medio
Mb MegaBit
MB MegaByte
MBONE Multicast Backbone
Mbps Megabits Per Second - Megabits Por Segundo
MLD Multicast Listener Discovery - Descubrimiento de Oyentes de
Multidifusión
MMS Microsoft Media Server – Servidor de Medios Microsoft
MP Main Profile – Perfil Principal
MPEG Moving Picture Experts Group – Grupo de Expertos en Imágenes en
Movimiento
Ms Milisecond – Milisegundos
NAL Network Abstraction Layer - Capa de Abstracción de Red
OS Operating System - Sistema Operativo
OSI Open System Interconnection - Modelo de Interconexión de
Sistemas Abiertos
PIM Protocol Independent Multicast - Protocolo Independiente de
Multidifusión
PIM-SM Protocol Independent Multicast - Sparse Mode, Protocolo
Independiente Multicast – Modo Disperso
PIM-SSM Protocol Independent Multicast - Source-Specific Multicast,
Protocolo Independiente Multicast – Modo de Origen Especifico
QoS Service Quality - Calidad de Servicio
RAID Redundant Array of Independent Disks- Conjunto Redundante de
Discos Independientes
RFC Requests for Comments - Petición De Comentarios
RIP Routing Information Protocol - Protocolo de Información de Ruteo
RP Rendezvous Point – Punto de Encuentro
RTCP Real-time Transport Control Protocol - Protocolo de Control de
Transporte en Tiempo Real
RTMP Real Time Messaging Protocol – Protocolo de Mensajería en
Tiempo Real
RTMPT Real Time Messaging Protocol Tunneled - Protocolo de Mensajería
en Tiempo Real Canalizado
RTMP Real Time Messaging Protocol Secure - Protocolo de Mensajería en
Tiempo Real Asegurado
RTMPE Real Time Messaging Protocol Encrypted - Protocolo de Mensajería
en Tiempo Real Encriptado
RTP Real-Time Transport Protocol - Protocolo de Transporte en Tiempo
Real
RTSP Real Time Streaming Protocol – Protocolo de Streaming en Tiempo
Real.
OSPF Open Shortest Path First - Primer Camino Más Corto
RTVE Spanish Radio Television - Radio de Televisión Española
SDH Synchronous Digital Hierarchy - Jerarquía Digital Síncrona
SLA Service Level Agreement – Acuerdo de Nivel de Servicio
SSD Solid-State Drive – Unidad de Estado Sólido
SVCD Super Video Compact Disc – Disco Compacto de Súper Video
TCP Transmission Control Protocol - Protocolo de Control de
Transmisión.
T3 44.736 Mbps line
TS Transport Stream - Transporte de Streaming
UDP User Datagram Protocol – Protocolo de Datagrama de Usuario
USB Universal Serial Bus - Bus Universal en Serie.
VCEG Video Coding Experts Group - Grupo de Expertos en Codificación
de Video
VCD Video Compact Disc – Disco de Video Compacto
VCL Video Coding Layer - Capa de Codificación de Video
VHS Video Home System – Video de Sistema Casero
VLAN Virtual Local Area Network - Red de Área Local Virtual
VLC Video LAN Client – Cliente de Video LAN
VLS Video LAN Server – Servidor de Video LAN
VoIP Voice over IP - La Voz Sobre IP
WAN Wide Area Network – Red de Área Amplia
XP Extended Profile – Perfil Extendido
ÍNDICE GENERAL
FIRMAS RESPONSABLES Y NOTAS ................................................................... - 6 -
RESPONSABILIDAD DEL AUTOR ....................................................................... - 7 -
ÍNDICE DE ABREVIATURAS ................................................................................ - 8 -
ÍNDICE GENERAL ................................................................................................. - 14 -
ÍNDICE DE TABLAS .............................................................................................. - 21 -
ÍNDICE DE GRÁFICOS ......................................................................................... - 22 -
INTRODUCCIÓN .................................................................................................... - 24 -
CAPÍTULO I ............................................................................................................. - 27 -
1. MARCO REFERENCIAL .................................................................................. - 27 -
1.1. ANTECEDENTES ...................................................................................... - 28 -
1.2. JUSTIFICACIÓN DEL PROYECTO DE TESIS....................................... - 30 -
1.2.1. JUSTIFICACIÓN TEÓRICA .............................................................. - 30 -
1.2.2. JUSTIFICACIÓN METODOLÓGICA ............................................... - 31 -
1.2.3. JUSTIFICACIÓN PRÁCTICA ........................................................... - 32 -
1.3. OBJETIVOS ............................................................................................... - 34 -
1.3.1. OBJETIVO GENERAL ....................................................................... - 34 -
1.3.2. OBJETIVOS ESPECÍFICOS .............................................................. - 34 -
1.4. HIPÓTESIS ................................................................................................. - 34 -
CAPÍTULO II ........................................................................................................... - 36 -
2. MARCO TEÓRICO ............................................................................................ - 36 -
2.1. STREAMING ............................................................................................. - 37 -
2.1.1. STREAMING DE VIDEO ...................................................................... - 37 -
2.1.2. TIPOS DE STREAMING DE VIDEO .................................................... - 38 -
2.1.2.1. EN DIRECTO O TIEMPO REAL ....................................................... - 38 -
2.1.2.2. SOBRE DEMANDA ........................................................................... - 38 -
2.1.3. COMPONENTES DE UN SISTEMA DE STREAMING DE VIDEO .. - 39 -
2.1.3.1. SERVIDOR DE STREAMING ........................................................... - 40 -
2.1.3.2. CLIENTE ............................................................................................. - 40 -
2.1.3.3. RED DE COMUNICACIÓN – MEDIO ............................................. - 41 -
2.1.4. PROTOCOLOS PARA REALIZAR STREAMING .............................. - 42 -
2.1.4.1. PROTOCOLOS PARA STREAMING EN DIRECTO ....................... - 42 -
2.1.4.2. PROTOCOLOS PARA STREAMING SOBRE DEMANDA ............ - 43 -
2.1.5. ARQUITECTURAS DE RED UTILIZADAS EN LOS SISTEMAS DE
STREAMING ........................................................................................................ - 43 -
2.2. CODEC ....................................................................................................... - 46 -
2.2.1. CODEC DE VIDEO ................................................................................ - 46 -
2.2.2. COMPRESIÓN DE VIDEO .................................................................... - 47 -
2.2.2.1. FUNCIONAMIENTO DE LA COMPRESIÓN DE VIDEO .............. - 47 -
2.2.2.2. TIPOS DE COMPRESIÓN DE VIDEO ............................................. - 48 -
2.2.3. CODEC H.264 ......................................................................................... - 49 -
2.2.3.1. IMPORTANCIA .................................................................................. - 50 -
2.2.3.2. CARACTERÍSTICAS ......................................................................... - 50 -
2.2.3.3. PERFILES ........................................................................................... - 51 -
2.2.4. CODEC XVID ......................................................................................... - 52 -
2.2.4.1. CARACTERÍSTICAS ......................................................................... - 53 -
2.2.4.2. PERFILES ........................................................................................... - 53 -
2.2.5. CODEC THEORA .................................................................................. - 54 -
2.2.5.1. CARACTERÍSTICAS ......................................................................... - 55 -
2.2.5.2. PERFILES ........................................................................................... - 55 -
2.3. PROTOCOLO DE INTERNET VERSIÓN 6 ............................................. - 57 -
2.3.1. IPv6 - PROTOCOLO DE INTERNET VERSIÓN 6 .............................. - 57 -
2.3.1.1. DIRECCIONES IP DISPONIBLES .................................................... - 58 -
2.3.1.2. CARACTERÍSTICAS DE IPv6 .......................................................... - 58 -
2.3.1.3. TIPOS DE DIRECCIONES IPv6 ........................................................ - 60 -
2.4. MULTICAST .............................................................................................. - 62 -
2.4.1. ÁREAS DE APLICACIÓN Y USABILIDAD ....................................... - 62 -
2.4.2. ESTRUCTURA DE UNA DIRECCIÓN MULTICAST EN IPV6 ........ - 62 -
2.4.3. COMUNICACIÓN EN UNA RED MULTICAST ................................. - 64 -
2.4.4. PROTOCOLOS DE ENRUTAMIENTO MULTICAST CON IPV6 ..... - 66 -
CAPÍTULO III .......................................................................................................... - 67 -
3. APLICACIONES DE DISTRIBUCIÓN LIBRE PARA SERVIDOR
STREAMING DE VIDEO .................................................................................. - 67 -
3.1 CARACTERÍSTICAS DE UN SERVIDOR STREAMING DE VIDEO .. - 68 -
3.2 APLICACIONES PARA REALIZAR STREAMING DE VIDEO ........... - 69 -
3.3 CARACTERÍSTICAS DE LAS APLICACIONES DE SOFTWARE LIBRE .. -
70 -
FLUMOTION ...................................................................................... - 70 -
VIDEO LAN ........................................................................................ - 71 -
RED 5 MEDIA SERVER .................................................................... - 73 -
ICECAST ............................................................................................. - 75 -
GNUMP3D .......................................................................................... - 76 -
FFMPEG .............................................................................................. - 78 -
DARWIN STREAMING SERVER (DSS) ......................................... - 79 -
CAPÍTULO IV .......................................................................................................... - 83 -
4. DISEÑO E IMPLEMENTACIÓN DE AMBIENTES DE PRUEBA .............. - 83 -
4.1. TOPOLOGÍA, ALCANCE Y DISEÑO DE LA RED INFORMÁTICA ... - 84 -
4.1.1. TOPOLOGÍA .......................................................................................... - 84 -
4.1.2. ALCANCE .............................................................................................. - 85 -
4.1.3. DISEÑO Y FUNCIONAMIENTO DEL ESCENARIO DE PRUEBAS - 86 -
4.2. DIRECCIONAMIENTO DE LA RED ....................................................... - 89 -
4.3. EQUIPOS USADOS PARA LA ARQUITECTURA DEL STREAMING - 90 -
4.3.1. HARDWARE Y SOFTWARE DEL SERVIDOR DE STREAMING DE
VIDEO - 91 -
a) SOFTWARE ........................................................................................ - 91 -
b) HARDWARE ...................................................................................... - 92 -
c) CONFIGURACIÓN DEL SOFTWARE PARA LA EMISIÓN DE
VIDEO - 93 -
4.3.2. HARDWARE Y SOFTWARE DEL CLIENTE DE STREAMING DE
VIDEO - 95 -
a) SOFTWARE ........................................................................................ - 95 -
b) HARDWARE ...................................................................................... - 96 -
4.4. EQUIPOS UTILIZADOS PARA UNA TRANSMISIÓN EN VIVO ........ - 97 -
4.4.1. CARACTERÍSTICAS DE LA TARJETA CAPTURADORA Y
FILMADORA .................................................................................................... - 97 -
4.4.2. CONFIGURACIÓN DEL MÓDULO V4L2 PARA TARJETA
CAPTURADORA DE VIDEO .......................................................................... - 98 -
4.5. HERRAMIENTAS UTILIZADAS PARA GENERAR CONGESTIÓN. - 101 -
4.6. CONFIGURACIÓN DE LOS CODEC's EN EL SERVIDOR PARA
GENERAR EMISIÓN ......................................................................................... - 104 -
a) CONFIGURACIÓN DEL CODEC H.264 PARA STREAMING DE VIDEO
SOBRE DEMANDA Y EN VIVO. ..................................................................... - 104 -
Configuración sobre demanda ........................................................... - 104 -
Configuración en vivo ....................................................................... - 106 -
b) CONFIGURACIÓN DEL CODEC XVID PARA STREAMING DE VIDEO
SOBRE DEMANDA Y EN VIVO. ..................................................................... - 108 -
Configuración sobre demanda ........................................................... - 108 -
Configuración en vivo ....................................................................... - 109 -
c) CONFIGURACIÓN DEL CODEC THEORA PARA STREAMING DE VIDEO
SOBRE DEMANDA Y EN VIVO. ..................................................................... - 110 -
Configuración sobre demanda ........................................................... - 110 -
Configuración en vivo ....................................................................... - 111 -
4.7. CONFIGURACIÓN DEL CLIENTE PARA RECIBIR EMISIÓN ......... - 111 -
CAPÍTULO V ......................................................................................................... - 113 -
5. ANÁLISIS DE RESULTADOS Y COMPROBACIÓN DE LA HIPÓTESIS- 113 -
5.1. DETERMINACIÓN DE ESCENARIOS Y NÚMERO DE PRUEBAS .. - 114 -
5.2. PARÁMETROS PARA ANALIZAR EL RENDIMIENTO EN REDES - 116 -
5.2.1. PÉRDIDA DE PAQUETES .............................................................. - 116 -
5.2.2. LATENCIA ....................................................................................... - 117 -
5.2.3. JITTER ............................................................................................... - 118 -
5.2.4. ANCHO DE BANDA ........................................................................ - 118 -
5.3. HERRAMIENTAS UTILIZADAS PARA MEDIR EL RENDIMIENTO- 119 -
5.4. VALORES REFERENCIALES PARA ANÁLISIS DE INDICADORES DEL
RENDIMIENTO .................................................................................................. - 120 -
5.4.1. PÉRDIDA DE PAQUETES .............................................................. - 120 -
5.4.2. LATENCIA ....................................................................................... - 121 -
5.4.3. JITTER ............................................................................................... - 122 -
5.4.4. ANCHO DE BANDA ........................................................................ - 126 -
5.5. PROCESAMIENTO DE RESULTADOS ................................................ - 127 -
5.5.1. CAPTURA Y MEDICIÓN DE DATOS DEL CODEC H.264 ......... - 127 -
5.5.2. CAPTURA Y MEDICIÓN DE DATOS DEL CODEC XVID ......... - 128 -
5.5.3. CAPTURA Y MEDICIÓN DE DATOS DEL CODEC THEORA ... - 129 -
5.6. COMPROBACIÓN DE LA HIPÓTESIS ................................................ - 130 -
5.6.1. TIPO DE INVESTIGACIÓN ............................................................ - 130 -
5.6.2. MÉTODOS Y TÉCNICAS DE INVESTIGACIÓN ......................... - 131 -
5.6.3. ANÁLISIS ESTADÍSTICO DE LOS DATOS ................................. - 132 -
a. Análisis del indicador Pérdida de Paquetes ....................................... - 132 -
b. Análisis del indicador Latencia .......................................................... - 133 -
c. Análisis del indicador Jitter ............................................................... - 135 -
d. Análisis del indicador Ancho de Banda ............................................. - 137 -
5.6.4. INTERPRETACIÓN DE RESULTADOS Y DETERMINACIÓN DEL
CODEC ÓPTIMO ............................................................................................ - 139 -
5.6.5. ANALISIS Y PLANTEAMIENTO DE LA HIPOTESIS NULA Y
ALTERNATIVA MEDIANTE CHI CUADRADO ........................................ - 142 -
a. Valores observados ............................................................................ - 143 -
b. Valores esperados .............................................................................. - 144 -
c. Tabla de contingencia ........................................................................ - 145 -
d. Chi Cuadrado calculado ..................................................................... - 146 -
e. Grados de Libertad ............................................................................. - 147 -
f. Nivel de significancia ........................................................................ - 147 -
g. Interpretación de resultados del Valor Crítico y Chi Cuadrado ......... - 148 -
CONCLUSIONES .................................................................................................. - 150 -
RECOMENDACIONES ........................................................................................ - 152 -
RESUMEN .............................................................................................................. - 154 -
SUMMARY ............................................................................................................. - 155 -
ANEXOS .................................................................................................................. - 156 -
ANEXO 1 ................................................................................................................. - 156 -
SECCIÓN I: Archivo de configuración del router emisor ................................... - 156 -
SECCIÓN II: Archivo de configuración del router de punto de redirección ....... - 160 -
SECCIÓN III: Archivo de configuración del router receptor .............................. - 165 -
ANEXO 2 ................................................................................................................. - 170 -
SECCIÓN I: Mediciones en la red del CODEC H.264 ....................................... - 170 -
SECCIÓN II: Mediciones en la red del CODEC Xvid ........................................ - 178 -
SECCIÓN III: Mediciones en la red del CODEC Theora ................................... - 186 -
ANEXO 3 ................................................................................................................. - 194 -
Tabla de distribución de chi cuadrado con valores críticos ...................................... - 194 -
ANEXO 4 ................................................................................................................. - 196 -
Guía de implementación de streaming de video sobre una red con tráfico Multicast en
IPv6 para el laboratorio LIRSI – FIE ................................................................... - 196 -
1. DISEÑO Y CONFIGURACIÓN DE UNA RED MULTICAST IPv6 ........... - 196 -
1.1. Esquema de la Red ......................................................................................... - 196 -
1.2. Configuración de los Routers ........................................................................ - 197 -
1.2.1. Configuración del router de emisión de multidifusión .............................. - 199 -
1.2.2. Configuración del router como punto de redirección de la multidifusión . - 201 -
1.2.3. Configuración del router receptor de multidifusión ................................... - 203 -
2. INSTALACIÓN DE LA APLICACIÓN EMISORA Y RECEPTORA DE VIDEO
VLC ................................................................................................................. - 205 -
2.1 Instalación de VLC en Linux ......................................................................... - 205 -
2.2 Instalación de VLC en Windows ................................................................... - 207 -
3. CONFIGURACIÓN PARA LA EMISIÓN DE VIDEO ................................ - 212 -
3.1 Emisión en vivo desde una filmadora ............................................................ - 213 -
3.1.1 Configuración del driver Video4Linux ...................................................... - 215 -
3.2 Emisión sobre demanda desde una webcam .................................................. - 217 -
3.3 Emisión sobre demanda ................................................................................. - 220 -
4. RECEPCIÓN DE UN VIDEO EN UN CLIENTE DESDE UNA FUENTE DE
MULTIDIFUSIÓN .......................................................................................... - 222 -
GLOSARIO ............................................................................................................. - 225 -
BIBLIOGRAFÍA .................................................................................................... - 230 -
ÍNDICE DE TABLAS
TABLA II. 1 Diferencias entre los tipos de streaming de video ............................... - 39 -
TABLA II. 2 Comparativa entre los CODEC's de video ........................................... - 56 -
TABLA II. 3 Tipos de direcciones IPv6 y Prefijos ................................................... - 61 -
TABLA III. 1 Comparativa de aplicaciones de software libre .................................. - 81 -
TABLA IV. 1 Direccionamiento del escenario de pruebas ...................................... - 90 -
TABLA IV. 2 Características de la máquina designada para Servidor .................... - 92 -
TABLA IV. 3 Requisitos de instalación para VLC .................................................. - 93 -
TABLA IV. 4 Características de la máquina cliente portátil .................................... - 96 -
TABLA IV. 5 Características de la máquina cliente de escritorio ........................... - 97 -
TABLA V. 1 Valoración cuantitativa en la medición del rendimiento .................. - 127 -
TABLA V. 2 Comportamiento del CODEC H.264 en los distintos escenarios ..... - 128 -
TABLA V. 3 Comportamiento del CODEC Xvid en los distintos escenarios ....... - 129 -
TABLA V. 4 Comportamiento del CODEC Theora en los distintos escenarios .... - 130 -
TABLA V. 5 Indicadores de rendimiento para los CODEC H.264, Xvid y Theora
....................................................................................................................... ……..- 132 -
TABLA V. 6 Valores observados de los CODEC de video ................................... - 144 -
TABLA V. 7 Valores esperados de los CODEC de video ..................................... - 145 -
TABLA V. 8 Tabla de Contingencia Chi Cuadrado ............................................... - 146 -
ÍNDICE DE GRÁFICOS
FIGURA I. 1 Planteamiento del escenario de pruebas ............................................... - 33 -
FIGURA II. 1 Tecnología de streaming .................................................................... - 37 -
FIGURA II. 2 Difusión de streaming en vivo ........................................................... - 38 -
FIGURA II. 3 Difusión de streaming sobre demanda ............................................... - 39 -
FIGURA II. 4 Arquitectura centralizada basada en un solo servidor ........................ - 45 -
FIGURA II. 5 Sistema de distribución de jerarquía en el registro de internet .......... - 57 -
FIGURA II. 6 Cabeceras de IPv4 e IPv6 ................................................................... - 60 -
FIGURA II. 7 Dirección Multicast en IPv6 ............................................................... - 63 -
FIGURA II. 8 Comunicación con trafico Multicast .................................................. - 65 -
FIGURA III. 1 Servidor de streaming RED 5 ........................................................... - 75 -
FIGURA III. 2 Servidor de streaming Gnump3d ...................................................... - 78 -
FIGURA III. 3 Servidor de streaming Darwin .......................................................... - 80 -
FIGURA IV. 1 Diseño del escenario de pruebas ...................................................... - 87 -
FIGURA IV. 2 Prototipo de pruebas con equipos reales .......................................... - 87 -
FIGURA IV. 3 Pantalla principal de la distribución Ubuntu ................................... - 91 -
FIGURA IV. 4 Pantalla inicial de Software VLC en Ubuntu .................................. - 95 -
FIGURA IV. 5 Pantalla de configuración de Ostinato ........................................... - 102 -
FIGURA IV. 6 Configuración de Ostinato para una congestión moderada ........... - 103 -
FIGURA IV. 7 Configuración de Ostinato para una congestión fuerte .................. - 103 -
FIGURA IV. 8 Abrir medio para CODEC H.264 .................................................. - 105 -
FIGURA IV. 9 Configuración de destino sobre demanda para CODEC H.264 .... - 105 -
FIGURA IV. 10 Configuración de preferencias difusión sobre demanda .............. - 106 -
FIGURA IV. 11 Configuración de dispositivo de captura ..................................... - 107 -
FIGURA IV. 12 Abrir medio para CODEC Xvid .................................................. - 108 -
FIGURA IV. 13 Configuración de destino sobre demanda para CODEC Xvid .... - 109 -
FIGURA IV. 14 Abrir medio para CODEC Theora ............................................... - 110 -
FIGURA IV. 15 Configuración de destino sobre demanda para CODEC Theora . - 111 -
FIGURA IV. 16 Abrir volcado de red en un cliente de multidifusión ................... - 112 -
FIGURA V. 1 Diagrama de Árbol .......................................................................... - 114 -
FIGURA V. 2 Visualización del comando para comprobar la latencia .................. - 122 -
FIGURA V. 3 Ingreso a Jperf/Iperf por medio de comando .................................. - 123 -
FIGURA V. 4 Ingreso a Jperf/Iperf en modo gráfico ............................................. - 123 -
FIGURA V. 5 Jperf/Iperf en modo servidor ........................................................... - 124 -
FIGURA V. 6 Jperf/Iperf en modo cliente ............................................................ - 125 -
FIGURA V. 7 Análisis de la pérdida de paquetes en porcentajes ......................... - 133 -
FIGURA V. 8 Análisis de la latencia ..................................................................... - 134 -
FIGURA V. 9 Análisis de la latencia en valores porcentuales ............................... - 135 -
FIGURA V. 10 Análisis del Jitter ........................................................................... - 136 -
FIGURA V. 11 Análisis del Jitter en valores porcentuales .................................... - 137 -
FIGURA V. 12 Análisis del Ancho de Banda ........................................................ - 138 -
FIGURA V. 13 Análisis del Ancho de Banda en valores porcentuales ................. - 139 -
FIGURA V. 14 Porcentajes de los indicadores ...................................................... - 140 -
FIGURA V. 15 Chi Cuadrado ................................................................................ - 149 -
INTRODUCCIÓN
El mundo es cada vez más competitivo, por ello las empresas buscan diferentes formas
para poder transmitir sus mensajes y/o contenido multimedia (audio/video) a la
sociedad, y así poder llegar a gran cantidad de audiencia de manera rápida, económica y
eficiente, no sólo a nivel local sino también nacional, por tal motivo se ha buscado
alternativas como la implementación de servicios de streaming de video que mediante el
uso adecuado de los CODEC's (Codificador - Decodificador) de video, faciliten la
comunicación con los usuarios.
El servicio de streaming de video o video afluente es una evolución de las
telecomunicaciones, que permite transmitir voz y video en tiempo real y sobre demanda,
para ello hace uso de los CODEC's o algoritmos de compresión, que reduce
considerablemente el tamaño de un archivo de contenido multimedia para transmitirlo
por la red y llevar su contenido a los destinatarios finales. Con el avance masivo del
contenido multimedia se espera que las aplicaciones utilicen tráfico Multicast con IPv6
(Protocolo de Internet versión 6), las cuales son propuestas interesantes para el servicio
de streaming, ya que el tráfico Multicast, permite el envío de un paquete para múltiples
destinatarios, ahorrando el ancho de banda; mientras que la aparición del protocolo IPv6
proporciona un ambiente rico en funciones para el futuro de la interconexión mundial,
eliminando las barreras que el protocolo IPv4 (Protocolo de Internet versión 4) presenta,
como la falta de direcciones.
La presente investigación tiene como objetivo llevar a cabo la evaluación de los
CODEC's de video H.264, Xvid y Theora sobre tráfico Multicast en IPv6, para el
desarrollo de un prototipo en el laboratorio de investigación LIRSI (Laboratorio de
Investigación, Redes y Seguridad Informática) – FIE (Facultad de Informática y
Electrónica), por lo que se ha diseñado ambientes de prueba, los mismos que permiten
tener datos referenciales acerca del CODEC óptimo, para una transmisión de video en
tiempo real y sobre demanda bajo las configuraciones de la red mencionada, mediante la
estimación del rendimiento que presenta el CODEC en cada escenario, el análisis de la
comunicación los datos y el comportamiento de los mismos, culminando con la
emisión de resultados y la creación de una guía de implementación de streaming de
video.
En el Capítulo I Marco Referencial, se detalla los antecedentes, la justificación de la
investigación, los objetivos a cumplirse y la hipótesis planteada que al final del trabajo
será comprobada.
El Capítulo II Marco Teórico, comprende el estudio acerca de las principales
características de los CODEC's H.264, Xvid y Theora para streaming de video; el
protocolo de internet versión 6 y el funcionamiento de tráfico Multicast en equipos
Cisco y servidores Linux.
En el Capítulo III Aplicaciones de Distribución Libre para el Servidor Streaming de
Video, se presenta información sobre las aplicaciones de software gratuito comúnmente
utilizadas para la configuración del servidor de streaming de video, permitiendo la
comunicación entre los clientes y el servidor, con la finalidad de tener acceso a las
transmisiones multimedia.
En el Capítulo IV Diseño e Implementación de Ambientes de Prueba, se contempla los
diferentes ambientes de prueba realizados en la investigación, los mismos que constan
de aspectos como diseño, direccionamiento, enrutamiento, configuración y captura de
datos sobre la red con tráfico Multicast en IPv6.
En el Capítulo V Análisis de Resultados y Comprobación de la Hipótesis, se describe el
análisis de los valores obtenidos en el Capítulo IV con el fin de establecer diferencias y
conclusiones para comprobar la hipótesis planteada en el trabajo de investigación, para
lo cual se detalla las principales características acerca de los parámetros básicos para la
medición del rendimiento en redes.
Finalmente en la sección de Anexos se recalca la creación de una guía de
implementación de streaming de video sobre tráfico Multicast en IPv6, con la finalidad
de que diferentes instituciones y en especial el laboratorio LIRSI - FIE cuente con este
aporte científico para futuras implementaciones.
CAPÍTULO I
1. MARCO REFERENCIAL
En todo proceso de investigación, un elemento que sustenta el camino a seguir en un
trabajo científico es sin duda el marco referencial, ya que en éste se contempla aquellas
ideas o teorías fundamentales sobre las cuales se basa la tesis.
Este capítulo comprende los antecedentes, la justificación teórica, metodológica y la
práctica, en la que se exponen las razones acerca del problema, la usabilidad, utilidad y
los beneficios a obtener cuando se lleve a cabo la ejecución de los resultados del estudio
a realizar.
Además se contempla los objetivos que se van a cumplir y la hipótesis propuesta para
ser probada durante el desarrollo de la tesis.
- 28 -
1.1. ANTECEDENTES
El incremento definitivo de internet en la segunda década del siglo XXI, hace que cada
vez haya millones de personas que utilizan la red, no sólo para comunicarse, sino para
acceder a contenidos de todo tipo. Los libros, documentos, fotografías, cine o música ya
no se consumen de la misma manera, y cada día la red se reinventa para ofrecer nuevas
formas de acceder a ellos y hacer su disfrute más sencillo.
El sector audiovisual en la red, suscitado primordialmente por las necesidades de las
personas, es uno de los más importantes en la actualidad, ya que es capaz de llevar sus
contenidos multimedia a la sociedad y originar un gran crecimiento en la comunicación,
promoviendo el desarrollo de la cultura, amplias fuentes de información, conocimiento
y ocio mediante su difusión a través del internet.
El streaming nace como el primer desarrollo de la informática de consumo, permitiendo
ampliar negocios a niveles empresariales, educativos y en la salud, proporcionando un
alcance a gran audiencia de manera fácil y económica, garantizando transmisiones en
línea, utilizados ya sea para ruedas de prensa, negocios o aulas virtuales.
Existen varios tipos de streaming, entre ellos el más popular es el streaming de video o
video afluente, el cual apareció en abril de 1995, en sus inicios se permitía descargar
completamente el archivo para poderlo visualizar, mientras que ahora se puede
descargar un archivo o reproducirlo al mismo tiempo en la red.
Para que el contenido multimedia se realice, los datos deben ser comprimidos en el
equipo de origen mediante un CODEC, que sirve para transformar las señales de audio
y video, a datos que puedan ser enviados por la red, la misma que ayuda a que viajen
- 29 -
comprimidos a través del circuito de comunicación y se descomprimen en el lugar de
destino, obteniendo una mejor calidad de voz y video.
Para poder proporcionar un acceso claro, convincente y continuo, el streaming de video
se apoya en los beneficios que presenta el tráfico o difusión de contenido mediante la
tecnología Multicast, que permite conservar el ancho de banda, específicamente
diseñado para reducir el tráfico, transmitiendo un único flujo de información a miles de
destinatarios. De esta forma, se sustituyen las múltiples copias para todos los
beneficiarios con la entrega de un único flujo de información. En contraste con Unicast,
en donde se envía una copia, flujo de información a cada cliente o receptor que se
conecte al grupo.
En la actualidad, el intercambio de información a través de la internet clásica se realiza
de forma Unicast, por lo cual la transmisión es: ineficiente y limita la comunicación
entre múltiples usuarios, más aún cuando los recursos a consumir son mayores.
Sin embargo, y a pesar de las ventajas señaladas del video streaming y la difusión
Multicast, el mayor inconveniente que presenta el video afluente al desplegarlo, es que
el ancho de banda utilizado es directamente proporcional a la calidad del video en
términos de tiempo y resolución, esto es, entre más alta es la calidad del video se
requiere un ancho de banda más importante, por ello, es imprescindible usar algoritmos
de compresión de video que permitan maximizar el ancho de banda, ya que la
desacertada elección del CODEC para el servidor de streaming de video, provoca aparte
de la mala resolución del video e incomodidad por parte del usuario, problemas de
congestión en la red y bajo rendimiento en las aplicaciones por el consumo de ancho de
banda que el contenido multimedia requiere, por lo que nace la necesidad de realizar
- 30 -
una evaluación de CODEC's de video sobre tráfico Multicast en IPv6 para el desarrollo
de un prototipo en el laboratorio LIRSI– FIE.
Con la finalidad de determinar el CODEC más adecuado, que incremente el rendimiento
en las transmisiones de contenido multimedia, sobre tráfico Multicast IPv6 y así brindar
a las instituciones públicas, privadas y en especial al laboratorio LIRSI, una guía de
implementación de streaming de video con el CODEC que mejor rendimiento presente
en la difusión Multicast IPv6, para lo cual se realizará un prototipo de MBone
(Multicast Backbone) para la comprobación y evaluación de cada uno de los algoritmos
de compresión.
1.2. JUSTIFICACIÓN DEL PROYECTO DE TESIS
Toda idea plasmada en una investigación debe encontrarse claramente justificada, con el
objetivo de respaldar la ejecución de un escenario y una supuesta teoría o hipótesis de
conocimiento, por tal razón a continuación se da a conocer la justificación teórica,
metodológica y práctica.
1.2.1. JUSTIFICACIÓN TEÓRICA
La difusión de contenido multimedia (streaming de video) en la red, se ha convertido en
uno de los servicios actualmente más solicitados por las empresas, ya que dicha
transmisión permite que puedan ofertar sus productos y/o conocimientos mediante
videos publicitarios, magistrales, video clases, videotecas, etc., logrando que los
usuarios puedan acceder a información y recomendaciones importantes mediante las
aplicaciones visuales (videos) ofertadas.
- 31 -
Para el streaming de video es necesario la implementación de varios componentes, entre
ellos, el más importante y no tan estudiado es el CODEC de compresión de video, por
tal motivo se va a llevar a cabo un estudio de los CODEC's: H.264, Xvid y Theora, los
mismos que permiten codificar (comprimir) un video, garantizado la alta calidad de
imagen y la reducción del tamaño del archivo, tanto para la transmisión de éste en la red
como en el espacio que ocupa dentro de un dispositivo de almacenamiento masivo
(memoria USB (Bus Universal en Serie), SSD (Unidad de Estado Sólido), disquete,
etc.), permitiendo que el archivo de video sea manejable.
Dichos CODEC's fueron seleccionados por sus características relevantes, como lo son:
libre distribución, altamente utilizados en el mercado, eficientes y sobre todo apropiados
para el manejo de la transmisión multimedia.
IPv6 es la nueva generación del protocolo básico de internet, el motivo para crear un
nuevo protocolo fue: proporcionar un ambiente rico en funciones para el futuro de la
interconexión mundial y eliminar barreras que el protocolo IPv4 presenta como la falta
de direcciones. Además con el avance masivo del tráfico de voz, video y de aplicaciones
de tiempo real, se espera que las aplicaciones utilicen el tipo de tráfico Multicast para un
ahorro de ancho de banda en los enlaces troncales de la red, por tal motivo se estudiará
su funcionamiento, direccionamiento y enrutamiento.
1.2.2. JUSTIFICACIÓN METODOLÓGICA
La tesis se va a enfocar en una investigación analítica y práctica, en la que se utilizará el
método científico y las técnicas de investigación como: benchmark, la observación y la
documentación, técnicas que permitirán recopilar información necesaria y útil, para
llevar a cabo el estudio de los CODEC's antes mencionados.
- 32 -
1.2.3. JUSTIFICACIÓN PRÁCTICA
Para llevar a cabo la evaluación de los CODEC's de video sobre tráfico Multicast en
IPv6, se necesitará de la difusión de contenido multimedia en la red en tiempo real y
sobre demanda, ya que estas dos maneras de difusión son actualmente las más
solicitadas por los usuarios, permitiendo el acceso a cualquier tipo de información.
En las difusiones en tiempo real se necesitará una cámara digital (filmadora) y una
tarjeta capturadora de video. En la transmisión sobre demanda se empleará videos
educativos, que serán comprimidos y almacenados en el disco duro de dicho servidor, el
mismo que será configurado en la plataforma Linux.
Los trabajos experimentales se los realizará sobre escenarios de prueba con la
utilización de los equipos de la academia Cisco (Router Cisco 2811, Switch Cisco
Catalyst 2960, cables de red, computadoras de escritorio y portátiles).
Dichos escenarios se describen a continuación:
Red IPv6 Multicast, con el CODEC H.264 para streaming sobre demanda y en
tiempo real.
Red IPv6 Multicast, con el CODEC Theora para streaming sobre demanda y en
tiempo real.
Red IPv6 Multicast, con el CODEC Xvid para streaming sobre demanda y en
tiempo real.
El núcleo de la red tendrá como funcionalidad principal el ruteo Multicast en IPv6 y en
los bordes de esta red estarán los posibles usuarios con el direccionamiento IPv6 que se
podrán unir a los grupos Multicast generados.
- 33 -
Una vez realizadas las configuraciones básicas e iniciada la difusión de video en la red,
se procederá a la inyección de tráfico en la red, ya que sería muy fácil tener un buen
rendimiento en aplicaciones si las redes nunca se congestionaran, por tal motivo se
alterará la red con una congestión moderada, congestión fuerte y sin congestión.
Posteriormente se realizará mediciones de rendimiento, tomando en cuenta los
siguientes parámetros cuantitativos:
Latencia
Jitter
Ancho de banda
Pérdida de paquetes
Logrando determinar el CODEC con mejor rendimiento, bajo los parámetros
mencionados.
Para mayor comprensión se presenta a continuación la Figura I. 1: Planteamiento del
escenario de pruebas, en la que abarca todas las configuraciones descritas.
FIGURA I. 1 Planteamiento del escenario de pruebas
Fuente: Elaboración propia de los autores
- 34 -
1.3. OBJETIVOS
1.3.1. OBJETIVO GENERAL
Evaluar los CODEC's de video sobre tráfico Multicast en IPv6 para el desarrollo de un
prototipo en el laboratorio LIRSI – FIE.
1.3.2. OBJETIVOS ESPECÍFICOS
Estudiar las principales características de los CODEC's H.264, Xvid y Theora para
streaming de video, el protocolo de internet versión 6 (IPv6) y la tecnología
Multicast en equipos Cisco y servidor Linux.
Analizar y determinar las aplicaciones de distribución libre para la implementación
del servidor streaming de video.
Implementar y configurar los escenarios de prueba para evaluar los CODEC's de
video aplicado al streaming que permita determinar el más adecuado en base a su
rendimiento en transmisiones visuales en la red.
Diseñar una guía de implementación de streaming de video sobre una red de tráfico
Multicast en IPv6 para el laboratorio LIRSI – FIE.
1.4. HIPÓTESIS
El análisis de CODEC's de video sobre tráfico Multicast en IPv6 para el desarrollo de
un prototipo en el laboratorio LIRSI – FIE permitirá determinar el CODEC más
adecuado, que mejorará el rendimiento en transmisiones visuales en la red.
- 35 -
Variable independiente: CODEC's de streaming de video
Variable dependiente: Rendimiento
o Parámetros de medición (indicadores):
- Consumo del ancho de banda
- Latencia
- Jitter.
- Pérdida de datagramas en la red.
CAPÍTULO II
2. MARCO TEÓRICO
La presencia del marco teórico en un trabajo científico es una de las fases más
importantes a desarrollar, ya que éste consiste en revisar distintas literaturas y resaltar la
teoría que va a fundamentar el proyecto de tesis con base al problema planteado y las
soluciones que el tema contribuye a la sociedad.
El presente capitulo se basa en buscar fuentes documentales que permita recopilar
información relevante sobre los objetos de estudio como son: video streaming;
CODEC's de video H.264, Xvid, Theora; protocolo de internet versión 6; tráfico,
direccionamiento y enrutamiento Multicast, conceptualizando los aspectos y
características fundamentales de cada uno de éstos.
- 37 -
2.1. STREAMING
Se define al streaming como: Una técnica para transmitir datos (usualmente sobre el
internet) en un flujo continuo, permitiendo que los archivos multimedia de gran tamaño
puedan ser vistos en el computador del cliente antes de que sea descargado
completamente, Thampi [1], tal como se refleja en la Figura II. 1.
El streaming permite acelerar la descarga del contenido multimedia en la web,
permitiendo que tanto imágenes y audio se reproduzcan de manera simultánea, cabe
mencionar además que mientras se va descargando el archivo desde el servidor, en el
cliente se va construyendo un buffer, el cual se va llenando de la información
descargada para posteriormente reproducirla.
FIGURA II. 1 Tecnología de streaming
Fuente: Elaboración propia de los autores
2.1.1. STREAMING DE VIDEO
El video ha sido y será un importante medio de comunicación y de entretenimiento por
mucho tiempo, debido a que el video es mucho más llamativo que los demás medios de
comunicación llega a ser utilizado en ámbitos educativos, divulgativos, sitios de
conocimiento, ocio, además mediante el video se puede tener seguridad en lugares
públicos y privados, en empresas, edificios hasta en automóviles, por esta y muchas más
utilidades el video afluente o video streaming actualmente es de gran interés.
La idea básica del video streaming, consiste en dividir el video en partes iguales, para
transmitir estas partes en secuencia, permitiendo que el receptor pueda decodificar y
- 38 -
reproducir el video según cómo vaya recibiendo las tramas del video, sin tener que
esperar que lleguen todas las partes, Thampi [1].
2.1.2. TIPOS DE STREAMING DE VIDEO
Las dos formas más comunes para la difusión de contenido multimedia son las
siguientes: en directo o tiempo real y sobre demanda.
2.1.2.1. EN DIRECTO O TIEMPO REAL
El streaming de video en tiempo real es consumido únicamente en el momento que se
está transmitiendo.
El servidor comienza a transmitir en un instante dado y los usuarios que se conectan a
él, ven la información que se está emitiendo en ese instante, Ibnoulkhatib [2], tal como
se representa en la Figura II. 2.
FIGURA II. 2 Difusión de streaming en vivo
Fuente: Elaboración propia de los autores
Éste tipo de streaming está orientado a la multidifusión y no existe interactividad ya que
el usuario no puede adelantar ni rebobinar, solo pausar, por ejemplo: la televisión,
porque sintoniza señales que están transmitidas en vivo, sin importar si son pregrabadas
o no, la señal se transmite en el momento que se lo enciende.
2.1.2.2. SOBRE DEMANDA
En este tipo de servicio los usuarios solicitan el envío de información en el instante que
lo deseen, siendo ésta información personalizada para cada usuario, Ibnoulkhatib [2].
- 39 -
Sobre demanda permite que los usuarios interactúen con el contenido, además dicho
contenido se encuentra grabado o almacenado en el disco duro de un servidor, tal como
se muestra en la Figura II. 3, por ejemplo: la página de Youtube, ya que es un
repositorio de videos extremadamente grande, los cuales se pueden visualizar cuando es
requerido sin importar la hora.
FIGURA II. 3 Difusión de streaming sobre demanda
Fuente: Elaboración propia de los autores
A continuación se presenta la Tabla II. 1 que especifica las diferencias existentes entre
los tipos de transmisión de Streaming de video.
TABLA II. 1 Diferencias entre los tipos de streaming de video
EN DIRECTO O
TIEMPO REAL
SOBRE
DEMANDA
Manejo del contenido
multimedia
En tiempo real, el contenido
no está guardado.
Previamente grabado y
almacenado en el disco duro.
Forma de visualizar
el contenido
multimedia.
El usuario puede ver el
inicio, medio o ya al final
de la transmisión.
El usuario tiene acceso a ver
todo el contenido en
cualquier momento.
Interactividad No posee interactividad Amplia interactividad.
Fuente: Elaboración propia de los autores
2.1.3. COMPONENTES DE UN SISTEMA DE STREAMING DE VIDEO
Los sistemas de streaming de video para el presente trabajo van a estar compuestos por
tres componentes esenciales: el servidor, la red de comunicaciones y los clientes del
sistema de streaming. A continuación se describe la funcionalidad de cada uno de estos
componentes.
- 40 -
2.1.3.1. SERVIDOR DE STREAMING
El servidor es la máquina encargada de almacenar y gestionar los videos que se desean
distribuir a través de la red de comunicaciones a los diferentes usuarios.
Independientemente del tipo de arquitectura que se utiliza en un sistema de streaming de
video, el servidor está compuesto por tres subsistemas: El subsistema de control, de
almacenamiento y de comunicación.
Subsistema de control: se encarga de recibir y controlar todas aquellas
solicitudes de video que los usuarios realicen, para lo cual el subsistema
internamente debe ordenar dichas solicitudes, verificar su petición y atenderlas
de mejor manera, logrando que no exista un retraso respecto a las demás
solicitudes.
Subsistema de almacenamiento: su trabajo consiste en el almacenamiento y la
recuperación de la información multimedia desde los dispositivos de
almacenamiento, en este caso desde el disco duro del servidor.
Subsistema de comunicación: está relacionado directamente con la red de
comunicaciones debido a que éste subsistema atrapa el contenido del video que
ya está listo para emitirse y lo entrega a la red permitiendo optimizar el recurso
de ancho de banda y del servidor mediante la gestión de políticas.
Posteriormente en el capítulo III del presente documento se detallará con más énfasis las
aplicaciones que resultan ser propicias para la configuración del servidor.
2.1.3.2. CLIENTE
Los clientes son cada una de las máquinas receptoras de la información que se trasmite,
éstas deben soportar la recepción y la visualización sin cortes de los contenidos
multimedia, para ello utiliza un reproductor, un buffer o espacios de memoria que
- 41 -
reserva cierta información para hacer menos notorio algún tipo de retraso en la emisión
del video y de un algoritmo de compresión CODEC, como mínimo se necesita tener un
cliente, sino no tendría sentido la transmisión.
Los clientes constan de cuatro componentes: interfaz de red, decodificador, buffer y la
sincronización, los mismos que trabajan de manera conjunta.
La interface entre los usuarios y el sistema de streaming se realiza mediante el
reproductor. Este módulo es el encargado de recibir los comandos del usuario y enviar
la señal al servidor a través de la interface de red. El reproductor almacena los
contenidos recibidos desde el servidor en unos buffers (espacios de memoria) locales,
decodifica los contenidos recibidos en tiempo real y envía las imágenes obtenidas a la
pantalla de visualización, con la temporización correcta, Ibnoulkhatib [2].
2.1.3.3. RED DE COMUNICACIÓN – MEDIO
La red de comunicación es el medio por dónde se envía la información, en este caso por
donde se envían los videos, la red es el internet, por lo cual se habla de la capa 4
(Transporte) del modelo OSI (Interconexión de Sistemas Abiertos), donde utiliza
datagramas UDP (Protocolo de Datagramas de Usuario) para realizar streaming, que son
paquetes que se envían sin esperar confirmación de entrega al destinatario, además de
permitir que la transmisión sea más rápida y fluida.
La red de comunicación de un sistema de streaming se caracteriza por unos elevados
requisitos de ancho de banda (capacidad de transferencia de grandes volúmenes de
datos) y grandes velocidades de transmisión, Ibnoulkhatib [2].
- 42 -
Dentro del sistema afluente, existen tres niveles de red dependiendo de la arquitectura
estas son: la red principal, troncal y las redes locales. La red principal es donde se
conectan los servidores con la red de distribución (red troncal), la red troncal conecta y
transporta la información desde los servidores a los clientes. La red local hace la
conexión final de los clientes con el sistema afluente.
2.1.4. PROTOCOLOS PARA REALIZAR STREAMING
Existe una variedad de protocolos para realizar Streaming por lo que a continuación se
presenta los protocolos más comunes y utilizados en los tipos de video streaming como
son: en tiempo real y sobre demanda.
2.1.4.1. PROTOCOLOS PARA STREAMING EN DIRECTO
Para transmitir videos en tiempo real es necesario utilizar protocolos que no estén
basados en el protocolo TCP (Protocolo de Control de Transmisión), puesto que éste
protocolo está orientado a la conexión y en caso que se produzca un error o se pierda un
dato la información se vuelve a reenviar. Debido a ello es preciso utilizar protocolos
basados en UDP, el protocolo más importante para realizar la transmisión de video y
sonido en tiempo real es RTP (Protocolo de Transporte en Tiempo Real).
RTP: nuevo protocolo creado para transmitir información multimedia como
videos en tiempo real de datos sobre UDP, conduce la entrega de paquetes de
manera coordinada mediante el RTSP (Protocolo de Streaming en Tiempo Real)
y el RTCP (Protocolo de Control de Transporte en Tiempo Real). RTCP se
encarga de la comunicación, es decir del empaquetado y el transporte de los
datos, usado para transmitir parámetros de información multimedia, controla el
estado de la conexión. RTSP trabaja a nivel de aplicación y controla la entrega
- 43 -
de datos ya que el tipo de contenido con el que se trabaja al hacer streaming es
muy sensible.
2.1.4.2. PROTOCOLOS PARA STREAMING SOBRE DEMANDA
Cuando se realiza la transmisión de videos sobre demanda, el cliente es el que controla
la recepción de los datos, por lo tanto se pueden utilizar protocolos basados en TCP,
como HTTP (Protocolo de Transferencia de Archivos) y FTP (Protocolo de
Transferencia de Hipertexto). Debido a que los protocolos HTTP y FTP son fiables y se
construyen en la capa más alta de TCP, aseguran que los paquetes lleguen a su destino
de manera secuencial. Cuando se esté utilizando protocolos basados en TCP existe la
ventaja de reenviar los paquetes en caso de que éstos se pierdan en el camino.
Para el presente trabajo se va hacer uso del protocolo RTP /MPEG (Grupo de Expertos
en Imágenes en Movimiento) Transport Protocol para transmisiones sobre demanda y
transmisiones en vivo, debido a que este protocolo trabaja conjuntamente con el
protocolo UDP, permitiendo una comunicación de manera mucho más eficiente.
2.1.5. ARQUITECTURAS DE RED UTILIZADAS EN LOS SISTEMAS
DE STREAMING
Antes de implementar un servicio de streaming se debe conocer el tipo de arquitectura
de red a utilizar, ya que dependiendo de la arquitectura, el número de componentes
utilizados en un servicio de streaming van a variar.
A continuación se describe las principales características de las arquitecturas utilizadas
para llevar a cabo la implementación de un sistema de streaming.
Arquitectura típica: cuenta con una máquina servidor y otra máquina cliente,
que produce y consume el servicio de streaming respectivamente.
- 44 -
Arquitectura sin servidor: aquí no se cuenta con un servidor de audio y video,
esta arquitectura se basa en hacer uso de un servidor web para realizar algunas
de las funciones de un servidor multimedia, por tal razón se la conoce como:
pseudo-streaming o arranque rápido, ésta arquitectura no es usada para
transferencia en tiempo real y no almacena datos en el cliente, por ende no es
recomendable para la tecnología streaming.
Arquitectura sin cliente: como su nombre lo indica no existen clientes, por ende
para la visualización de contenido multimedia se utiliza un applet Java o un
plugin, además los archivos se descargan en ese mismo momento. Este tipo de
arquitectura usa páginas web donde se visualice el contenido, un ejemplo de esto
es la página www.youtube.com.
Además de las arquitecturas mencionadas, existen otros tipos de arquitecturas,
especificadas a continuación.
Arquitectura de servidores independientes: se basa en el uso de redes locales, es
decir, usuarios agrupados en segmentos de red cuyo tráfico es independiente de
las demás porciones de red.
Arquitecturas basadas en servidores proxy: son estaciones, que pueden
funcionar en internet o en redes locales, no almacenan el contenido completo del
archivo, solo almacena las partes más importantes, o a su vez las más populares,
funciona como una cache y aparece por el costo elevado de los servidores
independientes.
Arquitectura centralizada: se basa en una red principal o central, a la cual todos
los usuarios se conectan, brindando acceso a un servidor. La principal
característica es la gestión centralizada de todas las peticiones de los usuarios y
- 45 -
la utilización de la red principal que es compartida por todos los flujos de
información, Ibnoulkhatib [2]. En este tipo de esquema se pueden definir otros
tipos de arquitecturas dependiendo del número de servidores que puede tener un
sistema.
Arquitectura con un solo servidor: la gestión de los clientes se basa en
una única estación de trabajo que administra la atención de todas las
peticiones de forma centralizada, tal como lo representa la Figura II. 4.
Por lo tanto una simple computadora puede servir para funcionar como
servidor de audio y video. Si existen sistemas donde la cantidad de
recursos es elevada, se debe buscar una computadora donde los
requerimientos sean mucho más sofisticados (ejemplo gran procesador).
FIGURA II. 4 Arquitectura centralizada basada en un solo servidor
Referencia: http://wikitel.info/images/9/9e/RedservidorIPTV.jpg
Arquitectura con varios servidores: se propone para mejorar los
problemas y limitaciones de la arquitectura con un solo servidor, ya que
tener más servidores va a permitir tener un servicio escalable. Es por ello
que dentro de este se conocen dos tipos de arquitecturas más: la
- 46 -
arquitectura que posee servidores paralelos y la otra que es tener un
clúster de servidores.
2.2. CODEC
La conversión de ondas analógicas a ondas digitales se lo realiza a través de un
codificador - decodificador (CODEC).
Un CODEC es una serie de funciones algorítmicas, un pequeño programa, pieza de
software o controlador, que tiene la capacidad de comprimir y descomprimir secuencias
de datos de audio y video en su propio formato. El CODEC transforma dichas
secuencias a datos que puedan ser enviados por la red, para obtener una mejor calidad
de voz y video, por ende un CODEC debe utilizar la menor cantidad de información
para lograr tener una tasa de bits sumamente baja, es decir debe ser eficiente.
2.2.1. CODEC DE VIDEO
Todo archivo multimedia y en especial los videos, ocupan y requieren gran capacidad
de almacenamiento en un computador, no importa si el video es de mínima duración, de
unos pocos minutos, con una resolución apenas aceptable o es de larga duración, de
igual forma va a requerir un medio donde almacenarse (disco duro, CD (disco
compacto), DVD (disco de almacenamiento de datos)), debido a estos motivos se
ocupan los algoritmos de compresión y descompresión mejor conocidos como: CODEC
para obtener un almacenamiento mucho menor.
En la actualidad existen dos tipos de CODEC's para manejar archivos multimedia como
lo son: CODEC de video y CODEC de audio, de los cuales se limitará al estudio de los
de video.
Un CODEC de video en sí es un tipo de CODEC (algoritmo de compresión) que
permita comprimir o descomprimir un video digital, tomado de Apuntes SyT [3].
- 47 -
2.2.2. COMPRESIÓN DE VIDEO
En un sistema de video digital existe una etapa de compresión de video que se entiende
como codificación de video. Esta etapa es un proceso muy importante, ya que éste
reduce la cantidad de información (número de bits) necesaria para representar,
transmitir y almacenar un contenido de video sin disminuir la calidad de imagen.
La compresión se define por dos sistemas: el codificador y el decodificador. El
codificador convierte una señal de video a un formato comprimido. Este formato es
conocido por el decodificador el cual reconstruye la señal de video para ser luego
presentada en un reproductor.
2.2.2.1. FUNCIONAMIENTO DE LA COMPRESIÓN DE VIDEO
La compresión de video implica reducir y eliminar datos redundantes del video para que
el archivo de video pueda enviarse y almacenarse de manera eficiente en discos duros
del computador.
En el proceso de compresión se aplica un algoritmo al vídeo original para crear un
archivo comprimido y listo para ser transmitido o guardado. Para reproducir el archivo
comprimido, se aplica el algoritmo inverso y se crea un vídeo que incluye prácticamente
el mismo contenido que el vídeo original. El tiempo que se tarda en comprimir, enviar,
descomprimir y mostrar un archivo es lo que se denomina latencia. Cuanto más
avanzado sea el algoritmo de compresión, mayor será la latencia, según Axis
Communications [4].
Es decir que si en el proceso de compresión se utiliza un determinado algoritmo, se
necesitaría entonces tener instalado en la máquina receptora el mismo algoritmo, ya que
- 48 -
el proceso de compresión se basa en codificar la señal para enviarla por la red y
decodificarla al momento de la visualización de video.
2.2.2.2. TIPOS DE COMPRESIÓN DE VIDEO
Dependiendo del método de compresión que se utiliza existen diferentes tipos de
CODEC's, por ende la compresión de video se lo hace de dos maneras, explicadas a
continuación:
a. COMPRESIÓN CON PÉRDIDAS
El sistema de compresión elimina aquella información de las imágenes que es
prácticamente inapreciable por el ojo humano. La calidad de imagen depende
directamente de la cantidad de información que se haya eliminado, esto se conoce con el
nombre de grado de compresión. A mayor grado de compresión menor calidad de
imagen y viceversa, tomado de Universidad Nacional de Educación a Distancia [5]. Los
efectos negativos de este método compresión son el empobrecimiento del tono y la
nitidez global.
Dentro de los CODEC's más utilizados para la compresión con pérdida se tiene los
siguientes: tomado de Apuntes SyT [3]:
AVS (Audio de video estándar), Cineform, Cinepak, Dirac
H.261, H.264, H.263, Nero Digital, Xvid, Theora
b. COMPRESIÓN SIN PERDIDAS
Este tipo de compresión se refiere a que conserva todos los datos de la señal original
para cuando llega el momento de la descompresión, se obtenga la imagen tal y como era
en un principio, tomado de Universidad Nacional de Educación a Distancia [5]. La
compresión sin pérdida de datos, es utilizada para comprimir archivos o información
- 49 -
que contienen datos que no pueden ser degradados o perdidos, como pueden ser
documentos de texto, archivos ejecutables, etc
Dentro de los CODEC's más utilizados para la compresión sin pérdida se tiene los
siguientes: tomado de Apuntes SyT [3]:
AVIzlib , CorePNG , Dirac, FastCodec
Ffv1, SheerVideo, x264, YULS
Como se mencionó anteriormente los CODEC's H.264, Xvid y Theora son los propicios
para llevar a cabo nuestro estudio por ser de distribución libre, altamente utilizados en el
mercado, eficientes y sobre todo apropiados para el manejo de la transmisión
multimedia.
2.2.3. CODEC H.264
El CODEC H.264 AVC (CODEC de Video Avanzado) fue aprobado en Marzo del
2003, sus inicios se dio a principios del año 98, cuando el VCEG (Grupo de Expertos en
Codificación de Video) propusieron reunirse para trabajar conjuntamente en un nuevo
proyecto llamado H.26L, con el objetivo de que dicho proyecto pueda duplicar la
eficiencia de codificación respecto a estándares desarrollados anteriormente, finalmente
en Diciembre del 2001 se formó un JVT (Equipo de Video Conjunto) el cual ayudaría a
terminar el proyecto H.26L.
El CODEC H.264 cubre dos capas de desarrollo, descritas a continuación:
VCL (Capa de Codificación de Video): se encarga de todo el procesamiento,
codificación y compresión de la señal de video, Nicholls & Reina [6].
NAL (Capa de Abstracción de Red): Pensando en los ambientes de red sobre
el cual está orientado el desarrollo del estándar H.264, se provee una capa que
- 50 -
brinda información de cabecera a cada dato del VCL, de manera apropiada para
las diferentes capas de transporte o medios de almacenamiento, Nicholls &
Reina [6].
2.2.3.1. IMPORTANCIA
EL estándar H.264/AVC surgió con el objetivo de crear un estándar que fuera capaz de
proporcionar una buena calidad de imagen, reduciendo notablemente el flujo de bits de
salida de la secuencia de video codificada, y cuyo objetivo adicional es que se pueda
aplicar a una gran variedad de aplicaciones, como el almacenamiento en Bluerays,
videoconferencias, televisión por cable, aplicaciones a bajo caudal, televisión HD (Alta
Definición) y video streaming a través de internet, etc.
H.264/AVC permite comprimir mucho más las secuencias de video y proporcionar
mayor flexibilidad, destinada a satisfacer el mayor número de aplicaciones posibles,
admite alta robustez frente a errores y tolera errores en la transmisión en la red bajando
considerablemente su latencia.
2.2.3.2. CARACTERÍSTICAS
A continuación se presenta las características de la norma de codificación de alta
compresión H.264 o MPEG-4 parte 10.
Alcanza un alto nivel en calidad de video y compresión, puesto que es robusto a
errores, lo cual lo consigue porque incorpora un ordenamiento tolerante de
macro bloques FMO (Orden Flexible de Macroblock) y la transmisión
redundante de tramas.
Representa una extensión de los formatos antes ya desarrollados (MPEG-1,
MPEG-2, H.261, H.263) porque sigue manteniendo la base para la codificación.
- 51 -
EL formato H.264 emplea un módulo de transformación para el manejo de la
información residual y correlación espacial de los cuadros.
Presenta diferentes perfiles para el flujo de datos (bitstream). Estos especifican
un conjunto de características y alcances del codificador. Tales como elementos
de la sintaxis del estándar; esto determina la carga que opera sobre el
codificador. En la norma H.264 existen tres perfiles bases: baseline el cual se
emplea para aplicaciones de teleconferencia; main empleado para aplicaciones
de video digital de alta calidad; extended el cual se emplea en aplicaciones
multimedia para internet, Flores [7].
2.2.3.3. PERFILES
Un perfil de un CODEC es un conjunto de características identificadas, para cumplir
con un determinado conjunto de especificaciones de las aplicaciones previstas.
El formato H.264 incluye los perfiles: CBP (Perfil Básico Limitado), BP (Perfil Básico),
MP (Perfil Principal), XP (Perfil Extendido), HiP (Alto Perfil), Hi10P (Alto Perfil 10),
Hi422P (Alto Perfil 4:2:2), Hi444PP (Alto Perfil Predictivo 4:4:4) y Alto Perfil Estéreo,
Salavert [8].
CBP y BP: los dos perfiles son usados principalmente en aplicaciones de bajo
costo, pero BP requiere un grado adicional de robustez en la presencia de
errores, por tal motivo añade herramientas para recuperación de error.
MP: desarrollado inicialmente para las aplicaciones de difusión y
almacenamiento, lamentablemente su importancia fue opacado cuando apareció
el perfil High.
XP: delegado para video streaming, tiene una capacidad de compresión alta y
robustez de la pérdida de datos.
- 52 -
HiP: éste es el perfil principal para las aplicaciones de difusión y
almacenamiento en disco, en especial para aplicaciones de televisión de alta
definición, adoptado en HD DVD y Blue-ray Disc.
Los perfiles Hi10P, Hi422P, Hi444PP están basados en el perfil HiP usados para
video entrelazado donde la crominancia va variando, es decir se usan hasta 10 y
14 bits por muestra de precisión de la imagen.
Alto Perfil Estéreo: está orientado al video 3D estereoscópico y combinan las
herramientas del perfil High con capacidad de predicción inter-vista de la
extensión multi-vista de codificación de video, Salavert [8].
2.2.4. CODEC XVID
Es un CODEC de video gratuito y de código abierto, bajo GPL (Licencia Pública
General), apareció en el año 2004, desarrollado por programadores voluntarios de todo
el mundo, está basado en las librerías que utilizan los CODEC's DivX 4 y OpenDivX,
por ello existen numerosos colaboradores mejorándolo desinteresadamente, por su
calidad y eficiencia ha ganado gran popularidad y es utilizado en muchas aplicaciones
entre ellas video streaming.
Éste CODEC trabaja realizando compresiones con pérdida, es decir, aquellas donde la
copia, una vez comprimida es distinta byte a byte que al original, y habitualmente de
menor calidad (salvo algunos casos donde, con el uso de filtros de imagen, se pueden
arreglar determinados defectos de un video). Afortunadamente, utilizando un buen
programa de compresión y las configuraciones adecuadas, esta pérdida llega a ser
indistinguibles y permite comprimir una película DVD al tamaño de un CD con calidad
similar, tomado de MundoDivX [9].
- 53 -
DivX, Xvid, y 3DivX son diferentes implementaciones del estándar MPEG-4 Parte 2.
Éstos CODEC's proporcionan un factor de compresión muy alto, ya que usando un
bitrate similar al del VCD (Disco de Video Compacto) o SVCD (Super Disco de Video
Compacto), se obtiene una calidad de imagen muy similar al DVD. A su vez, mediante
el uso del CODEC MP3, se logra una óptima compresión de audio. Todo esto, al
encapsularse en el formato contenedor AVI, permite almacenar películas completas de
excelente calidad en 1 o 2 CD. Estos formatos se pueden reproducir en los nuevos
reproductores de DVD que tengan el logo de DivX Certified, tomado de DivXLand.org
[10].
2.2.4.1. CARACTERÍSTICAS
Las principales características del CODEC Xvid son las siguientes:
Compatible diferentes sistemas operativos (Linux, Windows, Mac).
Su instalación es fácil y rápida, garantiza la mejor calidad en audio y video.
Contiene un algoritmo de compresión que optimiza el espacio en computador.
Posee un simple panel de configuración, se adapta perfectamente a cualquier
entorno.
Permite la creación y el intercambio interoperable de video digital entre distintas
aplicaciones de software y una amplia gama de dispositivos.
2.2.4.2. PERFILES
Los perfiles que posee Xvid permiten que la codificación sea compatible con los
reproductores de mesa DivX. Posee un submuestreo de 4:2:2. El perfil AS (Avance
Simple) limita la resolución a 352 x 288 y la velocidad de transmisión de bits permite
hasta 384 Kbits/s. Los perfiles ARTS (Tiempo Real Avanzado de Streaming) limitan el
- 54 -
video a la misma resolución que el perfil simple pero el límite de velocidad de
transmisión de bits es de 4 Mbits/s.
Cada perfil tiene varios niveles con los que se puede variar la resolución/bitrate. Existe
también la posibilidad de configurar libremente el CODEC sin utilizar ningún perfil,
Beltrán & Basañez [11].
2.2.5. CODEC THEORA
Es un formato de compresión de video con pérdidas. Fue desarrollado por la fundación
Xiph.Org quien publicó la versión final el 3 de noviembre del 2008, y es distribuido sin
derechos de licencia, junto con sus otros proyectos de medios de comunicación libres y
de código abierto, WebAcademico [12], tiene una eficiencia similar al CODEC MPEG
4 - parte 2 con respecto al diseño y la tasa de transferencia, éste CODEC posee una
transformación y compensación de movimiento basada en bloque de coseno discreta de
8 x 8 por lo tanto le coloca en la misma clase de CODEC's que: MPEG 1, H. 263 Y
MPEG 2.
Generalmente trabaja junto con el CODEC de audio Vorbis o Flac, dentro de sus
ventajas, éste CODEC puede ser almacenado en cualquier formato contenedor, pero se
encuentra en el contenedor OGG, el mismo que resulta ser ideal para difundir streaming
de video por internet.
A diferencia de los CODEC's propietarios sin documentación pública disponible,
Theora presenta su documentación disponible para todos los usuarios en cualquier
momento y sin restricciones.
La naturaleza de ser código abierto hace que sea muy poco probable que pueda
desaparecer, lo que si puede pasar con los CODEC's propietarios una vez que sus
desarrolladores decidan abandonar el negocio.
- 55 -
El formato de compresión de video Theora es esencialmente compatible con el formato
de compresión video VP3, que consiste en un súper conjunto compatible con versiones
anteriores. Theora es un súper conjunto de VP3, donde las corrientes de VP3 se pueden
convertir en flujos de Theora sin re-compresión. La compresión de video VP3 puede ser
decodificada utilizando implementaciones Theora pero la compresión de video Theora
por lo general no se puede descodificar utilizando implementaciones antiguas VP3,
WebAcademico [12].
2.2.5.1. CARACTERÍSTICAS
Entre sus principales características se encuentran:
Transmisión a una tasa de bits variable y con pérdidas.
Tiene implementado el algoritmo DCT para comprimir archivos.
Se puede trasmitir prácticamente desde cualquier servidor HTTP.
Theora es multiplataforma, debido que en Linux funciona normalmente y
también existen soluciones fáciles de instalar en Windows y Mac OS (Sistema
Operativo).
Theora es adecuado para la entrega de contenido de internet.
A pesar de que es un formato de compresión libre no presenta eficiencia respecto a los
anteriores estándares de codificación, debido a que no tiene soporte para video
entrelazado y optimización de transmisión de videos de altas resoluciones.
2.2.5.2. PERFILES
Theora que actualmente soporta datos de video de dimensiones arbitrarias progresivas a
una velocidad constante en uno de los varios espacios de color Y'CbCr. Entre los
- 56 -
perfiles con los que el CODEC es compatible están tres formatos de submuestreo de
croma diferentes que son: 04:02:00, 04:02:02, 04:04:04, Barbato [13].
A continuación se presenta la Tabla II. 2 en manera de resumen sobre las principales
características, ventajas e historia de los CODEC's H.264, Xvid y Theora.
TABLA II. 2 Comparativa entre los CODEC's de video
H.264 Xvid Theora
Año de
lanzamiento
2003 2004 2008
Empresa o grupo
desarrollador
VCEG inicia un
nuevo proyecto
llamado H.26L. En
el 2001 se formó
JVT para terminarlo.
Es código abierto,
bajo licencia GPL,
desarrollado por
programadores
voluntarios de todo el
mundo.
Fundación
Xiph.Org, y es
distribuido sin
derechos de
licencia, código
libre.
Características y
Ventajas
Reduce el flujo de
bits. Proporciona
buena calidad de
imagen. Mayor
flexibilidad. Alta
robustez de errores.
Factor de compresión
alto, compatible con
diferentes sistemas
operativos, garantiza
mejor calidad de
audio y video.
Multiplataforma,
adecuado para
internet sobre
http, transmite a
una tasa de bits
variable, usa
DCT.
Tipo de
compresión
Con pérdidas Con pérdidas Con pérdidas
Usabilidad Videoconferencia,
Televisión por cable
y HD, video
streaming,
almacenamiento
Bluerays.
Video streaming,
almacena películas
completas en 1 0 2
CD, comprimir una
película DVD
Reproduce de
videos con
formato Ogv, Ogg
Streaming de
video,
CODEC similar
y contenedores
MPEG-4 parte 10,
MP4
MPEG-4 Parte 2, AVI MPEG-4 Parte 2,
OGG Vorbis
Algoritmos de
compresión
predecesores
MPEG-1, MPEG-2,
H.261, H.263.
Basado en las
librerías que utilizan
los CODEC's DivX 4
y OpenDivX
VP3, MPEG 1,
MPEG 2, H.263.
Submuestreo de
croma y luma
4:2:2, 4:4:4 4:2:0 4:2:0, 4:2:2, 4:4:4.
Fuente: Elaboración propia de los autores
- 57 -
2.3. PROTOCOLO DE INTERNET VERSIÓN 6
2.3.1. IPv6 - PROTOCOLO DE INTERNET VERSIÓN 6
Una dirección IP (Protocolo de Internet) se utiliza en internet para comunicar un
ordenador de manera similar que un número de teléfono, se utiliza para conectar a una
línea telefónica. Cada dirección IP es única y todos los datos que se transmiten a esa
dirección serán enviados a través del internet para llegar a su destino, Duarte [14].
Para que cada computador pueda tener una dirección del protocolo de internet es
necesario formar parte de una subdivisión, lo que conlleva a la asignación de una
dirección, es ahí donde el sistema de registros de internet tal como se presenta en la
Figura II. 5, entra en funcionamiento, ya que éste ha sido creado con el objetivo de
cumplir el proceso de ruteo e información, encargándose de que los espacios de
direcciones de internet sean asignados correctamente a los usuarios finales, cada una de
las organizaciones tiene una subdivisión y un espacio para poder utilizar direcciones, es
ahí donde los clientes de IPv6 para el presente trabajo han de utilizar la subdivisión /64
como mascara para la conexión con otros usuarios.
FIGURA II. 5 Sistema de distribución de jerarquía en el registro de internet Referencia: http://3.bp.blogspot.com/-XAaDmSXUSKg/UHSTvDOC1iI/AAAAAAAAAHY/r7U9mIWCBEI/s320/RegistroInternet_figura1.jpg
- 58 -
2.3.1.1. DIRECCIONES IP DISPONIBLES
El actual espacio de direcciones IPv4 contiene 4.3 mil millones de direcciones. El
número de direcciones que ofrece IPv6 es 340.282.366.920.938.000.000.000.000.000
trillones de trillones de direcciones (2 a la potencia de 128), lo que significa que el
tamaño de internet podría duplicarse cada año, y todavía así se tendría suficientes
direcciones para los próximos 96 años, Duarte [14].
2.3.1.2. CARACTERÍSTICAS DE IPv6
El protocolo de internet versión 6 es la nueva versión del protocolo de internet, diseñado
como el sucesor del protocolo de internet versión 4.
Los cambios de IPv4 a IPv6 según el RFC (Petición De Comentarios) 2460
Especificación Protocolo Internet, Versión 6 [15], recaen principalmente en:
Capacidades de Direccionamiento Extendida: IPv6 incrementa el tamaño de
dirección IP de 32 bits a 128 bits, para dar soporte a más niveles de
direccionamiento jerárquico, un número mucho mayor de nodos direccionables,
y una autoconfiguración más simple de direcciones. La escalabilidad del
enrutamiento multienvío se mejora agregando un campo ámbito a las
direcciones multienvío.
Simplificación del Formato de Cabecera: Algunos campos de la cabecera IPv4
se han sacado o se han hecho opcional, para reducir el costo del caso común de
proceso de tratamiento de paquete y para limitar el costo del ancho de banda.
Soporte Mejorado para las Extensiones y Opciones: Los cambios en la manera
en que se codifican las opciones de la cabecera IP permiten un reenvío más
eficiente, límites menos rigurosos en la longitud de opciones, y mayor
flexibilidad para introducir nuevas opciones en el futuro.
- 59 -
Capacidad de Etiquetado de Flujo: Una nueva capacidad se agrega para permitir
el etiquetado de paquetes que pertenecen a flujos de tráfico particulares para lo
cual el remitente solicita tratamiento especial, como la calidad de servicio no
estándar o el servicio en tiempo real.
Capacidades de Autenticación y Privacidad: Extensiones para utilizar
autenticación, integridad de los datos y confidencialidad de los datos.
A continuación se especifica un listado de resumen de más características de IPv6.
IPv6 presenta la oportunidad para actualizar funcionalidades, es decir este
protocolo soporta Multicast, QoS (Calidad de Servicio) y movilidad.
El protocolo IPv6 ya no cuenta con direcciones broadcast.
Cada campo de una dirección IPv6 es conocido como prefijo, este prefijo
permite conocer su ruta de encaminamiento.
Cualquier campo de la dirección IPv6 puede contener una cantidad de bits sólo
de ceros o sólo de unos.
Las direcciones IPv6 se las debe colocar a las interfaces de red, asociando la
dirección con un prefijo de subred con un enlace, para el presente trabajo se
tiene prefijo /64.
Cuando se configura una dirección IPv6, aparte de la dirección de la interfaz
aparece una dirección de enlace local/global.
Otra de las principales diferencias respecto a IPv4 se encuentra en el formato de
cabecera tal como se presenta la Figura II. 6, toda la información de este
formato se describe en el RFC 2460 Especificación Protocolo Internet, Versión
6 [15].
- 60 -
FIGURA II. 6 Cabeceras de IPv4 e IPv6
Referencia: http://www.redclara.net/imag/var/MapTopolDecember_08_2006.gif
2.3.1.3. TIPOS DE DIRECCIONES IPv6
A nivel general, las direcciones de IPv6 se las clasifica en tres grandes categorías
descritas a continuación:
Unicast
o Link-Local
o Site- Local
o Global- Local
o Dirección inespecífica
o Dirección de Loopback
o Compatible con IPv4
Multicast
Anycast
a. DIRECCIONES UNICAST
Al igual que en IPv4, son las más comunes y utilizadas. Estas son asignadas a una
interface o nodo permitiendo la comunicación directa entre dos nodos de la red. Ésta
técnica de comunicación es conocida como uno a uno (one-to-one), Duarte [16].
- 61 -
A continuación se puede ver un ejemplo de una dirección IPv6 Unicast:
2001:1dc9:4d5c:0026:0000:0000:1e3g:2a3b/64
b. DIRECCIONES MULTICAST
Las direcciones Multicast permiten identificar múltiples interfaces o nodos en una red.
Con éste tipo de direcciones existe la posibilidad de comunicarse con múltiples nodos
de manera simultánea. Ésta técnica de comunicación es conocida como uno a mucho
(one-to-many), Duarte [16]. Se presenta un ejemplo de una dirección IPv6 Multicast:
FF13:0:0:0:0:0:0:40
c. DIRECCIONES ANYCAST
Las direcciones Anycast son un nuevo tipo de dirección en IPv6. Al igual que una
dirección Multicast, una dirección Anycast identifica múltiples interfaces, sin embargo,
mientras que los paquetes de Multicast son aceptados por varios equipos, los paquetes
Anycast sólo se entregan a una interfaz o nodo, Duarte [16]. Se presenta un ejemplo de
una dirección IPv6 Anycast: 2002:0ef8:7402::/128
Para finalizar la explicación respecto a los tipos de direcciones de IPv6, se cree
conveniente realizar una acotación referente a los tipos y los prefijos de direcciones, tal
como se observa en la Tabla II. 3., representada a continuación.
TABLA II. 3 Tipos de direcciones IPv6 y Prefijos
Dirección IPv6 Prefijo – Notación IPv6
Dirección inespecífica (no especificada) :: /128
Dirección reservada de Loopback ::1 /128
Multicast FF00::/8
Link- Local Unicast FE80::/10
Site- Local Unicast FC00::/7
Global- Local Unicast Todas las demás
Fuente: Elaboración propia de los autores
- 62 -
2.4. MULTICAST
Multicast también conocido como multidifusión IP es una comunicación generada entre
un solo emisor (fuente) y múltiples receptores (grupo de destinatarios) dentro de una
red, permitiendo que una única transmisión pueda ser dividida entre varios usuarios, es
decir se establece una relación de uno a muchos, lo que reduce significativamente el uso
de ancho de banda en internet, tomado de TechTerms.com [17].
En este tipo de comunicación, la dirección de la fuente es una dirección Unicast, pero la
dirección de destino es una dirección de grupo, un grupo de uno o más
destinos/receptores. La dirección de grupo define a los miembros del grupo, que pueden
estar localizados en cualquier sitio en internet o en una red privada.
2.4.1. ÁREAS DE APLICACIÓN Y USABILIDAD
La multidifusión se utiliza para transmitir de manera eficiente transmisiones multimedia
y otros tipos de datos entre ellos se puede recalcar aplicaciones como: uso general para
sistemas distribuidos y para los medios de streaming a través de internet, tales como la
televisión en vivo y radio por internet.
También soporta video conferencias, servicios DNS (Sistema de Nombres de Dominio),
servicios de tiempo y webcasts. Además se puede utilizar para enviar información
variada a través de internet, tales como: juegos en red, noticias, cotizaciones de bolsa,
educación a distancia, servicios de descubrimiento, replicación de bases de datos e
incluso copias digitales de software, tomado de TechTerms.com [17].
2.4.2. ESTRUCTURA DE UNA DIRECCIÓN MULTICAST EN IPV6
En IPv6 se tiene todo un bloque completo de direcciones para Multicast, los cuales
empiezan desde el rango FF00::/8 hasta el rango FFFF::/8.
- 63 -
A continuación en la Figura II. 7. se presenta los bloques de una dirección Multicast
IPv6.
FIGURA II. 7 Dirección Multicast en IPv6
Fuente: Elaboración propia de los autores
Explicando la Figura II. 7, a continuación se detalla cada uno de los octetos.
Primer octeto conocido como de mayor orden: una dirección Multicast siempre
empieza con FF, es decir 11111111 en binario.
Primeros 4 bits del segundo octeto conocido como Flags: se encuentra formado
por 4 bits, donde el primer bit está reservado para futuras implementaciones, el
segundo bit es el R, el tercer bit se conoce como punto de encuentro P y el
cuarto bit es el Transient T, donde los valores varían entre uno o cero,
dependiendo si son valores bien conocidos permanentemente asignada por
IANA (Autoridad De Asignación de Números de Internet) tendrá el valor de
cero y si con valores variables poseerán el valor de uno.
- 64 -
4 bits del segundo octeto conocido como Scope: Indica el ámbito de aplicación
del conjunto de redes IPv6, para el que deber ser destinado el paquete Multicast.
Además provee información por medio de los protocolos de enrutamiento
Multicast, donde los routers utilizan el ámbito de multidifusión para determinar
si el tráfico Multicast se puede reenviar. Es un valor desde 0 a 0xF en diferentes
ámbitos según el RFC 2373 IP Version 6 Addressing Architecture [18], el cual
lo recomendamos para la identificación de los valores que este campo deberá
poseer, en dicho documento se menciona algunos valores que no están siendo
utilizados como 3, 4, 6, 7, 8, A, B, C, D. Para el presente trabajo se utiliza el
valor “e”, el cual es un valor de scope global que se lo puede utilizar sin
problemas.
Group ID: el identificador de un grupo de Multicast está formado por el flag y
el scope, los valores que éstos reciban son de gran importancia para la
identificación de estos 128 bits restantes.
2.4.3. COMUNICACIÓN EN UNA RED MULTICAST
Las direcciones Multicast de IPv6 son fundamentales en la nueva era informática, por
tal motivo se describe su funcionamiento. Una dirección Multicast en IPv6 se define
como un identificador para un grupo Multicast IPv6, éste es un grupo de usuarios
receptores que desean recibir un flujo de datos en particular, dicho grupo no tiene
fronteras físicas o geográficas, por ende se pueden localizar en cualquier lugar de
internet o en cualquier red privada.
Un usuario puede pertenecer a uno o varios grupos Multicast. Los usuarios pueden
escuchar múltiples direcciones Multicast al mismo tiempo, estos usuarios pueden unirse
- 65 -
o dejar el grupo Multicast en cualquier momento, esto se debe a que la pertenencia a un
grupo de multidifusión es dinámica.
Si un usuario receptor está interesado en recibir flujo de datos que se estén emitiendo,
debe pertenecer a un grupo en particular señalado por su router local. Esta señalización
se consigue con el protocolo MLD (Descubrimiento de Oyentes de Multidifusión), los
routers utilizan el protocolo MLD para saber si los miembros de un grupo están
presentes en sus subredes directamente conectadas. Los usuarios se unen a grupos
Multicast enviando mensajes de informe MLD, tomado de Cisco System [19].
El flujo de datos Multicast llegará a un número ilimitado de receptores pertenecientes a
un grupo, utilizando solo una copia de datos de multidifusión en cada subred, con ello
se permite tener niveles de eficiencia de red superiores, disminuyendo los ciclos de
procesamiento de CPU (Unidad Central De Proceso) de las computadoras en la red,
tomado de Cisco System [19].
Para un mejor entendimiento de lo mencionado se presenta a continuación la Figura II.
8, la cual presenta gráficamente la comunicación en una red Multicast.
FIGURA II. 8 Comunicación con trafico Multicast
Referencia: http://www2.san.gva.es/prof/calidadyacred/images/Image4.gif
- 66 -
2.4.4. PROTOCOLOS DE ENRUTAMIENTO MULTICAST CON IPV6
Al hablar de enrutamiento se está hablando de ruteo, éste es un proceso que se debe
implementar en equipos que soporten la configuración de protocolos de ruteo, en este
caso que soporten ruteo basado en IPv6, permitiendo que los paquetes se envíen y
reenvíen entre las máquinas pertenecientes a una red informática.
Con la llegada de IPv6, los protocolos de ruteo deben enfrentarse con varias
complicaciones, entre ellas:
El tamaño de una dirección IPv6 es cuatro veces el de una dirección IPv4. Esto
tiene consecuencias en el tamaño de memoria que se necesita para almacenar
estas direcciones y en el ancho de banda necesario para enviar las
actualizaciones a los demás routers, tomado de Blog personal Sepulveda [20].
Una misma interfaz puede tener múltiples direcciones IPv6, tomado de Blog
personal Sepulveda [20].
El software IOS (Sistema Operativo de Interconectividad) de cisco soporta los
siguientes protocolos de ruteo para Multicast IPv6, Cisco System [19]:
MLD: Utilizado por los ruteadores para encontrar receptores para un grupo de
Multicast en los enlaces conectados directamente.
Protocolo Independiente Multicast – Modo Disperso (PIM-SM): Utilizado entre
ruteadores para saber porque interfaces enviar o no paquetes de Multicast.
Protocolo Independiente Multicast – Modo de Origen Especifico (PIM-SSM):
Igual que PIM-SM, con la característica adicional de poder especificar desde qué
origen recibir los paquetes de Multicast.
CAPÍTULO III
3. APLICACIONES DE DISTRIBUCIÓN LIBRE PARA SERVIDOR
STREAMING DE VIDEO
El manejo de aplicaciones gratuitas en un país, institución u organización es de suma
importancia, ya que los softwares no licenciados permiten un ahorro en los recursos
económicos de cualquier institución y ayudan al desarrollo local y/o personal.
El presente capitulo tiene como propósito detallar las principales características de las
aplicaciones de software libre en cuanto a facilidades y optimizaciones de la tecnología
streaming de video se refiere, ya que dicho análisis va a permitir determinar la
aplicación más adecuada para la configuración del servidor streaming, además dicha
aplicación debe soportar transmisiones bajo la tecnología Multicast e IPv6, debido a que
en eso se enfoca el presente estudio.
- 68 -
3.1 CARACTERÍSTICAS DE UN SERVIDOR STREAMING DE VIDEO
La transmisión de contenido multimedia requiere un servidor con ciertas características,
en cuanto a almacenamiento, servicio en tiempo real, calidad de servicio y ancho de
banda se refiere, dichas características limitan considerablemente el número de clientes
que puede tener un servidor de streaming, por tal motivo a continuación se describe
brevemente cada una de estas para poder tomar las debidas precauciones.
Capacidad de almacenamiento: como ya se mencionó los archivos que
contengan información multimedia fácilmente exceden la capacidad de
almacenamiento que los discos duros poseen, por tal motivo se requiere
dispositivos de gran capacidad.
Servicio en tiempo real: para garantizar la reproducción continua de los
contenidos multimedia, no es suficiente con que el servidor de streaming envíe
los datos al usuario y éste los reciba correctamente; además hace falta que esta
recepción se reproduzca dentro un intervalo de tiempo específico. Esto implica
que todos los componentes del sistema deben tener un control del tiempo
máximo permitido para poder realizar cada uno de las operaciones que
intervienen en la entrega de información a los usuarios, Ibnoulkhatib [2].
Calidad de Servicio: en toda entrega de contenido multimedia que se realice a
través de una red informática es necesario proporcionar calidad de servicio
aceptable para el usuario, ya que la calidad de imagen, retraso y sincronización
de audio y video, pixeleo de la imagen, son aspectos que el usuario va a notar al
momento de una visualización de video, por ende estos aspectos necesitan de un
intensivo control al momento de la transmisión desde el servidor hacia los
clientes para verificar dicha calidad.
- 69 -
Ancho de banda: Los contenidos multimedia requieren el procesamiento de un
gran volumen de información de forma periódica y durante grandes periodos de
tiempo. Este volumen de información exige grandes anchos de banda en la red
de transmisión. Los requisitos de ancho de banda no se circunscriben
exclusivamente a la red de comunicaciones entre el servidor de streaming y los
usuarios finales, sino que también involucran al sistema de almacenamiento.
Esto implica la utilización de sistemas de almacenamiento complejos basados en
sistemas de almacenamiento jerárquicos o bien la utilización de un conjunto de
discos en configuración RAID (Conjunto Redundante de Discos
Independientes), Ibnoulkhatib [2].
Cabe mencionar que debido a estas características los servidores genéricos no pueden
ser utilizados para brindar el servicio de streaming.
3.2 APLICACIONES PARA REALIZAR STREAMING DE VIDEO
En la actualidad existe una gran variedad de softwares libres y propietarios, utilizados
por los administradores de red, para brindar el servicio de streaming de video sobre
demanda, en vivo o una combinación de ambas, proporcionando cada uno de los
servicios a través de ciertas configuraciones.
Entre los softwares con licencia propietario se tiene:
QuickTime Streaming Server (Apple), Real Media Server, Helix
Universal Server (Real Networks), Helix DNA Server (Real
Networks), Windows Media Server (Microsoft), Wonza Media
Server, Flash Media Server, entre otros.
- 70 -
Entre los softwares con licencia libre se tiene:
Flumotion, Video LAN (Red de Área Local) Server, Red5 Media
Server, Icecast, GNUMP3D, Ffmpeg Server, Darwin Streaming
Server, Live555, Sirannon, entre otros.
Además de estos, anteriormente existieron otros softwares que lamentablemente
ahora ya están fuera de funcionamiento como:
Milgra, Oregano, XL2 Media Server, Palantair, Subsonic,
PeerStream, Concurrent, BitBand, Entone, SeaChange, Kasenna,
Peercast
3.3 CARACTERÍSTICAS DE LAS APLICACIONES DE SOFTWARE LIBRE
La importancia de la utilización del software no licenciado en una institución son varias,
entre ellas se tiene: autonomía tecnológica, estandarización e integración, seguridad y
ahorro en los recursos económicos de cualquier empresa, destacando que no por ser más
económico es inseguro.
Por dichos motivos, a continuación se detalla las características de las principales
aplicaciones de software libre, considerando que entre sus principales características
deberá cumplir con ciertos parámetros como son: soporte de la tecnología Multicast,
protocolo IPv6 y transmisiones de video en vivo y sobre demanda.
FLUMOTION
Flumotion no es sólo un software para streaming de video, sino también es una
empresa que mantiene su oficina principal en la ciudad de Barcelona – España a
partir del año 2006. Desde sus inicios ésta empresa ha sido considerada como la
mejor para realizar transmisiones de audio y video en internet. La empresa
- 71 -
cuenta con un sin número de clientes y canales muy importantes entre los que se
puede mencionar RTVE (Radio Televisión Española), Grupo COPE, Antena 3,
BMW, Tele 5, etc.
Está basado en Linux, su licencia es libre, con la mayoría de componentes bajo
LGPL2.1 y el resto bajo GPL 2+, Expat y PSF-2. En función de lo que necesita
el cliente, Flumotion proporciona 3 tipos de productos: Flumotion Streaming
Plataform, Flumotion Streaming Server (Software) y Flumotion WebTV.
Una de las ventajas que posee Flumotion es ser una empresa especializada en el
streaming de contenido audiovisual (Streaming Media Server), ofreciendo
grandes posibilidades de estabilidad y escalabilidad.
El software Streaming Media Server que ofrece la empresa Flumotion, permite
tanto el streaming de ficheros en disco bajo demanda a través de HTTP hasta el
streaming en tiempo real de lo que se está grabando a través de una webcam, un
screencast, cámara de video, etc.
Además dicha aplicación se encuentra en los repositorios de la distribución de
Ubuntu que soporta los CODEC VP8 y Theora, por lo que permite la
transmisión de archivos con formato OGG y WEBM. Otra de las características
es que el software soporta la difusión Multicast más no soporta IPv6.
VIDEO LAN
Es una aplicación no licenciada que posee código abierto para cualquier usuario,
también es considerada como plataforma de video, puesto que puede ser un
reproductor, servidor o un plugins de algún navegador web para la reproducción
de videos en línea, dependiendo de las necesidades del usuario y el modo de
usabilidad que requieran.
- 72 -
Al ser considerado video LAN como un proyecto, es lógico considerar su etapa
de desarrollo, resumiendo de esta manera que el proyecto principal se
encontraba compuesto de dos tendencias descritas a continuación:
VLC (Video LAN Client): es un software que fue desarrollado en el
lenguaje de programación C/C++ para que pueda ser usado como
cliente, el cual era capaz de recibir tramas de video.
VLS (Video LAN Server): por su parte VLS también era un
software que se creó igualmente bajo el lenguaje de programación
C/C++, con el propósito principal de que este software genere flujos
de video. En la actualidad el software VLS ya no se desarrolla ni se
difunde, por ende su existencia es solo histórica y todas sus funciones
fueron heredadas para que forme parte de VLC.
Una vez descrito sus inicios, a continuación se presenta las principales
características del software VLC:
Soporta múltiples plataformas (Windows, Mac OS X, Linux, BeOS,
OpenBSD, etc).
Soporta protocolos: RTSP, UDP, RTP, HTTP, MMS (Servidor de
Medios Microsoft), IGMPv3 (Protocolo de Administración de grupos
de Internet).
Soporte de múltiples formatos.
CODEC de video
MPEG 1, MPEG 2, MPEG 4, DIVX 1, DIVX 2, DIVX
3, H.263, H.264, WMV 1, WMV 2, VP8, M-JPEG
- 73 -
(A/B), Theora, Dirac, XviD, 3ivX D4, H.261, H.263 /
H.263i
CODEC de audio
MPEG AUDIO, MP3, MPEG 4 AUDIO (AAC),
VORBIS, FLAC, SPEEX, WAV, WMA 2, A52/AC-3.
Contenedores
MPEG-TS, MPEG-PS, MPEG 1, ASF/WMV, WEBM,
MJPEG, MKV, OGG/OGM, WAV, RAW, MP4/MOV,
FLV, AVI.
Contiene filtros de manipulación y transcodificación de video.
Soporte redes IPv4 e IPv6.
Soporta transmisiones de video en Multicast y Unicast.
Permite la transmisión de cualquier video desde dispositivos que
capten video como la filmadora, DVD, VCD, SVCD y DVB
(Broadcast de video digital).
Permite guardar el video mientras se reproduce.
RED 5 MEDIA SERVER
Es un software gratis, de código abierto de FMS (Servidor de Medios Flash)
que puede hacer todo lo que Adobe FMS hace. Red 5 es perfecto para poder
transmitir video en vivo y transmisiones de audio, como también grabar
secuencias multimedia en vivo. Es compatible con todos los formatos
populares de audio y formatos de video.
- 74 -
Red 5 es un potente software capaz de manejar hasta miles de conexiones
simultáneas a la vez. Es una alternativa mucho más barata en términos de
alojamiento como Adobe FMS.
El servidor de flash de código abierto escrito en java Red 5 puede soportar lo
siguiente:
Streaming de Video (FLV, F4V, MP4, 3GP).
Streaming de audio (MP3, F4A, M4A, AAC).
Permite grabar series de cliente (FLV y AAC en un contenedor FLV).
Objetos compartidos
Transmisión en vivo Publishing.
Remoting.
Soporte de protocolos: RTMP (Protocolo de Mensajería en Tiempo
Real), RTMPT (Protocolo de Mensajería en Tiempo Real Canalizado),
RTMPS (Protocolo de Mensajería en Tiempo Real Asegurado) y
RTMPE (Protocolo de Mensajería en Tiempo Real Encriptado).
La multidifusión no está disponible en Flash. Por esa razón, ningún servidor de
medios puede ofrecer una solución Multicasting para Flash Player. En lo que
respecta a Red 5 cuenta con la funcionalidad de unicasting para sus
transmisiones. Para el presente trabajo otra de las deficiencias que presenta
dicho servidor es que no permite la configuración del nuevo protocolo IPv6.
A continuación en la Figura III. 1, se puede visualizar la imagen principal del
servidor de streaming RED 5.
- 75 -
FIGURA III. 1 Servidor de streaming RED 5
Referencia: http://tyskiebusiness.files.wordpress.com/2010/05/picture-4a.png
ICECAST
Es un servidor de streaming de licencia libre originalmente de audio, pero
también soporta video en sus últimas versiones, como es en el Icecast versión 2.
Se puede montar un servidor Icecast en sistemas operativos como: Windows,
Linux y Mac.
Es un proyecto de código libre mantenido por la Fundación Xiph.org sin fines de
lucro, dedicada a la reproducción de herramientas de dominio público, hogar de
la familia de software de Ogg/Vorbis.
Como en su forma original Icecast fue creado para la trasmisión de audio en
internet, éste puede ser utilizado para crear una estación de radio para alguna
empresa o también se puede crear una página web para tener un repositorio de
música en la que se use de manera personal.
- 76 -
La manera de operar de éste servidor es parecida al software bajo licencia
llamado Shoutcast perteneciente a Nullsoft. Los protocolos que el servidor
utiliza son: HTTP Y SHOUTcast2, los formatos que soporta en sus últimas
versiones streams son: Ogg Vorbis, MP3, Ogg Speex, Ogg FLAC, Ogg Theora,
NSV, y AAC.
Icecast gestiona la autenticación de clientes y proveedores de audio, proporciona
varios streaming de forma simultánea y puede variar la calidad de audio
limitando el número de clientes que se pueden conectar.
Prácticamente permite la transmisión de las listas de archivos de audio y video
que el servidor Icecast tenga bajo su directorio, para lo cual el cliente deberá
conectarse desde su navegador web, donde ingresará la dirección del servidor,
seguido del puerto; cabe mencionar que esta aplicación permite transmisión en
vivo y sobre demanda mediante la web, dicho software presenta ciertas
limitaciones como soporte del protocolo IPv6 y transmisión mediante la
tecnología Multicast.
GNUMP3D
Es un servidor streaming de audio y video que permite transmisiones bajo
demanda y soporta el protocolo IPv4, está escrito inicialmente en C, C++, hasta
terminar en lenguaje Perl.
Permite reproducir ficheros de música y video en diferentes formatos, desde otro
ordenador distinto del que están almacenados estos ficheros, es compatible con
archivos de audio como: 669, AAC, APE, M4A, FAR, FLAC, IT, MID, MOD,
- 77 -
MP3, MTM, OGG, RA, RM, S3M, STM, ULT, WAV, XM, WMA, M4P, MPC,
AIF, AIFF, SHN y archivos de video como: MOV, MPG, MPEG, AVI, WMV.
Esta aplicación fue revelada por Steve Kemp el 18 de Octubre del 2007, se
distribuye bajo licencia GNU-GPL, forma parte del proyecto Edna, es poco
conocido debido a su falta de publicidad, a pesar de ello resulta ser de gran
utilidad para aquellas personas que les gusta intercambiar información a través
de red locales o mediante amigos en línea.
El contenido multimedia es accesible mediante cualquier navegador web, brinda
la posibilidad de escoger la plantilla que más nos agrade o permite la creación de
una plantilla personalizada mediante código HTML (Lenguaje de Marcas de
Hipertexto) y CSS (Hojas De Estilo en Cascada). Se caracteriza por ser pequeño,
estable, portable, seguro, fácil de instalar, configurar y usar.
Es compatible con diferentes plataformas como son: Windows, Unix, GNU.
Dentro de los clientes que soportan sus transmisiones se tiene: XMMS,
FreeAmp y WinAmp.
Gnump3d resulta ser entonces un servidor streaming capaz de servir su
contenido multimedia audio y video mediante la web, usando el protocolo
HTTP, además se caracteriza por pasar datos de la canción como título y autor
solo con habilitar el protocolo ShoutCast.
La forma de trabajar de este servidor para la transmisión de audio y video en la
red, varían en ciertas configuraciones que se las debe realizar en su archivo
master, ubicado por lo general en: "/etc/gnump3d/gnump3d.conf", en dicho
- 78 -
archivo se debe configurar las líneas de código referentes al número de puerto
(port) y la dirección de la carpeta contenedora de los archivos ya sea audio o
video (root), una vez especificado estos parámetros con una serie de comandos
se procede a indexar los datos de las carpetas a la página web que la aplicación
Gnump3d brinda para que los clientes puedan tener acceso desde cualquier sitio.
A continuación en la Figura III. 2 se presenta la pantalla principal de Gnump3d,
en la que se puede observar un listado de canciones a reproducir.
FIGURA III. 2 Servidor de streaming Gnump3d
Referencia: http://dl.maximumpc.com/galleries/linuxstream/gnump3g1.png
FFMPEG
Es el marco multimedia líder, capaz de decodificar, codificar, transmitir,
reproducir casi cualquier cosa que las personas y las máquinas han creado,
permite además hacer streaming de audio y video. Es compatible con los
formatos antiguos sin importar si fueron diseñados por algún comité de normas,
comunidad o una sociedad anónima, por ende funciona bajo la licencia GNU en
Linux, aunque puede ser ejecutado en múltiples sistemas operativos incluyendo
Windows.
- 79 -
FFmpeg contiene libavcodec, libavutil, libavformat, libavfilter, libavdevice,
libswscale y libswresample que puede ser utilizado por las aplicaciones, este
proyecto ofrece varias herramientas como: ffmpeg, ffserver, ffplay y ffprobe que
puede ser utilizado por los usuarios finales para la transcodificación, streaming y
reproducción.
Ffserver: es un servidor de streaming de audio y video, compatible con varias
transmisiones en vivo, recibe archivos pregrabados o fluye archivos desde
alguna entrada, se apoya en los protocolos RTP / RTSP / HTTP.
DARWIN STREAMING SERVER (DSS)
El servidor QuickTime Streaming Server posee una versión de software libre no
licenciado gratuito que entro en funcionamiento a partir del 16 de marzo de 1999
y es desarrollado por la empresa Apple. Este es considerado como un servidor
de streaming que le permite enviar los medios de transmisión de audio y video a
los clientes a través de internet utilizando protocolos RTP y RTSP.
Darwin Streaming Server proporciona un alto nivel de personalización y se
ejecuta en una variedad de plataformas como: Linux, RedHat Linux, Solaris y
Windows NT/2000, que le permite manipular el código para satisfacer las
necesidades del cliente.
Entre los formatos que dicho servidor soporta se tiene: 3GP, MP3, MP4,
H.264/MPEG-4 AVC y MPEG-4 Parte 2, se cuenta con la última versión 6.0.3
estable, desarrollada en el 10 de mayo del 2007. Este servidor no soporta IPv6
pero si soporta tecnología Multicast.
- 80 -
A continuación se presenta la Figura III. 3 en la cual se visualiza la pantalla
principal del servidor Darwin Streaming
FIGURA III. 3 Servidor de streaming Darwin
Referencia: https://www.linux-user.de/ausgabe/2005/01/048-darwin/playlist2.png
A continuación se presenta la Tabla III. 1 donde se realiza una comparación de las
principales características de las aplicaciones de distribución libre ya descritas.
- 81 -
TABLA III. 1 Comparativa de aplicaciones de software libre
Flumotion VideoLAN Red5 Icecast Gnump3d FFmpeg DSS
Soporte de
Múltiples
Plataformas
Difusión
Unicast
Difusión
Multicast
Soporte IPv4
Soporte IPv6
Permite
Autenticación
Soporta
Monitoreo
Transmisión
en Vivo
Transmisión
sobre
demanda
Soporte
protocolos
RTP, RTSP
Soporte de
protocolo Http
CODEC de
Video
Vp8,
Theora
Mpeg
1,2,4
H.263,
H.264,
Xvid,
Vp8,
Theora,
Dirac,
Divx 2,
Divx 3,
Wmv 1,
Wmv2
FlV,
Mp4
,
3Gp,
F4V
Mp3,
Ogg
vorbis,
Ogg
Theora,
Ogg
Flac,
NSV,
AAC
Mov,
Mpg,
Avi,
Wmv,
Mpeg
Libdvd
css,
libavco
dec
3Gp,
Mp3,
Mp4,
H.26
4
Mpeg
-4
Fuente: Elaboración propia de los autores
Para el presente trabajo de investigación se requiere una aplicación de software libre
que cumpla con ciertas características básicas para llevar a cabo la resolución del
problema planteado como lo son: soporte para la tecnología Multicast, direccionamiento
sobre el nuevo protocolo de internet IPv6, compatibilidad con los CODEC's en estudio,
- 82 -
permita la emisión de video en vivo y sobre demanda, y que además dicha aplicación se
pueda configurar como un servidor streaming y como un reproductor multimedia en los
clientes, por tales motivos la aplicación seleccionada es VLC. Además de las
características mencionadas cabe recalcar que se busca una aplicación que contenga una
gama de contenedores, es decir distintas maneras de encapsular un video para emisiones
en la red, uno de esos contenedores puede ser el TS (Transporte de Streaming) los
cuales son nuevos contenedores creados y diseñados para soportar pérdidas y errores en
una transmisión de largo alcance, es decir fueron creados especialmente para hacer
streaming de video donde se encapsule el audio y video y se transmita en la red.
CAPÍTULO IV
4. DISEÑO E IMPLEMENTACIÓN DE AMBIENTES DE PRUEBA
El buen diseño e implementación de una red informática es fundamental en toda
empresa, y más aún en un trabajo de investigación, ya que éste permite evitar problemas
de: pérdidas de datos, seguridad, lentitud al momento de procesar la información y
sobre todo eliminar las caídas en la red.
El presente capítulo tiene como propósito dar a conocer la topología, diseño,
configuración y alcance de la red informática utilizada para llevar a cabo la
comprobación de cada uno de los CODEC's. Para realizar dicha comprobación se va a
describir los ambientes de prueba para la transmisión en directo y sobre demanda de
cada uno de los CODEC's, los mismos que constan de aspectos como instalación,
configuración y captura de datos.
- 84 -
4.1. TOPOLOGÍA, ALCANCE Y DISEÑO DE LA RED INFORMÁTICA
4.1.1. TOPOLOGÍA
La topología de red permite determinar la disposición física en la que se conectan los
equipos a una red de computadores o servidores.
Para el presente trabajo se decide utilizar la topología de red jerárquica, donde la
información fluye siguiendo un camino establecido, permitiendo llevar los mensajes
hacia los destinatarios finales.
Las redes jerárquicas se administran y se expanden de manera mucho más fácil
(escalabilidad) que otras redes, dichas redes constan de tres capas con funciones
específicas cada una y estas capas son: núcleo, acceso y distribución.
La capa de acceso es aquella que permite la conexión de los dispositivos finales sean
éstos computadoras, teléfonos, e incluso impresoras, a la red. La capa de distribución se
basa específicamente en los switch, ya que permite controlar el flujo de tráfico mediante
el uso de VLAN (Red de Área Local Virtual). Finalmente la capa de núcleo es la
encargada de proporcionar conectividad entre los distintos puntos de acceso (router,
switch, etc), permitiendo enlazar diferentes servicios, como: internet, redes privadas,
redes LAN y telefonía.
Es decir, cuando se quiere enviar datos desde una computadora hacia otra, éstos deben
pasar por la red de acceso, considerada como el primer punto para conectarse con los
routers, una vez que la información esté en dicho punto, son ellos los encargados de
enviar los datos a los destinatarios finales utilizando el núcleo de la red.
- 85 -
4.1.2. ALCANCE
Es imprescindible dar a conocer el alcance de una red informática que va a poseer el
presente trabajo, es decir explicar el tamaño geográfico y al número de equipos y/o
componentes físicos.
Debido a que la presente investigación tiene como propósito realizar una guía de
implementación de streaming para el laboratorio LIRSI-ESPOCH, se especifica que el
alcance del trabajo es con fines académicos, por ende su escenografía va a ser esencial-
básica, no tan compleja, donde se simule el internet y la transmisión de video en la red.
Además para el alcance del presente trabajo se va a tomar en cuenta el tiempo de plazo
(2 años) que un egresado de la ESPOCH posee para llevar acabo la elaboración del
trabajo de grado.
De acuerdo al alcance de la investigación, la infraestructura de la red jerárquica es
básica, por lo que se utilizará un número de equipos que satisfagan con el planteamiento
de los objetos de estudio en este caso: streaming, Multicast e IPv6, por tal razón se
necesita de tres routers cisco catalyst de la serie 2800 con IOS (Sistema Operativo de
Interconexión) C2801-ADVIPSERVICESK9-M) Version 12.4(8a) release software
(fc2), dos switch catalyst 2960 y computadores portátiles y de escritorio con
aceleradores de tarjeta gráfica, donde estos equipos van a estar conectados mediante
enlaces Fast Ethernet categoría 5e de tipo cruzado y directo.
- 86 -
4.1.3. DISEÑO Y FUNCIONAMIENTO DEL ESCENARIO DE
PRUEBAS
Los routers van a estar configurados con el protocolo de enrutamiento OSPF (Primer
Camino Más Corto) y el nuevo protocolo de internet versión 6, para la difusión de datos
sobre la tecnología Multicast, para lo cual se va hacer uso de los comandos de Cisco
para la configuración de cada uno de los equipos.
Cada router tendrá su propia configuración por lo que existe uno en el cual se da a
conocer el grupo Multicast, cabe recalcar que existen diferentes maneras de identificar
un grupo Multicast, en esta ocasión va a ser un grupo embebido en RP (Punto de
Encuentro), dicho punto es de gran utilidad dentro de una configuración con tecnología
Multicast, ya que éste escucha las peticiones por parte de los clientes y envía respuestas
a dichas peticiones, es aquí donde los mensajes PIM (Protocolo Independiente
Multicast) entran en funcionamiento permitiendo la comunicación entre los routers,
además de enviar y recibir información del grupo Multicast para entregar a los routers
fronteras que se conectan con los clientes por medio de switchs catalys 2960 y de los
mensajes MLD.
Los mensajes MLD permiten la comunicación con los bordes de las redes hacia cada
uno de los clientes mediante enlaces Fast Ethernet categoría 5e de tipo directo. Los
routers están conectados mediante enlaces Fast Ethernet categoría 5e de tipo cruzado
donde cada enlace va a estar configurado con un ancho de banda de 15 Mbps (Megabits
por segundo), debido al gran volumen de datos multimedia que un video requiere, lo
cual exige un requisito de ancho de banda riguroso sobre la red desde 56 Kbps (Kilobits
por segundo) hasta 15 Mbps, Thampi [1].
- 87 -
A continuación en la Figura IV. 1 se presenta el diseño general del escenario de
pruebas para el desarrollo del presente trabajo.
FIGURA IV. 1 Diseño del escenario de pruebas
Fuente: Elaboración propia de los autores
Los prototipos de prueba para cada uno de los escenarios fueron desarrollados
físicamente en los laboratorios de la academia de redes Cisco de la ESPOCH tal como
se muestra en la Figura IV. 2, ya que dichos laboratorios cuentan con el ambiente
apropiado y los equipos físicos necesarios para llevar a cabo la implementación de cada
uno de los escenarios.
FIGURA IV. 2 Prototipo de pruebas con equipos reales
Fuente: Elaboración propia de los autores
A manera de resumen, a continuación se presenta los comandos de las configuraciones
más relevantes.
- 88 -
Comando basado en el patrón de Cisco para configuración de una dirección del
nuevo protocolo de internet versión seis en una de las interfaces de red.
ServerStream(config)# interface FastEthernet0/0
ServerStream(config-if)# ipv6 address 2001:10::1/64
Comando basado en el patrón de Cisco para la configuración del protocolo de
ruteo compatible con IPv6. Actualmente los protocolos de ruteo compatibles son
OSPF, OSPFv3 o RIP (Protocolo de Información de Ruteo), para el presente
trabajo se utiliza el protocolo OSPF, ya que es un protocolo de ruteo interno que
distribuye la información entre los routers. Cabe recalcar que para la
configuración del protocolo OSPF se debe habilitar ruteo en IPv6, como nuestro
estudio es sobre tráfico Multicast este también será activado.
ServerStream(config)# ipv6 unicast-routing
ServerStream(config)# ipv6 Multicast-routing
ServerStream(config)# ipv6 router ospf 100
ServerStream(config-rtr)# router-id 1.1.1.1
ServerStream(config-rtr)# exit
Comando basado en el patrón de Cisco, útil para la configuración del grupo
Multicast que como ya se menciono va a ser un grupo embebido.
ServerStream(config)# interface FastEthernet0/0
ServerStream(config-if)# ipv6 mld join-group FF7E:240:2001:2:2:2:0:1
- 89 -
Comando basado en el patrón de Cisco para configurar un router como servidor
de DHCP (Protocolo de Asignación Dinámica de Direcciones) que brinde
direcciones del protocolo de internet versión 6:
RCLIENTE(config)# ipv6 dhcp pool streaming
RCLIENTE(config-dhcp)# prefix-delegation pool streaming-prefix-new
RCLIENTE(config-dhcp)# exit
RCLIENTE(config)# interface fastEthernet 0/1
RCLIENTE(config-if)# ipv6 address FC01::1/64
RCLIENTE(config-if)# ipv6 dhcp server streaming
RCLIENTE(config-if)# no shutdown
RCLIENTE(config-if)# exit
RCLIENTE(config)# ipv6 local pool client-prefix-pool FC01::/50 64
El archivo de configuración completa de cada uno de los equipos se detalla en el Anexo
1, mientras que en el Anexo 4 en la guía de implementación se detalla paso a paso la
configuración de cada uno de los equipos.
4.2. DIRECCIONAMIENTO DE LA RED
Una dirección IPv6 tiene un tamaño de 128 bits, los cuales se encuentran repartidos en 8
bloques, donde cada bloque está formado por números hexadecimales de 16 bits cada
uno (valor de 0000 a FFFF), separados por “:”.
Las direcciones IPv6 son muy largas por ende en ocasiones se usan secuencia de ceros
representado por doble punto“::”.
A continuación en la Tabla IV. 1 se da a conocer el direccionamiento IPv6 utilizado
para el presente trabajo.
- 90 -
TABLA IV. 1 Direccionamiento del escenario de pruebas
Identificador
del Router
Interfaz de
Red
Dirección
IPv6
Mascara de
Red
Puerta de
Enlace
Predeterminado
ServersStream F0/1 FC00::1 64
ServersStream F0/0 2001:10::1 64
PRedireccion F0/1 2001:10::2 64
PRedireccion F0/0 2001:20::3 64
RouterCliente F0/0 2001:20::4 64
RouterCliente F0/1 FC01::1 64
Clientes FastEthernet DHCP 64 FC01::1
Fuente: Elaboración propia de los autores
4.3. EQUIPOS USADOS PARA LA ARQUITECTURA DEL STREAMING
En el Capítulo II, se mencionó los componentes que forman parte de un sistema de
video streaming como lo son: servidor, cliente y red, además de mencionar las
principales características de las arquitecturas de red utilizadas para llevar a cabo el
streaming, debido a dichas características para el presente trabajo se utilizará la
arquitectura de red centralizada basada en un sólo servidor de streaming de video, el
mismo que será capaz de trasmitir la señal audiovisual al núcleo central de la red, el
cual estará configurado con la tecnología Multicast IPv6, para finalmente permitir a los
clientes disfrutar de dichas emisiones en sus reproductores.
A continuación se describe las principales características en cuanto a software y
hardware de cada uno de los clientes y servidores.
- 91 -
4.3.1. HARDWARE Y SOFTWARE DEL SERVIDOR DE STREAMING
DE VIDEO
a) SOFTWARE
En la actualidad es muy común encontrar a gran cantidad de empresas con equipos
sobre distribuciones libres, no sólo por las ventajas mencionadas sino también por el
cumplimiento al decreto N° 1014, el cual ordena el uso de software libre en todas las
instituciones públicas del país.
Para el presente trabajo se utilizará la distribución libre Ubuntu versión 12.10, ya que
permite habilitar o denegar paquetes Multicast, pero por lo general la multidifusión en
Ubuntu ya viene habilitado por defecto y además permite la configuración de red con el
protocolo IPv6, a diferencia de otras distribuciones como Fedora que no viene
habilitado el tráfico Multicast.
Como se puede observar en la Figura IV. 3, Ubuntu es un sistema operativo basado en
Linux que incluye su propio entorno de escritorio Unity, orientado al usuario promedio,
distribuido bajo licencia libre, su kernel es basado en Unix, de fácil uso, rápido,
accesible, libre de virus, eficiente y con gran tendencia a crecer cada día más según la
página DistroWatch.com.
FIGURA IV. 3 Pantalla principal de la distribución Ubuntu
Fuente: Elaboración propia de los autores
- 92 -
b) HARDWARE
Una máquina será el servidor streaming por lo que deberá cumplir con algunas
características, como: tener gran capacidad de almacenamiento para alojar los videos
pero las capacidades de hardware van a variar, ya que esto depende de la aplicación de
software que utilice para la configuración.
Además debe tolerar la instalación de la distribución de Linux Ubuntu, que como
mínimo para su utilización se necesita 384 MB de RAM, 8 GB de disco duro y un
procesador de 1000 MHZ.
A continuación en la Tabla IV. 2, se detalla las características físicas de la máquina
sobre la cual fue configurada la distribución libre y la aplicación para realizar streaming.
TABLA IV. 2 Características de la máquina designada para Servidor
Características Valor
Procesador Pentium(R) Dual- Core
Velocidad del Procesador T4500 2.30GHz
Memoria RAM 3.00 GB
Disco Duro 300 GB
Tipo de sistema 32 bits
Tarjeta gráfica Mobile Intel(R) 4 Series Express
Chipset Family, de modelo Intel(R)
GMA 4500MHD, posee un acelerador
gráfico, con memoria dedicada de
128Mb, memoria compartida de 1231
Mb y una resolución de 1366 x 768.
Otras características Wifi 802.11 b/g/n, webcam, Ethernet
gigabit, micrófono, teclado, mouse,
cargador.
Fuente: Elaboración propia de los autores
- 93 -
c) CONFIGURACIÓN DEL SOFTWARE PARA LA EMISIÓN
DE VIDEO
Inicialmente VLC se lo conoce como un cliente de video LAN – Video LAN Client, es
un reproductor de medios, capaz de reproducir los formatos de audio y video más
difundidos de manera totalmente autónoma con un resultado excelente gracias a un
tratamiento posterior de la imagen y el sonido con una calidad superior.
Actualmente VLC se lo puede configurar como servidor ya que todos los beneficios que
en su momento mantuvo VLS se lo trasladó a VLC, por lo tanto ahora VLC puede ser
usado como servidor para transmitir audio y video en vivo y sobre demanda en redes del
protocolo versión cuatro y seis, sobre tráfico de unidifusión y multidifusión, con el
soporte de CODEC's de audio y video, ya antes descritos.
VLC también puede ser usado como cliente, ya que permite recibir las tramas de video,
decodificando y visualizando gran variedad de estándares, entre ellos el flujo MPEG
sobre varios sistemas operativos debido a que es compatible para plataformas como:
Windows, Linux, Mac e incluso para Set-top box.
Dependiendo el software que se seleccione para configurar streaming, los requisitos van
a variar, a continuación en la Tabla IV. 3 se visualiza las características mínimas y
recomendadas para la instalación de VLC.
TABLA IV. 3 Requisitos de instalación para VLC
Características
Requisitos
Mínimos
Requisitos
Recomendaciones
Procesador 500 MHz 2.4 GHz
Memoria RAM 128 Mb 512 Mb
Espacio Libre en el disco
duro
50 Mb 100 Mb
Fuente: Elaboración propia de los autores
- 94 -
A pesar de que VLC es una aplicación que viene y reconoce casi cualquier CODEC
multimedia, es recomendable que antes de proceder a la instalación de dicho software,
se instalen CODEC's multimedia de diferente soporte, para lo cual se procede a la
ejecución de algunos comandos.
Instalar el meta paquete "ubuntu-restricted-extras", el cual es usado para
decodificar archivos de formato MP3, otros formatos de audio (plugins
GStreamer), las fuentes de Microsoft y para crear archivos de audio
comprimidos.
# sudo apt-get install ubuntu-restricted-extras
Instalar la librería “libdvdcss”, “libdvdcss2” para poder ver DVD's / CD's
originales o comerciales:
# sudo apt-get install libdvdcss2
Cuando se procede a la instalación de ubuntu-restricted-extras ya se instala la
librería "libdvdread4" en el directorio "/usr/share/doc", ahora sólo queda
ejecutarlo con el siguiente comando:
# sudo /usr/share/doc/libdvdread4/install-css.sh
La instalación de VLC es sumamente sencillo para lo cual es necesaria la ejecución de
algunos comandos que se detallan a continuación:
Se accede a los repositorios de video LAN y a obtener de este, la versión estable
del software.
# sudo add-apt-repository ppa:videolan/stable-daily
Actualización del sistema operativo.
# sudo apt-get update
- 95 -
Instalación de la aplicación y del plugin correspondiente para el navegador que
se tenga en la distribución.
# sudo apt-get install vlc browser-plugin-vlc
A continuación en la Figura IV. 4 se presenta la pantalla principal del software VLC,
luego de su instalación y listo para entrar en funcionamiento.
FIGURA IV. 4 Pantalla inicial de Software VLC en Ubuntu
Fuente: Elaboración propia de los autores
4.3.2. HARDWARE Y SOFTWARE DEL CLIENTE DE STREAMING
DE VIDEO
a) SOFTWARE
Los clientes que se encuentren conectados a la red, van a poseer un sistema operativo de
Windows o Linux. Si el cliente cuenta con un sistema operativo de software libre, es
preferible que tenga instalado la distribución de Ubuntu en la misma versión que la
instalada en el servidor, debido a las ventajas que presenta, si caso contrario el cliente
posee un sistema operativo de software propietario, se aconseja que por el momento
- 96 -
maneje una versión conocida capaz de soportar IPv6 como: Windows Seven Ultimate,
Home o Professional.
Cada máquina cliente además de contar con un sistema operativo, debe tener instalado y
configurado un reproductor de multimedia, éste será capaz de recibir los flujos de
información que el servidor de streaming este emitiendo, para el presente trabajo se
necesita que cada cliente ya sea propietario o libre tenga instalado el software VLC.
b) HARDWARE
Se va a utilizar computadoras de escritorio y portátiles con diferentes características, en
cuanto al sistema operativo, capacidad del procesador, memoria y sobre todo acelerador
en las tarjetas de video gráficas se refiere.
A continuación en la Tabla IV. 4, se presenta las características de una de las maquinas
portátiles utilizadas como cliente.
TABLA IV. 4 Características de la máquina cliente portátil
Características Valor
Procesador Intel(R) Core (TM)
Velocidad del Procesador T6500 2.10GHz
Memoria RAM 2.00 GB
Disco Duro 320 GB
Arquitectura del sistema 32 bits
Sistema Operativo Ubuntu 12.10
Características de la tarjeta de video Mobile Intel(R) 4 Series Express
Chipset Family, de modelo Intel(R)
GMA 4500MHD, posee un acelerador
gráfico, con memoria dedicada de
64Mb, memoria compartida de 1631
Mb, y una resolución de 1366 x 768.
Características de la tarjeta de red Realtek PCIe FE Family Controller
Fuente: Elaboración propia de los autores
- 97 -
En la Tabla IV. 5 mostrada a continuación se presenta las características de una de las
máquinas de escritorio usadas como cliente de un sistema de multidifusión para la
captura de datos.
TABLA IV. 5 Características de la máquina cliente de escritorio
Características Valor
Procesador Intel(R) Core
Velocidad del Procesador I3-530 2.93 GHZ
Memoria RAM DDR3 4 GB
Disco Duro 500 GB SATA 7200 RPM
Tarjeta Madre INTEL DH55HC SOCKET 1156
Sistema Operativo Windows 7, Ubuntu 12.10
Características de la tarjeta de
video
Tarjeta de video Nvidia, de
modelo Nvidia Geforce EVGA GT
640, con una frecuencia de
memoria de 1 GB con una interfaz
de 64-bit GDDR5, con una
resolución de 2560 x 1600, con
soporte para conectividad
multimedia VGA, HMDI, Dual
Link DVI-D
Características de la tarjeta de red Realtek PCIe FE Family
Controller
Fuente: Elaboración propia de los autores
4.4. EQUIPOS UTILIZADOS PARA UNA TRANSMISIÓN EN VIVO
Para este tipo de difusión se necesita de dispositivos importantes como lo son: tarjeta
capturadora de video y una filmadora.
4.4.1. CARACTERÍSTICAS DE LA TARJETA CAPTURADORA Y
FILMADORA
Tarjeta Capturadora de Video
La tarjeta utilizada es una EasyCAP de marca Syntek, la cual permite capturar vía USB
2.0, todo tipo de imágenes y vídeos, además de pasar a digital películas desde
- 98 -
videocámaras, videoconsolas, TV, VHS (Video de Sistema Casero), DVD, etc. Este
accesorio dispone de cuatro conectores: los tres conectores conocidos RCA son audio
estéreo y vídeo, el último conector se lo conoce como: S-VIDEO. Soporta control del
brillo y contraste, soporta NTSC, PAL, SECAM, posee una entrada RCA Compuesto y
una S-Video, es fácil, pequeño, transportable, tiene entrada de audio estéreo (RCA), su
tamaño es de: 95 x 24 x 16 mm, originalmente compatible con Windows XP, vista 7
con arquitectura de x86/x64.
Filmadora
El dispositivo utilizado para captar video es una filmadora handycam de marca sony
perteneciente a la serie dcr-sr33 que entre sus principales características tiene: grabar
video, imágenes y audio con mayor intensidad, la filmadora posee un disco de
almacenamiento interno de 40 gigas, que permite guardar más de una hora de video.
Además de éste almacenamiento la filmadora es compatible con memorias de
almacenamiento externo como son las stick duo.
Esta filmadora posee una pantalla táctil en la cual se puede configurar ciertas
características propicias para cada ambiente, permite grabar en lugares oscuros, posee
un zoom de 40x, resolución de video efectiva de la cámara de 480 pixeles, los videos
que se tenga en el disco interno pueden ser editados, eliminados y hasta dividir
películas.
4.4.2. CONFIGURACIÓN DEL MÓDULO V4L2 PARA TARJETA
CAPTURADORA DE VIDEO
V4L2 es la abreviatura que se le da a Video4Linux, es un driver que los administradores
en Linux o computación cargan manualmente a los módulos del kernel de una
- 99 -
distribución de Linux, cuando el montaje de los dispositivos de video por alguna razón
no fue detectada con éxito, ya que el funcionamiento de dicho driver se basa en conectar
en el módulo del kernel una nueva dirección conocida como: "videodev", el mismo que
proporciona funciones auxiliares y una interfaz de aplicación para los dispositivos de
video externos que se conecten.
El dispositivo de video virtual v4l2loopback, es un driver para video4linux que permite
hacer tuberías con señales de video. Este driver es usado como entrada para el programa
que normalmente se comunica con el dispositivo de video4linux y la salida es usada con
otros programas como por ejemplo: WebcamStudio o Mplayer, tomado de Blog
Caballero [21].
Los dispositivos pueden soportar varias funciones relacionadas, por ejemplo la captura
de video, superposición de video y la captura VBI, todas estas de una o de otra manera
se encuentran relacionadas, ya que estas comparten varias funciones entre ellas la
misma entrada de video y el sintonizador de frecuencia.
En la distribución seleccionada y ya instalada Ubuntu, se va a realizar la instalación del
módulo v4l2loopback por medio de una serie de pasos descritos a continuación:
Antes de empezar la instalación se debe proceder a la actualización del sistema
operativo mediante el comando:
# sudo apt-get update
Se procede a la instalación de las cabeceras del kernel de la distribución Ubuntu
12.10 y código fuente del módulo v4l2loopback con los siguientes comandos:
- 100 -
# sudo apt-get install linux-headers-3.12.0-031200-generic
module-assistant
# sudo apt-get install v4l2loopback-source
Seguidamente debe prepararse el módulo v4l2loopback, para lo cual se hace uso
del module-assistant, este va ayudar a la compilación e instalación del módulo
v4l2loopback mediante la ejecución de los siguientes comandos:
# sudo m-a prepare
# sudo m-a update
# sudo m-a a-i v4l2loopback-source
Una vez acabado el proceso de instalación ya se cuenta con el módulo
v4l2loopback en su distribución de Linux, sólo queda cargar dicho módulo al
kernel (núcleo del sistema operativo), para ello se digita el siguiente comando:
# sudo modprobe v4l2loopback
Se puede verificar si el módulo fue cargado correctamente con el siguiente
comando:
# lsmod | grep v4l2loopback
Existe un comando usado para verificar si durante el proceso de carga no ha
habido errores, dicho comando funciona de manera opcional y es el siguiente:
# dmesg | grep v4l2loopback
Se puede verificar si el modulo del dispositivo de video fue instalado y creado
correctamente en el directorio /dev diguitando lo siguiente:
# ls /dev/video*
- 101 -
Por último se debe configurar que el módulo para el dispositivo de video se
cargue automáticamente cuando se prenda y arranque el sistema operativo
Ubuntu, para lo cual se ejecuta el siguiente comando:
# echo "v4l2loopback" >> /etc/modules
Como el fichero donde se quiere editar no posee los permisos necesarios de
súper usuario saldrá un error, para corregir eso, se debe ejecutar previamente el
siguiente comando:
# sudo chmod 777 /etc/modules
Finalmente se debe reiniciar el equipo para que cargue por defecto el módulo
instalado al sistema operativo mediante la ejecución del siguiente comando:
# sudo reboot
4.5. HERRAMIENTAS UTILIZADAS PARA GENERAR CONGESTIÓN
Se debe tener en cuenta que las redes nunca van a estar libres de congestión, ya que los
enlaces de red en cualquier organización, son destinados para el paso de información de
diferente tipo.
Para el presente estudio se llevará a cabo la evaluación de los CODEC's considerando la
congestión del enlace, entre ellos se tendrá el enlace sin congestión, el cual se basa en
usar toda la capacidad del canal solo para el paso de un tipo de datos, en este caso para
transmisiones de video.
Otras consideraciones de los enlaces son la congestión moderada y fuerte, las cuales
consisten en dedicar la capacidad del canal para trasmitir información de diferente tipo,
sobrecargando el enlace, en este caso se usará para transmitir datos de video y archivos
de tipo TCP con diferente número de paquetes y tiempo.
- 102 -
Para la generación de paquetes se utiliza el software Ostinato por su facilidad de uso,
libre distribución, velocidad y eficiencia, ya que tiene la capacidad de crear tráfico en la
red desde el cliente al servidor tal y como se presenta en la Figura IV. 5.
FIGURA IV. 5 Pantalla de configuración de Ostinato
Fuente: Elaboración propia de los autores
Ostinato es un software de distribución libre no licenciada con las siguientes
características:
Compatible tanto para Windows como para Linux.
Permite la creación de paquetes (TCP, UDP, ICMP (Protocolo de Mensajes de
Control de Internet.), IGMP, MLD) para congestionar la red.
Permite configurar el paso de paquetes en distinto tipo de redes como son: IPv4,
IPv6, IPv4 over IPv6, ARP, IPv6 over IPv4.
Para la congestión moderada se va a llevar a cabo la trasmisión de 50000 paquetes, con
una longitud de la trama de 1024, los cuales se irán enviando en un tiempo de 10
paquetes por segundo, tal como se presenta la Figura IV. 6.
- 103 -
FIGURA IV. 6 Configuración de Ostinato para una congestión moderada
Fuente: Elaboración propia de los autores
Para producir una congestión fuerte se procede a generar 100000 paquetes con una
longitud de la trama de 1024, los cuales se van a ir generando en un tiempo de 20
paquetes por segundo, tal como se visualiza en la Figura IV. 7.
FIGURA IV. 7 Configuración de Ostinato para una congestión fuerte
Fuente: Elaboración propia de los autores
- 104 -
4.6. CONFIGURACIÓN DE LOS CODEC's EN EL SERVIDOR PARA
GENERAR EMISIÓN
a) CONFIGURACIÓN DEL CODEC H.264 PARA STREAMING DE
VIDEO SOBRE DEMANDA Y EN VIVO.
Configuración sobre demanda
Mediante la utilización del software VLC, instalado en el servidor de streaming,
se procede a la emisión de videos sobre demanda, con la codificación H.264
para lo cual se realiza el siguiente proceso:
En el software VLC, en la barra de menús, se pulsa en la pestaña Medio,
y se selecciona la opción Emitir.
Con esta opción se obtiene una ventana titulada “Abrir Medio”, en la
cual se tiene 4 opciones que son: Archivo, Disco, Red, Dispositivo de
Captura; de estas opciones se selecciona la opción Archivo, en ésta se
pulsa el botón añadir, para agregar el video que se desea transmitir en la
red en este caso con extensión .MP4, ubicado en el disco local o
cualquier otro dispositivo de almacenamiento, tal como se muestra en la
Figura IV. 8, luego se pulsa el botón emitir.
- 105 -
FIGURA IV. 8 Abrir medio para CODEC H.264
Fuente: Elaboración propia de los autores
En la siguiente ventana se procede a configurar el destino y las opciones
de transcodificación del video, para el destino se elige el protocolo:
RTP/MPEG Transport Stream y se pulsa en el botón Añadir, dicha
acción despliega una ventana, donde se digita la dirección del grupo de
Multicast ff7e:240:2001:2:2:2:0:1, y el puerto 5001. En la opción de
transcodificación se escoge el perfil del CODEC a evaluar, y se pulsa en
siguiente, tal como se presenta en la Figura IV. 9.
FIGURA IV. 9 Configuración de destino sobre demanda para CODEC H.264
Fuente: Elaboración propia de los autores
- 106 -
Finalmente en la pestaña de configuración de preferencias, se habilita la
opción emitir todas las emisiones elementales y el Tiempo de Vida
(TTL) que será configurado en su máximo valor 255, luego se da clic en
emitir, tal como se visualiza en la Figura IV. 10.
FIGURA IV. 10 Configuración de preferencias difusión sobre demanda
Fuente: Elaboración propia de los autores
Configuración en vivo
Mediante la utilización del software VLC, instalado en el servidor de streaming,
se procede a la emisión de videos en vivo, con la codificación H.264 para lo cual
se realiza el siguiente proceso:
En el software VLC, en la barra de menús, se pulsa en la pestaña Medio,
y se selecciona la opción Emitir.
Con esta opción se obtiene una ventana titulada “Abrir Medio”, en la
cual se tiene 4 opciones que son: Archivo, Disco, Red, Dispositivo de
Captura; de estas opciones se selecciona la opción Dispositivo de
Captura, en esta pantalla se escoge el modo de captura Video for Linux
2, en la selección de dispositivo se elige el nombre del dispositivo de
- 107 -
video de la tarjeta capturadora que el sistema operativo detecte por lo
general /dev/video1, seguidamente se escoge el nombre del dispositivo
de audio hw:0,0, luego de esto se selecciona y se da clic en Emitir, tal
como se presenta en la Figura IV. 11.
FIGURA IV. 11 Configuración de dispositivo de captura
Fuente: Elaboración propia de los autores
En la siguiente ventana se procede a configurar el destino y las opciones
de transcodificación del video, tal como se lo describió en la difusión
sobre demanda Figura IV. 9.
Finalmente en la pestaña de configuración de preferencias, se habilita la
opción emitir todas las emisiones elementales y el Tiempo de Vida que
será configurado en su máximo valor 255. luego se da clic en emitir, tal
como se presenta en la Figura IV. 10.
- 108 -
b) CONFIGURACIÓN DEL CODEC XVID PARA STREAMING DE
VIDEO SOBRE DEMANDA Y EN VIVO.
Configuración sobre demanda
Para la emisión de videos sobre demanda mediante la codificación de Xvid, se
realiza pasos similares a los hechos en el CODEC H.264, las principales
diferencias se detallan a continuación.
Cuando se selecciona la opción Archivo, se procede a agregar el video
con extensión .AVI que se desea transmitir en la red, ubicado en el disco
local o cualquier otro dispositivo de almacenamiento, para lo cual se
pulsa el botón añadir, tal como se muestra en la Figura IV. 12, luego se
pulsa el botón Emitir.
FIGURA IV. 12 Abrir medio para CODEC Xvid
Fuente: Elaboración propia de los autores
1. En la siguiente ventana se procede a configurar el destino y las opciones
de transcodificación del video, para el destino se elige el protocolo:
RTP/MPEG Transport Stream y se pulsa en el botón Añadir, dicha
acción despliega una ventana, donde se digita la dirección del grupo de
- 109 -
Multicast ff7e:240:2001:2:2:2:0:1, y el puerto 5001. En la opción de
transcodificación se escoge el perfil del CODEC a evaluar (Xvid), y se
pulsa en siguiente, tal como se presenta en la Figura IV. 13.
FIGURA IV. 13 Configuración de destino sobre demanda para CODEC Xvid
Fuente: Elaboración propia de los autores
Configuración en vivo
Para la difusión de video en vivo mediante la utilización de la codificación Xvid
se procede a realizar pasos similares a los del CODEC H.264 en vivo, con la
única diferencia que en la elección de perfiles se selecciona el correspondiente a
la transcodificación del CODEC a evaluar (Xvid) tal como se representa en la
Figura IV. 13.
- 110 -
c) CONFIGURACIÓN DEL CODEC THEORA PARA STREAMING
DE VIDEO SOBRE DEMANDA Y EN VIVO.
Configuración sobre demanda
Los pasos a seguir para la emisión de videos sobre demanda mediante la
codificación de Theora son similares a los hechos en el CODEC H.264, las
principales diferencias se detallan a continuación.
Cuando se selecciona la opción Archivo, se procede a agregar el video
que se desea transmitir en la red, ubicado en el disco local o cualquier
otro dispositivo de almacenamiento donde se encuentra el video con la
extensión .OGG, para lo cual se pulsa el botón añadir, tal como se
muestra en la Figura IV. 14, luego se pulsa el botón emitir.
FIGURA IV. 14 Abrir medio para CODEC Theora
Fuente: Elaboración propia de los autores
En la siguiente ventana se procede a configurar el destino y las opciones
de transcodificación del video, para el destino se elige el protocolo:
RTP/MPEG Transport Stream y se pulsa en el botón Añadir, dicha
acción despliega una ventana, donde se digita la dirección del grupo de
Multicast ff7e:240:2001:2:2:2:0:1, y el puerto 5001. En la opción de
- 111 -
transcodificación se escoge el perfil del CODEC a evaluar (Theora), y se
pulsa en siguiente, tal como se presenta en la Figura IV. 15.
FIGURA IV. 15 Configuración de destino sobre demanda para CODEC Theora
Fuente: Elaboración propia de los autores
Configuración en vivo
Para la difusión de video en vivo mediante la utilización de la codificación
Theora se procede a realizar pasos similares a los del CODEC H.264 y CODEC
Xvid en vivo, con la única diferencia que en la elección de perfiles se selecciona
el correspondiente a la transcodificación del CODEC a evaluar (Theora), tal
como se visualiza en la Figura IV. 15.
4.7. CONFIGURACIÓN DEL CLIENTE PARA RECIBIR EMISIÓN
El cliente de un grupo de multidifusión necesita recibir las transmisiones multimedia,
para ello se accede al software VLC, donde se selecciona la pestaña Medio de la barra
de menú y se da clic en Abrir volcado de red, en esta ventana se procede a escribir la
dirección del grupo de Multicast del cual se desea recibir el video, dando a conocer el
- 112 -
protocolo y el puerto específico para recibir la transmisión, tal como se presenta en la
Figura IV. 16.
FIGURA IV. 16 Abrir volcado de red en un cliente de multidifusión
Fuente: Elaboración propia de los autores
CAPÍTULO V
5. ANÁLISIS DE RESULTADOS Y COMPROBACIÓN DE LA HIPÓTESIS
La parte fundamental en el desarrollo de un proyecto de tesis es el poder llegar a la
etapa de análisis de resultados, la cual consiste básicamente en entrelazar los datos y
resultados que se encontraron en la investigación con la información de la base teórica,
para poder interpretar la información obtenida y al final emitir conclusiones
importantes.
El presente capitulo tiene como propósito detallar el número de pruebas a realizar, las
principales características de los indicadores utilizados para la comprobación de la
hipótesis, además de detallar y analizar los datos obtenidos en cada uno de los
escenarios mediante tablas y cuadros estadísticos, con la finalidad de establecer
diferencias y poder identificar el mejor CODEC de video y así poder emitir
conclusiones y recomendaciones.
- 114 -
5.1. DETERMINACIÓN DE ESCENARIOS Y NÚMERO DE PRUEBAS
Para determinar el número de escenarios se utilizó el diagrama de árbol, el cual es una
gráfica en forma de árbol, en donde sus ramas vienen a representar todos los posibles
experimentos y resultados que se pueden obtener de una comprobación y
experimentación aleatoria.
En esta investigación se tiene en cuenta el tipo de streaming, el tipo de congestión y los
CODEC's de video a comparar, por tal motivo a continuación se representa la FIGURA
V. 1, el diagrama de árbol resultante, mediante el cual se logró establecer un total de 18
escenarios, los cuales llevó a cabo para poder determinar el mejor CODEC en las
distintas transmisiones.
FIGURA V. 1 Diagrama de Árbol
Fuente: Elaboración propia de los autores
Una vez determinado el número de escenarios, es imprescindible determinar el número
de pruebas a realizar para cada uno de estos, por tal motivo se toma en cuenta las
recomendaciones por parte de la IETF (Grupo de Trabajo de Ingeniería de Internet),
documentos de la ITU-T (Unión Internacional de Telecomunicaciones) relacionados
con Quality of Service and Network Performance que van desde la sección Y.1500
- 115 -
hasta la sección Y.1599, y distintos RFC como: RFC 2544 Benchmarking Methodology
for Network Interconnect Devices [22] y RFC 1242 Benchmarking Terminology for
Network Interconnection Devices [23], ya que en estos documentos se da a conocer la
manera de evaluación para cada uno de los parámetros de medición del rendimiento,
recomendando claramente que las pruebas durarán entre 60 y 120 segundos y, se
repetirán entre 10 a 20 veces, de acuerdo a la complejidad de la infraestructura y la
rigurosidad del análisis.
Para la ejecución de las pruebas en esta investigación se utilizó un tiempo de 80
segundos en las transmisiones de video en vivo y sobre demanda con repeticiones de 20
veces para cada escenario.
En la transmisión en vivo se debe considerar la falta de presencia de un tope de
transmisión o tiempo límite, ya que mientras la cámara este prendida y capturando video
se puede seguir realizando pruebas.
Para una transmisión sobre demanda, sí se cuenta con un tiempo máximo de duración,
debido a que se transmite videos pregrabados en discos duros que poseen un tiempo
inicial y final, para el presente estudio se usó un video con una duración de 5 minutos
11 segundos titulado “Casualidad”.
La duración del tiempo para videos sobre demanda se lo elije debido a datos estadísticos
obtenidos por parte del INEC (Instituto Nacional de Estadísticas y Censos) en encuestas
tituladas: “Uso del tiempo”, las mismas que indican, que una persona en Ecuador de
edad media, dedica su tiempo de entre mínimo 3 minutos hasta un tiempo promedio de
1 hora 30 minutos a mirar televisión o videos en internet.
- 116 -
5.2. PARÁMETROS PARA ANALIZAR EL RENDIMIENTO EN REDES
La recomendación E.800 (Terms and Definition Related to Quality of Service) de la
ITU (Unión Internacional de Telecomunicaciones), define al rendimiento de una red
como: “La habilidad de una red o una porción de la misma para proveer funciones
relativas a comunicaciones entre usuarios”, por tal razón para el presente trabajo se
considera que el rendimiento de la red es la capacidad y la velocidad que se posee para
transferir datos de un extremo de la red al otro.
A continuación se da a conocer las características de los indicadores usados para la
medición del rendimiento en una red como son: latencia, jitter, ancho de banda y
pérdida de paquetes.
Cabe mencionar que dichos indicadores coinciden con los de la metodología
recomendada por el RFC 2544 Benchmarking Methodology for Network Interconnect
Devices [22] y que además la eficiencia que debe presentar el tráfico de video en la red
también involucra estos valores.
5.2.1. PÉRDIDA DE PAQUETES
Se debe considerar que la pérdida de paquetes en una red se produce por diferentes
motivos entre ellos: porque los paquetes se demoraron en llegar a su destino y se los
descarta en el camino, por sobrepasar el tiempo de vida útil o por falta de memoria en el
buffer, se tiene un ancho de banda demasiado limitado para cierto tipo de información o
simplemente el canal de comunicaciones está demasiado saturado con mucho tráfico en
la red.
- 117 -
Como ya se mencionó el presente estudio va hacer uso de paquetes UDP ya que estos
no están orientados a la conexión y facilitan en gran medida las transmisiones de video
en la red.
5.2.2. LATENCIA
La latencia o retardo según el RFC 2544 Benchmarking Methodology for Network
Interconnect Devices [22] sección 3.8, es el intervalo de tiempo que comienza cuando el
final del primer bit de la trama entrante alcanza el puerto de entrada y termina cuando el
comienzo del primer bit de la misma trama es visto en el puerto de salida.
En una definición más concreta y clara se menciona entonces que la latencia, es el
tiempo en que una trama o paquete de datos, tarda en hacer su recorrido desde la
estación que está emitiendo el video hasta la estación que la recibe.
Es importante determinar con exactitud la cantidad de latencia que existe en la ruta entre
el origen y el destino para las LAN y las WAN (Red de Área Amplia), ya que además
del retraso físico en la transmisión se le añade el retraso en el empaquetado IP de las
muestras, retraso de los propios equipos de encaminamiento (routers, switch, etc.) y
sobre todo retardo que se genera con la utilización de los CODEC.
La latencia es uno de los factores claves para tener en cuenta en una trasmisión de
video, ya que este factor implica mucho en la satisfacción con el usuario, por ejemplo:
en una emisión de fútbol en vivo el usuario no va a tolerar que la imagen llegue mucho
después de lo que el sonido ya le predijo.
- 118 -
5.2.3. JITTER
El Jitter también conocido como efecto de fluctuación en la red, es la variación que se
produce en el tiempo desde que se generan los paquetes en el emisor, hasta que se
reciben dichos paquetes en el receptor.
El proceso que el jitter realiza es complejo, ya que al momento de que los usuarios
reciban los paquetes, internamente se está forzando al decodificador a recoger los
paquetes, juntarlos, empaquetarlos y entregarlos al usuario final, debido a ello este
proceso puede causar problemas en la latencia.
Las comunicaciones que se realizan en tiempo real como video conferencias o video
clases sienten aún más el efecto que genera el jitter. La manera de solucionar dicho
inconveniente es reservando un espacio del ancho de banda que el enlace posea o
incorporando enlaces con mayor velocidad (100 Mb (Megabit) Ethernet, E3/T3, SDH
(Jerarquía Digital Síncrona)).
5.2.4. ANCHO DE BANDA
El ancho de banda puede ser clasificado como una relación entre costo y calidad, donde
sí se invierte más dinero se consigue añadir más ancho de banda a los enlaces y por
ende se tiene más capacidad y rapidez para el envío y recepción de la información.
El ancho de banda no es más que la cantidad de datos que se manda en un enlace de la
red informática durante un tiempo determinado, por tal motivo este indicador se mide en
mega bits, kilo bits o en Bps (bits por segundo).
- 119 -
La codificación y compresión de los datos se encuentra directamente ligada con el
ancho de banda, puesto que a mayor compresión de los datos menos consume la
capacidad del enlace.
5.3. HERRAMIENTAS UTILIZADAS PARA MEDIR EL RENDIMIENTO
Es común que investigadores y/o administradores de red necesiten medir distintos
indicadores de red, para lo cual existen varias herramientas disponibles que cumplen
con dicho propósito, pero no todas las herramientas poseen las mismas características o
evalúan los mismos parámetros de rendimiento.
Para llevar a cabo la medición del rendimiento que presentan los CODEC's en cada uno
de los escenarios, se han seleccionado algunas herramientas por su eficiencia, gratuidad
y popularidad, como son los software: Iperf, Jperf y Wireshark.
Iperf: dicha herramienta es de código libre, software no licenciado, funciona
mediante la ejecución de comandos a través de consolas, entre sus características
permite medir las fluctuaciones en la red, ancho de banda, perdida de paquetes y
crear flujos de datos UDP con diferentes tamaños de tramas Ethernet tal como lo
describe el RFC 2544 Benchmarking Methodology for Network Interconnect
Devices [22].
Jperf: es la herramienta en modo gráfico que le complementa a la herramienta de
software libre Iperf, dicho programa funciona bajo el lenguaje de programación
Java.
Wireshark: es la herramienta más sofisticada para analizar y capturar paquetes,
cabeceras, tráfico en la red, permite verificar el funcionamiento de protocolos y
- 120 -
hasta descubrir claves personales cuando se realiza conexiones a internet mediante
una red inalámbrica.
Comandos para monitorear una red: Además de hacer uso de los software ya
descritos, se hará uso de comandos básicos utilizados para verificar la conexión de
una máquina con otra en una red, tanto con el protocolo IPv6 e IPv4 como son: el
ping, ping6, route y traceroute, dichos comandos serán útiles para la medición de la
latencia.
5.4. VALORES REFERENCIALES PARA ANÁLISIS DE INDICADORES DEL
RENDIMIENTO
5.4.1. PÉRDIDA DE PAQUETES
Rango de evaluación:
La pérdida de paquetes máxima admitida para que no se degrade la comunicación deber
ser inferior al 1%. Pero es bastante dependiente del códec que se utiliza.
Cuanto mayor sea la compresión del CODEC más pernicioso es el efecto de la pérdida
de paquetes.
Si la perdida de paquetes sobrepasa el 2% provoca que el video sea de tan mala calidad
que los usuarios prefieren no verlo, aunque el audio puede sonar algo aceptable la
imagen no llega por eso definitivamente la pérdida de paquetes por arriba del 2 % es
totalmente inaceptable en un video de calidad empresarial.
- 121 -
Modo de evaluación:
Para poder obtener el porcentaje de los paquetes perdidos en cada una de las
transmisiones de video en vivo y sobre demanda se va a ejecutar la herramienta
Jperf/Iperf por un tiempo de 80 segundos en 20 repeticiones sucesivas por cada uno de
los escenarios descritos en la Figura V. I tal como se presenta en el Anexo 2, ya que
esta herramienta permite obtener el número de datagramas enviadas, datagramas
transferidas y el ancho de banda consumido.
5.4.2. LATENCIA
Rango de evaluación:
Debido a lo citado se puede recalcar que la latencia influye en las comunicaciones, por
tal motivo se describe a continuación ciertos valores de referencia obtenidos del
documento ITU-T G.114 [24], en el cual se detalla los valores que debe poseer la
latencia en una transmisión, dichos valores serán usados para llevar a cabo la evaluación
en el presente trabajo.
Los rangos de valores de la latencia son aceptables si se mantuvieran por debajo de los
150 ms (Milisegundos) ya que no afectaría de modo significativo a la mayoría de las
aplicaciones. Pero si los retardos superan los 400 ms afecta gravemente a tareas
interactivas.
Forma de evaluación:
Para la medición y captura de datos de la latencia se utiliza el comando ping, ya que
permite verificar la conexión y el tiempo de conexión que tiene una máquina con otra en
la red, por tal motivo se va a generar por cada uno de los escenarios descritos en la
- 122 -
Figura V. I repeticiones de 80 pines sucesivos con una longitud de la trama de 2798
bytes que resulta ser la sumatoria de los valores recomendables más significativos de
una trama Ethernet según el RFC 2544 Benchmarking Methodology for Network
Interconnect Devices [22], durante la emisión de video en vivo y sobre demanda, los
valores de cada escenario se detallan en el Anexo 2.
Para mejor comprensión de lo mencionado, a continuación en la Figura V. 2 se puede
visualizar la ejecución del comando desde la máquina cliente hacia la fuente emisora en
uno de los escenarios antes planteados.
FIGURA V. 2 Visualización del comando para comprobar la latencia
Fuente: Elaboración propia de los autores
5.4.3. JITTER
Rango de evaluación:
Los valores recomendados para el jitter entre el punto inicial y final de una
comunicación de video debería ser menor que 50 ms para ser considerada como
aceptable, esto según la recomendación descrita en el ITU-T Y.1541 [25].
- 123 -
Modo de evaluación:
Para llevar a cabo la medición y captura de datos del indicador jitter se utiliza la
herramienta Jperf/Iperf, la cual se va a configurar como servidor y cliente.
Configuración Jperf/ Iperf como servidor
Como el servidor de streaming está configurado en la distribución de Ubuntu,
Iperf también debe estar configurado allí, es por eso que se procede a la
instalación por medio de paquetes y comandos para finalmente ingresar al
programa seleccionando cualquiera de las siguientes opciones:
La primera es mediante la ejecución del comando ./jperf.sh por medio de
la consola, cabe recalcar que para ejecutar dicho comando se debe ubicar
bajo el directorio que lo contenga, tal como se presenta en la Figura V. 3
a continuación:
FIGURA V. 3 Ingreso a Jperf/Iperf por medio de comando
Fuente: Elaboración propia de los autores
Otra manera de ingresar al programa Iperf en Ubuntu es gráficamente
para lo cual se ingresa a la carpeta que contenga el archivo
correspondiente a Iperf, para darle doble clic y pulsar en ejecutar, tal
como se presenta en la Figura V. 4 a continuación:
FIGURA V. 4 Ingreso a Jperf/Iperf en modo gráfico
Fuente: Elaboración propia de los autores
- 124 -
Una vez ubicado en el programa se selecciona la opción “server” para
configurarlo como servidor, el servidor va a escuchar los paquetes de tipo UDP
por el puerto 5001 ya que por ese puerto y con ese tipo de información UDP se
va a realizar las comunicaciones, para mejor comprensión se presenta la Figura
V. 5 a continuación.
FIGURA V. 5 Jperf/Iperf en modo servidor
Fuente: Elaboración propia de los autores
Configuración Jperf/ Iperf como cliente:
Para la ejecución del programa Jperf en la máquina cliente con sistema operativo
Windows se debe ingresar dando doble clic en el archivo Jperf.jar, una vez
ingresado al programa se selecciona la opción “Client”, se da a conocer la
dirección con la cual se va a llevar a cabo la comunicación y el análisis, es decir
la dirección del servidor streaming, seguidamente se da a conocer el puerto 5001
- 125 -
por el cual se va a emitir la información, finalmente se configura el tamaño del
paquete y el tiempo que va a tener esta prueba. Para la configuración del tamaño
de paquetes UDP se da a conocer que los enlaces tienen una capacidad de ancho
de banda de 1, 875 MB (Mega Bytes), un tamaño de buffer y tamaño de trama
otorgados automáticamente al momento de activar la opción “tipo de tráfico”
IPv6. Durante la transmisión del video en vivo o sobre demanda se envió tráfico
desde el cliente al servidor durante 80 segundos con intervalos de tiempo de un
segundo tal como se visualiza en la Figura V. 6 expuesta a continuación:
FIGURA V. 6 Jperf/Iperf en modo cliente
Fuente: Elaboración propia de los autores
Una vez detallado el proceso de configuración de Jperf/Iperf como cliente y como
servidor, se menciona entonces que dicho proceso de emisión y escucha de la
herramienta se va a ejecutar 20 veces durante la emisión del video en vivo y sobre
demanda para cada uno de los escenarios descritos en la Figura V. I con una duración
de envío de 80 segundos, dichos datos obtenidos por cada escenario se detalla en el
Anexo 2.
- 126 -
5.4.4. ANCHO DE BANDA
Rango de evaluación:
Como ya se mencionó en el capítulo IV sección 4.1.3, titulado Diseño y
Funcionamiento del Escenario de Pruebas, los requisitos de ancho de banda de video
van a variar desde los 56 Kbps hasta los 15 Mbps, estos requisitos de ancho de banda
son altamente superior a los requisitos de audio que varían desde 8 Kbps hasta 128
Kbps, aunque en un sistema de streaming multimedia o en una video llamada se da
mayor prioridad al audio, ya que la pérdida de audio es más irritante para la salud
humana que la de video.
Modo de evaluación:
Para poder obtener el consumo del ancho de banda se va a ejecutar la herramienta
Jperf/Iperf por un tiempo de 80 segundos, durante las transmisiones de video en vivo y
sobre demanda, la ejecución de esta herramienta se la va a realizar 20 veces por cada
uno de los escenarios descritos en la Figura V. I, ya que esta herramienta permite
obtener el número de datagramas enviadas, datagramas transferidas y el ancho de banda
consumido, dichos datos obtenidos por cada uno de los escenarios se detalla en el
Anexo 2.
Una vez detalla la manera de evaluación y el rango de cada uno de los parámetros que
se consideran para analizar el rendimiento, a continuación en la Tabla V. 1 se describen
los valores aceptables e inaceptables de cada uno de estos parámetros, además de
mencionar la herramienta necesaria para llevar a cabo la captura y medición de cada
indicador.
- 127 -
TABLA V. 1 Valoración cuantitativa en la medición del rendimiento
Parámetros de
medición
Valoración Herramienta
para hacer
mediciones
Aceptable Inaceptable
Latencia < 150 ms > 400 ms Ping
Jitter < 50 ms > 50 ms Jperf/Iperf
Ancho de Banda 56 Kbps - 15
Mbps
> 15 Mbps Jperf/Iperf
Pérdida de Paquetes < 1% > 2 % Jperf/Iperf
Fuente: Elaboración propia de los autores
5.5. PROCESAMIENTO DE RESULTADOS
La captura y procesamiento de información junto con los beneficios que representa la
era tecnológica, permiten el manejo de datos mucho más reales y específicos, por tal
motivo en esta sección se va a detallar los resultados que se lograron obtener de cada
uno de los indicadores: latencia, Jitter, ancho de banda y pérdida de paquetes,
involucrados en la medición del rendimiento, en cada uno de los escenarios, mediante la
utilización de las herramientas Jperf/Iperf y comandos básicos como Ping.
5.5.1. CAPTURA Y MEDICIÓN DE DATOS DEL CODEC H.264
En el Anexo 2 sección I se presentan todos los datos e imágenes obtenidas de las
mediciones realizadas sobre cada uno de los escenarios descritos en la Figura V. 1 de
color verde, los cuales fueron creados para evaluar el codificador H.264. Para la
evaluación de éste codificador se llevó a cabo la creación de un perfil en el software
para generar streaming donde se utilizó el CODEC de audio MP3 junto con el CODEC
de video H.264 y todo esto se transmitió mediante el contenedor MP4.
- 128 -
A continuación en la Tabla V. 2 se presenta el promedio de los datos de cada escenario
útiles para llevar a cabo el análisis del comportamiento de éste CODEC en la red.
TABLA V. 2 Comportamiento del CODEC H.264 en los distintos escenarios
Reporte
del
Servidor
(%)
Reporte
Total
(%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
Escenario 1 0,03 0,00017 131,75 12,4605 1,4203 3 3,8 15,5
Escenario 2 0,599 0,00156 111,065 11,3254 1,4975 3 3,7 15
Escenario 3 0,4465 0,01059 96,825 10,1215 1,308 3 4,3 14,5
Escenario 4 0,196 0,00017 133,6 13,91 1,47695 3 3,05 10,5
Escenario 5 0,0396 0,00399 96,58 10,1105 1,5694 3,05 3,4 10,3
Escenario 6 0,0285 0,00017 129,6 13,605 1,45635 3 3 9,25
Sumatoria 1,3396 0,01666 699,42 71,5329 8,7285 18,05 21,25 74,9
Promedio 0,22327 0,0028 116,57 11,92215 1,45475 3,008 3,54 12,5
Número de
Pruebas
Paquetes Perdidos Ancho de Banda
Jitter
(ms)
Latencia
Fuente: Elaboración propia de los autores
5.5.2. CAPTURA Y MEDICIÓN DE DATOS DEL CODEC XVID
En el Anexo 2 sección II se detallan todos los resultados e imágenes obtenidas de las
mediciones realizadas sobre cada uno de los escenarios que fueron planteados en la
Figura V. I de color rojo, los mismos fueron creados para comprobar la funcionalidad
del CODEC de video Xvid, cabe mencionar que para dichas comprobaciones fue
necesario la creación de un perfil que maneje el CODEC Xvid (MPEG 4 parte dos) para
el manejo de video y la utilización del CODEC MP3 para manejo de audio junto con el
contenedor AVI.
- 129 -
A continuación en la Tabla V. 3 se presenta el promedio de los datos de cada escenario
útiles para llevar a cabo el análisis del comportamiento de éste CODEC en la red.
TABLA V. 3 Comportamiento del CODEC Xvid en los distintos escenarios
Reporte
del
Servidor
(%)
Reporte
Total
(%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
Escenario 1 0,041 0,00017 129,15 13,365 1,4281 3 3,2 15,2
Escenario 2 0,509 0,00245 129,6 13,535 1,47195 3 3,4 13,9
Escenario 3 0,396 0,00174 83,025 8,6805 1,3747 3 3,35 15,6
Escenario 4 0,1065 0,00357 130,45 13,68 1,4472 3 3,05 6,9
Escenario 5 0,06625 0,04739 85,955 9,0215 1,606 3 3 12,8
Escenario 6 0,182 0,00018 130,9 13,74 1,4844 2,95 3 11,8
Sumatoria 1,30075 0,0555 689,08 72,022 8,81235 17,95 19 76,1
Promedio 0,21679 0,0092 114,8466667 12,003667 1,46873 2,992 3,17 12,7
Número de
Pruebas
Paquetes Perdidos Ancho de Banda
Jitter
(ms)
Latencia
Fuente: Elaboración propia de los autores
5.5.3. CAPTURA Y MEDICIÓN DE DATOS DEL CODEC THEORA
En el Anexo 2 sección III se presentan los datos e imágenes obtenidas de las
mediciones realizadas sobre cada uno de los escenarios que se utilizaron para
comprobar la eficacia del CODEC de video Theora en la red tal como se describió en la
Figura V. 1 de color celeste.
Cabe recalcar que junto con la utilización del CODEC de video Theora, se utilizó el
CODEC de audio Vorbis y el contenedor de datos OGG para realizar dichas
transmisión.
- 130 -
A continuación en la Tabla V. 4 se presenta el promedio de los datos de cada escenario
útiles para llevar a cabo el análisis del comportamiento de éste CODEC en la red.
TABLA V. 4 Comportamiento del CODEC Theora en los distintos escenarios
Reporte
del
Servidor
(%)
Reporte
Total
(%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
Escenario 1 0 0,00866 138,9 14,685 1,4357 3 3,05 12,7
Escenario 2 0,01229 0,01416 146 14,6785 1,41245 3 3,15 17,4
Escenario 3 0,05439 0,00017 146,9 15,415 1,4394 3 3,1 11,1
Escenario 4 0,0197 0,01935 116,05 12,175 1,6697 3 3,9 17,9
Escenario 5 0,10796 0,00803 134 14,05 1,4974 3 3,45 15,5
Escenario 6 0,01753 0,01397 136,2 14,07 1,48925 3,05 4,35 20,2
Sumatoria 0,21186 0,06434 818,05 85,0735 8,9439 18,05 21 94,8
Promedio 0,03531 0,0107 136,3416667 14,178917 1,49065 3,008 3,5 15,8
Número de
Pruebas
Paquetes Perdidos Ancho de Banda
Jitter
(ms)
Latencia
Fuente: Elaboración propia de los autores
5.6. COMPROBACIÓN DE LA HIPÓTESIS
5.6.1. TIPO DE INVESTIGACIÓN
Para el presente estudio se utilizó la investigación experimental puesto que esta permite
la realización de un conjunto de experimentos en un laboratorio o localidad adecuada
que consten con la implementación e instrumentación necesarias para llevar a cabo la
comprobación de las teorías planteadas e investigadas, donde el investigador manipule
las variables, mida efectos de las variables y valide la situación experimental.
- 131 -
5.6.2. MÉTODOS Y TÉCNICAS DE INVESTIGACIÓN
Los métodos y técnicas utilizados para llevar a cabo la comprobación de la hipótesis
son: la observación, documentación y el método científico experimental basado en
valores referenciales o mejor conocidos como umbrales.
La observación: puesto que al realizar varios experimentos se va a tener que observar el
comportamiento de cada uno de los CODEC's al someterlos a los distintos escenarios
para corroborar los resultados y las mediciones que se obtienen en cada prueba.
La documentación: para poder llevar a cabo la implementación de cada escenario se
debe investigar y revisar documentación acerca del funcionamiento del nuevo protocolo
de internet versión seis y la nueva tecnología de tráfico Multicast, sin olvidar que la
documentación es sumamente importante en el desarrollo del trabajo científico porque
permite la revisión del marco teórico para los respectivos objetos de estudio.
El método científico experimental: para el presente estudio fue seleccionado éste
método, ya que facilita el manejo de grandes cantidades de datos, permitiendo
desarrollar distintos ambientes de pruebas y experimentos, además de ajustarse
perfectamente a las necesidades expuestas en la investigación, debido a que en su
proceso está el planteamiento de un problema, la definición de una estrategia para
recolectar datos, representación, interpretación y análisis de resultados para emitir
conclusiones y recomendaciones.
Este método va a utilizar valores referenciales de cada uno de los indicadores utilizados
para el análisis del rendimiento, descrito en la Tabla V. 1.
- 132 -
5.6.3. ANÁLISIS ESTADÍSTICO DE LOS DATOS
Para llevar a cabo el análisis estadístico de los datos se va a necesitar de los valores
promedios obtenidos en el apartado anterior titulado “Procesamiento de los Datos” en
las tablas: Tabla V. 2, Tabla V. 3 y Tabla V. 4, las cuales presentan el comportamiento
que tiene cada uno de los CODEC's H.264, Xvid y Theora en los distintos escenarios,
por tal motivo a continuación se muestra la Tabla V. 5 la misma contendrá los valores
finales de los indicadores que están sometidos a evaluación.
TABLA V. 5 Indicadores de rendimiento para los CODEC H.264, Xvid y Theora
Reporte
del
Servidor
(%)
Reporte
Total
(%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
CODEC
H.2640,22327 0,0028 116,57 11,92215 1,45475 3,008 3,54 12,5
CODEC
Xvid0,21679 0,0092 114,8466667 12,003667 1,46873 2,992 3,17 12,7
CODEC
Theora0,03531 0,0107 136,3416667 14,178917 1,49065 3,008 3,5 15,8
CODEC
Paquetes Perdidos Ancho de Banda
Jitter
(ms)
Latencia
Fuente: Elaboración propia de los autores
a. Análisis del indicador Pérdida de Paquetes
Para un mejor entendimiento de los datos obtenidos respecto a la pérdida de
paquetes presentado en la Tabla V. 5 es necesario mostrar cada uno de los
resultados en porcentajes, debido a que la herramienta Jperf/Iperf permite la
captura de la pérdida de paquetes en porcentajes, por tal motivo a continuación
en la Figura V. 7 se presenta los resultados obtenidos respecto a la pérdida de
paquetes para cada uno de los CODEC's, sobre las transmisiones de video en
vivo y sobre demanda, con y sin congestión, en la misma se puede verificar que
- 133 -
los tres CODEC's no sobrepasan el valor referencial del 1% detallado en la
Tabla V. 1, por lo tanto se los considera como valores aceptables.
FIGURA V. 7 Análisis de la pérdida de paquetes en porcentajes
Fuente: Elaboración propia de los autores
En la Figura V. 7 se verifica que el CODEC Theora posee una pérdida de
paquetes del 0,0107% siendo el CODEC que más paquetes perdió en su
transmisión ya que dicho valor obtenido es el más elevado respecto a los demás
CODEC, el CODEC Xvid presenta una pérdida de paquetes mediáticas del
0,0092%, mientras que el CODEC H.264 posee una pérdida de paquetes del
0,0028%, el cual viene a ser el menor valor, siendo éste CODEC el que menos
paquetes pierde en su transmisión.
b. Análisis del indicador Latencia
En la Tabla V. 5 se muestran los datos obtenidos del tiempo mínimo, medio y
máximo que la latencia presenta en la difusión de video en vivo, sobre demanda
con congestión moderada, fuerte y sin congestión.
CODEC
H.264
CODEC
Xvid
CODEC
Theora
Paquetes Pérdidos (%) 0,0028 0,0092 0,0107
0
0,002
0,004
0,006
0,008
0,01
0,012
Paquetes Pérdidos (%)
- 134 -
Como ya se mencionó para el análisis de la latencia se hace uso del tiempo
medio de la latencia, debido a que dicho valor es el tiempo promedio que los
paquetes se demoran en realizar su trayectoria, estos valores se presentan en la
Figura V. 8 en la cual se observa que los tres CODEC's no sobrepasan el valor
referencial de 150 ms detallado en la Tabla V. 1, por lo tanto los tres resultados
se los considera como valores aceptables.
FIGURA V. 8 Análisis de la latencia
Fuente: Elaboración propia de los autores
A continuación los datos de la Figura V. 8 van hacer representados como
valores porcentuales en la Figura V. 9 con el objetivo de presentar un mejor
entendimiento para el lector. Para llevar a cabo la transformación de los
resultados se va hacer uso de la regla de tres designándole al valor referencial
aceptable de la latencia de 150 ms un valor porcentual de 100%.
CODEC H.264 CODEC Xvid CODEC Theora
Latencia (ms) 3,54 3,17 3,5
2,9
3
3,1
3,2
3,3
3,4
3,5
3,6
Latencia (ms)
- 135 -
FIGURA V. 9 Análisis de la latencia en valores porcentuales
Fuente: Elaboración propia de los autores
Como se puede observar en la Figura V. 9 el CODEC que más rápido realizó la
transmisión de datos de un extremo a otro en la red, es el CODEC de video Xvid
con un 2,113333333%, mientras que el CODEC que más tiempo se demoró en
realizar la transmisión en la red es el CODEC H.264 con un 2,36%, por su parte
el CODEC de video Theora presenta un valor mediático del 2,333333333%
respecto a los otros CODEC's ya que no se demora ni se tarda mucho en realizar
su transmisión.
c. Análisis del indicador Jitter
En la Tabla V. 5 presentada anteriormente se muestran los datos obtenidos del
jitter o tiempo de variación que toman los paquetes en la difusión de video en
vivo, sobre demanda con congestión moderada, fuerte y sin congestión en la red,
dichos valores se muestran de manera gráfica a continuación en la Figura V.
10.
CODEC H.264 CODEC Xvid CODEC Theora
Latencia (%) 2,36 2,11333333 2,33333333
1,95
2
2,05
2,1
2,15
2,2
2,25
2,3
2,35
2,4
Latencia (%)
- 136 -
Gracias a la presente gráfica se puede observar que los tres CODEC's no
sobrepasan el valor referencial del jitter de 50 ms detallado en la Tabla V. 1, por
lo tanto los tres resultados se los considera como valores aceptables.
FIGURA V. 10 Análisis del Jitter
Fuente: Elaboración propia de los autores
Debido a que los datos representados de manera porcentual son mucho más
fáciles de interpretar a continuación en la Figura V. 11 se presenta el porcentaje
del jitter que obtuvo cada uno de los CODEC. Para llevar a cabo la
transformación de los resultados se va hacer uso de la regla de tres designándole
al valor referencial aceptable del jitter de 50 ms un valor porcentual de 100%.
CODEC H.264 CODEC Xvid CODEC Theora
Jitter (ms) 1,45475 1,46873 1,49065
1,43
1,44
1,45
1,46
1,47
1,48
1,49
1,5
Jitter (ms)
- 137 -
FIGURA V. 11 Análisis del Jitter en valores porcentuales
Fuente: Elaboración propia de los autores
Como se puede observar en la Figura V. 11 el CODEC de video que menos
tiempo tubo en la variación de paquetes durante las transmisiones de streaming
en la red es el CODEC de video H.264 con un porcentaje del 2,9095%, mientras
que el CODEC de video que más tiempo obtuvo en las fluctuaciones de la red
fue el CODEC de video Theora con un 2,9813%, por su parte el CODEC de
video Xvid presenta un valor mediático del 2,93746% respecto a los otros
CODEC's ya que el tiempo de variación no se demora ni tarda mucho en sus
transmisiones.
d. Análisis del indicador Ancho de Banda
En la Tabla V. 5 presentada anteriormente se muestran los datos obtenidos de
las tramas transferidas por cada uno de los CODEC en los distintos escenarios,
además de presentar el consumo total del ancho de banda para cada CODEC en
la difusión de video en vivo, sobre demanda con congestión moderada, fuerte y
sin congestión en la red.
CODEC H.264 CODEC Xvid CODEC Theora
Jitter (%) 2,9095 2,93746 2,9813
2,86
2,88
2,9
2,92
2,94
2,96
2,98
3
Jitter (%)
- 138 -
Dichos valores se muestran de manera gráfica a continuación en la Figura V.
12, en la misma se puede observar que los CODEC's de video H.264 y Xvid no
sobrepasan el valor referencial de 15 Mbps detallado en la Tabla V. 1, por lo
tanto estos resultados se los considera como valores aceptables, caso contrario
ocurre con el CODEC de video Theora ya que sobrepasa el límite de consumo
del ancho de banda.
FIGURA V. 12 Análisis del Ancho de Banda
Fuente: Elaboración propia de los autores
Para mejor comprensión de los datos a continuación en la Figura V. 13 se
presenta el valor porcentual que obtuvo cada uno de los CODEC en el consumo
de ancho de banda en los diferentes escenarios. Para llevar a cabo la
transformación de los resultados se va hacer uso de la regla de tres designándole
al valor referencial aceptable del ancho de banda de 15 Mbps un valor
porcentual de 100%.
CODEC H.264 CODEC Xvid CODEC Theora
Ancho de Banda
(Mbps)11,92215 12,003667 14,178917
10,5
11
11,5
12
12,5
13
13,5
14
14,5
Ancho de Banda (Mbps)
- 139 -
FIGURA V. 13 Análisis del Ancho de Banda en valores porcentuales
Fuente: Elaboración propia de los autores
Como se puede observar en la Figura V. 13 el CODEC de video que menos
ancho de banda consume durante las transmisiones de streaming en la red es el
CODEC de video H.264 con un porcentaje del 79,481%, mientras que el
CODEC de video que más ancho de banda consumió fue el CODEC de video
Theora con un 94,52511333%, por su parte el CODEC de video Xvid presenta
un valor mediático del 80,02444667% respecto a los otros CODEC's ya que el
consumo de ancho de banda no consume ni demasiado ni poco ancho de banda
en sus transmisiones.
5.6.4. INTERPRETACIÓN DE RESULTADOS Y DETERMINACIÓN
DEL CODEC ÓPTIMO
A continuación en la Figura V. 14 se presenta el valor porcentual que cada
indicador obtuvo al someterlos a los distintos escenarios de transmisión de video en
vivo, sobre demanda con congestión moderada, fuerte, y sin congestión, utilizando
la codificación de los distintos CODEC's de video H.264, Xvid y Theora.
CODEC
H.264CODEC Xvid
CODEC
Theora
Ancho de Banda (%) 79,481 80,0244467 94,5261133
70
75
80
85
90
95
100
Ancho de Banda (%)
- 140 -
FIGURA V. 14 Porcentajes de los indicadores
Fuente: Elaboración propia de los autores
Para la determinación del CODEC que presentó mejor rendimiento en las
difusiones de video en la red sobre demanda y en vivo con congestión modera,
fuerte o sin congestión, se va a considerar los valores referenciales descritos en el
apartado anterior en la Tabla V. 1.
En lo que se refiere al análisis del primer indicador que es la pérdida de paquetes,
se cuenta con un valor referencial del 1%, dicho valor indica que entre menor sea la
pérdida de paquetes por debajo o igual del 1% se lo considera como valor aceptable
y que presenta mejor rendimiento en la red. En la Figura V. 14 se verifica que el
CODEC de video que más pérdida de paquetes presenta en las transmisiones de red,
es el Theora con un 0,0107%, el siguiente CODEC que más paquetes pierde en la
red, es el CODEC Xvid con un 0,0092%, mientras que el CODEC de video H.264
es el que menos paquetes perdió en la transmisión con un 0,0028%, por lo tanto es
el que mejor rendimiento presenta.
0 10 20 30 40 50 60 70 80 90 100
Pérdida de Paquetes (%)
Latencia (%)
Jitter (%)
Ancho de Banda (%)
Pérdida de
Paquetes (%)Latencia (%) Jitter (%)
Ancho de Banda
(%)
CODEC H.264 0,0028 2,36 2,9095 79,481
CODEC Xvid 0,0092 2,11333333 2,93746 80,0244467
CODEC Theora 0,0107 2,33333333 2,9813 94,5261133
Rendimiento
- 141 -
En lo que se refiere al análisis del segundo indicador que es la Latencia, se mide
en milisegundos y se la considera como tiempo de ping, entre más bajo es el tiempo
de ping por debajo o igual al valor referencial de 150 ms, menor latencia se
obtendrá y por ende mejor rendimiento para que la red funcione en condiciones
aceptables. Como se puede observar en la Figura IV. 14, el CODEC de video que
más tiempo tomó en realizar la transmisión en la red, es el CODEC H.264 con un
2,36%, por su parte el CODEC de video Theora presenta un valor mediático del
2,333333333% respecto a los otros CODEC's ya que no se demora ni se tarda
mucho en realizar su transmisión, mientras que el CODEC de video que más rápido
realizó la transmisión de datos de un extremo a otro en la red, es el CODEC Xvid
con un 2,113333333%, por lo tanto dicho CODEC presenta mejor rendimiento.
En lo que se refiere al análisis del tercer indicador que es el Jitter también se lo
mide en milisegundos y es considerado como la variación que se da al tiempo de
pings, entre menor sea dicha variación o fluctuación en la red por debajo o igual al
valor referencial de 50 ms se lo considera como valores aceptables para que la red
presente un buen rendimiento y esté en óptimas condiciones. En la Figura V. 14 se
puede verificar que el CODEC de video que ha obtenido mayor fluctuación de
latencia en la red es el CODEC Theora con un valor del 2,9813% en comparación
con el CODEC Xvid que presenta un valor mediático del 2,93746% y el CODEC
H.264 con un porcentaje del 2,9095% siendo éste el CODEC que menor valor
porcentual presenta por ende el que mejor rendimiento posee.
Finalmente para el análisis del cuarto indicador ancho de banda se va a considerar
que entre menor ancho de banda se consuma por debajo o igual al valor referencial
- 142 -
de 15 Mbps para emisiones de video en la red, va a presentar un mejor rendimiento
y velocidad. En la Figura V. 14 se presenta el CODEC de video que mayor ancho
de banda ha consumido como lo es el Theora con un porcentaje del 94,52511333%
en contraste con el CODEC Xvid que acarrea un porcentaje del 80,02444667% y el
CODEC H.264 con un valor del 79,481%, concluyendo que éste último es el que
consume menos ancho de banda en las transmisiones visuales en la red por ende el
que presenta mejor rendimiento.
Luego de todo lo descrito anteriormente, se deduce que mediante el análisis de
CODEC's de video sobre tráfico Multicast en IPv6, se logró determinar que el
CODEC de video más adecuado para el desarrollo de un prototipo en el
laboratorio LIRSI – FIE es el CODEC H.264, debido a que dicho CODEC,
presentó valores porcentuales de los indicadores: jitter, ancho de banda y pérdida
de paquetes, por debajo de los valores aceptables necesarios para tener un buen
funcionamiento en la red a pesar de presentar un retardo o latencia
considerablemente elevada.
5.6.5. ANALISIS Y PLANTEAMIENTO DE LA HIPOTESIS NULA Y
ALTERNATIVA MEDIANTE CHI CUADRADO
Luego de identificar el CODEC de video que mejor actúa en la red mediante la
interpretación de los datos porcentuales de cada uno de los indicadores, se va a
corroborar que dicho análisis está en lo correcto mediante la definición de
hipótesis nula e hipótesis alternativa.
Para el análisis se va a llevar a cabo la comprobación de la hipótesis por medio
de la distribución de probabilidad Chi Cuadrado, ésta distribución comúnmente
- 143 -
se la utiliza cuando la investigación a realizar no tiene otra investigación con
cual llevar a cabo la comparación de resultados y sólo permite verificar y
comprobar si dos variables están o no relacionadas.
H0: Hipótesis Nula
H1: Hipótesis Alternativa
Redacción Hipótesis Nula
H0: El análisis de CODEC's de video sobre tráfico Multicast en IPv6 para
el desarrollo de un prototipo en el laboratorio LIRSI – FIE permitirá
determinar que el CODEC más adecuado no mejorará el rendimiento en
transmisiones visuales en la red.
Redacción Hipótesis Alternativa
H1: El análisis de CODEC's de video sobre tráfico Multicast en IPv6 para
el desarrollo de un prototipo en el laboratorio LIRSI – FIE permitirá
determinar que el CODEC más adecuado mejorará el rendimiento en
transmisiones visuales en la red.
a. Valores observados
A continuación en la Tabla V. 6 se muestran los valores observados de los
indicadores del rendimiento de cada uno de los CODEC's de video.
- 144 -
TABLA V. 6 Valores observados de los CODEC de video
Pérdida de
Paquetes %
Latencia
(%)
Jitter
(%)
Ancho de
Banda (%) TOTAL
CODEC
H.264 0,0028 2,36 2,9095 79,481 84,7533
CODEC
Xvid 0,0092 2,1133333 2,93746 80,024447 85,08444
CODEC
Theora 0,0107 2,3333333 2,9813 94,526113 99,851446
TOTAL 0,0227 6,8066666 8,82826 254,03156 269,68919
Fuente: Elaboración propia de los autores
b. Valores esperados
A continuación en la Tabla V. 7 se muestran los valores esperados de los
indicadores del rendimiento de cada uno de los CODEC de video, para
determinar dichos valores se procedió aplicar la siguiente formula:
fe: Frecuencia del valor esperado
Stc: sumatoria total de cada columna es decir de cada indicador
Stf: sumatoria total de cada fila es decir de cada uno de los CODEC's
T: valor total de filas y columnas
- 145 -
TABLA V. 7 Valores esperados de los CODEC de video
Pérdida de
Paquetes Latencia Jitter
Ancho de
Banda TOTAL
CODEC
H.264 0.0071337 2,1390826 2,7743943 79,832688 84,746165
CODEC
Xvid 0,0071616 2,1474402 2,7852342 80,144602 85,084438
CODEC
Theora 0,0084045 2,5201436 3,2686312 94,054265 99,8514444
TOTAL 0,0155661 6,8066664 8,8282597 254,031555 269,682047
Fuente: Elaboración propia de los autores
c. Tabla de contingencia
A continuación se presenta la Tabla V. 8 mediante columnas paso a paso, la
manera de manipular con los valores observados y valores esperados una vez
que se hayan obtenido los mismos, dichos datos son utilizados para poder llegar
a descubrir el valor global del Chi Cuadrado para posteriormente poderlo
interpretar y comprobar con el valor crítico de Chi Cuadrado.
- 146 -
TABLA V. 8 Tabla de Contingencia Chi Cuadrado
0,0028 0.0071337 -0,004334 0,0000188 0,0026327
0,0092 0,0071616 0,0020384 0,0000042 0,0005802
0,0107 0,0084045 0,0022955 0,0000053 0,000627
2,36 2,1390826 0,2209174 0,0488045 0,0228156
2,1133333 2,1474402 -0,034107 0,0011633 0,0005417
2,3333333 2,5201436 -0,18681 0,0348981 0,0138477
2,9095 2,7743943 0,1351057 0,0182536 0,0065793
2,93746 2,7852342 0,1522258 0,0231727 0,0083198
2,9813 3,2686312 -0,287331 0,0825592 0,025258
79,481 79,832688 -0,351688 0,1236845 0,0015493
80,024447 80,144602 -0,120155 0,0144372 0,0001801
94,526113 94,054265 0,4718479 0,2226404 0,0023672
269,68919 0,0852986
Fuente: Elaboración propia de los autores
d. Chi Cuadrado calculado
Para llevar a cabo el análisis de Chi Cuadrado se hace uso de la siguiente
fórmula:
- 147 -
∑
X2: Chi Cuadrado
fo: Frecuencia del valor observado
fe: Frecuencia del valor esperado
e. Grados de Libertad
Para el funcionamiento de la distribución probabilística continua Chi Cuadrado,
es necesario determinar los grados de libertad mediante la siguiente fórmula,
estos grados son usados para leer e interpretar el valor crítico de Chi Cuadrado
en la tabla respectiva que ésta distribución posee.
nf: número de filas
nc: número de columnas
f. Nivel de significancia
Al hablar de nivel de significancia, se está hablando del error que se puede
cometer al rechazar el planteamiento de una hipótesis nula. La fórmula que se
utiliza es la siguiente:
- 148 -
ns= nivel de significancia
Num = Se refiere a un valor del 1 al 10 que se le designa para identificar que tan
válido representa un estudio a realizar, es decir entre más elevado es el valor se
confirma que el estudio es más acertado, si el valor es mucho menor se interpreta
que el estudio está expuesto a muchos errores, para tener un valor en porcentajes
se lo divide para 100. Por lo general se trabaja con un margen de error o nivel de
significancia de 5 ósea del 0,05%, lo que indica que hay una probabilidad del
0,95 de que la hipótesis nula sea verdadera
g. Interpretación de resultados del Valor Crítico y Chi Cuadrado
Una vez determinado el valor de Chi Cuadrado de los datos tabulados y el valor
critico en la tabla de Chi Cuadrado, se va a proceder hacer el respectivo análisis,
donde se tendrá en cuenta que si el valor de Chi Cuadrado tabulado se encuentra
por debajo del valor crítico de Chi Cuadrado descubierto en la tabla del Anexo
3, la hipótesis nula se rechaza.
Para el presente trabajo de investigación se confirma que el CODEC de video
H.264 descubierto anteriormente como el más adecuado para transmisiones de
video en la red, va a mejorar el rendimiento en dichas transmisiones visuales,
puesto que como se observa en la Figura V. 15 el valor de Chi Cuadrado
tabulado es del 0,0852986 y se encuentra por debajo del valor crítico de la tabla
del Chi Cuadrado del 12,592 por lo tanto el valor del Chi Cuadrado tabulado se
- 149 -
encuentra en el área de rechazo de la hipótesis nula planteada lo que significa
que se rechaza la hipótesis nula y se acepta la hipótesis alternativa, es decir que
el análisis de CODEC's de video sobre tráfico Multicast en IPv6 para el
desarrollo de un prototipo en el laboratorio LIRSI – FIE permitió verificar que el
CODEC H.264 mejora el rendimiento en transmisiones visuales en la red.
FIGURA V. 15 Chi Cuadrado
Fuente: Elaboración propia de los autores
CONCLUSIONES
El estudio comparativo de los CODEC’s de video H.264, Xvid y Theora
permitió concluir que son de distribución libre, compatibles con múltiples
sistemas operativos, útiles para video conferencia y streaming de video, reducen
y comprimen el flujo de bits.
El análisis de las aplicaciones de distribución libre como: FLUMOTION,
VIDEO LAN CLIENT, RED5 MEDIA PLAYER, ICECAST, GNUMP3D,
FFMPEG, DARWIN STREAMING SERVER (DSS) para el servidor
Streaming, permitió concluir que VIDEO LAN CLIENT es el software
adecuado para llevar a cabo el estudio porque permite la transmisión de video en
vivo y sobre demanda, configurarlo como cliente y servidor, soporta múltiples
plataformas, protocolos IPv6, RTP, RTSP y los CODEC’s en estudio, además de
ser compatible con Multicast y Unicast.
El desarrollo de las pruebas con las debidas configuraciones en los equipos de
Cisco permitió demostrar que el CODEC H.264 es el más adecuado para realizar
streaming de video en tiempo real y sobre demanda, con congestión moderada,
fuerte y sin congestión, al obtener una latencia elevada de 2.36% y una
fluctuación de 2,9095%, pérdida de paquetes de 0,0028% y consumo de ancho
de banda de 79,481% sumamente menores a los valores obtenidos respecto a los
otros CODEC en estudio.
- 151 -
Se utilizó la distribución de Chi Cuadrado para demostrar que el CODEC H.264
aumenta el rendimiento en las transmisiones visuales en la red, dando como
resultado de los valores esperados de 0,0852986, quedando por debajo del valor
crítico de la tabla de la misma distribución de 12,592, por lo que cae en el área
de rechazo de la hipótesis nula, lo que significa que se la rechaza y se acepta la
alternativa, es decir que el CODEC H.264 si aumenta el rendimiento.
Se diseñó una guía de implementación de streaming de video sobre una red con
tráfico Multicast en IPv6 útil para el laboratorio LIRSI – FIE, tomando en
cuenta que la configuración del módulo de la tarjeta capturadora de video en
Linux es muy importante para llevar a cabo una transmisión de video en tiempo
real porque se necesita capturar datos desde una filmadora y en ocasiones el
sistema operativo Linux no reconoce hardware adicional.
RECOMENDACIONES
Para realizar una emisión de video en vivo se recomienda la utilización de una
cámara de video profesional, similares a las utilizadas en un canal de televisión,
debido a que en el presente estudio se hizo uso de una filmadora de poca
resolución lo cual resultó de uso limitado para ciertas tomas pero básica para
realizar emisiones de video.
Si se emite datos de video pregrabadas en el disco duro o en tiempo real desde
una webcam o una filmadora, se recomienda la utilización de CODEC de audio
que sean compatible con el CODEC de video para que trabajen de manera
conjunta con el contenedor adecuado, ya que dependiendo del CODEC de audio,
video y contenedor las emisiones de video en la red van hacer mucho más
aceptables.
Debido a que es necesario la utilización de una tarjeta capturadora de video para
realizar transmisiones de audio y video en la red, se recomienda utilizar una
tarjeta original que soporte la transcodificación de varios CODEC de audio,
video y contenedores para evitar problemas al momento de difundir datos.
Según la experiencia obtenida en el presente trabajo al momento de utilizar los
equipos de la academia Cisco, se recomienda que para hacer uso de dichos
equipos se prevea la configuración a realizar, con el objetivo de ganar tiempo y
ejecutar las prueba de cada escenario más rápido, ya que los equipos son
- 153 -
utilizados por diversas personas con diferentes propósitos y el tiempo de uso
resulta ser limitado en ciertas ocasiones, además se recomienda obtener
respaldos de las configuraciones realizadas en los router y switch de Cisco en
discos extraíbles como: memory flash, disco duro portátil, etc.
Se recomienda la utilización de cables Fast Ethernet categoría 5e cruzados y
directos para la conexión de routers, switch y redes de área local debido a que
los cables Seriales provocan una transmisión de video con baja resolución.
RESUMEN
Se evaluó codecs de video sobre tráfico Multicast en IPv6, para el desarrollo de un
prototipo en el laboratorio LIRSI-FIE y se determinó el codec más adecuado que
mejorará el rendimiento en las transmisiones visuales en la red, por lo que se utilizó los
indicadores: pérdida de paquetes, latencia, jitter y consumo del ancho de banda.
Se utilizó el método experimental basado en valores referenciales o umbrales para
desarrollar diversos ambientes de prueba y experimentos para difusiones de streaming
de video. El comando ping y herramientas Iperf, Jperf, Wireshark se usaron para
obtener valores de cada uno de los indicadores del rendimiento.
El desarrollo de pruebas permite concluir que el codec H.264 es el más adecuado para
realizar streaming de video en diferentes escenarios porque posee una fluctuación de
1,45475ms, pérdida de paquetes de 0,0028%, latencia de 3,54ms y consumo de ancho
de banda de 11,92215Mbps, menores a los valores referenciales (50ms, 1%, 150ms,
15Mbps respectivamente) y a los valores que los demás codec presentan. El resultado de
la prueba de Chi Cuadrado de 0,0852986 demostró que el codec H.264, en efecto
mejora el rendimiento en trasmisiones visuales en la red debido a que se encuentra por
debajo del valor crítico.
Se recomienda utilizar el protocolo RTP MPEG/Transport para transmisiones de video
en vivo y sobre demanda, además usar filmadora con resolución mayor a 1080 pixeles y
tarjeta capturadora de video que soporte transcodificaciones de varios codecs de audio,
video y contenedores.
Palabras Claves: /LABORATORIO DE INVESTIGACIÓN DE REDES Y SISTEMAS
INFORMÁTICOS [FIE-ESPOCH]/, /CODEC DE VIDEO/, /TECNOLOGÍA
MULTICAST/, /PROTOCOLO IPv6/ ESTUDIO COMPARATIVO/
SUMMARY
Video codecs were evaluated about multicast traffic in ipv6 in order to develop a
prototype in the laboratory LIRSE-FIE and the most appropriate codec was determined
which will improve the visual transition performance in the network. Indicators like
lack of packages, latency, jitter, and consume of broadband.
Experimental method was used based on referential or thresholds values in order to
develop different testing sceneries and experiments for broadcasting video streaming.
The command ping and tools like Iperf, Jperf, Wireshark were used in order to get
values from each one of the performance indicators.
Testing allows to conclude that codec H.264 is the most appropriate to perform video
streaming in different sceneries because it has a fluctuation of 1,45475 ms, package
losing of 0,0028%, latency of 3,54 ms and consume of broadband of 11,92215 Mbps,
lower that referential values (50ms, 1%, 150ms, 15Mbps respectively) and the other
values that codec presents. The result of Chi square test of 0,0852986 showed that the
codec H.264, in fact it betters the visual transmission performance in network due to
they are under the critic value.
It is recommended to use the protocol RTP MPEG/ Transport live video transmissions
and about demand, besides to use a video camera with the resolution higher than 1080
pixels and video card of transcodifications support video of different codecs of audio,
video and containers.
KEY WORDS: /NETWORK AND INFORMATICS SYSTEMS RESEARCH
LABORATORY (FIE-ESPOCH)/, /VIDEO CODEC/, /MULTICAST
TECHNOLOGY/, /PROTOCOL IPv6/, /COMPARATIVE STUDY/
ANEXOS
ANEXO 1
SECCIÓN I: Archivo de configuración del router emisor
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ServerStream
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
!
no aaa new-model
!
dot11 syslog
ip source-route
!
!
ip cef
!
!
ipv6 unicast-routing
ipv6 cef
ipv6 Multicast-routing
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
voice-card 0
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
!
interface Loopback0
no ip address
ipv6 address 2001:1:1:1::1/64
ipv6 ospf 100 area 0
!
interface FastEthernet0/0
bandwidth 15360
no ip address
shutdown
duplex auto
speed auto
ipv6 address 2001:10::1/64
ipv6 mld join-group FF7E:240:2001:2:2:2:0:1
ipv6 ospf 100 area 0
!
interface FastEthernet0/1
bandwidth 15360
no ip address
shutdown
duplex auto
speed auto
ipv6 address FC00::1/64
ipv6 ospf 100 area 0
!
interface Serial0/1/0
no ip address
shutdown
clock rate 2000000
!
interface Serial0/1/1
no ip address
shutdown
clock rate 2000000
!
interface Serial0/2/0
no ip address
shutdown
clock rate 2000000
!
interface Serial0/2/1
no ip address
shutdown
clock rate 2000000
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
!
ipv6 router ospf 100
router-id 1.1.1.1
log-adjacency-changes
!
!
!
!
!
!
!
control-plane
!
!
!
!
mgcp fax t38 ecm
!
!
!
!
!
!
gatekeeper
shutdown
!
!
line con 0
line aux 0
line vty 0 4
login
!
scheduler allocate 20000 1000
end
SECCIÓN II: Archivo de configuración del router de punto de redirección
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname PRedireccion
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
!
no aaa new-model
memory-size iomem 5
!
dot11 syslog
ip source-route
!
!
ip cef
!
!
ipv6 unicast-routing
ipv6 cef
ipv6 Multicast-routing
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
voice-card 0
!
!
!
!
!
archive
log config
hidekeys
!
!
!
!
!
!
!
!
!
interface Loopback0
no ip address
ipv6 address 2001:2:2:2::2/64
ipv6 ospf 100 area 0
!
interface FastEthernet0/0
bandwidth 15360
no ip address
shutdown
duplex auto
speed auto
ipv6 address 2001:20::3/64
ipv6 ospf 100 area 0
!
interface FastEthernet0/1
bandwidth 15360
no ip address
shutdown
duplex auto
speed auto
ipv6 address 2001:10::2/64
ipv6 ospf 100 area 0
!
interface FastEthernet0/0/0
!
interface FastEthernet0/0/1
!
interface FastEthernet0/0/2
!
interface FastEthernet0/0/3
!
interface Serial0/2/0
no ip address
shutdown
clock rate 125000
!
interface Serial0/2/1
no ip address
shutdown
clock rate 125000
!
interface Vlan1
no ip address
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
!
ipv6 pim rp-address 2001:2:2:2::2
ipv6 router ospf 100
router-id 2.2.2.2
log-adjacency-changes
!
!
!
!
!
!
!
control-plane
!
!
!
!
mgcp fax t38 ecm
!
!
!
!
!
!
gatekeeper
shutdown
!
!
line con 0
line aux 0
line vty 0 4
login
!
scheduler allocate 20000 1000
end
SECCIÓN III: Archivo de configuración del router receptor
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname RCLIENTE
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
!
resource policy
!
memory-size iomem 5
ip cef
!
!
!
!
!
ipv6 unicast-routing
ipv6 cef
ipv6 dhcp pool streaming
prefix-delegation pool streaming-prefix-new
!
ipv6 Multicast-routing
!
voice-card 0
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
no ip address
ipv6 address 2001:3:3:3::3/64
ipv6 ospf 100 area 0
!
interface FastEthernet0/0
bandwidth 15360
no ip address
shutdown
duplex auto
speed auto
ipv6 address 2001:20::4/64
ipv6 ospf 100 area 0
!
interface FastEthernet0/1
bandwidth 15360
no ip address
shutdown
duplex auto
speed auto
ipv6 address FC01::1/64
ipv6 dhcp server streaming
ipv6 ospf 100 area 0
!
interface Serial0/2/0
no ip address
shutdown
clock rate 125000
!
interface Serial0/2/1
no ip address
shutdown
clock rate 125000
!
interface Serial0/3/0
no ip address
shutdown
clock rate 2000000
!
interface Serial0/3/1
no ip address
shutdown
clock rate 2000000
!
!
!
no ip http server
no ip http secure-server
!
ipv6 local pool client-prefix-pool FC01::/50 64
ipv6 router ospf 100
router-id 3.3.3.3
log-adjacency-changes
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
scheduler allocate 20000 1000
end
ANEXO 2
SECCIÓN I: Mediciones en la red del CODEC H.264
Escenario 1: Transmisión de video sobre demanda mediante el uso del
CODEC H.264 sin congestión.
TABLA 1: Resultados de la evaluación del CODEC H.264 del primer escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0 0,00017 132 13,8 1,607 3 4 14 1
2 0 0,00017 131 2,51 1,314 3 4 22 1
3 0 0,00017 133 13,9 1,534 3 4 24 1
4 0 0,00017 134 14 1,902 3 3 9 1
5 0 0,00017 132 13,8 1,461 3 4 15 1
6 0 0,00017 134 14,1 1,371 3 4 24 1
7 0 0,00017 131 13,8 1,486 3 3 13 1
8 0 0,00017 131 13,7 1,377 3 4 21 1
9 0 0,00017 132 0,9 1,472 3 4 13 1
10 0 0,00017 133 13,9 1,448 3 3 10 1
11 0 0,00017 131 13,7 1,431 3 3 11 1
12 0 0,00017 131 13,8 1,465 3 3 11 1
13 0 0,00017 131 13,8 1,45 3 3 8 1
14 0 0,00017 132 13,9 1,38 3 8 22 1
15 0 0,00017 132 13,9 1,428 3 4 15 1
16 0 0,00017 128 10,4 1,566 3 4 34 1
17 0,13 0,00017 133 13,9 1,247 3 3 15 1
18 0,15 0,00017 131 13,8 1,428 3 4 11 1
19 0,18 0,00017 131 13,8 0,615 3 3 7 1
20 0,14 0,00017 132 13,8 1,424 3 4 10 1
Suma 0,6 0,0034 2635 249,21 28,406 60 76 309 20
Prom
Total0,03 0,00017 131,75 12,4605 1,4203 3 3,8 15,45 1
Escenario 1:Transmisión del CODEC H.264 sobre demanda sin congestión
Número
de
Pruebas
LatenciaAncho de BandaPaquetes PerdidosTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 2: Transmisión del video sobre demanda mediante el uso del
CODEC H.264 con congestión moderada.
TABLA 2: Resultados de la evaluación del CODEC H.264 del segundo escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,55 0,00018 130 13,6 1,426 3 4 27 1
2 0,64 0,00018 132 13,9 1,564 3 4 10 1
3 0,6 0,00018 132 13,9 1,629 3 4 27 1
4 0,65 0,00018 131 13,8 1,435 3 4 29 1
5 0,63 0,00018 132 13,7 1,592 3 3 9 1
6 0,58 0,00018 131 13,8 1,382 3 4 13 1
7 0,62 0,014 133 13,9 1,725 3 4 11 1
8 0,6 0,00018 132 13,8 1,458 3 4 18 1
9 0,59 0,00018 68,2 7,15 1,425 3 4 9 1
10 0,55 0,00018 92,7 4,09 1,336 3 3 9 1
11 0,57 0,014 110 11,5 1,438 3 3 9 1
12 0,67 0,00018 71,8 7,53 1,406 3 4 13 1
13 0,6 0,00018 122 12,8 1,552 3 3 14 1
14 0,62 0,00018 72,6 7,62 1,41 3 4 27 1
15 0,48 0,00018 123 12,9 1,308 3 4 12 1
16 0,58 0,00018 69,4 7,28 1,526 3 3 9 1
17 0,55 0,00018 122 12,8 1,658 3 4 8 1
18 0,59 0,00018 73,6 7,72 1,656 3 4 15 1
19 0,68 0,00018 123 12,9 1,599 3 4 21 1
20 0,63 0,00018 120 11,8 1,425 3 3 9 1
Suma 11,98 0,03124 2221,3 226,49 29,95 60 74 299 20
Prom
Total0,599 0,001562 111,065 11,3245 1,4975 3 3,7 14,95 1
Escenario2: Transmisión del CODEC H.264 sobre demanda con congestión moderada
Número
de
Pruebas
LatenciaAncho de BandaPaquetes PerdidosTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 3: Transmisión de video sobre demanda mediante el uso del
CODEC H.264 con congestión fuerte.
TABLA 3: Resultados de la evaluación del CODEC H.264 del tercer escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,45 0,00018 71,6 7,51 2,058 3 4 10 1
2 0,52 0,00018 118 12,4 1,495 3 4 12 1
3 0,49 0,012 75,6 7,93 1,016 3 6 28 1
4 0,5 0,056 123 12,9 1,282 3 3 20 1
5 0,42 0,00018 72,7 7,62 0,817 3 4 14 1
6 0,51 0,00018 122 12,8 1,427 3 4 12 1
7 0,55 0,00018 78 7,16 1,572 3 4 9 1
8 0,5 0,048 122 12,8 1,019 3 4 19 1
9 0,35 0,00018 121 12,7 1,315 3 4 35 1
10 0,48 0,01 122 12,8 1,187 3 4 24 1
11 0,41 0,032 72,4 7,9 1,541 3 4 12 1
12 0,48 0,031 122 12,8 1,377 3 4 10 1
13 0,44 0,011 69,6 7,3 1,424 3 4 11 1
14 0,52 0,00018 121 12,7 1,346 3 4 12 1
15 0,41 0,00018 70,2 7,36 0,846 3 4 14 1
16 0,36 0,00018 123 12,9 1,718 3 9 4 1
17 0,39 0,00018 69,8 7,31 1,464 3 4 16 1
18 0,35 0,0097 122 12,8 0,767 3 4 9 1
19 0,39 0,00018 70,8 7,42 1,313 3 4 9 1
20 0,41 0,00018 69,8 7,32 1,176 3 4 10 1
Suma 8,93 0,21186 1936,5 202,43 26,16 60 86 290 20
Prom
Total0,4465 0,010593 96,825 10,1215 1,308 3 4,3 14,5 1
Escenario 3: Transmisión del CODEC H.264 sobre demanda con congestión fuerte
Número
de
Pruebas
LatenciaAncho de BandaPaquetes PerdidosTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 4: Transmisión de video en vivo mediante el uso del CODEC
H.264 sin congestión.
TABLA 4: Resultados de la evaluación del CODEC H.264 del cuarto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,2 0,00017 136 14,2 1,414 3 3 15 1
2 0,21 0,00017 135 12,2 1,536 3 3 11 1
3 0,21 0,00018 136 14,3 1,5 3 3 31 1
4 0,2 0,00017 133 14 1,464 3 3 4 1
5 0,21 0,00017 136 14,2 1,562 3 3 28 1
6 0,19 0,00017 136 14,2 1,455 3 3 5 1
7 0,22 0,00018 131 13,8 1,402 3 3 5 1
8 0,17 0,00017 136 14,2 1,511 3 3 11 1
9 0,17 0,00017 134 14 1,548 3 3 17 1
10 0,17 0,00017 134 14,1 1,508 3 3 5 1
11 0,18 0,00018 131 13,7 1,566 3 3 4 1
12 0,19 0,00017 131 13,8 1,423 3 4 15 1
13 0,17 0,00018 132 13,8 1,446 3 3 20 1
14 0,2 0,00018 133 14 1,437 3 3 5 1
15 0,19 0,00017 131 13,7 1,431 3 3 5 1
16 0,21 0,00018 132 13,9 1,443 3 3 7 1
17 0,22 0,00017 133 13,9 1,505 3 3 5 1
18 0,21 0,00017 135 14,2 1,415 3 3 6 1
19 0,21 0,00017 135 14,2 1,53 3 3 5 1
20 0,19 0,00018 132 13,8 1,443 3 3 6 1
Suma 3,92 0,00347 2672 278,2 29,539 60 61 210 20
Prom
Total0,196 0,0001735 133,6 13,91 1,47695 3 3,05 10,5 1
Escenario 4:Transmisión del CODEC H.264 en vivo sin congestión
Número
de
Pruebas
Tramas
Perdidas
LatenciaJitter
(ms)
Ancho de BandaPaquetes Perdidos
Fuente: Elaboración propia de los autores
Escenario 5: Transmisión de video en vivo mediante el uso del CODEC
H.264 con congestión moderada.
TABLA 5: Resultados de la evaluación del CODEC H.264 del quinto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mínim
o (ms)
Medio
(ms)
Maxim
o (ms)
1 0,12 0,054 113 11,9 2,576 3 4 14 1
2 0,037 0,00017 119 12,9 2,32 3 3 5 1
3 0,062 0,00017 76,8 8,05 1,332 3 3 9 1
4 0,06 0,00017 119 12,4 2,046 3 4 20 1
5 0,05 0,00017 112 11,8 2,328 3 3 7 1
6 0,041 0,00017 69,7 7,3 1,301 3 3 5 1
7 0,053 0,00017 113 11,9 1,811 3 3 19 1
8 0,053 0,00017 67,4 7,07 1,539 3 3 5 1
9 0,043 0,00017 115 12 1,721 3 3 8 1
10 0,023 0,00017 123 12,9 1,319 3 4 8 1
11 0,056 0,00017 66,7 6,99 1,417 3 3 15 1
12 0,06 0,00017 65,9 6,91 1,377 3 3 8 1
13 0,014 0,00017 112 11,08 1,401 3 4 9 1
14 0,0074 0,00017 117 12,3 1,386 3 3 9 1
15 0,0099 0,00017 72,8 7,64 1,395 3 3 4 1
16 0,0099 0,00017 61,9 6,42 1,28 3 3 8 1
17 0,0042 0,00017 108 11,3 1,255 3 3 8 1
18 0,0033 0,00017 117 12,2 1,321 3 4 9 1
19 0,0083 0,01 119 12,5 0,859 3 4 24 1
20 0,077 0,013 63,4 6,65 1,404 4 5 11 1
Suma 0,792 0,07989 1931,6 202,21 31,388 61 68 205 20
Prom
Total0,0396 0,0039945 96,58 10,1105 1,5694 3,05 3,4 10,25 1
Escenario 5:Transmisión del CODEC H.264 en vivo con congestión moderada
Número
de
Pruebas
LatenciaAncho de BandaPaquetes PerdidosTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 6: Transmisión de video en vivo mediante el uso del CODEC
H.264 con congestión fuerte.
TABLA 6: Resultados de la evaluación del CODEC H.264 del sexto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,039 0,00017 130 13,6 1,412 3 3 12 1
2 0,032 0,00017 130 13,6 1,351 3 3 5 1
3 0,018 0,00017 130 13,6 1,455 3 3 5 1
4 0,031 0,00017 129 13,6 1,474 3 3 21 1
5 0,017 0,00017 128 13,4 1,29 3 3 6 1
6 0,037 0,00017 129 13,6 1,377 3 3 5 1
7 0,025 0,00017 131 13,7 1,652 3 3 5 1
8 0,028 0,00017 129 13,6 1,359 3 3 5 1
9 0,03 0,00017 130 13,6 1,521 3 3 4 1
10 0,026 0,00017 129 13,6 1,413 3 3 5 1
11 0,029 0,00017 129 13,6 1,456 3 3 45 1
12 0,03 0,00017 131 13,7 1,433 3 3 5 1
13 0,032 0,00017 131 13,7 1,701 3 3 4 1
14 0,029 0,00017 126 13,3 1,456 3 3 4 1
15 0,031 0,00017 128 13,4 1,442 3 3 5 1
16 0,031 0,00017 131 13,8 1,45 3 3 7 1
17 0,026 0,00017 129 13,5 1,423 3 3 26 1
18 0,022 0,00017 130 13,7 1,485 3 3 6 1
19 0,024 0,00017 131 13,7 1,512 3 3 6 1
20 0,033 0,00017 131 13,8 1,465 3 3 4 1
Suma 0,57 0,0034 2592 272,1 29,127 60 60 185 20
Prom
Total0,0285 0,00017 129,6 13,605 1,45635 3 3 9,25 1
Escenario 6:Transmisión del CODEC H.264 en vivo congestion fuerte
Número
de
Pruebas
LatenciaAncho de BandaPaquetes PerdidosTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Cliente que realiza petición para visualizar un video sobre demanda
emitido en la red por un grupo Multicast mediante el uso del CODEC
H.264
Comprobación del rendimiento y captura de datos mediante la herramienta
Jperf/Iperf en una emisión de video con congestión mediante el uso del
CODEC H.264
Cliente que realiza petición para visualizar un video en tiempo real emitido
en la red por un grupo Multicast mediante el uso del CODEC H.264
La figura expuesta a continuación, representa el proceso de solicitud que se
realiza internamente entre la comunicación de paquetes para conocer los
vecinos que un grupo Multicast en el protocolo de internet versión seis
puede poseer.
SECCIÓN II: Mediciones en la red del CODEC Xvid
Escenario 1: Transmisión de video sobre demanda mediante el uso del
CODEC Xvid sin congestión.
TABLA 1: Resultados de la evaluación del CODEC Xvid del primer escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0 0,00017 132 13,8 1,199 3 3 6 1
2 0 0,00017 126 13,2 1,497 3 3 29 1
3 0 0,00017 127 13,3 1,452 3 3 13 1
4 0 0,00017 126 13,2 1,392 3 3 6 1
5 0 0,00017 127 13,3 1,453 3 3 15 1
6 0 0,00017 128 13,2 1,442 3 3 12 1
7 0 0,00017 128 13,4 1,494 3 3 22 1
8 0 0,00017 131 13,7 1,458 3 3 16 1
9 0 0,00017 131 13,7 1,392 3 3 33 1
10 0 0,00017 126 13,2 1,431 3 3 13 1
11 0 0,00017 127 13,4 1,47 3 5 31 1
12 0 0,00017 128 10,2 1,429 3 4 25 1
13 0 0,00017 128 13,4 1,491 3 3 22 1
14 0 0,00017 132 13,9 1,329 3 4 6 1
15 0 0,00017 134 14 1,438 3 3 18 1
16 0,12 0,00018 130 13,6 1,459 3 3 4 1
17 0,16 0,00018 127 13,3 1,433 3 3 5 1
18 0,2 0,00018 132 13,8 1,451 3 3 15 1
19 0,17 0,00018 131 13,8 1,436 3 3 6 1
20 0,17 0,00018 132 13,9 1,416 3 3 6 1
Suma 0,82 0,00345 2583 267,3 28,562 60 64 303 20
Prom
Total0,041 0,0001725 129,15 13,365 1,4281 3 3,2 15,15 1
Escenario 1:Transmisión del CODEC Xvid sobre demanda sin congestión
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 2: Transmisión de video sobre demanda mediante el uso del
CODEC Xvid con congestión moderada.
TABLA 2: Resultados de la evaluación del CODEC Xvid del segundo escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,55 0,00018 127 13,3 1,437 3 3 9 1
2 0,49 0,00018 131 13,8 1,507 3 3 6 1
3 0,59 0,00018 127 13,3 1,513 3 4 3 1
4 0,57 0,00018 131 13,7 1,562 3 3 6 1
5 0,51 0,00018 132 13,8 1,474 3 4 30 1
6 0,49 0,00018 129 13,5 1,443 3 4 35 1
7 0,57 0,00018 127 13,3 1,53 3 4 42 1
8 0,65 0,00018 131 13,7 1,483 3 3 6 1
9 0,45 0,00018 132 13 1,009 3 4 24 1
10 0,55 0,014 127 13,3 1,28 3 3 25 1
11 0,52 0,015 126 13,2 1,421 3 3 5 1
12 0,38 0,00018 131 13,7 1,67 3 4 14 1
13 0,49 0,00018 128 13,4 1,262 3 5 3 1
14 0,35 0,00018 131 13,8 1,799 3 3 14 1
15 0,54 0,00018 132 13,8 1,328 3 3 15 1
16 0,35 0,00018 131 13,8 1,98 3 3 9 1
17 0,55 0,00018 127 13,3 1,354 3 3 9 1
18 0,38 0,017 131 13,7 1,337 3 3 7 1
19 0,59 0,00018 130 13,6 1,497 3 3 11 1
20 0,61 0,00018 131 13,7 1,553 3 3 5 1
Suma 10,18 0,04906 2592 270,7 29,439 60 68 278 20
Prom
Total0,509 0,002453 129,6 13,535 1,47195 3 3,4 13,9 1
Escenario 2:Transmisión del CODEC Xvid sobre demanda con congestión moderada
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 3: Transmisión de video sobre demanda mediante el uso del
CODEC Xvid con congestión fuerte.
TABLA 3: Resultados de la evaluación del CODEC Xvid del tercer escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,3 0,00018 67,9 7,09 1,866 3 4 29 1
2 0,51 0,00018 116 11,6 1,443 3 3 15 1
3 0,35 0,00018 93,4 9,79 1,203 3 4 10 1
4 0,5 0,00018 90,3 9,46 1,347 3 3 4 1
5 0,29 0,024 55,7 5,84 1,376 3 3 5 1
6 0,52 0,00018 93,6 9,82 1,347 3 4 28 1
7 0,24 0,00018 65,1 6,83 1,109 3 4 34 1
8 0,45 0,00018 86,4 9,06 1,373 3 3 5 1
9 0,42 0,00018 58,9 6,18 1,229 3 3 5 1
10 0,53 0,00018 86,2 9,04 1,164 3 3 10 1
11 0,3 0,00018 87 9,13 1 3 3 8 1
12 0,47 0,00018 90,3 9,47 1,363 3 3 8 1
13 0,34 0,00018 85,5 8,97 1,348 3 3 5 1
14 0,39 0,00018 119 12,5 1,361 3 3 5 1
15 0,33 0,00018 64,5 6,77 2,278 3 5 25 1
16 0,46 0,0076 63,6 6,67 1,34 3 3 4 1
17 0,32 0,00018 114 12 0,889 3 3 34 1
18 0,57 0,00018 60 6,29 1,312 3 4 49 1
19 0,34 0,00018 82,6 8,66 1,876 3 3 5 1
20 0,29 0,00018 80,5 8,44 1,27 3 3 23 1
Suma 7,92 0,03484 1660,5 173,61 27,494 60 67 311 20
Prom
Total0,396 0,001742 83,025 8,6805 1,3747 3 3,35 15,55 1
Escenario 3: Transmisión del CODEC Xvid sobre demanda con congestión fuerte
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 4: Transmisión de video en vivo mediante el uso del CODEC
Xvid sin congestión.
TABLA 4: Resultados de la evaluación del CODEC Xvid del cuarto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,22 0,00018 128 13,6 1,469 3 3 5 1
2 0,23 0,00018 127 13,3 1,572 3 3 21 1
3 0,16 0,00018 135 14,1 1,447 3 3 4 1
4 0,17 0,00018 130 13,6 1,441 3 3 7 1
5 0,18 0,00018 132 13,8 1,448 3 3 5 1
6 0,17 0,00018 134 14,1 1,434 3 3 5 1
7 0,22 0,00018 134 14 1,384 3 3 5 1
8 0,19 0,00018 130 13,6 1,418 3 3 5 1
9 0,21 0,00018 132 13,9 1,406 3 4 14 1
10 0,18 0,00018 130 13,6 1,397 3 3 6 1
11 0,2 0,00018 128 13,4 1,444 3 3 5 1
12 0 0,00017 131 13,8 1,478 3 3 6 1
13 0 0,00017 130 13,7 1,478 3 3 5 1
14 0 0,00017 133 13,9 1,403 3 3 5 1
15 0 0,00017 129 13,5 1,442 3 3 5 1
16 0 0,00017 132 13,8 1,414 3 3 6 1
17 0 0,00017 128 13,4 1,518 3 3 15 1
18 0 0,00017 130 13,6 1,447 3 3 4 1
19 0 0,00017 129 13,5 1,454 3 3 5 1
20 0 0,068 127 13,4 1,45 3 3 5 1
Suma 2,13 0,07134 2609 273,6 28,944 60 61 138 20
Prom
Total0,1065 0,003567 130,45 13,68 1,4472 3 3,05 6,9 1
Escenario 4:Transmisión del CODEC Xvid en vivo sin carga
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 5: Transmisión de video en vivo mediante el uso del CODEC
Xvid con congestión moderada.
TABLA 5: Resultados de la evaluación del CODEC Xvid del quinto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,073 0,00018 63,2 6,63 1,435 3 3 9 1
2 0,098 0,00018 61,3 6,42 1,365 3 3 23 1
3 0,089 0,00018 64,5 6,77 1,763 3 3 8 1
4 0,11 0,00018 57 5,97 1,414 3 3 26 1
5 0,075 0,011 65,5 6,87 1,482 3 3 15 1
6 0,053 0,00018 59,4 6,23 1,614 3 3 8 1
7 0,038 0,00018 117 12,3 1,245 3 3 8 1
8 0,053 0,18 116 12,2 1,819 3 3 7 1
9 0,064 0,00018 59,4 6,22 1,378 3 3 13 1
10 0,089 0,00018 62,6 6,56 1,305 3 3 19 1
11 0,049 0,014 118 12,4 1,615 3 3 5 1
12 0,061 0,00018 115 12,1 2,542 3 3 5 1
13 0,078 0,24 115 12,1 1,358 3 3 29 1
14 0,073 0,5 117 12,2 1,621 3 3 8 1
15 0,051 0,00018 116 12,2 1,872 3 3 5 1
16 0,028 0,00018 115 12,1 2,524 3 3 6 1
17 0,062 0,00018 67,6 7,09 1,705 3 3 8 1
18 0,062 0,00018 87,4 9,16 1,616 3 3 25 1
19 0,056 0,00018 86,6 9,08 1,388 3 3 21 1
20 0,063 0,00018 55,6 5,83 1,059 3 3 8 1
Suma 1,325 0,9477 1719,1 180,43 32,12 60 60 256 20
Prom
Total0,06625 0,047385 85,955 9,0215 1,606 3 3 12,8 1
Escenario 5: Transmisión del CODEC Xvid en vivo con congestión moderada
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 6: Transmisión de video en vivo mediante el uso del CODEC
Xvid con congestión fuerte.
TABLA 6: Resultados de la evaluación del CODEC Xvid del sexto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,17 0,00018 129 13,6 1,467 2 3 18 1
2 0,19 0,00018 131 13,8 1,492 3 3 21 1
3 0,2 0,00018 132 13,8 1,463 3 3 5 1
4 0,2 0,00018 130 13,6 1,474 3 3 5 1
5 0,19 0,00018 129 13,6 1,447 3 3 5 1
6 0,18 0,00018 132 13,9 1,435 3 3 5 1
7 0,17 0,00018 131 13,8 1,505 3 3 6 1
8 0,21 0,00018 132 13,8 1,501 3 3 5 1
9 0,14 0,00018 129 13,6 1,6709 3 3 6 1
10 0,19 0,00018 132 13,9 1,492 3 3 5 1
11 0,19 0,00018 134 14 1,498 3 3 9 1
12 0,21 0,00018 129 13,5 1,484 3 3 5 1
13 0,21 0,00018 132 13,9 1,484 3 3 21 1
14 0,15 0,00018 128 13,4 1,522 3 3 5 1
15 0,15 0,00018 133 13,9 1,469 3 3 6 1
16 0,16 0,00018 130 13,6 1,46 3 3 6 1
17 0,17 0,00018 133 14 1,396 3 3 46 1
18 0,2 0,00018 128 13,4 1,441 3 3 46 1
19 0,2 0,00018 132 13,9 1,476 3 3 5 1
20 0,16 0,00018 132 13,8 1,511 3 3 5 1
Suma 3,64 0,0036 2618 274,8 29,6879 59 60 235 20
Prom
Total0,182 0,00018 130,9 13,74 1,4844 2,95 3 11,75 1
Escenario 6:Transmisión del CODEC Xvid en vivo con congestion fuerte
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Cliente que realiza petición para visualizar un video sobre demanda
emitido en la red por un grupo Multicast mediante el uso del CODEC Xvid
Comprobación del rendimiento y captura de datos mediante la herramienta
Jperf/Iperf en una emisión de video con congestión mediante el uso del
CODEC Xvid
Cliente que realiza petición para visualizar un video en tiempo real emitido
en la red por un grupo Multicast mediante el uso del CODEC Xvid
En la pantalla presentada a continuación se puede verificar un mensaje
MLD la cual representa la comunicación que existe entre los routers con los
clientes, permitiendo de esta manera que los clientes tengan acceso a la
visualización de la transmisión que se está realizando en la red.
SECCIÓN III: Mediciones en la red del CODEC Theora
Escenario 1: Transmisión de video sobre demanda mediante el uso del
CODEC Theora sin congestión.
TABLA 1: Resultados de la evaluación del CODEC Theora del primer escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0 0,00017 140 14,7 1,436 3 3 24 1
2 0 0,00017 140 14,7 1,437 3 3 10 1
3 0 0,17 139 14,6 1,586 3 3 6 1
4 0 0,00017 140 14,7 1,303 3 3 5 1
5 0 0,00017 140 14,7 1,385 3 3 15 1
6 0 0,00017 140 14,7 1,419 3 3 4 1
7 0 0,00017 140 14,7 1,433 3 3 6 1
8 0 0,00017 140 14,7 1,432 3 3 6 1
9 0 0,00017 140 14,7 1,423 3 3 4 1
10 0 0,00017 139 14,6 1,422 3 3 25 1
11 0 0,00017 140 14,7 1,422 3 3 5 1
12 0 0,00017 140 14,7 1,405 3 3 6 1
13 0 0,00017 140 14,7 1,419 3 3 43 1
14 0 0,00017 140 14,7 1,417 3 3 26 1
15 0 0,00017 140 14,7 1,446 3 4 6 1
16 0 0,00017 140 14,7 1,44 3 3 6 1
17 0 0,00017 140 14,7 1,491 3 3 6 1
18 0 0,00017 140 14,7 1,423 3 3 12 1
19 0 0,00017 140 14,7 1,488 3 3 33 1
20 0 0,00017 140 14,6 1,487 3 3 6 1
Suma 0 0,17323 2798 293,7 28,714 60 61 254 20
Prom
Total0 0,0086615 139,9 14,685 1,4357 3 3,05 12,7 1
Escenario 1: Transmisión del CODEC Theora sobre demanda sin congestión
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 2: Transmisión de video sobre demanda mediante el uso del
CODEC Theora con congestión moderada.
TABLA 2: Resultados de la evaluación del CODEC Theora del segundo escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,067 0,00018 147 15,4 1,367 3 3 25 1
2 0,051 0,00018 146 15,3 1,284 3 3 25 1
3 0,049 0,00018 147 15,4 1,459 3 3 6 1
4 0 0,28 147 15,4 1,358 3 3 42 1
5 0,0068 0,00017 148 15,5 1,371 3 3 16 1
6 0 0,00017 147 15,5 1,484 3 3 20 1
7 0 0,00017 147 15,4 1,451 3 3 6 1
8 0 0,00017 147 15,4 1,427 3 3 5 1
9 0,069 0,00018 147 2,87 1,455 3 3 37 1
10 0 0,00017 146 15,3 1,34 3 4 48 1
11 0 0,00017 144 15,1 1,275 3 3 26 1
12 0 0,00017 144 15,1 1,362 3 4 30 1
13 0 0,00017 148 15,5 1,345 3 4 3 1
14 0 0,00017 146 15,3 1,389 3 3 10 1
15 0 0,00017 143 15 1,36 3 3 6 1
16 0,003 0,00017 145 15,2 1,537 3 3 23 1
17 0 0,00017 145 15,2 1,381 3 3 5 1
18 0 0,00017 146 15,3 1,412 3 3 5 1
19 0 0,00017 145 15,2 1,816 3 3 5 1
20 0 0,00017 145 15,2 1,376 3 3 5 1
Suma 0,2458 0,28327 2920 293,57 28,249 60 63 348 20
Prom
Total0,01229 0,0141635 146 14,6785 1,41245 3 3,15 17,4 1
Escenario 2: Transmisión del CODEC Theora sobre demanda con congestión moderada
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 3: Transmisión de video sobre demanda mediante el uso del
CODEC Theora con congestión fuerte.
TABLA 3: Resultados de la evaluación del CODEC Theora del tercer escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,003 0,00017 147 15,4 1,427 3 4 73 1
2 0,055 0,00018 147 15,5 1,518 3 3 6 1
3 0 0,00017 146 15,3 1,446 3 3 6 1
4 0,007 0,00017 145 15,3 1,369 3 3 15 1
5 0,001 0,00017 146 15,3 1,528 3 3 23 1
6 0,068 0,00018 149 15,6 1,357 3 3 5 1
7 0,007 0,00017 147 15,4 1,391 3 3 6 1
8 0 0,00017 147 15,4 1,993 3 3 15 1
9 0 0,00017 146 15,4 1,428 3 3 6 1
10 0,0097 0,00018 147 15,4 1,482 3 3 5 1
11 0,007 0,00017 145 15,3 1,687 3 3 5 1
12 0,15 0,00017 148 15,5 1,364 3 3 5 1
13 0,12 0,00017 147 15,5 1,573 3 3 5 1
14 0,083 0,00018 148 15,6 1,349 3 3 5 1
15 0,039 0,00017 145 15,1 1,428 3 3 6 1
16 0,068 0,00017 148 15,5 1,421 3 4 10 1
17 0,11 0,00018 144 15,1 1,119 3 3 5 1
18 0,12 0,00018 148 15,5 1,342 3 3 5 1
19 0,11 0,00018 149 15,6 1,248 3 3 7 1
20 0,13 0,00018 149 15,6 1,318 3 3 9 1
Suma 1,0877 0,00348 2938 308,3 28,788 60 62 222 20
Prom
Total0,054385 0,000174 146,9 15,415 1,4394 3 3,1 11,1 1
Escenario 3:Transmisión del CODEC Theora sobre demanda con congestión fuerte
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 4: Transmisión de video en vivo mediante el uso del CODEC
Theora sin congestión.
TABLA 4: Resultados de la evaluación del CODEC Theora del cuarto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,087 0,017 131 13,8 1,405 3 4 34 1
2 0,014 0,00019 129 13,5 1,519 3 3 6 1
3 0,004 0,022 108 11,3 1,574 3 4 13 1
4 0,0076 0,021 132 13,9 1,471 3 3 7 1
5 0,094 0,00019 122 12,8 1,477 3 4 29 1
6 0,01 0,019 112 11,8 1,793 3 4 8 1
7 0,008 0,018 125 13,1 1,504 3 4 10 1
8 0,0013 0,00019 108 11,3 1,889 3 4 14 1
9 0,0076 0,021 113 11,8 1,491 3 4 25 1
10 0,0082 0,025 123 12,9 1,93 3 4 29 1
11 0,026 0,066 109 11,4 1,52 3 4 29 1
12 0,0066 0,023 109 11,4 1,852 3 4 12 1
13 0,0062 0,0019 115 12,1 1,405 3 4 10 1
14 0,0092 0,084 109 11,4 1,939 3 4 39 1
15 0,0086 0,025 116 12,2 1,966 3 4 39 1
16 0 0,023 96 10,1 1,854 3 4 8 1
17 0,017 0,02 125 13,1 1,881 3 4 10 1
18 0,074 0,00019 116 12,2 1,99 3 4 7 1
19 0,004 0,00019 106 11,1 1,469 3 4 20 1
20 0,0061 0,00019 117 12,3 1,465 3 4 9 1
Suma 0,3994 0,38704 2321 243,5 33,394 60 78 358 20
Prom
Total0,01997 0,019352 116,05 12,175 1,6697 3 3,9 17,9 1
Escenario 4:Transmisión del CODEC Theora en vivo sin congestión
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 5: Transmisión de video en vivo mediante el uso del CODEC
Theora con congestión moderada.
TABLA 5: Resultados de la evaluación del CODEC Theora del quinto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max(m
s)
1 0,027 0,00019 144 15,1 1,258 3 3 25 1
2 0,02 0,03 137 14,3 1,409 3 4 36 1
3 0,017 0,00019 136 13,2 1,401 3 4 17 1
4 0,02 0,00018 143 15,3 1,412 3 3 5 1
5 0,015 0,00019 135 14,1 1,724 3 3 5 1
6 0,013 0,00019 134 14,1 1,954 3 4 22 1
7 0,088 0,025 130 13,7 1,478 3 3 16 1
8 1,8 0,00019 126 13,4 1,48 3 4 7 1
9 0,021 0,00019 145 15,2 1,388 3 3 9 1
10 0,024 0,034 133 13,9 1,378 3 3 7 1
11 0,0037 0,019 116 12,7 1,313 3 4 16 1
12 0,013 0,00019 130 13,6 1,869 3 3 7 1
13 0,018 0,024 137 14,4 1,761 3 3 11 1
14 0,012 0,024 139 14,6 1,358 3 4 66 1
15 0,011 0,0019 128 13,4 1,579 3 4 8 1
16 0,021 0,00019 143 15 1,366 3 3 8 1
17 0,01 0,00019 141 14,8 1,885 3 4 11 1
18 0,0025 0,00037 115 12,1 1,332 3 4 20 1
19 0,011 0,00019 126 13,2 1,123 3 3 6 1
20 0,012 0,00018 142 14,9 1,48 3 3 8 1
Suma 2,1592 0,16053 2680 281 29,948 60 69 310 20
Prom
Total0,10796 0,0080265 134 14,05 1,4974 3 3,45 15,5 1
Escenario 5:Transmisión del CODEC Theora en vivo con congestión moderada
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Escenario 6: Transmisión de video en vivo mediante el uso del CODEC
Theora con congestión fuerte.
TABLA 6: Resultados de la evaluación del CODEC Theora del sexto escenario
Reporte del
Servidor
(%)
Reporte
Total (%)
Tramas
Transferidas
(Mbps)
Tramas
Consumidas
(Mbps)
Mín
(ms)
Med
(ms)
Max
(ms)
1 0,015 0,00019 135 14,2 1,434 3 4 29 1
2 0,014 0,00019 130 13,6 1,902 3 3 9 1
3 0,016 0,026 138 14,5 1,306 3 3 12 1
4 0,97 0,25 140 14,8 1,561 3 3 8 1
5 0,13 0,00018 136 14,3 1,543 3 3 63 1
6 0,13 0,00018 137 14,3 1,41 3 3 6 1
7 0,09 0,00019 138 13,8 1,498 3 4 8 1
8 0,099 0,00018 140 13,9 1,434 3 3 12 1
9 0,11 0,00019 137 13,8 1,437 3 5 31 1
10 0,18 0,00018 132 13,8 1,73 3 5 18 1
11 0,18 0,00018 137 13,9 1,388 3 7 21 1
12 0,1 0,00019 130 14,3 1,485 3 6 23 1
13 0,92 0,00019 128 14,2 1,498 4 4 8 1
14 0,11 0,00018 137 14 1,459 3 4 25 1
15 0,024 0,00018 133 13,9 1,487 3 4 6 1
16 0,016 0,00018 140 13,9 1,201 3 4 9 1
17 0,18 0,00018 138 14,1 1,388 3 4 14 1
18 0,18 0,00018 139 14,2 1,73 3 7 18 1
19 0,016 0,00018 140 14 1,427 3 5 63 1
20 0,025 0,00018 139 13,9 1,467 3 6 20 1
Suma 3,505 0,2793 2724 281,4 29,785 61 87 403 20
Prom
Total0,17525 0,013965 136,2 14,07 1,48925 3,05 4,35 20,15 1
Escenario 6:Transmisión del CODEC Theora en vivo con congestión fuerte
Paquetes PerdidosNúmero
de
Pruebas
Ancho de Banda LatenciaTramas
Perdidas
Jitter
(ms)
Fuente: Elaboración propia de los autores
Cliente que realiza petición para visualizar un video sobre demanda
emitido en la red por un grupo Multicast mediante el uso del CODEC
Theora
Comprobación del rendimiento y captura de datos mediante la herramienta
Jperf/Iperf en una emisión de video con congestión mediante el uso del
CODEC Theora
Cliente que realiza petición para visualizar un video en tiempo real emitido
en la red por un grupo Multicast mediante el uso del CODEC Theora.
Para la medición de uno de los indicadores del rendimiento fue necesario
modificar el tamaño del paquete de datos a transmitir en la red, la figura
mostrada a continuación presenta dicho cambio que sufre el paquete.
ANEXO 3
TABLA DE DISTRIBUCIÓN DE CHI CUADRADO CON VALORES CRÍTICOS
Referencia: http://image.slidesharecdn.com/tablachi-cuadrado-130304103318-phpapp02/95/slide-1-638.jpg?cb=1362414835
CONTINUACIÓN: TABLA DE DISTRIBUCIÓN DE CHI CUADRADO CON VALORES CRÍTICOS
Referencia: http://image.slidesharecdn.com/tablachi-cuadrado-130304103318-phpapp02/95/slide-2-638.jpg?cb=1362414835
ANEXO 4
GUÍA DE IMPLEMENTACIÓN DE STREAMING DE VIDEO SOBRE UNA
RED CON TRÁFICO MULTICAST EN IPv6 PARA EL LABORATORIO LIRSI
– FIE
1. DISEÑO Y CONFIGURACIÓN DE UNA RED MULTICAST IPv6
1.1. Esquema de la Red
Los routers están configurados con el protocolo de enrutamiento OSPF y con el
protocolo de internet IPv6.
La configuración del grupo de Multicast es embebida en RP, ya que es de gran
utilidad porque escucha las peticiones por parte de los clientes y envía respuestas
a dichas peticiones, permitiendo a los mensajes PIM comunicarse con el grupo
de Multicast con él envió y recibimiento de información hacia los routers
fronteras que se conectan con los clientes.
Los routers están conectados mediante enlaces Fast Ethernet categoría 5e de tipo
cruzado y con un ancho de banda de 15 Mbps, debido al gran volumen de datos
multimedia que un video requiere. Para una mejor compresión se presenta la
siguiente figura.
1.2. Configuración de los Routers
Para la configuración de los routers se procede a conectar la interfaz de la
línea de comandos del router con el computador mediante un cable al
puerto serie o de consola. Una vez conectado el cable se ingresa al
programa que me permita manipular el router como lo es la aplicación
“HyperTerminal”, para ello se sigue la ruta Programas, Accesorios,
Comunicaciones, HyperTerminal o ingresamos directamente a
HyperTerminal dando doble clic en el acceso directo de dicho programa.
En la pantalla siguiente, se presenta la descripción de la conexión se
ingresa el nombre del equipo que se quiere manipular y se da clic en
siguiente.
Seguidamente se da a conectar detallas de la conexión, se selecciona el
puerto para tener una conexión, en este caso el puerto COM1, ya que
permite que un dispositivo periférico se conecte al computador mediante
un cable, luego de la selección se da clic en “Aceptar”.
Lo siguiente que se procede a realizar es la configuración del puerto, en
donde se recomienda establecer los siguientes valores que se observan en
la imagen ya que funciona perfectamente con el puerto COM1 y se pulsa
clic en “Aceptar”.
Luego de realizar la configuración de la conexión con el router se
procede a encenderlo y esperar que aparezca la secuencia de mensajes de
arranque como se visualiza a continuación. Ésta secuencia permite
confirmar que la comunicación del router con el puerto por medio de la
consola es correcto.
Finalmente cuando la conexión se haya establecido, en el router va
aparecer el prompt Router>, donde se digita el comando “enable” para
pasar a modo Privilegiado, de aquí en adelante ya se procede a la
configuración respectiva de cada router.
1.2.1. Configuración del router de emisión de multidifusión
Comando para ingresar al modo privilegio :
Router> enable
Comando para ingresar al modo de configuración :
Router# configure terminal
Comando para asignar un nombre al dispositivo
Router(config)# hostname ServerStream
Comandos para habilitar multidifusión
ServerStream (config)# ipv6 unicast-routing
ServerStream (config)# ipv6 Multicast-routing
Comando para configurar protocolo de enrutamiento OSPF
ServerStream (config)# ipv6 router ospf 100
ServerStream (config-rtr)# router-id 1.1.1.1
ServerStream (config-rtr)# exit
Comando para configurar la interface virtual o lógica usada para
mantener latente el protocolo de ruteo OSPF, para diagnosticar
conectividad y saber si el protocolo de comunicación es válido.
ServerStream (config)# interface loopback 0
ServerStream (config-if)# ipv6 address 2001:1:1:1::1/64
ServerStream (config-if)# ipv6 pim
ServerStream (config-if)# ipv6 ospf 100 area 0
ServerStream (config-if)# no shutdown
ServerStream (config-if)# exit
Comando para configurar la interface Fast ethernet con acceso a
la WAN y configuración del grupo de multidifusión.
ServerStream (config)# interface serial FastEthernet0/0
ServerStream (config-if)# ipv6 address 2001:10::1/64
ServerStream (config-if)# ipv6 ospf 100 area 0
ServerStream (config-if)# ipv6 pim
ServerStream (config-if)# ipv6 mld join-group
ff7e:240:2001:2:2:2:0:1
ServerStream (config-if)# no shutdown
ServerStream (config-if)# exit
Commando para configurar la interface Fast ethernet con acceso a
la LAN.
ServerStream (config)# interface serial FastEthernet0/1
ServerStream (config-if)# ipv6 address FC00::1/64
ServerStream (config-if)# ipv6 ospf 100 area 0
ServerStream (config-if)# ipv6 pim
ServerStream (config-if)# no shutdown
ServerStream (config-if)# exit
1.2.2. Configuración del router como punto de redirección de la
multidifusión
Comando para ingresar al modo privilegio :
Router> enable
Comando para ingresar al modo de configuración :
Router# configure terminal
Comando para asignar un nombre al dispositivo
Router(config)# hostname PRedireccion
Comandos para habilitar multidifusión
PRedireccion (config)# ipv6 unicast-routing
PRedireccion (config)# ipv6 Multicast-routing
Comando para configurar protocolo de enrutamiento OSPF
PRedireccion (config)# ipv6 router ospf 100
PRedireccion (config-rtr)# router-id 2.2.2.2
PRedireccion (config-rtr)# exit
Comando para configurar la interface virtual o lógica usada para
mantener latente el protocolo de ruteo OSPF, para diagnosticar
conectividad y saber si el protocolo de comunicación es válido.
PRedireccion (config)# interface loopback 0
PRedireccion (config-if)# ipv6 address 2001:2:2:2::2/64
PRedireccion (config-if)# ipv6 pim
PRedireccion (config-if)# ipv6 ospf 100 area 0
PRedireccion (config-if)# no shutdown
PRedireccion (config-if)# exit
Comando para configurar la interface Fast ethernet con acceso al
núcleo de la red.
PRedireccion (config)# interface serial FastEthernet0/0
PRedireccion (config-if)# ipv6 address 2001:20::3/64
PRedireccion (config-if)# ipv6 ospf 100 area 0
PRedireccion (config-if)# ipv6 pim
PRedireccion (config-if)# no shutdown
PRedireccion (config-if)# exit
Commando para configurar la interface Fast ethernet con acceso
al núcleo de la red.
PRedireccion (config)# interface serial FastEthernet0/1
PRedireccion (config-if)# ipv6 address 2001:10::2/64
PRedireccion (config-if)# ipv6 ospf 100 area 0
PRedireccion (config-if)# ipv6 pim
PRedireccion (config-if)# no shutdown
PRedireccion (config-if)# exit
Comando para configurar el punto de redirección de los datos que
el grupo Multicast difunde.
PRedireccion (config)# ipv6 pim rp-address 2001:2:2:2::2
1.2.3. Configuración del router receptor de multidifusión
Comando para ingresar al modo privilegio :
Router> enable
Comando para ingresar al modo de configuración :
Router# configure terminal
Comando para asignar un nombre al dispositivo
Router(config)# hostname RCLIENTE
Comandos para habilitar multidifusión
RCLIENTE (config)# ipv6 unicast-routing
RCLIENTE (config)# ipv6 Multicast-routing
Comando para configurar protocolo de enrutamiento OSPF
RCLIENTE (config)# ipv6 router ospf 100
RCLIENTE (config-rtr)# router-id 3.3.3.3
RCLIENTE (config-rtr)# exit
Comando para configurar la interface virtual o lógica usada para
mantener latente el protocolo de ruteo OSPF, para diagnosticar
conectividad y saber si el protocolo de comunicación es válido.
RCLIENTE (config)# interface loopback 0
RCLIENTE (config-if)# ipv6 address 2001:3:3:3::3/64
RCLIENTE (config-if)# ipv6 pim
RCLIENTE (config-if)# ipv6 ospf 100 area 0
RCLIENTE (config-if)# no shutdown
RCLIENTE (config-if)# exit
Comando para configurar la interface Fast Ethernet con acceso al
núcleo de la red.
RCLIENTE (config)# interface serial FastEthernet0/0
RCLIENTE (config-if)# ipv6 address 2001:20::4/64
RCLIENTE (config-if)# ipv6 ospf 100 area 0
RCLIENTE (config-if)# ipv6 pim
RCLIENTE (config-if)# no shutdown
RCLIENTE (config-if)# exit
Comando para configurar la interface Fast Ethernet con acceso a
la LAN.
RCLIENTE (config)# interface serial FastEthernet0/1
RCLIENTE (config-if)# ipv6 address FC01::1/64
RCLIENTE (config-if)# ipv6 ospf 100 area 0
RCLIENTE (config-if)# ipv6 pim
RCLIENTE(config-if)#ipv6 dhcp server streaming
RCLIENTE (config-if)# no shutdown
RCLIENTE (config-if)# exit
Comando para configurar el router como un servidor de
direcciones DHCP.
RCLIENTE(config)# ipv6 dhcp pool streaming
RCLIENTE(config-dhcp)# prefix-delegation pool streaming-
prefix-new
RCLIENTE(config-dhcp)# exit
RCLIENTE(config)# ipv6 local pool client-prefix-pool FC01::/50
64
2. INSTALACIÓN DE LA APLICACIÓN EMISORA Y RECEPTORA DE
VIDEO VLC
2.1 Instalación de VLC en Linux
A pesar de que VLC es una aplicación que reconoce casi cualquier CODEC
multimedia, es recomendable que antes de proceder a la instalación de dicho
software, se instalen CODEC’s multimedia de diferente soporte, para lo cual se
procede a la ejecución de algunos comandos:
Instalar el meta paquete ubuntu-restricted-extras, el cual es usado para
decodificar archivos de formato MP3.
# sudo apt-get install ubuntu-restricted-extras
Instalar la librería “libdvdcss”, “libdvdcss2” para poder ver DVD's / CD's
originales o comerciales:
# sudo apt-get install libdvdcss2
Finalmente al momento de realizar la instalación del paquete ubuntu-
restricted-extras, se instala la librería libdvdread4 en el directorio
"/usr/share/doc", por lo tanto ahora se debe ejecutar con el siguiente
comando:
# sudo /usr/share/doc/libdvdread4/install-css.sh
La instalación de VLC no es compleja para lo cual se ejecuta los siguientes
comandos:
Accedemos a los repositorios de Video LAN para obtener la versión más
estable:
# sudo add-apt-repository ppa:videolan/stable-daily
Con el siguiente comando actualizamos el sistema operativo
# sudo apt-get update
Seguidamente instalamos la aplicación y actualizamos el plugin
correspondiente para el navegador instalado en la distribución:
# sudo apt-get install vlc browser-plugin-vlc
Una vez realizado los pasos de instalación y configuración ya se puede
contar con la aplicación VLC en Linux en modos grafico tal como se
presenta la siguiente figura.
2.2 Instalación de VLC en Windows
Ingresar a la página oficial de Video LAN
http://www.videolan.org/vlc/releases/2.0.5.html
Se recomienda descargarse la versión que soporte transmisiones y
recepciones en la nueva tecnología Multicast mediante el nuevo
protocolo IPv6 en el sistema operativo Windows, es por ello que se
selecciona la aplicación VLC 2.0.5 pulsando clic en el botón “Descargar
VLC”.
Se abrirá otra ventana donde se agradece por adquirir el producto,
además de presentar un cronometro de tiempo de espera hasta que se
autorice la descarga.
Luego de concluir el tiempo de espera, se visualiza una ventana
emergente la cual muestra la opción de “Guardar” la aplicación o
“Cancelar” la descarga, por ende se da clic en “Guardar archivo”.
Una vez completada la descarga de la aplicación, se busca el lugar donde
se guardó el programa, como por ejemplo: C:\Users\Pame\Downloads y
se da doble clic en el archivo ejecutable para comenzar la instalación.
Windows es un sistema operativo que verifica las acciones antes de
ejecutarlas completamente, por ende previo a la instalación de VLC,
aparece una ventana emergente la cual confirma si se va a llevar a cabo o
no dicha acción, se da clic en la opción si para confirmar la instalación.
Seguido de esta acción se presenta la primera pantalla de la aplicación
VLC donde se debe seleccionar el lenguaje para realizar la instalación, se
selecciona “Español” y se pulsa en “OK”.
Se visualiza la pantalla de bienvenida al asistente de instalación de VLC
media player en la que se muestra un pequeño saludo y se indica que se
debe pulsar en el botón “Siguiente” para continuar o en el botón
“Cancelar” para anular la instalación.
La pantalla consiguiente se refiere a los términos de licencia que se
deben aceptar cuando se instala el programa VLC, si está de acuerdo con
los términos establecidos se da clic en: “Siguiente” o se da clic en
“Cancelar” para anular la instalación.
Posteriormente la pantalla que se presenta es la selección de
componentes donde se marcan o se desmarcan los componentes y las
características de VLC media player 2.0.5 que se desea instalar. Una vez
seleccionado los componentes se da clic en la opción “Siguiente” o se da
clic en “Cancelar” para anular la instalación.
Seguidamente la pantalla que se visualiza es la selección del lugar de
instalación, si se está de acuerdo con el lugar donde se va a instalar se
pulsa clic en el botón “Instalar”, si se desea cambiar la ruta de instalación
se da clic en el botón “Examinar”, finalmente si se desea anular la
instalación se da clic en “Cancelar”.
Lo último a realizar es esperar que el proceso de instalación finalice para
dar clic en la opción “Terminar”.
La aplicación VLC ya se encuentra instalada y lista para realizar
transmisiones y reproducciones de audio y video, se da doble clic en el
acceso directo de VLC ubicado en el escritorio o el listado de programas
de Windows.
3. CONFIGURACIÓN PARA LA EMISIÓN DE VIDEO
La difusión de video en vivo y sobre demanda se la va a realizar con el codec de video
más adecuado y que mejora el rendimiento en la red como lo es el codec H.264. Para
una transmisión en vivo se necesita de dispositivos importantes como lo son: tarjeta
capturadora de video y una filmadora, al ser éstos dispositivos un nuevo hardware para
la distribución de Ubuntu, se necesita configurar un módulo o driver para que reconozca
su conexión mediante puerto USB a la computadora.
3.1 Emisión en vivo desde una filmadora
Mediante la utilización del software VLC instalado en el servidor de streaming,
se procede a la emisión de videos en vivo, con la codificación H.264 para lo cual
se realiza el siguiente proceso:
En el software VLC, en la barra de menús, se pulsa en la pestaña Medio, y
se selecciona la opción Emitir.
Seguidamente se visualiza una ventana con 4 opciones, donde se selecciona
la opción Dispositivo de Captura, seguidamente se escoge la modo de
captura Video for Linux 2, en la selección de dispositivo se elige el nombre
del dispositivo de video de la tarjeta capturadora que el sistema operativo
detecta, por lo general es /dev/video1, después se escoge el nombre del
dispositivo de audio hw:0,0, y se da un clic en Emitir.
En la siguiente ventana se procede a configurar el destino y las opciones de
transcodificación del video, para el destino se elige el protocolo:
RTP/MPEG Transport Stream y se pulsa en el botón Añadir, dicha acción
despliega una ventana, donde se digita la dirección del grupo de Multicast
ff7e:240:2001:2:2:2:0:1, y el puerto 5001. En la opción de transcodificación
se escoge el perfil del CODEC a evaluar, y se pulsa en Siguiente.
Finalmente en la pestaña de configuración de preferencias, se habilita la
opción emitir todas las emisiones elementales y el Tiempo de Vida (TTL)
que será configurado en su máximo valor 255, luego se da clic en emitir.
3.1.1 Configuración del driver Video4Linux
Se va a llevar a cabo la configuración del driver video4linux en la
distribución de Ubuntu mediante una serie de comandos mencionados
posteriormente. Dicho driver es utilizado para hacer un enlace virtual
v4l2loopback entre un dispositivo que capture video externamente como la
filmadora y programas como por ejemplo: WebcamStudio o Mplayer que
permita la salida de video.
Se debe actualizar primero el sistema operativo con los siguientes
comandos:
# sudo apt-get update
Se procede a la instalación de las cabeceras del kernel de la distribución
Ubuntu 12.10 y código fuente del módulo v4l2loopback con los
siguientes comandos:
# sudo apt-get install linux-headers-3.12.0-031200-generic module-
assistant
# sudo apt-get install v4l2loopback-source
Seguidamente se debe preparar el módulo v4l2loopback, para lo cual se
utiliza el module-assistant, este va ayudar a la compilación e instalación
del módulo v4l2loopback mediante la ejecución de los siguientes
comandos:
# sudo m-a prepare
# sudo m-a update
# sudo m-a a-i v4l2loopback-source
Una vez realizado los pasos anteriores, se obtiene el módulo
v4l2loopback, por lo que se debe cargar dicho modulo al Kernel,
utilizando el comando:
# sudo modprobe v4l2loopback
Para verificar si el modulo fue cargado correctamente se digita los
siguientes comandos:
# lsmod | grep v4l2loopback
Existe un comando usado para verificar si durante el proceso de carga no
ha habido errores, dicho comando funciona de manera opcional y es el
siguiente:
# dmesg | grep v4l2loopback
Para verificar si el modulo del dispositivo de video fue isntalado
correctamente en el directorio /dev se digita lo siguiente:
# ls /dev/video*
Se debe configurar el módulo para se cargue automáticamente cuando se
prenda y arranque el sistema operativo Ubuntu, para lo cual se ejecuta el
siguiente comando:
# echo "v4l2loopback" >> /etc/modules
Como el fichero donde se quiere editar no posee los permisos necesarios
de súper usuario saldrá un error, para corregir eso, se debe ejecutar
previamente el siguiente comando:
# sudo chmod 777 /etc/modules
Finalmente se debe reiniciar la máquina para que cargue por defecto el
modulo, digitando el comando:
# sudo reboot
3.2 Emisión sobre demanda desde una webcam
Para llevar a cabo la emisión de videos en vivo con una webcam se realiza los
siguientes pasos:
En el software VLC, en la barra de menús, se pulsa en la pestaña Medio, y
se selecciona la opción Emitir.
Seguidamente se visualiza una ventana con 4 opciones, donde se selecciona
la opción Dispositivo de Captura, seguidamente se escoge la modo de
captura Video for Linux 2, en la selección de dispositivo se elige el nombre
del dispositivo de video de la tarjeta capturadora que el sistema operativo
detecta, por lo general es /dev/video0, después se escoge el nombre del
dispositivo de audio hw:0,0, y se da un clic en Emitir.
En la siguiente ventana se procede a configurar el destino y las opciones de
transcodificación del video, para el destino se elige el protocolo:
RTP/MPEG Transport Stream y se pulsa en el botón Añadir, dicha acción
despliega una ventana, donde se digita la dirección del grupo de Multicast
ff7e:240:2001:2:2:2:0:1, y el puerto 5001. En la opción de transcodificación
se escoge el perfil del CODEC a evaluar, y se pulsa en Siguiente.
Finalmente en la pestaña de configuración de preferencias, se habilita la
opción emitir todas las emisiones elementales y el Tiempo de Vida (TTL)
que será configurado en su máximo valor 255, luego se da clic en emitir.
3.3 Emisión sobre demanda
Mediante la utilización del software VLC instalado en el servidor de streaming,
se procede a la emisión de videos sobre demanda, con la codificación H.264,
realizando los siguientes pasos:
En el software VLC, en la barra de menús, se pulsa en la pestaña Medio, y
se selecciona la opción Emitir.
Seguidamente se visualiza una ventana con 4 opciones, donde se selecciona
la opción Archivo. Esta opción permite añadir el video que se quiere emitir,
con la extensión .MP4 y se da un clic en la opción Emitir.
En la siguiente ventana se procede a configurar el destino y las opciones de
transcodificación del video, para el destino se elige el protocolo:
RTP/MPEG Transport Stream y se pulsa en el botón Añadir, dicha acción
despliega una ventana, donde se digita la dirección del grupo de Multicast
ff7e:240:2001:2:2:2:0:1, y el puerto 5001. En la opción de transcodificación
se escoge el perfil del CODEC a evaluar, y se pulsa en Siguiente.
Finalmente en la pestaña de configuración de preferencias, se habilita la
opción emitir todas las emisiones elementales y el Tiempo de Vida (TTL)
que será configurado en su máximo valor 255, luego se da clic en emitir.
4. RECEPCIÓN DE UN VIDEO EN UN CLIENTE DESDE UNA FUENTE DE
MULTIDIFUSIÓN
Para que un usuario pueda recibir un video desde una fuente emisora se necesita tener
instalado una versión de VLC que soporte las emisiones de video en multidifusión en
IPv6, por tales motivos se utiliza la versión: VLC 2.0.5.
Para la recepción de video en un cliente se realiza los siguientes pasos:
Acceder al software VLC mediante doble clic en el acceso directo de la
aplicación ubicada en una máquina cliente que posee el sistema operativo
Windows.
Se pulsa clic en la pestaña Medio de la barra de menú para desplegar todas las
opciones disponibles, de éstas opciones dar clic en la opción “Abrir volcado de
red” o “Abrir ubicación de red”.
En la ventana que se despliegue, se procede a escribir la dirección del grupo de
Multicast FF7E:240:2001:2:2:2:0:1 del cual se desea recibir el video, dando a
conocer el protocolo RTP y el puerto específico: 5001 para recibir la
transmisión.
GLOSARIO
Arquitectura de Red Sistema funcional compuesto de equipos de transmisión,
programas, protocolos de comunicación y de infraestructuras
físicas o inalámbricas que permite la transmisión de datos entre
diferentes componentes.
Ancho de Banda Cantidad de información o de datos que se puede enviar a través
de una conexión de red en un período de tiempo dado
Benchmark Técnica utilizada para medir el rendimiento de componentes de un
sistema.
Bit Digito del sistema de numeración binaria (0 o 1).
Bitrate Define el número de bits que se transmiten por unidad de tiempo, a
través de un sistema de transmisión digital o entre dos dispositivos
digitales.
Byte Unidad de información como un múltiplo del bit, equivalente a
ocho bits.
Buffer Un buffer (o búfer) es un espacio de memoria, en el que se
almacenan datos para evitar que el programa o recurso que los
requiere, ya sea hardware o software, se quede sin datos durante
una transferencia.
Calidad de Servicio Rendimiento promedio visto por los usuarios de una red de
telefonía o de computadoras.
CODEC Abreviatura de codificador-decodificador. Describe una
especificación desarrollada en software, hardware o una
combinación de ambos, capaz de transformar un archivo con un
flujo de datos o una señal.
Congestión de Red Fenómeno producido cuando a la red (o parte de ella) se le ofrece
más tráfico del que puede cursar.
Compresión Reducción del volumen de datos tratables para representar una
determinada información empleando una menor cantidad de
espacio.
Codificador Circuito combinacional con 2N entradas y N salidas, cuya misión
es presentar en la salida el código binario correspondiente a la
entrada activada.
Crominancia Componente que contiene la información sobre el color de una
señal de vídeo.
Decodificador Circuito combinacional, cuya función es inversa a la del
codificador, esto es, convierte un código binario de entrada de N
bits de entrada y M líneas de salida.
Hardware Hardware se refiere a todas las partes tangibles de un sistema
informático; sus componentes son: eléctricos, electrónicos,
electromecánicos y mecánicos. Son cables, gabinetes o
cajas, periféricos de todo tipo y cualquier otro elemento físico
involucrado.
IOS Sistema Operativo de Interconexión de Redes creado por Cisco
Systems para programar y mantener equipos de interconexión de
redes informáticas como switches (conmutadores) y routers
(enrutadores).
Interconexión La interconexión constituye una técnica que responde a la
necesidad de hacer interactuar las distintas infraestructuras (redes)
con tecnologías y diseños diferentes, con la finalidad que los
usuarios conectados perciban el servicio como si se tratara de una
sola red.
Internet Conjunto descentralizado de redes de comunicación
interconectadas que utilizan la familia de protocolos TCP/IP
LAN Una red de área local, red local o LAN (del inglés Local Área
Network) es la interconexión de
varias computadoras y periféricos. Su extensión está limitada
físicamente a un edificio o a un entorno de 200 metros.
Luminancia En una transmisión de señal de vídeo, la luminancia es la
componente que codifica la información de luminosidad o brillo
que posee una imagen.
Multicast Servicio de red en el cual un único flujo de datos, proveniente de
una determinada fuente, puede ser enviada simultáneamente para
diversos destinatarios
MBONE Desarrollo de los dos primeros experimentos de transmisión de
audio de la IETF (Internet Engineering Task Force) en el que
audio y video son transmitidos en tiempo real desde el lugar de
reunión de la IETF a destinos a lo largo del mundo
Plataforma Sistema que sirve como base para hacer funcionar determinados
módulos de hardware o de software
Protocolo Método establecido entre dos o más ordenadores para intercambiar
datos en Internet.
Rendimiento Medida concreta y de fácil cálculo, que permite saber si una red
está funcionando en forma óptima
Ruteo Función de buscar un camino entre todos los posibles en una red
de paquetes cuyas topologías poseen una gran conectividad.
Streaming Distribución de multimedia a través de una red de computadoras
de manera que el usuario consume el producto al mismo tiempo
que se descarga
Software Software es un equipamiento lógico o soporte lógico de
un sistema informático, que comprende el conjunto de los
componentes lógicos necesarios que hacen posible la realización
de tareas específicas.
Submuestreo de
crominancia y
luminancia
Es la práctica de codificación de imágenes mediante la aplicación
de menos resolución para la información de crominancia que para
la información de luminancia, debido a que el ojo humano es más
sensible a la pérdida de información del brillo que del color.
Telecomunicaciones Estudio y aplicación de la técnica que diseña sistemas que
permitan la comunicación a larga distancia a través de la
transmisión y recepción de señales.
Transcodificación Práctica de conversión de un archivo de audio, video u otro
archivo comprimido de un formato a otro. También se refiere a la
recodificación al mismo formato para alterar la velocidad de bits
del archivo.
Unicast Envío de información desde un único emisor a un único receptor
Videoconferencia Sistema interactivo que permite a varios usuarios mantener una
conversación virtual por medio de la transmisión en tiempo real de
video, sonido y texto a través de Internet.
VoIP Grupo de recursos que hacen posible que la señal de voz viaje a
través de Internet empleando un Protocolo de Internet.
WAN Tipo de red de computadoras capaz de cubrir distancias desde
unos 100 hasta unos 1000 km, proveyendo de servicio a un país o
un continente o cualquier red en la cual no estén en un mismo
edificio todos sus miembros.
BIBLIOGRAFÍA
[1] Thampi, S.M, A Review on P2P Video Streaming (2013, 6 Agosto). [Online].
Disponible en: Http://arxiv.org/ftp/arxiv/papers/1304/1304.1235.pdf
[2] Ibnoulkhatib, G., Sistema de captura de imágenes de Streaming para el
mantenimiento de la continuidad de la señal de TV(UPV-TV) (2013, 8 Agosto).
[Online]. Disponible en:
http://riunet.upv.es/bitstream/handle/10251/14449/PFCghita2.pdf?sequence=1
[3] Apuntes SyT, CODEC (2013, 14 Agosto). [Online]. Disponible en:
http://www.figge.com.ar/index.htm/ApuntesSyT/C%F3decs%20y%20formatos.
[4] Axis Communications AB, Compresión de video (2013, 20 Agosto). [Online].
Disponible en:
http://www.axis.com/es/products/video/about_networkvideo/compression.html
[5] Universidad Nacional de Educación a Distancia, Conversión entre formatos de
video y audio (2013, 28 Agosto). [Online]. Disponible en:
http://ocw.innova.uned.es/mmm3/video_digital/contenidos/pdf/Conversion_entr
e_formatos.pdf
[6] Nicholls, S. y Reina, J., Análisis Estado del Arte Codificación de Video en 3D
(2013, 3 Septiembre). [Online]. Disponible en:
kosmos.upb.edu.co/web/uploads/articulos/(A)_Analisis_del_Estado_del_Arte_d
e_la_Codificacion_de_Video_en_3d_byNTgx.pdf
[7] Flores, G., Conteo de objetos en flujos de video H.264 (2013, 5 Septiembre).
[Online]. Disponible en:
mcyti.izt.uam.mx/archivos/Tesis/Generacion2009/ICR_GustavoFlores.pdf
[8] Salavert, A., Formatos de video digital (2013, 12 Septiembre). [Online].
Disponible en: Http://www.monografias.com/trabajos-pdf4/formatos-video-
digital/formatos-video-digital.pdf
[9] Mundodivx, Configuración del codec XviD (2013, 25 Septiembre). [Online].
Disponible en: http://www.mundodivx.com/codecs/xvid.php
[10] Dixlang.org, Codec de Video (2013, 29 Septiembre). [Online]. Disponible en:
http://www.divxland.org/es/article/8/codecs_de_video#.UtwjaLR77IU
[11] Beltrán, D. y Basañez, L., Técnicas y algoritmos para la adquisición, transmisión
y visualización de escenas 3D (2013, 9 Octubre). [Online]. Disponible en:
http://upcommons.upc.edu/e-prints/bitstream/2117/570/1/IOC-DT-P-2004-
05.pdf
[12] Mailto, A., Theora, detalles técnicos, historia, rendimiento, reproducción,
codificación, edición, streaming (2013, 14 Octubre). [Online]. Disponible en:
Http://centrodeartigos.com/articulos-utiles/article_117805.html
[13] Barbato, L., Draft-barbato-avt-rtp-theora-01, RTP Payload Format for Theora
Encoded Video (2013, 17 Octubre). [Online]. Disponible en:
http://tools.ietf.org/html/draft-barbato-avt-rtp-theora-01
[14] Duarte, E., Que es IPv6 (2013, 21 Octubre). [Online]. Disponible en:
Http://blog.capacityacademy.com/2012/06/14/que-es-IPv6-y-como-nos-afecta/
[15] Deering, S. y Hinden, R., Especificación, protocolo internet, versión 6 (IPv6)
(2013, 29 Octubre). [Online]. Disponible en: Http://www.rfc-es.org/rfc/rfc2460-
es.txt
[16] Duarte, E., Todo sobre IPv6 – Tipos de direcciones (2013, 16 Marzo). [Online].
Disponible en: Http://blog.capacityacademy.com/2013/04/16/cisco-ccna-todo-
sobre-IPv6-tipos-de-direcciones/
[17] Christensson, P., Multicasting (2013, 20 Marzo). [Online]. Disponible en:
Http://www.techterms.com/definition/Multicasting
[18] Hinden, R. y Deering, S., IP Version 6 Addressing Architecture (2013, 26
Noviembre). [Online]. Disponible en: http://www.ietf.org/rfc/rfc2373.txt
[19] Cisco Systems, Implementing IPv6 Multicast (2013, 10 Diciembre). [Online].
Disponible en:
http://www.cisco.com/en/US/docs/ios/IPv6/configuration/guide/ip6-
Multicast.pdf
[20] Sepulveda, P., Modulo 4: Enrutamiento IPv6 (2013, 16 Diciembre). [Online].
Disponible en: http://www.franciscosepulveda.eu/page/10/
[21] Caballero, G., Dispositivo de vídeo virtual con v4l2loopback Debian Wheezy,
(2013, 19 Diciembre). [Online]. Disponible en:
https://lcaballero.wordpress.com/2012/09/11/dispositivo-de-video-virtual-con-
v4l2loopback-en-debian-wheezy/
[22] Bradner, S. y McQuaid, J., RFC 2544, Benchmarking Methodology for Network
Interconnect Devices (2014, 13 Enero). [Online]. Disponible en:
http://www.ietf.org/rfc/rfc2544.txt
[23] Bradner, S., RFC 1242, Benchmarking Terminology for Network
Interconnection Devices (2014, 22 Enero). [Online]. Disponible en:
http://www.ietf.org/rfc/rfc1242.txt
[24] Publicaciones UIT-T, ITU TG 114 (2014, 10 Febrero). [Online]. Disponible en:
http://www.itu.int/rec/T-REC-G.114/es
[25] Publicaciones UIT-T, ITU-T Y.1541 Internet protocol aspects – Quality of
service and network performance (2014, 19 Febrero). [Online]. Disponible en:
http://www.itu.int/rec/T-REC-Y.1541-201112-I/es