ABSTRACT
Neste trabalho será apresentada a metodologia utilizada para validar a arquitetura de um compensador de movimentos para o novo padrão de codificação de vídeo H.264/AVC. Esta arquitetura foi projetada para processar amostras de luminância e crominância a uma taxa capaz de satisfazer os requisitos de um decodificador H.264 Level 4 em perfil Main. Para a validação foram utilizados dados de vídeos reais extraídos diretamente do software de referência do padrão H.264. Estes dados que após serem pré-processados por programas desenvolvidos nas linguagens C/C++, foram inseridos na arquitetura através do programa de simulação ModelSim da Mentor Graphics. Os dados resultantes das simulações sofreram, então, novo processamento e foram comparados aos resultados extraídos do software de referência garantindo, assim, a correção do processamento realizado pela arquitetura desenvolvida.
1. INTRODUÇÃO
O novo padrão de codificação de vídeo H.264 também denominado MPEG-4 parte 10 – AVC (Advanced Video Coding), desenvolvido em cooperação pela ITU-T Video Coding Experts Group (VCEG) e pelo ISO/IEC Moving Picture Experts Group (MPEG), traz um grande crescimento na capacidade de compressão de vídeos se comparando a outros padrões como MPEG-1, MPEG-2 e MPEG-4. Esse aumento na capacidade de compressão se dá através de um grande aumento da complexidade computacional envolvida no processo de compressão e
descompressão. Para tal aumento de complexidade, tornou-se inviável o processamento de vídeos H.264 de alta definição (HDTV) em tempo real através de software, sendo este mais um forte motivo para o desenvolvimento de hardware para o tratamento desse padrão.
Este artigo descreve o processo de testes e validação de uma arquitetura dedicada para compensação de movimento (MC) seguindo o padrão H.264/AVC.
O método de validação aplicado se baseia na comparação de resultados obtidos por simulações da arquitetura aos resultados gerados pelo software de referência do padrão H.264.
Funções adicionais foram inseridas ao software de referência com o intuito de obter os dados necessários às entradas da arquitetura. Utilizando dados de vídeos reais foram executadas simulações do compensador de movimento, todos os resultados foram guardados para posterior comparação. Após uma comparação realizada por software concluiu-se que os resultados gerados pela arquitetura do MC estavam de acordo com os resultados de referência.
Este trabalho está inserido no projeto de um codec H.264 em hardware para TV de alta definição (HDTV – 1920x1080). Este codec será utilizado nas investigações acadêmicas que servirão de subsidio para a construção do Sistema Brasileiro de Televisão Digital (SBTVD).
O artigo trará na seção 2, uma breve apresentação das características gerais e dos principais blocos contidos no padrão H.264. Na seção 3, será analisado em maiores detalhes a ferramenta da compensação de movimento. A seção 4 apresentará o projeto da arquitetura do compensador de movimento enquanto sua validação será detalhada na seção 5. A conclusões deste projeto estão apresentadas na seção 6.
VALIDAÇÃO DE UMA ARQUITETURA PARA
COMPENSAÇÃO DE MOVIMENTO SEGUNDO O
PADRÃO H.264/AVC
Bruno Zatt, Arnaldo Azevedo, Luciano Agostini, Sergio Bampi
Instituto de Informática, Universidade Federal do Rio Grande do Sul (UFRGS), Porto Alegre, Brazil
2. H.264 / MPEG-4 AVC
O padrão H.264 foi definido pela JVT (Joint Video Team), união dos grupos VCEG (Video Coding Experts Group) e MPEG (Moving Picture Experts Group), tendo como base o projeto H.26L da ITU-T. Seu primeiro draft foi aprovado em outubro de 2003 (ITU-T, 2003) e sofreu o acréscimo de novas funções em julho de 2004 através da extensão Fidelity Range Extensions (FRExt) (ITU-T, 2004; ITU-T, 2005b).
Foram definidos quatro perfis para o padrão H.264 que englobam diferentes ferramentas de codificação, permitindo, assim, a escolha do perfil mais adequado a cada aplicação. Estes perfis são Baseline, Main, Extended e High e estão apresentados na figura 1.
Figura 1. Perfis do Padrão H.264
O padrão H.264 trabalha sobre macroblocos (MB) de 16x16 amostras considerando imagens no espaço de cores YCbCr. Estes macroblocos são classificados de acordo com o modo de codificação ao qual são submetidos, podendo ser do tipo I (Intra), P (Predictive) e B (Bi-predictive). Os slices, estruturas que agrupam os macroblocos, também são classificados podendo ser dos tipos I (Intra), P (Predictive), B (Bi-predictive), SP (Switching P) ou SI (Switching I). Slices do tipo I apresentam apenas macroblocos do tipo I, slices P podem conter macroblocos I e macroblocos P enquanto slices B contém tanto macroblocos I como macroblocos B. Os slices SI (apenas macroblocos I) e SP (macroblocos I e P) existem apenas no perfil Extended e são responsáveis por funcionalidades de troca entre diferentes streams de vídeo[8].
O H.264 pode processar os macroblocos de 16x16 em blocos distintos de diversos tamanhos (16x16, 8x16, 16x8, 8x8, 4x8, 8x4 e 4x4 amostras).
Dentre as funcionalidades básicas de um codificador H.264 estão as funções responsáveis pelas transformadas inversas, quantização inversa, decodificação de entropia, predição intraframe, predição interframe (MC) e filtro de deblocagem, como mostrado na figura 2. Estas funções serão analisadas individualmente com mais detalhes.
Figura 2. Decodificador H.264
Decodificação de Entropia: Os algoritmos para decodificação de entropia utilizados pelo H.264 são o VLC (Variable Lenght Coding), o CAVLC (Context Adaptative Variable Lenght Coding), o CABAC (Context Adaptative Binary Arithmetic Coding) e o Exp_Golomb. Considerando o perfil implementado pelo decodificador e o tipo dos dados a serem decodificados, é selecionado o método utilizado para a decodificação de entropia.
Transformadas Inversas: Para converter os dados do
domínio freqüência para o domínio espacial, o padrão pode utilizar uma aproximação inteira da IDCT-2D(transformada discreta do co-seno inversa) sobre blocos de 4x4 ou 8x8 (somente perfil High), além da transformada Hadamard inversa sobre blocos de 4x4 ou 2x2 amostras que foram processadas pela DCT. Os dados processados pelas transformadas inversas geram os resíduos que serão somados aos resultados da decodificação intra ou inter frame, e a escolha de qual transformada inversa será utilizada depende da transformada aplicada pelo codificador.
Quantização Inversa: A quantização inversa é realizada através de um quantizador inverso escalar. São definidos 52 diferentes valores para o passo de quantização que são definidos pelo parâmetro QP.
Predição Intraframe: Esse bloco é responsável por calcular o valor de um determinado bloco ou macrobloco através das informações de blocos vizinhos dentro de um mesmo slice. A predição intraframe opera no domínio espacial e conta com nove modos de predição para blocos de luminância 4x4 e quatro modos para blocos de luminância 16x16 além de quatro modos para blocos de crominância. Slices Redundantes CAVLC Grupo de Slices e ASO Slices P Slices I Slices B CABAC Predição ponderada Slices SP e SI Partição de dados Perfil Baseline Perfil Extended Perfil Main Transformada Adaptativa Quantização em Percepção Perfil High Decodificação INTRA MC Decodificaçã o de Entropia Quadro de Referência Quantizaçã o Inversa + Inversa T Quadro Atual
MC (Predição Interframe): O MC é responsável por calcular as amostras de um bloco a partir de blocos de frames vizinhos. A esse processo é dado o nome de compensação de movimento. Para esse processo o padrão adota interpolação com precisão de ¼ pixel, permite referencia a múltiplos quadros e permite múltiplos tamanho de bloco. Esse modo de predição será detalhado na seção 3.
Filtro de Deblocagem: É um filtro adaptativo ao contexto e tem o objetivo de suavizar as bordas entre os blocos. Para isso o é aplicado na vizinhança dos blocos, tanto vertical como horizontalmente, e pode assumir cinco diferentes forças de filtragem de acordo com as características dos blocos a serem filtrado.
3. COMPENSAÇÃO DE MOVIMENTO
A compensação de movimento é responsável por reconstruir macroblocos do frame atual a partir de frames vizinhos, chamados de frames de referência. O compensador de movimento consome mais da metade do tempo de processamento do decodificador [2] e está presente tanto no codificador como no decodificadorO frames de referência são gerenciados por duas listas, Lista 0 e Lista 1, para slices do tipo P apenas a Lista 0 é utilizada, mas para slices do tipo B pode-se utilizar apenas Lista 0, apenas Lista 1 ou ambas.
Conhecendo os frames de referência a serem utilizados, vetores de movimento indicam a localização das amostras desejadas Estas amostras são interpoladas com uma precisão de ¼ de pixel para luminância e 1/8 de pixel para crominância e então, são somadas aos blocos de resíduo vindos das transformadas para reconstruir o macrobloco desejado.
A figura 3 indica como é realizada a interpolação com precisão de 1/2 pixel em blocos de luminância. Neste caso é aplicado um filtro FIR de 6-taps. Os quadrados escuros da figura representam os pixeis originais da imagem, enquanto os quadrados tracejados simbolizam pixeis interpolados.
Figura 3. Interpolação de luminância 1/2 pixel
A figura 4 mostra como é feita a interpolação de 1/4 de pixel, para este caso é utilizada apenas uma média simples entre pixeis vizinho. Quadrados escuros são pixeis originais da imagem, quadrados tracejados são interpolações de 1/2 pixel e quadrados brancos são interpolados com precisão de 1/4 de pixel.
Figura 4. Interpolação de luminância 1/4 pixel Na figura 5 é demonstrada a interpolação de 1/8 pixel utilizada para blocos de crominância. Os quadrados A, B, C e D representam pixeis originais da imagem. A posição do quadrado calculado da figura 5 representa às coordenadas dX = 2 e dY = 3.
Figura 5. Interpolação de crominância 1/8 de pixel O bloco de compensação de movimento pode ser separado em dois módulos principais: o preditor de vetores e o processador de amostras. O preditor de vetores é responsável por calcular os vetores de movimento do bloco atual, utilizando dados do bitstream, além de informações contidas em blocos vizinhos, essa operação é realizada para explorar a alta correlação entre vetores de movimento de blocos vizinhos. O processador de amostras é responsável pela interpolação e pela predição ponderada. Nesta trabalho é abordada apenas a validação para o processador de amostras.
Para atingir maiores taxas de compressão, o padrão H.264 introduziu técnicas que não faziam parte de padrões anteriores devido a sua grande complexidade computacional. A compensação de movimento engloba a capacidade de referenciar múltiplos frames, a predição ponderada, a predição direta, macroblocos skip, múltiplos tamanhos de bloco e interpolação 1/4 pixel.
a c G b H i k h j m M s N d f G b H n q h j m M s N g e G b H r p h j m M s N j cc dd h m ee ff aa bb b s gg hh A B C D E F G H I J K L M N O P Q R S T
Múltiplas referencias: Em padrões anteriores era permitido referenciar apenas frames imediatos ao frame atual. No H.264 pode-se referenciar frames distantes tanto no passado como no futuro.
Os frames de referencia são gerenciados por duas listas, a Lista 0. Cada bloco 8x8 de um macrobloco tipo B pode referenciar até dois frames possibilitando que cada macrobloco referencie até 8 frames.
Predição ponderada: Essa ferramenta está incluída no perfil Main do padrão H.264 e é responsável por aplicar um fator multiplicativo e um deslocamento aditivo às amostras interpoladas. A predição ponderada é especialmente útil em cenas de “fade” (cenas onde a cena perde ou ganha intensidade de forma gradual).
Predição direta: Faz a inferência dos frames de referência bem como dos vetores de movimento do bloco em processamento quando esses dados não vêm explicitamente através do bitstream.
Esse tipo de predição utiliza como informação apenas as referencias e os vetores de blocos vizinhos. Quando utiliza-se a predição direta espacial são utilizados os blocos vizinhos dentro do mesmo frame, enquanto que ao usar a predição direta temporal usa-se as informações de blocos de frames vizinhos, um bloco do frame imediato a frente e um bloco de algum frame para traz (em ordem temporal).
Macroblocos skip: Bastante freqüentes em frames do
H.264, são macroblocos que não carregam informação de referencias, vetores ou resíduos consigo.
Múltiplos tamanhos de bloco: No H.264, cada macrobloco de luminância pode ter vários tamanhos: ter apenas uma partição de 16x16, ser dividido em duas partições 16x8, duas partições 8x16 ou ser dividido em quatro partições 8x8. Cada partição 8x8 ainda pode ser dividida em duas sub-partições 4x8, duas 8x4 ou quatro 4x4.
Interpolação 1/4 pixel: Os blocos geralmente não se movimentam apenas em posições inteiras da grade de pixeis. Portanto, para encontrar um melhor casamento entre blocos de frames vizinhos, o MC gera sub amostras em posições fracionárias da grade de pixeis através da interpolação com precisão de 1/4 de pixel.
4. ARQUITETURA
A arquitetura proposta em [1] foi desenvolvida para processar amostras de luminância e crominância a taxas suficientes para decodificar vídeos em HDTV no perfil Main. Seus aspectos mais gerias serão descritos de maneira resumida nesta seção, citando os principais blocos que compões o projeto e descrevendo rapidamente suas funcionalidades.
O projeto do processador de amostras conta com um caminho de dados para luminância e dois para crominância trabalhando em paralelo, além de um buffer de 384 posições, 256 para luma e 128 para croma. O diagrama de blocos do processador de amostras está apresentado na figura 6.
Figura 6. Arquitetura do Processador de Amostras O caminho de dados para luminância conta com um buffer de entrada, o interpolador com precisão de ¼ de pixel, um ponderador responsável pelo processo de predição ponderada, um buffer 4x4 e uma media para bi-predição e finalmente um operador de clip, essa arquitetura está apresentada pela figura 7. O caminho de dados para crominância é muito semelhante apenas trocando o interpolador e alterando o tamanho do buffer de 4x4 para 2x2 amostras.
O interpolador de luminância baseado em [12] utiliza filtros FIR 1-D de 6-taps (1,-5,20,20,-5,1), quatro verticais e nove horizontais, para gerar a interpolação de ½ pixel e quatro filtros bilineares para obter a interpolação de ¼ pixel. Este interpolador tem uma latência de nove ciclos e como entrada recebe nove amostras de luminância por ciclo gerando quatro amostras interpoladas a cada ciclo.
Figura 7. Caminho de Dados para Luminância Os interpoladores de crominância são iguais para as componentes de cor Cb e Cr. Cada interpolador é composto de um filtro bilinear com precisão de 1/8 de pixel. Sua entrada são 3 amostras por ciclo e sua saída 2 amostras por ciclo de relógio.
O ponderador responsável pela predição ponderada, aplica um fator multiplicativo e um deslocamento aditivo às amostras interpoladas. Este ponderador foi desenvolvido para trabalhar também com valores negativos.
Para limitar as amostras de saída a valores entre 0 e 255, aplica-se um clip que reduz o tamanho das amostras de 17 bits para apenas 8 bits utilizando dois multiplexadores e um comparador.
5. VALIDAÇÃO
Para comprovar 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. Então foram localizadas, no código do software de referência, as variáveis necessárias para os testes e inseridas funções para capturá-las em arquivos de texto.
Obtendo os casos de teste teve início a fase de simulação, onde utilizou-se o software ModelSim [4] da Mentor Graphics para inserir os dados obtidos na arquitetura desenvolvida. Mas antes de rodar as 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 compensador de movimento foram salvos em outros arquivos de texto.
De posse dos resultados gerados pelo software de referencia e dos resultados extraídos através da simulação da arquitetura, foram escritos outros pequenos programas capazes de fazer a comparação entre esses resultados.
Cada uma dessas etapas do processo de validação será descrita com mais nas próximas sub-seções do texto.
5.1. Localização dos casos de teste
Para obter os casos de teste necessários, primeiramente foi feito um estudo do software de referência do padrão H.264 com o objetivo de localizar onde se encontravam as variáveis necessárias e em que ponto deveriam ser capturadas. Para esse trabalho de busca foi utilizado a versão “JM 9.5” [3] do software de referência.
Descobriu-se que as funções relativas à predição do tipo inter frame no JM.95 estão bastante restritas ao arquivo “macroblock.c” do decodificador (ldecod). Foi possível, então, localizar todas as variáveis de controle, dados a serem processados e resultados obtidos, dentro do arquivo “macroblock.c”.
As variáveis de controle e de contexto capturadas foram “img->type”, que indica o tipo do frame, “mv_mode”, “pred_dir”, “direct_pdir”, “i4” e “j4” indicando a posição do bloco processado, os vetores referentes à Lista 0 (“vec1_x” e “vec1_y”) e os vetores referentes à Lista 1 (“vec2_x” e “vec2_y”) e o flag que indica o uso de predição direta espacial “img->direct_spatial_mv_pred_flag”. Estas variáveis indicam o
tipo de predição, qual lista de referência será utilizada e como deverá ser feita a interpolação.
Foram, também, armazenados dados relativos à predição ponderada como a variável “img->apply_weights” que diz quando a ponderação deve ser aplicada, os fatores multiplicativos “alpha_fw” e “alpha_bw” e os deslocamentos “offset0” e “offset1” referentes à Lista 0 e Lista 1, além do fator de arredondamento >wp_round_luma” e seu logaritmo na base dois “img->luma_log2_weight_denom”.
As variáveis de controle capturadas foram as mesmas tanto para luminância quanto para crominância, no entanto, o ponto no qual foram capturados são distintos. Dentro da função “decode_one_macroblock” existem dois laços de iteração principais, é dentro do laço responsável pelo cálculo dos componentes de luma que foram capturadas as variáveis de controle para luminância, do mesmo modo capturamos as variáveis de controle para croma dentro do laço responsável pelo cálculo de componentes de crominância.
Além das variáveis de controle são necessárias as matrizes com os dados de entrada bem como das matrizes com os resultados já processados. Para isso, foram criadas estruturas de dados (matrizes bi-dimensionais) para armazenar tais valores. Foram definidas duas matrizes de inteiros com 9x9 posições, “test_block” e “test_block_bw”, que armazenam dados de entrada vindos da Lista 0 e da Lista 1. Os resultados são armazenados em outra matriz bi-dimensional chamada “test_block_out”, com tamanho definido pelo tamanho do bloco a ser processado (“BLOCK_SIZE”).
Quando se trata de capturar dados de entrada para luminância, o ponto utilizado é imediatamente após a chamada da função “get_block” atualizando “test_block” ou “test_block_bw”, dependendo, dos parâmetros passados para “get_block”. Por sua vez, “test_block_out” deve ser atualizada junto aos testes feitos com a variável “img->apply_weights”. Isso tudo dentro do laço de luminância.
Para obter os dados corretos para croma, dentro do laço de crominância, deve-se atualizar os valores de “test_block” e “test_block_bw” após o cálculo das variáveis “if1”, ”jf1”, ”if0” e ”jf0”, enquanto “test_block_out” deve ser salvo junto aos testes com a variável “img->apply_weights”.
5.2. Obtenção dos casos de teste
A partir da localização dos pontos em que as variáveis deveriam ser capturadas, bastou inserir funções para salvá-las no arquivo de texto adequado.
Em um arquivo de entrada chamado de “INTER_IN.txt” foram salvas variáveis de controle e contexto, bem como os dados de luminância a serem processados de forma com que todas as variáveis e um
contador de blocos ficassem na mesma linha seguida de nove ou dezoito linhas de dados a serem processados. A necessidade de nove ou dezoito linhas de dados se explica pela existência de blocos do tipo P que utilizam uma matriz de 9x9 amostras enquanto blocos do tipo B podem utilizar duas matrizes 9x9.
Da mesma forma, foi procedido com as variáveis de crominância que foram salvas em um arquivo chamado “INTER_IN_C.txt” contendo variáveis de controle seguidas de uma ou duas matrizes de 4x4 amostras.
Dentre as variáveis de controle e contexto salvas, estão tipo do slice, tipo do macrobloco e do submacrobloco, os vetores de movimento para Lista 0 e Lista 1, os valores de deslocamento e fator multiplicativo para predição ponderada, além do contador de bloco. Estas informações devem preceder os valores a serem interpolados, pois através delas poderemos reconhecer o tipo de bloco a ser processado e inserir, na simulação, a quantidade adequada de amostras.
Quanto aos dados de saída, foram capturados no arquivo “INTER_OUT_ref.txt” para luminância e “INTER_OUT_C_ref.txt” para crominância. Os resultados da interpolação para luminância compõe uma matriz de 4x4 amostras que foi salva no arquivo de texto precedida pelo contador de bloco. Da mesma forma foram salvas as matrizes 2x2 com os resultados da interpolação dos valores de crominância.
5.3. Tratamento dos dados de simulação
Uma vez que os dados a serem inseridos na arquitetura devem estar em uma representação binária, foi necessária a criação de pequenos softwares capazes de realizar a conversão dos dados obtidos em representação decimal para sua representação correspondente em binário.
Com isso o arquivo de texto “INTER_IN.txt” renomeado para “INTER_IN_bin.txt” passou a conter uma linha com 142 bits seguida de nove ou dezoito linhas de 72 bits para cada bloco. Enquanto “INTER_IN_C_bin.txt” esta organizado em uma linha de 142 bits seguida de quatro ou oito linhas com 24 bits.
Os arquivos contendo os resultados da interpolação não foram convertidos para sua representação em binário, uma vez que não passaram pela simulação e apenas serão utilizados na fase de comparação entre os resultados.
5.4. Test bench
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 repassado para o processador de amostras com as informações de controle necessárias e variáveis, como as da predição ponderada. Então, dependendo do bloco sob processamento são repassadas, também, ao compensador de movimento uma ou duas matrizes de amostras para cada componente de cor (YCbCr).
Além de inserir os estímulos de entrada à arquitetura testada, o test bench foi escrito para observar sinais de saída e identificar quando o sinal de validade estiver ativo. Este sinal de validade nomeado como “Valid” é ativo em nível lógico 1 (um) e indica a existência de amostras já processadas e prontas para serem lidas. As amostras processadas são, então, salvas em arquivos de texto acompanhadas de um contador de blocos.
5.5. Simulação
Apenas depois desses processos de busca e conversão de dados e descrição do test bench pôde-se executar as simulação 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”[4]. 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 [5].
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 feita 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 modulo descrito.
Como referência para testes, utilizou-se o vídeo “Foreman.yuv” de resolução 176x144 pixeis e duração de 100 quadros.
Toda essa bateria de testes foi aplicada aos caminhos de dados de luminância e crominância de forma separada. Apenas depois foram feitas as simulações do processador de amostras como um todo.
As simulações foram primeiramente aplicadas para o vídeo citado codificado apenas com frames do tipo P, além de um frame tipo I que deve ser o primeiro frame obrigatoriamente, obtendo resultados para validar o processamento apenas de blocos 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 frames tipo P e frames tipo B intercalados entre si. Nesta segunda etapa obteve-se dados para comprovar completamente o funcionamento do processador de amostras em simulações de caráter comportamental.
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.
Os resultados processados pelas simulações do compensador de movimento foram armazenadas em dois arquivos de texto utilizando representação binária. Os resultados de luminância foram salvos no arquivo INTER_OUT.txt enquanto os resultados de crominância foram salvos em INTER_OUT_C.txt, com esses arquivos estão disponíveis dados suficientes para comparar com os resultados extraídos do “JM 9.5”.
5.6. Comparação dos resultados
De posse dos arquivos contendo os valores processados pelo compensador de movimento desenvolvido e dos arquivos com os resultados gerados pelo software de referência, foram escritos dois novos programas (um para luma e um para croma) em C/C++ capazes de comparar tais resultados.
A execução destes softwares de comparação mostraram que a arquitetura estava, de fato, de acordo com o perfil Main do padrão H.264.
A plataforma de validação desenvolvida permite que, facilmente se possa aplicar testes com diversos vídeos de diferentes definições, no entanto os mais de 150 mil blocos de luminância e 70 mil blocos de crominância processados de maneira correta a partir do vídeo Foreman.yuv dão uma grande confiabilidade no funcionamento do compensador de movimento.
6. CONCLUSÃO
Este trabalho descreve o método de teste e validação aplicados a uma arquitetura dedicada a compensação de movimento segundo o perfil Main do padrão H.264/AVC.
Foram apresentados, de forma superficial, algumas características do padrão H.264 e seus blocos funcionais mais relevantes. Também foi abordado, com maior detalhamento, o bloco da compensação de movimento. Apresentou-se aspectos gerais da arquitetura proposta em [1] responsável pelo processador de amostras da predição interframe (MC).
Neste artigo foram citados todos os dados necessários para viabilizar o processo de validação, assim como a localização de tais dados. Os passos do método de
validação também foram descritos individualmente de forma detalhada.
Com base nos testes realizados utilizando mais de 220 mil blocos extraídos de vídeos reais, foi possível constatar o correto funcionamento da arquitetura do compensador de movimento segundo o perfil Main do padrão H.264.
7. REFERÊNCIAS
[1] Azevedo, A.; et all. Motion Compensation Sample Processing for HDTV H.264/AVC Decoder. In: 23rd NORCHIP CONFERENCE. Oulu: IEEE, 2005. [2] Horowitz, M. et al, H.264/AVC Baseline Profile Decoder Complexity Analysis. IEEE Transactions on Circuits and Systems for Video Technology, [S.l.], v. 13, n. 7, p. 704-716, Jul. 2003.
[3] http://iphome.hhi.de/suehring/tml/
[4] http://www.model.com/
[5] http://www.xilinx.com/products/silicon_solutions/fpgas/ virtex/virtex_ii_pro_fpgas/index.htm
[6] J.M. Boyce. "Weighted prediction in the H.264/MPEG AVC video coding standard. Circuits and Systems, 2004. ISCAS '04. Proceedings of the 2004 International Symposium on. Volume 3, 23-26 May 2004 Page(s):III - 789-92 Vol.3
[7] JVT Editors (T. Wiegand, G. Sullivan, A. Luthra), Draft ITU-T Recommendation and final draft international standard of joint video specification (ITU-T Rec.H.264|ISO/IEC 14496-10 AVC), JVT-G050r1, Geneva, May 2003.
[8] Karczewicz, M.; Kurceren, R. The SP- and SI-frames design for H.264-AVC. IEEE Transactions on Circuits and Systems for Video Technology. [S.l.], v. 13, n. 7, p. 637-644, Jul. 2003.
[9] Lei Deng; Wen Gao; Ming-Zeng Hu; Zhen-Zhou Ji; “An Efficient VLSI Implementation for MC Interpolation of AVS Standard”. Advances in Multimedia Information Processing - PCM 2004: 5th Pacific Rim Conference on Multimedia, Tokyo, Japan, November 30 - December 3, 2004. Proceedings, Part III [10] Sheng-Zen Wang; Ting-An Lin; Tsu-Ming Liu; Chen-Yi Lee; "A New Motion Compensation Design for H.264/AVC Decoder". Circuits and Systems, 2005. ISCAS 2005. IEEE International Symposium on. 23-26 May 2005 Page(s):4558 - 4561
[11] T. Wiegand; G. Sullivan; G. G. J. Bjntegaard; A. Luthra;."Overview of the H.264/AVC video coding standard". Circuits and Systems for Video Technology, IEEE Transactions on. Volume 13, Issue 7, July 2003 Page(s):560 - 576
[12] Wen-Nung Lie; Han-Ching Yeh; Tom C.-I. Lin; Chien-Fa Chen; "Hardware-Efficient Computing Architecture for Motion Compensation Interpolation in H.264 Video Coding" Circuits and Systems, 2005. ISCAS 2005. IEEE International Symposium on. 23-26 May 2005 Page(s):2136 – 2139
[13] Wiegand, T.; Schwarz, H.; Joch, A.; Kossentini, F.; Sullivan, G.J.; "Rate-constrained coder control and comparison of video coding standards". Circuits and Systems for Video Technology, IEEE Transactions on. Volume 13, Issue 7, July 2003 Page(s):688 – 703
[14] Xiaosong Zhou; Eric Q. Li; Yen-Kuang Chen; “Implementation of H.264 Decoder on General-Purpose Processors with Media Instructions,” in SPIE Conf. on Image and Video Communications and Processing, Jan. 2003.
