Download implementación en java/c++ del estándar de codificación h.264
Document related concepts
no text concepts found
Transcript
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