Download implementación en java/c++ del estándar de codificación h.264

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)
INGENIERO EN INFORMÁTICA
PROYECTO FIN DE CARRERA
IMPLEMENTACIÓN EN JAVA/C++
DEL ESTÁNDAR DE CODIFICACIÓN
H.264
Autora: Rocío Vega Alonso
Madrid, septiembre de 2009
AUTORIZADA LA ENTREGA PARA LA ALUMNA
Rocío Vega Alonso
DIRECTOR DE PROYECTO
Juan Antonio Pérez-Campanero Atanasio
Fdo:
Fecha:
VISTO BUENO DEL COORDINADOR DE PROYECTOS
David Contreras Bárcena
Fdo:
Fecha:
En primer lugar y sí por ser más importante, a la gente que me ha ayudado a
cumplir este objetivo en mi vida, bien académicamente, bien por ser un apoyo en los
momentos más difíciles (gracias a Dios no muchos), bien por hacerme más fuerte.
Y la mejor manera de dar las gracias es estando aquí en este día, pensando en
que es un nuevo comienzo en el que cuento con ellos.
Benevolencia no quiere decir tolerancia de lo ruin, o conformidad con lo inepto, sino
VOLUNTAD DE BIEN.
Antonio Machado
III
RESUMEN
IV
Se trata del estudio del estándar de alta definición H.264 así como de sus aplicaciones e
implementaciones basadas en software libre desarrolladas en C++ o en JAVA.
El estándar H.264, es una norma que define un códec de vídeo de alta compresión,
capaz de proporcionar una buena calidad de imagen con bitrates notablemente inferiores a los
estándares previos. Actualmente está implementado por empresas y organizaciones para
aplicaciones propias, por ello se puede llegar a conseguir el reto que se propusieron desde las
instituciones que lo desarrollaron, ITU-T Video Coding Experts Group (VCEG) e ISO Motion
Picture Experts Group (MPEG): Conseguir un estándar de codificación de video
internacional eficiente.
En primer lugar, se han explicado conceptos generales del mundo de la imagen digital,
tales como la percepción de color, la descomposición del mismo en los diferentes sistemas, la
codificación en todas sus fases y el término códec.
A continuación se ha realizado un repaso de las unidades que se definen en el estándar,
tales como los diferentes componentes del color de una imagen: luma, array que se refiere a la
intensidad con la que se da un color (luminiscencia) y chroma, 2 arrays que definen los
diferentes valores de crominancia (Cr para rojo y Cb para azul). Asimismo se habla también de
los diferentes perfiles de la aplicación. También se ha especificado los tipos de división en
macrobloques, unidad con la que se conoce a una agrupación de bits que puede variar en este
estándar, dependiendo de la forma en la que se procesen los datos.
De esto precisamente se habla en los siguientes apartados, del proceso de codificación
del video, que se compone de las siguientes fases:
•
Predicción. Que puede realizarse de dos maneras, intra o inter, dependiendo de si la
predicción se basa en el espacio o en el tiempo.
•
Transformación: para lo que se ha explicado la DCT (Transformada del Coseno
Discreto).
V
•
Cuantificación: proceso que se encuentra dentro de la DCT.
•
Codificación basada en entropía: para lo que se ha expuesto las soluciones que plantea
el estándar:
•
o
Variable-Length Coding (VLC)
o
Context-based adaptive variable length coding (CAVLC)
o
Codificación Aritmética y Adaptativa basada en el contexto (CABAC)
Filtros: explicado debido a que es una de las ventajas del estándar: el suavizado de
bloques.
A continuación se ha decidido realizar un estudio sobre comparativas, en primer lugar
de estándares previos, y en segundo lugar de algunas implementaciones del estándar, libres o
no, en cuanto al rendimiento y otras características.
Para dar un enfoque más práctico, se han escogido dos aplicaciones con este estándar
que se hayan implementado con éxito, para ello se ha elegido la videovigilancia y la
videoconferencia, explicando para cada una de ellas, el por qué resulta ventajoso el H.264 frente
a los otros.
Ya para finalizar, se ha realizado una implementación por la metodología Extreme
Programming utilizando la librería FFMPEG y las aplicaciones que vienen con ella, así como
las opciones que tienen para el vídeo y demás. Se trata de una aplicación sencilla que compara
dos imágenes de video de dos protocolos diferentes, realiza una conversión de formatos o
muestra las características de un determinado video.
En mi opinión, el H.264 es un firme candidato a convertirse en el más extendido,
aunque aún queden unas fases por definir, como puede ser la propia codificación, debido a la
cantidad de aplicaciones que están realizando su implementación propia.
Por último se ha realizado un plan de Gestión de Proyecto que se adjunta en el Anexo
A.
VI
ABSTRACT
VII
This project deals with a research about the H.264 high definition standard, as well as
its applications and implementations based on free software, and developed in C++ or JAVA.
The H.264 standard is a regulation which defines a high compression video codec that
can provide a good image quality with considerably lower bit rates than the previous standards.
Nowadays, it is implemented by companies and organizations for their own
applications. That is why the challenge from the original designer groups, ITU-T Video Coding
Experts Group (VCEG) and ISO Motion Picture Experts Group (MPEG), is possible to be
achieved: the creation of an efficient and international video codec.
A review of the units defined on the standard is going to be introduced, such as the
different components of a color in a given image: luma, array related to the intensity of a color
(luminance) and chroma, two arrays which define the different chrominance values (Cr for red,
and Cb for blue). The types of division have also been specified in macroblocks, which refers to
a group of bits that can vary on this standard depending on the way to process the data.
Those issues are just treated in the following sections based on the video codification
process, which consists of the following stages:
•
Prediction. It can be made in two different ways, intra or inter, depending on the
prediction was based on the space or on the time.
•
Transformation. It is based on the Discrete Cosine Transform (or DCT).
•
Quantization. This processed is included in the DCT.
•
Entropy-based codification. For which the proposed solution in the standard are
introduced.
o
Variable-Length Coding (VLC).
o
Context-based adaptive variable length coding (CAVLC).
o
Context-based Adaptive Binary Arithmetic Coding (CABAC).
VIII
•
Filtering. Explained, because the block smooth is one of the standard advantages.
Then, a research about comparatives between previous standards, and also between
different implementations, which can be free or not, related to several characteristics such as
performance and others.
In order to obtain a practical point of view, two successfully implemented applications
of this standard were chosen: videovigilance and videoconference. The reasons of their
advantages with respect to other implementations without using H.264 are explained in detail.
Finally, an implementation based on Extreme Programming methodology has been
developed, using FFMPEG library and its applications, as well as the options for video and
other possibilities. It is a simple application that compares two different video images from two
different protocols, makes a format conversion or shows the characteristics of a certain video.
In addition, the different profiles of the applications are mentioned.
Regarding H.2654 standard, in my opinion, it is a solid candidate to become the most
extended video standard, despite the fact that there still are some stages to be defined, such as
the proper codification. That could be due to the huge number of different applications which
have their own implementations.
At the end of the document, a Project Management Plan was developed, and it is
introduced in the Appendix A.
IX
ÍNDICE DE CONTENIDOS
X
Implementación en Java/C++ del Estándar de Video H.264
1
Introducción y descripción del proyecto. .............................................................. 7
1.1
Introducción. ................................................................................................. 7
1.2
Descripción del Proyecto............................................................................. 13
2
Motivación y justificación. .................................................................................. 16
3
Objetivos del Proyecto. ....................................................................................... 18
4
5
3.1
Objetivos técnicos. ...................................................................................... 18
3.2
Objetivos del Proyecto. ............................................................................... 18
Fundamentos de Codificación ............................................................................. 21
4.1.1
Codificación de Fuente........................................................................... 21
4.1.2
Cuantificación. ....................................................................................... 23
4.1.3
. La Imagen Digital: Percepción y Representación. ............................... 24
4.1.4
Transformadas: visión global de la imagen. ........................................... 27
Especificaciones del Estándar de vídeo H.264. ................................................... 32
5.1
Introducción al estándar. ............................................................................. 32
5.2
Componentes H.264 .................................................................................... 34
5.2.1
Características de diseño. ....................................................................... 35
5.2.2
Partición en bloques: .............................................................................. 36
5.2.3
Luma en H.264: ...................................................................................... 36
5.2.4
Chroma en H.264 ................................................................................... 37
5.2.5
Formatos de datos en H.264 ................................................................... 38
5.2.6
Perfiles.................................................................................................... 39
5.3
Conceptos aplicados. ................................................................................... 41
5.3.1
El codificador ......................................................................................... 42
5.3.2
El decodificador ..................................................................................... 44
5.4
Especificaciones del Estándar. .................................................................... 45
5.4.1
Predicción. .............................................................................................. 45
5.4.2
Transformación y cuantificación ............................................................ 57
5.4.3
Codificación entrópica. .......................................................................... 78
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
1
Implementación en Java/C++ del Estándar de Video H.264
5.4.4
5.5
6
7
Filtro ....................................................................................................... 95
Comparativa del estándar. ......................................................................... 105
5.5.1
H264 vs Otros....................................................................................... 105
5.5.2
Diferentes implementaciones de H264................................................. 107
Aplicaciones de H.264. ..................................................................................... 116
6.1
Videoconferencia....................................................................................... 116
6.2
Videovigilancia. ........................................................................................ 117
Análisis conceptual de la aplicación. ................................................................ 120
7.1
Descripción de los recursos utilizados. ..................................................... 120
7.1.1
Introducción. ........................................................................................ 120
7.1.2
Componentes utilizados. ...................................................................... 120
7.2
Metodología. ............................................................................................. 122
7.3
Planificación y Requisitos. ........................................................................ 124
7.4
Diseño........................................................................................................ 126
8
Conclusiones y trabajos futuros. ....................................................................... 127
9
Bibliografía........................................................................................................ 129
10
Anexo I: Plan de gestión del Proyecto. ......................................................... 131
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
2
Implementación en Java/C++ del Estándar de Video H.264
ÍNDICE DE FIGURAS Y TABLAS
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
3
Implementación en Java/C++ del Estándar de Video H.264
FIGURAS
FIGURA 1: áreas del proyecto. ................................................................................................... 13
FIGURA 2: proceso codificación................................................................................................ 23
FIGURA 3: medidas de las prestaciones..................................................................................... 24
FIGURA 4: figuras filtrado paso bajo. ........................................................................................ 31
FIGURA 5: figuras filtrado paso alto. ......................................................................................... 31
FIGURA 6: muestras luma y chroma 4:2:0................................................................................. 39
FIGURA 7: figura proceso codificación y descodificación. ....................................................... 41
FIGURA 8: diagrama de flujo del codificador H.264. ................................................................ 42
FIGURA 9: diagrama de flujo del decodificador H.264. ............................................................ 44
FIGURA 10: diagrama de flujo del predicción intra H.264. ....................................................... 45
FIGURA 11: diagrama de flujo del predicción inter H.264. ....................................................... 46
FIGURA 12: bloques adyacentes y correspondientes variables en H.264. ................................. 48
FIGURA 13: macrobloques en una imagen residual................................................................... 49
FIGURA 14: predicción e interpolación en H.264...................................................................... 50
FIGURA 15: interpolación luma de un cuarto de muestra. ......................................................... 51
FIGURA 16: tipos de movimiento en la predicción H.264. ........................................................ 53
ECUACION 1: DCT análisis para 8 coeficientes. ...................................................................... 58
ECUACION 2: DCT síntesis para 8 coeficientes. ...................................................................... 58
FIGURA 17: las muestras afectadas por un límite vertical y horizontal que separa un
macrobloque P y uno Q ............................................................................................................... 99
FIGURA 18: desarrollo de los estándares de MPEG y de ITU-T ............................................. 105
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
4
Implementación en Java/C++ del Estándar de Video H.264
FIGURA 19: esquema de metodología Extrem Programming.................................................. 123
FIGURA 20: esquema fases de la metodología Extrem Programming. .................................... 123
TABLAS
Tabla 1: OBJ-001- Estudio de Procesado de imagen Digital ...................................................... 19
Tabla 2: OBJ-002- Estudio del Estándar H.264 .......................................................................... 19
Tabla 3: OBJ-003- Estudio de las Aplicaciones.......................................................................... 20
Tabla 4: OBJ-004- Comparativa con otros estándares ................................................................ 20
Tabla 5: Comparativa entre estándares previo y H.264 ............................................................ 106
Tabla 6: RQ-01 Comparar videos. ............................................................................................ 124
Tabla 7: RQ-02 Convertir videos. ............................................................................................. 125
Tabla 8: RQ-03 Mostrar características de un vídeo. ................................................................ 125
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
5
Implementación en Java/C++ del Estándar de Video H.264
MEMORIA
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
6
Implementación en Java/C++ del Estándar de Video H.264
1 Introducción y descripción del proyecto.
1.1 Introducción.
Se trata del estudio del estándar de alta definición H.264 así como de sus aplicaciones e
implementaciones basadas en software libre desarrolladas en C++ o en JAVA. Asimismo se
tratará de realizar una comparativa mediante una aplicación desarrollada en Java.
El estándar H.264, es una norma que define un códec de vídeo de alta compresión,
capaz de proporcionar una buena calidad de imagen con bitrate notablemente inferiores a los
estándares previos. Es una realidad, que estos estándares se utilizan cada vez con mayor
frecuencia en aplicaciones que precisan de rapidez y a la vez poca pérdida de calidad de imagen.
Entre otras cosas, gracias a la flexibilidad de H.264, ya ha sido implementado y
utilizado en distintas áreas como el DVD de alta definición, (Blu-ray entre otros), la difusión de
vídeo digital, desde streaming a la TV de alta definición, el almacenamiento de vídeo en línea
(como YouTube), la telefonía móvil 3G y en software como QuickTime, Flash y el sistema
operativo de Apple, MacOS X, así como en consolas de videojuegos como PlayStation 3.
Con tantas aplicaciones de interés implementando el estándar, se puede llegar a
conseguir el reto que se propusieron desde los grupos que lo desarrollaron, ITU-T Video Coding
Experts Group (VCEG) e ISO Motion Picture Experts Group (MPEG):
Conseguir un estándar de codificación de video internacional eficiente.
Como resultado de las reuniones salieron dos estándares idénticos: ISO MPEG4 Part 10
de MPEG4 e ITU-T H.264. El nombre oficial del estándar es Advanced Video Coding (AVC),
aunque es más conocido como H.264.
La elección de un buen códec de video puede influir, de hecho influye, en la transmisión
y en el almacenamiento de video digital. Por ello es tan importante la eficiencia y la calidad.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
7
Implementación en Java/C++ del Estándar de Video H.264
Actualmente parecen ser conceptos contradictorios, ya que para videos de Alta
Definición (High Definition, HD en adelante) se penaliza en exceso la transmisión y el
almacenamiento, y para conseguir unas tasas de bits bajas, la calidad se ve claramente resentida.
Cuando se trata de aplicaciones en Tiempo Real este hecho es aún más crítico. Este estándar ha
conseguido muy buenos resultados en cuanto a equilibrar ambos aspectos y, además, define
diferentes perfiles para poder adaptar la calidad y la tasa de bits dependiendo de la aplicación.
Este proyecto abarca diferentes ámbitos de creciente interés en el mundo de la
informática. Por ello, en un primer capítulo, se hablará de cómo influyen en la elección de un
estándar de codificación los diversos factores que actualmente se presentan a la hora de realizar
streaming de vídeo.
El streaming se define como el flujo de datos que produce un archivo cuando se
visualiza desde un servidor sin necesidad de descarga. En concreto se hablará del streaming de
video para poder exponer los antecedentes y la metodología de la videoconferencia en internet.
De una manera resumida, se dirá que los datos que se obtienen del servidor se
almacenan en un buffer para su posterior visualización mediante un reproductor.
Como reseña histórica, se puede introducir que la aparición del streaming tuvo lugar
aproximadamente en 1995 cuando se lanzó por primera vez RealAudio 1.0 que consistía en la
reproducción de audio.
A continuación se describirá el funcionamiento de un proceso de streaming corriente. El
proceso se inicia desde el cliente, conectándose con el servidor que comienza a mandar el
fichero. Para el envío se utiliza un códec que comprime el archivo que viaja sobre un protocolo
ligero (UTP, RTP…). En el cliente se constituye un buffer que almacena la información que va
llegando. Una vez que el buffer contiene una parte del archivo comienza la reproducción del
mismo, al mismo tiempo que continúa con la descarga. Cabe destacar la importancia de la
sincronización en este tipo de sistemas, ya que los programas no reproducirán el archivo si este
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
8
Implementación en Java/C++ del Estándar de Video H.264
no está, y, si la conexión varía su retardo, se podrá reproducir el contenido del buffer, según el
protocolo. Si se sufren demasiados retardos, el buffer se vacía y la ejecución del archivo
también se cortaría hasta que se normalizase.
nor
Parece evidente que el streaming es una técnica muy utilizada en Internet debido a la
facilidad y rapidez con la que se puede reproducir contenido multimedia sin la necesidad de la
descarga. Algunos datos que secundan esta afirmación, pueden ser
ser los siguientes
Esto afirmó que Youtube era la mayor web de reproducción
ión de video mediante
streaming y actualmente es la tercera página web más visitada hasta el momento, después de
Google y Microsoft (datos de alexa.com).
Uno de los usos más comerciales
comerciales del streaming es la videoconferencia. Se podría decir
que la videoconferencia tiene dos ámbitos, el empresarial y el uso corriente orientado a las
comunicaciones en usuarios domésticos. En ambos casos se puede utilizar, por ahorro de ancho
de banda sinn disminución de la calidad, el protocolo H.264.
En un entorno empresarial, la videoconferencia aporta numerosos beneficios, tales como
c
el ahorro de tiempo, desplazamiento y estancia de directivos,, gerentes o empleados, que son
consecuencia directa de las comunicaciones internas y externas, es decir, entre miembros de la
misma empresa o con proveedores y clientes. Además, las posibilidades y funciones que ofrece
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
9
Implementación en Java/C++ del Estándar de Video H.264
la videoconferencia son numerosas, como por ejemplo, ofrece la posibilidad de realizar
reuniones y cursos de la organización en tiempo real con equipos sencillos, parecidos o, incluso,
iguales a los actuales y extendidos teléfonos IP. A todo lo anterior, se suma la posibilidad que
ofrece la tecnología actual de realizar multivideoconferencia, es decir, conferencias con más de
dos participantes. Se necesitaría una unidad que coordinase y sincronizase los diferentes
participantes. Como se mencionaba anteriormente, numerosas empresas implantan los servicios
de videoconferencia ofreciendo rapidez, fiabilidad y calidad, aportando como solución equipos
que soporten el protocolo H.264. Un ejemplo es la empresa Techo Trend que ofrece, con dicho
protocolo, una línea RDSI con un ancho de banda de 384 Kbps una calidad óptima.
Entre los diferentes problemas que se encuentra al implantar una videoconferencia en un
entorno doméstico, el principal se remite a que la línea por excelencia es el ADSL, y ésta no es
una tecnología pensada para la transmisión de vídeo o audio en tiempo real, ya que la
conectividad que proporciona es asimétrica, sin ancho de banda reservado ni calidad de servicio.
Es por esto que, si se junta el streaming de vídeo, un protocolo de alta definición, con las
particularidades del ADSL, surge la necesidad de utilizar un protocolo de Tiempo Real y por
tanto ligero.
Las aplicaciones web que mezclan texto con vídeo y con distintos contenidos
multimedia, son conocidas como webconferencia. La conferencia por internet, es de alguna
manera, la forma de llamar a la conferencia sobre IP, eso abarca:
•
La audioconferencia, comprendida como diferentes redes integradas que usan VoIP
en redes IP privadas para transmitir voz.
•
La dataconferencia, presentaciones simultáneas, pizarra electrónica, control remoto
de aplicaciones…
•
La webconferencia que comprende mensajería instantánea, chat, VoIP y
videoconferencia, dataconferencia… sobre el protocolo IP.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
10
Implementación en Java/C++ del Estándar de Video H.264
Como se ha mencionado anteriormente, existen diferentes modos de videoconferencia,
clasificándolas según el contenido de los datos a enviar a través de la red. Sin embargo, existe
otra clasificación, según el número de destinatarios y la forma de envío de los datos a los
mismos:
•
Videoconferencia de grupos.
•
Videoconferencia individual.
•
Multivideoconferencia (Comunicación de más de dos puntos).
•
Videomonitorización (Envío de imágenes distantes en tiempo real).
•
Videostreaming o Webcast (Difusión de contenidos audiovisuales a
muchos receptores a través de Internet).
Para todo ello, se mencionó con anterioridad la importancia de una buena compresión
de los datos y del uso de un protocolo ligero (UDP) que permita la sincronización y el envío
efectivo de los paquetes, en detrimento de la fiabilidad de los mismos.
Este protocolo surge de la necesidad que crea la red IP, al tener unas características que
no la hacen apropiada para la transmisión de grandes cantidades de datos. Se trata de un
protocolo de Tiempo Real, que aporta las soluciones a las carencias IP ante la transmisión de
datos que estén sujetos a limitaciones de tiempo real, como pide ser el vídeo, el audio, etc…. La
función principal es implementar los números de secuencia de paquetes IP para reconstruir
dicha secuencia, aun cuando durante el trayecto, el orden haya sido alterado.
Un protocolo RT permite:
•
identificar el tipo de información transmitida.
•
agregarle marcadores temporales y números de secuencia a la información
transmitida.
•
controlar la llegada de los paquetes a destino.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
11
Implementación en Java/C++ del Estándar de Video H.264
Además, los paquetes de difusión múltiple pueden utilizar RTP para encaminar
conversaciones a múltiples destinatarios.
Este protocolo suele ir acompañado de su correspondiente protocolo de control, éste
suele denominarse RTCP y realiza el control de flujo RTP que permite transmitir información
básica sobre los participantes de la sesión y la calidad de servicio. Éste se basa en transmisiones
periódicas de paquetes de control que realizan todos los participantes de la sesión.
RTCP es un protocolo de control asociado con RTP, que mide los desempeños pero no
ofrece garantías. Para esto, se debe utilizar un protocolo de reserva como RSVP o asegurarse de
que los enlaces de comunicación utilizados sean de proporción correcta en relación con el uso
que se hace de ellos.
Como anteriormente se ha comentado, el RTP permite la administración de flujos
multimedia sobre IP. La información sobre la sincronización y la numeración se encuentra en la
cabecera de los datagramas UDP sobre IP. No se realiza compresión ni cifrado, puesto que ello
dependerá del algoritmo de compresión realizado en un paso previo a la transmisión de los
datos. Cabe destacar que se utiliza un canal RTP por tipo de flujo, por ejemplo para vídeo y
audio se utilizarían canales diferentes.
Los protocolos RTP y RTCP se encuentran en un nivel de aplicación y utilizan los
protocolos de transporte subyacentes TCP o UDP. Pero el uso de RTP/RTCP generalmente se
lleva a cabo por encima de UDP. RTP y RTCP utilizan tanto el método de difusión individual
(punto a punto) como el método de difusión múltiple (multipunto). Utilizan puertos separados
de un par de puertos. RTP utiliza el puerto par y RTCP el puerto impar inmediatamente
superior.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
12
Implementación en Java/C++ del Estándar de Video H.264
1.2 Descripción del Proyecto
Dado que la implementación
implementación de un estándar como tal, es mayor que el propósito de un
proyecto, se intentará comprender y utilizar las características del mismo de una manera práctica
y visual.
Por todo ello se ha dividido el proyecto en cuatro áreas que posteriormente
posterior
se unirá
mostrando los datos de trasmisión y reproducción de un vídeo en HD comprimido con este
estándar.
FIGURA 1: áreas del proyecto.
Ahora se procederá a explicar cada área de manera independiente.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
13
Implementación en Java/C++ del Estándar de Video H.264
Estudio de la imagen digital:
En un primer momento se estudiará la imagen digital en aspectos
como la percepción del color, el filtrado, la representación, la compresión y transmisión y la
reconstrucción, siempre haciendo hincapié en las características utilizadas o implementadas en
el H.264. Asimismo se establecerán los diferentes tipos de características con pros y contras,
para las que no se definan o queden a elección del desarrollador.
Estudio del Códec H.264:
Con la especificación del estándar se tratará de realizar un
estudio del mismo y resumirlo de una manera clara para los lectores. Se sacará tanto las
características definidas por éste, como las que se dejan en libre elección, para al final entender
los motivos de que existan numerosas aplicaciones de un estándar que no son compatibles en
muchos casos.
Comparativa de estándares de HD:
Como se ha visto en el apartado introductorio, existe muchas
aplicaciones de streaming y de videoconferencia, así como un mercado amplio que elige ver los
archivos de video en formatos de HD. En un apartado de este proyecto se tratará de repasar los
principales estándares que compiten con H.264 y cómo éstos se especializan en diferentes
aplicaciones del mercado.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
14
Implementación en Java/C++ del Estándar de Video H.264
Aplicaciones que lo implementen:
Por último pero no menos importante se recorrerán las diferentes
aplicaciones realizadas que implementen o utilicen implementaciones libres de este estándar.
Posteriormente se estudiará una librería llamada FFMPEG que lo utiliza y es una de las más
utilizadas actualmente mediante una aplicación que enseñe además, sus posibilidades.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
15
Implementación en Java/C++ del Estándar de Video H.264
2 Motivación y justificación.
justificación.
Actualmente
todos
los
dispositivos
hardware
usados
en
sistemas
de
multivideoconferencia, videoteléfonos, seguridad, telemedicina etc.… son compatibles con el
estándar en el que se basa este proyecto: el H.264. En apartados anteriores se ha hablado de la
importancia que hoy en día se le da a la transmisión de vídeo y a la velocidad en que esto
ocurre.
Asimismo, numeras empresas utilizan e sus desarrollos de videovigilancia, cámaras de
alta definición, y el protocolo elegido para ello es el H.264, lo que sugiere que se es muy
admisible el consumo de ancho de banda para la calidad que se obtiene de su implementación.
Los dispositivos sobre los que se realiza la transmisión, tienen una implementación
hardware del estándar. Sin embargo, si se dispone de una aplicación software como cliente,
como puede ser una herramienta de colaboración, apoyarse en una librería que encapsule la
codificación del estándar H.264 es necesario para garantizar y maximizar las prestaciones del
sistema.
Se encuentra que las implementaciones del estándar para los clientes son privadas y
desarrolladas únicamente por los fabricantes de los dispositivos que lo implementan, sin
embargo la especificación del mismo es abierta, aunque requiera la utilización de patentes.
Por tanto, las circunstancias que se presentaron con anterioridad (auge del streaming,
auge de las comunicaciones por videoconferencia, …) unido a las ventajas que presenta el
estándar, la motivación del proyecto se puede indicar como:
Encontrar alguna implementación libre eficiente y encapsularla de manera que
sea fácil utilizarla en cualquier plataforma.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
16
Implementación en Java/C++ del Estándar de Video H.264
No obstante, el desarrollo de una librería que implemente el estándar de vídeo, queda
fuera del ámbito de un Proyecto Final de Carrera por su envergadura.
Sin embargo, el estudio de las implementaciones existentes, la descripción detallada del
estándar y de las posibles aplicaciones, pueden dar pie a una primera aproximación que permita,
en un futuro, la utilización de estas librerías para optimizarlas y cumplir las necesidades
anteriores.
En segundo lugar, el motivo principal de la elección de este proyecto es el aprender de
una manera más profunda, el funcionamiento de la codificación y transmisión de vídeo que se
ha visto a lo largo de la carrera.
Tanto el tema relacionado con la codificación de imágenes o de información digital en
general, como la transmisión y recepción de los datos, son mencionados a lo largo de la carrera,
no obstante, el estudio del estándar requiere un esfuerzo adicional, ya que el enfoque que se le
da principalmente, está más relacionado con las aplicaciones de señales digitales (frecuencias,
muestreo, captura…) que al protocolo propiamente dicho.
Además de lo anterior, la especificación del estándar posee un lenguaje y unos
conceptos que requieren un estudio adicional.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
17
Implementación en Java/C++ del Estándar de Video H.264
3 Objetivos del Proyecto.
3.1 Objetivos técnicos.
técnicos.
A continuación se realizará una especificación de los objetivos que se van a
implementar en este Proyecto Fin de Carrera.
•
Objetivos técnicos: ser capaz de entender, escribir y emitir conclusiones de las
comparaciones entre estándares de codificación de vídeo de alta definición.
Asimismo mostrar dichas características para justificar dichas características
mediante las aplicaciones que los implementen.
3.2 Objetivos del Proyecto.
A continuación se presentan unas tablas que especifican los objetivos del proyecto.
Mediante estos objetivos se podrá establecer el éxito o fracaso de la aplicación y la
finalización del mismo. Además nos permitirá marcar mejor el desarrollo de las fases del
mismo. Estos objetivos están escritos según un intento de estandarización de documentación de
Durán y Bernárdez.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
18
Implementación en Java/C++ del Estándar de Video H.264
Tabla 1: OBJ-001- Estudio de Procesado de imagen Digital
OBJ-001
Estudio de Procesado de imagen Digital
Versión
Septiembre 2009 (Primera versión)
Autor
Rocío Vega Alonso
Fuente
•
Apuntes de Universidad Carlos III de Madrid de Telecomunicaciones.
•
Apuntes de Informática de Universidad Pontificia de Comillas.
•
Otras fuentes diversas como papers, doctorados… que se citan en la
bibliografía.
Descripción
Entender la adquisición y el procesamiento de las imágenes digitales y del vídeo
digital, así como su almacenamiento y posterior procesado.
Comentarios
Ninguno
Tabla 2: OBJ-002- Estudio del Estándar H.264
OBJ-002
Estudio del Estándar H.264
Versión
Septiembre 2009 (Primera versión)
Autor
Rocío Vega Alonso
Fuente
•
http://www.itu.int/rec/T-REC-H.264
•
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?c
snumber=43058.
•
VCodex.
Descripción
Leer el estándar y entender, con la mayor profundidad posible, las características y
funcionamiento del mismo, realizando un resumen detallado.
Comentarios
Ninguno
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
19
Implementación en Java/C++ del Estándar de Video H.264
Tabla 3: OBJ-003- Estudio de las Aplicaciones
OBJ-003
Estudio de las Aplicaciones
Versión
Septiembre 2009 (Primera versión)
Autor
Rocío Vega Alonso
Fuente
•
http://ffmpeg.org/
•
Otras fuentes diversas como papers, doctorados… que se citan en la
bibliografía.
Descripción
Realizar un estudio práctico de las aplicaciones principales que, en la actualidad,
implementan este estándar y son utilizados en el mercado actual.
Comentarios
Ninguno
Tabla 4: OBJ-004- Comparativa con otros estándares
OBJ-004
Comparativa con otros estándares
Versión
Septiembre 2009 (Primera versión)
Autor
Rocío Vega Alonso
Descripción
Realizar, mediante un estudio, una comparativa sobre otros estándares en
diferentes ámbitos y aplicaciones prácticas.
Subobjetivos
Comentarios
•
Realizar el estudio de las diferentes especificaciones de los estándares.
•
(opcional) Demostrar las conclusiones mediante una aplicación práctica
que los aplique en diferentes ámbitos.
Ninguno
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
20
Implementación en Java/C++ del Estándar de Video H.264
4 Fundamentos de Codificación
Codificación es la transformación de una señal para su transmisión o almacenamiento.
Hay tres clases:
•
Codificación de Canal o de Control de Errores: fiabilidad de la transmisión por
canales ruidosos.
4.1.1
•
Codificación de fuente: formato digital inteligente.
•
Shannon: los dos tipos pueden diseñarse independientemente.
Codificación de Fuente.
Fuente.
El objetivo de la codificación de una fuente es reducir el número de bits para representar
la información reducir el bitrate lo máximo posible. Existen dos tipos de Codificación de
Fuente:
Sin pérdidas:
•
La señal original puede reconstruirse a partir de la codificada.
•
Un ejemplo: codificación por entropía, que se explicará a continuación.
Con pérdidas:
•
Única alternativa para señales analógicas (cuantificación).
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
21
Implementación en Java/C++ del Estándar de Video H.264
•
Objetivo: representar digital y eficientemente la señal original de forma que pueda
recuperarse con la mayor fidelidad posible.
•
Permite la transmisión fiable por canales ruidosos.
ruidosos
Como se ha dicho anteriormente,
anteriormente se explicará brevemente qué es eso de la codificación
por entropía. Claude Shannon definió en su artículo A Mathematical Theory of Information el
concepto “cantidad de características distintivas” se necesitan (de media) para codificar algo,
algo
cualquier cosa. Shannon determinó que la cantidad de información (medida en bits) necesaria
para codificar un dato era de:
log(1/p)
donde p es la probabilidad de que aparezcaa ese dato y log es el
logaritmo en base 2.
Si se quiere saber la cantidad de bits que se necesitará (de media) para codificar un
elemento del conjunto tan sólo se tendrá que multiplicar la información necesaria para codificar
cada elemento por la probabilidad
probabil
de que ese elemento aparezca.
La entropía es una cota inferior para cualquier codificación.
codificación. O dicho de otro modo,
necesitas al menos esa cantidad de bits para codificar ese conjunto de opciones. Con menos bits
perderás información.
Actualmente existee una creciente
c
utilización de sistemas de comunicaciones de tasa
variable, y dado que a actividad de la fuente puede sufrir grandes variaciones,, para los sistemas
de tasa fija aparece
parece la necesidad de un "buffer",
"buffer" un control
ontrol de "overflow" y "underflow".
"underflow"
Algunos ejemplos son: código Morse o códigos "runlength".
"runlength"
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
22
Implementación en Java/C++ del Estándar de Video H.264
4.1.2
Cuantificación.
Cuantificación.
Se denomina cuantificación a la representación digital de las señales analógicas.
Se define muestreo como la cantidad de veces que medimos el valor de la señal en un
periodo de tiempo (usualmente en 1 segundo). Según el teorema de Nyquist-Shannon la
cantidad de veces que debemos medir una señal para no perder información debe de ser al
menos el doble de la frecuencia máxima que alcanza dicha señal. Por su parte, la cuantificación
es el número de símbolos que utilizamos para guardar una medida de una señal. Para guardar la
medida la codificamos con un conjunto de bits. A mayor número de bits empleados para
guardar la medida mayor exactitud.
FIGURA 2: proceso codificación
Algunas medidas de las prestaciones:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
23
Implementación en Java/C++ del Estándar de Video H.264
FIGURA 3: medidas de las prestaciones.
Dentro de los diferentes tipos de cuantificación merece la pena mencionar a los que
posteriormente se hará referencia en la especificación del estándar:
Cuantificación adaptativa: se adaptan las propiedades del cuantificador al nivel de la
señal de entrada:
Codificación diferencial (predictiva): La codificación diferencial será tanto más eficaz
cuanto más redundante sea la seña ya que se trata de obtener una estimación de la muestra a
cuantificar a partir de las anteriores.
Predecibilidad ⇔Redundancia
4.1.3
. La Imagen
Imagen Digital: Percepción y Representación.
En el fondo del ojo existen millones de células especializadas en detectar las longitudes
de onda procedentes de nuestro entorno. Estas células, principalmente los conos y los
bastoncillos, recogen las diferentes partes del espectro de luz solar y las transforman en
impulsos eléctricos, que son enviados luego al cerebro a través de los nervios ópticos, siendo
éste el encargado de crear la sensación del color.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
24
Implementación en Java/C++ del Estándar de Video H.264
En realidad el mecanismo de mezcla y producción de colores llevados a cabo por la
reflexión de la luz sobre un cuerpo, es diferente al de la obtención de colores por mezcla directa
de rayos de luz, como ocurre con el del monitor de un ordenador.
Los colores obtenidos directamente naturalmente por descomposición de la luz solar o
artificialmente mediante focos emisores de luz de una
longitud de onda determinada se denominan colores
aditivos.
No es necesaria la unión de todas las
longitudes del espectro visible para obtener el blanco,
ya que si se mezcla solo rojo, verde y azul se
obtendrá el mismo resultado. Es por esto por lo que
estos colores son denominados colores primarios,
porque la suma de los tres produce el blanco. Además, todos los colores del espectro pueden ser
obtenidos a partir de ellos.
Otra forma de obtener el color es a sustractiva, donde los colores primarios son otros,
concretamente el cian, el magenta y el amarillo. A partir de estos tres colores se puede obtener
casi todos los demás, salvo el blanco y el negro.
Cuando la luz solar choca contra la superficie de un objeto, éste absorbe diferentes
longitudes de onda de su espectro total, mientras que
refleja otras. Estas longitudes de onda reflejadas son
precisamente las causantes de los colores de los
objetos, colores que por ser producidos por filtrado de
longitudes de onda se denominan colores sustractivos.
Este fenómeno es el que se produce en pintura, donde
el color final de una zona va a depender de las
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
25
Implementación en Java/C++ del Estándar de Video H.264
longitudes de onda de la luz incidente reflejadas por los pigmentos de color de la misma.
Bien, pues a partir de las mezclas de los colores aditivos se obtiene una matriz
bidimensional de pequeñas unidades llamadas píxeles que componen la imagen digital. Cada
píxel contiene la información acerca de un punto o de una pequeña región de la escena, de modo
que el número de píxeles es finito y el contenido de cada píxel está cuantificado. Digamos que
tratamos de incluir la menor cantidad y tamaño de datos de representación para la imagen
digital, pero obteniendo un grado de calidad. Esta calidad es medible, desde el punto de vista
humano, si nuestro ojo no distingue los píxeles individuales de la imagen al completo.
Este sistema descrito en el anterior párrafo, es lo que conocemos como sistema RGB, en
el que todos los colores que se visualizan, por ejemplo, en el monitor están en función de las
cantidades de rojo, verde y azul utilizadas. Por ello, para representar un color en el sistema RGB
se le asigna un valor entre 0 y 255 (notación decimal) o entre 00 y FF (notación hexadecimal)
para cada uno de los componentes rojo, verde y azul que lo forman. Los valores más altos de
RGB corresponden a una cantidad mayor de luz blanca. Por consiguiente, cuantos más altos son
los valores RGB, más claros son los colores.
De esta forma, un color cualquiera vendrá representado en el sistema RGB mediante la
sintaxis decimal (R,G,B) o mediante la sintaxis hexadecimal #RRGGBB. El color rojo puro, por
ejemplo, se especificará como (255,0,0) en notación RGB decimal y #FF0000 en notación RGB
hexadecimal, mientras que el color rosa claro dado en notación decimal por (252,165,253) se
corresponde con el color hexadecimal #FCA5FD.
El Modelo HSI, otro tipo diferente al RGB, de color es un modelo de coordenadas 3D
en el que cada color está representado por un punto único. HSI se corresponde con el acrónimo:
•
TONO (H hue): longitud de onda dominante del color, es decir, el color puro del
que se parte.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
26
Implementación en Java/C++ del Estándar de Video H.264
•
SATURACIÓN (S): pureza del color. Grado del color puro que ha de mezclarse con
blanco.
•
4.1.4
INTENSIDAD (I): Brillo del color.
Transformadas: visión global de la imagen.
En cuanto al procesado de las imágenes, cabe destacar que existen distintos tipos de
abordar el problema:
•
Operaciones punto a punto
•
Operaciones en entorno local
•
Operaciones globales: transformadas.
Transformaciones punto a punto
Las transformaciones punto a punto son operaciones que trabajan con los pixeles como
objetos individuales; se aplica una función que depende únicamente del valor del pixel. Con
imágenes digitales se pueden emplear tablas que reasignen el tono de gris de cada pixel: se
conocen como LUTs (Look-up tables). Veamos un ejemplo sencillo:
Otro ejemplo es el logaritmo, que se suele aplicar como la función que se expresa a
continuación para evitar operandos negativos o nulos y sirve para visualizar mejor las zonas
oscuras de las imágenes con rango dinámico muy grande (no es un aumento del brillo).
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
27
Implementación en Java/C++ del Estándar de Video H.264
g(x,y)=log (1+|f(x,y)|)
Otro Tipo de punto a punto son las transformaciones mediante histograma y mediante
mapas de bits. El histograma mide la densidad de probabilidad de tonos de gris. Un ejemplo de
aplicación de esto es la mejora automática del contraste, se realiza una igualación de
histogramas con la que se pretende que todos los niveles de gris tengan la misma frecuencia de
aparición, es decir, un histograma plano y luego se usa el histograma como LUT.
Transformaciones de entorno local
Son aquellas que, además de emplear el valor del pixel toman información de los
píxeles vecinos o entorno para calcular la salida. Los entornos suelen ser subimágenes
cuadradas de tamaño impar Las operaciones a realizar en cada entorno pueden ser:
• Lineales: El resultado de un filtrado lineal en un entorno puede verse como una
combinación lineal de los valores de los píxeles del entorno, una convolución. Esta operación se
suele especificar mediante una máscara, que es una matriz de números que recoge los
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
28
Implementación en Java/C++ del Estándar de Video H.264
coeficientes de la combinación lineal (respuesta impulsional bidimensional). Existen diferentes
máscaras para cada una de las finalidades que se requieran.
•
Máscara de suavizado: realizan un promediado de los píxeles vecinos,
dando un resultado de desenfoque.
•
Máscaras de detección de bordes: extraen o realzan los bordes de la imagen
• No lineales: necesaria implementación particular
•
Máscaras no lineales: mediana para filtrar ruido impulsivo.
Transformaciones de entrono global o mediante transformadas.
Es en este último punto en el que se centra el estándar, intentando comprender la
imagen como un total y aprovechando características que afectan al todo para una compresión
más eficaz. A continuación se enumeran los tipos de transformadas que existen:
•
Transformadas unitarias: se utilizan matrices unitarias, aquellas en las que sus vectores
columna forman una base ortonormal:
UH U = I, U–1 = UH, (UH = UT , caso real)
Son transformadas unitarias (Tx=Ux; x= UHTx) la DFT, la DCT, la Tr. Hadamar y
Haar.
o
Transformada de Fourier bidimensional
o
Transformada de Coseno (Seno) Discreto (DCT)
o
Transformada de Hadamard (Haar)
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
29
Implementación en Java/C++ del Estándar de Video H.264
•
Otras transformadas
o
Transformada Karhunen-Loeve
Karhunen
o
Transformada Wavelet
o
Transformada de Radon
Transformada de Fourier bidimensional
bidim
Se utiliza para el análisis:
Y para la síntesis:
El filtrado paso bajo se realiza para resaltar la silueta o las superficies homogéneas:
homogéneas
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
30
Implementación en Java/C++ del Estándar de Video H.264
FIGURA 4: figuras filtrado paso bajo.
Sin embargo, el filtrado de paso alto se corresponde con los bordes de los objetos:
FIGURA 5: figuras filtrado paso alto.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
31
Implementación en Java/C++ del Estándar de Video H.264
5 Especificaciones del Estándar de vídeo
vídeo H.264.
H.264.
5.1 Introducción al estándar.
Para comenzar, diremos que el H.264 definirá posteriormente un códec. El término
códec, es una abreviatura de Compresor-Descompresor. Es un programa que realiza una
transformación de un archivo de datos, particionado éste y codificando el flujo de datos
simétricamente a la recuperación del mimo. Un códec puede servir en distintos estados de la
información y con diferentes funcionalidades. Puede utilizarse en la transmisión de un archivo o
en el almacenaje, para comprimir propiamente, para cifrar o para modificar su formato. En
realidad, el uso más habitual será el de comprimir el archivo aunque e añaden diferentes
funciones.
Existen
diferentes
clasificaciones
de
códecs
debido
al
gran
número
de
implementaciones que circulan y a su amplia funcionalidad y tipo de archivos específicos a
tratar. Una primera clasificación podría ser los códecs que, para conseguir el tamaño más
pequeño posible, provocan pérdidas de información frente a los que no, aunque cabe destacar,
que la mayor parte de las aplicaciones de estos programas se requiere que esa pérdida se realice.
Un ejemplo, en los archivos multimedia que se envían por la web, para un amento de calidad
casi imperceptible para el ser humano, el tamaño de los archivos consume una gran cantidad de
ancho de banda y produce un incremento considerable de retardos en procesamiento y
transmisión. Los códecs que no pierden información en el proceso de compresión, suelen
emplearse cuando la calidad del archivo multimedia enviado por la web, se requiere para un
tratamiento posterior de dicho archivo.
Como un caso particular, en las videoconferencias, el archivo a tratar contiene tanto
vídeo como audio y, por tanto, se necesita utilizar alguna forma de sincronizarlos, bien mediante
Software, bien mediante códigos o referencias en el propio archivo. Esto produce que en la
transmisión y tratamiento del archivo, en realidad se produzcan tres flujos, o tres streams que
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
32
Implementación en Java/C++ del Estándar de Video H.264
deben ser tratados como uno para las aplicaciones de reproducción finales. Este proceso es el
que se necesita controlar mediante un determinado formato de video.
Un formato de video regula que tanto el video y el audio como la sincronización entre
ambos sean reproducibles para que el usuario final comprenda el archivo multimedia, y en
concreto la conferencia, como uno.
El problema fundamental que se concreta cuando hablamos de códecs de vídeo, trata en
torno a los siguientes puntos:
•
El tamaño de los archivos de vídeo y la capacidad de proceso de un ordenador
doméstico.
•
El procesamiento para el envío puede ser complejo debido al tamaño del
archivo.
La sincronización de la videoconferencia se enfrenta a:
•
Sincronización audio y vídeo.
•
Sincronización entre pares de usuarios.
•
Establecimiento de control en las multivideoconferencias.
•
Retardos en la red y en el proceso de los datos.
•
Consumo de ancho de banda frente a aprovechamiento de los búferes origen y
destino.
•
Calibración entre calidad y rapidez.
•
El tamaño de los archivos suele ser grande y tanto la transmisión como el
almacenamiento puede llevar al equipo al límite de su capacidad de proceso.
La mayor parte de los códecs comprimen en el momento de la transmisión y se
descomprimen en el momento de la visualización, en tiempo real y de manera transparente al
usuario.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
33
Implementación en Java/C++ del Estándar de Video H.264
Los algoritmos para desarrollar los códecs tratan de equilibrar los siguientes factores:
•
Calidad de video.
•
La cantidad de datos necesario para representarlo (conocida como tasa de bits).
•
La complejidad propia del algoritmo.
•
La robustez frente a las pérdidas de datos y errores.
•
La facilidad de edición.
•
La posibilidad de acceder directamente a los frames, y otros factores.
Como se dijo en la introducción, existen dos estándares idénticos: ISO MPEG4 Parte o
actualización 10 de MPEG4 y el ITU-T H.264, aunque el que se utiliza en el proyecto: H.264.
En consonancia con los estándares previos, H.264 no define explícitamente un CODEC
como tal, sino que especifica la sintaxis de un bitstream comprimido y un decodificador,
además de una serie de métodos para codificar organizados por perfiles de los que se hablará
posteriormente.
5.2 Componentes H.264
A continuación se realizará un resumen de lo que se puede ver en el estándar en cuanto
a las características generales, la organización de los datos y en definitiva los primeros
apartados del estándar que no entran en el proceso de transformación de la información.
En la introducción, el estándar refleja el carácter genérico de la recomendación o
especificación. En este caso se refiere a que da servicio a un amplio rango de aplicaciones
bitrates, resoluciones, calidades y servicios propiamente.
Una de las orientaciones del estándar, entre muchas otras, es para mejorar las
comunicaciones en tiempo real. Para desarrollar la especificación se han mantenido
requerimientos de las aplicaciones típicas, desarrollando elementos algorítmicos e integrándolos
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
34
Implementación en Java/C++ del Estándar de Video H.264
en la sintaxis que se define, por ello, esta especificación facilita el intercambio de información
entre aplicaciones.
Un perfil es un subconjunto de sintaxis completa de un flujo de bits (bitstream, en
adelante) que son especificados en el estándar. Cada nivel especifica un conjunto de límites de
los valores que pueden tomar los elementos sintácticos.
Dentro de los límites impuestos por la sintaxis de un perfil dado, es posible que varíe
bastante la ejecución del codificador o decodificador, dependiendo de los valores tomados por
los elementos sintácticos como el tamaño del bitstream.
Para tratar con este tipo de variaciones, se definieron una serie de niveles para cada
perfil. Un nivel es un conjunto específico de restricciones impuestas sobre los elementos
sintácticos (definiciones)
en cuanto al tamaño del bitstream. Son límites de valores o
restricciones sobre las combinaciones aritméticas de valores (por ejemplo el ancho del dibujo
multiplicado por la altura por el número de dibujos decodificados por segundo.
En conformidad con el estándar, el contenido del video codificado usa una sintaxis
común. Para lograr un subconjunto de sintaxis completa, flags, parámetros y otros elementos
sintácticos son incluidos en el bitstream que luego señaliza la presencia o ausencia de los
propios elementos sintácticos.
5.2.1
Características de diseño.
La representación que se especifica en la sintaxis está diseñada para permitir una
capacidad de compresión alta manteniendo una calidad alta. La manera típica del algoritmo es
una codificación con pérdidas de información, salvo que se realice una compresión de calidad
alta de los perfiles High ~ formato.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
35
Implementación en Java/C++ del Estándar de Video H.264
Existen numerosas técnicas que pueden ser usadas para una compresión eficiente. Los
algoritmos de codificación pueden elegir entre dos maneras de predicción, como se explicará
más adelante, solamente mencionar que puede ser:
•
Predicción inter basada en vectores de movimiento para predecir basándose en la
división en bloques y para aprovechar la dependencia estadística temporal entre
cada imagen de un video. Este algoritmo es más eficiente, pero utiliza para predecir
bloques o frames que ya han sido codificados, con lo cual, puede obtenerse una
menor calidad que en el otro método.
•
Predicción intra usa la predicción por dependencias espaciales y para aprovechar la
dependencia estadística espacial entre cada imagen de un video. Esta predicción se
realiza sin referencias de otras imágenes y puede proporcionar puntos de acceso a la
secuencia codificada para continuar por ésta. Se consigue mejor calidad pero la
eficiencia es moderada.
5.2.2
Partición en bloques:
Como en los anteriores estándares, se define macrobloque como un boque,
propiamente dicho, de 16x16 muestras luma, o luminiscencia y sus dos correspondientes
bloques de chroma, o crominancia, que se tomará como la unidad básica de procesado de
imagen. Sin embargo, un macrobloque puede ser particionado para la manera de codificar
usando el modo inter. El tamaño o la selección del mismo en este modo se realiza mediante la
compensación del movimiento y la cantidad de datos necesarios para representarlo. La
explicación de cómo se realizan estos se hará en el apartado de predicción.
5.2.3
Luma en H.264:
Aplicado a las señales de vídeo, luma representa el brillo en una imagen, la parte
“blanca y negra” o parte acromática de la misma. Si luma representa de alguna forma la
intensidad con la que se da un color. La descomposición de la imagen RGB en los vectores
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
36
Implementación en Java/C++ del Estándar de Video H.264
luma y croma, permiten a los sistemas de video optimizar la imagen para mejorar la percepción
visual del mismo.
Para lo que nos aplica, luma permite separar la muestra de la intensidad del color, a la
cual el ojo humano es más sensible, y optimizar la compresión basándonos en eso.
Luma, cuya notación puede ser Y o L, es una propiedad que especifica que un conjunto
de arrays o un solo array representa la señal monocromática relacionada con los colores
primarios.
5.2.4
Chroma en H.264
Es una manera de conducir la señal de video en dos componentes diferentes que,
sumados a la intensidad dan la señal:
U = B'–Y'
B'
(blue – luma)
V = R'–Y'
R'
(red – luma)
El muestreo chroma es el proceso
proceso de codificar imágenes utilizando menos resolución
para la información del color que para la de luma anteriormente explicada. Para el video digital
el sistema utilizado es Y’CbCr, que es un sistema de codificado para sistema de representación
de colores RGB. La notación que se sigue para las componentes de luma y de chroma es la
siguiente:
J:a:b
Donde:
•
J Referencia del muestreo horizontal anchura de la región. 4 normalmente.
•
a número de muestras de crominancia (Cr, Cb) enla primera fila de J pixeles.
•
b numero
umero de muestras de crominancia adicionales en la segunda fila de J pixeles.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
37
Implementación en Java/C++ del Estándar de Video H.264
5.2.5
Formatos de datos en H.264
En el estándar, la imagen fuente y la decodificada se componen de uno o más arrays de
muestras según:
•
Luma (Y) únicamente, con o sin arrays auxiliares.
•
Luma y dos chroma (Y’CbCr), con o sin arrays auxiliares.
•
Verde, Azul y Rojo (RGB), con o sin arrays auxiliares.
Para ordenar la estructura o representarla se utilizan dos variables llamadas: SubWidthC
y SubHeigthC que dependen de la estructura escogida para las muestras luma y Chroma:
El estándar define la siguiente tabla:
Chroma_format_idc
separate_colour_plane_flag
0
1
2
3
3
0
0
0
0
1
Formato
Chroma
Monochrome
4:2:0
4:2:2
4:4:4
4:4:4
SubWidthC
SubHeigthC
2
2
1
-
2
1
1
-
Chroma_format_idc: define el tipo de formato chroma.
•
Para Chroma_format_idc = 0 solo hay un array y se considera luma.
•
Para Chroma_format_idc = 1 (4:2:0) cada uno de los dos array de chroma tiene la mitad
de altura y la mitad de anchura que el luma.
•
Para Chroma_format_idc = 2 (4:2:2) cada uno de los dos array de chroma tiene la
misma altura y la mitad de anchura que el luma.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
38
Implementación en Java/C++ del Estándar de Video H.264
•
Para
Chroma_format_idc
=
3
(4:4:4)
se
comprueba
el
valor
de
separate_colour_plane_flag:
o
Si es 0, cada uno de los dos chroma arrays tiene la misma altura y la misma
anchura que el luma.
o
Si es 1: los tres planos de colores son procesados por separado como imágenes
monocromáticas.
Posiciones vertical y horizontal nominales de muestras luma y croma 4:2:0 en un
cuadro:
FIGURA 6: muestras luma y chroma 4:2:0.
5.2.6
Perfiles
Los perfiles especifican restricciones sobre bitstreams limitan las capacidades
necesarias para decodificar los bitstreams. Si se ha aplicado un perfil con sus correspondientes
restricciones y formatos, debe implementarse en todos los decodificadores.
Si bien todos los perfiles utilizan el mismo conjunto de definiciones de nivel, cada
implementación puede soportar un nivel distinto por cada perfil soportado. Por lo general, para
cualquier perfil determinado, los niveles corresponden a la carga computacional y a la capacidad
de memoria del decodificador
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
39
Implementación en Java/C++ del Estándar de Video H.264
Se especifican tres niveles, el básico, el principal y el extendido. Están definidos en el
anexo A del estándar y son listas de restricciones y valores límite.
Un ejemplo de las aplicaciones que distinguen los perfiles podría ser el siguiente:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
40
Implementación en Java/C++ del Estándar de Video H.264
5.3 Conceptos aplicados.
Si con anterioridad se vió la codificación como una
na secuencia de pasos en un proceso
resumido de la siguiente manera:
La aplicación del mismo al estándar de vídeo podría realizarse
realizarse del siguiente modo:
CODIFICACIÓN:
Video original
DECODIFICACIÓN
DECODIFICACIÓN:
Video original
FIGURA 7: figura proceso codificación y descodificación.
Los elementos funcionales básicos:
•
Predicción
•
Transformación
•
Cuantificación.
•
Codificación basada en entropía
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
41
Implementación en Java/C++ del Estándar de Video H.264
Son ligeramente diferentes entre los estándares previos, aunque los cambios importantes
ocurren en los detalles de cada elemento funcional en el estándar H.264.
Anteriormente se ha visto de una manera general estas características para la
codificación de información digital.
A continuación se utilizarán los conceptos para explicar el funcionamiento de los
algoritmos expuestos en la especificación.
5.3.1
El codificador
El codificador de H.264 tiene este diagrama de flujo:
FIGURA 8: diagrama de flujo del codificador H.264.
5.3.1.1 Forward Path
La parte en color azul es correspondiente al ciclo o camino forward, donde Fn es el
frame actual, en el instante n. El frame es procesado en macrobloques y cada uno de ellos se
puede codificar de modo predicción inter o predicción intra.
En cada caso un macrobloque formado por predicción (P) está basado en un frame
reconstruido.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
42
Implementación en Java/C++ del Estándar de Video H.264
En el modo predicción intra, P está formado por muestras del Frame actual Fn, una vez
codificado, decodificado y reconstruido, pero no ha sido filtrado, como se muestra en la figura
anterior, y se adjudica al bloque el nombre uF’n.
En el otro modo, predicción inter, el macrobloque P está formado por una predicción
realizada a partir de una o más frames de referencia que pueden ser anteriores o futuros (n-1,
n+1) que ya hayan sido codificados y reconstruidos. En la imagen, el Frame de referencia está
representado por: uF’n.
Del macrobloque P y del actual, se obtiene una diferencia residual de macrobloque (Dn).
A este macrobloque diferencial se le aplica una transformación y cuantificación para dar X, que
es como llamaremos al conjunto de coeficientes de transformación ya cuantificación. Éstos, son
reordenados según la codificación basada en entropía. X, junto con información necesaria para
la decodificación del macrobloque (como el modo de predicción utilizado, tamaño o salto de
cuantificación, etc.…) forma el flujo de bits o bitstream comprimido. Esto es lo que pasa a
Network Abstraction Layer (NAL) para transmitir o almacenar la información.
5.3.1.2 Inverse Path
La parte de color rosa se corresponde con la reconstrucción de los bloques. Para ello se
utiliza el bloque de coeficientes X que son decodificados para reconstruir un frame que a su vez
codificará otros macrobloques. A los coeficientes se le aplica una “decuantificación” u
operación contraria a la cuantificación, que podría llamarse re-escalado y se representa por
(Q-1) y una transformación inversa (T-1) para producir un macrobloque diferente (Dn’). La
causa de esta diferencia es la utilización de algoritmos con pérdidas en la cuantificación.
Entonces se dice que Dn’ es una versión distorsionada de Dn. La predicción de P sumado a Dn’
crea un frame reconstruido en el que se ha perdido información con respecto al original.
Posteriormente se aplica un filtro para reducir el efecto bloque y los efectos de la distorsión y se
crea un marco de referencia reconstruido a partir de los que se obtienen de F’n.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
43
Implementación en Java/C++ del Estándar de Video H.264
5.3.2
El decodificador
El decodificador de H.264 tiene el siguiente diagrama de flujo, obtenido de la propia
lógica.
FIGURA 9: diagrama de flujo del decodificador H.264.
El decodificador recibe un bitstream desde la NAL, los datos son descodificados y
reordenados para producir un conjunto de coeficientes cuantificados X, re –escalados e
inversamente transformados para obtener Dn’, exactamente igual que se vio antes para obtener
un Frame de referencia.
Ahora, a partir de la información de la cabecera del bitstream decodificado, se crea el
macrobloque P idéntico al original. P sumado a Dn’ produce uF’n que, filtrado da como
resultado el bloque decodificado F’n.
El camino de la reconstrucción en el codificador es utilizado mayoritariamente para
asegurarse de que codificador y decodificador utilizan el mismo frame de referencia para crear
el bloque de predicción P.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
44
Implementación en Java/C++ del Estándar de Video H.264
5.4 Especificaciones del Estándar.
5.4.1
Predicción.
Predicción.
Como vimos anteriormente en el diagrama de flujo general del estándar, un
Frame se descompone en macrobloques que pueden ser de diferentes tamaños
y a continuación se elegiría el modo de predicción de los macrobloques. Hay
dos maneras de predecir y ambas se realizan con un frame o con uno o más bloques ya
procesados (cuantificadoss y transformados) y que han sufrido alguna pérdida con respecto al
original.
La diferencia reside en que la manera predicción intra aún no ha pasado por el filtro de
suavizado de bloques.
Se aprovecha la dependencia estadística espacial entre cada imagen
imagen de un video.
FIGURA 10: diagrama de flujo del predicción intra H.264.
Sin embargo
bargo para la manera de predicción inter, el bloque que se forma se hace con una
predicción de compensación del movimiento con uno o más frames anteriores como referencia.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
45
Implementación en Java/C++ del Estándar de Video H.264
Se aprovecha la dependencia estadística temporal entre cada imagen de un video.
FIGURA 11: diagrama de flujo del predicción inter H.264.
5.4.1.1 La predicción del codificado Inter.
La predicción inter crea un modelo de predicción a partir de uno o más frames de video
ya codificados. El modelo se forma alternando muestras del marco de referencia, que es lo que,
a grandes rasgos, se denomina predicción basada en compensación del movimiento.
Aplicado al estándar, sería correcto decir que se utiliza compensación basada en
bloques, que se lleva implementando desde el estándar H.261. Existen importantes diferencias
entre esos estándares previos y el actual, como que soporta un rango de tamaño de bloques y los
vectores de píxeles se definen mejor, de manera que definen “subpixeles”, como por ejemplo ¼
de pixel en la componente luma.
Este proceso genera como resultado las muestras de predicción inter del macrobloque
considerado, que son una matriz 16x16 predL de muestras luma y dos matrices 8x8 predCr y
predCb de muestras croma, una para cada componente croma Cb y Cr.
Estructura de árbol para la compensación del movimiento.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
46
Implementación en Java/C++ del Estándar de Video H.264
H.264 permite un rango de tamaños de bloques que va desde 16x16 a 4x4 muestras de
luminancia. La componente de luminancia de cada macrobloque de 16x16, puede ser dividida
de 4 maneras diferentes:
Cada una de las subdivisiones es a su vez una partición en macrobloque lo que se
conoce como sub-partición.
Si la elección del tamaño de de 8x8, las divisiones quedarían de la siguiente manera:
Estas particiones y subparticiones dan lugar a un gran número de combinaciones para
cada tamaño de bloque. Es lo que se conoce como estructura en árbol de compensación de
movimiento.
Para cada partición y subpartición se necesita un vector de movimiento y cada uno de
estos debe ser codificado y transmitido. Además la elección del tipo de partición también debe
estar codificada en el bitstream comprimido.
Como en otras muchas aplicaciones que necesitan un protocolo de transmisión, nos
encontramos con el problema de elegir entre un bloque mayor, con el que necesitaremos menos
cabeceras y menos bits para representarlas, y sin embargo no es la mejor solución al problema,
ya que la compensación de movimiento residual puede contener una suma de energía con alto
detalle que se perdería por escoger bloques grandes.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
47
Implementación en Java/C++ del Estándar de Video H.264
Por contrapunto, la elección de una partición pequeña, da mucho detalle y menos
energía residual después de la compensación pero al existir mayor numero de bloques y
particiones, se necesitaran más cabeceras o vectores de movimiento. La elección de la partición
debería realizarse por el impacto que causen en la mejora de la compresión. Cuanto más
homogénea sea un área, mejor utilizar unos bloques mayores.
La resolución de cada componente croma de un macrobloque es la mitad que la
componente luma. Cada bloque croma se divide de la misma manera que el luma, menos
cuando la partición tiene exactamente la mitad de la resolución horizontal y vertical, (por
ejemplo, una distribución 8x16 de la componente luma se correspondería con una 4x8 en
croma). La componente horizontal y vertical de cada vector (uno por partición como dijimos
antes) son divididos mor la mitad cuando se aplican a los bloques croma.
A continuación de qué es un bloque adyacente en el estándar. Dentro de cada recuadro
se encuentra el nombre de la variable que se le da o como se refiere a los bloques en el estándar.
FIGURA 12: bloques adyacentes y correspondientes variables en H.264.
El codificador de referencia utilizado en H.264 elige el tamaño más apropiado de
macrobloque según el área en el que se aplique, si existen pocos cambios, el bloque es mayor y
si existen más cambios, el bloque es menor y mejor la precisión. Esto se realiza minimizando el
vector de movimiento y el codificado residual.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
48
Implementación en Java/C++ del Estándar de Video H.264
FIGURA 13: macrobloques en una imagen residual.
Esta imagen se corresponde con la residual sin compensación de movimiento.
Cada partición en un macrobloque codificado de esta forma (modo inter) se predice
desde un área con el mismo tamaño en la imagen de referencia. El desplazamiento entre las dos
áreas se corresponde con el vector de movimiento que tiene una resolución de ¼ de pixel en la
componente luma. Los componentes en las posiciones que hallamos, no existen en la imagen de
referencia y hay que crearlas utilizando una interpolación de las muestras más cercanas. Un
ejemplo ilustrativo:
Una partición 4x4 del frame actual, se predice a partir de la región vecina de la imagen
o frame de referencia. Si las componentes horizontal y vertical del vector de movimiento son
enteros, las muestras relevantes en el bloque de referencia existen. Si uno o ambos componentes
del vector son fracciones (o número con decimales), las muestras de la predicción se forman a
partir de una interpolación de las adyacentes en la imagen de referencia.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
49
Implementación en Java/C++ del Estándar de Video H.264
FIGURA 14: predicción e interpolación en H.264.
Para codificar un vector de movimiento para cada partición puede utilizarse un número
significativo de bits, especialmente si las particiones son pequeñas. Estos vectores normalmente
son correlativos a sus vecinos y predichos a partir de ellos ya codificados. MVD, la diferencia
entre el vector actual y el predicho se codifica y envía. El vector predicho, MVP, se puede hallar
de diferentes maneras, pero la más simple de todas es calculando la mediana de los vectores de
movimiento de las particiones de macrobloques inmediatamente encima, diagonalmente encima
y a la derecha e inmediatamente a la izquierda del macrobloque actual.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
50
Implementación en Java/C++ del Estándar de Video H.264
FIGURA 15: interpolación luma de un cuarto de muestra.
En la decodificación se realiza exactamente igual que la codificación.
5.4.1.2 La predicción del codificado Intra
Si un macrobloque se codifica de manera intra, es porque se forma basándose en un
bloque previamente codificado y reconstruido pero sin filtrar. Para las muestras luma, P puede
formarse para los sub-bloques o para el completo, pero además existen 9 modos de predicción
opcionales para cada 4x4 bloques luma, cuatro opcionales para los de 16x16, y un modo único
para los chroma 4x4.
Veamos cómo se predice un bloque luma 4x4:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
51
Implementación en Java/C++ del Estándar de Video H.264
Las imágenes de arriba y de la izquierda, han sido previamente codificadas y
reconstruidas y están disponibles en el codificador y decodificador para ser utilizadas como
referencia de otras.
La predicción del bloque P se calcula basándose en las muestras etiquetadas de la
siguiente manera:
En algunos casos, no se tienen disponibles todas las muestras de A-M dentro de la
imagen actual. Si el tipo de predicción es el modo 0 o DC, si no están todas las muestras
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
52
Implementación en Java/C++ del Estándar de Video H.264
disponibles en la imagen actual, se modifica dependiendo de las disponibles, pero en el caso del
resto de los modos, no se usarán si no están todas las muestras disponibles.
Las flechas en la siguiente figura indicarán la dirección de la predicción en cada modo.
Para los modos 3-8, las muestras predichas se formarán mediante una media ponderada de las
muestras predichas de la A~Q. El codificador deberá seleccionar para cada bloque la predicción
que minimice el valor residual de P y del bloque codificado.
FIGURA 16: tipos de movimiento en la predicción H.264.
Ejemplo:
Calculamos los9 tipos de modos de predicción para un macrobloque de 4x4. La suma de
errores Absolutos (Sum of Absolute Errors (SAE)) para cada predicción indica la magnitud del
error de predicción. En este caso, el error menor lo da el modo 7.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
53
Implementación en Java/C++ del Estándar de Video H.264
Bloques de 16x16:
Ahora podemos ver los cuatro modos de predicción para bloques de tamaño 16x16,
alternativa al visto anteriormente:
Ese proceso acepta como argumentos las muestras reconstruidas de los bloques luma (si
los hubiere) antes de aplicar un proceso de filtrado de bloques correspondiente. Este proceso
genera como resultado las muestras luma de predicción Intra del macrobloque considerado
predL[ x, y ].
•
Modo 0: Vertical. Extrapolación desde arriba. (h)
•
Modo 1: Horizontal. Desde la Izquierda (v)
•
Modo 2: DC. Desde arriba a la izquierda
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
54
Implementación en Java/C++ del Estándar de Video H.264
•
Modo 3: Plano. Una función se aplica al plano para accede a las muestras de
arriba y a la izquierda de H y V. este modo es apropiado para áreas de poca o
suave variación lumínica.
Un ejemplo:
Al igual que con los bloques 4x4, mostramos un macrobloque que ha sido previamente
codificado. El resultado de la predicción por cada modo se muestra en la figura inmediatamente
inferior.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
55
Implementación en Java/C++ del Estándar de Video H.264
Como vemos la mejor manera es la que corresponde al modo 3.
Bloques de 8x8:
A continuación explicaremos la forma de predecir un bloque chroma de tamaño 8x8.
Estos bloques se predicen de arriba a la izquierda o simplemente a la izquierda. Los 4
modos de predecir son muy similares a los de los bloques luma de 16x16 que acabamos de
mostrar, salvo que el orden de los números que describen los modos son diferentes. DC (modo
0), horizontal (modo 1), vertical (modo 2) y plano (modo 3).
La elección del modo intra para la predicción para cada bloque 4x4 debe ser indicado al
decodificador y esto requiere una cantidad de bits. Sin embargo, mucho de los bloques
predichos para un tamaño 4x4 producen vectores correlativos.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
56
Implementación en Java/C++ del Estándar de Video H.264
5.4.2
Transformación y cuantific
cuantificación
ficación
Como hemos visto con anterioridad, el estándar define el proceso de
reescalado
escalado o decuantificación y la transformación inversa, procesos que
reciben como entrada los coeficientes de transformación ya cuantificados.
s. Los valores de
reescalado son transformados utilizando una transformación inversa. La correspondiente
transformación y cuantificación no están estandarizados pero se pueden obtener de lo sí
definido.
Donde:
Son los bloques residuales o diferencias.
Coeficientes
oeficientes cuantificados.
cuantificados
Desarrollar la transformación y el proceso de cuantificación.
La transformación básica 4x4 usada en H.264 es una DCT.
DCT Estos procesos están
estructurados de tal manera que se minimiza la complejidad y la carga computacional lograda
dividiendo el proceso en dos partes, un núcleo y una de escalado.
Para la transformación, se considera un bloque de pixeles y se procesa según la
Transformada de Cosenos Discreto en 2D y se sigue de la cuantificación,, de la que hablaremos
posteriormente.
Primeramente hablaremos de la Transformada del Coseno Discreto en 2D.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
57
Implementación en Java/C++ del Estándar de Video H.264
5.4.2.1 Transformada del Coseno Discreto en 2D (DCT)
La Transformada del Coseno Discreto (DCT) es un tipo de transformada unitaria con la
misma filosofía que la denominada Transformada de Fourier, pero utiliza funciones de cosenos
reales en lugar de exponenciales complejas. En el presente caso de estudio se tratará de explicar
los fundamentos de la DCT bidimensional, que es la que tendría sentido utilizar.
Al tratarse a su vez de una transformada en el dominio discreto, su formulación
presentará sumatorios en lugar de integrales y funciones coseno en lugar de las mencionadas
exponenciales complejas. Así, la fórmula de la DCT de análisis para, por ejemplo, 8
coeficientes es la siguiente:
ECUACION 1: DCT análisis para 8 coeficientes.
También, para el mismo ejemplo, tendremos la siguiente fórmula de síntesis:
ECUACION 2: DCT síntesis para 8 coeficientes.
La siguiente figura muestra un conjunto de 64 funciones base cosinusoidales
bidimensionales (imágenes base) que se generaron multiplicando un conjunto de funciones base
unidimensionales (de ocho puntos) orientadas horizontalmente, por un conjunto verticalmente
orientado de las mismas funciones. Las imágenes base orientadas horizontalmente representan
las frecuencias horizontales y las orientadas verticalmente representan las frecuencias verticales.
Por convenio, el término DC de las funciones base horizontales está situado a la izquierda, y
arriba en el caso de las funciones base verticales.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
58
Implementación en Java/C++ del Estándar de Video H.264
Por consiguiente, la fila superior y la columna de la izquierda tienen variaciones de
intensidad en una dimensión, que si se representan, serían las mismas que las de la siguiente
figura. (Para propósitos de ilustración, un gris neutro representa cero en estas figuras, el blanco
representa amplitudes positivas, y el negro representa amplitudes negativas.)
Cuando ponderamos ( ∑ ) por un adecuado conjunto de 64 coeficientes, estas funciones
base pueden utilizarse para representar cualquier valor de 64 muestras. En la siguiente figura se
muestra la secuencia en que estas 64 funciones base son progresivamente sumadas. Este modelo
en zig-zag, (utilizado en los algoritmos JPEG), aproximadamente ordena las funciones de menor
a mayor frecuencia espacial.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
59
Implementación en Java/C++ del Estándar de Video H.264
Debido a que las funciones base de la DCT bidimensional son productos de dos
funciones base unidimensionales, la única función base constante (coeficiente DC) se encuentra
en la esquina superior izquierda del conjunto.
Al aplicar la transformada discreta del coseno muchos de los coeficientes obtenidos son
pequeños, es decir, la mayoría de la energía de los datos se almacena en pocos coeficientes. El
par de la transformada discreta del coseno bidimensional se obtiene de forma sencilla a partir
del caso unidimensional y de la propiedad de separabilidad. Dichos coeficientes base para las
figuras anteriores, se obtienen mediante la siguiente formulación:
Interpretación De La DCT
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
60
Implementación en Java/C++ del Estándar de Video H.264
A la derecha, se presentan gráficos sobre las 64
funciones base, donde se muestra que las bajas frecuencias
vienen representadas por las funciones base de la parte superior
izquierda del cuadro total, y las altas frecuencias se representan
por la mayoría de la parte inferior derecha del cuadro total.
Por otra parte, la parte inferior izquierda del cuadro
viene representada por las funciones base que resaltan los
bordes horizontales, y la parte superior derecha por las
funciones base que resaltan los bordes verticales, tal y como se
muestra a continuación.
Como ejemplo inicial, se muestran una imagen (figura de la izquierda) y su DCT (figura
de la derecha), observando así que la información relativa a los bordes horizontales pasa a tener
mayor peso en la parte izquierda de la DCT:
Otro ejemplo ilustrativo es el que se presenta a continuación. Se trata de un ejemplo de
aproximación sucesiva de la obtención de una DCT sobre toda la imagen inicial. Se observa que
a medida que aumenta el número de coeficientes utilizados para la obtención de la DCT, se
consiguen imágenes más nítidas y más parecidas a la original.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
61
Implementación en Java/C++ del Estándar de Video H.264
Bloques De La DCT
A priori las muestras de cualquier tamaño pueden descomponerse en una DCT
bidimensional y, dado que se puede demostrar que se obtiene una mayor compactación, se
utilizará para las explicaciones bloques de tamaño 8x8. Cada bloque 8x8 se transforma
independientemente, pero esta segmentación en bloques conlleva algunos problemas.
Debido a que la imagen se divide en bloques 8x8, las frecuencias espaciales en la
imagen y las frecuencias espaciales de las funciones base no son precisamente equivalentes.
Una simple función base coseno de una frecuencia dada, puede representar únicamente una fase
particular de una oscilación espacial en el bloque; la representación de una fase arbitraria, por
tanto, requiere bien una función seno o un armónico coseno de la frecuencia fundamental.
La segmentación en bloques 8x8 puede también producir "efectos de bloque" discontinuidades visibles entre bloques adyacentes -.
Si fijáramos todos los coeficientes AC a cero, entonces el coeficiente DC tendría que
representar todas las muestras en un bloque. En aquellos puntos donde los términos DC difieran
notablemente de bloque a bloque, la discontinuidad sería visible. Estos efectos de bloque
aparecen como bordes en la imagen, y los bordes abruptos implican altas frecuencias espaciales.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
62
Implementación en Java/C++ del Estándar de Video H.264
Sin embargo, estas frecuencias espaciales tienen lugar en las transiciones entre bloques y son
provocadas por la ausencia de coeficientes AC. En este caso se necesitan coeficientes AC no
nulos para suprimir este efecto.
A continuación, se muestra un ejemplo con la famosa imagen “The cameraman”, y su
DCT por bloques:
También se muestra para la misma imagen original, el efecto de compresión que se
produce tras eliminar el 43% en la figura de la izquierda, el 56% en la central, y el 85% en la
figura de la derecha.
Como era de esperar, a medida que se eliminan más coeficientes de la DCT
(comprimiendo en mayor grado la imagen), se obtiene un resultado más borroso.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
63
Implementación en Java/C++ del Estándar de Video H.264
Cuantificación y Representación de la DCT Entera
La cuantificación permite reducir la precisión con la que los coeficientes de la DCT se
representan cuando se convierte la DCT a una representación entera, y es en donde se tiende a
anular muchos coeficientes y aún más los de altas frecuencias espaciales.
Los valores cuantificados pueden ser asignados individualmente para cada coeficiente
DCT, utilizando el criterio basado en la visibilidad de las funciones base.
Si medimos el umbral de visibilidad de una función base determinada: amplitud del
coeficiente a partir de la cual la función base es detectable por el ojo humano podemos dividir
los coeficientes por ese valor con el apropiado redondeo a valores enteros, es decir, el proceso
de cuantificación. Si multiplicamos los coeficientes obtenidos por ese valor antes de la
reconstrucción, crearemos una condición en la que el ojo no podría detectar ninguna diferencia
entre los coeficientes DCT cuantificados y sin cuantificar.
Esto implicaría el baremo de la aceptación de defectos (dividir por un coeficiente
mayor) o una mayor precisión (por un número menor).
De una manera “oficial” diremos:
•
Cuantificación es el proceso de ponderación y truncamiento de los
coeficientes de la DCT a valores enteros
•
Decuantificación: es el restablecimiento aproximado de la magnitud de los
coeficientes originales de la DCT.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
64
Implementación en Java/C++ del Estándar de Video H.264
Codificación de Imagen
La DCT, al ser una transformada discreta puede aplicarse a codificación de imagen,
desde un punto de vista de reducción de ancho de banda o compresión de datos.
El objetivo es conseguir que una imagen o secuencia de imágenes (dominios espacialtemporal), se traslade a un dominio transformado de tal forma que se reduzca el ancho de banda
para la transmisión o los requerimientos para el almacenamiento; de tal forma que la
subsiguiente recuperación de la imagen o secuencia de imágenes mediante la transformada
inversa, no presente una distorsión perceptible.
A pesar de que se han definido muchas medidas cuantitativas para minimizar la
distorsión en estos dominios, como puede ser el error cuadrático medio (MSE), error absoluto
medio (MAE), coeficiente de correlación (CC), etc..., la DCT se pondera según el ojo humano,
y es éste el que decidiría en última instancia la calidad de las mismas. Además de la calidad,
bien sea medida cuantitativa o cualitativamente, son igualmente importantes otros factores tales
como la complejidad de la implementación (realización hardware) y las diversas características
opcionales pertenecientes a cada aplicación específica.
En codificación transformada de imágenes, una imagen NxN es dividida en bloques de
tamaño LxL (generalmente son del mismo tamaño).
Como hemos dicho anteriormente, la mayoría de estos bloques suelen dimensionarse en
bloques de tamaño 8x8 y 16x16 en codificación de imagen. Estos bloques de tamaño pequeño
permiten introducir características adaptativas basadas en la actividad o detalle existente en el
bloque, comúnmente llamadas cabeceras.
Gracias a esta división, la complejidad del hardware (tamaño de la memoria y lógica
computacional) se reduce considerablemente en comparación con la DCT bidimensional de un
cuadro completo (un cuadro simple puede ser de tamaño 512x512). Aunque puede existir
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
65
Implementación en Java/C++ del Estándar de Video H.264
correlación entre bloque adyacentes, esto no es suficiente para justificar una transformada de
tamaño de bloque superior a 16x16. Por lo tanto este tamaño de bloque de 16x16 es la mejor
solución de compromiso, teniendo en cuenta la distribución estadística de las imágenes,
cuantificadores, y el ruido de los canales. Por otro lado, los codificadores de videoconferencia y
videoteléfonos basados en la DCT se han desarrollado utilizando bloques de 8x8 ó 16x16.
Asimismo el algoritmo básico de codificación de imágenes estáticas (recomendado por JPEG),
está basado en la aplicación de una DCT bidimensional con tamaño de bloques 8x8.
Después de dividir la imagen en bloques de tamaño LxL en el dominio transformado, el
selector descarta algunos de los coeficientes tanto de forma adaptativa como fija. Una
interpretación física de este proceso de selección puede observarse en la figura en la que se
muestran las imágenes base de la DCT bidimensional que recordamos a continuación:
El bloque superior izquierdo es de intensidad uniforme, representando el promedio de
un bloque de imagen. La progresión de izquierda a derecha representa un número creciente de
bordes verticales. De forma similar, la progresión desde arriba hacia abajo representa un número
creciente de bordes horizontales; en el bloque inferior derecho se produce la mezcla máxima de
bordes horizontales y verticales (este bloque tiene una forma de tablero de ajedrez).
El descarte de los coeficientes de alta frecuencia en el dominio de la DCT bidimensional
implica la supresión de las imágenes base correspondientes a la imagen original, por lo tanto
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
66
Implementación en Java/C++ del Estándar de Video H.264
podemos considerar la DCT bidimensional como un proceso de descomposición desde el
dominio espacial hacia el dominio de las imágenes base de la DCT.
Esto significa que coges una imagen y la vas descomponiendo en capas, cada una con
unas frecuencias y unas líneas destacadas H o V que al sumarla se quedará como la original.
Pero como esos sumandos están ponderados, si algún coeficiente es cero se suprime el sumando
con lo que se pierde información.
Esta descomposición estructural puede utilizarse adaptativamente seleccionando los
coeficientes de la transformada bloque por bloque base, para su posterior procesado, mediante la
asignación a cada bloque de un número finito de clases basada en la distribución de sus
coeficientes.
Si el proceso de descomponer un conjunto de muestras en un conjunto ponderado de
funciones base cosinusoidales se denomina Transformada Discreta del Coseno Directa
(DCT), al método de reconstruir el conjunto de muestras a partir del conjunto ponderado de
funciones base cosinusoidales se le conoce como Transformada Discreta del Coseno Inversa
(IDCT).
El método más sencillo para implementar la DCT es seguir las ecuaciones teóricas. Por
ejemplo, para el caso de una DCT bidimensional de ocho puntos, comprobamos que existe un
límite superior de 64 multiplicaciones y 56 sumas para cada DCT unidimensional. (Los
términos " coseno " pueden combinarse con las constantes antes del cálculo, ya que, las
funciones coseno se convierten en números discretos en cada posición). Por lo tanto, una DCT
completa de 8x8 realizada de esta forma, en formato unidimensional separable - ocho filas y
luego ocho columnas -, requeriría 1024 multiplicaciones y 869 sumas, además de las
operaciones adicionales para cuantificar los coeficientes.
Si realmente la DCT necesitara tantas operaciones para su cálculo, tendríamos que
elegir un algoritmo diferente para la compresión de imágenes. De hecho, el algoritmo más
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
67
Implementación en Java/C++ del Estándar de Video H.264
eficiente para la DCT 8x8, requiere sólo 54 multiplicaciones, 464 sumas, y 6 desplazamientos
aritméticos para producir un método adecuado de cuantificación.
Las técnicas de la DCT rápida aprovechan la ventaja que ofrecen las simetrías existentes
en las ecuaciones de la DCT, utilizándolas para reducir el número de operaciones. Las
amplitudes pueden asociarse con los signos adecuados antes de la multiplicación.
De esta forma, para el mismo caso mencionado anteriormente, el número total de
operaciones es 22 multiplicaciones y 28 sumas. Además, si los coeficientes de la DCT se
ponderan de tal forma que una multiplicación se combina con la cuantificación, tenemos
únicamente 14 multiplicaciones y 28 sumas para producir un sistema adecuado de
cuantificación.
Recordamos que sirven las cuentas realizadas para la unidimensional, ya que la DCT
bidimensional es separable, se puede calcular como DCT's unidimensionales sobre todas las
filas, y más tarde sobre las columnas formadas por los coeficientes de las filas.
5.4.2.2 Codificación y cuantificación basada en DCT
Una vez que nos ha quedado claro en qué consiste la transformada del coseno, diremos
que en la definición del estándar, este proceso se aísla en un núcleo que llamaremos Cf y en una
matriz de escalado Sf. Utilizando en el proceso de cuantificación una constante de escalado = 215
y redondeando el resultado final, el proceso de cuantificación será:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
68
Implementación en Java/C++ del Estándar de Video H.264
Desarrollando el reescalado y el proceso de transformación inversa
Debido a que se utiliza para la transformación la DCT, parece evidente que se realizara
una DCT inversa o IDCT en un núcleo que llamaremos Ci y una matriz de escalado que
llamaremos Si. En este caso el proceso de escalado y reescalado se realiza por una constante 26
y compensado redondeando el resultado final.
Combinando el proceso de reescalado y Si con Vi donde:
Tenemos:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
69
Implementación en Java/C++ del Estándar de Video H.264
Desarrollamos Cf y Sf para bloques de 4x4
Consideramos una DCT de de un bloque X, y con las propiedades vistas:
Donde ‘·’ es una multiplicación matricial y A es
Las filas de A son ortogonales y A tiene las propiedades de ser una matriz unitaria:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
70
Implementación en Java/C++ del Estándar de Video H.264
Calculando la ecuación anterior con un procesador normal, requiere una cantidad
enorme de carga computacional y una aproximación irracional de número s b y c. Como
dijimos en la explicación de la DCT, existe para estos algoritmos una manera más rápida de
calcularla aprovechando las
propiedades de la matriz A y utilizando una aproximación
particular, que es multiplicarlo por un factor =2.5, se obtiene:
Esta aproximación minimiza la complejidad de implementación y de carga, mientras
que mantiene
tiene la mejora de compresión de este algoritmo. Las filas de Cf tienen diferentes
normas. Para restablecer la propiedad ortonormal que poseía la matriz A y poder aplicar
algoritmos de la DCT rápida, hay que multiplicar
Donde · denota una multiplicación
multiplicació elemento a elemento (A = B·C aij= bij·cij). Aplicando
la DCT se obtiene:
Reorganizando:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
71
Implementación en Java/C++ del Estándar de Video H.264
Donde
Desarrollando Ci y Si de bloques de 4x4
Consideramos una 2D IDCT de 4x4 de un bloque Y
Donde
Escogiendo esta vez una aproximación con una escala 0,5, se obtiene Ci:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
72
Implementación en Java/C++ del Estándar de Video H.264
Ésta es ortogonal pero no cumple que sea normal, con lo que multiplicando, de manera
análoga al proceso directo por
A lo que aplicamos IDCT:
Reorganizando:
Donde
El núcleo de la transformada inversa Ci y la matriz de reescalado Vi descritas vienen
explícitamente definidas en el estándar y a partir de esto podemos obtener los demás datos.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
73
Implementación en Java/C++ del Estándar de Video H.264
Desarrollando Vi
De la ecuación
H.264 proporciona un rango de factores de escala o Qstep determinado, el número
concreto no viene definido en el estándar sino que la Vi o matriz de reescalado está especificada.
Los valores de Qstep correspondientes a cada Vi se corresponden con la siguiente tabla.
QP
0
1
2
3
4
5
6
…
12
…
18
…
48
…
51
Qstep
0.625
0.702
0.787
0.884
0.992
1.114
1.250
…
2.5
…
5.0
…
160
…
224
El valor de Vi depende de Qstep visto y de Si, el valor de escala. Se han calculado para
los 6 primeros, (0~5) y se muestran a continuación:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
74
Implementación en Java/C++ del Estándar de Video H.264
Para valores mayores de QP el correspondiente valor de Vi se dobla. Los tres valores
que aparecen en cada matriz para cada valor, vienen definidos en el estándar, y se muestran en
la tabla que sigue:
De ahí que para los valores QP de 0 a 5, Vi se obtiene como:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
75
Implementación en Java/C++ del Estándar de Video H.264
La notación seguida es: matriz (fila, columna), de la que se tiene que Vi = v(QP,n) de
manera simple para valores pequeños, pero la forma general es la que se muestra a
continuación:
Ahora si juntamos todo, quedaría que el núcleo del que hablábamos anteriormente,
quedaría de la siguiente manera o con el siguiente valor:
Hallando Mf
De las ecuaciones anteriormente vistas y despejando; f se tiene
(1)
(2)
De (1) y (2) se tiene:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
76
Implementación en Java/C++ del Estándar de Video H.264
Ya hemos calculado, porque se pueden obtener fácilmente de las especificaciones del
estándar, Si, Sf y Vi.
Obteniendo Mf como:
Los valores de Mf para los QP que van de 0~5 se obtendrían de la siguiente manera:
Donde m es el valor que se expresa en la siguiente tabla:
Para completar la transformada directa, o forward que es como la venimos llamando
durante el documento, se tiene que la forma general para escalado y cuantificación para bloques
de 4x4 es:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
77
Implementación en Java/C++ del Estándar de Video H.264
5.4.3
Codificación entrópica.
El objetivo de la codificación, tal y como describimos con anterioridad, es
buscar
uscar el código que represente los valores cuantificados sin distorsión con el
menor número de bits posible, lo que nos lleva a una codificación entrópica. Esta se puede
resumir en su forma o enunciado general:
Dondee S denota la información y P la información codificada, luego I(si) denota la información
de S.
Si ocurrirá
irá una media de Pi*N veces (N
( es el número de símbolos).
Parece lógico pensar, según la afirmación anterior que: P1*N ocurrencias de S1 aportarán una
información de
Entonces la información total que se desea codificar:
Entonces podemos definir
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
78
Implementación en Java/C++ del Estándar de Video H.264
El estándar especifica dos maneras de codificación entrópica:
•
Context-based Adaptive Binary Arithmetic Coding (CABAC)
•
Variable-Length Coding (VLC)
5.4.3.1 Variableariable-Length Coding (VLC)
A continuación se muestran los parámetros requeridos para codificar y trasmitir:
Secuencia, imagen y elementos sintácticos de un corte.
Tipo de macrobloque (mb_type en el
estándar).
Patrón de bloque codificado.
Parámetro de cuantificación.
Índice del frame de referencia.
Vector de movimiento.
Datos residuales.
Método de predicción para cada macrobloque
codificado.
Indica qué bloque dentro de un macrobloque
contiene coeficientes codificados.
Transmitido como un valor delta de un valor
previo de QP.
Identifica el frame de referencia para
predicción inter.
Transmitido como una diferencia (mvd) de
vector de movimiento predicho.
Coeficientes de datos para cada bloque 4x4 o
2x2.
A variable que determina el tipo de codificación es entropy_coding_mode y, cuando es
igual a 0, el bloque residual se codifica según un esquema de codificación de longitud variable y
adaptable al contexto: context-adaptive variable length coding (CAVLC), y otras unidades de
codificación de longitud variable son codificadas usando un tipo de codificación llamado
Exponential Golomb.
La codificación Exponential Golomb es de construcción regular y las palabras
codificadas, siguen la siguiente sintaxis:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
79
Implementación en Java/C++ del Estándar de Video H.264
[M zeros][1][INFO]
Donde
de INFO es un campo de M bits que llevan la información. La siguiente tabla
muestra los primeros 9 códigos:
0
1
1
1
10
010
2
11
011
3
100
00100
4
101
00101
5
110
00110
6
111
00111
7
1000
0001000
8
1001
0001001
Una palabra codificada puede descodificarse según esta regla:
1. leer en M los ceros seguidos de 1
2. leer M bits del campo INFO
3. code_num= 2M + INFO – 1
Y code_num es el índice con el que se construye esta codificación.
Un parámetro (como los que vimos antes) a ser codificado es mapeado a code_num de
alguna de las siguientes maneras:
•
Directamente o sin signo, para macrobloques, cuya notación es: ue(v), donde v es el
parámetro.
•
Mapeado con signo, usado para el vector de movimiento delta (diferencial), delta QP y
otros, la notación es se(v) y se mapea de la siguiente manera:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
80
Implementación en Java/C++ del Estándar de Video H.264
•
De lo contrario, si el elemento sintáctico se codifica como me(v), para calcular el valor
del elemento sintáctico se llama al proceso de mapeado del patrón de bloques
codificados, el cual asigna un valor según una tabla de la que se presentn aquí las
priemras 10 entradas:
•
De lo contrario (el elemento sintáctico está codificado como te(v)), se determina en
primer lugar los valores posibles del elemento sintáctico. Éste toma valores entre 0 y x,
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
81
Implementación en Java/C++ del Estándar de Video H.264
siendo x mayor o igual que 1, y el cálculo de valor del elemento sintáctico depende del
valor de x.
–
Si x es mayor que 1, codeNum y el valor del elemento sintáctico se calculan de la
misma manera que los elementos sintácticos codificados como ue(v).
–
De lo contrario (x es igual a 1), el proceso de análisis de codeNum, que es igual al
valor del elemento sintáctico, es equivalente a la siguiente expresión:
Cada uno de los tipos de mapeados es diseñado para producir menores palabras
codificadas para valores que aparecen frecuentemente y mayores palabras codificadas para los
menos frecuentes.
5.4.3.2 ContextContext-based adaptive variable length coding (CAVLC)
El otro método descrito por el estándar, llamado Context-based adaptive variable
length coding (CAVLC), es usado para codificar bloques 4x4 o 2x2 de transformada de
coeficientes ordenados. Este método es diseñado para mejorar aprovechando las características
de los bloques de tamaño 4x4 cuantificados, obteniendo así las siguientes ventajas:
•
Después de la predicción, la transformación y la cuantificación, los bloques están
típicamente dispersos, contienen numerosos ceros. Este método presenta mayor
compactación.
•
Los coeficientes distintos de cero más altos después del recorrido en zigzag a veces son
secuencias de +1 o -1. CAVLC también compacta estas cadenas.
•
El número de coeficientes distintos de cero en los bloques vecinos es correlativo. El
número de coeficientes es codificado usando una tabla de búsqueda que depende de
estos coeficientes para optimizar las búsquedas.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
82
Implementación en Java/C++ del Estándar de Video H.264
•
El nivel o magnitud de coeficientes distintos de cero tiende a ser más alto al principio de
un array ordenado y más bajo alrededor de las altas frecuencias. CAVLC toma ventaja
adaptando la elección de la tabla para el parámetro, dependiendo de la magnitud de los
niveles codificados.
La codificación CAVLC de un bloque de coeficientes de transformada se realiza tal y
como se describe a continuación.
1) Codificación del número de coeficientes y de los “trailing” o siguientes (coeff_token).
El primer VLC, coeff_token, codifica tanto el número total de coeficientes con valor
distinto de cero (TotalCoeffs), como el número de los siguientes valores +/-1 (T1). TotalCoeffs
puede tomar cualquier valor desde 0 (bloque de 4x4 sin coeficientes) hasta 16 (16 coeficientes
distintos de cero). T1 puede tomar cualquier valor desde 0 hasta 3; si hay más de 3 valores +/-1
siguientes, sólo los 3 últimos son tratados como “casos especiales”, y el resto son codificados
como coeficientes normales.
Existen 4 opciones de “look-up tables” o tablas de verdad para ser usadas en la
codificación de coeff_token, denominadas Num-VLC0, Num- VLC1, Num-VLC2 and NumFLC (3 tablas de código de longitud variable y 1 de código de longitud fija). La elección de la
tabla depende del número de coeficientes distintos de cero en los bloques previamente
codificados NU y NL, posicionados a la izquierda y encima respectivamente. El parámetro N se
calcula como:
Si los bloques U y L están disponibles (por ejemplo, en el mismo “slice” o parte
codificada), N = (NU+NL)/2.
Si sólo está disponible el bloque U, N=NU; si sólo está disponible el bloque L, N=NL; si
ninguno está disponible N=0.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
83
Implementación en Java/C++ del Estándar de Video H.264
Como se muestra en la siguiente tabla, N selecciona la “look-up table” y de esta forma,
la elección del VLC se adapta dependiendo del número de coeficientes codificados en los
bloques vecinos (contexto adaptativo). Num-VLC0 está “predispuesto” a tener pequeños
números de coeficientes; pequeños valores de TotalCoeffs (0 y 1) tienen asignados códigos
particularmente cortos y altos valores de TotalCoeffs tienen asignados códigos particularmente
largos. Num-VLC1 está predispuesto a tener números medios de coeficientes (valores del
TotalCoeffs alrededor de 2-4 tienen asignados códigos relativamente cortos), Num-VLC2 está
predispuesto a tener números altos de coeficientes y FLC asigna un código fijo de 6 bits a cada
valor de TotalCoeffs.
N
0, 1
2, 3
4, 5, 6, 7
8 o mayor
Tabla para coeff_token
Num-VLC0
Num-VLC1
Num-VLC2
FLC
2) Codificación del signo de cada T1.
Para cada T1 (siguientes +/-1) señalizado por coeff_token, un único bit codifica el signo
(0=+, 1=-). Están codificados en orden inverso, comenzando por el T1 más frecuente.
3) Codificación de los niveles de los coeficientes distintos de cero restantes
El nivel (signo y magnitud) de cada coeficiente restante distinto de cero en el bloque, se
codifica en orden inverso, desde el más frecuente hasta el coeficiente DC o de continua. La
elección de la tabla VLC para codificar cada nivel se adapta dependiendo de la magnitud de
cada nivel codificado sucesivo (contexto adaptativo). Hay 7 tablas VLC a elegir, desde
Level_VLC0 a Level_VLC6. Level_VLC0 está predispuesto a tener menores magnitudes;
Level_VLC1 está predispuesto a tener magnitudes ligeramente superiores y así sucesivamente.
La elección de la tabla es adaptada de la siguiente forma:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
84
Implementación en Java/C++ del Estándar de Video H.264
a) Inicialización de la tabla al nivel Level_VLC0 (a menos que existan más de 10
coeficientes distintos de cero y menos de 3 “trailings” o seguidos, en cuyo caso se
inicializaría al nivel Level_VLC1).
b) Codificación del coeficiente distinto de cero más frecuente.
c) Si la magnitud de este coeficiente es mayor que un umbral predefinido, se sube a la
siguiente tabla VLC.
De esta forma, la elección del nivel está relacionada con la magnitud de los últimos
coeficientes codificados. Los umbrales se muestran en la siguiente tabla; el primer umbral es
cero, que significa que la tabla siempre se incrementa tras la codificación del primer nivel de
coeficientes.
Tabla VLC actual
VLC0
VLC1
VLC2
VLC3
VLC4
VLC5
VLC6
Umbral para el incremento de tabla
0
3
6
12
24
48
N/A (tabla más alta)
4) Codificación del número total de ceros previos al último coeficiente
TotalZeros es la suma de todos los ceros previos al mayor coeficiente distinto de cero
del array reordenado. Esto se codifica con una VLC. La razón del envío de una VLC separada
que indique TotalZeros es que muchos bloques contienen un número de coeficientes distintos de
cero al comienzo del array y (como se verá más adelante) esta aproximación significa que el
zero-runs al comienzo del array no necesita ser codificado.
5) Codificación de cada “run” de ceros o ceros predecesores
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
85
Implementación en Java/C++ del Estándar de Video H.264
El número de ceros que preceden a cada coeficiente distinto de cero (run_before) se
codifica en orden inverso. Un parámetro run_before para cada coeficiente distinto de cero,
comenzando por el más frecuente, con dos excepciones:
a) Si no hay más ceros a la izquierda a codificar (por ejemplo, ?[run_before]=TotalZeros),
no es necesario codificar más valores run_before.
b) No es necesario codificar run_before para el último (menos frecuente) coeficiente
distinto de cero.
La VLC para cada conjunto de ceros predecesores se elije dependiendo de:
a) El número de ceros que aún no han sido codificados (ZerosLeft), y
b) El run_before.
Por ejemplo, si sólo quedan 2 ceros por codificar, run_before sólo puede tomar 3
valores (0, 1 ó 2), de forma que la VLC no necesita más de 2 bits; si aún quedan 6 ceros por
codificar, run_before puede tomar 7 valores (de 0 a 6), y la tabla VLC necesita ser lo
suficientemente más larga.
Ejemplos de Codificación en CAVLC
En todos los ejemplos siguientes, se supone que la tabla Num-VLC0 se utiliza para
codificar coeff_token.
EJEMPLO 1
Bloque de 4x4:
0
0
1
0
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
3
-1
0
0
-1
1
0
0
0
0
0
0
86
Implementación en Java/C++ del Estándar de Video H.264
Bloque reordenado:
•
0, 3, 0, 1, -1, -1, 0, 1, 0, …
•
TotalCoeffs = 5 (indexados de más frecuentes [4] a menos frecuentes [0])
•
TotalZeros = 3
•
T1s = 3 (de hecho hay 4 “trailings” o seguidos, pero solo 3 pueden ser
codificados como un
“caso especial”)
Codificación:
Elemento
coeff_token
T1 signo (4)
T1 signo (3)
T1 signo (2)
Level (1)
Level (0)
TotalZeros
run_before (4)
run_before (3)
run_before (2)
run_before (1)
run_before (0)
Elemento
coeff_token
T1 signo (4)
T1 signo (3)
T1 signo (2)
Level (1)
Level (0)
TotalZeros
run_before (4)
run_before (3)
run_before (2)
run_before (1)
run_before (0)
Valor
TotalCoeffs=5, T1s=3
+
+1 (usa Level_VLC0)
+3 (usa Level_VLC1)
3
ZerosLeft=3; run_before=1
ZerosLeft=2; run_before=0
ZerosLeft=2; run_before=0
ZerosLeft=2; run_before=1
ZerosLeft=1; run_before=1
Valor
TotalCoeffs=5, T1s=3
+
+1 (usa Level_VLC0)
+3 (usa Level_VLC1)
3
ZerosLeft=3; run_before=1
ZerosLeft=2; run_before=0
ZerosLeft=2; run_before=0
ZerosLeft=2; run_before=1
ZerosLeft=1; run_before=1
Código
0000100
0
1
1
1
0010
111
10
1
1
01
No requiere código; último coeficiente
Código
0000100
0
1
1
1
0010
111
10
1
1
01
No requiere código; último coeficiente
El bitstream transmitido para este bloque es 000010001110010111101101.
Decodificación:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
87
Implementación en Java/C++ del Estándar de Video H.264
El array de salida se construye a partir de los valores decodificados, como se muestra a
continuación. Los valores añadidos al array de salida en cada etapa están subrayados.
Código
0000100
0
1
1
1
0010
111
10
1
1
01
Elemento
coeff_token
T1 signo
T1 signo
T1 signo
Level
Level
TotalZeros
run_before
run_before
run_before
run_before
Valor
TotalCoeffs=5, T1s=3
+
+1
+3
3
1
0
0
1
Array de salida
Vacío
1
-1, 1
-1, -1,
1, 1
1, -1,
1, -1, 1
3, 1, -1,
- -1, 1
3, 1, -1,
- -1, 1
3, 1, -1,
- -1, 0, 1
3, 1, -1,
- -1, 0, 1
3, 1, -1,
- -1, 0, 1
3, 0, 1, -1, -1, 0, 1
El decodificador ha insertado dos ceros; sin embargo, TotalZeros es igual a 3, por lo que
otro cero es insertado antes del coeficiente más bajo, haciendo el siguiente array de salida:
0, 3, 0, 1, -1,
1, -1, 0, 1.
EJEMPLO 2
Bloque de 4x4:
-2
3
-3
0
4
0
0
0
0
0
0
0
-1
0
0
0
Bloque reordenado:
•
-2, 4, 3, -3,
3, 0, 0, -1, …
•
TotalCoeffs = 5 (indexados de más frecuentes [4] a menos frecuentes [0])
•
TotalZeros = 2
•
T1s = 1
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
88
Implementación en Java/C++ del Estándar de Video H.264
Codificación:
Elemento
coeff_token
T1 signo (4)
Level (3)
Level (2)
Level (1)
Level (0)
TotalZeros
run_before (4)
run_before (3..0)
Valor
TotalCoeffs=5, T1s=1
Enviado como -2 (*) (usa Level_VLC0)
3 (usa Level_VLC1)
4 (usa Level_VLC1)
-2 (usa Level_VLC2)
2
ZerosLeft=2; run_before=2
0
Código
0000000110
1
0001
0010
00010
111
0011
00
No requiere código
El bitstream transmitido para este bloque es 000000011010001001000010111001100.
(*): Level (3), con un valor de -3, se codifica como caso especial. Si hay menos de 3
T1s, entonces el primer nivel no-T1 no tendrá un valor de +/-1 (en caso contrario, habría sido
codificado como un T1). Para guardar los bits, este nivel es incrementado si es negativo
(decrementando si positivo), de forma que +/-2 se mapea a +/-1, +/-3 se mapea a +/-2, y así
sucesivamente. Así, se utilizan VLCs más cortas.
Después de codificar el Level (3), la tabla Level_VLC es incrementada porque la
magnitud de este nivel es mayor que el primer umbral (que es 0). Después de codificar el Level
(3), con una magnitud de 4, el número de tabla es de nuevo incrementado porque Level (1) es
mayor que el segundo umbral (que es 3). Tenga en cuenta que el final Level (-2) utiliza un
código diferente del primer Level codificado (también -2).
Decodificación:
Código
0000000110
1
0001
0010
00010
111
0011
00
Elemento
coeff_token
T1 signo
Level
Level
Level
Level
TotalZeros
run_before
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
Valor
TotalCoeffs=5, T1s=3
-2, decodificado como -3
+3
+4
-2
2
2
Array de salida
Vacío
-1
-3, -1
+3, -3, -1
+4, 3, -3, -1
-2, 4, 3, -3, -1
-2, 4, 3, -3, -1
-2, 4, 3, -3, 0, 0, -1
89
Implementación en Java/C++ del Estándar de Video H.264
Todos los ceros han sido decodificados dando lugar al siguiente array de salida:
-2, 4, 3, -3,
- 0, 0, -1.
Este ejemplo muestra cuántos bits son guardados mediante la codificación de
TotalZeros: sólo un único “run” necesita ser codificado incluso si hay 5 coeficientes distintos de
cero.
5.4.3.3 Codificación Aritmética y Adaptativa basada en
en el contexto (CABAC)
Este proceso acepta como argumento una petición del valor de un elemento sintáctico y
los valores de los elementos sintácticos analizados antes y genera como resultado el valor del
elemento sintáctico.
Cuando “entropy_coding_mode” se establece a 1, se usa un sistema de codificación
aritmética para codificar y decodificar elementos de sintaxis H.264. El esquema de codificación
aritmética seleccionado para H.264, Context-based
Context
Adaptive Binary
ry Arithmetic Coding o
CABAC consigue obtener una
na buena compresión mediante:
a) La selección de modelos de probabilidad para cada elemento de sintaxis de acuerdo
a
al
contexto del elemento.
b) La adaptación de las estimaciones probabilísticas basada en estadísticas locales.
c) El uso de codificación aritmética.
Laa codificación de un símbolo de datos requiere las siguientes etapas.
1) “Binarización”: CABAC utiliza codificación aritmética binaria, que significa que sólo
se codifican decisiones binarias (1 ó 0). Un símbolo con valor no binario (por ejemplo,
un coeficiente
te de una transformada o un vector de movimiento) es “binarizado” o
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
90
Implementación en Java/C++ del Estándar de Video H.264
convertido a código binario antes de la codificación aritmética. Este proceso es similar
al procedimiento de conversión de un símbolo de datos a un código de longitud
variable, excepto en que el código binario es además codificado (por el codificador
aritmético) antes de la transmisión.
Las etapas 2, 3 y 4 se repiten para cada “bin” (es como se dice a cada bit de una
secuencia de bits en binario) del símbolo “binarizado”.
2) Selección del modelo de contexto: un modelo de contexto es un modelo de probabilidad
para uno o más “bins” del símbolo “binarizado”. Este modelo puede ser elegido a partir
de una selección de modelos disponibles dependiendo de las estadísticas de los últimos
símbolos de datos codificados. El modelo de contexto almacena la probabilidad de que
cada “bin” sea “1” ó “0”.
3) Codificación aritmética: un codificador aritmético codifica cada “bin” de acuerdo al
modelo de probabilidad seleccionado. Tenga en cuenta que existen dos sub-rangos para
cada “bin” (correspondientes a “0” o a “1”).
4) Actualización de probabilidad: el modelo de contexto seleccionado se actualiza
basándose en el valor codificado real (por ejemplo, si el valor del “bin” era “1”, se
incrementa el contador de frecuencia de “unos”).
El proceso de Codificación.
Se ilustra el proceso de codificación para un ejemplo, MVDx (diferencia de vector de
movimiento en la dirección x).
1) “Binarización” del valor MVDx. La “binarización” se realiza de acuerdo a la siguiente
tabla para | MVDx | < 9 (valores mayores de MVDx son “binarizados” usando una
contraseña de tipo Ex - Golomb).
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
91
Implementación en Java/C++ del Estándar de Video H.264
| MVDx |
0
1
2
3
4
5
6
7
8
“Binarización”
0
10
110
1110
11110
111110
1111110
11111110
111111110
Tenga en cuenta que cada una de estas contraseñas “binarizadas” son únicamente
decodificables. El primer bit de la contraseña “binarizada” es “bin” 1; el segundo bit es “bin” 2;
y así sucesivamente.
2) Elección de un modelo de contexto para cada “bin”. Uno de 3 posibles modelos es
seleccionado para el “bin” 1, basándose en los valores MVD codificados previamente.
La norma L1 de dos valores codificados de la forma anteriormente descrita, ek, se
calcula como se indica a continuación:
ek = | MVDA | + | MVDB |;
donde A y B son los bloques situados inmediatamente a la
izquierda y encima del bloque actual, respectivamente.
ek
Modelo de contexto para el “bin” 1
0 ? ek < 3
Modelo 0
3 ? ek < 33
Modelo 1
33 ? ek
Modelo 2
Si ek es pequeño, entonces existe una alta probabilidad de que el MVD actual
tenga un valor pequeño; y si se trata del caso opuesto, si ek es grande, entonces existe una alta
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
92
Implementación en Java/C++ del Estándar de Video H.264
probabilidad de que el MVD actual tenga un valor mayor. Se selecciona una tabla de
probabilidad (modelo de contexto) de acuerdo a su valor.
Los “bins” restantes se codifican usando uno de los 4 modelos de contexto
complementarios:
“Bin”
1
2
3
4
5
6 y posteriores
Modelo de contexto
0, 1 ó 2 dependiendo de ek
3
4
5
6
6
3) Codificación de cada “bin”. El modelo de contexto seleccionado proporciona dos
estimaciones probabilísticas: la probabilidad de que el “bin” contenga “1”, y la
probabilidad de que el “bin” contenga “0”. Estas estimaciones determinan los dos subrangos que el codificador aritmético utiliza para codificar el “bin”.
4) Actualización de los modelos de contexto. Por ejemplo, si se seleccionó el modelo de
contexto 2 para el “bin” 1 y el valor del “bin” 1 era “0”, el contador de frecuencia de
“ceros” es incrementado. Esto significa que la siguiente vez que se seleccione este
modelo, la probabilidad de un “0” será ligeramente superior. Cuando el número total de
apariciones de un modelo sobrepasa un valor umbral, los contadores de frecuencia de
“ceros” y de “unos” serán reducidos, lo que en efecto da una mayor prioridad a las
observaciones recientes.
Los modelos de contexto
Los modelos de contexto y los esquemas de “binarización” para cada elemento de
sintaxis son definidos en el estándar. Existen un total de 267 modelos de contexto aparte, del 0
al 266 (a septiembre de 2002) para los diferentes elementos de sintaxis. Algunos modelos tienen
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
93
Implementación en Java/C++ del Estándar de Video H.264
diferentes usos dependiendo del tipo de “slice” (o parte): por ejemplo, no se permiten
macrobloques salteados en un “I-slice”, de forma que los modelos del 0 al 2 son los utilizados
para codificar “bins” de “mb_skip” o “mb_type” dependiendo de si el “slice” actual es Intra
codificado.
Al principio de cada “slice” codificado, los modelos de contexto son inicializados
dependiendo del valor inicial del QP (Quantization Parameter) o parámetro de cuantificación
(dado que esto tiene un efecto significativo en la probabilidad de aparición de los diferentes
símbolos de datos).
El motor de la codificación aritmética
El decodificador aritmético se describe en detalle en el estándar. Tiene 3 propiedades
definidas:
1) La estimación probabilística se obtiene mediante un proceso de transición entre 64
estados probabilísticos separados para el “Least Probable Symbol” (LPS, la menos
probable de entre las dos posibles decisiones “0” o “1”).
2) El rango R, que representa el estado actual del codificador aritmético, es cuantificado a
un rango pequeño de valores pre-establecidos antes de calcular el nuevo rango en cada
paso, pudiendo calcular dicho nuevo rango mediante una “look-up table” o tabla de
verdad (evitando así multiplicaciones, por ejemplo).
3) Se define un proceso de codificación y decodificación simplificado para los símbolos de
datos con una distribución de probabilidad casi uniforme.
La definición del proceso de decodificación se diseña para facilitar las
implementaciones de codificación y decodificación de baja complejidad. En general, CABAC
proporciona una eficiencia de codificación mejorada, comparada con VLC, pagando el precio de
una mayor complejidad computacional.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
94
Implementación en Java/C++ del Estándar de Video H.264
5.4.4
Filtro
El filtro se aplica para minimizar el efecto bloque.
La mayoría de los estándares de compresión de vídeo como ITUH, MPEG-4, H.264
usan JPEG relacionado con la técnica de codificación de transformadas basadas en bloques para
explotar la redundancia espacial. La aproximación básica consiste en dividir la totalidad de la
imagen en bloques de 8x8, transformar cada bloque usando la DCT, cuantificados y codificados
por entropía. El paso de cuantificación divide los coeficientes transformados con una tabla de
cuantificación por la que la mayoría de los coeficientes de la DCT de cada bloque caigan dentro
de una zona muerta. Como resultado, sólo existe un coeficiente DC y algunos más a bajas tasas
de bit. El efecto consiste en la pérdida de correlación entre bloques adyacentes y en las
discontinuidades de los bordes de los bloques. Como consecuencia, las imágenes reconstruidas
sufren efectos visualmente desagradables conocidos como efectos de bloque o artefactos de
bloque.
Otra fuente de efectos de bloque en vídeo es la predicción de la compensación de
movimiento. Los bloques de compensación de movimiento son generados copiando los datos de
píxel interpolado a partir de diferentes localizaciones de los marcos de posibles referencias
diferentes. Esto provoca discontinuidades en los bordes de los bloques copiados debido a que
casi nunca existe una relación perfecta para ese dato. Adicionalmente, en los procesos de copia,
las discontinuidades existentes en los bordes de los marcos de referencia son desarrolladas en el
interior del bloque a compensar, que resulta con artefactos visualmente alarmantes.
Existen dos técnicas principales desarrolladas para contar los efectos de bloque: postfiltros y filtros de desbloqueo en bucle. La siguiente tabla muestra los filtros de desbloqueo
empleados por varios estándares de compresión de vídeo. En la técnica de post-filtrado, se
aplica el filtro tras el decodificador usando los parámetros de decodificación.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
95
Implementación en Java/C++ del Estándar de Video H.264
Opera en un buffer del display fuera del bucle de codificación. El uso del post-filtrado
es opcional en la mayoría de los estándares, así como no es una parte normativa de los
estándares.
Los filtros en bucles operan dentro del bucle de codificación. Se aplica el filtro al marco
reconstruido, tanto en el codificador como en el decodificador. Los marcos filtrados se usan
como marcos de referencia para la compensación del movimiento del subsecuente marco
codificado.
Aplicando el filtro dentro de la zona de codificación, se puede mejorar la calidad del
marco reconstruido, cuyos resultados en la mejora de precisión de la predicción de la
compensación de movimiento para el siguiente marco codificado, dado que la calidad de la
referencia de predicción es mejorada. H.264/AVC emplean filtrados adaptativos de desbloqueo
en el bucle a favor de la reducción de los efectos de bloque.
5.4.4.1 H.264/AVC ININ-LOOP DEBLOCKING FILTER
H.264 emplea un “adaptive in-loop deblocking filter” (o filtro de desbloqueo en bucle
adaptativo) después de la codificación de la transformada inversa, para minimizar el efecto
bloque o distorsión, obteniendo dos beneficios principalmente:
1. Los bordes de los bloques son suavizados, mejorando la apariencia de las imágenes
decodificadas, particularmente con altos ratios de compresión.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
96
Implementación en Java/C++ del Estándar de Video H.264
2. El macrobloque filtrado se usa en el caso de que la predicción sea del tipo intra (de
compensación del movimiento) para posteriores frames en el codificador, dando lugar a
menores errores después de la predicción.
Por tanto, el filtro es aplicado a cada macrobloque decidido para reducir los efectos de
bloqueo sin reducir la nitidez de la imagen.
La salida del filtro se usa en la predicción de la compensación de movimiento de los
siguientes marcos. El proceso del filtro de desbloqueo es invocado por los componentes de
luminosidad y crominancia por separado. El filtrado es aplicado a los bordes vertical y
horizontal del bloque, excepto en los límites de la partición.
El orden del filtrado a nivel de macrobloque se muestra en la siguiente figura.
Inicialmente, 4 límites verticales de la componente de luminosidad, por ejemplo VLE1, VLE2,
VLE3 y VLE4, son filtrados. Después, los bordes horizontales de la componente de
luminosidad, por ejemplo HLE1, HLE2, HLE3, y HLE4, son filtrados. Finalmente, los bordes
verticales de la componente de crominancia, VCE1, VCE2, y los bordes horizontales, HCE1 y
HCE2 son filtrados. También se puede alterar la fuerza del filtro o desactivar el filtro.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
97
Implementación en Java/C++ del Estándar de Video H.264
Por tanto, los filtros se aplican según los bordes sean horizontales o verticales, y
escogeremos bloques de 4x4 para la explicación.
A continuación numeramos los tipos de filtros:
Para la componente luma:
•
Filtro de 4 líneas verticales.
•
Filtro de 4 líneas horizontales.
Para cada elemento (i,j) de la componente chroma (o crominancia):
•
Filtro de 2 líneas verticales
Para cada elemento (k,l) de la componente chroma (o crominancia):
•
Filtro de 2 líneas horizontales.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
98
Implementación en Java/C++ del Estándar de Video H.264
Como se puede observar, la operación de filtrado afecta a 3 muestras en cada lado del
borde. Las 4 muestras en el límite vertical o en el horizontal en bloques adyacentes son p0, p1,
p2, p3 y q0, q1, q2, q3 respectivamente, como se muestran en la siguiente figura.
FIGURA 17: las muestras afectadas por un límite vertical y horizontal que separa un macrobloque P y uno Q
La operación de filtrado de desbloqueo se puede dividir en 3 pasos principales, cálculo
de la fuerza de filtrado, decisión de filtrado e implementación del filtrado.
5.4.4.2 CÁLCULO DE LA FUERZA DE FILTRADO
La fuerza de filtrado o cantidad de filtrado se calcula con la ayuda del parámetro
denominado “boundary strength” (Bs, o fuerza de borde). El bS del filtro depende del
cuantificador actual, del tipo de macrobloque, del vector de movimiento, del gradiente de las
muestras de la imagen a lo largo del borde, y de otros parámetros, tal y como se muestra en la
siguiente figura.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
99
Implementación en Java/C++ del Estándar de Video H.264
Dados dos bloques p y q mostrados anteriormente, y los diferentes píxeles adyacentes a
cada borde (p0, p1, p2, p3 y q0, q1, q2, q3):
•
El modo de codificación/predicción es intra para p o para q y el borde se corresponde
con un macrobloque: Bs=4.
•
El modo codificación/predicción es intra para p o para q y el borde no pertenece a un
macrobloque: Bs=3.
•
Ni p ni q se codificó de modo intra pero alguno de los dos contienen coeficientes
codificados. Bs=2.
•
Ni p ni q se codificó de modo intra, ni poseen coeficientes codificados, pero p o q tienen
diferentes frame de referencia o un numero diferente de frame de referencia o diferentes
valores de vectores de movimiento. Bs=1.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
100
Implementación en Java/C++ del Estándar de Video H.264
•
Ni p ni q se codificó de modo intra, ni poseen coeficientes codificados, pero p y q tienen
algún frame de referencia idéntico e idéntico vector de referencia. Bs=0.
Donde la escala es 0, representando no aplicar filtro y 4 representa el filtro más fuerte.
Las reglas de selección de dicho valor se ilustran en el anterior diagrama de flujo. Los
valores del Bs del filtrado de bordes de bloques de crominancia no son calculados
independientemente, y se usan los mismos valores calculados para la luminosidad. La
aplicación de estas reglas da como resultado un filtrado fuerte en las zonas donde existe
distorsión de bloques significante, como bordes de un macrobloque intra-codificado, o bordes
que contengan coeficientes codificados.
5.4.4.3 DECISIÓN DE FILTRADO
La decisión de filtrado no depende sólo de la fuerza de borde no nula, dado que no se
puede comenzar el filtrado sólo sobre la base de una fuerza de borde no nula. El filtrado de
desbloqueo puede no ser necesario, incluso en el caso de fuerza de borde no nula. Esto es
especialmente cierto cuando se tienen transiciones verdaderamente bruscas a lo largo de los
bordes. La aplicación del filtrado a dichos bordes dará como resultado una imagen borrosa.
Cuando los píxeles no varían mucho a lo largo del borde del bloque en regiones muy
suaves, los efectos de bloque son prácticamente despreciables. Por tanto, se necesita otra
condición, además de la fuerza de borde no nula, en la decisión de filtrado.
Como consecuencia, un grupo de muestras del conjunto (p2, p1, p0, q0, q1, q2) es
filtrado sólo si:
(a) Bs > 0, y
(b) |p0-q0|, |p1-p0| y |q1-q0| son cada una menores que un umbral α  y
β, respectivamente; donde α  y β son los umbrales definidos en el estándar
H.264.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
101
Implementación en Java/C++ del Estándar de Video H.264
Los umbrales α y β se incrementan con el parámetro QP (“average quantizer
parameter” o parámetro de cuantificación media) de los dos bloques p y q. El propósito de
la decisión de filtrado es “desconectar” el filtro cuando exista un cambio significante
(gradiente) a lo largo de borde del bloque de la imagen original, lo cual no es debido a la
distorsión de bloque.
La definición de un cambio significante depende de QP. Cuando QP es pequeño, la
pequeña transición a lo largo del borde es debida probablemente a características de la
imagen sin relación con los efectos de bloque, por lo que deberían preservarse manteniendo
los valores de los umbrales α y β a niveles pequeños. Cuando QP es grande, la distorsión
de bloque probablemente sea significante y los umbrales α y β sean mayores, de forma
que más muestras de bordes serán filtradas.
5.4.4.4 IMPLEMENTACIÓN DEL FILTRADO
El filtrado de desbloqueo de la luminosidad se desarrolla en cuatro bordes de 16
muestras, y en dos bordes de 8 muestras para los componentes de crominancia, en las
direcciones horizontal y vertical, respectivamente.
Las siguientes reglas se aplican en la implementación del filtrado:
(a) Los valores de píxel de encima y de la izquierda del MB actual que puedan haber
sido modificados por el filtro en MBs previos, se usarán como entrada al filtro del actual
MB y podrán ser modificados durante el filtrado del MB actual.
(b) Los valores de píxel modificados durante el filtrado de bordes verticales son
utilizados como entrada al filtrado de bordes horizontales para el mismo MB.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
102
Implementación en Java/C++ del Estándar de Video H.264
(c) Los valores de píxel modificados durante los filtrados de bordes previos se usan
como entrada al filtrado del siguiente borde tanto para la dirección horizontal como para la
vertical.
El procedimiento del cálculo de muestras de píxel filtradas es como se explica a
continuación. Cuando los valores enteros de la fuerza de borde son de 1 a 3, los pasos
requeridos para el cálculo de muestras filtradas es:
1. Se aplica un filtro de 4 pasos con entradas p1, p0, q0, q1, produciendo las
salidas filtradas p’0 y q’0.
2. Si |p2-p0| es menor que el umbral β, entonces se aplica otro filtro de 4 pasos con
entradas p2, p1, p0, q0, produciendo la salida filtrada p’1 para la componente
luminosidad únicamente.
3. Si |q2-q0| es menor que el umbral β, entonces se aplica otro filtro de 4 pasos con
entradas q2, q1, q0, q0, produciendo la salida filtrada q’1 para la componente
luminosidad únicamente.
Cuando el valor entero de la fuerza de borde es igual a 4, se usa el siguiente
procedimiento para obtener la salida filtrada:
1. Si |p2-p0| es menor que el umbral β,|p0-q0| es menor que el umbral α /4 y el
bloque actual es de luminosidad, entonces p’0 es producida por un filtrado de 5
pasos de p2, p1, p0, q0, q1; p’1 por un filtrado de 4 pasos de p2, p1, p0, q0; y
p’2 es producida por un filtrado de 5 pasos de p3, p2, p1, p0, q0.
2. En caso contrario, p’0 es producida por un filtrado de 3 pasos de p1, p0 y q0.
3. Si |q2-q0| es menor que el umbral β,|p0-q0| es menor que el umbral α /4 y el
bloque actual es de luminosidad, entonces q’0 es producida por un filtrado de 5
pasos de q2, q1, q0, p0, p1; q’1 por un filtrado de 4 pasos de q2, q1, q0, p0; y
q’2 es producida por un filtrado de 5 pasos de q3, q2, q1, q0, p0.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
103
Implementación en Java/C++ del Estándar de Video H.264
4. En caso contrario, q’0 es producida por un filtrado de 3 pasos de q1, q0 y p0.
El procedimiento de la generación de los valores de las muestras filtradas se ilustra
en la siguiente figura.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
104
Implementación en Java/C++ del Estándar de Video H.264
5.5 Comparativa del estándar.
5.5.1
H264 vs Otros.
Dentro de los estándares de nueva generación de la serie MPEG, destacan dos de ellos:
H.264, cuyo nombre oficial es AVC, y UIT-T H.263 que es ampliamente utilizado para sistemas
de videoconferencia.
De la estandarización de los códecs de vídeo, H.264 es el más actual de los publicados
conjuntamente por los organismos ITU-T y MPEG. A continuación mostramos una secuencia
temporal de los diferentes estándares emitidos:
FIGURA 18: desarrollo de los estándares de MPEG y de ITU-T
Con este estándar pretendían dar una solución abierta y sin complicar el diseño
notablemente, pero que se consiguiese una mejor calidad de imagen con tasas binarias
notablemente inferiores (bitrate).
A continuación se presenta una tabla comparativa de los estándares de MPEG:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
105
Implementación en Java/C++ del Estándar de Video H.264
Característica
Tamaño del
Macrobloque
MPEG-2
MPEG-4 Part 2
MPEG-4 Part 10
16x16 (modo cuadro)
16x16
16x16
Tamaño de bloque
8x16 (modo campo)
Predicción intra
No
Transformada
DCT 8x8
Dominio de la
transformada
DCT wavelet 8x8
Cuantificación escalar
Cuantificación
con tamaño constante
entre pasos del
entropía
Exactitud de las
muestras de la imagen.
Cuadros de Referencia
Modo de predicción
bidireccional
8x8 4x4 DCT entera
4x4 2x2 Hadamard
Cuantificación escalar
Cuantificación vectorial
cuantificador
Codificación de la
Dominio espacial
con tamaño entre pasos
de 12.5% de la
velocidad binaria
VLC, CAVLC,
VLC
VLC
½ muestra
¼ muestra
¼ muestra
1 cuadro
1 cuadro
Múltiples cuadros
CABAC
adelante / atrás
Adelante / atrás
Adelante /atrás
atrás / atrás
backward / backward
Predicción con peso
No
No
Si
Filtro de desbloqueo
No
No
Si
Tipo de Cuadros
I, P, B
I, P, B
I, P, B, SI, SP
Perfiles
5 perfiles
8 perfiles
7 perfiles
Acceso Aleatorio
Si
Si
Si
Partición de datos, FEC
Resistencia a errores.
para transmisión de
paquetes por
importancia
Velocidad de
transmisión
Complejidad del
Codificador
Compatibilidad con
estándares previos
Sincronización,
partición de datos,
extensión de
encabezados, VLCs
reversibles
Partición de datos,
ajuste de parámetros,
orden flexible de
macrobloques,
rebanadas redundantes,
rebanadas tipo SP y SI
2-15 Mbps
64 Kbps - 2 Mbps
64 Kbps - 150 Mbps
Mediana
Mediana
Alta
Si
Si
No
Tabla 5: Comparativa entre estándares previo y H.264
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
106
Implementación en Java/C++ del Estándar de Video H.264
En cuanto a la eficiencia de la codificación, se ha demostrado que el estándar H.264 ha
supuesto una mejora significativa al que se corresponde con el MPEG parte 2.
Las principales diferencias se pueden hallar en la estructura de bloques funcionales del
algoritmo. Por ejemplo, compensación de movimiento en bloques de tamaño variable,
interpolación para exactitud fraccional, filtro de desbloqueo adaptativo, slices de tipo SI y SP,
mayor resistencia a los errores que los estándares anteriores, transformada 4x4, predicción con
carga, CABC, CAVLC y predicción direccional para codificación INTRA.
5.5.2
Diferentes implementaciones de H264.
Entre otros estudios, hemos encontrado uno que indica para diferentes resoluciones de
video, tamaños, medios de transmisión y procesadores, medidas de carga computacional para un
grupo de implementaciones del Códec H.264.
Estas implementaciones son:
Codecs:
•
XviD (MPEG-4 ASP códec)
•
MainConcept H.264
•
Intel H.264
•
x264
•
AMD H.264
•
Artemis H.264
El test se ha realizado para tres aplicaciones diferentes que difieren entre ellas por
resolución, bitrate y requisitos de velocidad de codificación:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
107
Implementación en Java/C++ del Estándar de Video H.264
•
Videoconferencias: (bitrate de 50~400 kbps).
•
Vídeos: (bitrate de 500~1500 Kbps).
•
Televisión en alta definición (HDTV): (bitrate de 1~10 Mbps)
Limitaciones presentadas por cada tipo de aplicación
Videoconferencias: (para 200 kbps).
•
Mínimo 60 fps para valores de alta velocidad. (“High Speed”).
•
Mínimo 30 fps para valores de Alta calidad (“High Quality”)
Vídeos: (para 750 Kbps).
•
Mínimo 15 fps para valores de alta velocidad. (“High Speed”).
•
Mínimo 4 fps para valores de Alta calidad (“High Quality”)
Televisión en alta definición (HDTV): (para 3 Mbps y secuencias
secuenci 1280x720)
•
Mínimo 4 fps para valores de alta velocidad. (“High Speed”).
•
Mínimo 1 fps para valores de Alta calidad (“High Quality”)
Medidas de calidad: Ratios.
Para medir la calidad se ha utilizado: peak-to-peak
peak
signal-to-noise
noise ratio o PSNR.
Videoconferencia.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
108
Implementación en Java/C++ del Estándar de Video H.264
Para interpretar las tablas que se presentan a continuación indicar que cada fila y cada
columna se corresponde con un códec y cada intersección, que corresponde con una celda, es la
comparación de la media de ratio
Media de ratios de bitrate medidos mediante PSNR, para las mismas condiciones
usando secuencias de videoconferencia y prestaciones de High Speed:
Podemos observar que MainConcept es la mejor implementación del estándar para
videoconferencias, ya que el bitrate, cuanto menor, mejor es el códec.
Media de ratios de bitrate medidos mediante PSNR, para las mismas condiciones
usando secuencias de videoconferencia y prestaciones de High Quality:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
109
Implementación en Java/C++ del Estándar de Video H.264
Como vemos MainConcept es también el mejor para videoconferencia con la prestación
de alta calidad,.
Vídeos.
Se han probado los diferentes códecs para diferentes películas obteniendo que,
dependiendo de ésta los resultados son diferentes.
Para High Quality:
Se ha realizado una prueba para la película Battle:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
110
Implementación en Java/C++ del Estándar de Video H.264
Vemos que para el modo de Alta Calidad de compresión, la mejor implementación de
H.264 es X264. Sin embargo, para la película “El señor de los Anillos”:
Es MainConcept la mejor implementación (menor bitrate).
Para High Speed:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
111
Implementación en Java/C++ del Estándar de Video H.264
Aquí para la misma película, “Battle” vemos el gráfico:
Cabe destacar que, siendo mejor la implementación x264, es muy próxima a
MainConcept. También se observa la clara inestabilidad de la implementación de Artemis para
x264.
Para “El Señor de los Anillos”:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
112
Implementación en Java/C++ del Estándar de Video H.264
Aquí de nuevo vemos que es MainConcept el que destaca sobre los demás, aunque
sigue estando muy seguido de los demás.
En este apartado hemos encontrado además un dato a resaltar. Se trata de la velocidad
de codificación:
AMD es, para una prestación de Alta Calidad, claramente superior al resto, lo que
implica que, para no tener una calidad ni una velocidad muy inferior, se consigue una alta
velocidad de codificación.
Televisión de Alta Definición (HDTV)
Para High Speed, la comparación de los códecs queda de la siguiente manera:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
113
Implementación en Java/C++ del Estándar de Video H.264
Nos encontramos que MainConcept es superior al resto menos para Artemis, cuya
comparación es superada por la implementación de Intel.
En este caso es mejor para todas las comparaciones la implementación x264.
Resumen
Para la videoconferencia:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
114
Implementación en Java/C++ del Estándar de Video H.264
Las mejor implementaciones son x264 y MainConcept según los resultados obtenidos,
siendo este último la mejor alternativa de los dos por muy poco. El que peor calidad aporta es el
codificado de AMD, que como contrapunto es 5 veces más rápido que XviD.
Para el video o películas:
Los líderes no difieren de la videoconferencia aunque se intercambian dependiendo de
la película y AMD sigue siendo el que peor calidad aporta.
Televisión de Alta Calidad:
Aquí depende de qué estemos midiendo, si las prestaciones son relativas u orientadas a
la calidad, destaca x264 y si son relativas a la velocidad, destaca MainConcept.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
115
Implementación en Java/C++ del Estándar de Video H.264
6 Aplicaciones de H.264.
H.264.
En este apartado, pretendemos exponer algunas de las aplicaciones para las cuales se
está adoptando el estándar H.264.
6.1 Videoconferencia.
Que el video digital está en auge es un hecho constatado, como lo introducíamos al
principio del documento. Algunos expertos apuntan a que el desarrollo de las normas de
codificación está impulsando la ampliación del uso del video digital y su difusión por internet.
Además de ofrecer una mejor calidad de imagen, se va perfeccionando la compresión
para que esta calidad no suponga un gasto computacional o de ancho de banda, y se pueda
almacenar más información en menos espacio en medios como DVD o Discos externos. Como
muestra de los beneficios del protocolo H.264, éste permite obtener calidad de DVD en
transferencias de 1 MBPS, lo cual permite obtener videos con calidad de DVD en tiempo real a
través de Internet con conexiones de al menos 1MBPS.
Entre los sectores que se benefician altamente de las bondades de este estándar se
incluyen la videoconferencia, la radiodifusión de vídeo, el vídeo en tiempo real en dispositivos
móviles, la telemedicina y la tele-educación.
El H.264 posee un estándar previo, el H.263 que está más extendido en este ámbito, no
obstante, H.264 proporciona un alto nivel de eficiencia de compresión, lo que permite que los
videoconferenciantes experimenten casi el doble de calidad en el video a través del mismo
ancho de banda que actualmente utilizan. Además supone una optimización de los recursos de la
red y rentabiliza, desde el punto de vista empresarial, el uso de las videoconferencias.
Actualmente existen muchas empresas líderes en sistemas de videoconferencia que han
participado en el desarrollo del H.264 y ofrecen sistemas que obtienen el doble de eficiencia de
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
116
Implementación en Java/C++ del Estándar de Video H.264
compresión de video de alta calidad usando 384 Kbps en lugar de los casi 800 Kbps a los que
nos tenían acostumbrados.
6.2 Videovigilancia.
Videovigilancia.
Como hemos mencionado en el documento numerosas veces, con este estándar se
consigue comprimir los datos para su almacenamiento y para su transmisión, respetando la
calidad del video y del audio.
Para la aplicación de videovigilancia, se obtienen resultados muy buenos debido a que
en el estándar se define una escena como una representación codificada de objetos audiovisuales
y relacionados mediante el espacio y el tiempo en árboles de bloques, como hemos visto en
apartados anteriores. Cada nodo de este árbol, puede ser elementos primitivos como el fondo
(una imagen fija) objetos (personas moviéndose), objetos de audio y las cabeceras.
Los objetos tienen algunas propiedades adjuntas, como sus coordenadas espaciales,
escala, localización, zoom, rotación… y permiten reconstruir la secuencia original tras codificar
todas las capas de los objetos.
En los sistemas de videovigilancia se necesita transmitir o almacenar grandes cantidades
de video a una calidad, cuanto menos, aceptable, pero utilizando poco ancho de banda o espacio
en disco.
Dado que existen muchos parámetros configurables, para este tipo de aplicación se
necesita realizar un estudio para compensar diferentes características que son, en muchas
ocasiones contradictorias.
Por ejemplo. Un factor a tener en cuenta es la luminosidad. Puede utilizarse una
implementación/configuración diferente e estándares si una cámara de videovigilancia se
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
117
Implementación en Java/C++ del Estándar de Video H.264
encuentra en una zona poco luminosa. Con lo cual, la elección deberá realizarse utilizando
medidas tomadas en diferentes días a diferentes horas y hallar la media.
El sistema conseguirá una mayor ventaja del estándar H.264 si el dispositivo de captura
es la limitación de dicho sistema, porque tiene más procesos en funcionamiento o porque el
dispositivo debe capturar desde varias cámaras, el mejor es H.264.
El estándar consume menos carga computacional debido, entre otras cosas, a la
descomposición en imágenes que realiza:
Con la codificación diferencial, sólo se codifica entera la primera imagen (fotograma I).
En las dos imágenes siguientes (fotogramas P), existen referencias a la primera imagen en lo
que se refiere a elementos estáticos, como la casa, mientras que sólo se codifican las partes
móviles, como el hombre que corre, usando vectores de movimiento y reduciendo así la
cantidad de información que se envía y almacena
Otra de las ventajas que posee el H.264 en la aplicación de videovigilancia, es que
puedes encontrarte en determinados momentos con una gran cantidad de movimiento y perder
toda la ventaja. Sin embargo, este problema se soluciona o se ve mitigado por la
implementación de la compensación de movimiento basada en los bloques de píxeles.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
118
Implementación en Java/C++ del Estándar de Video H.264
Esto, que hemos explicado anteriormente sobre la predicción del movimiento y la
diferencia de éste con el real. De una manera práctica, la imagen que se expone a continuación
muestra la descomposición de las imágenes:
Lo que se envía por la cámara de videovigilancia es la imagen residual y el modo de
predicción interna. En destino se realiza la predicción y se suma la imagen residual obteniendo
la imagen de salida. Como se puede observar se obtienen buenos resultados con esta
codificación, y es a consecuencia de las mejoras introducidas en H.264.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
119
Implementación en Java/C++ del Estándar de Video H.264
7 Análisis conceptual de la aplicación.
7.1 Descripción de los recursos utilizados.
utilizados.
7.1.1
Introducción.
Esta aplicación trata de realizar una demostración de la calidad de diferentes formatos.
De una manera subjetiva, puede apreciarse la calidad de video si se muestra en comparación con
otros. De una manera objetiva puede medirse la tasa de bits para la misma resolución, ancho de
banda en la transmisión….
Se requiere implementar una aplicación que muestre una comparación entre diferentes
formatos de HD, según se escoja por el usuario.
7.1.2
Componentes utilizados.
Para realizar la aplicación se utilizarán los siguientes programas:
7.1.2.1 FFMPEG:
Ffmpeg es un programa sin interfaz gráfica que permite convertir o transformar entre
formatos multimedia, tanto de video como de audio. Aunque existen otros programas, algunos
sin necesidad de usar comandos, es una de las opciones más completas y eficaces. Se trata de
una aplicación de desarrollo bajo la licencia GPL.
Viene con 3 opciones de aplicación:
•
FFmpeg: es una herramienta en línea de comandos para convertir _cheros de
vídeo, flujos de red o la entrada de una tarjeta de TV a varios formatos de vídeo.
•
FFserver: es un servidor de flujo para todo lo que FFmpeg pueda usar como
entrada (_cheros, ujos, entrada de la tarjeta de TV, cámara web, etc)
•
FFplay: es un reproductor de medios muy simple y portable que utiliza las
librerías FFmpeg y la librería SDL.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
120
Implementación en Java/C++ del Estándar de Video H.264
Esta librería viene incluida por defecto en las últimas ediciones de Linux.
El manejo se realiza por línea de comandos usando una sintaxis que intenta ser intuitiva,
aunque esta característica se ve disminuida por la cantidad de parámetros que se pueden
modificar. No obstante muchos de ellos se pueden deducir automáticamente. Normalmente solo
tienes que introducir el bit rate que quieras obtener.
Con esta librería puedes convertir desde una tasa de muestreo a otra, y modificar el
tamaño del video con un filtro multifase de alta calidad.
La manera general de uso es:
ffmpeg [[infile options][`-i' infile]]... {[outfile options] outfile}
Con esta aplicación puedes agregar subtítulos, redimensionarlo, y , por supuesto,
convertirlo a otro formato.
Esta aplicación se utilizará para realizar las mediciones y las conversiones a otros
formatos.
7.1.2.2 FFPLAY
Es el reproductor que viene con la aplicación FFMPEG. Se utilizará en el programa para
mostrar los vídeos en diferentes formatos con la misma resolución.
La forma general de usarlo es con la siguiente sintaxis:
ffplay [options] `input_file'
Entre las opciones se encuentra la que vamos a utilizar con mayor frecuencia para poder
mostrar los efectos de la compresión sobre las imágenes y es mostrar los vectores
`-vismv':Visualize motion vectors
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
121
Implementación en Java/C++ del Estándar de Video H.264
7.2 Metodología.
La metodología a seguir se tratará de Extreme Programing (XP)
Es una de las metodologías de desarrollo de software más exitosas en la actualidad
utilizadas para proyectos de corto plazo, pequeños equipos y cuyo plazo de entrega es
inmediato. La metodología consiste en una programación rápida o extrema, cuya particularidad
es tener como parte del equipo, al usuario final, pues es uno de los requisitos para llegar al éxito
del proyecto.
Características de XP, la metodología se basa en:
•
Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos, de tal
manera que adelantándonos en algo hacia el futuro, podamos hacer pruebas de los fallos
que pudieran ocurrir. Es como si nos adelantáramos a obtener los posibles errores.
•
Refabricación: se basa en la reutilización de código, para lo cual se crean patrones o
modelos estándares, siendo más flexible al cambio.
•
Programación en pares: una particularidad de esta metodología es que propone la
programación en pares, la cual consiste en que dos desarrolladores participen en un
proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el
otro no está haciendo en ese momento. En este caso, al tratarse de un solo desarrollador,
no se puede utilizar este principio.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
122
Implementación en Java/C++ del Estándar de Video H.264
Planificación
Prueba
XP
Diseño
Programación
FIGURA 19:
1 esquema de metodología Extrem Programming.
Las fases que define esta metodología son las siguientes:
FIGURA 20: esquema fases de la metodología Extrem Programming.
No obstante, dado que la aplicación no es excesivamente grande y no es excesivamente
compleja,
mpleja, solo se especificará el nivel 1 del anterior diagrama:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
123
Implementación en Java/C++ del Estándar de Video H.264
Aplicación
Planificación
Diseño
Desarrollo
Pruebas
7.3 Planificación y Requisitos.
Requisitos.
Siguiendo la metodología antes descrita, realizaremos a la vez la Planificación y la
especificación de requisitos, dejando para la siguiente fase, los objetivos a cumplir y cuando
deben estar realizados. A partir del siguiente documento, se realizará el diseño de cada fase.
Tabla 6: RQ-01 Comparar videos.
RQ-01 Comparar videos.
Se debe poder comparar al menos dos vídeos en formatos diferentes a la vez
en la misma pantalla. El proceso será el siguiente:
El usuario elegirá la opción comparar dos videos.
Deberá elegir el primero y dará Aceptar.
El sistema comprobará la extensión, dará un mensaje de error si no es de los
reconocidos y volverá a la pantalla principal.
Deberá elegir el segundo vídeo y dará Aceptar.
El sistema comprobará la extensión, dará un mensaje de error si no es de los
reconocidos y volverá a la pantalla principal.
El sistema reproducirá los dos videos para que éstos comiencen a la vez. (no se
puede utilizar sincronizado porque depende de la codificación utilizada.
Fecha de Finalización : 31 / 08 / 2009
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
124
Implementación en Java/C++ del Estándar de Video H.264
Tabla 7: RQ-02 Convertir videos.
RQ-02 Convertir videos.
Se debe poder convertir de un formato origen a alguno de los formatos
conocidos y proporcionados por la librería FFMPEG:
El usuario elegirá la opción convertir video.
Deberá elegir el video y dará Aceptar.
El sistema comprobará la extensión, dará un mensaje de error si no es de los
reconocidos y volverá a la pantalla principal.
Deberá elegir el formato del vídeo destino y dará Aceptar.
El sistema comprobará la extensión, dará un mensaje de error si no es de los
reconocidos y volverá a la pantalla principal.
El sistema convertirá de manera transparente al usuario el video e
informará cuando llegue al final.
Fecha de Finalización: 31/08/2009
Tabla 8: RQ-03 Mostrar características de un vídeo.
RQ-03 Mostrar características de un vídeo.
Se debe poder visualizar las características del formato de compresión del
video.
El usuario elegirá la opción mostrar características del video.
Deberá elegir el video y dará Aceptar.
El sistema comprobará la extensión, dará un mensaje de error si no es de los
reconocidos y volverá a la pantalla principal.
El sistema mostrará por pantalla las características del formato.
Fecha de Finalización 31/08/2009
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
125
Implementación en Java/C++ del Estándar de Video H.264
Estos tres requisitos deberán estar cumplimentados para las fechas indicadas en la parte
inferior de cada tabla. Esto implica todas las etapas de su desarrollo, incluida la prueba de
validación.
7.4 Diseño
Según el creador de esta metodología Kent Beck. en cualquier momento el diseño
adecuado para el software es aquel que: supera con éxito todas las pruebas, no tiene lógica
duplicada, refleja claramente la intención de implementación de los programadores y tiene el
menor número posible de clases y métodos.
Por ello hemos decido seguir una notación propia basada en UML para simplificar y
realizar con mayor rapidez el diseño de la aplicación. No obstante, recogerá también los
principios de calidad de software, como pueden ser la fiabilidad y la sencillez.
El diseño se realizará mediante una interfaz gráfica con tres botones que de la
posibilidad al usuario de elegir cada una de las opciones planteadas por los requisitos.
Clase principal:
Realizará el control de la interfaz y llamará a las clases pertinente que ejecutarán el
código.
Clase Runtime de JAVA
Capturará el control y ejecutará las sentencias pasadas por parámetro.
Librería FFMPEG
Se ejecutará con las opciones indicadas por parámetro.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
126
Implementación en Java/C++ del Estándar de Video H.264
8 Conclusiones y trabajos futuros.
El estudio se ha realizado con la idea de facilitar futuros desarrollos basados en la
programación del estándar.
Aunque parezca imposible a día de hoy hablar de un estándar internacional y único para
formato de compresión y codificación de vídeo, lo cierto es que con este estándar y por las
aplicaciones y artículos que he leído, está obteniendo muchas críticas positivas para casi todas
las aplicaciones.
La principal ventaja es que parece obtener muy buena calidad por mayor velocidad y
menor bitrate para casi todos los tipos de aplicaciones, como puede ser la videoconferencia o
como puede ser DVD en HD.
Dado que ha recibido buena aceptación entre el mundo del video digital y se han
realizado numerosas implementaciones con buenos resultados, es probable que el conjunto
formado por las dos organizaciones defina en el estándar la parte que aun está inconclusa.
Otro de los motivos por los que, en mi opinión este estándar es bien aceptado, es debido
a que la especificación es lo suficientemente restrictiva como para que pueda estandarizarse,
pero lo suficientemente flexible como para poder adaptar a una aplicación, los diferentes
perfiles según se requiera rapidez o calidad.
En cuanto a las conclusiones académicas, el proyecto me ha servido en gran medida
para estudiar un tema que siempre me ha llamado la atención y el cual no es estudiado durante
la carrera con tanta profundidad.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
127
Implementación en Java/C++ del Estándar de Video H.264
Asimismo, he podido aprender en diferentes temas, desde la base matemática y
estadística del mismo, hasta la parte de medición de la calidad, pasando por las aplicaciones y el
estudio del estado actual de las comunicaciones y el video digital.
Me he encontrado, como parte llamativa del proyecto muchos proyectos de
implementación libre del estándar –FFmpeg utiliza x264, la implementación libre del estándar-,
a mucha gente trabajando en realizar una buena optimización de esas implementaciones libres y,
en numerosos casos superan con creces a las implementaciones que no son libres-como casi
todas las aplicaciones de videoconferencia-.
Como último dato, decir que pese a que la especificación del estándar sea libre, lo cierto
es que para realizar la implementación se han de pagar al menos 5 patentes, pese a que el
estándar sea abierto, no se ha conseguido que los algoritmos que utiliza lo sean.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
128
Implementación en Java/C++ del Estándar de Video H.264
9 Bibliografía.
[ITU-T]
[TECHNO]
[SENIORIEEE]
[VILLA]
Página oficial de International Telecommunication Union
http://www.itu.int/en/pages/default.aspx
Página web de Techotrends.
Overview of the H.264/AVC Video Coding Standard:
THOMASWIEGAND, GARY J. SULLIVAN, Senior Member, IEEE,
GISLE BJØNTEGAARD, and AJAY LUTHRA, Senior Member, IEEE
Bog de DIEGO VILLA
[RUIZ]
El h.264 un nuevo estándar para compresión de video y su aplicación a la
videoconferencia: ING. ROSALBA RUIZ ABREU
[JARDONC,198
5]
La codificación perfecta: CARLOS MARIA FERNANDEZ-JARDONC.
Universitario de Vigo
[ATDS,2008]
Apuntes de Aplicaciones del tratamiento digital de señales, curso 20082009: Universidad Carlos III de Madrid
[SHI- SUN,99]
Image and video compression: Fundamentals, Algorithms and standards.
YUN Q SHI Y HUIFANG SUN.
[NCESD.NET]
http://www.ncesd.net/IVC/H323/CodecH264.htm
[WIPRO.COM]
http://www.wipro.com/insights/mpeg4videocoding.htm
[ACIS.ORG]
http://www.acis.org.co/Paginas/noticias/NuevaNoticia.asp?Not_ID=2893
[PUG.COM]
http://www.pug.com/resources/PUG%20Press%20Releases/2-AprilJune-2003/H.264.pdf
[VCODEX]
http://www.vcodex.com/h264.html
[FFMPEG]
http://ffmpeg.org
[UNGE-DUQ]
[DUR-BER]
Transmisión de multimedia en Internet y FFmpeg. MARIO
UNGEMACH y SEBASTIÁN DUQUE
Metodología para la Elicitación de Requisitos de Sistemas Software
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
129
Implementación en Java/C++ del Estándar de Video H.264
ANEXO A: PLAN DE GESTIÓN
DEL PROYECTO
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
130
Implementación en Java/C++ del Estándar de Video H.264
10 Anexo I: Plan de gestión del Proyecto.
10.0 Índice del Plan de Gestión
10.0
Índice del Plan de Gestión ......................................................................................... 131
10.1
Planteamiento ............................................................................................................ 134
10.1.1
Sumario. ............................................................................................................. 134
10.1.1.1
Propósito, Alcance y Objetivo. ................................................................... 134
10.1.1.2
Restricciones y Asunciones. ....................................................................... 136
10.1.1.3
Entregables. ................................................................................................ 137
10.1.1.4
Resumen de la Planificación y el Presupuesto............................................ 139
10.1.2
Evolución del Plan de Gestión del Proyecto. ..................................................... 141
10.2
Referencias. ............................................................................................................... 142
10.3
Definiciones. .............................................................................................................. 143
10.4
Organización. ............................................................................................................. 145
10.4.1
Interfaces Externos. ............................................................................................ 145
10.4.2
Estructura Interna. .............................................................................................. 145
10.4.2.1
10.5
Organigrama con los flujos de información y de control (de gestión). ....... 149
Gestión ....................................................................................................................... 151
10.5.1
Gestión de Lanzamiento. .................................................................................... 151
10.5.1.1
Recursos Humanos. .................................................................................... 151
10.5.1.2
Recursos Materiales.................................................................................... 151
10.5.1.3
Plan de Formación ...................................................................................... 152
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
131
Implementación en Java/C++ del Estándar de Video H.264
10.5.2
Planificación del Trabajo. .................................................................................. 152
10.5.2.1
Actividades a Realizar ................................................................................ 152
10.5.2.2
Planificación de Actividades. ..................................................................... 155
10.5.2.3
Asignación de Recursos.............................................................................. 156
10.5.2.4
Asignación Presupuestaria. ......................................................................... 157
10.5.3
Plan de Control................................................................................................... 157
10.5.3.1
Control de Requisitos. ................................................................................ 157
10.5.3.2
Control de la Planificación. ........................................................................ 160
10.5.3.3
Control Presupuestario. .............................................................................. 160
10.5.3.4
Control de Calidad ...................................................................................... 161
10.5.3.5
Informes de Seguimiento ............................................................................ 161
10.5.3.6
Métricas de Control. ................................................................................... 162
10.5.4
Plan de Gestión de Riesgo .................................................................................. 162
10.5.5
Plan de Cierre, .................................................................................................... 163
10.6
Tecnología ................................................................................................................. 164
10.6.1
Modelo de Procesos. .......................................................................................... 164
10.6.2
Métodos, Herramientas y Técnicas. .................................................................. 168
10.6.3
Infraestructura. ................................................................................................... 169
10.6.4
Aceptación de productos: ................................................................................... 169
10.7
Soporte ....................................................................................................................... 171
10.7.1
Plan De Gestión De La Configuración ............................................................... 171
10.7.1.1
Identificación De Los Elementos De La Configuración ............................. 171
10.7.1.2
Control de Cambios de la Configuración ................................................... 172
10.7.1.3
Definición y Gestión de los Puntos de Control de la Configuración .......... 172
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
132
Implementación en Java/C++ del Estándar de Video H.264
10.7.1.4
Realización de Informes del Estado de la Configuración. .......................... 172
10.7.1.5
Control del Proceso de Edición de los Elementos Documentales .............. 173
10.7.2
Plan de verificación y validación. ...................................................................... 173
10.7.2.1
Organización del Equipo de Verificación y Validación. ............................ 173
10.7.2.2
Descripción De Los Elementos Sujetos A Verificación Y Validación ....... 173
10.7.2.3
Identificación De Las Actividades A Realizar Para La V&V .................... 174
10.7.2.4
Planificación De Las Actividades De Verificación y Validación ............... 174
10.7.2.5
Listas de Comprobación. ............................................................................ 175
10.7.3
Plan de Garantía de Calidad. .............................................................................. 175
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
133
Implementación en Java/C++ del Estándar de Video H.264
Plan de Gestión del Proyecto
10.1 Planteamiento
10.1.1 Sumario.
10.1.1.1 Propósito, Alcance y Objetivo.
El Proyecto trata de realizar un estudio sobre las implementaciones y usos del estándar
de vídeo H.264 sobre plataformas Open Source, así como un repaso sobre sus mejoras y
características esenciales. Asimismo, el proyecto tratará de justificar mediante una pequeña
aplicación, los valores obtenidos por el estándar en cuanto a consumo de ancho de banda y
bitrate, para una alta calidad de imagen.
A modo de resumen se establece que se trata de estudiar el funcionamiento y las
características del estándar en cada una de las siguientes fases:
Así pues, se requieren una serie de puntos relacionados con los siguientes componentes:
1. Estudio del estándar que concluirá en un repaso de sus características
esenciales.
2. Estudio del uso del estándar y posibles aplicaciones.
3. Aplicaciones libres que lo implementen.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
134
Implementación en Java/C++ del Estándar de Video H.264
4. Comparativa del uso en los diferentes ámbitos de aplicación con otros
estándares.
5. Por otra parte, se procederá a realizar los siguientes puntos mediante una
pequeña aplicación SW.
6. Mediciones reales sobre vídeos de Formato H.264.
7. Usos y muestras de las diferentes aplicaciones estudiadas.
8. Representación de las diferencias entre estándares.
9. En cuanto a los diferentes objetivos del desarrollo del este Proyecto Fin de
Carrera nos encontramos con:
OBJ-001: Estudio de Procesado de imagen Digital
Descripción: Entender la adquisición y el procesamiento de las imágenes digitales y del vídeo
digital, así como su almacenamiento y posterior procesado.
OBJ-002: Estudio del Estándar H.264
Descripción: Leer el estándar y entender, con la mayor profundidad posible, las características
y funcionamiento del mismo, realizando un resumen detallado.
OBJ-003: Estudio de las Aplicaciones
Descripción: Realizar un estudio práctico de las aplicaciones principales que, en la actualidad,
implementan este estándar y son utilizados en el mercado actual.
OBJ-004: Comparativa con otros estándares
Descripción: Realizar, mediante un estudio, una comparativa sobre otros estándares en
diferentes ámbitos y aplicaciones prácticas.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
135
Implementación en Java/C++ del Estándar de Video H.264
10.1.1.2 Restricciones y Asunciones.
Las asunciones del proyecto vienen especificadas en el apartado anterior y se componen
del alcance y los objetivos cumplimentados.
En cuanto a las restricciones del proyecto se pueden agrupar de la siguiente manera:
Tiempo
El Proyecto Fin de Carrera (en adelante PFC) se desarrollará en el transcurso del curso
escolar correspondiente a 5º de IINF. Este periodo puede extenderse hasta septiembre del 2009.
Disponibilidad
El transcurso del desarrollo del PFC deberá compaginarse con las demás asignaturas
impartidas en el curso, siendo condición indispensable, superar todas las asignaturas para la
presentación del mismo. Esto afecta a la disponibilidad del alumno en cuanto al desarrollo del
Proyecto.
El desarrollo del Proyecto se realizará bajo las especificaciones de la empresa
Telefónica, con lo cual, las consultas o dudas sobre el proyecto estarán sujetas a la
disponibilidad de los empleados destinados al proyecto.
Software
La implementación libre escogida para el estudio deberá estar desarrollada en Java o en
C++, asimismo, la aplicación a desarrollar para las pruebas deberá estar desarrollada en los
mismos lenguajes de programación.
Documentación, estándares y restricciones generales.
La especificación del códec H.264 deberá ser la estándar:
•
ISO/IEC 14496-10 - MPEG-4 Part 10).
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
136
Implementación en Java/C++ del Estándar de Video H.264
Los sistemas informáticos ofertados deberán ser conformes con las normativas técnicas
existentes:
•
ISO-9241.
•
UNE-EN 29241.
El formato del documento de la memoria del proyecto Fin de Carrera será la impuesta
por la Universidad Pontificia de Comillas.
10.1.1.3 Entregables.
La identificación de los entregables o productos finales, de manera representativa y
unívoca, se ha utilizado la siguiente notación: PFC – IINF – IEVh264 - TD - NO - NR.
•
•
•
•
•
•
PFC: Proyecto Fin de Carrera.
IINF: Carrera a la que referencia: Ingeniería en Informática.
IEVh264: Implementación del Estándar de Video H264.
TD: Tipo de Documento, con las siguientes opciones:
o PGP: Plan de Gestión del Proyecto.
o IS: Informe de Seguimiento.
o AR: Acta de Reunión.
o MU: Manual de Usuario de la instalación.
o PL: Planificación del proyecto.
o MP: Memoria del Proyecto.
o DR: Documento de Requisitos.
o PP: Presentación del Proyecto.
o AA: Anexo A del Proyecto.
o AB: Anexo B del Proyecto.
NO: Número de orden del tipo de documento. Componente numérica de dos
dígitos.
NR: Número de revisión. Componente numérica de dos dígitos, que representa el
nº de versión.
Además los entregables pueden clasificarse por su destino de distribución,
diferenciándose entre entregables externos e internos, como se explica a continuación.
Entregables externos.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
137
Implementación en Java/C++ del Estándar de Video H.264
Son aquellos que son el producto final, que tendrá como destinatario final al
Coordinador del Proyecto y al Tribunal, además del resto de participantes del proyecto.
MP: Memoria del Proyecto.
Fecha de Edición: 1 de Septiembre de 2009
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
PGP: Plan de Gestión del Proyecto.
Fecha de Edición: 1 de Septiembre de 2009
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
MU: Manual de Usuario de la instalación.
Fecha de Edición: 1 de Septiembre de 2009
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
PL: Planificación del proyecto.
Fecha de Edición: 1 de Septiembre de 2009
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
DR: Documento de Requisitos.
Fecha de Edición: 1 de Septiembre de 2009
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
AA: Anexo A del Proyecto.
Fecha de Edición:
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
138
Implementación en Java/C++ del Estándar de Video H.264
AB: Anexo B del Proyecto.
Fecha de Edición:
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
PP: Presentación del Proyecto.
Fecha de Edición: Aproximadamente el 18 de septiembre de 2009
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
Entregables internos.
Son aquellos que se realizan para la gestión interna del proyecto o que son resultado de
la misma, y tendrán como destinatarios finales al Director del Proyecto y al Jefe de Proyecto.
IS: Informe de Seguimiento.
Fecha de Edición: Periódicamente por solicitud del Director de Proyecto.
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
AR: Acta de Reunión.
Fecha de Edición: Periódicamente por solicitud del Director de Proyecto, después de
cada Seguimiento.
Responsable: Jefe de Proyecto: Rocío Vega Alonso.
10.1.1.4 Resumen de la Planificación y el Presupuesto.
Como una manera sencilla de identificar los gastos y la planificación que se tendrán en
la consecución del proyecto se adjuntan las siguientes tablas.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
139
Implementación en Java/C++ del Estándar de Video H.264
Resumen de la planificación:
WP-0.
Proyecto
WP-1.
Gestión del proyecto
WP-2.
Realización Técnica del
Proyecto
WP--3.
Cierre del Proyecto
WP-1.1
Lanzamiento del
Proyecto
WP-2.1
Estudio del estándar
WP-1.2
Seguimiento del
Proyecto
WP-2.2
Estudio aplicaciones
libres del Estándar
WP-1.3
PGP
WP-2.3
Aplicacioón
Demostración
Resumen del Presupuesto:
Artículo
Nombre del
Responsable
Precio
Unidades
Webcam
Rocío Vega Alonso
25€
2
Equipos
Rocío Vega Alonso
0€
2
Reproductor HD
compatible con
H264
Rocío Vega Alonso
0€
-
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
Comentarios
Solo necesarias 2 unidades
si se realizan los objetivos
opcionales
Solo necesarias 2 unidades
si se realizan los objetivos
opcionales
Herramientas Libres
140
Implementación en Java/C++ del Estándar de Video H.264
10.1.2 Evolución del Plan de Gestión del Proyecto.
No se realizará ninguna revisión del Plan de Gestión del Proyecto, debido a que no se
producirán cambios sustanciales desde la edición del mismo hasta la entrega de la memoria del
Proyecto, donde va incluido.
Excepciones:
En la revisión por parte del Coordinador del Proyecto, se posponga la entrega del PFC
hasta febrero del 2010.
En la revisión por parte del Coordinador del Proyecto, se realice un cambio sustancial
tales como:
•
•
Título del Documento: Memoria del Proyecto.
Puntos principales del Documento: Memoria del Proyecto.
En la revisión por parte del Director del Proyecto, se posponga la entrega del PFC hasta
febrero del 2010.
En la revisión por parte del Director del Proyecto, se realice un cambio sustancial tales
como:
•
•
Título del Documento: Memoria del Proyecto.
Puntos principales del Documento: Memoria del Proyecto.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
141
Implementación en Java/C++ del Estándar de Video H.264
10.2 Referencias.
[1] Metodología de gestión: Estándar para la gestión de proyectos informáticos IEEE 10581998.
[2] Normativa: Relacionada con la instalación de Sistemas Informáticos ISO 9241 (EN 29241).
[3] Metodología de desarrollo: A. Durán, B. Bernárdez. "Metodología para la licitación de
Requisitos de Sistemas Software (versión 2.0)". Informe Técnico del Dpto. de Lenguajes y
Sistemas Informáticos de la Universidad de Sevilla. Sevilla, Octubre 1999
[4] Metodología de desarrollo (2): Jesús Barranco de Areba, “Metodología del análisis
estructurado de sistemas”. Edition: 2. Publicado por Universidad Pontificia de Comillas de
Madrid, 2002.
El resto de las referencias referidas al proyecto se encuentran en la bibliografía del mismo.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
142
Implementación en Java/C++ del Estándar de Video H.264
10.3 Definiciones.
A continuación se muestran todos los acrónimos y sus significados utilizados. Las
referencias técnicas referentes al estándar no son incluidas en este apartado, ya que lo son en un
apartado específico de las características del mismo.
WP:
Paquete de Trabajo.
DP:
Director de Proyecto.
JP:
Jefe de Proyecto.
ANA:
Analista.
C:
Cliente.
PRO:
Programador.
RC:
Responsable del Cliente.
RP:
Responsable del Proveedor.
RRHH: Recursos Humanos.
RS:
Responsable de Subcontratas.
ES:
Equipo de Soporte.
PGP:
Plan de Gestión del Proyecto.
CO:
Consultor.
SAE:
Servicio Andaluz de Empleo.
HW:
Hardware.
SW:
Software.
IEEE 1058-1998: Estándar del Institute of Electrical and Electronics Engineers 1058-1998.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
143
Implementación en Java/C++ del Estándar de Video H.264
Notación de la Matriz de Responsabilidades:
E:
La persona o grupo es quien ejecuta la actividad
C:
La persona o grupo debe ser consultado durante la actividad. Su opinión cuenta.
I:
Debemos informar a la persona o grupo de que decisiones se toman.
A:
La persona que tiene la última palabra, en la aprobación del resultado.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
144
Implementación en Java/C++ del Estándar de Video H.264
10.4 Organización.
10.4.1 Interfaces Externos.
En este apartado se especifica la relación que tiene el desarrollo del proyecto con otras
entidades u organizaciones.
Proyecto Implementación del Estándar
de vídeo H.264
El Proyecto Implementación del Estándar de Vídeo H.264 se desarrolla en el marco de
la Universidad Pontificia de Comillas como asignatura Proyecto
Proyecto Fin de Carrera, y establece la
normativa y los profesores necesarios para su fin en los diferentes roles: Coordinador y
Director/es de Proyecto.
En este caso, el proyecto es desarrollado por las especificaciones de la empresa
Telefónica. En concreto por el departamento I+D en la Provincia de Granada mediante el
responsable Sergio Moreno.
10.4.2 Estructura Interna.
A continuación realizaremos un diagrama que explicará la organización y las
dependencias que se tienen en la empresa, así como los nombres de los responsables y su
posición.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
145
Implementación en Java/C++ del Estándar de Video H.264
Rol
CRD:
Coordinador de
Proyectos
Responsabilidades
• Concretar la definición del Proyecto.
• Controlar/supervisar el trabajo, con el Director del
Proyecto.
• Comunicarse con el equipo de trabajo para
supervisar ritmo e incidencias.
• Recoger y evaluar el Proyecto finalizado.
Funcionalidades explícitas:
DP:
Director de Proyecto
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
• Proponer un Proyecto con calidad suficiente y
establecer las líneas maestras que deben ser
verificables de forma práctica.
• Facilitar las orientaciones adecuadas ante los
problemas que vayan surgiendo en el desarrollo del
146
Implementación en Java/C++ del Estándar de Video H.264
Proyecto.
• Supervisar la realización del Proyecto, la calidad de
sus contenidos, y que se desarrolla de acuerdo con
las normas, consultando con el Coordinador de
Proyectos.
• Contralar y realizar el seguimiento de los objetivos,
planos, presupuestos y calidad acordados
• Aprobar los Informes de Situación de Proyecto
• Coordinar las diferentes Unidades Organizativas
involucradas en el proyecto
• Supervisar la estructura organizativa y la asignación
de recursos del proyecto
• Apoyar al Jefe de Proyecto en la realización de las
tareas que tenga asignadas, tanto técnicas como de
gestión de proyecto
• Supervisar el cumplimiento de los plazos y
presupuestos autorizados
Funcionalidades explícitas:
JP:
Jefe de Proyecto
• Elaborar el Proyecto con calidad.
• Elaborar el Plan de Proyecto
• Coordinar y planificar las actividades de los
distintos grupos del proyecto
• Coordinar las relaciones con los usuarios
• Dirigir técnicamente el proyecto (Desarrollo del
Software y Gestión de la Configuración)
• Integrar en el proyecto, mediante coordinación, las
actividades realizadas por los grupos de
“Verificación y Validación” y “Garantía de Calidad”
• Aprobar los documentos del proyecto y enviarlos a
los demás responsables.
• Controlar el cumplimiento de los objetivos, coste,
plazo y calidad establecidos para el Proyecto en el
Plan de Proyecto
• Elaborar los Informes de Situación del Proyecto
• Se asegura de que se aplica la metodología
establecida en el Plan de Proyecto
• Apoyar y diseñar conjuntamente con los analistas la
nueva arquitectura a implantar una vez estudiada la
arquitectura actual.
Funcionalidades explícitas:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
147
Implementación en Java/C++ del Estándar de Video H.264
COL:
Colaborador
ANA:
Analista
PRO:
Programador
• Establecer el marco de estudio y los requisitos del
Proyecto.
• Supervisar las alternativas planteadas por el analista,
así como aportar y orientar en la solución que éste
plantee.
Funcionalidades explícitas:
• Análisis del entorno funcional y operativo del
entorno de trabajo.
• Estudiar las diferentes alternativas y plantear la
mejor a sus superiores.
• Trabajar coordinadamente con los especialistas
programadores en integración HW para una correcta
instalación de la nueva arquitectura y/o solución de
problemas surgidas.
Funcionalidades explícitas:
• Encargado de realizar la aplicación a partir del
documento de requisitos y diseño de la misma.
• Conocimiento del entorno funcional y operativo del
entorno de trabajo
• Conocimiento y estudio detallado de la arquitectura
actual y la de futura implantación
• Solucionar cualquier problema técnico surgido en la
aplicación
Funcionalidades explícitas:
TST:
Tester
• Buscar la forma más efectiva de realizar el plan de
pruebas establecido.
• Recoger los resultados definidos en el plan de
pruebas.
• Generar informe con resultados para que puedan ser
estudiados por los Directores de Proyectos y
Analistas.
Funcionalidades explícitas:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
148
Implementación en Java/C++ del Estándar de Video H.264
10.4.2.1 Organigrama con los flujos de información y de control (de gestión).
A continuación se muestra en el organigrama antes expuesto, los flujos de información
y el tipo de documento que se lleva en él.
Esta leyenda muestra los diferentes tipos de documentos según su carácter oficial o no.
Documentos Internos.
Documentos externos No oficiales
Documentos externos Oficiales.
En esta leyenda lo que lleva es el tipo de documento, según sean entregables, que
deberán ser de tipo PDF, el código fuente, que deberá ser en Java, otros documentos pero con
formato definido, por ejemplo, los documentos de objetivos y requisitos se realizarán según la
documentación propuesta por Durán y Bernárdez, y, por último, la información que sirve de
orientación, aprobación o consulta.
Documentos Entregables PDF.
Código Fuente.
Otros Documentos (informes automatizado,
pruebas…).
Traspaso de información únicamente.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
149
Implementación en Java/C++ del Estándar de Video H.264
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
150
Implementación en Java/C++ del Estándar de Video H.264
10.5 Gestión
10.5.1 Gestión de Lanzamiento.
10.5.1.1 Recursos Humanos.
A continuación se indican los recursos humanos necesarios para llevar a cabo este
proyecto, así como las semanas de incorporación y desincorporación:
Fecha de
Incorporación
Fecha de
Desincorporación
David Contreras Bárcena
14/10/08
28/09/09
J.A. Pérez-Campanero Atanasio
14/10/08
28/09/09
Sergio Moreno Claros
14/10/08
28/09/09
Jefe de Proyecto
Rocío Vega Alonso
14/10/08
28/09/09
Analista
Rocío Vega Alonso
1/12/08
28/09/09
Programador
Rocío Vega Alonso
1/03/09
28/09/09
Tester
Rocío Vega Alonso
1/03/09
28/09/09
Rol
Coordinador de
Proyectos
Director de
Proyecto
Colaborador
Nombre
Modalidad
Tiempo
Partido
Tiempo
Partido
Tiempo
Partido
Tiempo
Completo
Tiempo
Completo
Tiempo
Completo
Tiempo
Completo
10.5.1.2 Recursos Materiales
En este apartado se realiza una enumeración de los recursos que serán utilizados para el
proyecto, teniendo en cuenta que no será necesaria la adquisición de todos los elementos, ya que
al ser un proyecto personal se podrán utilizar los recursos del Jefe de Proyecto. Estos artículos
se especifican con coste 0 para el proyecto:
Artículo
Webcam
Equipos
Reproductor HD
compatible con
H264
Nombre del
Responsable
Rocío Vega
Alonso
Rocío Vega
Alonso
Rocío Vega
Alonso
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
Precio
Unidades
20€
2
0€
2
0€
-
Comentarios
Solo necesarias 2 unidades si se
realizan los objetivos opcionales
Solo necesarias 2 unidades si se
realizan los objetivos opcionales
Herramientas Libres
151
Implementación en Java/C++ del Estándar de Video H.264
10.5.1.3 Plan de Formación
Este apartado no se aplica a este proyecto. La razón principal es que uno de los
objetivos del proyecto es la propia investigación y formación sobre un campo desconocido. Por
parte del Director de Proyecto y del Coordinador de Proyecto, no será necesario plan de
formación.
10.5.2 Planificación del Trabajo.
10.5.2.1 Actividades a Realizar
En este apartado, se especificará una división de las unidades de trabajo
correspondientes al proyecto. La herramienta utilizada para mostrarla es la EDT (Estructura de
División de Trabajo) mediante la cual, el criterio para especificar dichas unidades es funcional,
sin atender a una planificación temporal ni personal.
personal
WP-1.1
Lanzamiento del
Proyecto
WP-1.
Gestión del
proyecto
WP-1.2
Seguimiento del
Proyecto
WP-1.3
PGP
WP-2.1
Estudio del
estándar
WP-0.
Proyecto
WP-2.
Realización Técnica
del Proyecto
WP-2.2
Estudio aplicaciones
libres del Estándar
WP-2.3
Aplicacioón
Demostración
WP-1.2.1
Reglas del Proyecto
WP-1.2.2
Seguimiento del
Proyecto
WP-2.3.1
Especificación
WP-2.3.2
Diseño
WP-2.3.3
Programación
WP-3.
Cierre del Proyecto
WP-2.3.4
Pruebas
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
152
Implementación en Java/C++ del Estándar de Video H.264
A continuación se realizará una descripción de cada paquete de trabajo:
Este apartado trata del manejo y organización del proyecto y se
descompone en los siguientes apartados.
WP-1.1 Lanzamiento del Proyecto:
Proyecto: En esta actividad, el jefe de proyecto estudiará en
detalle el pliego de prescripciones técnicas y se reunirá formalmente para el lanzamiento del
proyecto.
WP-1.2 Seguimiento del Proyecto: esta actividad se compone a su vez de:
•
WP-1.2.1
1.2.1 Reglas del Proyecto: documento previo al actual en el que
se establecen las normas básicas del proyecto. Tiene longitud variable y
puede servir de contrato.
•
WP-1.2.2
1.2.2 Seguimiento del Proyecto: Esta actividad consta de la
realización de todos los informes de seguimiento y procedimientos de
control estipulados para realizar el control del proyecto.
WP-1.3 PGP, Plan de Gestión de Proyecto: es el documento actual y que realiza la
oferta para el problema planteado.
Se trata de cubrir específicamente y con calidad, cada uno de los
objetivos planteados y aprobados en el
el documento anterior.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
153
Implementación en Java/C++ del Estándar de Video H.264
WP-2.1 Estudio del estándar: Se trata de recoger en un documento resumen, todas las
características del estándar, recogiendo sobretodo las ventajas del mismo.
WP-2.2 Estudio aplicaciones libres del Estándar: Se trata de encontrar la mejor
implementación libre del estándar, de manera que se plantee como línea de trabajo futura, la
optimización de ese código para uso propio. En este mismo punto se tratará de encontrar las
aplicaciones que usen el estándar en su versión libre.
WP-2.3 Aplicación Demostración: este apartado se descompone a su vez de los
siguientes subapartados.
•
WP-2.3.1 Especificación: en el que se detallan los requisitos que debe cumplir
la aplicación de demostración.
•
WP-2.3.2 Diseño: En la que se establecen las pautas de desarrollo de la
aplicación así como su interfaz con el usuario..
•
WP-2.3.3 Programación: Es la fase de desarrollo de la aplicación en la que se
ponen en práctica las pautas de diseño.
•
WP-2.3.4 Pruebas: fase en la que se validan y verifican todos los puntos
anteriores.
Se trata de la fase en la que se documenta y archiva el proyecto.
Esta fase es crucial si se tienen líneas de trabajo futuras y para mejorar en
proyectos posteriores.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
154
Implementación en Java/C++ del Estándar de Video H.264
10.5.2.2 Planificación de Actividades.
A continuación se muestra con detalle la planificación de las actividades a realizar en el
proyecto, mediante un diagrama PERT.
Las actividades realzadas en paralelo correspondientes con la especificación de la
aplicación con el estudio del estándar y de las aplicaciones que lo implementan, se realizarán
con un pequeño retardo entre ellas, entendiendo que mientras se estudia surgen las
especificaciones que se desean demostrar con la aplicación.
De la misma forma la programación y las pruebas se realizaran en paralelo, probando
los módulos que se vayan desarrollando.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
155
Implementación en Java/C++ del Estándar de Video H.264
A continuación veremos marcado el camino crítico que se sigue:
Como vemos, la parte más gruesa del proyecto, que trata del análisis del estándar es, a
su vez, las actividades que no admiten retraso.
10.5.2.3 Asignación
Asignación de Recursos.
A continuación se muestra la Matriz de Responsabilidades, en dónde se relaciona cada
integrante con las tareas en las que puede participar según la notación vista en el apartado 3
(Definiciones):
ROL
Work Package
1.1
1.2.1
1.2.2
1.3
2.1
2.2
2.3.1
2.3.2
2.3.3
2.3.4
3
Lanzamiento del Proyecto
Reglas del Proyecto
Seguimiento del Proyecto
Plan de Gestión del Proyecto
Estudio del estándar
Estudio de las aplicaciones
libres del estándar
Especificaciones
Diseño
Programación
Pruebas
Cierre del Proyecto
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
CP
DP
COL
JP
ANA
A-I
A-I
E
E
A
A
E
E
I
I
I
E
E
E
E
A
E
E
I
A
E
I
I
I
I
E
A
E
E
E
E
E
A-I-E
I
I
I
I
A-E
PRO
TST
E
E
E
E
E
E
E
156
Implementación en Java/C++ del Estándar de Video H.264
10.5.2.4 Asignación Presupuestaria.
Como especificamos anteriormente, el coste del proyecto resultará cero en cuanto a
material. Mostramos, no obstante, la tabla presupuestaria de nuevo:
Artículo
Nombre del
Responsable
Precio
Unidades
Webcam
Rocío Vega Alonso
0€
2
Equipos
Rocío Vega Alonso
0€
2
Reproductor HD
compatible con
H264
Rocío Vega Alonso
0€
-
Comentarios
Solo necesarias 2 unidades
si se realizan los objetivos
opcionales
Solo necesarias 2 unidades
si se realizan los objetivos
opcionales
Herramientas Libres
10.5.3 Plan de Control.
10.5.3.1 Control de Requisitos.
En este apartado se detallará los pasos formales para la petición de cambios en los
requisitos, además de los documentos formales para realizarlos.
Solicitud de cambio por parte del equipo de trabajo:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
157
Implementación en Java/C++ del Estándar de Video H.264
El Equipo de Trabajo delega en el analista la solicitud de cambio que solicita
informalmente al Jefe de Proyecto el cambio. El Jefe de Proyecto consulta con el colaborador el
cambio y tras unir la opinión del grupo y del colaborador realiza, vía mail, una solicitud de
cambio al Director de Proyecto. Si esta solicitud se aprueba, entonces se realiza una notificación
al Coordinador que debe dar también su visto bueno. Esta comunicación puede ser vía mail o
verbal.
Solicitud de cambio por parte del Coordinador o el Director de Proyecto:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
158
Implementación en Java/C++ del Estándar de Video H.264
Tanto el Coordinador como el Director de Proyectos notifican al jefe de Proyecto un
cambio, que suele ser sobre la planificación o revisión de objetivos. El jefe de Proyecto es el
encargado de notificar a su equipo y al colaborador, y planificar dichos cambios sobre las fechas
estimadas.
Opcionalmente, se puede pedir el siguiente formulario de cambio:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
159
Implementación en Java/C++ del Estándar de Video H.264
PFC – IINF – IEVh264
10.5.3.2 Control de la Planificación.
No será necesario el envío de informes al Director de Proyecto, ya que se realizarán
controles informales periódicos. Esto será condición suficiente para no definir informes de
control de la planificación.
10.5.3.3 Control Presupuestario.
Dado que los recursos utilizados corren a cuenta del Jefe de Proyecto, no será necesario
realizar informes sobre el gasto presupuestario. No obstante, si se necesitase incluir algún
recurso a cuenta de otra empresa, esta solicitud de realizará informalmente vía mail.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
160
Implementación en Java/C++ del Estándar de Video H.264
10.5.3.4 Control de Calidad
A medida que se finalicen las actividades se irán verificando y validando por el Jefe de
Proyecto y el Director de Proyecto. De esta manera se consideran los siguientes entregables
como baseline [ver definición Apartado 33 Definiciones.], para ser chequeados exhaustivamente
por las partes anteriormente citadas:
10.5.3.5 Informes de Seguimiento
Será el Jefe de Proyecto quien se encargue de convocar y coordinar estas revisiones del
proyecto y resolver los problemas aparecidos en el desarrollo y/o proponer
propone las acciones
correctoras necesarias. A continuación se muestra el contenido de los informes de seguimiento:
Informes de Seguimiento
1.
2.
3.
4.
5.
6.
7.
8.
9.
Objetivos previstos para el primer periodo.
Objetivos alcanzados durante el primer periodo.
Incidencias encontradas en el primer periodo.
Análisis de las desviaciones.
Revisión de la planificación.
Acciones correctoras para resolver incidencias.
Objetivos previstos para el siguiente periodo.
Movimiento de recursos: Humanos y materiales.
Control de costes.
Toda esta información será procesada y mostrada en un cuadro de mando integral,
dónde se muestren indicadores del estado actual del proyecto.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
161
Implementación en Java/C++ del Estándar de Video H.264
10.5.3.6 Métricas de Control.
Se han considerado las siguientes métricas:
•
Horas/hombre trabajadas: Se contabilizan al final de semana a través del
completado de una tabla que más tarde formará parte del informe de seguimiento.
•
Gasto en euros respecto al presupuesto: Se calculará en base a las horas/hombre
contabilizadas, para cada perfil y su coste/hora.
•
Grado de Avance: se utilizará usando porcentajes entre 0% y 100%. Además se
definen tres etapas.
0% => No iniciado.
50% => Iniciada.
100% => Finalizada.
10.5.4 Plan de Gestión de Riesgo
Dado que se trata de un Proyecto Fin de Carrera, no será necesario seguir un plan de
Riesgos exhaustivo, únicamente cabe mencionar que se han identificado los siguientes Riesgos:
TIPO RESP*.
ID
RIESGO
PROBABILIDAD
IMPACTO
R01
GES
JP
Modificación sustancial del alcance
20%
MEDIO/ALTO
R02
GES
JP
Aumento de los objetivos
40%
MEDIO
R03
ORG
JP
Retraso de los entregables
20%
BAJO
R04
TEC
JP
Cambio de versión de herramientas
5%
MEDIO
*Resp. ( Responsable).
Donde los tipos:
•
•
•
GES: corresponde a Gestión
ORG: corresponde a Organización.
TEC: corresponde a Técnico.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
162
Implementación en Java/C++ del Estándar de Video H.264
Los riesgos arriba expuestos son en base a estimaciones y a experiencias pasadas, por
tanto esta tabla puede modificarse de una manera importante, sobre todo porque este Proyecto
intenta interactuar con un entorno real donde pueden influir muchas variables que podrían
afectar principalmente a los objetivos a cubrir por el Proyecto, detallados en el Apartado 1.1.1
del presente documento.
El plan de actuación para cada Riesgo es el siguiente:
ID
PROBABILIDAD
IMPACTO
20%
MEDIO/ALTO
40%
MEDIO
R03 Reaccionar: unificar dos entregables en uno solo.
20%
BAJO
R04 Evitar: Tomar la decisión de la versión antes de utilizarla.
5%
MEDIO
R01
R02
ACTUACIÓN
Reaccionar: reajustar la planificación y si es necesario
eliminar alguna fase de las opcionales
Mitigar: guardar un tiempo de planificación para esta
posibilidad
10.5.5 Plan de Cierre,
Para el cierre del proyecto se llevarán a cabo las siguientes acciones:
•
Archivo de la documentación y material producido en el proyecto.
•
Reorganización de funciones al personal asignado.
•
Obtención de las lecciones aprendidas.
•
Análisis de los objetivos cumplidos y valoración.
•
Realización del informe final.
•
Redacción de líneas de Trabajo futuras.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
163
Implementación en Java/C++ del Estándar de Video H.264
10.6 Tecnología
10.6.1 Modelo de Procesos.
Se recuerda que la descomposición del trabajo, realizada para este proyecto en
particular, se encuentra descrita en el apartado de este documento: 5.2.1 Actividades a
desarrollar.
A continuación pasamos a mostrar una descripción detallada de algunos de los paquetes
anteriormente definidos en el diagrama de actividades. Para cada una de las actividades
usaremos un formulario basado en cuatro apartados:
•
Entrada: en este apartado se indican los documentos o recursos necesarios para
iniciar el desarrollo de cada actividad.
•
Actividades: se describen las tareas funcionales que se van a llevar a cabo en cada
uno de los paquetes de trabajo.
•
Salida: en este apartado se describen los documentos y elementos que se obtienen
como resultado de haber realizado el paquete de trabajo.
•
Gestión: en este apartado se establece quien es el responsable, cuál es el
presupuesto con el que se cuenta (horas/hombre) y cuál es el plazo que se tiene.
WP-1.1. Lanzamiento del Proyecto
Entrada
Actividades
•
•
•
Salida
Gestión
•
•
Extracción de los objetivos y el alcance del Proyecto.
Reunión de Lanzamiento.
Anexo A de la gestión de PFC de Universidad Pontificia de
Comillas.
Responsable: JP: Rocío Vega Alonso.
Plazo: 15 días para la entrega del documento.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
164
Implementación en Java/C++ del Estándar de Video H.264
WP-1.2.1. Reglas del Proyecto
Entrada
Actividades
Acta de Reunión de Lanzamiento.
•
•
•
•
•
•
•
•
•
Salida
Gestión
•
•
Determinar los participantes del proyecto.
Realizar la matriz de responsabilidades.
Actividades Determinar el propósito, el alcance y los objetivos del
proyecto.
Determinar las restricciones.
Identificar los entregables internos y externos.
Elegir y aplicar una Metodología, ajustándola al proyecto.
Realizar una estimación y un presupuesto
Determinar un plan de control.
Anexo B de la gestión de PFC de Universidad Pontificia de
Comillas.
Responsable: JP: Rocío Vega Alonso.
Plazo: 15 días para la entrega del documento.
WP-1.2.2. Seguimiento del Proyecto
Entrada
Planificación del Proyecto.
Documento de Reglas de Proyecto.
Actividades
Salida
Gestión
•
•
•
•
•
•
•
Analizar los objetivos cubiertos durante el periodo establecido.
Identificar las incidencias.
Analizar las deviaciones en la planificación y/o presupuesto.
Establecer los objetivos a analizar en el siguiente periodo.
Si procede, establecer los movimientos de los recursos humanos.
Informes de Seguimiento
Responsable: JP: Rocío Vega Alonso.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
165
Implementación en Java/C++ del Estándar de Video H.264
WP-1.3. Plan de Gestión del Proyecto
Entrada
Reglas del Proyecto.
•
•
•
•
•
•
Adaptar las Reglas del Proyecto al estándar IEEE de metodología
de Gestión.
Realizar los planes de control, auditorías, V&V que se apliquen al
proyecto.
Actividades Determinar los interfaces (relaciones) del proyecto.
Elaborar un plan de gestión específico para el proyecto actual.
Elaborar una planificación detallada.
Establecer un marco tecnológico para el proyecto.
Plan de Gestión del Proyecto.
•
Responsable: JP: Rocío Vega Alonso.
Actividades
•
Salida
Gestión
WP-2.1. Estudio del Estándar
Entrada
Especificaciones del Estándar de ITU-T
Actividades
•
•
•
•
Leer y comprender el estándar y sus características.
Escribir un resumen aclarativo.
Destacar las ventajas e inconvenientes frente a otros estándares.
Memoria del Proyecto.
•
Responsable: JP: Rocío Vega Alonso.
Salida
Gestión
WP-2.3.1. Especificación
Entrada
Documentación de las aplicaciones utilizadas en la aplicación final.
Actividades
Salida
Gestión
•
•
•
•
•
Estudio de los parámetros y opciones de las aplicaciones.
Realizar los requisitos necesarios para la aplicación.
Memoria del Proyecto.
Documento de Requisitos.
Responsable: JP: Rocío Vega Alonso.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
166
Implementación en Java/C++ del Estándar de Video H.264
WP-2.3.2. Diseño
Entrada
Documento de Requisitos.
Actividades
•
Salida
•
•
•
Gestión
Diseñar la implementación de la aplicación según el estándar
UML
Memoria del Proyecto.
Documento de diseño del Proyecto.
Responsable: ANA: Rocío Vega Alonso.
WP-2.3.3. Programación
Entrada
Documento de Diseño del Proyecto.
Actividades
•
Salida
•
•
•
Gestión
Desarrollar en el leguaje de programación Java lo acordado según
el documento de diseño.
Memoria del Proyecto.
Código Fuente.
Responsable: PRO: Rocío Vega Alonso.
WP-2.3.4. Pruebas
Entrada
Código Fuente
Actividades
•
•
Salida
Gestión
•
•
Realizar las pruebas de Verificación y Validación internas previas
a las finales.
Realizar las pruebas de la aplicación y de las características
extraídas del estándar.
Memoria del Proyecto.
Responsable: TST: Rocío Vega Alonso.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
167
Implementación en Java/C++ del Estándar de Video H.264
WP-3. Cierre del Proyecto
Entrada
Memoria del proyecto
Plan de Gestión del Proyecto.
Actividades
•
Salida
Gestión
•
•
•
•
•
•
Archivo de la documentación y material producido en el
proyecto.
Reorganización de funciones al personal asignado.
Actividades Obtención de las lecciones aprendidas.
Análisis de los objetivos cumplidos y valoración.
Realización del informe final.
Memoria del Proyecto.
Responsable: JP: Rocío Vega Alonso.
10.6.2 Métodos, Herramientas y Técnicas.
En primer lugar detallaremos la metodología seguida para cada parte del proyecto,
teniendo en cuenta que no adoptamos ninguna teórica al pie de la letra, sino que vamos
aplicando a cada fase la que consideramos más completa.
Metodologías.
•
Para la extracción y documentación de los requisitos, hemos seguido la notación
propuesta por Durán y Bernárdez de la Universidad de Sevilla. A pesar de no
ser un estándar, la tendencia actual es que se documenten las especificaciones
según este formato.
•
Para el desarrollo de Software se seguirá la metodología de Ingeniería del
Software basada en UML, según la vista durante la Carrera de Informática.
•
Para depuración de software se han utilizado herramientas convencionales
como son el JavaScript debugger y la herramienta gdb incluida en el sistema
operativo de Linux.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
168
Implementación en Java/C++ del Estándar de Video H.264
•
Para la gestión se ha utilizado la metodología propuesta por IEEE, según el
estándar para la gestión de proyectos informáticos de este organismo, 10581998.
10.6.3 Infraestructura.
No será necesaria una infraestructura como tal para el desarrollo del Proyecto, aunque
debemos reflejar las herramientas y componentes que hemos utilizado para el desarrollo del
mismo.
•
Para la redacción del documento y la realización de la presentación de los
diferentes Anexos a entregar, se ha utilizado Microsoft Word y Microsoft
PowerPoint, por ser la herramienta más extendida, cualidad necesaria para el
desarrollo de la memoria debido al cambio continuo de ubicación del equipo
dedicado a esta tarea.
•
Para el desarrollo de la aplicación se ha elegido Java 1.6.0_12.
•
Para el entorno de desarrollo se ha elegido eclipse SDK-3.1.2 y versiones
estables sobre ésta, sobre el sistema operativo Windows.
•
Para la conversión de formatos de video se ha elegido FFMPEG en la SVNr16573
10.6.4 Aceptación de productos:
La aceptación de cada entregable será conseguida según el cumplimiento de los
siguientes criterios:
•
Cumplimiento de la fecha de entrega.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
169
Implementación en Java/C++ del Estándar de Video H.264
•
Cumplimiento de los objetivos propuestos.
•
Cumplimiento del grado de calidad establecido según:
•
o
Características operativas.
o
Capacidad de soportar cambios.
o
Adaptación de nuevos entornos.
Normativa de la Universidad Pontificia de Comillas para la entrega de PFC.
En el apartado 1.1.3 (Entregables) de este Plan de Gestión del Proyecto se detallan las
fechas de edición de cada entregable.
PFC IINF IMPLEMENTACION EN JAVA/C++DEL ESTÁNDAR DE VIDEO H.264
HOJA DE
ACEPTACIÓN
Observaciones.
Fecha entrada
Fecha aceptación
Firma de Jefe de Proyecto
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
Firma de Director de Proyecto
Firma del Coordinador de Proyecto
170
Implementación en Java/C++ del Estándar de Video H.264
10.7 Soporte
A continuación vamos a definir los planes y criterios necesarios para ofrecer un correcto
soporte al proyecto antes, durante y tras la finalización del mismo, es decir, durante su Proyecto,
Instalación y Explotación.
10.7.1 Plan De Gestión De La Configuración
El objetivo de la edición de este plan es la de controlar y ofrecer un soporte sobre todos
los elementos que integran y constituyen la configuración de un Proyecto, en este caso El
proyecto fin de Carrera Implementación en Java/C++ del Estándar de Vídeo H.264. Se han de
controlar todos los cambios y versionado que sufran todos los elementos durante el Ciclo de
Vida, es decir, durante su Planificación, Construcción y Explotación.
Mediante este Plan de Gestión de la Configuración también se establecen los Puntos de
Control de la Configuración que son los momentos precisos dentro del Ciclo de Vida de la
Instalación que se toman como referencia principal para realizar un control de la configuración.
Se harán referencias a distintas versiones cuando se produzcan cambios funcionales
significativos sobre el elemento afectado, y una revisión cuando el elemento afectado en
cuestión sea sometido a una corrección en un error o una mejora en su rendimiento.
A continuación definimos los distintos puntos que forman el Plan de Gestión de la
Configuración.
10.7.1.1 Identificación De Los Elementos De La Configuración
Elementos Software sujetos al Plan de la Configuración:
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
171
Implementación en Java/C++ del Estándar de Video H.264
•
Aplicación en Java/C++ de la implementación del estándar.
Elementos Documentales sujetos al Plan de la Configuración:
•
•
Memoria del Proyecto Fin de Carrera.
Plan de Gestión de Proyecto.
10.7.1.2 Control de Cambios de la Configuración
Todo cambio en cualquier elemento de la Gestión de la Configuración será registrado
como tal indicando si es un cambio o versión en dicho
dicho elemento de la Configuración de la
Instalación.
Deberá ser referenciado acorde al siguiente modelo: EE- VVV. RRR
•
•
•
EE: Elemento
VVV: Versión
RRR: Revisión
10.7.1.3 Definición y Gestión de los Puntos de Control de la Configuración
Se establecerá un Punto de Control de la Configuración en cada final de etapa del Ciclo
de Vida de la Instalación. No deben confundirse con los puntos de Verificación y Validación
mencionados anteriormente, identificados por Baseline:
Para el final de estos dos paquetes de trabajo se realizará un control especial, en el que
todo lo realizado hasta ese momento deberá estar validado.
10.7.1.4 Realización de Informes del Estado de la Configuración.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
172
Implementación en Java/C++ del Estándar de Video H.264
Se realizará un informe de Estado de la Configuración en cada punto de control de fin
de fase de la Metodología del Proyecto, y será editado por el equipo de proyecto, supervisado
por el Jefe de Proyecto y aprobado por el Director de Proyecto.
10.7.1.5 Control del Proceso de Edición de los Elementos Documentales
En cada cambio de versión o revisión de cualquier elemento físico asociado a un
elemento documental, el cambio o actualización será inmediato, además de que todos los
elementos documentales serán almacenados para disposición del Cliente y miembros el equipo
interno del proyecto.
10.7.2 Plan de verificación y validación.
Este plan consiste en definir el nivel de independencia de los equipos encargados de
Validar el proyecto “contra” los requisitos del cliente y de Verificar la buena práctica empleada
en el proyecto.
La Verificación y Validación será realizada finalmente por el Director y Coordinador de
Proyectos, que establecerán una puntuación según la calidad y el cimplimiento de los objetivos
del mismo.
A continuación desarrollaremos los puntos definidos para el Plan de Verificación y
Validación.
10.7.2.1 Organización
Organización del Equipo de Verificación y Validación.
10.7.2.2 Descripción De Los Elementos Sujetos A Verificación Y Validación
Mediante la identificación y descripción de los elementos sujetos a Verificación y
Validación se implementarán las Listas de Comprobación que serán el elemento clave y básico
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
173
Implementación en Java/C++ del Estándar de Video H.264
para realizar el proceso descrito. Para cada elemento de las Listas de Comprobación se indicará
si cumple con los requisitos iniciales descritos y se comprobarán que se aplican correctamente
los procedimientos empleados para la realización del Proyecto.
Dado que el proyecto es de pequeña envergadura, las listas de comprobación se basaran
en los objetivos descritos y el cumplimiento de las metodologías anteriormente mencionadas.
10.7.2.3 Identificación De Las Actividades A Realizar Para La Verificación Y Validación
Se identificarán las actividades a realizar por los equipos de Verificación y Validación,
compuestas por:
•
Elección de los elementos sujetos a Verificación y Validación.
•
Verificación de las resoluciones efectuadas en los comentarios emitidos en la
Verificación y Validación realizadas.
•
Modificación y aprobación de los documentos y productos afectados cuando
cumplan satisfactoriamente los requisitos establecidos.
•
Realización del Plan de Pruebas de Validación y aplicación del mismo sobre los
elementos de las Listas de Comprobación.
•
Documentación adecuada de las pruebas efectuadas.
10.7.2.4 Planificación De Las Actividades De Verificación y Validación
La planificación de las actividades de Verificación y Validación se realizará conforme a
la planificación del proyecto en sí, determinando únicamente si se realizará antes, durante o al
finalizar cada fase según se incluya como actividad del paquete de trabajo la propia verificación
y validación. Esto se ha resuelto así atendiendo al tamaño del proyecto, y teniendo en cuenta
que la verificación y validación será realizada por personas que han participado en el mismo.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
174
Implementación en Java/C++ del Estándar de Video H.264
10.7.2.5 Listas de Comprobación.
Elementos Software sujetos a Verificación y Validación:
•
Aplicación en Java/C++ de la implementación del estándar.
Elementos Documentales sujetos Verificación y Validación:
•
Memoria del Proyecto Fin de Carrera.
•
Plan de Gestión de Proyecto.
10.7.3 Plan de Garantía de Calidad.
Mediante este plan se asentarán las bases, actividades y criterios que designarán y
definirán la calidad del proyecto, entendiendo esta calidad como el conjunto de propiedades y
de características de un producto o servicio, que le confieren aptitud para satisfacer unas
necesidades explícitas o implícitas. Esta calidad será designada de acuerdo a las siguientes
características del producto:
o
Características operativas
•
Corrección: el producto ha de hacer lo que tiene que hacer
•
Fiabilidad: lo hace de forma fiable durante todo el tiempo
•
Eficiencia: se ejecuta lo mejor que puede
•
Seguridad: es segura y lo hace todo de forma segura
•
Facilidad de uso: es intuitivo y fácil de usar
o
Capacidad de soportar cambios
•
Facilidad de mantenimiento: se puede corregir y mantener de forma sencilla
•
Flexibilidad: con qué facilidad se puede cambiar y readaptar
•
Facilidad de prueba: facilidad de probar el producto
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
175
Implementación en Java/C++ del Estándar de Video H.264
o
Adaptación a nuevos entornos
•
Portabilidad: en qué medida puede ser utilizado en distintas máquinas o hardware
•
Reusabilidad: medida en la que puede ser utilizado en distintos proyectos o
elementos
•
Interoperabilidad: medida en la que puede interactuar o ser compatible con otros.
Rocío Vega Alonso
J.A. Pérez-Campanero Atanasio
176