Preditor de Vetores de Movimento em Hardware Segundo o Padrão H.264/AVC

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA CURSO DE ENGENHARIA DE COMPUTAÇÃO BRUNO ZATT Preditor de Vetores de Movimento em Hardware Segundo o Padrão H.264/AVC Trabalho de Diplomação. Prof. Dr. Sergio Bampi Orientador Prof. MSc. Luciano Volcan Agostini Co-orientador Porto Alegre, novembro de 2006.

2 UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. José Carlos Ferraz Hennemann Vice-reitor: Prof. Pedro Cezar Dutra Fonseca Pró-Reitor de Graduação: Prof. Carlos Alexandre Netto Diretor do Instituto de Informática: Prof. Flávio Rech Wagner Coordenador do ECP: Prof. Altamiro Amadeu Susin Bibliotecária-Chefe do Instituto de Informática: Beatriz Regina Bastos Haro

3 AGRADECIMENTOS Gostaria de agradecer primeiramente a Deus pela dádiva maior, a dádiva da vida. Aos meus pais, João Francisco Zatt e Amantina Cardoso Ribeiro Zatt, que propiciaram a mim excelentes condições para que hoje chegasse até esse ponto. Pais que foram responsáveis por transmitir a mim, valores que carregarei por toda a vida. Meu irmão Gustavo Zatt por estar sempre ao meu lado e dar apoio em todos os momentos de alegria e de tristeza. Agradeço a todos amigos que sempre me apoiaram e deram alegria para continuar na luta. Aos amigos que fiz em minha terra natal, Santo Ângelo, e aos amigos que fiz aqui, em Porto Alegre, meu muito obrigado. À minha namorada Arielli Sallet Nascimento por seu amor, carinho e pelo apoio incondicional nessa difícil reta final de minha faculdade. Agradeço aos colegas e mestres, sem os quais minha formação não atingiria o nível que atingi. Aos colegas de trabalho do grupo TV-Digital. Ao Arnaldo Pereira de Azevedo Filho pelos ensinamentos valiosos que me transmitiu durante os dois últimos anos de trabalho. Ao Luciano Volcan Agostini, meu co-orientador, pelo suporte incondicional durante o desenvolvimento deste trabalho e de tantos outros. Ao Pro. Sergio Bampi, meu orientador, pela oportunidade da inserção nas atividades de pesquisa e desenvolvimento. Enfim, agradeço a todos aqueles que de alguma forma contribuíram para minha formação como homem e como engenheiro de computação. Muito obrigado a todos!

4 4

5 SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS... 7 LISTA DE FIGURAS... 9 LISTA DE TABELAS RESUMO ABSTRACT INTRODUÇÃO COMPENSAÇÃO DE MOVIMENTO E O PADRÃO H.264/AVC O Padrão de Compressão de Vídeo H.264/AVC Compensação de Movimento (MC) Tamanho de blocos variável Múltiplos quadros de referência Vetores apontando para fora das bordas do quadro Precisão de quarto de pixel Bi-predição e Predição Ponderada Predição Skip e Direta Predição de Vetores de Movimento PREDITOR DE VETORES DE MOVIMENTO (MVP) Algoritmo de Predição de Vetores Predição de Slices P Predição de Slices B Software para Predição de Vetores IMPLEMENTAÇÃO DO MVP EM HARDWARE Arquitetura do MVP e Descrição VHDL Preditor Com Suporte à Slices P Preditor Com Suporte à Slices B e Predição Direta Espacial Preditor Com Suporte à Slices B e Predição Direta Espacial e Temporal Validação Prototipação Resultados IMPLEMENTAÇÕES ALTERNATIVAS... 62

6 6 5.1 Plataforma x86 / Linux Plataforma Sun / SunOS Plataforma Mac / Mac OS Standard Cell Resultados CONCLUSÃO REFERÊNCIAS... 70

7 LISTA DE ABREVIATURAS E SIGLAS AVC CABAC CAVLC CIF CODEC DC DCT DDR DPCM DRAM DVD FIFO FIR FPGA FRExt GB HDTV H422P H444P Hi10P IEC IEEE INTRA ISO ITU-T JVT MB Advanced Video Coding Context-Based Adaptive Binary Arithmetic Coding Context-Based Adaptive Variable Length Coding Common Intermediate Format codificador/decodificador Direct Current Discrete Cosine Transform Double Data Rate Differential Pulse Code Modulation Dynamic Random Access Memory Digital Versatile Disk First In First Out Finite Impulse Response Field Programmable Gate Array Fidelity Range Extensions Giga Bytes High Definition Digital Television High 4:2:2 Profile High 4:4:4 Profile High 10 Profile International Electrotechnical Commission Institute of Electric and Electronics Engineers Intra Prediction International Organization for Standardization International Telecommunication Union - Telecommunication Joint Video Team Mega Bytes

8 8 MC ME MPEG MVP PC PMV POC Q Q -1 QCIF QP RAM RGB SBTVD SDTV SP SI T T -1 UFRGS USB VCEG VGA VHDL VHSIC XUP YCbCr WP Motion Compensation Motion Estimation Moving Picture Experts Group Motion Vector Predictor Personal Computer Predictve Motion Vector Picture Order Counter Quantization Inverse Quantization Quarter Common Intermediate Format Quantization Parameter Random Access Memory Red, Green, Blue Sistema Brasileiro de Televisão Digital Standard Definition Television Switching P Switching I Transform Inverse Transform Universidade Federal do Rio Grande do Sul Universal Serial Bus Video Coding Experts Group Video Graphics Array VHSIC Hardware Description Language Very High Speed Integrated Circuit Xilinx University Program Luminance, Chrominance Blue, Chrominance Red Weighted Prediction

9 LISTA DE FIGURAS Figura 2.1: Perfis Baseline, Main, Extended e High do padrão H.264/AVC Figura 2.2: Diagrama em blocos de um codificador H.264/AVC Figura 2.3: Diagrama em blocos de um decodificador H.264/AVC Figura 2.4: (a) quadro atual a ser predito; (b) predição com vetor de movimento inteiro com valores inteiros (1, -1); (c) vetor de movimento com valores fracionários (0,5 ; 0,75) Figura 2.5: Interpolação para posições de ½ pixel para o componente de luminância.. 22 Figura 2.6: Interpolação para posições de ¼ de pixel Figura 2.7: Interpolação para componentes de crominância Figura 3.1: Ordem de predição de vetores no MB Figura 3.2: Relação entre blocos vizinho (a) em formatos idênticos e (b) em formatos diferentes Figura 3.3: Fluxograma do software de predição de vetores de movimento Figura 4.1: Blocos necessários ao cálculo do MVP Figura 4.2: Estrutura de registradores para armazenamento de vetores internos ao macrobloco (0 a 15) e vetores de macroblocos vizinhos (A, B, C e D) Figura 4.3: Estrutura de registradores para armazenamento de índices de referência internos ao macrobloco (0 a 3) e índices de macroblocos vizinho (A, B, C e D) Figura 4.4: Diagrama de estados da FSM do MVP Figura 4.5: Diagrama de estados do macroestado TESTE Figura 4.6: Diagrama de estados do macroestado STANDARD Figura 4.7: Diagrama de estados do macroestado SET_VECTORS Figura 4.8: Estrutura de habilitação de escrita nos registradores Figura 4.9: Diagrama de estados do macroestado MEMORY_REFRESH Figura 4.10: Diagrama de estados do macroestado PRE_PROCESS_DIRECT_SPATIAL Figura 4.11: Diagrama de estados do macroestado SPATIAL Figura 4.12: Diagrama de estados do macroestado TEMPORAL Figura 4.13: Caminho de dados para o cálculo do fator de escala Figura 4.14: Plataforma de prototipação Figura 4.15: Terminal de comunicação com RS

10 LISTA DE TABELAS Tabela 3.1: Tipos de macroblocos em Slices tipo P Tabela 3.2: Tipos de sub-macroblocos em Slices tipo P Tabela 3.3: Tipos de macroblocos em Slices tipo B Tabela 3.4: Tipos de sub-macroblocos em Slices tipo B Tabela 4.1: Sinais de Entrada do MVP Tabela 4.2: Sinais de Entrada do MVP Tabela 4.3: Síntese do MVP com Suporte a Slices P Tabela 4.4: Síntese do MVP com Suporte a Slices B e Predição Direta Espacial Tabela 4.5: Síntese do MVP com Suporte a Slices B e Predição Direta Espacial e Temporal Tabela 4.6: Síntese do Protótipo com Suporte a Slices B e Predição Direta Espacial Tabela 4.7: Síntese do Protótipo com Suporte a Slices B e Predição Direta Espacial e Temporal Tabela 4.8: Taxa de processamento do MVP para HDTV Tabela 5.1: Desempenho das Diferentes Implementações em quadros HDTV por segundo... 66

11 RESUMO Com o objetivo de aumentar a capacidade de compressão de vídeo em relação aos padrões já existentes, foi desenvolvido o padrão H.264/AVC. O padrão foi definido em 2003 pelo JVT, formado a partir da união de especialistas do VCEG da ITU-T e especialistas do MPEG da ISO/IEC. Este trabalho propõe uma solução arquitetural para o preditor de vetores de movimento (MVP) de acordo com o perfil Main do padrão H.264/AVC. Este módulo faz parte da compensação de movimento. A arquitetura proposta foi modelada por uma máquina de estados finitos que opera sobre dados armazenados em bancos de registradores. A validação foi realizada por meio de simulações, utilizando dados extraídos de seqüências de vídeos reais codificadas. Os dados extraídos foram armazenados em arquivos e utilizados como entrada para a simulação. Os resultados da simulação foram, então, comparados com resultados extraídos. A arquitetura proposta foi prototipada em uma placa XUP Virtex-II PRO equipada com um FPGA VP-30 da família Virtex-II PRO da Xilinx. O processador PowerPC 405 embarcado no FPGA, foi utilizado para gerenciar o protótipo do preditor de vetores. O preditor de vetores de movimento foi descrito em 7500 linhas de VHDL, distribuídas em 7 diferentes arquivos. Os resultados de síntese gerados pelo software Xilinx ISE apresentaram uma utilização de 3636 slices, 3596 registradores, 6221 LUTs, 3 blocos de memória interna e 3 multiplicadores. Sua freqüência máxima de operação atingiu 133,9 MHz, atingindo desempenho suficiente para decodificar HDTV em tempo real. O preditor é capaz de decodificar, por segundo, uma média de 254 quadros HDTV para slices P, 101 quadros para slices B com predição direta espacial e 162 quadros para slices B com predição direta temporal. Foi utilizada, também, uma análise do desempenho do hardware desenvolvido, comparando-o a diferentes implementações em software rodando sobre plataformas distintas. Nenhuma arquitetura completa para predição de vetores de movimento em hardware seguindo o padrão H.264/AVC no perfil Main foi encontrada na literatura até o presente momento, inviabilizando a comparação deste trabalho com trabalhos relacionados. Palavras-Chave: Compressão de Vídeo, H.264/AVC, Compensação de Movimento (MC), Preditor de Vetores de Movimento (MVP), FPGA.

12 12 An H.264/AVC Motion Vector Predictor Hardware Architecture ABSTRACT H.264/AVC is the new video coding standard of the ITU-T Video Coding Experts Group (VCEG) and the ISO/IEC Moving Picture Experts Group (MPEG). The standard promises much higher compression than that possible with earlier standards. This work presents a hardware architecture for the H.264/AVC motion vector predictor (MVP). The MVP is part of the motion compensation hardware block. Motion vector predictor architecture was modeled as a set of registers and a finite state machine (FSM). The validation was made by simulation using data extracted from encoded video sequences. The data was stored in files and used as input for simulation. Then, the simulation results were compared to the extracted results. The prototyping platform consists of the EDK/ISE software and prototyping board XUP Virtex-II Pro with a Xilinx Virtex-II PRO FPGA device. The MVP was described in 7,500 lines of VHDL code. The synthesis results generated by Xilinx ISE present a device utilization of slices, 3596 registers, 6221 LUTs, 3 block RAMs and 3 multipliers. The design reaches a clock frequency of MHz decoding real time HDTV. The designed architecture is able to decode up to 254 HDTV frames of P slices, 101 HDTV frames of B slices using spatial direct prediction and 162 HDTV frames of B slices using temporal direct prediction. In the current literature, a motion vector predictor in hardware with support for all H.264/AVC Main profile features was not found. Keywords: Video compression, H.264/AVC, Motion Compensation (MC), Motion Vector Predictor (MVP), FPGA.

13 1 INTRODUÇÃO A compressão de vídeos digitais tem sido um assunto amplamente pesquisado e estudado, devido às suas diversas possibilidades de aplicação e utilização. O armazenamento e a transmissão de vídeos, principalmente em alta definição, exigem alta capacidade de compressão para se tornarem viáveis. Durante aproximadamente 10 anos, o padrão MPEG-2 tem sido o padrão de codificação de vídeo predominante no mercado, sendo utilizado pela grande maioria dos sistemas de televisão digital, bem como por mídias populares como o DVD e por uma vasta gama de dispositivos portáteis, como câmeras digitais. No entanto, a busca por maiores resoluções de imagem, tem trazido a necessidade de armazenamento e transmissão de vídeos em alta definição (HDTV) e, conseqüentemente, a necessidade de um maior poder de compressão de vídeos. Com o objetivo de aumentar a capacidade de compressão de vídeo em relação aos padrões já existentes, foi desenvolvido o padrão H.264/AVC. O padrão foi definido em 2003 pelo JVT (ITU-T, 2005), formado a partir da união de especialistas do VCEG da ITU-T (ITU-T, 2006) e especialistas do MPEG da ISO/IEC (ISO/IEC, 2006). O H.264/AVC atingiu o objetivo de obter taxas mais elevadas de compressão de vídeo, chegando a reduzir em 50% a quantidade de bits necessários para representação de um vídeo se comparado ao MPEG-2. Esse aumento na capacidade de compressão se deve a um considerável incremento na complexidade computacional dos codecs H.264/AVC em relação a padrões mais antigos. Com o aumento da complexidade computacional, a codificação e decodificação de vídeos H.264/AVC se mostrou intratável por meio de software na tecnologia atual, impulsionando, assim o, desenvolvimento de codecs em hardware para esta tarefa. Outro fator que incentiva o desenvolvimento de hardware para o H.264/AVC é o grande interesse comercial envolvido, principalmente relacionado à televisão digital de alta definição e pelas novas mídias ópticas inseridas no mercado, como o Blu-Ray e o HD-DVD. Este trabalho está inserido no projeto de um codec H.264/AVC em hardware para TV de alta definição (HDTV 1920x1080). Este codec foi utilizado nas investigações acadêmicas que serviu de subsídio para a construção do Sistema Brasileiro de Televisão Digital (SBTVD). Este trabalho tem como objetivo apresentar a arquitetura desenvolvida para o módulo de predição de vetores de movimento para o padrão H.264/AVC abordando todas as etapas de desenvolvimento, desde o domínio do problema até a prototipação da arquitetura. A arquitetura desenvolvida tem o objetivo de prover desempenho suficiente para processar vídeos de alta definição, com dimensões de 1920x1080 pixels, em tempo real

14 14 (30 quadros por segundo) de acordo com o perfil Main do padrão H.264/AVC no nível 4.0. Este texto foi construído da seguinte forma. No capítulo 2 é apresentado o padrão de compressão de vídeo H.264/AVC, com suas principais características, perfis, níveis e definições úteis para a compreensão do restante do texto. Ainda no capítulo 2, é detalhado o módulo da compensação de movimento, no qual está inserido o preditor de vetores de movimento. O capítulo 3 apresenta o algoritmo de predição de vetores, alvo desse trabalho, e o software desenvolvido para efetuar essa tarefa. A arquitetura proposta é descrita no capítulo 4, assim como seu desenvolvimento, validação e prototipação. Implementações alternativas, utilizadas para comparação de desempenho com a arquitetura proposta, são detalhadas no capítulo 5. O capítulo 6 apresenta as conclusões.

15 15 2 COMPENSAÇÃO DE MOVIMENTO E O PADRÃO H.264/AVC Este capítulo apresentará, de forma breve, as principais características do padrão de compressão de vídeo H.264/AVC, seus perfis e níveis, bem como seus principais componentes. Em seguida será detalhado o processo de compensação de movimento no H.264/AVC, com suas funcionalidades e inovações em relação aos padrões mais antigos. 2.1 O Padrão de Compressão de Vídeo H.264/AVC O padrão de compressão de vídeo H.264/AVC (Advanced Video Coding) (ITU-T, 2003), também conhecido como MPEG-4 Parte 10, foi desenvolvido conjuntamente pela ITU-T, através de seu grupo de especialistas em codificação de vídeo (VCEG Video Coding Experts Group) (ITU-T, 2006), e pela ISO/IEC, representada pelo seu grupo de especialistas em imagem em movimento (MPEG Motion Picture Experts Group) (ISO/IEC, 2005). Esta união deu origem ao JVT (Joint Video Team) (ITU-T, 2005) que concluiu a definição do padrão em O padrão H.264/AVC opera sobre imagens no espaço de cores YCbCr (MIANO, 1999), este espaço de cores é composto por um canal de luminância e dois de crominância, sendo que a relação entre Y, Cb e Cr depende do perfil do padrão considerado. Os perfis serão apresentados ainda nesta seção. As imagens são formadas por macroblocos que contém 16x16 amostras de luminância e as amostras de crominância associadas. Grupos de macroblocos são associados em slices. Cada slice pode ser classificado em cinco diferentes tipos (I, P, B, SI e SP). Slices do tipo I contém apenas macroblocos do tipo I. Slices do tipo P podem conter macroblocos tipo P e tipo I. Os slices B podem conter macroblos I, P e B. Os slices SI e SP são definidos apenas no perfil Extended e visam permitir o chaveamento entre fluxos de bits diferentes, sem comprometer a eficiência da codificação. O número de macroblocos em um slice pode variar de um até o número total de macroblocos do quadro (RICHARDSON,2003). Macroblocos do tipo I são codificados através da codificação intraframe, que utiliza amostras contidas no slice atual, explorando a redundância espacial dentro do slice. Estes macroblocos também podem ser codificados através do modo I_PCM onde são transmitidos os valores das amostras diretamente.

16 16 Os macroblocos tipo P são codificados utilizando a codificação interframe, que utiliza amostras contidas em um dos quadros de referência previamente codificados. Este tipo de codificação visa explorar a redundância temporal que existe entre os quadros de uma seqüência de vídeo. Os quadros de referência são organizados em uma lista, chamada pelo padrão de lista 0 (ITU-T, 2003). Macroblocos B também são codificados pela codificação interframe, no entanto, cada partição pode utilizar informações de até dois quadros de referência diferentes. As referências são organizadas em duas listas, chamadas de lista 0 e lista 1. A forma como os macroblocos são particionados e como as listas de referências são organizadas serão melhor descritas na próxima seção. O padrão H.264/AVC é dividido em diferentes perfis. Cada perfil suporta um grupo de funções e é especificado para satisfazer determinados tipos de aplicações. O perfil Baseline é direcionado para aplicações como videoconferência, suporta apenas slices I e P e utiliza códigos de comprimento de palavra variável adaptativos ao contexto (CAVLC) como método de codificação de entropia. O perfil Main é orientado à transmissão de televisão e armazenamento de vídeo. Além das funções do perfil Baseline, o perfil Main suporta vídeo entrelaçado, slices do tipo B, predição ponderada e codificação de entropia utilizando codificação aritmética adaptativa ao contexto (CABAC). O perfil Extended é focado para aplicações em streaming de vídeo e não suporta vídeo entrelaçado ou o CABAC, mas agrega modos para habilitar uma troca eficiente entre bitstreams codificados (através de slices do tipo SP e SI) e melhora a resiliência a erros (através do particionamento de dados). Esses três perfis utilizam amostras de 8 bits, e utilizam relação 4:2:0 entre os canais Y, Cb e Cr. Em 4:2:0, os canais de crominância possuem metade da resolução horizontal e metade ta resolução vertical do canal de luminância. Portanto, um macrobloco é composto por 16x16 amostras de luminância, 8x8 amostras de crominância azul (Cb) e 8x8 amostras de crominância vermelha (Cr). Quatro novos perfis, conhecidos como perfis High foram definidos por meio de uma extensão ao padrão, chamada de fidelity range extensions (FRExt) (ITU-T, 2004), com o objetivo de ampliar o ancance do padrão para vídeos de elevada qualidade. Os perfis High visam alta qualidade e vídeos para entretenimento, suportam tamanho de bloco adaptativo para a transformada (4x4 ou 8x8), suportam matrizes de quantização baseadas em percepção e suportam uma representação sem perdas de regiões específicas do conteúdo do vídeo. Além disso, suportam vídeos com amostras de até 12 bits e relações de cor 4:2:0, 4:2:2 e 4:4:4. A Figura 2.1 apresenta um pequeno resumo das funcionalidades de cada perfil.

17 17 Perfil Extended Slices SP e SI Partição de dados Predição ponderada Slices B Slices I Slices P CAVLC Perfil High Transformada Adaptativa Quantização em Percepção CABAC Perfil Main Grupo de Slices e ASO Slices Redundantes Perfil Baseline Figura 2.1: Perfis Baseline, Main, Extended e High do padrão H.264/AVC Além da divisão em diversos perfis, o padrão H.264/AVC também define 16 diferentes níveis, que são definidos em função da taxa de processamento e da quantidade de memória necessária para cada implementação. Com a definição do nível utilizado, é possível deduzir o número máximo de quadros de referência e a máxima taxa de bits que podem ser utilizados (SULLIVAN, 2004). O diagrama de blocos do codificador é apresentado na Figura 2.2, enquanto a Figura 2.3 apresenta o diagrama de blocos do decodificador. Estas figuras exibem as principais operações e a forma com que se relacionam. Quadro Atual (original) Predição INTER T Q Codificação de Entropia ME Quadros de Referência MC Predição INTRA Quadro Atual (reconstruído) Filtro + Figura 2.2: Diagrama em blocos de um codificador H.264/AVC T -1 Q -1

18 18 Quadros de Referência Predição INTER MC Predição INTRA Quadro Atual (reconstruído) Filtro + T -1 Q -1 Decodificação de Entropia Figura 2.3: Diagrama em blocos de um decodificador H.264/AVC As etapas de estimação e compensação de movimento (KUHN, 1999) do padrão H.264/AVC (módulo ME na Figura 2.2 e módulo MC nas Figuras 2.2 e 2.3) é onde se encontram a maior parte das inovações e dos ganhos obtidos pelo H.264/AVC sobre os demais padrões. Uma importante inovação é o uso de blocos de tamanho variável, onde se pode usar uma partição do macrobloco em blocos de tamanho 16x16, 16x8, 8x16, 8x8, 4x8, 8x4 ou 4x4 para realizar a ME e a MC. Outra inovação é a precisão de ¼ de pixel, para buscar o melhor casamento e para realizar a reconstrução do quadro. O H.264/AVC também prevê o uso de múltiplos quadros de referência, que não precisam ser somente os quadros I ou P imediatamente anteriores ou posteriores. Também é uma inovação o uso de predição bi-preditiva, ponderada e direta para os slices do tipo B. Além disso, os vetores de movimento podem apontar para fora da borda do quadro. Por fim, a predição de vetores de movimento com base nos vetores vizinhos também é uma novidade (ITU-T, 2003; RICHARDSON, 2003; WIEGAND, 2003a). O compensador de movimento (MC), presente tanto no codificador quanto no decodificador, é responsável por reconstruir o quadro atual a partir dos vetores de movimento e quadros de referência. Seu funcionamento será detalhado na próxima seção, uma vez que este trabalho é direcionado a este módulo do CODEC. A etapa de predição INTRA (Figuras 2.2 e 2.3) é outra inovação introduzida pelo padrão H.264/AVC, pois mesmo nos macroblocos do tipo I é realizada uma predição antes da aplicação da transformada, ainda no domínio espacial. Esta predição leva em conta as amostras já codificadas do slice atual. No que diz respeito às transformadas direta e inversa (módulos T e T -1 nas Figuras 2.2 e 2.3), o H.264/AVC introduziu algumas inovações. A primeira delas é que as dimensões da transformada foram definidas em 4x4 ao invés do tradicional 8x8. Outra inovação é relativa ao uso de uma aproximação inteira das transformadas de modo a facilitar a sua implementação em hardware de ponto fixo e evitar erros de casamento entre o codificador e o decodificador (MALVAR, 2003). Além disso, uma segunda transformada é aplicada sobre os elementos DC resultantes da DCT para todos os blocos de crominância (Hadamard 2x2) e para os macroblocos em que é feita a predição INTRA 16x16 (Hadamard 4x4) (RICHARDSON, 2003). A quantização no padrão H.264/AVC (módulos Q e Q -1 nas Figuras 2.2 e 2.3) é uma quantização escalar (RICHARDSON, 2002). O fator de quantização é função de um parâmetro QP de entrada, que é usado no codificador para controlar a qualidade da compressão e o bit-rate de saída.

19 19 O padrão H.264/AVC normatiza a utilização de um filtro redutor do efeito de bloco (módulo Filtro nas Figuras 2.2 e 2.3). Este filtro era opcional na maioria dos demais padrões de compressão de vídeo, mas passou a ser obrigatório no H.264/AVC. Uma inovação importante do filtro definido no padrão H.264/AVC é que este filtro é adaptativo, conseguindo distinguir entre uma aresta real da imagem e um artefato gerado por um elevado passo de quantização. Na codificação de entropia (Figuras 2.2 e 2.3) o H.264/AVC também introduz ferramentas que aumentam bastante a eficiência de codificação deste bloco. Há, basicamente, dois tipos de codificação: a codificação de comprimento variável adaptativa ao contexto (CAVLC) e a codificação aritmética adaptativa baseada em contexto (CABAC). A principal inovação é o uso de codificação adaptativa baseada em contextos. Nesta codificação, a maneira com que os diversos elementos sintáticos são codificados depende do elemento a ser codificado, da fase em que se encontra o algoritmo de codificação e dos elementos sintáticos que já foram codificados. 2.2 Compensação de Movimento (MC) Esta seção apresenta a Compensação de movimento (MC) abordando também a Estimação de movimento (ME), uma vez que estes módulos estão fortemente relacionados. A estimação de movimento está presente apenas no codificador e têm como função encontrar a região dos quadros de referência que mais se assemelha ao macrobloco atual. Este módulo é o que apresenta a maior complexidade computacional dentre todos os módulos de um codificador H.264/AVC (PURI, 2004). Este grande custo computacional é função das inovações inseridas neste módulo do padrão, que tiveram o objetivo de atingir elevadas taxas de compressão. Reside nos módulos da ME e MC as principais fontes de ganhos do H.264/AVC em relação aos demais padrões de compressão de vídeo (WIEGAND, 2003, RICHARDSON, 2003). A estimação de movimento deve prover as ferramentas de codificação capazes de localizar, nos quadros de referência, qual macrobloco mais se assemelha ao macrobloco atual. Assim que é encontrado este macrobloco, a ME deve gerar um vetor indicando a posição deste macrobloco no quadro de referência. Este vetor é chamado de vetor de movimento e deve ser inserido junto com a codificação do macrobloco. Para a realização da estimação de movimento é considerado apenas o componente de luminância do macrobloco. Cada componente de crominância possui a metade da resolução horizontal e vertical do componente de luminância, então os componentes horizontal e vertical de cada vetor de movimento são divididos por dois para serem aplicados aos blocos de crominância. A compensação de movimento deve ser capaz de a partir dos vetores de movimento e dos quadros de referência, reconstruir a predição do quadro atual. Durante a fase de codificação, este quadro será subtraído do quadro atual para gerar o quadro de resíduos que passará pela transformada. Na decodificação, o resultado da compensação é somado aos resíduos gerados pela transformada inversa, para gerar o quadro atual.

20 20 O módulo de compensação de movimento deve ter as ferramentas necessárias para decodificar todos os modos de codificação utilizados pela ME. Entre elas estão algumas das principais inovações do padrão H.264/AVC e que são listados abaixo: Tratar múltiplos tamanhos de partições de macroblocos; Utilizar múltiplos quadros de referência anteriores e posteriores; Tratar vetores que apontam para fora da borda do quadro; Reconstruir os macroblocos considerando uma precisão de ¼ de pixel para os vetores de movimento; Reconstruir os macroblocos que utilizam as predições bi-preditiva, ponderada e direta para slices do tipo B; Reconstruir corretamente os macroblocos do tipo skip para slices tipo P e B. Interpretar corretamente os vetores construídos com base na predição de vetores; Cada uma destas inovações será descritas nas próximas sub-seções, em maiores detalhes Tamanho de blocos variável A principal inovação do H.264/AVC no ponto de vista da estimação de movimento está na possibilidade de utilização de tamanhos de blocos variáveis para realizar a estimação e compensação de movimento. Ao invés de usar um macrobloco inteiro na estimação de movimento, o padrão H.264/AVC permite o uso de partições de macrobloco e partições de sub-macroblocos. As partições de macroblocos possuem tamanhos de 16x16, 8x16, 16x8 e 8x8. As partições de sub-macrobloco possuem tamanhos de 8x8, 8x4, 4x8, 4x4. Cada partição pode possuir seu próprio vetor de movimento Múltiplos quadros de referência Outra característica importante do padrão H.264/AVC é o uso de múltiplos quadros de referência. No padrão H.264/AVC os quadros de referência não precisam ser somente os quadros I ou P imediatamente anteriores ou posteriores ao quadro atual. Há a opção de se usar como referência múltiplos quadros temporalmente para frente ou para trás do quadro atual (RICHARDSON, 2003). O padrão define, inclusive, que quadros do tipo B podem ser usados como referência na predição, diferentemente do que acontece no padrão MPEG-2 (ITU-T, 1994). O padrão H.264/AVC define duas listas contendo os quadros de referência. A lista chamada de lista 0 contém como primeiro quadro o quadro passado mais próximo, seguido de quaisquer outros quadros passados, seguidos de quaisquer outros quadros futuros. A lista chamada lista 1 contém como primeiro quadro o quadro futuro mais

21 21 próximo, seguido de quaisquer quadros futuros, seguidos de quaisquer outros quadros passados. O padrão H.264/AVC define um tipo de armazenamento especial nas listas, o quadro long_term (ITU-T,2003). Se um quadro se mostrar útil para ser referenciado por um longo período de tempo, o mesmo é assinalado como sendo um quadro de referência long_term, o que o mantém no buffer de quadros até que o gerenciador de listas o apague Vetores apontando para fora das bordas do quadro A possibilidade de utilizar vetores de movimento que apontam para fora dos limites dos quadros também faz parte do padrão H.264/AVC. Neste caso é realizada uma extrapolação dos quadros nas bordas Precisão de quarto de pixel Uma outra característica importante da estimação e compensação de movimento do padrão H.264/AVC é que ela prevê uma precisão de 1/4 de pixel para os vetores de movimento. Normalmente, os movimentos que acontecem de um quadro para o outro não estão restritos às posições inteiras de pixel. Assim, se são utilizados apenas vetores de movimento com valores inteiros, normalmente não é possível encontrar casamentos ótimos. Por isso, o padrão H.264/AVC prevê a utilização de vetores de movimento com valores fracionários de 1/2 pixel e de 1/4 de pixel. Na Figura 2.4 é apresentado um exemplo da precisão do vetor de movimento com valores fracionários. Figura 2.4: (a) quadro atual a ser predito; (b) predição com vetor de movimento inteiro com valores inteiros (1, -1); (c) vetor de movimento com valores fracionários (0,5 ; 0,75) Na Figura 2.4 (a) está representado, com pontos pretos, um bloco 4x4 do quadro atual que será predito a partir de uma região do quadro de referência na vizinhança da posição do bloco atual. Se os componentes horizontal e vertical do vetor de movimento são inteiros, então as amostras necessárias para o casamento estão presentes no bloco de referência. Como exemplo, a Figura 2.4 (b) apresenta, com pontos em cinza, um possível casamento do bloco atual no quadro de referência, onde o vetor de movimento utiliza apenas valores inteiros, neste caso, o vetor de movimento é (1, -1). Se um dos

22 22 componentes do vetor de movimento apresenta valor fracionário, então as amostras preditas são geradas a partir da interpolação entre amostras adjacentes do quadro de referência. Como exemplo, a Figura 2.4 (c) apresenta um casamento com um vetor de movimento que utiliza dois valores fracionários, com as amostras sendo geradas por interpolação. No caso do exemplo, o vetor é ( 0,5; 0,75). No H.264/AVC, a estimação e compensação de movimento usando ¼ de pixel é obrigatória. Na prática, a estimação é realizada com precisão de ¼ de pixel para os componentes de luminância. Para os elementos de crominância, a precisão é, na verdade, de 1 8de pixel. A interpolação para ¼ de pixel de pixel é realizada em dois passos. No primeiro passo, é realizada a interpolação dos quadros para ½ pixel, usando um filtro FIR de seis taps, com pesos (1/32, -5/32, 5/8, 5/8, -5/32, 1/32), da forma como está descrito na Figura 2.5. Na Figura 2.5, as posições inteiras são representadas por letras maiúsculas e as de ½ pixel por letras minúsculas. A aa B C bb D E F G b H I J j cc dd h m ee ff K L M s N O P Q gg R S hh T Figura 2.5: Interpolação para posições de ½ pixel para o componente de luminância. No segundo passo, são interpoladas as posições de ¼ de pixel, a partir das amostras construídas no primeiro passo e das amostras inteiras, usando a média simples entre dois pontos, na relação que está apresentada na Figura 2.6. G a b c H h i j k m M s N G b H d f h j m n q M s N G b H h j m M s N Figura 2.6: Interpolação para posições de ¼ de pixel

23 23 Para os vetores de crominância, que utilizam uma resolução de 1 8de pixel, usa-se interpolação linear. As amostras interpoladas são geradas em intervalos de oito amostras entre amostras inteiras em cada componente de crominância. Considerando a Figura 2.7 como referência, cada posição interpolada a é uma combinação linear das amostras inteiras da vizinhança que, no caso da Figura 2.7, são as posições A, B, C e D. A B d y a 8-d x 8-d y C D Figura 2.7: Interpolação para componentes de crominância Bi-predição e Predição Ponderada Essa funcionalidade permite que um bloco seja predito a partir de dois quadros de referência, um quadro da lista 0 e um quadro da lista 1. A predição bi-preditiva utiliza um bloco de referência que é construído a partir de dois blocos, um na lista 0 e outro na lista 1. Neste caso, são necessários dois vetores de movimento, um para o quadro de referência da lista 0 e outro para o quadro de referência da lista 1. Então, cada amostra do módulo de predição é calculada como uma média entre as amostras dos quadros das listas 0 e 1. A predição ponderada é um método de escalonar os valores das amostras da compensação de movimento de um macrobloco num quadro do tipo P ou B. Ela faz parte dos perfis Main e Extended do padrão H.264/AVC. Existem dois modos de predição ponderada: modo explícito, que pode ser utilizada nos slices P, SP e B; e o modo implícito, que pode ser usado apenas em slices do tipo B. Um único fator de escala está associado a cada quadro de referência, para cada componente de cor em cada slice. No modo explícito, os parâmetros que compõem o fator de escala estão codificados no cabeçalho do slice. No modo implícito, esses parâmetros são derivados com base na distância relativa entre o quadro corrente e seus quadros de referência. Cada partição de macrobloco utiliza os parâmetros da predição ponderada associados ao seu índice de referência. A predição ponderada é realizada após a predição em quarto de pixel da compensação de movimento. Após a predição ponderada, uma operação de saturação é aplicada para manter as amostras dentro da faixa de valores determinada pelo padrão. A predição ponderada é especialmente útil em fades nas seqüências de vídeos.

24 Predição Skip e Direta O padrão H.264/AVC também aprimora o conceito de macrobloco skip em relação aos padrões anteriores. Diferente dos outros padrões, um macrobloco skip no padrão H.264/AVC usa uma predição de vetores de movimento, ao invés de simplesmente copiar o bloco co-localizado. O bloco co-localizado, no padrão H.264/AVC, é o bloco pertencente ao quadro de referência de índice 0 da lista 1, o qual se encontra na mesma posição que o bloco corrente. Essa predição calcula o vetor de movimento a partir dos vetores vizinhos para copiar uma área do quadro de referência. Além disso, se o macrobloco skip estiver em um slice B, o macrobloco é reconstruído no decodificador usando predição direta (SAHAFI, 2005). Além dos vetores de movimento, os índices de quadros de referência também são preditos baseados nos índices dos macroblocos vizinhos, utilizando a predição direta. A predição direta pode ser aplicada tanto no macrobloco inteiro quanto, individualmente, em uma ou mais das 4 partições de macrobloco no formato 8x8. A predição direta se divide em direta espacial e direta temporal, sendo que a direta espacial é uma inovação do H.264 enquanto a direta temporal é uma simplificação da predição encontrada no MPEG-4 parte 2. A predição direta utiliza informações presentes no quadro co-localizado que, segundo o padrão H.264, é o quadro de referência índice 0 da lista 1. Por bloco co-localizado entende-se ao bloco do quadro colocalizado que se encontra na mesma posição que o bloco corrente Predição de Vetores de Movimento Devido à alta correlação entre blocos vizinhos, os vetores de movimento de cada módulo são codificados de forma diferencial com base nos vetores da vizinhança. A predição de vetores de movimento no H.264/AVC define a predição padrão, a predição direta espacial e a predição direta temporal, além da predição de macroblocos skip. Na predição padrão, o vetor do bloco corrente é calculado somando-se os vetores de movimento diferenciais, transmitidos no bitstream, aos vetores de movimento preditos (predictive motion vectors - PMV) (ITU-T,2003), normalmente obtidos a partir da mediana dos vetores vizinhos. Na predição direta espacial os vetores são derivados considerando os vetores de movimento do bloco co-localizado, além dos vetores de blocos vizinhos como na predição padrão. A predição direta temporal utiliza a referência do bloco co-localizado para calcular as referências do bloco atual. De acordo com a distância entre as referências e o quadro corrente, aplica-se um fator de ponderação aos vetores do bloco co-localizado para se obter os vetores do bloco corrente. Macroblocos skip são preditos de acordo com o tipo de slice ao qual pertencem. Em um slice tipo P os vetores do macrobloco skip podem assumir o valor zero ou ainda podem ser tratados pela predição padrão. Já em slices tipo B, esses macroblocos são preditos pela predição direta, espacial ou temporal de acordo com o modo utilizado na codificação.

25 Como a predição de vetores será o foco deste trabalho, os modos de predição de vetores definidos pelo H.264/AVC e seus algoritmos serão abordados e discutidos com maior nível de detalhes no Capítulo 3. 25

26 3 PREDITOR DE VETORES DE MOVIMENTO (MVP) Este capítulo tem o objetivo de apresentar, em detalhes, o processo de predição de vetores de movimento no padrão H.264/AVC. Primeiramente serão descritos os modos utilizados em slices P e, em seguida, os modos utilizados para slices tipo B. Para validar os conceitos envolvidos no processo de predição, foi desenvolvido um programa utilizando a linguagem de programação C++. A descrição do programa também será assunto para este capítulo. Por ser o foco deste trabalho, o algoritmo de predição será analisado sob o ponto de vista do decodificador. 3.1 Algoritmo de Predição de Vetores Devido à elevada correlação entre blocos vizinhos, o padrão H.264/AVC define que os vetores de movimento, assim como os índices dos quadros de referência, sejam inferidos com base nos vetores de movimento e índices de referência dos blocos vizinhos. Esses vetores são chamados de vetores de movimento preditos (predictive motion vectors - PMV) (ITU-T,2003). Desta forma, apenas os vetores de movimento diferencias são codificados no bitstream, para depois serem somados aos PMVs, obtendo assim, os vetores de movimento do bloco atual. Os PMVs são normalmente obtidos aplicando a mediana aos vetores dos blocos vizinhos. No entanto, macroblocos skip e macroblocos que sofrem predição direta são tratados de maneiras diferentes. Os vetores de movimento calculados apresentam precisão de ¼ de amostra e são utilizados para interpolação de luminância. A partir desses vetores são derivados os vetores de movimento para crominância com precisão de 1/8 de amostra. A ordem de predição segue a ordem de duplo Z como ilustra a Figura 3.1.

27 27 Figura 3.1: Ordem de predição de vetores no MB No H.264/AVC, o bloco corrente, seja ele uma partição ou sub-partição, é denominado bloco E. As partições ou sub-partições contíguas ao bloco corrente são nomeadas com as letras A, B, C e D. Sendo A o bloco localizado à esquerda de E, B é o bloco localizado imediatamente acima de E, C é a partição acima e à direita de E e finalmente, D se localiza acima e a esquerda do bloco corrente E. A Figura 3.2 exemplifica essa relação entre os blocos vizinho. D B C D B C A A E E Figura 3.2: Relação entre blocos vizinho (a) em formatos idênticos e (b) em formatos diferentes Partições já processadas dentro do macrobloco corrente também são consideradas partições vizinhas e, portanto, são consideradas na predição das demais partições. Os modos de predição serão analisados nas sub-seções seguintes, na sub-seção será abordada a predição em slices tipo P enquanto a sub-seção abordará a predição em slices B Predição de Slices P Em slices P é utilizado o modo de predição padrão além de um modo específico para macroblocos skip. Para slices P, a predição é procedida apenas para lista 0.

28 28 A predição padrão começa pela verificação da presença dos blocos vizinhos. Nesse estágio é verificado se os blocos encontram-se dentro do quadro, se pertencem ao slice corrente e se já foram decodificados. Blocos que não satisfazem essas condições são marcados com não disponíveis e seus vetores são considerados zero. A operação padrão para o cálculo do PMV é a mediana aplicada a três vetores de movimento dos blocos vizinhos. Normalmente são utilizados os vetores dos blocos A, B e C. Caso C não esteja disponível, é utilizado o vetor do bloco D. No caso de apenas um dos blocos ter a mesma referência do bloco corrente, seu vetor é setado como PMV. Existe outra possibilidade no caso de blocos 16x8 e 8x16, onde estes compartilhem a mesma referência de seus vizinhos. Para partições no formato 8x16, a partição mais à esquerda tem o valor do vetor de movimento do vizinho A selecionado e a partição inferior tem o vetor de movimento do vizinho C selecionado. Para partições no formato 16x8, a partição superior do macrobloco tem o valor do vetor de movimento do vizinho B selecionado e a partição inferior tem o vetor de movimento do vizinho A selecionado. Quando a operação da mediana for utilizada, mas apenas o bloco A estiver disponível, seu vetor é setado como PMV. Uma vez que o PMV é calculado, a próxima etapa é somar a ele o vetor de movimento diferencial presente no bitstream. O resultado é o vetor de movimento definitivo e é atribuído a todo o bloco, seja ele um macrobloco, uma partição ou subpartição. Existem ainda macroblocos cujos vetores de movimento diferenciais não estão presentes no bitstream, a esses é dado o nome de macroblocos skip. Os macroblocos skip recebem um tratamento a parte. Quando em slices tipo P, os macroblocs skip utilizam como quadro de referência o índice 0 da lista 0. Quando o macrobloco skip tem seu vizinho A ou seu vizinho B marcados como não disponíveis, seus vetores são setados como sendo zero. O mesmo acontece quando A ou B utilizam como quadro de referência o índice 0 da lista 0 e seus vetores de movimento são iguais a zero. Nos outros casos, a predição padrão é utilizada. A seleção do tipo de predição a ser utilizada e do particionamento dos macroblocos é derivada com base no tipo do macrobloco. Na Tabela 3.1 é mostrada a relação entre o tipo do macrobloco, seu particionamento e o tipo da predição utilizado em cada partição.

29 29 Tipo de Macrobloco Tabela 3.1: Tipos de macroblocos em Slices tipo P Nome N º de Partições Tipo de Predição Partição 0 Tipo de Predição Partição 1 Dimensões das Partições 0 P_L0_16x16 1 Pred_L0-16 x 16 1 P_L0_L0_16x8 2 Pred_L0 Pred_L0 16 x 8 2 P_L0_L0_8x16 2 Pred_L0 Pred_L0 8 x 16 3 P_8x x 8 4 P_8x8ref x 8 inferido P_Skip 1 Pred_L0-16 x 16 A primeira coluna mostra os tipos de macrobloco possíveis em slices P e a segunda coluna mostra o nome de cada tipo de macrobloco. Na terceira coluna aparece o número de partições para cada tipo de macrobloco. A quarta e quinta coluna mostram o tipo de predição para cada uma das partições (quando existem). A sexta coluna mostra as dimensões de cada partição. Pred_L0 significa que a partição recebe predição apenas para lista 0. No caso dos tipos P_Skip e P_L0_16x16, o tipo de predição para a segunda partição não se aplica, já que possuem apenas uma partição. Os tipos P_8x8 e P_8x8ref0 possuem quatro partições e o tipo de predição e o particionamento para cada uma delas é determinado pelo tipo do sub-macrobloco segundo Tabela 3.2. Tipo de Sub- Macrobloco Tabela 3.2: Tipos de sub-macroblocos em Slices tipo P Nome N º de Sub- Partições Tipo de Predição Dimensões das Sub- Partições inferido P_L0_8x8 1 Pred_L0 8 x 8 1 P_L0_8x4 2 Pred_L0 8 x 4 2 P_L0_4x8 2 Pred_L0 4 x 8 3 P_L0_4x4 4 Pred_L0 4 x 4 Todos os sub-tipos de macrobloco aplicam o mesmo tipo de predição. As únicas diferenças são o número e as dimensões das sub-partições.

30 Predição de Slices B A predição dos vetores de movimento em slices tipo B pode ser efetuada através do modo padrão ou utilizando predição direta. A predição direta se divide em direta espacial e direta temporal, sendo que a direta espacial é uma inovação do H.264/AVC enquanto a direta temporal é uma simplificação da predição encontrada no MPEG-4 parte 2 (ITU-T,1999). Esse tipo de tratamento é aplicado a macroblocos do tipo direta ou a macroblocos do tipo skip. A predição padrão em slices tipo B é similar àquela utilizada em slices P e, portanto, não será descrita novamente. Enquanto para slices P apenas a lista 0 é considerada, nos slices B tanto lista 0 como lista 1, são usadas no processo de predição. A predição direta utiliza informações presentes no quadro co-localizado que, segundo o padrão H.264/AVC, é o quadro de referência índice 0 da lista 1. Por bloco co-localizado entende-se ao bloco do quadro co-localizado que se encontra na mesma posição que o bloco corrente. A predição direta espacial inicia o processo de decodificação calculando os índices dos quadros de referência. Para isso é verificada a presença das partições e sub-partições vizinhas. Caso estas não estejam disponíveis, seu índice de referência assume valor zero. Assim como na predição padrão, caso C esteja não disponível, o valor de D é utilizado (ver Figura 3.2). Após encontrar os valores dos índices de referência da vizinhança, uma operação chamada Menor Positivo é aplicada sobre os índices de referência para determinar o valor da referência do macrobloco atual. Essa operação assume o valor do menor índice de referência positivo. Caso todos índices sejam negativos, assume-se o maior índice negativo. Quando os índices de referência da lista 0 e lista 1 são negativos, ambas assumem índices de referência igual a zero, enquanto a flag directzeropredictionflag é ligada, para indicar a ocorrência dessa situação. Nesta fase também são determinados o vetores de movimento com base nos vetores dos blocos vizinhos ao macrobloco corrente, da forma já descrita anteriomenete. O próximo passo é dividir o macrobloco em quatro partições de 8x8, que por sua vez serão divididas em quatro sub-partições de 4x4. Cada sub-partição será predita de maneira independente. Para cada bloco 4x4 são selecionados os vetores de movimento e os índices de referência dos blocos co-localizados, para determinar o valor da flag colzeroflag. À flag ColZeroFlag é atribuído o valor um quando: O quadro de referência de índice 0 da lista 1 for do tipo long_term; O índice de referência da lista 0 do bloco co-localizado for igual a zero. Caso a lista 0 não seja utilizada, é analisada a lista 1. Os vetores de movimento, na resolução de quarto de pixel, se encontrarem no intervalo entre -1 e 1. Uma vez calculado ColZeroFlag, pode-se determinar o modo de predição a ser adotado. Os vetores de movimento do bloco corrente serão zerados sempre que: A flag directzeropredictionflag estiver ligada;

31 31 O índice de referência da lista avaliada, 0 ou 1, for igual a -1; O índice de referência da lista avaliada, 0 ou 1, for igual a 0 e ColZeroFlag for igual a 1; Caso as condições não sejam atendidas, a predição padrão, já descrita anteriormente, será aplicada sobre este bloco. Neste caso, o valor do PMV será o valor dos vetores para todo o bloco 4x4. Esse processo ocorre independentemente para lista 0 e lista 1. A outra possibilidade de predição de vetores em slices tipo B, a predição direta temporal, é uma simplificação da predição utilizada pelo MPEG-4 Parte 2. Em um primeiro momento, são determinados os índices de referência. Para a lista 0 é atribuído o índice de referência associado ao quadro referência do pela lista 0 do bloco co-localizado. Enquanto ao índice da lista 1 é atribuído o valor zero. Inicia-se, então, a fase de predição dos vetores de movimento que, a exemplo da predição direta espacial, são processados em blocos 4x4. Caso o quadro de referência seja marcado como long_term, o vetor de movimento da lista 0 assume o valor do vetor de movimento co-localizado. O vetor de movimento da lista 1 assume o vetor zero nesse bloco. Caso contrário o vetor é calculado com base no vetor co-localizado e na distância entre o quadro atual e os quadros de referência. A distância entre os quadros é calculada utilizando o contador de ordem de imagem (POC Picture Order Counter) (ITU- T,2003). Um fator de escala é determinado conforme as equações 3.1 e 3.2 onde TB é diferença entre o POC do quadro de referência da lista 0 e o POC do quadro de referência lista 1 e TD e a diferença entre o POC do quadro corrente e o POC do quadro de referência da lista 0. Os valores de TB e TD devem ser limitados ao intervalo [-128, 127]. TX ( Absoluto( TD / 2)) / TD = (3.1) DistScaleF actor = Clip3 ( 1024,1023,( TB * TX + 32) >> 6) (3.2) O fator de escala é aplicado ao vetor de movimento do bloco co-localizado para obter o valor do vetor para lista 0. O vetor para lista 1 é a subtração do vetor da lista 0 do vetor co-localizado. As equações 3.3 e 3.4 representam o calculo dos vetores onde mvcol é o vetor co-localizado e mvl0 e mvl1 são os vetores de lista 0 e lista 1 respectivamente. mvl 0 = ( DistScaleFactor * mvcol + 128) >> 8 (3.3) mvl1 = mvl0 mvcol (3.4)

32 32 Na predição direta espacial, a bi-predição é sempre utilizada, ou seja, tanto lista 0 como lista 1 são utilizadas. A Tabela 3.3 determina para cada tipo de macrobloco o número de partições, suas dimensões e o tipo de predição utilizada em cada partição. Tipo de Macrobloco Tabela 3.3: Tipos de macroblocos em Slices tipo B Nome N º de Partições Tipo de Predição Partição 0 Tipo de Predição Partição 1 Dimensões das Partições 0 B_Direct_16x16 - Direto - 8 x 8 1 B_L0_16x16 1 Pred_L0-16 x 16 2 B_L1_16x16 1 Pred_L1-16 x 16 3 B_Bi_16x16 1 BiPred - 16 x 16 4 B_L0_L0_16x8 2 Pred_L0 Pred_L0 16 x 8 5 B_L0_L0_8x16 2 Pred_L0 Pred_L0 8 x 16 6 B_L1_L1_16x8 2 Pred_L1 Pred_L1 16 x 8 7 B_L1_L1_8x16 2 Pred_L1 Pred_L1 8 x 16 8 B_L0_L1_16x8 2 Pred_L0 Pred_L1 16 x 8 9 B_L0_L1_8x16 2 Pred_L0 Pred_L1 8 x B_L1_L0_16x8 2 Pred_L1 Pred_L0 16 x 8 11 B_L1_L0_8x16 2 Pred_L1 Pred_L0 8 x B_L0_Bi_16x8 2 Pred_L0 BiPred 16 x 8 13 B_L0_Bi_8x16 2 Pred_L0 BiPred 8 x B_L1_Bi_16x8 2 Pred_L1 BiPred 16 x 8 15 B_L1_Bi_8x16 2 Pred_L1 BiPred 8 x B_Bi_L0_16x8 2 BiPred Pred_L0 16 x 8 17 B_Bi_L0_8x16 2 BiPred Pred_L0 8 x B_Bi_L1_16x8 2 BiPred Pred_L1 16 x 8 19 B_Bi_L1_8x16 2 BiPred Pred_L1 8 x B_Bi_Bi_16x8 2 BiPred BiPred 16 x 8 21 B_Bi_Bi_8x16 2 BiPred BiPred 8 x B_8x x 8 inferido B_Skip - Direto - 8 x 8

33 33 Na Tabela 3.3, Pred_L0 significa que apenas a lista 0 é utilizada, Pred_L1 significa que apenas a lista 1 é utilizada, enquanto que para BiPred tanto a lista 0 quanto a lista 1 são utilizadas. Quando o tipo de predição é Direta, a predição direta é utilizada. Quando o tipo de macroblo é 22, as quatro partições 8x8 são sub-particionadas e preditas de acordo com a Tabela 3.4. Tipo de Sub- Macrobloco Tabela 3.4: Tipos de sub-macroblocos em Slices tipo B Nome N º de Sub- Partições Tipo de Predição Dimensões das Sub- Partições inferido mb_type 4 Direto 4 x 4 0 B_Direct_8x8 4 Direto 4 x 4 1 B_L0_8x8 1 Pred_L0 8 x 8 2 B_L1_8x8 1 Pred_L1 8 x 8 3 B_Bi_8x8 1 BiPred 8 x 8 4 B_L0_8x4 2 Pred_L0 8 x 4 5 B_L0_4x8 2 Pred_L0 4 x 8 6 B_L1_8x4 2 Pred_L1 8 x 4 7 B_L1_4x8 2 Pred_L1 4 x 8 8 B_Bi_8x4 2 BiPred 8 x 4 9 B_Bi_4x8 2 BiPred 4 x 8 10 B_L0_4x4 4 Pred_L0 4 x 4 11 B_L1_4x4 4 Pred_L1 4 x 4 12 B_Bi_4x4 4 BiPred 4 x Software para Predição de Vetores Esta seção descreve a forma como foi desenvolvido o software para validar os conceitos da predição de vetores e analisar o comportamento do preditor aplicado a seqüências reais de vídeo. Devido à grande complexidade envolvida em projetar e descrever o hardware para o preditor de vetores, foco deste trabalho, optou-se por começar pelo desenvolvimento de um software que implementasse todas as funcionalidades do preditor de vetores para o perfil Main. O desenvolvimento desse software teve como objetivo o estudo de todos os processos da predição de vetores em uma abordagem prática. Além disso, esse software deu suporte ao desenvolvimento do hardware, portanto as estruturas utilizadas foram pensadas visando uma fácil transcrição para VHDL. Para esta implementação, foi utilizada a linguagem de programação C++.

34 34 As bases para o desenvolvimento do software foram a norma do padrão H.264/AVC além do software de referência do padrão na versão JM 9.5 (IMAGE, 2006). O software de referência foi desenvolvido em conjunto por pesquisadores integrantes do JVT e tem o objetivo de provar conceitos relacionados ao H.264/AVC. O JM 9.5, além de servir como base no desenvolvimento do software para predição de vetores de movimento, também foi utilizado como fonte de casos de testes para a validação, tanto do software, como do hardware desenvolvidos. O software para predição de vetores de movimento foi desenvolvido de forma incremental. Primeiramente foi desenvolvida a predição padrão para slices tipo P (apenas lista 0). Mas, para tratar vídeos no perfil Main, a implementação foi estendida. Anexou-se, então, o tratamento para predição padrão em slices tipo B (lista 0 e lista 1) seguido da predição direta espacial e, finalmente, a predição direta temporal. O fluxograma do software apresentado na Figura 3.3 foi organizado em um laço principal, que controla o número de macroblocos, e dois laços internos que controlam o andamento das partições e das sub-partições, de acordo com os tipos de macrobloco e sub-macroblocos. A Figura 3.3 mostra o fluxograma do software desenvolvido.

35 Figura 3.3: Fluxograma do software de predição de vetores de movimento 35

36 36 No primeiro passo, representado no fluxograma pelo bloco Inicialização de Variáveis, são inicializadas as variáveis de contexto que controlam o processo de predição. Dentre essas variáveis, max_x e max_y informam as dimensões dos quadros e direct_spatial_mv_pred_flag informa o modo da predição direta. As informações referentes as partições de cada tipo de macrobloco, também são inicializadas nesse estágio e armazenadas em vetores. As informações da Tabela 3.1, por exemplo, são armazenadas em um vetor de 5 posições, chamado partquant. As demais tabelas mostradas acima são armazenadas nos vetores subpartquant, BSpartQuant e BSsubpartQuant. Começa, então, o processo de predição propriamente dito. O Laço de MB é responsável pela iteração a nível de macrobloco e mantém um contador com o número de macroblocos processados. Apartir desse contador, é possível determinar a que quadro pertence o macrobloco atual, bem como a posição do macrobloco dentro do quadro. Essas informações são necessárias para setar as variáveis slice_type, block_x e block_y. A seguir, quando necessário, é feito um pré-processamento específico para a predição direta espacial, onde é checada a disponibilidade das partições vizinhas obtendo-se os índices de referência das mesmas. É determinado, então, o valor do índice de referência da partição atual e o valor de directzeropredictionflag, de acordo com o processo de predição direta espacial descrito anteriormente. O Laço de Partição é controlado pelo número de partições existentes no macrobloco. Essa informação é consultada no vetor partquant, para slices tipo P, ou no vetor BSpartQuant, no caso de slices do tipo B. Cada partição tem seus próprios índices de referência. No bloco Aquisição das Referências é feita a escolha desses índices. De acordo com os tipos de slice, macrobloco e partição, os índices de referência são obtidos de maneiras diferentes, podendo ser determinados a partir dos vizinhos ou mesmo vindo codificados no bitstream. No Laço de Sub-partição, é feita a iteração a nível de sub-partições. O número de passadas nesse laço é determinado com base no tipo da partição segundo o vetor subpartquant, para slices P, e o vetor BSsubpartQuant, para slices tipo B. Dentro desse laço é procedida toda a predição dos vetores de movimento de forma individual para cada sub-partição. O tipo da predição dos vetores de movimento é selecionado no bloco Tipo de Predição, podendo ser predição padrão, predição direta espacial ou predição direta temporal. No caso da predição padrão, primeiramente é testada a disponibilidade dos blocos vizinhos, para os vizinhos disponíveis é feita a busca dos vetores de movimento e índices de referência dos mesmos. Para a predição direta espacial, além do teste de disponibilidade dos vizinhos e da busca dos vetores e índices de referência destes, são buscados os vetores de movimento e índices de referência colocalizados. Com isso, é possível determinar colzeroflag e VecZeroFlag. Os dois tipos de predição citados acima são então submetidos a um processo que determina os vetores de movimento. Este processo é representado pelo bloco

37 37 Determinação dos MVs e Referências, na Figura 3.3. Os vetores podem ser calculados a partir da mediana dos vetores vizinhos ou ainda pode assumir o valor de vetores vizinhos, comforme já foi detalhado anteriormente. Na predição direta temporal, processada pelo bloco Calculo da Predição Direta Temporal, são obtidos os vetores de movimento e índices de referência co-localizados. Com os índices de referência é calculado o POC (picture order counter) dos quadros de referência. Os valores de POC, por sua vez, são utilizados no cálculo do fator de escala DistScaleFactor. Esse fator de escala é, então, aplicado aos vetores de movimento colocalizados, obtendo-se os vetores do bloco atual. Os módulos responsáveis por cada um dos tipos de predição geram os vetores de movimento preditos (PMVs). No entanto, em alguns casos, é necessário somar aos PMVs os vetores diferencias presentes no bitstream. Essa soma é feita no bloco Salva MVs e Referências que também é responsável por salvar os vetores de movimento e índices de referência nas posições corretas. Os blocos Calcula Posição da Sub-Partição e Calcula Posição da Partição são responsáveis por calcular a posição do próximo bloco a ser processado no quadro ao qual pertence. Isso é necessário para que seja realizada de forma correta o teste de disponibilidade dos blocos vizinhos e a busca dos blocos co-localizados. Quando é concluído o processamento de cada macrobloco, seus MVs e índices de referência são salvos na memória co-localizada e, se necessário, os blocos vizinhos são atualizados. No fluxograma da Figura 3.3, o bloco que efetua esses processos é nomeado como Atualiza Memória. A posição do próximo macrobloco a ser processado é calculada no bloco Calcula Posição do MB. A validação foi feita utilizando dados extraídos de vídeos reais, através do software de referência do padrão H.264/AVC. Para isso, foram inseridas funções no código fonte do software de referência, JM 9.5, afim de extrair dados de entrada e de saída do preditor de vetores implementado no software de referência. Os dados extraídos foram salvos no arquivo de texto chamado MV_out.txt. Após um estudo detalhado no software de referência, foram encontradas as variáveis e os pontos em que estas variáveis deveriam ser capturadas. Todas as inserções no código de referência foram feitas no arquivo macroblock.c do decodificador (ldecod). As variáveis capturadas na entrada do preditor foram: mb_type : tipo do macrobloco mb_subtipe:tipo das partições mvd_x_l0, mvd_y_l0 : vetor de movimento diferencial para lista 0 mvd_x_l1, mvd_y_l1 : vetor de movimento diferencial para lista 1 ref_frame_l0: índice de referência para lista 0 ref_frame_l1: índice de referência para lista 1 Na saída, foram capturadas as seguintes variáveis: mb_mv_l0:vetor de movimento lista 0 mb_mv_l1: vetor de movimento lista 1

38 38 mb_ref_l0: índice de referência lista 0 mb_ref_l1: índice de referência lista 1 O software desenvolvido lê as entradas contidas no arquivo de texto, procede a predição dos vetores de movimento e índices de referência e compara seus resultados aos resultados gerados pelo software de referência. A estrutura do arquivo MV_out.txt é composta por uma linha contendo o tipo do macrobloco, seguido de um contador de macrobloco e de um contador de slices. As 4 linhas seguintes contêm o tipo das partições, quando necessário. A seguir, vêm as linhas contendo informações de índices de referência da lista 0 e da lista 1, seguido das linhas com os vetores de movimento diferenciais da lista 0 e da lista 1. Essas informações são utilizadas no processo de predição de vetores. As linhas seguintes contêm o resultado da predição, índices de referência lista 0 e da lista 1, seguidos pelos vetores de movimento lista 0 e da lista 1. Depois de encontradas as variáveis, o software de referência foi executado para extrair dados de uma seqüência de vídeo real, afim de validar o software desenvolvido. A seqüência de vídeo utilizada foi Foreman.yuv, na resolução QCIF de 176x144 pixels. Nessa definição, existem 99 macroblocos em cada slice dispostos em 9 linhas de 11 macroblocos. Primeiramente, foi validada apenas a predição padrão para lista 0, utilizando 100 quadros do tipo P. Para isso a seqüência de vídeo foi codificada utilizando apenas quadros do tipo P. O processo de decodificação desse vídeo gerou o arquivo com os dados capturados. Este arquivo foi passado como entrada para o preditor de vetores desenvolvido que comparou seus resultados aos resultados do software de referência. Quando um erro é encontrado, o preditor pára o processamento e indica o tipo do erro. Após algumas correções, o preditor desenvolvido decodificou todos os 9900 macroblocos contidos nos 100 quadros P de maneira correta. A seguir, a mesma seqüência de 100 quadros foi codificada utilizando predição direta espacial segundo uma seqüência de quadros tipo I-P-B-B-P. O mesmo processo de validação foi aplicado, confirmando o funcionamento correto do preditor também para predição espacial. Para validar todos os modos de predição, bastou codificar o vídeo utilizando predição direta temporal e passar os dados capturados ao preditor desenvolvido. Neste caso, foi mantida a seqüência de quadros I-P-B-B-P. Como o software desenvolvido se comportou corretamente para todos os casos de teste, que abrangem todos os diferentes tipos de predição e quase macroblocos, este software foi considerado correto e pronto para servir de base para o desenvolvimento do hardware.

39 4 IMPLEMENTAÇÃO DO MVP EM HARDWARE Neste capítulo será apresentada a solução desenvolvida para o preditor de vetores de movimento em hardware. Será detalhada a escolha da arquitetura, passando pela descrição em VHDL, validação e chegando até a prototipação deste hardware. Na seção 4.1 será apresentada a arquitetura do preditor de vetores de movimento bem como os detalhes de desenvolvimento do VHDL associado. A seção 4.2 enfatiza a validação do módulo de hardware desenvolvido, mostrando a obtenção dos dados para simulação, o desenvolvimento do test bench e o método de simulação. A seção 4.3 aborda a prototipação desde a apresentação da plataforma de prototipação até os detalhes do método de prototipação. Os resultados do trabalho serão apresentados na seção Arquitetura do MVP e Descrição VHDL Essa seção irá apresentar a arquitetura e a descrição do módulo de hardware responsável pela predição dos vetores de movimento. A linguagem utilizada para a descrição da arquitetura foi o VHDL. O preditor de vetores foi desenvolvido para trabalhar em conjunto com o filtro para compensação de movimento apresentado em (AZEVEDO,2005) tendo como objetivo principal implementar um compensador de movimento completo para o padrão H.264/AVC segundo o perfil Main. Visando atingir desempenho para decodificar HDTV em resolução 1920x1080 pixels e amostragem 4:2:0, foi determinado que o módulo como um todo deveria trabalhar a uma freqüência de 100 MHz, fornecendo uma amostra processada por ciclo de relógio. Uma vez que existem 256 amostras de luminância e 128 amostras de crominância em um macrobloco no perfil Main, o preditor de vetores tem como restrição temporal a decodificação de um macrobloco em no máximo 384 ciclos de relógio, para não limitar a capacidade de processamento do filtro de amostras. Com base no software descrito no capítulo 3 e no conhecimento adquirido durante esse processo, passou-se para a descrição do hardware para a predição dos vetores de movimento. A exemplo do software, o hardware também foi desenvolvido de maneira

40 40 incremental, seguindo os mesmos três passos. Primeiramente foi desenvolvida a arquitetura para predição padrão para slices tipo P, seguido da descrição para predição direta espacial e, finalmente, o desenvolvimento da predição direta temporal. A predição de vetores para vídeos entrelaçados não foi abordada nesse trabalho. A modelagem do MVP em hardware foi realizada usando, por base, máquinas de estados finitos (FSM), uma vez que o algoritmo para predição de vetores de movimento se mostra extremamente seqüencial. A arquitetura foi descrita em VHDL utilizando uma descrição mista entre VHDL estrutural e comportamental. Essa abordagem foi tomada para permitir uma implementação mais eficaz das estruturas utilizadas em C++ e para propiciar ao sintetizador maior liberdade no reuso de componentes de hardware utilizados. A predição padrão para slices P, como descrito anteriormente, começa pela verificação da disponibilidade dos vizinhos selecionando seus vetores de movimento. É, então, obtida a mediana dos blocos vizinhos e esta é somada ao vetor de movimento diferencial. Essa soma dá origem aos MVs da partição ou sub-partição corrente. Para a realização deste cálculo, é necessário que todos macroblocos da linha superior sejam armazenados pela arquitetura. Foram então descritos dois buffers em memória, um para armazenar os vetores e outro para armazenar os índices de referência dos blocos vizinhos. Como essa implementação visa decodificar HDTV com 1920 pixels de largura, o buffer que armazena os vetores de movimento deve armazenar 480 vetores, para isso foi dimensionado em 512 palavras de 32 bits. O buffer de índices de referência deve armazenar 240 índices e, portanto, foi dimensionado em 60 palavras de 32 bits. A Figura 4.1 representa todos os blocos cujas informações devem ser armazenadas. Figura 4.1: Blocos necessários ao cálculo do MVP A arquitetura também conta com 10 conjuntos de registradores para o armazenamento dos vetores e índices vizinhos e internos do macrobloco corrente. A Figura 4.2 representa a disposição dos conjuntos de registradores que armazenam os vetores de movimento. As caixas com letras, na Figura 4.2, representam os vetores de movimento dos blocos vizinhos. As caixas com fundo em cinza representam os vetores de movimento do próprio macrobloco. Dois conjuntos com 4 registradores armazenam os vetores de movimento imediatamente à esquerda e acima do macrobloco corrente.

41 41 Esses vetores são referentes aos vizinhos A e B do macrobloco corrente, respectivamente (A e B na Figura 4.2). Dois registradores armazenam os vetores do bloco vizinho superior esquerdo e do bloco superior direito, referentes aos vizinhos D e C, respectivamente (D e C na Figura 4.2). Um conjunto de 16 registradores armazena os vetores de movimento dos blocos do macrobloco corrente (0 a 15 na Figura 4.2). Figura 4.2: Estrutura de registradores para armazenamento de vetores internos ao macrobloco (0 a 15) e vetores de macroblocos vizinhos (A, B, C e D) Os outros cinco conjuntos de registradores armazenam os índices de referência dos blocos vizinhos. Como cada partição de macrobloco (de até 8x8) compartilha as mesmas referências, são necessários menos registradores para armazenar os índices de referência dos blocos vizinhos, tal qual representado na Figura 4.3. Figura 4.3: Estrutura de registradores para armazenamento de índices de referência internos ao macrobloco (0 a 3) e índices de macroblocos vizinho (A, B, C e D) As operações sobre esses conjuntos de registradores foram descritas na forma de uma máquina de estados. Essa máquina de Mealy deve processar um macrobloco em, no máximo, 384 ciclos de relógio. Cada macrobloco pode ser dividido em até 16 blocos 4x4, que são processados de forma serial pela máquina de estados, para tanto, cada bloco deve ser processado em até 24 ciclos de relógio. A Figura 4.4 apresenta o diagrama da máquina de estados hierárquica do preditor de vetores de movimento. Cada macroestado, destacado com preenchimento na Figura 4.4, será desdobrado e seus estados serão detalhados ao longo desse capítulo.

42 Figura 4.4: Diagrama de estados da FSM do MVP 42

43 Preditor Com Suporte à Slices P Na figura 4.4, podemos ver a estrutura da máquina de estados hierárquica, onde os macroestados em branco são parte dessa primeira versão da arquitetura. Será realizada uma descrição de cada estado da arquitetura de forma detalhada, mostrando a função de cada estado no processo da predição de vetores. Essa primeira implementação da maquina de estados conta com 34 estados. Antes de iniciar o processamento, o estado RESET se encarrega de inicializar todas as variáveis de contexto importantes para o funcionamento correto do circuito. Depois, o estado WAITING fica em loop esperando a subida do sinal New_mbp, que dispara o processamento de um novo macrobloco. Nesse ponto, as informações de tipo de slice e de macrobloco devem estar disponíveis na entrada do módulo de hardware. O macroestado TEST é dividido em 2 estados como mostra a Figura 4.5. Com base nos tipos de slice e de macrobloco, no estado TEST_MB_TYPE, é testado se o macrobloco é tipo skip ou do tipo intra. O próximo estado, denominado TEST_MB_TYPE_1, faz a leitura dos tipos das partições quando necessário. Figura 4.5: Diagrama de estados do macroestado TESTE O macroestado seguinte, CONTROL_FOR, gerencia o laço de partições de macrobloco. O número de partições é consultado em uma tabelas determinadas a partir das tabelas mostradas no capítulo 3. A seleção das linhas da tabela é feita através de multiplexadores controlados pelo tipo do macrobloco atual. Nesse estado também é realizada, quando necessária, a leitura dos índices de referência presentes no bitstream. Caso a condição de passagem por esse laço for satisfeita o estado seguinte é o estado CONTROL_SUB_FOR, caso contrário, a máquina vai para o estado MEMORY_REFRESH. No macroestado CONTROL_SUB_FOR, é realizado o controle do número de subpartições dentro de cada partição. Neste estado são determinadas as dimensões do blocos, para que se possa encontrar os vizinhos corretos. O número de sub-partições é obtido de maneira análoga ao realizado no estado CONTROL_FOR, porém, utilizando como seletor nos multiplexadores, os tipos das partições. As dimensões da sub-partição também são determinadas a partir de tabelas. Quando satisfeita a condição de passagem desse laço, a máquina vai para o macroestado STANDARD, senão volta para o estado CONTROL_FOR. Tanto o macroestado CONTROL_FOR como o macroestado CONTROL_SUB_FOR, são compostos por apenas um estado que leva o mesmo nome de seu macroestado. O macroestado STANDARD é dividido em 7 estados como mostra a Figura 4.6. De acordo com aposição do bloco que está sendo processado e com suas dimensões, o estado AVAIL determina a disponibilidade dos vizinhos A, B, C e D. No caso

44 44 específico do vizinho C, um refinamento do teste de disponibilidade é realizada no estado AVAIL_C determinando a disponibilidade desse vizinho para sub-partições internas ao macrobloco. Os estados seguintes efetuam a leitura dos índices de referência e dos vetores de movimento dos blocos vizinhos. Como é preciso selecionar de qual conjunto de registradores vêm essas informações, um estado é utilizado para selecionar os valores de controle dos multiplexadores e outro para ler o valor dos registradores selecionados. Para ler os valores referentes ao vizinho A, o estado MV_REF_LOAD_A atribui o valor correto aos seletores dos multiplexadores e, apenas no estado seguinte, MV_REF_READ_A_LOAD_B, é feita a leitura dos dados. Esse estado, por sua vez, além da leitura dos dados para o vizinho A, também seta o seletor do multiplexador para os valores do vizinho B. Dessa maneira, como mostra a Figura 4.6, se sucedem os estados MV_REF_READ_B_LOAD_C, MV_REF_READ_C_LOAD_D e MV_REF_READ_D, até que os índices de referência e vetores de movimento dos blocos vizinhos sejam lidos. Figura 4.6: Diagrama de estados do macroestado STANDARD O macroestado SET_VECTORS é formado por 4 estados apresentados pela Figura 4.7. Como as informações dos blocos vizinhos são lidas mesmo que estes estejam marcados como não-disponíveis, o estado seguinte MV_REF_MOVE, mostrado na Figura 4.7, atribui o valor zero aos vetores e o valor -1 aos índices de referência do blocos não-disponíveis. Caso C não esteja disponível, este assume os valores do vizinho D. Nos estados seguintes é realizada a seleção do PMV. O PMV pode ser obtido através da mediana ou da cópia dos vetores de um dos três vizinhos. Quando apenas um dos vizinhos possui o mesmo índice de referência do bloco atual, o vetor de movimento desse bloco é selecionado como PMV. No estado REF_FRAME_SET_UNIQUE é testado se esse tipo de seleção deve ser realizada. No estado seguinte, REF_FRAME_SET, são testadas as dimensões do bloco corrente, a fim de saber se não é gerada a exceção descrita na seção Nesse caso, a forma de seleção do PMV é modificada. Neste estado é determinado o valor das flags zeromotionleft e zeromotionabove, que são ativadas quando os vizinhos A ou B, respectivamente, possuem vetores de movimento e índices de referência iguais a zero. Em paralelo, ainda no estado REF_FRAME_SET, é calculada a mediana dos vetores de

45 45 movimento dos blocos vizinhos, que será ou não utilizada no próximo estado, dependendo do modo de seleção do PMV. Em CALC_MV, a partir dos teste realizados nos estados anteriores, é feita a seleção do PMV. Para isso são avaliadas as flags zeromotionleft e zeromotionabove além do modo de seleção escolhido para o PMV. Neste estado também é calculada a posição da próxima partição a ser processada. Figura 4.7: Diagrama de estados do macroestado SET_VECTORS Basta então, somar o vetor de movimento diferencial ao PMV (se necessário) e salvar os resultados nos registradores corretos. É no macroestado SAVE_MV que isso ocorre, esse macroestado é composto por um único estado. Multiplexadores selecionam em quais registradores devem ser escritos os vetores de movimento. Cada multiplexador seleciona um conjunto de 4 bits. Cada bit na horizontal está associado a uma coluna, enquanto que cada bit na vertical está associado a uma linha. Um E lógico entre cada par de sinais horizontais e verticais liga a habilitação de escrita num registrador. A Figura 4.8 ilustra o mecanismo de habilitação de escrita. Cada intercessão entre as linhas tracejadas representa um E lógico que habilita o registrador. Figura 4.8: Estrutura de habilitação de escrita nos registradores Calculados os vetores de movimento e devidamente salvos nos registradores, a máquina de estados volta para o laço de sub-partições. Caso todas sub-partições já tenham sido processadas, a maquina de estados vai para o laço de partições. Assim que todas as partições tenham sido processadas, a máquina de estados sai desse laço e passa ao macroestado MEMORY_REFRESH (Figura 4.9), encarregado pela atualização dos registradores dos blocos vizinhos. Seis estados, de MEMORY_REFRESH_0 até MEMORY_REFRESH_5, fazem a atualização dos registrados dos blocos vizinhos, carregando nesses registradores os vetores de movimento e os índices de referência que serão os vizinhos do próximo macrobloco a ser processado. Também é função desses estados enviar os MVs e índices

46 46 de referência para a saída do módulo de predição de vetores. De forma serial, os 16 vetores de movimento e os 4 índices de referência são entregues serialmente. Para isso, são necessários 16 estados (como mostra a figura 4.9), portanto, além dos seis estados descritos acima, foram criados mais 10 estados adicionais. Esses estados adicionais têm apenas a função de repassar dados à saída e seus nomes são OUT_MV_6 até OUT_MV_15. Figura 4.9: Diagrama de estados do macroestado MEMORY_REFRESH Essa arquitetura tem uma latência mínima de 19 ciclos e máxima de 220 ciclos de relógio para que seja disponibilizado, na saída do preditor, o primeiro dado válido. Mais 16 ciclos são gastos para atualizar os registradores de blocos vizinhos e para enviar todos os vetores e índices de referência. No pior caso, são gastos 236 ciclos de relógio para realizar a predição e enviar os dados de um macrobloco, atingindo, assim, desempenho para satisfazer a exigência de proceder essa tarefa em no máximo 384 ciclos Preditor Com Suporte à Slices B e Predição Direta Espacial Como o objetivo desse trabalho é desenvolver um preditor de vetores para o perfil Main do padrão H.264/AVC, é necessário estender a primeira implementação para tratar slices tipo B e predição direta espacial. Em slices tipo B, existem 32 blocos a serem tratados, 16 da lista 0 e 16 da lista 1. Uma vez que não seria possível garantir o tratamento desses 32 blocos serialmente em 384 ciclos, optou-se para processar lista 0 e lista 1 paralelamente. Isso acarretou um aumento de hardware em relação ao preditor para slices P, já que todos os conjuntos de registradores tiveram de ser duplicados e os estados tiveram de ser estendidos para tratar duas listas em paralelo. Além disso, foi criado um fluxo de dados alternativo dentro do laço de predição de vetores para tratar a predição direta espacial. Para implementar esse novo fluxo, foram descritos novos estados que, na figura 4.4, estão representados por blocos grifados com linhas diagonais.

47 47 Caso um macrobloco ou partição de macrobloco utilize predição direta, o fluxo de dados é desviado para um pré-processamento particular para esse tipo de predição, representado pelo macroestado PRE_PROCESS_DIRECT_SPATIAL e detalhado na Figura Esse tratamento foi inserido antes dos laços principais, portanto cada macrobloco recebe esse tratamento no máximo uma única vez. Sua função é calcular os índices de referência da predição direta e determinar a flag directpredictonzeroflag. O estado DIRECT_PREDICTION_0 seta a disponibilidade dos vizinhos e seleciona os macroblocos que devem receber o tratamento para predição direta. Caso não seja necessário, o fluxo segue para o estado CONTROL_FOR, senão, é desviado para DIRECT_PREDICTION_1, onde são selecionados os índices de referência dos vizinhos. Nos estados DIRECT_PREDICTION_2 e DIRECT_PREDICTION_3, é calculado o índice de referência das duas listas. Como descrito na seção 3.1.1, esses índices são determinados encontrando o menor índice de referência positivo dos blocos vizinhos. Caso os índices de referência da lista 0 e da lista 1 sejam negativos, a flag directpredictonzeroflag é ativada e os índices de referência assumem o valor zero. O teste dos índices de referência é realizado no estado DIRECT_PREDICTION_4 enquanto a determinação do valor de directpredictonzeroflag é realizada em DIRECT_PREDICTION_5. Figura 4.10: Diagrama de estados do macroestado PRE_PROCESS_DIRECT_SPATIAL Acabado o pré-processamento para predição direta, o macrobloco é sujeito aos laços de partição. Macroblocos diretos são divididos em 4 partições e estas, por sua vez, são subdivididas em 4 sub-partições 4x4. Em macroblocos não diretos com partições diretas, estas partições diretas são divididas em 4 sub-partições 4x4. As partições que forem diretas utilizam os índices de referência calculados pelo pré-processamento para predição direta. O tratamento da predição direta espacial não se resume a um pré-processamento. Foi, também, inserido um novo caminho de dados dentro do laço de sub-partição,

48 48 responsável pela busca e análise dos vetores de movimento co-localizados, dos quais são derivados os vetores do bloco corrente. Esse caminho de dados é representado pelo macroestado SPATIAL composto por 4 estados apresentados na Figura As informações de vetores e referencias do quadro co-localizado foram armazenadas em memória. Como o volume desses dados é muito grande para serem armazenados na memória interna do FPGA, optou-se por armazenar em memória externa sendo assim dependente do mecanismo de acesso à memória fornecido pela Xilinx (XILINX,2006c). No estado AVAIL_DIRECT é realizado o teste de disponibilidade dos vizinhos e o cálculo da posição do bloco co-localizado a ser lido. Em READ_DIRECT é realizada a leitura dos vetores de movimento e índices de referência do bloco co-localizado, tanto para lista 0 como para lista 1. O estado seguinte, como mostrado na Figura 4.11, COLZEROFLAG_SET, determina o valor da flag colzeroflag, enquanto o estado VECZEROFLAG_SET determina o valor da flag VecZeroFlag. Os testes necessários para determinar essas variáveis são apresentados na seção Figura 4.11: Diagrama de estados do macroestado SPATIAL Feitas as modificações para suporte da predição direta espacial, o preditor passou a apresentar uma latência mínima de 17 ciclos, enquanto a latência máxima passou a ser de 226 ciclos. Somando-se os 16 ciclos finais para envio de resultados, essa arquitetura gasta, no máximo, 242 ciclos para um macrobloco, mantendo-se dentro dos 384 ciclos disponíveis para esse processo Preditor Com Suporte à Slices B e Predição Direta Espacial e Temporal Tomando por base a arquitetura da predição direta espacial, o desenvolvimento de uma arquitetura que suportasse também a predição direta temporal, passou pela inserção de um novo caminho de dados dentro dos laços principais, além de um modulo para o calculo do fator de escala. Foram inseridos seis estados adicionais para o tratamento da predição direta temporal. Esses estados são representados na Figura 4.4 pelo macroestado TEMPORAL (grifado com linhas verticais) e apresentados na Figura 4.12.

49 49 Figura 4.12: Diagrama de estados do macroestado TEMPORAL O estado TEMPORAL_0 se encarrega de calcular a posição do bloco co-localizado a ser lido pelo estado seguinte, o estado TEMPORAL_1. Como o fator de escala, DistScaleFactor, é calculado com base na distância dos quadros de referência e do quadro atual e cada partição pode referenciar quadros diferentes, esse fator deve ser calculado apenas uma vez a cada partição. Ou seja, não é necessário calcular o fator de escala para cada sub-partição. Como esse cálculo está dentro do laço de sub-partição, é realizado um teste para saber esse calculo já foi realizado antes, evitando a repetição do mesmo. É no estado TEMPORAL_2 que esse teste é feito. Quando é necessário calcular o fator de escala, o fluxo de dados segue para o estado TEMPORAL_3, senão, é desviado para o estado TEMPORAL_5. Também no estado TEMPORAL_2 é selecionado o índice de referência do bloco co-localizado. Esse índice é enviado ao gerenciador de listas para que este, por sua vez, devolva o índice de referência re-mapeado, além dos valores de POC para os quadros de referência e o quadro atual. Esses valores são necessários para a obtenção do fator de escala. Foi desenvolvida uma arquitetura para realizar o cálculo do fator de escala. Essa arquitetura será detalhada nos próximos parágrafos. O estado TEMPORAL_3 tem a função de disparar o cálculo, enquanto o estado TEMPORAL_4 entra em loop esperando que o fator de escala tenha sido determinado. O último estado inserido para processamento da predição direta temporal, o estado TEMPORAL_5, efetua o cálculo dos vetores de movimento. Vetores da lista 0 são calculados através da soma da constante 128 ao produto entre fator de escala e vetores co-localizados. Vetores da lista 1 são encontrados subtraindo os vetores co-localizados dos vetores da lista 0. Como citado acima, foi criada uma arquitetura especificamente para calcular o fator de escala utilizado na predição direta temporal. Essa arquitetura, apresentada na Figura 4.13, foi implementada em um pipeline de 3 estágios. O primeiro estágio é composto por dois subtratores de 18 bits, dois operadores de clip )utilizados para manter as saídas dos subtratores no intervalo [0, 255]), e um somador que adiciona a constante ao resultado de uma das subtrações. No segundo estagio existe um divisor de 16 bits. O último estagio conta com um multiplicador de 18 bits, um somador com a constante 32, um deslocador (shifter) e um operador de clip.

50 50 Figura 4.13: Caminho de dados para o cálculo do fator de escala A inserção da predição direta temporal concluiu a arquitetura proposta do preditor de vetores de movimento, essa arquitetura é capaz de tratar tanto a predição padrão quanto os dois tipos de predição direta. Essa arquitetura tem latência mínima de 17 ciclos e uma latência máxima de 226 ciclos. Somando-se os 16 ciclos finais para envio de resultados, a arquitetura completa gasta, no máximo 242, ciclos para processar um macrobloco, mantendo-se dentro dos 384 ciclos disponíveis para esse processo. O preditor de vetores para o perfil Main, em sua versão final, conta com 28 sinais de entrada e 23 sinais de saída. A tabela 4.1 mostra quais são os sinais de entrada, sua largura de bits e uma breve descrição do que representam.

51 51 Tabela 4.1: Sinais de Entrada do MVP Sinal Largura Função de bits clk 1 Relógio rst 1 Reset New_mbp 1 Dispara o processamento do preditor Max_X_L0, Max_Y_L0 9 Dimenções do slices Image_Type_L0 3 Tipo do slice mb_type_in_l0 6 Tipo do macrobloco sub_mb_type_in_0, 5 Tipo dos sub-macroblocos ou sub_mb_type_in_1, partições sub_mb_type_in_2, sub_mb_type_in_3 ref_input_l0, ref_input_l1 8 Índices de referência presentes no bitstream 1 Indica a disponibilidade de índices de referência na entrada Ref_Frame_Flag_L0, Ref_Frame_Flag_L1 mvd_x_l0, mvd_y_l0 16 Vetores de movimento diferenciais lista 0 mvd_x_l1, mvd_y_l1 16 Vetores de movimento diferenciais lista 1 direct_spatial_mv_pred_flag 1 Tipo da predição direta direct_8x8_inference_flag 1 Tipo de inferência mapped_idx 8 Índice de referência re-mapeado (para direta temporal) CurrPOC_In 17 POC do quadro atual POC0_In, POC1_In 17 POC do quadro de referência lista 0 e lista 1 MEM_MV_COLOCATED_OUT_L0, MEM_MV_COLOCATED_OUT_L1 32 Vetores de movimento lidos da memória co-localizada lista 0 e lista 1 MEM_REF_COLOCATED_OUT 16 Índices de referência lidos da memória co-localizada Os sinais de saída do preditor estão listados abaixo na tabela 4.2.

52 52 Tabela 4.2: Sinais de Entrada do MVP Sinal Largura Função de bits mb_ready_l0 1 Macrobloco predito, vetores disponíveis L0_used, L1_used 1 Utilização das listas. Indica se é predição lista 0, lista 1 ou bipredição type_read 1 Tipos de MB e sub-mb lidos mv_read_l0, mv_read_l1 1 Vetores de movimento diferenciais lidos Ref_Frame_Read_L0, 1 Índices de referência lidos Ref_Frame_Read_L1 MB_Block_X, MB_Block_Y 9 Posição do MB processado Temporal_ref_idx 8 Índice de referência a ser remapeado pelo gerenciador de listas Ref_L0, Ref_L1 8 Índices de referência mv_x_l0, mv_y_l0 16 Vetores de movimento lista 0 mv_x_l1, mv_y_l1 16 Vetores de movimento lista 1 WE_COLOCATED 1 Habilitação de escrita na memória co-localizada MEM_COLOCATED_ADDR_IN 18 Endereço de escrita na memória colocalizada MEM_COLOCATED_ADDR_OUT 18 Endereço de leitura na memória colocalizada MEM_MV_COLOCATED_IN_L0, MEM_MV_COLOCATED_IN_L1 32 Vetores de movimento a serem escritos na memória co-localizada MEM_REF_COLOCATED_IN 16 Índices de referência a serem escritos na memória co-localizada 4.2 Validação Esta seção descreve o método de validação utilizado para verificar o correto funcionamento da arquitetura proposta englobando a obtenção dos casos de teste, a simulação, a escrita do test bench e a simulação do VHDL descrito. Para verificar o funcionamento adequado da arquitetura descrita em VHDL, foi desenvolvida uma bateria de testes para validação desta descrição. Como uma validação formal se faz completamente inviável, partiu-se para a abordagem de validação através de simulações exaustivas. Para esta abordagem de validação, é necessária a existência de uma grande quantidade e variedade de casos de teste, casos que devem apresentar dados de entrada e resultados comprovadamente corretos. A busca desses casos foi feita através do software de referência do padrão H.264/AVC (IMAGE,2006).As variáveis necessárias para os testes já haviam sido localizadas durante o passo de validação do software do preditor de vetores. Desta vez, os dados de entrada foram salvos em cinco arquivos de

53 53 texto distintos, sendo: um para tipos de macroblocos e partições, um para vetores de movimento da lista 0, um para vetores de movimento da lista 1, um para índices de referência da lista 0 e um para índices de referência da lista 1. Em um sexto arquivo foram salvos os resultados. Obtidos os casos de teste teve início a fase de simulação, onde utilizou-se o software ModelSim (MENTOR,2006b) da Mentor Graphics para inserir os dados obtidos na arquitetura desenvolvida. Mas antes de rodar a simulação, preferiu-se converter os dados de teste para valores em binário, já que essa é a forma com que os dados são tratados pela arquitetura. Durante a simulação, os resultados calculados pelo preditor de vetores foram salvos em outros arquivos de texto. Para utilizar os dados já capturados e convertidos em uma simulação no ModelSim, foi escrito um test bench. O test bench é um código escrito em VHDL que descreve um módulo que envolve a arquitetura a ser testada e é responsável pela inserção de estímulos de entrada e pela leitura dos estímulos de saída desta arquitetura. Na inserção dos estímulos, esse módulo se encarrega de ler os dados binários dos arquivos de texto, identificando qual tipo de bloco será tratado e repassando para o preditor de vetores as informações de controle, vetores diferenciais e índices de referência necessários. Além de inserir os estímulos de entrada à arquitetura testada, o test bench foi escrito para observar os sinais de saída e identificar quando o sinal de validade estiver ativo. Este sinal de validade, nomeado como mb_ready, é ativo em nível lógico 1 (um) e indica a existência de vetores já processados e prontos para serem lidos. Os vetores e referências processadas são, então, salvas em arquivos de texto acompanhadas de um contador de macroblocos. Apenas depois desses processos de busca, conversão de dados e descrição do test bench pôde-se executar as simulações que validariam o compensador de movimento. Para esta simulação, como já citado, foi escolhido o software ModelSim desenvolvido pela empresa Mentor Graphics em sua versão ModelSim SE 6.0b (MENTOR,2006b). Esta ferramenta oferece grande facilidade em detecção de problemas no módulo testado, uma vez que permite a visualização do comportamento de todos os sinais internos à arquitetura através de formas de onda. Além disso, utilizando ModelSim pode-se fazer simulações não apenas comportamentais, mas também simulações da arquitetura já mapeada em diversas famílias de FPGA. Neste caso, o FPGA utilizado pra prototipação e simulação foi da família Xilinx Virtex-II Pro (XILINX,2006b). Durante as simulações foram detectados alguns pequenos erros de codificação em VHDL. A localização desses erros exigiu um esforço considerável e foi realizada através da observação do comportamento e dos valores assumidos pelos sinais internos da arquitetura. Depois de eliminar os bugs encontrados, pôde-se rodar as simulações exaustivas, capazes de comprovar com grande confiabilidade o funcionamento do módulo descrito. A seqüência de vídeo utilizada foi, novamente, Foreman.yuv, na resolução QCIF de 176x144. Nessa definição, existem 99 macroblocos em cada slice, dispostos em 9 linhas de 11 macroblocos.

54 54 As simulações foram primeiramente aplicadas para o vídeo citado codificado apenas com slices do tipo P, além de um slice tipo I que deve ser o primeiro frame obrigatoriamente. Assim foram obtidos os resultados para validar o processamento apenas de slices tipo P. Uma vez terminada a simulação para os blocos P, passou-se para a simulação da arquitetura com o mesmo vídeo, mas desta vez codificado com slices tipo P e slices tipo B intercalados entre si, de acordo com a seqüência I-P-B-B-P. Nessa segunda bateria de simulação, os slices B foram codificados utilizando predição direta espacial. A seguir, os slices B foram codificados com predição direta temporal e simulados. Completada essa etapa, foram obtidos dados para comprovar completamente o correto funcionamento do preditor de vetores em simulações de caráter comportamental. Os dados obtidos por meio de simulação foram considerados corretos após comparação com os dados gerados pelo software de referência. Essa comparação foi feita através de um programa descrito em C++. Esse processo de simulações aplicado em nível comportamental também foi aplicado para a arquitetura em fase de pós place and route, repetindo os resultados já encontrados na primeira fase de validação. 4.3 Prototipação Esta seção tem o objetivo de apresentar a plataforma e o método de prototipação do preditor de vetores de movimento, cuja descrição e validação foram detalhadas nas seções anteriores. A plataforma de prototipação consiste do software EDK/ISE (XILINX,2006) da Xilinx e da placa de desenvolvimento XUP Virtex-II Pro (XUP,2006) da produzida pela Digilent Inc. (DESIGN RESOURCES FOR DIGITAL ENGINEERS, 2005). O software de desenvolvimento é responsável pelo fluxo de síntese e programação da placa de desenvolvimento. O mesmo conta com uma biblioteca de softcores que implementam o controle dos dispositivos presentes na placa e estruturas de comunicação dentro do FPGA, como barramentos OPB e PLB. A placa de desenvolvimento XUP Virtex-II Pro conta com o dispositivo FPGA Virtex-II Pro XC2VP30-7 (XILINX,2006b). Esse dispositivo possui células lógicas, 136 multiplicadores de 18 bits, 2.448Kb de memória interna espalhados em 153 blocos de RAM e dois processadores PowerPC s 405. A placa possui um slot DIMM (168 pinos, para memórias com larguras de dados de 64 bits) e aceita memórias do tipo DDR DRAM de até 1GB de capacidade. Está instalado na placa um módulo de memória DDR DRAM de 512 MB PC2100 (relógio de 133MHz). Estão presentes na placa de desenvolvimento, entre outras, as interfaces de conexão: 10/100 Ethernet; USB2 para interface JTAG; vídeo XSGA com conversor D/A triplo de 8 bits por canal e capacidade para 180MSps; codificador de áudio compatível com AC97; interface serial ATA (SATA); duas interfaces PS/2 e uma interface RS-232. Além dessas interfaces, conectores de expansão de uso geral também se encontram disponíveis. A Figura 4.14 apresenta uma foto da placa de prototipação utilizada. A placa utilizada é a da direita na foto. A esquerda estão duas placas de extensão que não foram

55 55 utilizdas nesta prototipação. A placa superior é uma placa de captura de vídeo, enquanto a inferior é uma placa de extensão de entrada e saídas. Figura 4.14: Plataforma de prototipação Para os procedimentos de prototipação foram de fato utilizadas, além do dispositivo FPGA, a memória RAM externa e as interfaces de vídeo e RS-232. Foi utilizado também, um dos dois processadores PowerPC disponíveis no dispositivo FPGA. Para a prototipação do preditor de vetores de movimento, o mesmo foi mapeado para a área reconfigurável do FPGA. Suas entradas e saídas foram conectadas a um processador PowerPC, presente do dispositivo, por meio de um barramento OPB. Um programa rodando no PowerPC fornecia as entradas e lia as saídas do bloco mapeado. O programa também gerenciava a comunicação com o ambiente, lendo e escrevendo dados através da porta serial e tratando os dados processados para serem exibidos no monitor conectado à placa de desenvolvimento. Foi criado um projeto no ambiente de desenvolvimento EDK/ISE da Xilinx. O projeto, utilizando o arquivo de descrição da placa de desenvolvimento, utilizou os controladores da porta RS-232, da porta de vídeo, da memória RAM e de um controlador do barramento OPB. Dos recursos disponíveis no dispositivo FPGA, o projeto utilizou, ainda, 128KB de memória interna para armazenamento do código do programa e 64KB para armazenamento de seus dados. Por fim, o bloco do preditor de vetores foi adicionado aos recursos utilizados e conectado, como escravo, ao barramento OPB implementado. O bloco do preditor de vetores foi instanciado numa descrição VHDL do projeto, a qual define os componentes a serem mapeados na área reconfigurável do FPGA. Nessa descrição 9 registradores de 32 bits foram instanciados e mapeados como posição de

56 56 memória de dados acessíveis pelo PowerPC. As portas do preditor foram conectadas a esses registradores por meio de uma máquina de estados, que controla a escrita e a leitura dos registradores através do barramento OPB. As portas de relógio e de inicialização do sistema também foram conectadas aos registradores. Dessa forma, o relógio e a inicialização do sistema puderam ser controlados pelo programa desenvolvido, dando maior controlabilidade à plataforma de prototipação. Com essa estratégia, foi possível acompanhar, ciclo a ciclo, as saídas do preditor, fundamental para a análise dos problemas apresentados durante o processo de prototipação. Essa abordagem, todavia, não permite uma validação da freqüência máxima de relógio efetivamente alcançada pelo bloco mapeado no dispositivo real. Para o controle dos sinais a serem escritos no preditor de vetores, bem como a leitura dos sinais de saída, foi desenvolvido um programa em C para rodar no PowerPC. O programa está configurado para processar um quadro QCIF a cada iteração. Esse programa gerencia a comunicação com um computador Host conectado à placa através da interface RS-232. Primeiro o programa lê os dados da porta serial e os armazena na memória externa da placa. Esses dados são enviados ao módulo MVP no FPGA que realiza o processamento. Os resultados gerados pelo MVP são lidos pelo PowerPC e enviados ao computador Host por meio da RS-232. Os dados de entrada, usados na validação, são enviados para a placa de desenvolvimento via hyperterminal, conectado por um cabo serial na COM1. São enviados, de forma conjunta, os vetores diferenciais, os índices de referência e os tipos dos macroblocos e partições. Esses dados são armazenados em vetores de inteiros na memória interna do PowerPC. São armazenados dados de entrada referentes a um slice inteiro, para tanto, foram utilizados dois vetores para armazenar vetores da lista 0 e da lista 1, dois vetores para armazenamento dos índices de referência, além de um vetor para armazenar os tipos dos macroblocos e das partições. Para o processamento, o programa simula o comportamento de um test bench de hardware. Essa parte do programa foi descrita como um loop, onde cada iteração representava um ciclo de relógio. Em cada iteração do loop, escrevem-se as entradas nos registradores, lêem-se os registradores para capturar as saídas daquele ciclo e se varia o valor do registrador ligado ao sinal de relógio do preditor de vetores. O primeiro passo é atribuir às entradas do preditor de vetores os valores dos sinais de contexto e ativar o sinal que dispara o processamento, new_mbp. Os sinais que devem estar corretamente definidos antes de disparar o processamento são tipo de slice, tipo de macrobloco, tipo de sub-macrobloco, e tipo de predição direta. Depois de disparar a predição de um macrobloco, são testados os sinais de saída do preditor, esperando a solicitação de vetores de movimento diferencias ou índices de referência. O sinal que indica a existência de vetores calculados na saída também é continuamente avaliado. Quando existem vetores disponíveis, esses são lidos e armazenados em vetores próprios para esse fim. A última etapa é o envio dos resultados do processamento, vetores de movimento e índices de referência, para o Hyperterminal, através da interface RS-232. Esses dados podem, então, ser analisados visualmente ou mesmo por softwares de comparação. A Figura 4.15 mostra a forma como os dados são enviados ao Hyperterminal.

57 57 Figura 4.15: Terminal de comunicação com RS-232 Este procedimento de prototipação foi repetido para o preditor contendo as extensões para predição direta espacial e posteriormente para o preditor completo, com predição direta espacial e temporal. O preditor com suporte apenas para slices P não chegou a ser prototipado. 4.4 Resultados Esta seção apresentará os resultados obtidos no desenvolvimento do preditor de vetores de movimento em hardware. Serão analisados os resultados de síntese para o preditor de vetores em cada um dos três estágios de desenvolvimento. Também será analisado o desempenho médio do módulo, obtido por meio de simulação. Os dados de síntese apresentados nessa seção foram gerados pelo software ISE da Xilinx. Os dispositivos alvo dessa síntese foram FPGAs VP-30 da família Virtex-II PRO da Xilinx com speed grade -7 (xc2vp30-7ff896). Esses FPGAs foram escolhidos por serem parte da plataforma de prototipação disponível. A cada passo de evolução do desenvolvimento, o módulo foi sintetizado e esses dados foram armazenados para a análise o incremento de hardware conseqüente de cada modificação ou, mesmo, a variação no desempenho após cada modificação. Para os dois estágios em que a arquitetura foi prototipada, tem-se também, dados de síntese considerando todos os módulos adicionais, como, por exemplo, o gerenciador de barramentos e o controlador da inteface RS-232. Uma vez finalizada a arquitetura para predição de vetores para slices P, foi obtida, segundo a ferramenta de síntese, uma freqüência máxima de operação de 149,5 MHz. Os dados de ocupação de recursos do dispositivo estão apresentados na Tabela 4.3.