Francisco Javier Izquierdo Sebastián_vlc-vod

VideoLan-VoD-01
1
Evaluación de la plataforma VideoLAN como
servidor de Video Bajo Demanda.
Francisco Javier Izquierdo Sebastián.
Transmisión de Datos Multimedia, Master en Ingeniería de Computadores.
Resumen—VideoLAN es una comunidad de desarrollo Open
Source dedicada a la creación de módulos y aplicaciones para
tratamiento de video. Entre dichas aplicaciones figuran VLC
media player y VLS, reproductor y servidor de videos
respectivamente. Sin embargo, en los últimos meses se ha ido
incrementando el número de capacidades de VLC haciéndolo
igual de capaz, si no más, que VLS como servidor de video. De
entre todas las posibilidades que ofrece VLC, este trabajo
pretende evaluar la capacidad de dicho software de ejercer como
servidor de Video bajo Demanda (VoD). Tras una breve
introducción en las características del software y su instalación,
el trabajo se va a centrar en cómo realizar VoD con VLC, se
explicará brevemente el método y las herramientas empleadas
para hacer las mediciones para, a continuación, describir la
prueba real de carga del servidor mediante el incremento en el
número de peticiones y para distintos tipos de carga con el fin de
poder comparar comportamientos.
I. INTRODUCCIÓN
Los servicios de descarga de video por Internet están cada vez
más a la orden del día. Con el fin de obtener su cuota de
mercado en este campo los grupos desarrolladores de software
van creando y publicando sus programas Servidores de
Multimedia. Estos grupos de desarrollo son la mayoría
comerciales por lo que cabe esperar que sus productos den un
rendimiento lo suficientemente bueno como para mantenerse
en el mercado. Sin embargo, entre las comunidades de
desarrollo de software existen aquellas otras de código abierto
y no comerciales, entre las que se encuentra el Proyecto
VideoLAN, de software gratuito para video desarrollado bajo
licencia GNU, según ellos mismos se describen en [1]. Al
mismo tiempo entre los servicios de descarga de video por
Internet figura como caso particular el denominado Video
bajo Demanda en el cual el video no se descarga al completo
en una operación única y previa a cualquier otra
manipulación, sino que se va reproduciendo a medida que van
llegando partes del mismo, las suficientes como para poder ser
interpretado. Este tipo de reproducción directa, a medida que
va llegando el contenido, sin necesidad de esperar la descarga
total del mismo se conoce como streaming. En este sentido y
pasando por alto las características de las redes por las que un
envío debe pasar, el rendimiento del Servidor de VoD debe
cumplir unas expectativas de rendimiento con el fin de ofrecer
una calidad de servicio suficiente al usuario final. Con estas
dos premisas expuestas anteriormente nos ponemos en
situación acerca del objetivo final de este trabajo, que consiste
en realizar una evaluación a la aplicación VLC media player
en su faceta de servidor de VoD, esto es, someter al mismo a
una serie de pruebas de carga con el fin de obtener como
resultado final el índice de peticiones que soportaría en el caso
ideal de que no existieran problemas de red. En este sentido,
las pruebas se realizan en un entorno cerrado puesto que lo
que nos interesa es estudiar la capacidad de la aplicación del
servidor sin las perturbaciones propias de un entorno de red
abierto. Se va a tener en cuenta también el condicionante de
un par de características en lo que a videos servidos se refiere,
a saber, el bitratio de los videos servidos y la popularidad de
los mismos.
El resto del trabajo se organiza de la siguiente manera: en el
siguiente apartado, el II, las características principales del
software VLC así como el proceso de instalación del mismo;
en el III se explica cómo se ha preparado el entorno de
pruebas así como las características de los sistemas hardware
que han intervenido; el apartado IV servirá para explicar
brevemente que herramientas software se han empleado para
la realización de las mediciones; los resultados obtenidos se
repasan en el V y se exponen las conclusiones en el VI. Los
apartados VII y VIII servirán para proponer posibles trabajos
que mejoren y/o completen este y la bibliografía,
respectivamente. Se incluye al final un Anexo I con las
representaciones gráficas de los resultados obtenidos.
II. CARACTERÍSTICAS E INSTALACIÓN DE VLC
VLC media player nació como una aplicación de
manipulación de video, esto es, para la transformación y
visionado de archivos y/o dispositivos de video. Entre otras
características que la hacen interesante figuran la ya citada de
ser de licencia GNU, la existencia de versiones para diversas
plataformas (Linux, MacOS, Windows, etc.) y sobre todo la
capacidad de trabajar con diversos codecs, formatos en la
creación y conversión de los videos, así como protocolos de
envío y recepción de los archivos. Puede funcionar, en su
faceta de servidor que es la que nos ocupa, como servidor de
streaming o realizar envíos unicast o multicast.
Podemos añadir a todas estas características la variedad de
interfaces, además de la predeterminada gráfica de la
VideoLan-VoD-01
aplicación, con las que podemos actuar sobre la aplicación.
Así, se puede emplear tanto desde línea de comandos, como
vía telnet o web.
Igualmente existe la posibilidad de emplear distintos tipos de
filtros así como el volcado de video entre disco y red en un
sentido y en otro. [2]
La obtención del paquete de instalación del software se puede
realizar en la página de descargas de [1], debiendo elegir la
versión adecuada a la plataforma en la que se vaya a instalar.
Figura 1. Página de descarga del sitio web de VideoLAN
En nuestro caso se ha empleado la versión para Windows de
Microsoft (MS). La descarga nos proporciona un ejecutable
autoinstalable con lo que con la simple ejecución del mismo y
tras seleccionar un plan de simples opciones el sofware queda
instalado,
por
omisión,
en
c:\Archivos
de
programa\videolan\vlc.
Figura 2. Instalación de VLC media player
III. PREPARACIÓN DE LA EXPERIENCIA
La prueba se ha llevado a cabo en un aula con 23 PCs
marca Asus dotados de procesador Pentium IV a 3Ghz,
512Mb y tarjeta Ethernet de 100Mbps conectados en red
mediante un Hub de 100Mbps. En todos los ordenadores, con
2
sistema operativo Windows XP SP-2, se ha instalado VLC
respetando uno de ellos como Servidor de VoD y otro como
cliente observador. La función del Servidor era la de ofrecer
una colección de videos bajo el protocolo RTSP mediante un
módulo especial del VLC llamado VLM (VideoLAN Manager)
definido por ellos mismos como “un pequeño gestor para
controlar múltiples streams con una única instancia de VLC”
[2]. La gestión de este módulo solo se puede llevar a cabo vía
telnet o http. En este caso se ha optado por el uso de telnet
debido a que el interfaz http mostró un comportamiento algo
irregular.
Con el fin de poder realizar pruebas con distinto tipo de
carga se han recogido una colección de videos de diferentes
características en lo que a tasa de bits de compresión (bitrate),
duración y tamaño de cuadro se refiere. La elección de
emplear diversos videos es debido a que se pretendía
comprobar que el comportamiento del servidor no iba a ser
igual en el caso de que todos los clientes pidieran el mismo
video, pues se supone que puede ser servido desde caché, o en
su lugar hubiera una diversidad de peticiones, lo que
supondría más carga al servidor al no residir dichas peticiones
en caché. Del mismo modo se pretendía comprobar el
comportamiento si el video demandado era de mayor o menor
tasa de bits; en este caso lo esperado es que con un bitrate
mayor el deterioro en la calidad será mayor a medida que
crezca el número de peticiones, puesto que la sobrecarga que
añade cada nueva petición va en detrimento de la carga útil de
los paquetes. [3]
Para poder evaluar la calidad del software se ha optado por
realizar conjuntamente observaciones subjetivas, desde el
punto de vista del usuario final, en cuanto a la calidad del
video servido; junto con las medidas obtenidas en servidor en
términos de carga del sistema. Como ya se ha indicado, de los
23 ordenadores que intervienen en el experimento había dos
especiales, el servidor de streaming y el que ha sido
denominado cliente observador que ha servido para la
ejecución de una única instancia de VLC como cliente para la
observación subjetiva de la calidad del servicio. Los otros 21
han sido clientes con múltiples peticiones haciendo uso de una
de las características del software como es indicarle que
emplee como interfaz de salida la opción dummy con el fin de
no sobrecargar los clientes con el procesado gráfico.
En cuanto a la observación sobre el servidor hay que
indicar que se han tomado cuatro tipos de medida. El uso de
CPU, donde se espera que el rendimiento de la máquina no se
vea deteriorado hasta alcanzar el 60 ó 70%. El segundo
parámetro medido es el uso de la memoria principal, que en
principio no debe saturarse, aunque si se llega a un número de
peticiones suficientemente elevado sí que llegará a
sobrecargarse, de manera que se tendrá que hacer paginación
y el servicio se degradará considerablemente. La tercera
métrica tomada es la utilización de paginación de memoria a
disco, que si aumenta indicará que la memoria no está siendo
capaz e, igual que en el caso anterior, tendremos un deterioro
VideoLan-VoD-01
del sistema. Estas tres medidas irán acompañadas por el
número de subprocesos creados por el proceso principal de
VLC, lo que nos permitirá saber cuántas peticiones estaba
manejando el servidor. Todas estas medidas se registrarán al
mismo tiempo a intervalos regulares para poder comprobar la
evolución en el tiempo del sistema.
En el lado del servidor se ejecuta VLC indicándole que el
interfaz de acceso a VLM será telnet. Desde línea de comandos
se ejecutará vlc con la siguiente sintaxis.
vlc --ttl 12 –vvv --color -I telnet --telnet-password tdm -rtsp-host cmmf-00.gmmf.upv.es:5554
En esta misma orden se indica, además, que el servicio que
se va a ofrecer será mediante protocolo RTSP (Real Time
Streaming Protocol), así como el puerto que se va a emplear
para su posterior acceso. Igualmente se indica el password que
se va a emplear como usuario administrador y otros
parámetros sin relevancia para el estudio que nos ocupa. La
elección de RTSP como protocolo en las pruebas es debido a
que es un estándar orientado precisamente al streaming según
indica la RFC 2326.
A continuación se accede mediante hiperterminal al
servicio establecido. Aquí se pueden ir creando nuevos
elementos que describirán el tipo de video/s ofrecido/s y el
nombre con el que se obtendrá por la red. Para facilitar la
tarea en las distintas pruebas se crean archivos de
configuración que permiten establecer órdenes que luego
serán cargadas desde la terminal abierta. La sintaxis de los
archivos de configuración para las tres pruebas de carga es la
siguiente:
#VLC Archivo de configuración ratio alto
new gordo vod enabled
setup gordo input concierto.mpg
#VLC Archivo de configuración ratio bajo
new flaco vod enabled
setup flaco input concierto_bajo.mpg
#VLC Archivo de configuración variado
new p1 vod enabled
setup p1 input p1.mpg
new p2 vod enabled
setup p2 input p2.mpg
…
new p17 vod enabled
setup p17 input p17.mpg
Mediante new se crea una nueva instancia de video bajo
demanda y se habilita. Con setup se le indica cual es el
archivo de video que se va a servir bajo ese nombre en la url
correspondiente. Se pueden añadir tantos pares de líneas como
3
videos se deseen ofrecer, asignándole, eso sí, a cada uno un
nombre diferente.
La orden para cargar el fichero de configuración es bien
simple: load archivo_conf
Hay que decir que el interfaz telnet es bastante parco en
cuanto a mensajes de error. Cuando algo no funciona, en
efecto, se obtiene un mensaje de error, pero cuyo contenido no
es nada explícito, con lo que hay que revisar bien los nombres
de los archivos y su path si no están en el mismo directorio.
En los clientes y también desde línea de comandos se
lanzarán instancias paulatinamente hasta llegar a la sobrecarga
en el servidor, con el consecuente deterioro en la calidad del
video observado en el cliente observador. La posibilidad de
ejecutar los clientes desde línea de comandes facilita la tarea
puesto que se puede incluir en procesos por lotes. La sintaxis
es bien sencilla:
vlc rtsp://cmmf-00.gmmf.upv.es:5554/gordo --intf=dummy
Para cada carga de trabajo este es el proceso a seguir. A
partir de aquí será cuestión de tomar las medidas y observar
los resultados.
IV. HERRAMIENTAS EMPLEADAS EN LA MEDICIÓN
Como se ha expresado anteriormente se ha realizado
simultáneamente una observación de la calidad del video
servido junto a una medición en el servidor de ciertos valores
de rendimiento. Para esto último se ha empleado la
herramienta proporcionada por MS con sus sistemas Windows
llamada “Monitor de rendimiento” (perfmon.exe). Según se
describe en [4] esta utilidad es capaz de registrar todo tipo de
medidas de la mayoría de los componentes del sistema.
De manera predeterminada el monitor de rendimiento nos
muestra una gráfica con los contadores por defecto. Para
nuestra experiencia creamos una nueva entrada en el árbol de
Registros y alertas de rendimiento, bajo la rama Registros de
contador.
Figura 3. Consola de Monitor de Rendimiento
En esta nueva entrada en la consola se han establecido una
serie de valores a registrar que son:
“\\CMMF-00\Memoria\% de bytes asignados en uso”
“\\CMMF-00\Memoria\Páginas/s”
“\\CMMF-00\Procesador(_Total)\%
de
tiempo
de
VideoLan-VoD-01
procesador”
"\\CMMF-00\Proceso(vlc)\Número
de
subprocesos
(subprocesos)"
Con los datos obtenidos en cada una de las pruebas Monitor
de Rendimiento crea un fichero en formato .tsv (valores
separados por tabulador), y con el fin de facilitar el análisis de
los datos mediante una manera gráfica, se recurre al uso de
MS Excel para crear gráficos de línea que nos relacionen el
número de peticiones con los diversos indicadores.
Estas medidas serán contrastadas con las observaciones
subjetivas para poder obtener una conclusión.
V. RESULTADOS DE LAS MEDICIONES
El conjunto de medidas tomadas se deben clasificar en tres
grupos: Peticiones del mismo video de bitrate alto, peticiones
del mismo video de bitrate bajo y peticiones indiscriminadas
de videos con diferente tasa de bits. En cada una de estos tipos
de carga se han hecho varias pruebas, obteniendo para cada
una de ellas valores similares. Aquí se expone una muestra
representativa de cada uno de los tipos.
Las gráficas que se van a presentar en el anexo I tienen en
común los datos representados. Se muestra en el eje de
abscisas el número de subprocesos que ejecuta el proceso
VLC, pero de manera implícita también indica el tiempo,
puesto que los valores representados se han ido tomando en
intervalos de 15 segundos. En cuanto a las curvas
representadas cabe indicar para su mejor comprensión que en
el caso de los valores porcentuales de los usos de memoria y
de CPU se han multiplicado por 10 con el fin de apreciar
mejor su evolución. Esto se ha hecho así por la diferencia en
los órdenes de magnitud con el otro valor, el indicador de
Páginas por segundo.
He aquí la explicación para cada uno de los grupos de
pruebas.
- Único video bitrate alto:
Se observa que por cada petición realizada al servidor el
número de subprocesos se incrementa en tres. Esta
característica se cumple en todas las pruebas.
En este caso concreto se aprecia que mientras el incremento
de peticiones es lento y ligero, los valores de las medidas se
mantienen estables. Al comenzar una demanda mayor se
empieza a sobrecargar la memoria, lo que lleva a la
realización de más cantidad de paginado. No obstante no es
hasta alcanzar las 45 peticiones cuando el nivel de sobrecarga,
y por tanto el índice de paginado aumentan desmesuradamente
lo que lleva a un uso de CPU que alcanza el 60%. En este
punto es cuando se aprecia que el servicio de VoD deja de
funcionar de manera correcta.
- Único video bitrate bajo:
Podemos observar gráficamente las medidas tomadas para
este caso en la figura 2 del anexo I.
Este caso es similar al anterior, salvo que el número de
4
streams servidos antes de llegar a una degradación del servicio
es mayor. En este caso se alcanza la cifra de 60 peticiones
atendidas, unas pocas más que en el caso del video de tasa de
bits superior y es el indicador del uso de CPU el que coincide
con la apreciación subjetiva de error, de donde se puede
deducir que no es suficiente confiar en solo un parámetro para
llegar a conclusiones claras.
- Diversos videos de bitrates variados:
Para el caso de la prueba de carga con videos de diferente
tasa de bits los resultados se muestran en la figura 3 del anexo
I.
En este caso existe una considerable diferencia. Debido a
que los videos demandados son diferentes y, aunque algunos
de ellos se repitan en diferentes momentos, se observa un
incremento rápido del índice de paginación, lo que produce a
su vez un incremento del uso de CPU. El servicio se degrada
al alcanzar un número de peticiones bastante bajo,
concretamente 7.
VI. CONCLUSIONES
Por todo lo expuesto anteriormente, pero con las reservas
de haber hecho las pruebas con las limitaciones de hardware,
software y tiempo, se concluye que el software estudiado no
reúne la suficiente entidad como para hacer un uso comercial
del mismo. En concreto hay dos factores que llevan a dicha
conclusión.
Principalmente el resultado de la prueba en si, es decir, el
número de peticiones soportadas por el servidor es
insuficiente para un uso masivo como servidor de VoD, si
bien es cierto que no se han hecho pruebas en hardware más
potente. Es evidente que si pensamos en un servicio de cierta
relevancia no nos podemos limitar al uso de un simple
ordenador personal.
El segundo factor que desaconseja el uso de dicho software
es, al menos desde el punto de vista del usuario de entorno
gráfico, la falta de “amigabilidad” de la aplicación. Es verdad
que VLC tiene infinidad de opciones, utilidades, filtros y
parámetros con sus respectivos usos, pero también es cierto
que el empleo de los mismos resulta ser poco user friendly y
poco apoyado por la redacción de sus manuales. Sin embargo,
y aún no siendo el objetivo de este trabajo, si que parece muy
útil como herramienta de captura de video y transformación
entre formatos.
VII. TRABAJOS FUTUROS
Resultaría interesante realizar pruebas similares midiendo
mediante alguna herramienta más completa valores más
objetivos en cuanto a la calidad final de servicio. En concreto,
parece conveniente obtener datos sobre Latencia o Jitter, y ver
como afecta la carga del servidor a estos valores.
Las medidas tomadas lo han sido sobre una máquina que si
bien es un modelo bastante actual no se el adecuado para
realizar este tipo de funciones, por lo que se podría volver a
VideoLan-VoD-01
5
VIII. BIBLIOGRAFÍA
realizar este estudio, o uno mejorado, empleando como
servidor una máquina más potente.
En este trabajo no se ha comparado el software estudiado
con otros servidores existentes, cosa que podría realizarse con
el tiempo y los medios necesarios, con el fin de tener una
referencia con respecto a software comercial, por ejemplo.
[1] “The VideoLAN Project”, http://www.videolan.org
[2] “VideoLAN Documentation”,
http://www.videolan.org/doc
[3] M. Spasojevic, N. Bhatti y S. Roy. Understanding the
Impact of Diverse Streaming Workloads on End-User Quality
of Service. In 10th Iternational Workshop on Web Caching
and Content Distribution. 2005.
[4] “The Windows NT Performance Monitor”,
http://windowsitpro.com/articles/print.cfm?articleid=285
Anexo I – Representaciones gráficas
Video de alto bitrate
1800
1600
1400
1200
1000
800
600
400
7
7
1
5
6
1
5
7
1
5
7
1
5
7
1
5
8
1
5
7
1
5
7
1
5
7
1
4
2
1
4
2
1
2
7
1
1
5
1
1
5
1
1
2
1
1
2
1
1
2
6
1
1
0
0
3
1
2
8
2
5
2
5
2
5
2
2
2
2
1
9
1
9
1
9
1
9
1
9
1
9
1
9
1
6
1
3
1
0
7
1
0
7
0
6
200
Subprocesos de VLC
% de Memoria en uso
Páginas de memoria por segundo
% de tiempo de procesador
Vi d e o d e b a j o bi t r a t e
1200
1000
800
600
400
200
0
Subpr oc e s os de V LC
%de Memor i a en uso
Pági nas de memor i a por segundo
%de ti empo de pr ocesador
V i de o de bi t r a t e v a r i a do
1200
1000
800
600
400
200
0
13 13 13 13 13 13 13 13 13 16 22 16 16 22 13 25 22 25 22 22 22 25 31 34 34 37 40 40 40 40 40 45 43 46 43 42 46 47 49 49 49 46 40 40 37 34 34 28 31 31 31 25 22 22 19 16 13 13 13 13 13 10 10
Sub p r o c e s o s de V LC
% de M emor i a en uso
P ági nas de memor i a por segundo
% de t i empo de pr oc esador
7
7
7
7