Autorizada la entrega del proyecto del alumno/a: Fernando Puech Helguero EL DIRECTOR DEL PROYECTO. Javier Martín Ruiz

Transcripción

1 Autorizada la entrega del proyecto del alumno/a: Fernando Puech Helguero EL DIRECTOR DEL PROYECTO Javier Martín Ruiz Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos Miguel Ángel Sanz Bobi Fdo.: Fecha: / /

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA SISTEMA CLIENTE-SERVIDOR DE VÍDEO DIGITAL EN TIEMPO REAL PARA VIGILANCIA DE INSTALACIONES DESATENDIDAS EN REDES IP DE ANCHO DE BANDA VARIABLE AUTOR: FERNANDO PUECH HELGUERO MADRID, JUNIO 2007

3 SISTEMA CLIENTE-SERVIDOR DE VÍDEO DIGITAL EN TIEMPO REAL PARA VIGILANCIA DE INSTALACIONES DESATENDIDAS EN REDES IP DE ANCHO DE BANDA VARIABLE Autor: Puech Helguero, Fernando. Director: Martín Ruiz, Javier Entidad Colaboradora: ICAI Universidad Pontificia Comillas RESUMEN DEL PROYECTO El proyecto consiste en el diseño, desarrollo e integración de una aplicación cliente-servidor para apoyar el sistema de vídeo vigilancia de una serie de instalaciones, permitiendo acceder al vídeo emitido a través de una red IP, ya sea LAN o WAN. Para realizar lo anterior se han utilizado diferentes tecnologías y se han adaptado a las necesidades de un sistema de vídeo vigilancia, para ofrecer una plataforma final que a la vista del usuario sea una caja negra a la que solicitar el vídeo que se ha grabado, o se está grabando, de una instalación normalmente desatendida. El proyecto consiste en dos partes, el servidor y el cliente. El servidor realiza las funciones de captura, codificación, almacenamiento y transmisión del vídeo en tiempo real, así como también da soporte para que los clientes puedan reproducir el vídeo sin conocer a priori la ruta de acceso. El cliente es un reproductor integrado en una aplicación Java que permite seleccionar el vídeo a visualizar, indicando la cámara que se desea ver, y las fechas del vídeo a mostrar, ya sean pasadas o en directo. De esta manera se consigue que haya una interacción entre el cliente y el servidor, permitiendo optimizar el rendimiento, puesto que el servidor no necesita estar emitiendo continuamente todos los contenidos de los que dispone, sino que emite en función de lo que los diferentes usuarios solicitan. A su vez proporciona la posibilidad de acceder al sistema de vídeo vigilancia desde una red externa a la organización, lo que permite hacer un seguimiento exhaustivo de las instalaciones sin tener que desplazarse hasta las mismas. Esto posibilita la implantación del sistema, no sólo como sistema de vídeo vigilancia sino como sistema de seguimiento de proyectos de construcción, u otro tipo de proyectos de ingeniería. El proyecto se basa en tecnologías como son el streaming, los servicios Web Java, códecs modernos para la generación de vídeo de calidad, pero utilizando un espacio de almacenamiento reducido, y reproductores de última generación compatibles con dichos

4 formatos de vídeo. El cliente está desarrollado en el lenguaje de programación Java, y parte de los módulos del servidor también utilizan dicho lenguaje de programación. El cliente utiliza un sistema inglés Windows, ya que es el sistema operativo más utilizado por usuarios finales de PC, mientras que el servidor utiliza Linux como sistema operativo. VIDEO SURVEILLANCE SYSTEM BASED ON CLIENT-SERVER ARCHITECTURE AND IP NETWORKS WITH VARIABLE BANDWIDTH ABSTRACT This final dissertation consists in designing, developing and implementing a system designed to optimize the video surveillance of unattended facilities, by being able to transmit the recorded video through IP LAN or WAN networks. Several different technologies have been used and adapted to video surveillance requirements, to develop and implement this system. The idea is to provide a complete platform, acting as a black box to the final user, who asks the system for a video stream which was recorded at a previous time or is being recorded at the present time (live video feed). The system is made up of two main parts, the client software and the server software. The client software consists in a Java application with an embedded player which allows the final user to access the video feed on demand or live, by making queries specifying the camera and date to watch. The server software takes care of capturing, encoding, saving and transmitting the video feed in real time, and it is also able to provide the client software with the access paths to the video, based on the queries made by the client software. This architecture provides a fabulous way of optimizing accessibility to the video surveillance system, by allowing the user to access the video from a network outside the organization s network. It also makes this kind of system useful for controlling the development of engineering projects via real-time video. The system is developed using various technologies such as streaming, Java Web Services, modern codecs, which allow video encoding with high quality while consuming little storage space, and state of the art players compatible with these codecs. The client software has been developed using the Java programming language, and some of the server software s modules have been also developed with Java.

5 The server software runs under the Linux operating system, while the client runs under a Windows based operating system. This decision was made because Windows is the operating system desktop users are most familiar with.

6 ÍNDICE 1. Introducción Objetivos del proyecto Descripción de las tecnologías Introducción Metodología de desarrollo Streaming [APPLE02] Qué es el streaming? Por qué es necesario un servidor de streaming? Emisión en directo versus bajo demanda Ejemplo de sistema de streaming Cómo funciona el streaming? Multicast versus Unicast Retransmitiendo streams Protocolos utilizados RTSP (RFC 2326) [RTSP07] SDP (RFC 4566) [SDP07] Códecs H.264/AVC [H26407] XVID [XVID07] Java Web Services [JWS07] Fernando Puech Helguero 6

7 2.6.1 Axis [ASF05] Reproductores VLC QuickTime QTJava Descripción del modelo desarrollado Introducción Identificación de necesidades Objetivos del sistema Alcance del sistema Tipología de usuarios Restricciones Servidor Requisitos Prototipo 1 del servidor Prototipo 2 del servidor Prototipo 3 del servidor Arquitectura del servidor Notas adicionales Cliente Requisitos Prototipo 1 del cliente Fernando Puech Helguero 7

8 3.4.3 Prototipos 2 a 5 del cliente Prototipo 6 del cliente Prototipo 7 (aplicación definitiva) Arquitectura del cliente Notas adicionales Arquitectura del sistema completo Planificación y presupuesto del proyecto Introducción Tareas a realizar Planificación de las tareas Presupuesto del proyecto Conclusiones Conclusiones sobre la metodología Conclusiones sobre los resultados Recomendaciones para futuros estudios Bibliografía Anexo I Configuración del servidor Anexo II MPEG4IP Anexo III Despliegue y uso del cliente Anexo IV Axis Architecture Guide Fernando Puech Helguero 8

9 1. Introducción Fernando Puech Helguero 9

10 El proyecto consiste en el diseño, desarrollo e integración de una aplicación cliente-servidor para mayor el sistema de vídeo vigilancia de una serie de instalaciones, permitiendo acceder al vídeo emitido desde una red IP (Internet). Se trata de ofrecer al cliente la posibilidad de acceder al vídeo que se está emitiendo en ese momento o a vídeo creado en momentos anteriores. El servidor tiene que ser capaz de ofrecer los servicios anteriormente mencionados a los clientes, generando los ficheros de vídeo para que los clientes puedan visualizar grabaciones antiguas, emitiendo el vídeo que se está grabando en directo, realizando la transmisión necesaria para la distribución de los contenidos, y ofreciendo una plataforma que permita a los usuarios acceder al vídeo mediante consultas en las que se indica la cámara y las fechas del período que desean ver. Para realizar lo anterior se han tomado diferentes tecnologías y se han adaptado a las necesidades de un sistema de vídeo vigilancia, para ofrecer una plataforma final que a la vista del usuario es una caja negra a la que solicitar el vídeo que se ha grabado, o se está grabando, de alguna instalación normalmente desatendida. La tecnología utilizada en el proyecto se describe en detalle más adelante, pero cabe destacar el uso del streaming como base de transmisión de flujos de información multimedia, la utilización de servicios Web Java (JWS) para transmitir información que no es multimedia, aunque sí necesaria para que el cliente pueda conocer la manera de acceder a los flujos multimedia. Además hay que decir que se han utilizado sistemas de generación de contenido y transmisión del mismo en tiempo real, para poder sustituir a los tradicionales sistemas de vídeo vigilancia. Fernando Puech Helguero 10

11 2. Objetivos del proyecto Fernando Puech Helguero 11

12 El proyecto se plantea como un estudio de las tecnologías existentes y un desarrollo para adaptarlas a las necesidades de un sistema de vídeo vigilancia. Es decir, se trata de desarrollar un prototipo para estudiar la viabilidad de un sistema de vídeo vigilancia basado en el streaming en redes IP. Los objetivos del proyecto son los siguientes: Desarrollar el servidor: o Integrar el servidor de streaming y el generador de contenidos. o Desarrollar un controlador del generador de contenidos para la generación de una jerarquía de ficheros accesible. o Desarrollar un servicio (JWS) para atender las consultas de los clientes a la hora de acceder al contenido. Desarrollar un cliente que permita el acceso al vídeo generando consultas basadas en fechas y cámara a visualizar, y si el vídeo es en directo o no. Obtener retardos razonables (retardo < 5 segundos). Fernando Puech Helguero 12

13 2. Descripción de las tecnologías Fernando Puech Helguero 13

14 2.1 Introducción En este capítulo se describen las tecnologías utilizadas para el desarrollo de este proyecto, comenzando por la metodología de desarrollo utilizada y continuando por las tecnologías específicas de los diferentes elementos estudiados. Las tecnologías descritas son el streaming, los protocolos utilizados, los códecs, Java Web Services y reproductores utilizados. 2.2 Metodología de desarrollo El desarrollo del proyecto se basa en parte de la metodología de desarrollo evolutiva, puesto que es necesario utilizar software ya existente, pero adaptándolo. Inicialmente se realiza una fase de estudio del estado del arte, que consiste en el estudio de la tecnología existente para entenderla y así ser capaces de adaptarla a las necesidades del proyecto. Tras esa primera fase de estudio del estado del arte se realiza una fase de especificación para ver qué es lo que realmente se tiene que añadir a la tecnología existente, después de la cual se comienza el diseño y desarrollo de los diferentes módulos que irían formando el prototipo. Las fases de desarrollo y diseño son paralelas. Durante el desarrollo se realizan pruebas de la funcionalidad para saber en qué dirección tiene que ir el prototipo. Metodología utilizada [BARRA01] El desarrollo comienza con un prototipo que se ajusta a unos requisitos básicos, para ir evolucionando en posteriores fases y adaptándose a la nueva funcionalidad requerida. La ventaja de ésta metodología es que facilita el análisis de resultados y avance del proyecto, pudiendo reorientar el mismo poco a poco. En la figura 1 se puede apreciar el proceso de evolución del proyecto. Fernando Puech Helguero 14

15 Prototipo 1 P P Aplicación definitiva Figura Streaming [APPLE02] Qué es el streaming? El streaming consiste en transmitir contenido multimedia desde un servidor a un cliente en tiempo real, a través de una red con capacidades que van desde el módem hasta la más moderna conexión de banda ancha. Ningún fichero se descarga al disco duro del cliente, sino que el contenido multimedia se reproduce según se va recibiendo. Un servidor de streaming permite emitir contenido que se está grabando en ese momento en tiempo real, emitir vídeo bajo demanda y emitir listas de reproducción de contenido ya grabado Por qué es necesario un servidor de streaming? Si se quiere emitir contenido multimedia a través de Internet o en una red local, hace falta un servidor de streaming, al igual que también es necesario un servidor Web para poder publicar una serie de páginas Web o un servidor de correo para poder enviar y recibir . El servidor de streaming transmite el vídeo y el audio a los clientes como respuesta a una petición de dichos clientes, que utilizarán un software capaz de reproducir dichos medios. Las peticiones se gestionan utilizando el protocolo RTSP (Real Time Streaming Protocol), que permite controlar un stream con características de tiempo real. Los streams se transmiten Fernando Puech Helguero 15

16 utilizando el protocolo RTP (Real-Time Transport Protocol), que es el estándar utilizado para transmitir contenido con características de tiempo-real a través de las redes. Un servidor de streaming es capaz de crear además un stream a partir de una película grabada en el disco duro, así como de retransmitir copias de streams en directo (contenido que se está capturando en directo) a los que tenga acceso. Si se quiere transmitir a pocas personas podemos tener en una misma máquina el servidor de streaming, un servidor Web, uno de correo, etc. De lo contrario es necesario distribuir la carga entre varias máquinas, que sólo se dediquen a hacer de servidores de streaming Emisión en directo versus bajo demanda Hay dos maneras de realizar el streaming en tiempo real: emisión en directo o emisión bajo demanda. Con DSS se pueden realizar ambas. Los eventos en directo se transmiten según van sucediendo utilizando software como MPEG4IP. Este software codifica en tiempo real el contenido que se está recibiendo, como puede ser el vídeo de una cámara que está grabando el evento, y lo pasa al servidor de streaming para que éste lo retransmita a través de la red. Independientemente de cuando se conecten los clientes al servidor, cada uno verá el mismo punto del stream al mismo tiempo, es decir, que si uno llega un minuto más tarde se habrá perdido el primer minuto de vídeo pero verá lo mismo que está viendo el que se conectó un minuto antes. Esto se puede simular también utilizando ficheros ya grabados y listas de reproducción. Cuando la emisión es bajo demanda, el cliente comienza a ver el stream desde el principio independientemente de los demás clientes. Esto se puede hacer sólo accediendo a ficheros ya grabados. En este caso no hace falta un software que nos provea del stream codificado en tiempo real como en el caso anterior. Fernando Puech Helguero 16

17 2.3.4 Ejemplo de sistema de streaming Audio en directo Transmisor del contenido en directo Vídeo en directo Servidor de Streaming Figura 2 En la figura 2 el servidor es independiente del transmisor de contenido en directo, aunque también podemos tener el software que codifica el contenido grabado en directo en tiempo real en el propio servidor Cómo funciona el streaming? Cuando se ve la televisión o se escucha la radio, las ondas electromagnéticas o el cable se dedican exclusivamente a dicha transmisión. Esas transmisiones están, en su mayoría, sin comprimir y por lo tanto consumen un gran ancho de banda. A pesar de todo esto no es un problema porque dichas transmisiones no tiene que competir con otras transmisiones en la misma frecuencia. Cuando se transmite a través de Internet, el ancho de banda no está dedicado exclusivamente a una única transmisión sino que hay que compartirlo con una gran cantidad de tráfico que viene y va a través de Internet. Además en general se tiene un ancho de banda bastante limitado. Debido a esto el contenido multimedia se comprime, codifica y almacena para poder ser transmitido a través de Internet utilizando un software como el Darwin Streaming Server. Fernando Puech Helguero 17

18 El contenido que se transmite puede ser accedido por cualquier reproductor compatible con el protocolo que utilice el servidor de streaming (RTSP en el caso de DSS) y que además soporte los códecs que se han utilizado en la compresión y codificación del vídeo. Cuando un usuario quiere reproducir algún contenido su reproductor enviará la petición al servidor y el servidor le proveerá con el stream correspondiente Multicast versus Unicast DSS soporta tanto transporte multicast como transporte unicast para enviar el stream a sus clientes. Si se utiliza multiscast, un sólo stream es compartido por todos los clientes, con el consiguiente ahorro de ancho de banda y carga para el servidor. Es como si cada cliente encendiera la radio y empezase a escuchar una determinada emisora. El problema que surge es que el tráfico multicast no suele estar soportado en Internet, a no ser que se tenga acceso al backbone multicast (no es lo normal). Por lo tanto sólo se podrá utilizar este tipo de tráfico en la red local. En la figura 3 queda plasmado el funcionamiento con multicast. Multicast Figura 3 Fernando Puech Helguero 18

19 Si se utiliza unicast cada cliente inicia un stream, generándose una gran cantidad de conexiones punto a punto como se ve en la figura. La desventaja de unicast es que se genera una gran cantidad de tráfico que puede sobrecargar la red. La ventaja de unicast es que funciona sin ningún problema a través de Internet. Figura 4 Unicast Internet Retransmitiendo streams El servidor puede ser configurado como un retransmisor (relay). Un retransmisor espera un stream de entrada para después reenviarlo a uno o varios destinos. Gracias a esta configuración se puede reducir el ancho de banda consumido. Esta configuración es especialmente útil cuando un gran número de usuarios quieren acceder a un mismo stream desde diferentes lugares. Los que más partido pueden sacar de la configuración con retransmisores son las grandes empresas, por ejemplo, si una quiere emitir una conferencia mensual para que la vean todos sus empleados, la emisión puede ser retransmitida del origen (oficina central) al resto de sucursales repartidas por todo el globo. Fernando Puech Helguero 19

20 Transmisor del contenido en directo Clientes Destino Relay Sucursales Internet Clientes Figura 5 Destino El vídeo se captura en directo y es codificado y enviado al servido de retransmisión (relay) por el transmisor de contenido en directo, el cual retransmite el stream a los servidores de las diferentes sucursales para que estos a su vez lo transmitan a los clientes. Fernando Puech Helguero 20

21 2.4 Protocolos utilizados RTSP (RFC 2326) [RTSP07] El protocolo de flujo de datos en tiempo real (del inglés Real Time Streaming Protocol) establece y controla uno o muchos flujos sincronizados de datos, ya sean de audio o de video. El RTSP actúa como un mando a distancia mediante la red para servidores multimedia. RTSP es un protocolo no orientado a conexión, en lugar de esto el servidor mantiene una sesión asociada a un identificador, en la mayoría de los casos RTSP usa TCP para datos de control del reproductor y UDP para los datos de audio y video aunque también puede usar TCP en caso de que sea necesario. En el transcurso de una sesión RTSP, un cliente puede abrir y cerrar varías conexiones de transporte hacia el servidor para satisfacer las necesidades del protocolo. De forma intencionada el protocolo es similar en sintaxis y operación al HTTP de forma que los mecanismos de expansión añadidos al HTTP pueden en muchos casos añadirse a RTSP, en cualquier caso RTSP difiere en un número significativo de aspectos del HTTP: RTSP introduce nuevos métodos y tiene un identificador de protocolo diferente. Un servidor RTSP necesita mantener el estado de la conexión al contrario que HTTP Tanto el servidor como el cliente pueden lanzar peticiones. Los datos son transportados por un protocolo diferente El protocolo soporta las siguientes operaciones: Recuperar contenidos multimedia del servidor: El cliente puede solicitar la descripción de una presentación por HTTP o cualquier otro método. Si la presentación es multicast, la descripción contiene los puertos y las direcciones que serán usados. Si la presentación es unicast, el cliente es el que proporciona el destino por motivos de seguridad. Fernando Puech Helguero 21

22 Invitación de un servidor multimedia a una conferencia: Un servidor puede ser invitado a unirse a una conferencia existente en lugar de reproducir la presentación o grabar todo o una parte del contenido. Este modo es útil para aplicaciones de enseñanza distribuida dónde diferentes partes de la conferencia van tomando parte en la discusión. Adición multimedia a una presentación existente: Particularmente para presentaciones en vivo, útil si el servidor puede avisar al cliente sobre los nuevos contenidos disponibles. Figura 6 Peticiones RTSP Las peticiones RTSP están basadas en peticiones HTTP y generalmente son enviadas del cliente al servidor, las más típicas son: DESCRIBE, este método obtiene una descripción de una presentación o del objeto multimedia apuntado por una URL RTSP situada en un servidor. El servidor responde a esta petición con una descripción del recurso solicitado, entre otros datos la descripción contiene una lista de los flujos multimedia que serán necesarios para la reproducción. Esta solicitud/respuesta constituye la fase de inicialización del RTSP. Ejemplo: Cliente Servidor DESCRIBE rtsp://unservidor.com/uncontingut RTSP/1.0 Accept: application/sdp, application/rtsl, application/ mhe Fernando Puech Helguero 22

23 Servidor Cliente RTSP/ OK Content-Type: application/sdp Content-Length: 376 i=descripció del contingut m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 SETUP, especifica como será transportado el flujo de datos, la petición contiene la url del flujo multimedia (stream) y una especificación de transporte, esta especificación típicamente incluye un puerto para recibir los datos (audio o video), y otro para los datos RTCP (metadatos). El servidor responde confirmando los parámetros escogidos y llena las partes restantes, como los puertos escogidos por el servidor. Cada flujo de datos debe ser configurado con SETUP antes de enviar una petición de PLAY. Ejemplo: Cliente Servidor: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 Transport: RTP/AVP;unicast;client_port= Servidor Cliente RTSP/ OK Session: Transport: RTP/AVP;unicast; client_port= ;server_port= Fernando Puech Helguero 23

24 PLAY, esta petición provocará que el servidor comience a enviar datos de los flujos (streams) especificados utilizando los puertos configurados con SETUP. Ejemplo: Cliente Servidor PLAY rtsp://unservidor.com/audio RTSP/1.0 Session: PAUSE, detiene temporalmente uno o todos los flujos, de manera que puedan ser recuperados con un PLAY posteriormente. Ejemplo: Cliente Servidor PAUSE rtsp://unservidor.com/video1 RTSP/1.0 Session: Servidor Cliente RTSP/ OK TEARDOWN, detiene la entrega de datos para la URL indicada liberando los recursos asociados. Ejemplo: Cliente Servidor TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0 Session: Servidor Cliente RTSP/ OK Fernando Puech Helguero 24

25 Sesión RTSP El cliente accede a la URL RTSP por tal de obtener el nombre del servidor y el puerto. Si el nombre del servidor no está en formato IP, el cliente hace una consulta DNS para obtener la dirección correspondiente. El cliente inicia una conexión TCP hacia el servidor. Cuando la conexión está establecida correctamente, el cliene envía al servidor una petición OPTIONS. EL servidor devuelve información que puede incluir la versión de RTSP, la fecha, el número de sesión, el nombre del servidor y los métodos soportados. El cliente envía una petición DESCRIBE para obtener una descripción de la presentación. El servidor responde con todos los valores de inicialización necesarios para la presentación. El cliente envía SETUP para cada flujo de datos que se quiere reproducir. El SETUP especifica los protocolos aceptados para el transporte de los datos. El cliente inicializa los programas adecuados requeridos para reproducir la presentación. El cliente envía una petición PLAY que informa al servidor que ahora es el momento de comenzar a enviar datos. Durante la sesión, el cliente periódicamente hace ping al servidor utilizando peticiones SET_PARAMETER. Aunque la respuesta sea errónea el cliente la ignora informando al cliente que el servidor todavía está activo. Cuando la presentación termina o el usuario la para, el cliente envía un SET_PARAMETER que contiene las estadísticas de la sesión. El cliente envía TEARDOWN para dar por terminada la conexión con el servidor. Fernando Puech Helguero 25

26 En la figura se pueden ver los mensajes intercambiados en el establecimiento de una sesión RTSP: Figura 7 Fernando Puech Helguero 26

27 2.4.2 SDP (RFC 4566) [SDP07] Session Description Protocol (SDP), es un protocolo que permite describir los parámetros de inicialización de un stream multimedia. SDP está pensado para describir las sesiones multimedia de manera que quede estandarizado cómo anunciar la sesión, invitar a alguien a la sesión y alguna otra forma de iniciación de la sesión multimedia. SDP comenzó como una parte del Session Announcement Protocol (SAP), pero se ha utilizado en conjunción con RTP, SIP y para describir sesiones multicast. Existen 5 términos asociados a SDP: 1. Conferencia (Conference): Es un conjunto de dos o más usuarios que se están comunicando con un software determinado. 2. Sesión (Session): es el conjunto del emisor del contenido multimedia, el receptor de dicho contenido y el contenido que se está transmitiendo. 3. Anuncio de sesión (Session Announcement): es un mecanismo para hacer llegar a los usuarios la información de la sesión, siendo el servidor el que inicia la comunicación sin que el cliente haya realizado una solicitud explícitamente. 4. Publicidad de sesión (Session Advertisement): es igual que anuncio de sesión. 5. Descripción de sesión (Session Description): descripción detallada de la sesión, con información suficiente para que se pueda participar en dicha sesión. Fernando Puech Helguero 27

28 2.5 Códecs H.264/AVC [H26407] H.264 o MPEG-4 parte 10 es una norma que define un códec de vídeo de alta compresión, desarrollada conjuntamente por el ITU-T Video Coding Experts Group (VCEG) y el ISO/IEC Moving Picture Experts Group (MPEG). La intención del proyecto H.264/AVC fue la de crear un estándar capaz de proporcionar una buena calidad de imagen con tasas binarias notablemente inferiores a los estándares previos (MPEG-2, H.263 o MPEG-4 parte 2), además de no incrementar la complejidad de su diseño. Para garantizar un ágil desarrollo de la misma, la ITU-T y la ISO/IEC acordaron unirse para desarrollar conjuntamente la siguiente generación de códecs de vídeo. El Joint Video Team (JVT) estaba formado por expertos del VCEG y MPEG y nació en diciembre de 2001 con el objetivo de completar el desarrollo técnico del estándar hacia el La ITU-T planeó adoptar el estándar bajo el nombre de ITU-T H.264 y ISO/IEC bajo el nombre de MPEG-4 Parte 10 Códec de Vídeo Avanzado (AVC) y de aquí surgió el nombre híbrido de H.264/MPEG-4 AVC. Para empezar a programar el código del nuevo estándar adoptaron las siguientes premisas: La estructura DCT + Compensación de Movimiento de las versiones anteriores era superior a otros estándares y por esto no había ninguna necesidad de hacer cambios fundamentales en la estructura. Algunas formas de codificación de vídeo que habían sido excluidas en el pasado debido a su complejidad y su alto coste de implementación se volverían a examinar para su inclusión puesto que la tecnología VLSI había sufrido un adelanto considerable y una bajada de costes de implementación. Fernando Puech Helguero 28

29 Para permitir una libertad máxima en la codificación y evitar restricciones que comprometan la eficiencia, no se contempla mantener la compatibilidad con normas anteriores. Características de H.264/AVC El uso inicial del MPEG-4 AVC estuvo enfocado hacia el video de baja calidad para videoconferencia y aplicaciones por Internet, basado en 8 bits/muestra y con un muestreo ortogonal de 4:2:0. Esto no daba salida al uso de este códec en ambientes profesionales que exigen resoluciones más elevadas, necesitan más de 8 bits/muestra y un muestreo de 4:4:4 o 4:2:2, funciones para la mezcla de escenas, tasas binarias más elevadas, poder representar algunas partes de video sin perdidas y utilizar el sistema de color por componentes RGB. Por este motivo surgió la necesidad de programar unas extensiones que soportasen esta demanda. Tras un año de trabajo intenso surgieron las extensiones de gama de fidelidad (FRExt) que incluían: Soporte para un tamaño de transformada adaptativo. Soporte para una cuantificación con matrices escaladas. Soporte para una representación eficiente sin pérdidas de regiones específicas. Este conjunto de extensiones denominadas de "perfil alto" son: La extensión High que soporta 4:2:0 hasta 8 bits/muestra La extensión High-10 que soporta 4:2:0 hasta 10 bits/muestra La extensión High 4:2:2 que soporta hasta 4:2:2 y 10 bits/muestra La extensión High 4:4:4 que soporta hasta 4:4:4 y 12 bits/muestra y la codificación de regiones sin pérdidas. Fernando Puech Helguero 29

30 Nuevas especificaciones H.264/MPEG-4 AVC no supone una gran ruptura tecnológica con respecto a las normas de codificación de vídeo anteriores. Las diferencias se pueden encontrar a pequeña escala sobre el principio general de codificación (predicción, transformada, cuantificación, etc.). TIPOS DE IMÁGENES Podemos encontrar las mismas imágenes que en las normas precedentes (Imágenes I, P y B ) y dos nuevas, la SP (Switching P) y la SI (Switching I) que sirven para codificar la transición entre dos flujos de vídeo. Permiten, sin enviar imágenes intra muy costosas en tiempos de procesamiento, pasar de un vídeo a otro utilizando predicción temporal o espacial como antes, pero con la ventaja que permiten la reconstrucción de valores específicos exactos de la muestra aunque se utilicen imágenes de referencia diferentes o un número diferente de imágenes de referencia en el proceso de predicción. COMPENSACIÓN DEL MOVIMIENTO El proceso de compensación de movimiento es diferente de las normas precedentes puesto que propone una gran variedad de formas y de particiones de bloques. De cara a la compensación de movimiento, cada macrobloque, aparte del tamaño original (16x16 píxeles), puede ser descompuesto en sub-bloques de 16x8, 8x16 o 8x8 píxeles. En este último caso, es posible descomponer a su vez cada sub-bloque de 8x8 píxeles en particiones de 8x4, 4x8 o 4x4 píxeles. Antes, el estándar más novedoso introducía particiones de 8x8. Esta variedad de particiones proporciona una mayor exactitud en la estimación, a lo que se suma una precisión que puede llegar hasta un cuarto de píxel. Fernando Puech Helguero 30