Informe de pruebas unitarias y pruebas de sistemascontentiplicer.planetmedia.es/source/E 4.2 Informe de... · 2017-02-02 · Informe de pruebas unitarias y pruebas de sistemas

TSI-090100-2011-19/ Ministerio de Industria, Turismo y Comercio / AVANZA I+D (2011)

SISTEMA DE DISTRIBUCIÓN DE CONTENIDOS Y PUBLICIDAD PERSONALIZADA SOBRE IP

Proyecto CONTENTIPLICER

Informe de pruebas unitarias y pruebas de sistemas

Código E4.2

Responsable ADN STREAM

Autores

PLANET MEDIA, UNIVERSIDAD POLITÉCNICA DE

MADRID, ALCATEL-LUCENT, MISS INNOVAE, ADN

STREAM

Fecha 30/04/2014

Estado final


1

1. Índice de Contenido

1. Índice de Contenido ________________________________________________________ 1

2. Índice de figuras ___________________________________________________________ 2

3. Resumen ejecutivo _________________________________________________________ 3

3.1. Español _______________________________________________________________ 3

4. Resultados de las pruebas ejecutadas ________________________________________ 4

4.1.1. Servidor RTP Streaming (ADN Stream) __________________________________ 4

4.1.2. Detección de instantes para espacios publicitarios (UPM) ____________________ 5

4.1.3. Splicer (ALU) _______________________________________________________ 8

1.1.1. Gestor de campañas publicitarias (ALU) _________________________________ 9

1.1.2. Protección de flujos RTP (UPM) _______________________________________ 11

1.1.3. Reproductor de video (Planet Media Miss Innovae) ________________________ 12

1.1.3.1. Entorno de pruebas. ___________________________________________________________ 12

1.1.3.2. Resultado de pruebas unitarias. __________________________________________________ 13

1.1.3.3. Resultado de pruebas de integración/sistema. _______________________________________ 15

2. Conclusiones ____________________________________________________________ 18


2

2. Índice de figuras

Figura 1 PSNR de las secuencias resultantes de la transmisión de la secuencia de vídeo original aplicando los distintos esquemas de protección (PL-UEP: línea continua, FL-UEP: línea discontinua, EEP: línea a puntos) en distintos escenarios con sus parámetros correspondientes (PER, ABL y overhead debido al FEC empleado) ......................................................................... 12


3

3. Resumen ejecutivo

3.1. Español

El presente documento describe los resultados de la ejecución de las pruebas descritas en el Entregable 4.1, evaluando si los resultados obtenidos se adecúan a lo esperado y describiendo las modificaciones realizadas a los componentes a partir de estos resultados.


4

4. Resultados de las pruebas ejecutadas

4.1.1. Servidor RTP Streaming (ADN Stream)

Se describen a continuación los resultados de las prubas y tests funcionales sobre este modulo del proyecto y modificaciones realizadas para reajustar el funcionamiento en las áreas que lo requiren.

Pruebas de sistemas

Tests de conectividad e intercambio de archivos entre:

1. Módulo de carga de contenidos y codificadores

Se cargan con éxito archivos de peso y formato aleatorio entre MOV, MPEG2, MP4, AVI, 20 MB a 1 GB.

2. Codificadores y streamer.

Se intercambian con éxito archivos de peso y formato MP4, 20 MB a 1 GB.

3. Réplica de contenido en multiples streamers.

Se replican con éxito archivos de peso y formato MP4, 20 MB a 1 GB.

Se reajusta nomenclatura de los archivos para organización de diferentes calidades codificadas sobre un único contenido.

4. Descarga de contenidos desde streamers.

Se descargan con éxito archivos de peso y formato MP4, 20 MB a 1 GB.

Se reajusta bitrate mínimo a “solo audio” para testar capacidad del Sistema en el caso de compatibilidad necesaria con dispositivos móviles.

A efectos de demostrador, la carga, intercambio y descarga desde un único servidor en cada módulo se considera apta.

Pruebas de funcionalidad sobre modulo de gestión o CMS

Tests de proceso:

1.Carga de un archivo en cada formato origen posible, combinando MOV, AVI, MPEG 2, MP4 en bitrate origen 240 kbps, 450 kbps, 750 kbps y 1500 kbps para codificación a MP4 H264 en estos mismos bitrates.

Se considera apta la prueba una vez modificado el formulario de carga para la incorporación de contendos desde URL mediante FTP.

2. Comprobación de proceso de codificación mediante extracción de logs desde zona de codificación en el CMS.

Se considera apta la prueba una vez incorporado código de colores para identificar estados de codificación y divididas secciones en la pantalla de comprobación para distinguir contenidos en proceso, codificados o erroneos. Se provoca corte en proceso de comprobación para testar notificación adecuada de fallo en el Sistema.


5

3. Gestión de base de datos de contenido cargado: búsqueda de contenido específico, filtros de búsqueda.

Se considera apta la prueba una vez ajustada la búsqueda sobre contenidos de título y keywords. Se incorpora filtro de búsqueda por contenido más reciente sin criterio de palabra clave en metainformación.

4. Edición unitaria y en bloque de metainformación de los contenidos desde CMS: prueba de edición y consulta de metadatos.

Se considera apta la prueba una vez incorporado mensaje de “ cambios guardados correctamente” para identificación de la grabación adecuada de las modificaciones realizadas en el formulario.

5. Organización de contenidos en grupos (canales, categorías) para su distribución IP y OTT: pruebas de ordenación y reflejo de los mismos sobre frontend web.

Se considera apta la prueba una vez reajustados fallos de comunicación con frontend web para la reordenación de canales en la interfaz.

4.1.2. Detección de instantes para espacios publicitarios (UPM)

Para evaluar el funcionamiento del módulo de detección de instantes para insertar espacios publicitarios se han utilizado dos secuencias de vídeo, cuyas principales características se resumen a continuación:

Secuencia 1:

Nombre: Microondas.

Duración: 467.080 ms (aproximadamente 8 minutos).

Número de imágenes: 11677.

Resolución (alto × ancho): 576 × 720 píxeles.

Secuencia 2:

Nombre: nqiFcuQxiN.

Duración: 2.967.920 ms (aproximadamente 50 minutos).

Número de imágenes: 74198

Resolución (alto × ancho): 672 × 848 píxeles.

Los parámetros de la aplicación encargada de detectar los instantes adecuados para insertar la publicidad, cuya definición aparece en el entregable E.3.1, se han configurado de la siguiente forma:

Para la secuencia 1:

Commercial length (sec.): 20

Space between commercials (min.): 4

Para la secuencia 2:

Commercial length (sec.): 20

Space between commercials (min.): 20


6

De este modo, se espera detectar un único instante en la secuencia de menor duración (secuencia 1) y dos instantes en la de mayor duración (secuencia 2).

Tras el análisis de ambas secuencias, tal y como se describe en el entregable E.3.2 se han obtenido dos ficheros: el primero de ellos, con extensión txt, contiene los mensajes SCTE-35 que indican tanto la posición como las características (duración) de las pausas publicitarias; el segundo, con extensión xml, contiene los principales datos de la secuencia y los instantes de la secuencia original tras los cuales habrá que insertar la publicidad.

El contenido de estos dos ficheros para ambas secuencias es el siguiente:

Contenido del fichero txt para la secuencia 1:

-scte35cue 1 1000 22111200 20000

Contenido del fichero txt para la secuencia 2:

-scte35cue 1 1000 110779200 20000

-scte35cue 2 1000 220953600 20000

Contenido del fichero xml para la secuencia 1:

<?xml version="1.0"?>

<opencv_storage>

<SeqInfo>

<Name>Microondas</Name>

<NumFrames>11677</NumFrames>

<fps>25</fps>

<Duration>467080</Duration>

</SeqInfo>

<CommertialMoments>

<NumMoments>1</NumMoments>

<Moment1>

<Frame>6142</Frame>

<Time>245680</Time>

</Moment1>

</CommertialMoments>

</opencv_storage>

Contenido del fichero xml para la secuencia 2:

<?xml version="1.0"?>

<opencv_storage>

<SeqInfo>

<Name>nqiFcuQxiN</Name>


7

<NumFrames>74198</NumFrames>

<fps>25</fps>

<Duration>2967920</Duration>

</SeqInfo>

<CommertialMoments>

<NumMoments>2</NumMoments>

<Moment1>

<Frame>30772</Frame>

<Time>1230880<Time>

</Moment1>

<Moment2>

<Frame>60876</Frame>

<Time>2435040</Time>

</Moment2>

</CommertialMoments>

</opencv_storage>

A partir de estos resultados, se ha comprobado que los instantes detectados para insertar las pausas son adecuados, ya que se corresponden con cambios de toma dentro de las secuencias y están espaciados aproximadamente el tiempo indicado en la configuración. A continuación se ilustran los pares de imágenes que delimitan el cambio de toma en el que se incluirá la publicidad en la primera secuencia y los dos cambios de toma en los que se hará lo propio en la segunda secuencia.


8

Por último, se ha analizado el coste computacional del módulo implementado y se han obtenido los siguientes resultados:

Para la secuencia 1: se ha empleado un tiempo de 9,39 segundos.

Para la secuencia 2: se ha empleado un tiempo de 20,43 segundos.

A pesar de que la longitud de segunda secuencia es unas seis veces superior a la de la primera, como era de esperar y debido a que sólo se analizan las imágenes alrededor de los instantes en los que se desea insertar publicidad, el tiempo total de análisis es proporcional a este número de instantes (uno en el caso de la secuencia 1 y dos en el caso de la secuencia 2).

4.1.3. Splicer (ALU)

El plan de pruebas funcionales ha sido básico, centrándose en la personalización del contenido y su integración en un modulo virtualizado para poderse integrar en el entorno del proyecto CONTENTPLICER.

Estas pruebas funcionales forman parte del modulo completo del plan de pruebas del proyecto.


9

1.1.1. Gestor de campañas publicitarias (ALU)

Para realizar las pruebas de personalización de un gestor de campanas publicitarias se ha utilizado una aplicación de referencia que incluye como argumento de solicitud del contenido el identificador del perfil del cliente que realiza la solicitud.


10


11

1.1.2. Protección de flujos RTP (UPM)

Para validar el proceso de generación de protección diseñado se ha comparado nuestro algoritmo, que hemos llamado Packet-Level Unequal Error Protection (PL-UEP) y que, como se ha descrito en otros entregables, funciona a nivel de paquete, con otros esquemas:

Frame-Level Unequal Error Protection (FL-UEP): El primero de ellos realiza la optimización de las matrices de igual forma que nuestra estrategia. Sin embargo, el modelo de distorsión que emplea asume que todos los paquetes dentro de un cuadro son igual de importantes Diremos entonces que todos la protección se lleva a cabo a nivel de cuadro, y no de paquete (la granularidad es por tanto mayor).

Equal Error Protection (EEP): Por otro lado también comparamos nuestro algoritmo de protección desigual inteligente con una estrategia que no emplea ningún modelo de distorsión para ordenar los paquetes del GOP por su importancia. En este esquema, llamado de protección uniforme, todos los paquetes son igualmente relevantes y se protegen de igual manera. Este es el esquema implementado dentro de la mayoría de los sistemas de streaming estándar.

Para las pruebas se ha empleado una secuencia codificada con una estructura de predicción con cuadros B jerárquicos, resolución 720x480, tasa de bit 3 Mbps y tasa de cuadro 25 fps.

Se ha simulado un canal de transmisión empleando un modelo de Gilbert-Elliot con tasas de pérdida de paquetes (PER) de 0.5%, 1.0% y 1.5% y longitudes medias de las ráfagas de pérdidas (ABL) de 4, 8 y 12 paquetes.

Así mismo se han considerado distintos overheads debido a la introducción de redundancia.

En primer lugar se presentan los resultados en términos de Peak Signal-To-Noise Rate (PSNR), como medida de la diferencia de la secuencia resultante con respecto a la original.


12

Figura 1 PSNR de las secuencias resultantes de la transmisión de la secuencia de vídeo original aplicando los distintos esquemas de protección (PL-UEP: línea continua, FL-UEP: línea discontinua, EEP: línea a puntos) en distintos escenarios con sus parámetros correspondientes (PER, ABL y overhead debido al FEC empleado)

Como se puede observar, la estrategia descrita y desarrollada en el marco del proyecto, PL-UEP, obtiene en todos los casos mayores valores de PSNR que las estrategias con las que compite. Esto significa que el impacto de las pérdidas de transmisión es menor empleando dicho esquema que utilizando cualquiera de los otros dos.

Por otro lado, para mostrar cómo se plasma la selección del mecanismo de protección en la percepción que tiene el usuario de la secuencia que se le presenta se han alojado en http://www.gti.ssr.upm.es/~cdm/Contentiplicer/Secuencias_resultantes/ una serie de secuencias resultantes de la acción de las distintas estrategias: PL-UEP, FL-UEP, EEP y sin protección.

1.1.3. Reproductor de video (Planet Media Miss Innovae)

1.1.3.1. Entorno de pruebas.

Los tests fueron realizados en un entorno compuesto básicamente por un ordenador físico (anfitrión) que hospeda tanto la plataforma web con el módulo de reproductor de vídeo, como la máquina virtual correspondiente al módulo de streaming de vídeos. El ordenador anfitrión, Laptop Fujitsu Lifebook A530, tiene las siguientes características relevantes:

Procesador Intel Core I3 M 350 2.27 GHz

http://www.gti.ssr.upm.es/~cdm/Contentiplicer/Secuencias_resultantes/


13

4 GB RAM

Windows 7 - 64 Bits

Software:

o Gestor de máquinas virtuales: Oracle VirtualBox versión 4.3.12 r93733

o Pila web: XAMPP versión 1.8.3

o Herramienta de testing: LoadUIWeb versión 2.99.4592.23

1.1.3.2. Resultado de pruebas unitarias.

Retomando como guía los tests a realizar listados en el documento E.4.1 Informe de plan de pruebas, a continuación se detallan los correspondientes resultados obtenidos.

Interfaz gráfica. En este test se pretende comprobar la adaptabilidad de la interfaz respecto al dispositivo de usuario: PC o Móvil o Tablet.

Adaptabilidad

Landscape Portrait Window resize

PC

Fujitsu Lifebook A530

* * OK

Móvil

Apple iPhone 4

OK OK *

Tablet

Apple iPad 3

OK OK *

Tablet

Apple iPad 4

OK OK *

Google Nexus S OK OK *

OK = Test superado, Fail = Test no superado, * = Test no applicable

Tabla 1.Resultados tests de adaptabilidad nivel unitario.

La siguiente figura muestra una serie de capturas de los test realizados (versión móvil – imagen izquierda, versión PC – imagen derecha).


14

Ilustración 1. Tests de adaptabilidad nivel unitario.

Usabilidad. Este test, centrado en los usuarios, permitirá obtener la evaluación del demostrador en base a las interacciones de usuarios reales con el demostrador. En gran medida, este test evalúa la capacidad del demostrador de cumplir con el propósito para el que fue diseñado y desarrollado. Las métricas empleadas para realizar este test son:

o Exactitud. Número de errores cometidos por los sujetos de prueba y si estos fueron recuperables o no al usar los datos o procedimientos adecuados

o Tiempo requerido para concluir la actividad.

En este test, se solicitó a un grupo de 10 usuarios no expertos en el uso de la plataforma web del proyecto que hicieran uso de la aplicación intuitivamente con sus respectivos terminales móviles o PCs realizando tres tareas: autenticación, gestión de su perfil y visualización de streams. Al final debían manifestar si han obtenido desinterés en la aplicación como resultado del tiempo que han consumido hasta personalizar su perfil.

Usabilidad

No. de usuarios que:

completaron todas las tareas (autenticación, gestión perfil,

visualizar streams)

manifestaron desinterés en la aplicación como resultado

del tiempo invertido

10 0

Tabla 2.Resultados tests de usabilidad nivel unitario.

Rendimiento nivel unitario. Mediante este test, es posible determinar la rapidez de la realización de tareas en condiciones particulares de trabajo. También es útil para verificar atributos de escalabilidad. Para ello, se ha creado un escenario automatizado de pruebas donde 10 usuarios acceden a la plataforma web, se autentican y consultan el menú de streams. La selección y visualización de un stream se reserva para el test a nivel integración/sistema.


15

Los resultados de los tests arrojan resultados satisfactorios dado que las páginas web han sido renderizadas dentro de un tiempo mucho menor a 3 segundos en el navegador de los 10 usuarios haciendo uso de la plataforma de manera simultánea.

Ilustración 2. Tests de rendimiento nivel unitario.

Es apreciable el rendimiento en cuanto al promedio de carga de páginas igual a 271 ms con un máximo de 492 ms. Asimismo, no se reportan errores o warnings en las 160 peticiones web.

1.1.3.3. Resultado de pruebas de integración/sistema.

A nivel de integración/sistema solamente se toman como relevantes los tests referentes al rendimiento, dado que los tests de adaptabilidad y usabilidad son iguales tanto a nivel unitario como de sistema.


16

Rendimiento nivel integración/sistema. En este nivel, se evalúa el conjunto de las funcionalidades, los resultados de los tests, al igual que a nivel unitario, arrojan resultados satisfactorios dado que las páginas web han sido renderizadas en el navegador de los 10 usuarios haciendo uso de la plataforma de manera simultánea dentro de un tiempo mucho menor a 3 segundos establecido como umbral aceptable.

Ilustración 3. Tests de rendimiento nivel integración/sistema .

En comparación con las pruebas a nivel unitario, se puede apreciar un aumento en el tiempo de respuesta, dada la interacción con un módulo adicional y complejo como lo es la máquina virtual que provisiona los streams de vídeo. Esta ligera variación además es comprensible en el sentido de que la máquina anfitriona de las pruebas no tiene unas características excelsas para soportar


17

la carga de trabajo que supone ejecutar la máquina virtual mencionada. No obstante, a pesar de ello, es destacable que el promedio de carga de páginas es de 336 ms con un máximo de 1,04 segundos. Asimismo, no se reportan errores o warnings en las 190 peticiones web.


18

5. Conclusiones

Este documento resume los resultados de los tests de unidad e integración de los distintos componentes del sistema.

El servidor RTP de Streaming ha pasado con éxito la carga de archivos de peso y formato aleatorio entre MOV, MPEG2, MP4, AVI, 20 MB a 1 GB. y ha intercambiado, replicado y descargado con éxito archivos de peso y formato MP4, 20 MB a 1 GB.

A efectos de demostrador, la carga, intercambio y descarga desde un único servidor en cada módulo se considera apta.

Se ha comprobado que el módulo de detección de espacios publicitarios detecta correctamente los instantes para insertar las pausas, ya que se corresponden con cambios de toma dentro de las secuencias y están espaciados aproximadamente el tiempo indicado en la configuración.

Respecto al módulo de splicing, éste ha pasado correctamente las pruebas de generación, instalación y arranque automático de la máquina virtual del demostrador, generación y preparación de contenido primario y personalizado y las pruebas de emisión y personalización del canal con anuncio.

El gestor de campañas publicitarias ha pasado las pruebas de emisión y personalización del canal con anuncio y la reproducción del contenido personalizado del canal con Player iPhone4S, con Player iPad y con Player VLC Windows.

La validación del módulo de Protección de flujos RTP se ha realizado una comparación entre el algoritmo generado (Packet-Level Unequal Error Protection (PL-UEP) ) y distintos algoritmos de generación de protección: Frame-Level Unequal Error Protection (FL-UEP) y Equal Error Protection (EEP). Se ha mostrado que PL-UEP, obtiene en todos los casos mayores valores de PSNR que las estrategias con las que compite.

Respecto del componente de reproducción de vídeo, éste ha pasado correctamente las pruebas de adaptabilidad y usabilidad y de rendimiento a nivel unitario.

Respecto del resultado de las pruebas de rendimiento a nivel integración/sistema en comparación con las pruebas a nivel unitario, se puede apreciar un aumento en el tiempo de respuesta, dada la interacción con un módulo adicional y complejo como lo es la máquina virtual que provisiona los streams de vídeo. Esta ligera variación además es comprensible en el sentido de que la máquina anfitriona de las pruebas no tiene unas características excelsas para soportar la carga de trabajo que supone ejecutar la máquina virtual mencionada. No obstante, a pesar de ello, es destacable que el promedio de carga de páginas es de 336 ms con un máximo de 1,04 segundos. Asimismo, no se reportan errores o warnings en las 190 peticiones web.

Documents

Informe de pruebas unitarias y pruebas de sistemascontentiplicer.planetmedia.es/source/E 4.2 Informe de... · 2017-02-02 · Informe de pruebas unitarias y pruebas de sistemas