Especificação



Baixar 2,81 Mb.
Página7/24
Encontro01.07.2018
Tamanho2,81 Mb.
1   2   3   4   5   6   7   8   9   10   ...   24

4.2 Vídeo de saída


A implementação tratada neste trabalho suporta um subconjunto dos recursos presentes no padrão. A tabela 4.2 apresenta um resumo dos recursos suportados.




Parâmetro

Resumo

Perfis

Baseline

Níveis

1 e 1.2

Latência de codificação

4 quadros/segundo

Formato de vídeo comprimido

Fluxo de bytes H.264 (ISO/IEC 14496-15), Anexo B da Recomendação do ITU-T.

Tabela 4.2 – Resumo das especificações do projeto para vídeo de saída
      1. Perfis


De acordo com [26], um perfil especifica qual sintaxe de codificação (algoritmo) é usada, enquanto um nível especifica os vários parâmetros (resolução, taxa de quadros, taxa de bit, etc.).

Os padrões de codificação de vídeo em geral possuem uma gama enorme de recursos que, quando aplicados em conjunto, permitem obter altas taxas de compactação de vídeo. Um perfil nada mais é que um subconjunto desses recursos, especialmente selecionados para funcionar em determinados equipamentos e abranger um determinado público.

O perfil implementado neste trabalho é o Baseline, que é destinado aos dispositivos de baixa capacidade de processamento e o público de aplicações via Internet, tal como vídeo conferências, vídeo telefonia e comunicação sem fio.



        1. 4.2.1.1 Baseline

Dos cinco tipos de fatias disponíveis no padrão H.264, o perfil Baseline suporta apenas duas, I e P. Por meio desses dois tipos de fatias são implementadas as codificações Intra e Inter.

As fatias nesse perfil também não podem ser particionadas, ou seja, toda a fatia deverá ser enviada em uma única unidade NAL.

As codificações por entropia presentes são Exp-Golomb para parâmetros e CAVLC para dados.

Os recursos que não são permitidos nesse perfil são: a codificação CABAC; predição com peso; fatias SP, SI e B; particionamento de dado (fatias);


      1. 4.2.2 Orientação da Palavra de Dado (Endianess)


A função que testa o endian foi fixada para retornar little-endian, que é o padrão da arquitetura Intel.


  1. Capítulo 5: Desenvolvimento do Codificador H.264 em Java


O comitê criador do padrão H.264 disponibilizou um código-fonte de referência [2] escrito em C para que terceiros implementem suas próprias versões do codificador H.264, e como mencionado anteriormente a idéia central do trabalho é implementar uma versão em Java desse codificador.

O trabalho não consiste somente em portar um código-fonte escrito em C para Java, foi feita uma análise de orientação a objetos em cima do código estruturado fornecido como referência. Além disso, há toda uma preocupação com a integração dele com a JMF, que por sua vez possui uma arquitetura particular.

Seguindo a ordem como os dados são processados, os itens a seguir abordam cada aspecto relacionado ao projeto, descrevendo como cada parte do código-fonte de referência foi implementado em Java utilizando a Java Media Framework. E no Apêndice B há uma tabela que complementa este capítulo, mostrando mais diretamente a equivalência entre os diversos módulos do código de referência e as classes Java que implementam as funções desses módulos.




    1. 5.1 Leitura dos quadros do arquivo YUV


O processamento inicia pela leitura dos quadros descompactados no formato YCbCr, que eqüivale ao quadro original Fn da figura 2.3.

No código de referência, há um laço de repetição que percorre todos os quadros do arquivo a ser codificado. A cada iteração, é chamada a função encode_one_frame do arquivo image.c, que por sua vez chama a função ReadOneFrame, presente no mesmo arquivo, para ler um quadro do arquivo a ser codificado.

Neste trabalho, a leitura é realizada por meio da JMF, que lê cada quadro de vídeo do arquivo de entrada e permite acesso aos bytes individuais desse quadro por meio de um objeto da classe javax.media.Buffer.




      1. 5.1.1 Função encode_one_frame


No código do trabalho, o método process da classe H264Encoder eqüivale à função encode_one_frame. Mas o método process não chama nenhum método para ler um quadro do arquivo de origem, pois ele é chamado após a JMF ler cada quadro do arquivo. Em suma, é chamado o método process após cada quadro ter sido lido.

O método process da classe H264Encoder possui dois argumentos, ambos objetos da classe Buffer, onde o primeiro contém os dados lidos do arquivo de entrada e o segundo é destinado a armazenar os dados codificados.


      1. 5.1.2 Função ReadOneFrame


A funcionalidade oferecida pela função ReadOneFrame do código de referência é fornecida no trabalho por meio de um conjunto de classes implementadas por mim e controladas pela JMF.

O primeiro passo consiste em dizer à JMF que os arquivos com extensão .yuv devem ser lidos pela classe YUVParser. Então ao abrir um arquivo desse tipo a JMF chama o método setSource dessa classe passando um objeto DataSource que contém um fluxo com os bytes do arquivo lido.

Então é criado um objeto YUVVideoTrack que representa a trilha de vídeo desse arquivo. Caso o arquivo lido fosse composto por uma trilha de vídeo e uma de som, seria criada uma trilha a mais para interpretar o fluxo de áudio do arquivo. A classe YUVVideoTrack possui um método chamado readFrame que é chamado para ler um número determinado de bytes do arquivo (cujo valor foi preestabelecido no construtor dessa classe por meio do argumento dataSize). Esse número de bytes representa o tamanho de cada quadro de vídeo, dessa forma, a JMF chama o método readFrame para ler cada quadro do arquivo de origem, interpretar os dados, e colocar o resultado no objeto Buffer que recebe como parâmetro.

Os dados lidos pelo método readFrame da classe YUVVideoTrack e colocado no objeto Buffer recebido como argumento, são passados então para a classe de codificação por meio da JMF.


    1. 5.2 Predição Intra Quadro


A predição Intra é aquela que utiliza apenas as amostras contidas no mesmo quadro, sem fazer referência nenhum outro quadro anteriormente codificado, para reduzir a redundância entre duas amostras. A predição intra quadro visa reduzir a redundância espacial de cada quadro de um vídeo.



      1. 5.2.1 I_PCM


O modo I_PCM é uma alternativa à predição intra e consiste em transmitir os valores das amostras diretamente, sem predição, transformada ou codificação por entropia. Um macrobloco I_PCM é gravado com os mesmos valores que possuia no arquivo descompactado.

Neste trabalho, a classe IPCMEncodingMode implementa a predição I_PCM.


      1. 5.2.2 Intra 16x16 Luma


O modo de predição Intra 16x16 consiste em predizer os valores de um macrobloco inteiro a partir das amostras previamente codificadas de macroblocos vizinhos. Os valores preditos são subtraídos das amostras originais para obter valores residuais. Em seguida, esses valores residuais são transformados e quantizados. Lembrando que mesmo a predição sendo realizada no macrobloco como um todo, a transformada é aplicada em cada bloco 4x4 individualmente.



O H.264 utiliza as letras A, B, C e D para indicar quais partições (blocos ou macroblocos) estão disponíveis para a partição sendo codificada. A figura 5.1 mostra a posição dos macroblocos vizinhos (A, B, C e D) em relação ao macrobloco sendo codificado (E), e em vermelho blocos vizinhos e bloco corrente. Alguns macroblocos vizinhos não estão disponíveis próximo às bordas do quadro, por exemplo, se o macrobloco sendo codificado (E) for o número 0, ou seja, o primeiro do quadro, nenhum dos vizinhos estará disponível. Já o segundo macrobloco, número 1, terá apenas o vizinho A.

Figura 5.1 – Partição corrente (E) e partições vizinhas (A, B, C e D).


O padrão H.264/AVC define quatro modos de predição Intra 16x16 Luma: Vertical, Horizontal, DC e Plano. Cada qual sendo melhor aplicado em um determinado padrão de pixels. Por exemplo, o modo Plano se aplica bem em regiões onde há transição de tons.

No código de referência [2], a função Intra16x16_Mode_Decision calcula os quatro modos de predição por meio da função intrapred_16x16, logo em seguida verifica qual dos modos possui a menor distorção por meio da função find_sad_16x16 e por fim aplica a transformada e quantização usando a função dct_16x16.

O código desenvolvido neste trabalho separa cada um dos quatros modos em classes: Intra16x16LumaDCPredictor, Intra16x16LumaHorizontalPredictor, Intra16x16LumaVerticalPredictor e Intra16x16LumaChromaPlanePredictor. Cada uma dessas classes sobrescreve o método doIntraPrediction, o qual é invocado pela classe abstrata Intra16x16LumaAbstractPredictor que é a classe base dos modos. Toda funcionalidade comum aos quatro modos foi implementada nesta classe, tal como as rotinas de transformação, reconstrução, codificação por entropia e cálculo da distorção. Assim, cada classe é responsável por sua codificação.

Para saber qual é o melhor modo para um determinado macrobloco, basta obter a distorção de cada um dos modos e comparar os valores entre si.


Figura 5.2 – Ordem de escaneamento dos blocos 4x4 em um macrobloco [1].


Quando um macrobloco é codificado no modo Intra 16x16 Luma, cada coeficiente DC de cada um dos dezesseis blocos 4x4 luma é escaneado primeiro, formando um bloco 4x4 composto unicamente por coeficientes DC (figura 5.2). Nesse bloco de coeficientes DC é aplicada uma transformada adicional chamada Hadamard e, em seguida esses coeficientes são quantizados e reordenados. De forma similar, no modo Intra 8x8 Chroma, para cada componente é formado um bloco 2x2 de coeficientes DC, aplicada a transformada de Hadamard, uma quantização nos coeficientes e a reordenação dos mesmos em um vetor.

Os dezesseis blocos 4x4 luma (0 a 15), os quatro blocos 4x4 Cb (18 a 21) e os quatro blocos 4x4 Cr (22 a 25) são chamados de blocos AC. Esses blocos são escaneados a partir da segunda posição da figura 5.4, contendo quinze coeficientes cada, ao invés de dezesseis. Esses blocos são então quantizados e reordenados. Os blocos –1 (contendo dezesseis coeficientes), 16 (com quatro coeficientes) e 17 (também com quatro coeficientes) são chamados de blocos DC.




      1. 5.2.2 Intra 8x8 Chroma


Os modos de predição Intra 8x8 Chroma são bem parecidos com os Intra 16x16 Luma, exceto pela ordem (DC, Horizontal, Vertical e Plano) e pelo fato do modo 0, Plano, realizar a predição individualmente nos quatro blocos 4x4 que compõem o bloco 8x8, ao contrário do modo Intra 16x16 Luma Plano, que realiza uma única predição no bloco inteiro.

No código de referência [2], a função IntraChromaPrediction calcula os quatro modos de predição Intra Chroma (DC, Horizontal, Vertical e Plana) para cada um dos componentes de cor (Cb e Cr) do macrobloco sendo codificado. Nessa mesma função são computados todos os quatros modos de predição. Em seguida é chamada na função ChromaResidualCoding, para cada um dos componente de cor (Cb e Cr), é decidido o tipo de predição e realizada a transformada e quantização do resíduo dos coeficientes. A função ChromaPrediction4x4 fica responsável por decidir o tipo de predição, Intra ou Inter, e a função IntraChromaPrediction4x4 copia os valores da predição para um buffer global e atribui os valores residuais à outro buffer. Por fim, a função dct_chroma aplica a transformada e quantização no resíduo dos coeficientes.

O modo Intra 8x8 Chroma adota o mesmo esquema do modo Intra 16x16 Luma, separando cada um dos quatros modos de predição em classes: Intra8x8ChromaDCPredictor, Intra8x8ChromaHorizontalPredictor, Intra8x8ChromaVerticalPredictor e Intra8x8ChromaPlanePredictor. Cada uma dessas classes sobrescreve o método doIntraPrediction, invocado pela classe abstrata Intra8x8ChromaAbstractPredictor que é a classe base dos modos e onde toda funcionalidade comum aos quatro modos de predição foi implementada.






1   2   3   4   5   6   7   8   9   10   ...   24


©livred.info 2017
enviar mensagem

    Página principal