Análise do desempenho do H.264 em arquiteturas multicore

Análise do desempenho do H.264 em arquiteturas multicore

1

UNIOESTE - Universidade Estadual do Oeste do Paraná Laboratório de Sistemas Computacionais (LSC)

Rua Universitária, 2069. Jardim Universitário. Caixa Postal 711 - CEP 85819-110 Cascavel, PR

alexandre.giron@unioeste.br Marcio.oyamada@unioeste.br

Resumo. Atualmente, nota-se o aumento de arquiteturas multicores no mercado de processadores de propósito geral e embarcados. No entanto, para um uso eficiente de tais arquiteturas é necessário que as aplicações sejam desenvolvidas visando à extração de paralelismo no nível de threads. Este artigo faz uma análise da decodificação de vídeos no padrão H.264 e suas possibilidades de extração de paralelismo no nível de threads. Uma comparação entre paralelismo no nível de macroblocos e no particionamento de frames é realizado em uma arquitetura multicore com suporte a 8 threads.

1. Introdução

As arquiteturas multiprocessadas integradas em único chip são utilizadas atualmente em sistemas embarcados, notebooks e computadores desktop. Estas arquiteturas visam um compromisso entre desempenho e consumo de potência, satisfazendo os requisitos cada vez mais exigentes das aplicações atuais. Estas arquiteturas podem ser homogêneas ou heterogêneas. Nas homogêneas todos os núcleos implementam o mesmo conjunto de instruções, enquanto que as heterogêneas integram processadores de diferentes arquiteturas, como processadores de propósito geral e processadores de sinais digitais (DSP).

Um exemplo de uma aplicação que demanda desempenho e baixo consumo de potência em termos computacionais é o padrão de vídeos H.264 [1]. Como a utilização deste padrão oferece é bastante variável, desde dispositivos portáteis (celulares, palm-tops) até decodificadores de alta definição (TV digital), é necessário considerar os requisitos de desempenho e também o consumo de potência, visto que alguns dispositivos dependem de hardware limitado e são alimentados por baterias.

Além disso, somente o fato de se munir de arquiteturas multiprocessadas para aumentar o desempenho não basta, pois é necessário que a aplicação possibilite a extração de paralelismo no nível de threads, para que esta se aproveite melhor dos recursos computacionais oferecidos. Conseqüentemente, fica a cargo dos desenvolvedores a resolução de problemas de exploração paralela espacial e temporal, acesso concorrente a variáveis e dependências de dados.

No caso do H.264, a sua complexidade e o grande número de dependência de dados no código dificultam a extração de paralelismo. O H.264 suporta vídeos de alta definição, exigindo um grande poder computacional para que o mesmo possa ser processado em tempo real. Isso ocorre pelo fato de que quanto maior a resolução dos quadros (frames) em um vídeo, maior é a complexidade e mais pixels devem ser processados. Em outras palavras, a dificuldade da decodificação de um vídeo é diretamente proporcional à sua resolução e ao seu tamanho (total de quadros).

Assim, este artigo tratará da análise da decodificação de vídeos no padrão H.264, utilizando-se de duas implementações do decodificador do H.264, que usam tipos de paralelismo distintos, fazendo um comparativo com relação ao ganho de desempenho (em termos de tempo de execução).

O estudo está dividido em seções: a Seção 2 apresenta o padrão H.264, suas vantagens e o projeto do seu decodificador; na Seção 3 são mostradas as alternativas de exploração paralela para a decodificação de vídeos H.264; na Seção 4 estão contidos os resultados e por fim na Seção 5 as conclusões obtidas e trabalhos futuros.

2. Padrão H.264

O padrão H.264 é dividido em perfis de aplicação, ou seja, ele se adapta ao dispositivo que irá utilizá-lo, permitindo ser executado em diferentes dispositivos, fato que justifica sua popularidade.

Além disso, o padrão oferece uma boa qualidade de imagem com uma taxa de bits mais baixa, comparada aos padrões MPEG-2 e MPEG-4, sobre os quais o H.264 foi construído [1].

Esse padrão é composto de um codificador e de um decodificador. O codificador tem a função de compactar o vídeo digital, para economizar espaço exigindo assim uma menor largura de banda para transmissão. O processo da codificação pode ser resumido na transformação de um vídeo em uma sequência de bits.

Já o decodificador faz o processo contrário, que consiste em extrair as informações de um vídeo compactado, recriando a sequência de imagens para serem exibidas na tela de um computador, por exemplo. É na decodificação que se encontra o foco deste estudo. 2.1. O processo da decodificação

No H.264, a decodificação é dividida em etapas, cada qual com uma função específica sobre a stream de entrada, ou seja, o vídeo compactado. São elas: descompressão (entropy decoder), reordenação, quantização inversa (Q-1), transformada inversa (T-1), compensação de movimentos (MC), predição Intra e Filtragem. O diagrama das etapas do decodificador H.264 e suas etapas podem ser vistas na Figura 1.

Figura 1. Etapas da decodificação de um vídeo H.264 [10]

A primeira etapa consiste em receber os bits comprimidos da stream de entrada, oriundos de meios como cabo, ar ou internet e encapsulados em “pacotes” de dados via NAL (Network Abstraction Layer).

A segunda etapa produz os elementos de sintaxe através desses bits, que podem estar codificados em CAVLC (Context-Adaptive Variable-Length Coding) ou CABAC (Context-Adaptive Binary Aritmetic Coding). Essa etapa é denominada Decodificação de Entropia, ou Entropy Decoding.

Pelo fato de que o H.264 permite o envio dos dados do vídeo fora de ordem, é necessário que ocorra a etapa da Reordenação. Após essa etapa, a Quantização Inversa e a Transformada Inversa são iniciadas, cujas funções são, respectivamente, recuperar os coeficientes truncados durante a codificação e passá-los para o domínio espacial. A Transformada Inversa produz o erro residual.

Então, é realizada a Compensação de Movimentos (CM), etapa que compõe a interpredição. Em muitos casos, os quadros próximos de uma sequência possuem características semelhantes (como o fundo imagem), diferindo apenas na movimentação de objetos na cena. Então a função da CM é diminuir as redundâncias de dados entre esses frames, utilizando frames de referência, diminuindo assim a taxa de bits do vídeo comprimido.

Já a predição Intra realiza um processo de predição espacial, que consiste, basicamente, em reduzir as redundâncias a partir de um mesmo quadro. Para isso, esse tipo de predição se utiliza de informações de blocos vizinhos apenas do quadro a ser comprimido.

Por fim, é realizada a filtragem, para suavizar as bordas entre os blocos vizinhos de um quadro, e então o resultado disso é o quadro reconstruído, ou seja, decodificado.

Os principais tipos de quadros são: I, P, e B-frames. O tipo do quadro define a predição utilizada, sendo que o tipo I é um frame que usa predição Intra, e a sua decodificação é independente dos demais. O tipo P usa predição Intra e Inter, sendo que sua decodificação depende de um ou mais frames anteriores, e o tipo B utiliza predição Intra e a sua predição Inter depende de frames anteriores a ele ou posteriores a ele [7].

3. Alternativas de Paralelismo no H.264

Em alguns estudos relacionados, encontramos algumas alternativas de execução paralela da decodificação do H.264. Explorar paralelismo com eficiência para o caso do decoder não é um processo simples, e requer atenção em alguns aspectos, como fatores limitantes ao paralelismo, flexibilidade, escalabilidade entre outros.

Para uma aplicação qualquer, pode-se afirmar que existem dois níveis de exploração paralela: Paralelismo Temporal (Task-Level) ou Paralelismo Espacial (Data-Level). O primeiro se baseia na divisão de partes funcionais do algoritmo, atribuindo-as a diferentes processadores. Já o segundo nível, o nível de dados, se baseia na divisão dos dados em partes menores para serem distribuídos entre os processadores. [9]

Entretanto, alguns aspectos com relação à exploração a ser usada devem ser analisados: x A escalabilidade: no paralelismo temporal, ela é um problema, caso o número de

tarefas for pequeno, implica em um número pequeno de processadores capazes de executar as tarefas em paralelo. Na exploração espacial, não será um problema se o número de partições dos dados for maior que o número de processadores;

x Overhead: no nível espacial, pode ocorrer overhead na comunicação dos dados que forem dependentes. No nível temporal, comunicação entre as tarefas de diferentes processadores é requerida, ou seja, deve haver um sincronismo entre os processos.

x Balanceamento de dados: na exploração temporal, o tempo de execução de cada tarefa pode variar, depende do dado que está sendo processado. Então se torna difícil prover um balanceamento de dados.

Especificamente para o caso do decodificador H.264, algumas alternativas de exploração de paralelismo são descritas [7]. Uma forma de aplicar a exploração paralela temporal na decodificação do H.264 é dividindo as tarefas, como, por exemplo, a execução da Quantização Inversa e da Transformada Inversa, em diferentes processadores.

Entretanto, nem todas as etapas do H.264 são paralelizáveis, como a Entropy Decoding, que é seqüencial devido às dependências de dados. Além disso, o número de tarefas é reduzido, limitando a escalabilidade da aplicação.

Para o caso da exploração do paralelismo espacial da decodificação do H264, existem três níveis de particionamento de dados, que são particularmente interessantes:

x Frame-Level: os quadros que não são usados como referência (B-Frames) na decodificação, podem ser processados de forma paralela, pois não há dependências de dados entre esses quadros. No entanto, o número de frames tipo B é pequeno e é definido na codificação do vídeo. Dessa forma, o paralelismo será limitado para poucos processos (threads).

x Slice-Level: os quadros podem ser divididos em uma ou mais partições (slices). Essas partições são independentes entre si, e, portanto, podem ser decodificadas em paralelo. Mas o número de partições é definido no processo da codificação, e, além disso, o aumento desse número acarreta no aumento na taxa de bits do vídeo comprimido. Em [7], é reportado que a taxa de bits aumenta em 34 % quando são utilizadas 64 partições por quadro.

x Macroblock-Level: os macroblocos (MB’s) de um quadro podem ser processados em paralelo caso as dependências entre eles forem satisfeitas. Em uma mesma partição, as dependências de dados estão nos macroblocos localizados na vizinhança superior, superior-esquerda, superior-direita, e na esquerda. Com base nisso, uma solução encontrada é processar os macroblocos de maneira diagonal, respeitando as dependências, permitindo assim a decodificação paralela.

Neste trabalho, será analisado a implementação paralela do decodificador no nível de macroblocos do H.264, chamada de Ffmpeg-2dwave [8], comparando com a implementação no nível de partições do decodificador H.264 [5], avaliando ganhos relativos de desempenho e tempo total de execução.

4. Visão geral do decodificador em nível de Partições

O software Ffmpeg disponibiliza, em [5] um decodificador paralelo H.264 com exploração espacial no nível de partições. Também se utilizam das POSIX-threads [3], permitindo a criação de múltiplos processos para a execução em arquiteturas multicore. Esta estratégia de decodificação se baseia na divisão dos frames em partições, que são agrupamentos de macroblocos. Sabendo-se que estas partições são independentes entre si, eles podem ser decodificados em paralelo. Na Figura 2, pode ser visto um frame com estas características.

Na Figura 2, o frame foi dividido em cinco partições (cada nível de cinza representa uma partição), e então eles podem ser decodificados por diferentes processadores. Entretanto, esse número, apesar de ser fixo para todos os frames de um vídeo, e ele é definido durante a codificação. Então, é necessário que, anteriormente, o vídeo seja codificado dessa forma (multislice).

5. Visão Geral do Ffmpeg-2dwave

Este decodificador se utiliza da exploração paralela espacial no nível de macroblocos, está disponibilizado em [6], e faz o uso das POSIX-Threads [3] para a criação de múltiplos processos para a execução em arquiteturas multicore.

Essa estratégia de decodificação paralela se baseia em processar os macroblocos de forma diagonal para respeitar as dependências entre os macroblocos vizinhos. Na Figura 3 essa estratégia pode ser visualizada.

Figura 3. Técnica do Ffmpeg-2Dwave em um frame. Os MB’s sendo processados são os MB’s que são independentes. (Adaptado de [7]).

De acordo com a Figura 3, as setas indicam as dependências de um macrobloco. Para decodificá-lo, é necessário ter apenas as informações dos macroblocos referenciados pelas setas. Então, quando as dependências forem satisfeitas, os macroblocos que são independentes entre si (em cinza-escuro, na Figura 3) podem ser processados em paralelo.

Uma vantagem dessa técnica é o fato de ela possuir uma boa escalabilidade, tendo em vista que o número de macroblocos independentes em um frame aumenta com o aumento da resolução da imagem:

x Resolução QCIF (176x144): 6 MBs independentes; x Resolução FHD (1920x1080): 60 MBs independentes;

Entretanto, esse número de MBs independentes não é constante. Esses valores correspondem a 4 e 9 espaços de tempo da decodificação, respectivamente. Além disso, pela Figura 3 pode-se afirmar que o número de MBs independentes é baixo no começo e no final da decodificação, e alto na metade da decodificação desse frame. Então, não é possível manter uma taxa fixa de processamento.

Outro fato importante é que o macrobloco independente somente poderá ser processado após a etapa da Entropy Decoding, pois esta etapa é executada de forma seqüencial. Na implementação utilizada neste trabalho, esse decodificador possui uma estrutura (a Frame manager), que controla a decodificação dos MBs em um frame. Ela é composta de uma thread de controle, de uma tabela de dependências, de uma thread pool (onde se encontram as worker threads), e de uma fila de tarefas.

Quando é encontrado um MB livre, é inserida uma tarefa (um macrobloco pronto para decodificar) na fila de tarefas. Então, qualquer thread disponível (worker thread) pode aceitá-la e processá-la. Ao terminar, ela atualiza a tabela de dependências, para que outra tarefa seja inserida na fila de processos, para ser executada.

Uma otimização, já proposta em [7], chamada de Tail submit, se baseia na forma de um acesso direto aos macroblocos prontos para serem processados, por parte das worker threads. No momento que uma worker thread encontrar um novo macrobloco livre, ela não precisa inseri-lo na fila de tarefas, podendo processá-la imediatamente. Assim, evita-se o ciclo de finalização/criação de novas threads no sistema. Essa otimização foi utilizada na obtenção dos resultados.

6. Resultados: Comparativo entre as estratégias

Para efetuar o comparativo entre os dois decodificadores apresentados, foi utilizada de uma arquitetura x86 multicore de 4 núcleos de processamento com 2 threads em cada núcleo, suportando até 8 threads executando em paralelo (Processador Xeon E5405 de 2GHz e 32GB de memória RAM, com Ubuntu 9.10 de 32 bits como Sistema Operacional). Foram utilizados, também, dois vídeos de teste, disponibilizados pela Xiph.org [2] para cada decoder, com pequenas diferenças com relação à codificação:

x Para a exploração no nível de partições (decoder 1), o vídeo Sintel_trailer720p e o RiverBed1080p foram codificados com oito partições por frame, em um total de 250 frames cada um, com o intuito de explorar o máximo de paralelismo (pois a arquitetura utilizada suporta até 8 threads paralelas);

x Para a exploração no nível de macroblocos (decoder 2), os dois vídeos foram codificados da mesma forma, diferindo apenas no número de partições em uma partição por frame. Com o aumento de partições nessa exploração poderia causar um maior overhead na comunicação entre as worker threads e a thread de controle.

x O software de codificação utilizado foi o x264 (disponibilizado em [4]).

Assim, foram criados cinco conjuntos de testes (para cada decoder): no primeiro, foi avaliado o tempo total da decodificação com apenas uma thread, e em seguida, dobrou-se o número de threads a cada novo conjunto de testes, chegando ao total de 16 threads. Os gráficos comparativos dos decoders, contendo as médias do tempo de execução, em segundos, para cada número de threads, podem ser visualizados na Figura 4 (a) e (b).

(a) Médias dos tempos de execução, para o

vídeo sintelTrailer

(b) Médias dos tempos de execução, para o vídeo riverbed

Figura 4. Gráficos das médias dos tempos de execução para paralelismo no nível de partições (Decoder1) e macroblocos (Decoder2)

Com base nos resultados apresentados na Figura 4(a), pode-se perceber que a execução

com o melhor desempenho foi o teste com 8 threads. No caso do decoder 2, a execução multithread obteve um ganho de 44,85% em relação à decodificação monothread. No decoder 2, o ganho com 8 threads foi de 36,52% em relação à execução monothread. Utilizando-se 16 threads não há ganho no tempo de execução, visto que a arquitetura suporta 8 threads de execução. Voltando-se para os resultados do vídeo riverbed em definição FullHD apresentados na Figura 4(b), os maiores ganhos também apareceram no teste com 8 threads.

Entretanto, com relação ao tempo total de execução, e comparando-se entre os dois decoders, é perceptível a diferença de tempo total gasto na decodificação. Em todos os casos, o decoder 1 obteve o menor tempo total de execução. Isso evidencia as dificuldades entre a comunicação entre as threads e o overhead na verificação de dependências de dados, que acaba resultando em um maior tempo de execução.

Fixando-se as configurações em 8 threads, o ganho médio do decoder 1 foi de 71,37% (riverbed) e 38,09% (sintelTrailer) em relação ao decoder 2.

7. Conclusões e Trabalhos Futuros

Neste artigo foi apresentado um estudo e um comparativo entre duas abordagens para a decodificação em paralelo do padrão de vídeos H.264. Duas técnicas de paralelismo espacial (de dados) foram apresentadas: paralelismo no nível de partições (slices) e de macroblocos. A análise de desempenho por parte das duas abordagens foi avaliada com relação ao tempo total de execução, com aumento gradativo no número de threads de execução.

Na exploração do paralelismo no nível de macroblocos, o ffmpeg-2dwave teve um tempo de execução maior que no paralelismo no nível de partições. No entanto seu paralelismo pode explorado em qualquer vídeo H.264, independente da forma de codificação.

Além disso, vale ressaltar que, na exploração no nível de partições, o vídeo deve ter sido previamente codificado de forma multislice. Esse tipo de codificação aumenta a taxa de bits do vídeo comprimido, mantendo a mesma qualidade de imagem. Para o vídeo 1 verificou-se um aumento de 8,12 % e para o vídeo 2 um aumento de 0,82% na taxa de bits na codificação com múltiplas partições. Portanto, se o objetivo é a máxima aceleração da decodificação paralela a escolha deve ser pela codificação em partições. No entanto, se é necessário uma solução genérica e escalável (independente do tipo de codificação), a solução mais adequada é o paralelismo no nível de macroblocos.

Esses resultados foram obtidos em uma arquitetura multicore homogênea. Como trabalhos futuros, planeja-se avaliar a decodificação do padrão de vídeos H.264 em uma arquitetura heterogênea, como a plataforma BeagleBoard [11], que integra um processador ARM/Cortex a8 com processadores de propósito especifico como o processador de sinais digitais (DSP) C64x.

Referências

[1] Richardson, I., “An Overview of H.264”,

http://www.vcodex.com/h264overview.html , julho de 2011.

[2] Xiphr.org Test Media, http://media.xiph.org/video/derf/, junho 2011. [3] POSIX Threads Programming. Disponível em:

https://computing.llnl.gov/tutorials/pthreads/ , maio 2011. [4] x264 – a free h264/avc encoder. Disponível em:

http://www.videolan.org/developers/x264.html, julho 2011.

[5] FFmpeg source code. Disponível em: http://FFmpeg.org/download.html, agosto 2010.

[6] FFmpeg-2dwave: A parallel h.264 decoder based on FFmpeg. Disponível em:

http://alvarez.site.ac.upc.edu/hdvideobench/FFmpeg-2dwave.html , janeiro 2011.

[7] Meenderinck, C.; Azevedo, A.; Alvarez, M.; Juurlink, B.; Ramirez, A. “Parallel Scalability of H.264”, Delft University of Technology, 2008.

http://portal.acm.org/citation.cfm?id=1629484, janeiro 2011.

[8] M. Alvarez, A. Ramirez, A. Azevedo, C.H. Meenderinck, B.H.H. Juurlink, M. Valero. “Scalability of Macroblock-level parallelism for H.264 decoding”. International Conference on Parallel and Distributed Systems 2009, December 8-11, 2009, Shenzhen, China.

[9] E. van der Tol, E. Jaspers, and R. Gelderblom, "Mapping of H.264 Decoding on a Multiprocessor Architecture". In Image and Video Communications and Processing, vol. 5022 p. 707-718, Jan. 2003, Santa Clara, CA, USA.

[10] MANOEL, E. T. M. Codificação de Vídeo H.264 - Estudo de Codificação Mista de Macroblocos. Dissertação (Monografia) — UFSC, 2007.

[11] Especificação da plataforma OMAP 3530 – Beagleboard.