BR112016007760B1 - Método e aparelho de decodificação de dados de vídeo e método de codificação de dados de vídeo - Google Patents

Método e aparelho de decodificação de dados de vídeo e método de codificação de dados de vídeo Download PDF

Info

Publication number
BR112016007760B1
BR112016007760B1 BR112016007760-1A BR112016007760A BR112016007760B1 BR 112016007760 B1 BR112016007760 B1 BR 112016007760B1 BR 112016007760 A BR112016007760 A BR 112016007760A BR 112016007760 B1 BR112016007760 B1 BR 112016007760B1
Authority
BR
Brazil
Prior art keywords
block
sub
blocks
video
video data
Prior art date
Application number
BR112016007760-1A
Other languages
English (en)
Other versions
BR112016007760A2 (pt
Inventor
Li Zhang
Ying Chen
Original Assignee
Qualcomm Incorporated
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Incorporated filed Critical Qualcomm Incorporated
Publication of BR112016007760A2 publication Critical patent/BR112016007760A2/pt
Publication of BR112016007760B1 publication Critical patent/BR112016007760B1/pt

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • H04N19/517Processing of motion vectors by encoding
    • H04N19/52Processing of motion vectors by encoding by predictive encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/56Motion estimation with initialisation of the vector search, e.g. estimating a good candidate to initiate a search
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/577Motion compensation with bidirectional frame interpolation, i.e. using B-pictures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)

Abstract

TÉCNICAS DE CODIFICAÇÃO DE VÍDEO COM O USO DE PARTIÇÃO DE MOVIMENTO ASSIMÉTRICO. Trata-se de técnicas para decodificar dados de vídeo que incluem receber dados residuais que correspondem a um bloco de dados de vídeo; em que o bloco de dados de vídeo é criptado com o uso de partição de movimento assimétrico, é previsto unidirecionalmente com o uso de previsão de síntese de vista de regresso (BVSP), e tem um, tamanho de 16x12, l2x16, 16x4 ou 4x16, partição do bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8X4 ou 4x8, que deriva um vetor de movimento de disparidade respectivo para cada um dentre os sub- blocos de um bloco de profundidade correspondente em uma figuração de profundidade correspondente a uma figuração de referência, que sintetiza um, bloco de referência respectivo para cada . um dos sub-blocos que usam os vetores de movimento de disparidade derivados respectivos, e decodifica o bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub-blocos que usam os dados residuais e os blocos de referência respectivos sintetizados.

Description

[0001] Este pedido reivindica o benefício do Pedido Provisório no U.S. 61/877.793, depositado em 13 de setembro de 2013, e do Pedido Provisório no U.S. 61/881.383, depositado em 23 de setembro de 2013, cujo conteúdo é incorporado a título de referência no presente documento.
CAMPO DA TÉCNICA
[0002] Esta revelação se refere à codificação de vídeo, isto é, criptação ou decodificação de dados de vídeo.
ANTECEDENTES
[0003] As capacidades de vídeo digital podem ser incorporadas em uma ampla faixa de dispositivos, incluindo televisões digitais, sistemas de difusão direta digital, sistemas de difusão sem fio, assistentes digitais pessoais (PDAs), computadores do tipo laptop ou desktop, computadores do tipo tablet, leitores de e-book, câmeras digitais, dispositivos de gravação digitais, reprodutores de mídia digitais, dispositivos de vídeo jogo, consoles de vídeo jogo, celular ou telefones de radiossatélite, conhecidos como “telefones inteligentes”, dispositivos de teleconferência por vídeo, dispositivos de difusão por vídeo e similares. Os dispositivos de vídeo digital implantam técnicas de codificação de vídeo, como as descritas nos padrões definidos por MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Parte 10, Codificação de Vídeo Avançada (AVC), o padrão de Codificação de Vídeo de Alta Eficiência (HEVC) atualmente sob desenvolvimento e extensões de tais padrões. Os dispositivos de vídeo podem transmitir, receber, criptar, decodificar e/ou armazenar informações de vídeo digital de maneira mais eficiente implantando-se tais técnicas de codificação de vídeo.
[0004] As técnicas de codificação de vídeo incluem predição espacial (intraimagem) e/ou predição temporal (interimagem) para reduzir ou remover a redundância inerente em sequências de vídeo. Para a codificação de vídeo com base em bloco, uma fatia de vídeo (por exemplo, um quadro de vídeo ou uma porção de um quadro de vídeo) pode ser particionada em blocos de vídeo, que também podem ser denominados de blocos em árvore, unidades de codificação (CUs) e/ou nós de codificação. Os blocos de vídeo em uma fatia intracodificada (I) de uma imagem são criptografados com o uso de uma predição espacial em relação às amostras de referência em blocos vizinhos na mesma imagem. Os blocos de vídeo em uma fatia intercodificada (P ou B) de uma imagem podem usar espacial em relação às amostras de referência em blocos vizinhos na mesma predição ou imagem temporal em relação às amostras de referência em outras imagens de referência. As imagens podem ser denominadas como quadros, e as imagens de referência podem ser denominadas como quadros de referência.
[0005] A predição temporal ou espacial resulta em um bloco preditivo para um bloco a ser codificado. Os dados residuais representam diferenças de pixel entre o bloco original a ser codificado e o bloco preditivo. Um bloco intercodificado é criptografado de acordo com um vetor de movimento que aponta para um bloco de amostras de referência que forma o bloco preditivo, sendo que os dados residuais indicam a diferença entre o bloco codificado e o bloco preditivo. Um bloco intracodificado é criptografado de acordo com um modo de intracodificação e os dados residuais. Para compressão adicional, os dados residuais podem ser transformados do domínio de pixel para um domínio de transformada, resultando em coeficientes residuais que podem, em seguida, ser quantizados. O coeficiente de transformada quantizado, disposto inicialmente em uma matriz bidimensional e pode ter sua varredura realizada a fim de produzir um vetor monodimensional de coeficiente de transformada, e a codificação por entropia pode ser aplicada para conseguir ainda mais compressão.
SUMÁRIO DA INVENÇÃO
[0006] Em geral, esta revelação se refere à codificação de vídeo tridimensional (3D) com base em codecs avançados, incluindo, em alguns exemplos, técnicas de codificação de profundidade. Esta revelação descreve técnicas para visualizar codificação de predição de síntese, incluindo a determinação de tamanhos de bloco, quando usadas em combinação com partição de movimento assimétrico. Esta revelação também descreve técnicas para predição de movimento avançado quando usada em combinação com partição de movimento assimétrico.
[0007] Em um exemplo da revelação, um método para decodificar dados de vídeo compreende receber dados residuais correspondentes a um bloco de dados de vídeo, em que o bloco de dados de vídeo é criptografado com o uso de partição de movimento assimétrico, é previsto de maneira unidirecional com o uso de predição de síntese de vista retrógrada (BVSP), e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16, particionar o bloco de dados de vídeo em sub-blocos, sendo que cada sub-bloco tem um tamanho de 8x4 ou 4x8, derivar um vetor de movimento de disparidade respectivo para cada um dos sub-blocos de um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência, sintetizar um bloco de referência respectivo para cada um dos sub-blocos com o uso dos vetores de movimento de disparidade derivados respectivos e decodificar o bloco de dados de vídeo realizando-se compensação de movimento em cada um dos sub-blocos com o uso dos dados residuais e dos respectivos blocos de referência sintetizados.
[0008] Em outro exemplo da revelação, um método para criptar dados de vídeo compreende gerar um bloco de dados de vídeo com o uso de partição de movimento assimétrico, em que o bloco de dados de vídeo é previsto de maneira unidirecional com o uso de predição de síntese de vista retrógrada (BVSP) e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16, particionar o bloco de dados de vídeo em sub- blocos, sendo que cada sub-bloco tem um tamanho de 8x4 ou 4x8, derivar um vetor de movimento de disparidade respectivo para cada dos sub-blocos de um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência, sintetizar um bloco referência respectivo para cada um dos sub-blocos com o uso dos vetores de movimento de disparidade derivados respectivos e criptar o bloco de dados de vídeo realizando-se a compensação de movimento em cada um dos sub-blocos com o uso dos blocos de referência respectivos sintetizados.
[0009] Em outro exemplo da revelação, um aparelho configurado para decodificar os dados de vídeo compreende uma memória de vídeo configurada para armazenar informações correspondentes a um bloco de dados de vídeo e um ou mais processadores configurados para receber dados residuais correspondentes ao bloco de dados de vídeo, em que o bloco de dados de vídeo é criptografado com o uso de partição de movimento assimétrico, é previsto de maneira unidirecional com o uso de predição de síntese de vista retrógrada (BVSP) e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16, particionar o bloco DE dados de vídeo em sub-blocos, sendo que cada sub-bloco tem um tamanho de 8x4 ou 4x8, derivar um vetor de movimento de disparidade respectivo para cada um dos sub-blocos de um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência, sintetizar um bloco referência respectivo para cada um dos sub-blocos com o uso dos vetores de movimento de disparidade derivados respectivos e decodificar o bloco de dados de vídeo realizando-se a compensação de movimento em cada um dos sub-blocos com o uso dos dados residuais e dos blocos de referência respectivos sintetizados.
[0010] Em outro exemplo da revelação, um aparelho configurado para decodificar dados de vídeo compreende meios para receber dados residuais correspondentes a um bloco de dados de vídeo, em que o bloco de dados de vídeo é criptografado com o uso de partição de movimento assimétrico, é previsto de maneira unidirecional com o uso de predição de síntese de vista retrógrada (BVSP) e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16, meios para particionar o bloco de dados de vídeo em sub-blocos, sendo que cada sub-bloco tem um tamanho de 8x4 ou 4x8, meios para derivar um vetor de movimento de disparidade respectivo para cada um dos sub-blocos a partir um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência, meios para sintetizar um bloco de referência respectivo para cada dos sub-blocos com o uso dos vetores de movimento de disparidade derivados respectivos e meios para decodificar o bloco de dados de vídeo realizando-se a compensação de movimento em cada um dos sub-blocos com o uso dos dados residuais e dos blocos de referência respectivos sintetizados.
[0011] Os detalhes de um ou mais aspectos das técnicas são estabelecidos nos desenhos anexos e na descrição abaixo. Outros objetos, aspectos e vantagens ficarão evidentes a partir da descrição, dos desenhos e das reivindicações.
BREVE DESCRIÇÃO DOS DESENHOS
[0012] A Figura 1 é um diagrama de blocos que ilustra um sistema de criptação e decodificação de vídeo exemplificativo que pode utilizar as técnicas de interpredição desta revelação.
[0013] A Figura 2 é um diagrama conceitual que ilustra uma ordem de decodificação exemplificativa para vídeo de múltiplas vistas.
[0014] A Figura 3 é um diagrama conceitual que ilustra uma estrutura de predição exemplificativa para um vídeo de múltiplas vistas.
[0015] A Figura 4 é um diagrama conceitual que ilustra valores de textura e de profundidade para um vídeo 3D.
[0016] A Figura 5 é um diagrama conceitual que ilustra tipos de partição exemplificativos.
[0017] A Figura 6 é um diagrama conceitual que ilustra candidatos de vetor de movimento de modo de mescla.
[0018] A Figura 7 é uma tabela que indica uma especificação exemplificativa de índices candidatos de mescla.
[0019] A Figura 8 é um diagrama conceitual que ilustra blocos vizinhos usados para um processo de derivação de vetor de disparidade exemplificativo.
[0020] A Figura 9 é um diagrama conceitual que ilustra um processo de derivação de vetor de disparidade de bloco vizinho.
[0021] A Figura 10 é um diagrama conceitual que ilustra quatro pixels de canto de um bloco de profundidade de 8x8.
[0022] A Figura 11 é um diagrama conceitual que ilustra uma derivação exemplificativa de candidato de vetor de movimento previsto entre vistas para modo de mescla/pulo.
[0023] A Figura 12 é uma tabela que indica uma especificação exemplificativa de índices de referência em 3D-HEVC.
[0024] A Figura 13 é um diagrama conceitual que ilustra uma derivação exemplificativa de um candidato de herança de vetor de movimento para codificação de profundidade.
[0025] A Figura 14 ilustra a estrutura de predição de predição residual avançada (ARP) em codificação de vídeo de múltiplas vistas.
[0026] A Figura 15 é um diagrama conceitual que ilustra uma relação exemplificativa dentre um bloco atual, um bloco de referência e blocos compensados de movimento.
[0027] A Figura 16 é um diagrama conceitual que ilustra uma predição de movimento entre vistas de unidade de subpredição.
[0028] A Figura 17 é um desenho conceitual que retrata técnicas de predição de síntese de vista retrógrada e de compensação de movimento desta revelação durante o uso de partição de movimento assimétrico.
[0029] A Figura 18 é um diagrama conceitual que ilustra técnicas de herança vetor de movimento e de compensação de movimento para partição tamanhos de movimento assimétrico de 4x16 e 16x4.
[0030] A Figura 19 é um diagrama de blocos que ilustra um exemplo de um criptografador de vídeo que pode implantar as técnicas de interpredição desta revelação.
[0031] A Figura 20 é um diagrama de blocos que ilustra um exemplo de um decodificador de vídeo que pode implantar as técnicas de interpredição desta revelação.
[0032] A Figura 21 é um fluxograma que ilustra um método de criptação exemplificativo da revelação.
[0033] A Figura 22 é um fluxograma que ilustra outro método de criptação exemplificativo da revelação.
[0034] A Figura 23 é um fluxograma que ilustra outro método de criptação exemplificativo da revelação.
[0035] A Figura 24 é um fluxograma que ilustra um método de decodificação exemplificativo da revelação.
[0036] A Figura 25 é um fluxograma que ilustra um método de decodificação exemplificativo da revelação.
[0037] A Figura 26 é um fluxograma que ilustra um método de decodificação exemplificativo da revelação.
DESCRIÇÃO DETALHADA
[0038] Em geral, esta revelação descreve técnicas relacionadas à codificação de vídeo 3D com base em codecs avançados, incluindo a codificação de uma ou mais vistas junto de um bloco de profundidade com o uso do codec de 3D-HEVC (Codificação de Vídeo de Alta Eficiência). Em particular, esta revelação descreve técnicas para dividir adicionalmente unidades de predição (PUs) particionadas com o uso de técnicas de partição de movimento assimétrico em sub-blocos menores. As técnicas desta revelação incluem técnicas para derivar e/ou herdar vetores de movimento e vetores de movimento de disparidade para sub-blocos de PUs particionadas com o uso de partição de movimento assimétrico.
[0039] A Figura 1 é um diagrama de blocos que ilustra um sistema de criptação e decodificação de vídeo exemplificativo 10 que pode utilizar as técnicas da presente revelação. Conforme mostrado na Figura 1, o sistema 10 inclui um dispositivo de fonte 12 que fornece dados de vídeo criptografados a serem decodificados posteriormente por um dispositivo de destino 14. Em particular, o dispositivo de fonte 12 pode fornecer dados de vídeo ao dispositivo de destino 14 por meio de uma mídia legível por computador 16. O dispositivo de fonte 12 e o dispositivo de destino 14 podem compreender qualquer um dentre uma ampla faixa de dispositivos, incluindo computadores de mesa, computadores do tipo notebook (isto é, do tipo laptop), computadores do tipo tablet, decodificadores de sinais, parelhos de telefone, tais como, os então chamados telefones “inteligentes”, então chamados “smart” pads, televisões, câmeras, dispositivos de exibição, reprodutores de mídia digital, consoles de jogos eletrônicos, dispositivo de transmissão contínua de vídeo, ou semelhantes. Em alguns casos, o dispositivo de fonte 12 e o dispositivo de destino 14 podem ser equipados para comunicação sem fio.
[0040] O dispositivo de destino 14 pode receber os dados de vídeo criptografados a serem decodificadores por meio de uma mídia legível por computador 16. A mídia legível por computador 16 pode compreender qualquer tipo de mídias ou dispositivos com capacidade para mover os dados de vídeo criptografados do dispositivo de fonte 12 ao dispositivo de destino 14. Em um exemplo, a mídia legível por computador 16 pode compreender uma mídia de comunicação para possibilitar que um dispositivo de fonte 12 transmite os dados de vídeo criptografados diretamente a um dispositivo de destino 14 em tempo real. Os dados de vídeo criptografados podem ser modulados de acordo com um padrão de comunicação, tal como, um protocolo de comunicação sem fio e transmitidos a um dispositivo de destino 14. A mídia de comunicação pode compreender qualquer mídia de comunicação sem fio e cabeada, tal como, um espectro de radiofrequência (RF) ou uma ou mais linhas de transmissão física. A mídia de comunicação pode formar parte de uma rede com base em pacote, tal como, uma rede de área local, uma rede de longa distância ou uma rede global, tal como, a Internet. A mídia de comunicação pode incluir roteadores, comutadores, estações-base, ou qualquer outro equipamento que pode ser útil que para facilitar a comunicação do dispositivo de fonte 12 com o dispositivo de destino 14.
[0041] Em alguns exemplos, os dados criptografados podem ser emitidos da interface de saída 22 para um dispositivo de armazenamento. De modo semelhante, os dados criptografados podem ser acessados pelo dispositivo de armazenamento através de uma interface de entrada. O dispositivo de armazenamento pode incluir qualquer um dentre uma variedade de meios de armazenamento de dados distribuídos ou acessados localmente como um disco rígido, discos Blu- ray, DVDs, CD-ROMs, memória flash, memória volátil ou não volátil ou qualquer outro meio de armazenamento digital adequado para armazenar dados de vídeo criptografados. Em um exemplo adicional, o dispositivo de armazenamento pode corresponder a um servidor de arquivo ou a outro dispositivo de armazenamento intermediário que pode armazenar o vídeo criptografado gerado pelo dispositivo de fonte 12. O dispositivo de destino 14 pode acessar os dados de vídeo armazenados do dispositivo de armazenamento por meio de transmissão contínua ou transferência por download. O servidor de arquivo pode ser qualquer tipo de servidor com capacidade para armazenar dados de vídeo criptografados e para transmitir esses dados de vídeo criptografados ao dispositivo de destino 14. Os servidores de arquivo exemplificativos incluem um servidor web (por exemplo, para um site da web), um servidor FTP, dispositivos de armazenamento anexado à rede (NAS) ou uma unidade de disco local. O dispositivo de destino 14 pode acessar os dados de vídeo criptografados através de qualquer conexão de dados padrão, incluindo uma conexão de Internet. Isso pode incluir um canal sem fio (por exemplo, uma conexão Wi-Fi), uma conexão cabeada (por exemplo, DSL, modem a cabo, etc.), ou uma combinação dos dois que é adequada para cessar os dados de vídeo criptografados armazenados em um servidor de arquivo. A transmissão de dados de vídeo criptografados do dispositivo de armazenamento pode ser uma transmissão contínua transmissão, uma transmissão através de transferência por download ou uma combinação das mesmas.
[0042] As técnicas da presente revelação não se limitam necessariamente a aplicações ou conimagens sem fio. As técnicas podem ser aplicadas à codificação de vídeo visando dar apoio a qualquer uma dentre uma variedade de aplicações de multimídia, tais como, difusões de televisão aberta, transmissões de televisão a cabo, transmissões de televisão a satélite, transmissões contínuas de vídeo pela Internet, tais como, transmissão contínua adaptativa dinâmica através de HTTP (DASH), vídeo digital que é criptografado em uma mídia de armazenamento de dados, decodificação de vídeo digital armazenado em uma mídia de armazenamento de dados, ou outras aplicações. Em alguns exemplos, o sistema 10 pode ser configurado para suportar transmissão de vídeo unidirecional ou bidirecional a fim de suportar aplicações, tais como, transmissão contínua de vídeo, reprodução de vídeo, difusão de vídeo e/ou vídeo telefonia.
[0043] No exemplo da Figura 1, o dispositivo de fonte 12 inclui uma fonte de vídeo 18, unidade de estimativa de profundidade 19, um criptografador de vídeo 20 e uma interface de saída 22. O dispositivo de destino 14 inclui a interface de entrada 28, decodificador de vídeo 30, unidade de renderização com base em imagem de profundidade (DIBR) 31 e o dispositivo de exibição 32. Em outros exemplos, um dispositivo de fonte e um dispositivo de destino pode incluir outros componentes ou disposições. Por exemplo, o dispositivo de fonte 12 pode receber dados de vídeo de uma fonte de vídeo externa 18, tal como, uma câmera externa. De igual modo, o dispositivo de destino 14 pode fazer interface com um dispositivo de exibição externo, em vez de incluir um dispositivo de exibição integrado.
[0044] O sistema ilustrado 10 da Figura 1 é apenas um exemplo. As técnicas desta revelação podem ser realizadas por qualquer dispositivo de criptação e/ou decodificação de vídeo digital. Embora, de modo geral, as técnicas desta revelação sejam realizadas por um dispositivo de criptação de vídeo, as técnicas também podem ser realizadas por um criptografador/decodificador de vídeo denominado tipicamente de “CODEC”. Ademais, as técnicas desta revelação também podem ser realizadas por um pré- processador de vídeo. O dispositivo de fonte 12 e o dispositivo de destino 14 são apenas exemplos de tais dispositivos de codificação em que o dispositivo de fonte 12 gera dados de vídeo codificados a para transmissão ao dispositivo de destino 14. Em alguns exemplos, os dispositivos 12, 14 pode operar de maneira substancialmente simétrica de modo que cada dos dispositivos 12, 14 incluam componentes de criptação e decodificação de vídeo. Por conseguinte, o sistema 10 pode suportar transmissão de vídeo unidirecional ou bidirecional entre os dispositivos de vídeo 12, 14, por exemplo, para a transmissão contínua de vídeo, para a reprodução de vídeo, para a difusão de vídeo ou para uma videotelefonia.
[0045] A fonte de vídeo 18 do dispositivo de fonte 12 pode incluir um dispositivo de captura de vídeo, tal como, uma câmera de vídeo, um arquivo de vídeo que contém um vídeo anteriormente capturado e/ou uma interface de alimentação de vídeo para receber vídeo de um fornecedor de conteúdo de vídeo. Como uma alternativa adicional, uma fonte de vídeo 18 pode gerar dados com base em computação gráfica como o vídeo-fonte ou uma combinação de vídeo ao vivo, vídeo arquivado e vídeo gerado por computador. Em alguns casos, caso a fonte de vídeo 18 seja uma câmera de vídeo, o dispositivo de fonte 12 e o dispositivo de destino 14 podem formar os então chamados telefones de câmera ou videofones. No entanto, conforme mencionado acima, as técnicas descritas nesta revelação podem ser aplicáveis à codificação de vídeo, em geral, e podem ser aplicados a aplicações sem fio e/ou cabeadas. Em cada caso, o vídeo capturado, pré-capturado ou gerado por computador pode ser criptografado pelo criptografador de vídeo 20. As informações de vídeo criptadas podem, então, ser emitidas pela interface de saída 22 para um meio legível por computador 16.
[0046] A fonte de vídeo 18 pode fornecer uma ou mais vistas de dados de vídeo ao criptografador de vídeo 20. Por exemplo, a fonte de vídeo 18 pode corresponder a um arranjo de câmeras, sendo que cada uma tem uma posição horizontal exclusiva em relação a uma cena particular que é filmada. Alternativamente, a fonte de vídeo 18 pode gerar dados de vídeo de perspectivas de câmeras horizontais distintas, por exemplo, com o uso de computação gráficas. A unidade de estimativa de profundidade 19 pode ser configurada para determinar valores para pixels de profundidade correspondentes aos pixels em uma imagem de textura. Por exemplo, a unidade de estimativa de profundidade 19 pode representar uma a unidade de Localização e Navegação pelo Som (SONAR), uma unidade de Detecção e Localização pela Luz (LIDAR), ou outra unidade com capacidade para determinar diretamente os valores de profundidade de maneira substancialmente simultânea durante ou registro de dados de vídeo de uma cena.
[0047] Adicional ou alternativamente, a unidade de estimativa de profundidade 19 pode ser configurada para calcular valores de profundidade indiretamente comparando- se duas ou mais imagens que foram capturadas substancialmente ao mesmo tempo a partir de diferentes perspectivas de câmera horizontais. Através do cálculo da disparidade horizontal entre valores de pixel substancialmente semelhantes nas imagens, a unidade de estimativa de profundidade 19 pode aproximar a profundidade de vários objetos na cena. A unidade de estimativa de profundidade 19 pode ser integrada de maneira funcional à fonte de vídeo 18, em alguns exemplos. Por exemplo, quando a fonte de vídeo 18 gera imagem de computação gráficas, a unidade de estimativa de profundidade 19 pode fornecer mapas de real profundidade para objetos gráficos, por exemplo, com o uso de coordenadas Z de pixels e objetos usados para renderizar imagens de texturas.
[0048] O meio legível por computador 16 pode incluir meios transitórios, como uma transmissão por difusão sem fio ou por difusão com fio ou meios de armazenamento (ou seja, meios de armazenamento não transitórios), como um disco rígido, unidade flash, disco compacto, disco de vídeo digital, disco Blu-ray ou outros meios legíveis por computador. Em alguns exemplos, um servidor de rede (não mostrado) pode receber dados de vídeo criptografados do dispositivo de fonte 12 e fornecer os dados de vídeo criptografados ao dispositivo de destino 14, por exemplo, por meio de uma transmissão de rede. De modo semelhante, um dispositivo de computação de uma instalação de produção de mídia, tal como uma, instalação de estampagem de disco, pode receber dados de vídeo criptografados do dispositivo de fonte 12 e produzir um disco que contém os dados de vídeo criptografados. Portanto, o meio legível por computador 16 pode ser entendido como incluindo um ou mais meios legíveis por computador de um certo número de formas, em vários exemplos.
[0049] A interface de entrada 28 de dispositivo de destinação 14 recebe informações a partir do meio legível por computador 16. As informações do meio legível por computador 16 podem inclui informações de sintaxe definidas pelo criptografador de vídeo 20, que também é usado pelo decodificador de vídeo 30, que inclui elementos de sintaxe que descrevem características e/ou o processamento de blocos e outras unidades codificadas, por exemplo, GOPs. O dispositivo de exibição 32 exibe os dados de vídeo decodificados para um usuário, e pode compreender qualquer um dentre uma variedade de dispositivos de visores como um tubo de raio de cátodo (CRT), um visor de cristal líquido (LCD), um visor de plasma, um visor de diodo emissor de luz orgânico (OLED) ou outro tipo de dispositivo de exibição. Em alguns exemplos, o dispositivo de exibição 32 pode compreender um dispositivo com capacidade para exibir duas ou mais vistas simultaneamente, ou de maneira substancialmente simultânea, por exemplo, para produzir um efeito visual 3D para um espectador.
[0050] A unidade de DIBR 31 do dispositivo de destino 14 pode renderizar vistas sintetizadas com o uso de informações de textura e de profundidade de vistas decodificadas recebidas do decodificador de vídeo 30. Por exemplo, uma unidade de DIBR 31 pode determinar a disparidade horizontal para dados de pixel de imagens de texturas como uma função de valores de pixels em mapas de profundidade correspondentes. Em seguida, a unidade de DIBR 31 pode gerar uma imagem sintetizada deslocando-se pixels em uma imagem de textura esquerda ou direita pela disparidade horizontal determinada. Dessa maneira, o dispositivo de exibição 32 pode exibir uma ou mais vistas, que podem corresponder às vistas decodificadas e/ou às vistas sintetizadas, em qualquer combinação. Em conformidade com as técnicas desta revelação, o decodificador de vídeo 30 pode fornecer valores de precisão originais e atualizados para faixas de profundidade e parâmetros de câmera para a unidade de DIBR 31, que podem usar as faixas de profundidade e os parâmetros de câmera para sintetizar apropriadamente as vistas.
[0051] Embora não seja mostrado na Figura 1, em alguns aspectos, o criptografador de vídeo 20 e o decodificador de vídeo 30 podem ser, cada um, integrados a um criptografador e decodificador de áudio, e podem incluir unidades MUX-DEMUX apropriadas, ou outro hardware e outro software, para lidar com a criptação tanto de áudio quanto de vídeo em um fluxo de dados comum ou fluxos de dados diferentes. Caso aplicável, as unidades MUX-DEMUX podem se conformar ao protocolo multiplexador ITU H.223, ou outros protocolos como protocolo de datagrama de usuário (UDP).
[0052] O criptografador de vídeo 20 e o decodificador de vídeo 30, cada um, podem ser implantados como qualquer um dentre uma variedade de conjunto de circuitos de criptografador adequado, como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), matrizes de portal programáveis por campo (FPGAs), lógica discreta, software, hardware, firmware ou quaisquer combinações dos mesmos. Quando as técnicas são implantadas parcialmente em software, um dispositivo pode armazenar instruções para o software em um meio legível por computador não transitório adequado e executar as instruções em hardware com o uso de um ou mais processadores para realizar as técnicas desta revelação. Cada um dentre o criptografador de vídeo 20 e o decodificador de vídeo 30 podem estar incluídos em um ou mais criptografadores ou decodificadores, um dos quais pode ser integrado como parte de um criptografador/decodificador (CODEC) combinado em um dispositivo respectivo. Um dispositivo que inclui o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, como um telefone celular.
[0053] O criptografador de vídeo 20 e o decodificador de vídeo 30 podem operar de acordo com um padrão de codificação de vídeo, tal como, um padrão de Codificação de Vídeo de Alta Eficiência (HEVC), e pode se conformar ao Modelo de Teste HEVC (HM). Alternativamente, o criptografador de vídeo 20 e o decodificador de vídeo 30 podem operar de acordo com outros padrões do proprietário ou industrias, tais como, o padrão ITU-T H.264, denominado alternativamente de MPEG-4, Parte 10, Codificação de Vídeo Avançada (AVC), ou extensões de tais padrões, tais como, a extensão MCVC do ITU-T H.264/AVC. O último rascunho comum de MVC é descrito em “Advanced video coding for generic audiovisual services”, ITU-T Recommendation H.264, março de 2010. Em particular, o criptografador de vídeo 20 e o decodificador de vídeo 30 podem operar de acordo com padrão de codificação de múltiplas vistas e/ou 3D, incluindo uma extensão 3D do padrão HEVC (por exemplo, 3D-HEVC).
[0054] Um rascunho do padrão HEVC, denominado de “Rascunho de Trabalho HEVC 10”, ou “WD 10”, é descrito no documento JCTVC-L1003v34, Brass et al., “High efficiency video coding (HEVC) text specification draft 10 10 (for FDIS & Last Call)”, Joint Collaborative Team on Video Coding(JCT- VC) de ITU-T SGI 6 WP3 e ISO/IEC JTC1/SC29/WG11, 12a reunião: Geneva, CH, 14 a 23 de janeiro de 2013, que, com data de 22 de agosto de 2014, pode ser transferido por download em: http://phenix.int- eyry.fr/ict/doc_end_user/documents/12_Geneva/wg11/JCTVC- L1003-v34.zip.
[0055] Outro rascunho do padrão HEVC é denominado no presente documento de “revisões de WD 10” descrito em Bross et al, “Editors’ propost corrections to HEVC version 1”, Joint Collaborative Team on Video Coding (JCT-VC) de ITU-T SGI 6 WP3 e ISO/IEC JTC1/SC29/WG11, 13a Reunião, Incheon, K, abril de 2013, que, com data de 22 de agosto de 2014, está disponível em: http://phenix.int- eyry.fr/jct/doc_end_user/documents/13_Incheon/wg11/JCTVC- M0432-v3.zip. Uma extensão com múltiplas vistas para HEVC, a saber, MV-HEVC, também está sendo desenvolvida pela JCT- 3V.
[0056] Atualmente, a Joint Collaboration Team on Video Coding 3D (JCT-3C) de VCEG e MPEG está desenvolvendo um padrão 3DV com base em HEVC, para o qual parte das tentativas de padronização inclui a padronização do codec de vídeo de múltiplas vistas com base em HEVC (MV-HEVC), e outra parte para a codificação de vídeo 3D com base em HEVC (3D- HEVC). Para MV-HEVC, deve-se garantir que haja apenas mudanças de sintaxe de alto nível (HLS) na mesma, de modo que nenhum módulo no nível de unidade de codificação/unidade de predição em HEVC precise ser reprojetado e possa ser reutilizado completamente para a MV-HEVC. Para 3D-HEVC, novas ferramentas de codificação, incluindo aquelas no nível de unidade de codificação/unidade de predição, tanto para a vista de textura quanto para a vista de profundidade podem ser incluídas e suportadas.
[0057] Um software de versão 3D-HTM para 3D- HEVC pode ser transferido por download no seguinte enlace: [3D-HTM version 8.0]: https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HT M-8.0/. Um rascunho de trabalho de 3D-HEVC (número do documento: El 001) é disponível em: http://phenix.it- sudparis.eu/jct2/doc_end_user/current_document.php?id=1361. A última descrição do software (número do documento: El 005) está disponível em: http://phenix.it- sudparis.eu/jct2/doc_end_user/current_document.php?id=1360.
[0058] Uma versão mais recente do software 3D- HTM para 3D-HEVC pode ser transferida por download no seguinte enlace: [3D-HTM version 12.0]: https://hevc.hhi.fraunhofer.de/svn/svn_3DVCSoftware/tags/HT M-12.0/. O rascunho de trabalho correspondente de 3D-HEVC (número do documento: 11001) está disponível em: http://phenix.int- eyry.fr/ict3v/doc_end_user/current_document.php?id=2299. A última descrição do software (número do documento: 11005) é disponível em: http://phenix.int- eyry.fr/jct3v/doc_end_user/current_document.php?id=2301.
[0059] Inicialmente, como técnicas de codificação exemplificativas de HEVC serão discutidas. As tentativas de padronização HEVC se baseiam em um modelo de evolução de um dispositivo de codificação de vídeo denominado de Modelo de Teste HEVC (HM). O HM presumiu diversas capacidades adicionais de dispositivos de vídeo de codificação em relação a dispositivos existentes de acordo com, por exemplo, ITU-T H.264/AVC. Por exemplo, embora o H.264 forneça nove modos de criptação de intrapredição, o HM pode fornecer até trinta e três modos de criptação de predição mais os modos DC e Planos.
[0060] Em HEVC e outras especificações de codificação de vídeo, uma sequência de vídeos inclui, tipicamente, uma série de imagens. As imagens também podem ser denominadas de “quadros”. Uma imagem pode incluir três matrizes de amostra, denominadas de SL, Scb, e Scr SL é uma matriz bidimensional (isto é, um bloco) de amostras de luma. Scb é uma matriz bidimensional de amostras de crominância Cb. Scb é uma matriz bidimensional de amostras de crominância Cr. As amostras de crominância também podem ser denominadas no presente documento de amostras de “croma”. Em outros exemplos, uma imagem pode ser um monocroma e pode incluir apenas uma matriz de amostras de luma.
[0061] A fim de gerar uma representação criptada de uma imagem, o criptografador de vídeo 20 pode gerar um conjunto de unidades de árvore de codificação (CTUs). Cada uma das CTUs pode ser um bloco de árvore de codificação de amostras de luma, dois blocos de árvore de codificação correspondentes de amostras de croma e estruturas de sintaxe usadas para codificar as amostras dos blocos de árvore de codificação. Em imagens de monocroma ou imagens que têm três planos de cor separados, uma CTU pode compreender um único bloco de árvore de codificação e estruturas de sintaxe usados para codificar as amostras do bloco de árvore de codificação. Um bloco de árvore de codificação pode ser um bloco NxN de amostras. Uma CTU também pode ser denominada de “bloco de árvore” ou de uma “unidade de codificação maior” (LCU). As CTUs de HEVC podem ser amplamente analógicas aos macroblocos de outros padrões standards, tais como, H.264/AVC. No entanto, a CTU não se limita necessariamente a um tamanho particular e pode incluir uma ou mais unidades de codificação (CUs). Uma fatia pode incluir um número inteiro de CTUs ordenados consecutivamente em uma ordem de varredura.
[0062] A fim de gerar uma CTU codificada, o criptografador de vídeo 20 pode realizar, recursivamente, partição de árvore quadrática nos blocos de árvore de codificação de uma CTU para dividir os blocos de árvore de codificação em blocos de codificação, por conseguinte, o nome “unidades de árvore de codificação”. Um bloco de codificação é um bloco NxN de amostras. Uma CU pode ser um bloco de codificação de amostras de luma e dois blocos de codificação correspondentes de amostras de croma de uma imagem que tem uma matriz de amostra de luma, uma matriz de amostra de Cb e uma matriz de amostra de Cr e estruturas de sintaxe usadas para codificar as amostras dos blocos de codificação. Em imagens de monocroma ou imagens que têm três planos de cor separados, uma CU pode compreender um único bloco de codificação e estruturas de sintaxe usados para codificar as amostras do bloco de codificação.
[0063] O criptografador de vídeo 20 pode particionar um bloco de codificação de uma CU em um ou mais blocos de predição. Um bloco de predição é um bloco (isto é, quadrado ou não quadrado) retangular de amostras nos quais a mesma predição é aplicada. Uma unidade de predição (PU) de uma CU pode compreender um bloco de predição de amostras de luma, dois blocos de predição correspondentes de amostras de croma e estruturas de sintaxe usadas para prever os blocos de predição. Nas imagens de monocroma ou em imagens que têm três planos de cor separados, uma PU pode compreende um único single bloco de predição e estruturas de sintaxe usadas para prever o bloco de predição. O criptografador de vídeo 20 pode gerar blocos preditivos de luma, de Cb e de Cr para blocos de predição de luma, de Cb e de Cr de cada PU da CU.
[0064] O criptografador de vídeo 20 pode usar intrapredição ou interpredição para gerar os blocos preditivos para uma PU. Se o criptografador de vídeo 20 usar intrapredição para gerar os blocos preditivos de uma PU, o criptografador de vídeo 20 pode gerar blocos preditivos da PU com base nas amostras decodificadas da imagem associada à PU. Em algumas versões de HEVC, para o componente de luma de cada PU, um método de intrapredição é utilizado com 33 modos de predição angulares (indicado de 2 a 34), modo de DC (indexado por 1) e modo Plano (indicado por 0).
[0065] Caso o criptografador de vídeo 20 use a interpredição para gerar os blocos preditivos de uma PU, o criptografador de vídeo 20 pode gerar os blocos preditivos da PU com base nas amostras decodificadas de uma ou mais imagens diferentes da imagem associada à PU. A interpredição pode ser uma interpredição unidirecional (isto é, predição de unipredição ou unipreditiva) ou uma interpredição bipreditiva (isto é, predição de bipredição ou bipreditiva). A fim realizar a unipredição ou bipredição, o criptografador de vídeo 20 pode gerar uma primeira lista de imagens de referência (RefPicList0) e uma segunda lista de imagens de referência (RefPicList1) para uma fatia atual. Cada uma das listas de imagens de referências pode incluir uma ou mais imagens de referência. Durante o uso da unipredição, o criptografador de vídeo 20 pode buscar as imagens de referência tanto na RefPicList0 como na RefPicList1 para determinar uma localização de referência dentro de uma imagem de referência. Adicionalmente, quando o uso da unipredição, o criptografador de vídeo 20 pode gerar, com base pelo menos em parte nas amostras correspondentes à localização de referência, os blocos de amostra preditivos para a PU. Ademais, durante o uso da unipredição, o criptografador de vídeo 20 pode gerar um único vetor de movimento que indica um deslocamento espacial entre um bloco de predição da PU e a localização de referência. A fim de indicar o deslocamento espacial entre um bloco de predição da PU e a localização de referência, um vetor de movimento pode incluir um componente horizontal que especifica um deslocamento horizontal entre o bloco de predição da PU e a localização de referência e pode incluir um componente vertical que especifica um deslocamento vertical entre o bloco de predição da PU e a localização de referência.
[0066] Durante o uso da bipredição para criptar uma PU, o criptografador de vídeo 20 pode determinar uma primeira localização de referência em uma imagem de referência na RefPicList0 e segunda localização de referência em uma imagem de referência na RefPicList1. Em seguida, o criptografador de vídeo 20 pode gerar, com base pelo menos parcialmente nas amostras correspondentes à primeira e segunda localização de referências, os blocos preditivos para a PU. Ademais, durante o uso da bipredição para criptar a PU, o criptografador de vídeo 20 pode gerar um primeiro vetor de movimento que indica um deslocamento espacial entre um bloco de amostra da PU e a primeira localização de referência e um segundo vetor de movimento que indica um deslocamento espacial entre o bloco de predição da PU e a segunda localização de referência.
[0067] Tipicamente, uma construção de lista de imagens de referência para a primeira ou para a segunda lista de imagens de referência (por exemplo, RefPicList0 ou RefPicList1) de uma imagem B inclui duas etapas: inicialização de lista de imagens de referência e reordenamento de lista de imagens de referência (modificação). A inicialização de lista de imagens de referência é um mecanismo explícito que coloca as imagens de referência na memória de imagem de referência (também conhecido como armazenamento temporário de imagem decodificada) em uma lista com base nos valores de ordem de POC (Contagem de Ordem de imagem, alinhada à ordem de exibição de uma imagem). O mecanismo de reordenamento de lista de imagens de referência pode modificar a posição de uma imagem que foi colocada na lista durante a inicialização de lista de imagens de referência a qualquer posição nova ou colocar qualquer imagem de referência na memória de imagem de referência em qualquer posição até mesmo caso a imagem não pertença à lista inicializada. Algumas imagens, após o reordenamento de lista de imagens de referência (modificação), podem ser colocadas em uma posição muito distante na lista. No entanto, caso uma posição de uma imagem exceda o número de imagens de referência ativas da lista, a imagem não é considerada como uma entrada da lista de imagens de referência final. O número de imagens de referência ativas pode ser sinalizado no cabeçalho de fatia para cada lista.
[0068] Após a lista de imagens de referências serem construídas (a saber, a RefPicList0 e a RefPicList1, se disponível), um índice de referência a uma lista de imagens de referência pode ser usado para identificar qualquer imagem de referência incluída na lista de imagens de referência.
[0069] Após o criptografador de vídeo 20 gera blocos preditivos de luma, de Cb e de Cr para uma ou mais PUs de uma CU, o criptografador de vídeo 20 pode gerar um bloco residual de luma para a CU. Cada amostra no bloco residual de luma da CU indica uma diferença entre uma amostra de luma em um dentre os blocos preditivos de luma da CU e uma amostra correspondente no bloco de codificação de luma original da CU. Além disso, o criptografador de vídeo 20 pode gerar um bloco residual de Cb para a CU. Cada amostra no bloco residual de Cb da CU pode indicar uma diferença entre uma amostra de Cb em um dentre os blocos preditivos de Cb da CU e uma amostra correspondente no bloco de codificação de Cb original da CU. O criptografador de vídeo 20 também pode gerar um bloco residual de Cr para a CU. Cada amostra no bloco residual de Cr da CU pode indicar uma diferença entre uma amostra de Cr em um dentre os blocos preditivos de Cr da CU e uma amostra correspondente no bloco de codificação de Cr original da CU.
[0070] Além disso, o criptografador de vídeo 20 pode usar a partição de árvore quadrática para decompor os blocos residuais luma, Cb e Cr de uma CU em um ou mais blocos de transformada luma, Cb e Cr. Um bloco de transformada é um bloco (por exemplo, quadrado ou não quadrado) retangular de amostras nos quais a mesma transformada é aplicada. Uma unidade de transformada (TU) de uma CU pode compreender um bloco de transformada de amostras de luma, dois blocos de transformada correspondentes de amostras de croma e estruturas de sintaxe usadas para transformar as amostras de bloco de transformada. Desse modo, cada TU de uma CU pode ser associada a um bloco de transformada de luma, um bloco de transformada de Cb e um bloco de transformada de Cr. O bloco de transformada de luma associado à TU pode ser um sub-bloco do bloco residual de luma da CU. O bloco de transformada de Cb pode ser um sub-bloco do bloco residual de Cb da CU. O bloco de transformada de Cr pode ser um sub- bloco do bloco residual de Cr da CU. Nas imagens de monocroma ou nas imagens que têm três planos de cor separados, uma TU pode compreender um único bloco de transformada e estruturas de sintaxe usadas para transformar as amostras do bloco de transformada.
[0071] O criptografador de vídeo 20 pode aplicar uma ou mais transformadas a um bloco de transformada de luma de uma TU a fim de gerar um bloco de coeficiente de luma para a TU. Um bloco de coeficiente pode ser uma matriz bidimensional de coeficientes de transformada. Um coeficiente de transformada pode ser uma quantidade escalar. O criptografador de vídeo 20 pode aplicar uma ou mais transformadas a um bloco de transformada de Cb de uma TU a fim de gerar um bloco de coeficiente de Cb para a TU. O criptografador de vídeo 20 pode aplicar uma ou mais transformadas a um bloco de transformada de Cr de uma TU a fim de gerar um bloco de coeficiente de Cr para a TU.
[0072] Após gerar um bloco de coeficiente (por exemplo, um bloco de coeficiente de luma, um Cb bloco de coeficiente ou um Cr bloco de coeficiente), o criptografador de vídeo 20 pode quantizar o bloco de coeficiente. Em geral, a quantização se refere a um processo no qual os coeficientes de transformada são quantizados para reduzir possivelmente a quantidade de dados usados para representar os coeficientes de transformada, o que fornece uma compressão adicional. Após o criptografador de vídeo 20 quantizar um bloco de coeficiente, o criptografador de vídeo 20 pode criptar por entropia elementos de sintaxe que indicam os coeficientes de transformada quantizados. Por exemplo, o criptografador de vídeo 20 pode realizar Codificação Aritmética Binária Adaptativa Ao Contexto (CAB AC - Context-Adaptive Binary Arithmetic Coding) nos elementos de sintaxe que indicam os coeficientes de transformada quantizados.
[0073] O criptografador de vídeo 20 pode emitir um fluxo de bits que inclui uma sequência de bits que forma uma representação de imagens codificadas e dados associados. O fluxo de bits pode compreender uma sequência de unidades de camada de abstração de rede (NAL). Uma unidade de NAL é uma estrutura de sintaxe que contém uma indicação do tipo de dados na unidade de NAL e bytes e que contêm esses dados na forma de uma carga de sequência de bytes brutos (RBSP) intercalados conforme necessário com bits de prevenção de emulação. Cada uma das unidades de NAL inclui um cabeçalho de unidade de NAL e encapsula uma RBSP. O cabeçalho de unidade de NAL pode incluir um elemento de sintaxe que indica um código do tipo unidade de NAL. O código do tipo unidade de NAL especificado pelo cabeçalho de unidade de NAL de uma unidade de NAL indica o tipo da unidade de NAL. Uma RBSP pode ser uma estrutura de sintaxe que contém um número inteiro de bytes que é encapsulado dentro de uma unidade de NAL. Em alguns exemplos, uma RBSP inclui zero bits.
[0074] Diferentes tipos de unidades de NAL podem encapsular diferentes tipos de RBSPs. Por exemplo, um primeiro tipo de unidade de NAL pode encapsular uma RBSP para um ajuste de parâmetro de imagem (PPS), um segundo tipo de unidade de NAL pode encapsular uma RBSP para uma fatia codificada, um terceiro tipo de unidade de NAL pode encapsular uma RBSP para as SEI, e assim por diante. As unidades de NAL que encapsulam as RBSPs para dados de codificação de vídeo (em oposição às RBSPs para os ajustes de parâmetros e mensagens de SEI) podem ser denominadas de unidades de NAL de camada de codificação de vídeo (VCL).
[0075] O decodificador de vídeo 30 pode receber um fluxo de bits gerado pelo criptografador de vídeo 20. Além disso, o decodificador de vídeo 30 podem analisar o fluxo de bits para obter elementos de sintaxe do fluxo de bits. O decodificador de vídeo 30 pode reconstruir as imagens dos dados de vídeo com base, pelo menos parcialmente, nos elementos de sintaxe obtidos do fluxo de bits. O processo para reconstruir os dados de vídeo pode ser, em geral, recíproco ao processo realizado pelo criptografador de vídeo 20. Por exemplo, o decodificador de vídeo 30 pode usar vetores de movimento de PUs para determinar os blocos preditivos para as PUs de uma CU atual. Além disso, o decodificador de vídeo 30 pode quantizar, inversamente, os coeficientes de blocos associados às TUs da CU atual. O decodificador de vídeo 30 pode realizar transformadas inversas nos blocos coeficientes para reconstruir os blocos de transformada associados às TUs da CU atual. O decodificador de vídeo 30 pode reconstruir os blocos de codificação da CU atual adicionando-se as amostras dos blocos preditivos para as PUs da CU atual às amostras correspondentes dos blocos de transformada das TUs da CU atual. Através da reconstrução dos blocos de codificação para cada CU de uma imagem, o decodificador de vídeo 30 pode reconstruir a imagem.
[0076] Em alguns exemplos, o criptografador de vídeo 20 pode sinalizar as informações de movimento de uma PU com o uso de um modo de mescla ou de um modo de predição de vetor de movimento avançado (AM VP). Em outras palavras, em HEVC, há dois modos para a predição de parâmetros de movimento, sendo que um é o modo de mescla e o outro é o AM VP. A predição de movimento pode compreender a determinação de informações de movimento de uma unidade de vídeo (por exemplo, uma PU) com base em informações de movimento de uma ou mais outras unidades de vídeo. As informações de movimento de uma PU podem incluir vetor(es) de movimento da PU e índice(s) de referência da PU.
[0077] Quando o criptografador de vídeo 20 sinalizar as informações de movimento de uma PU atual com o uso de um modo de mescla, o criptografador de vídeo 20 gera uma lista de candidatos de mescla. Em outras palavras, o criptografador de vídeo 20 pode realizar um processo de construção de listra previsora de vetor de movimento. A lista de candidatos de mescla inclui um conjunto de candidatos de mescla que indicam as informações de movimento de PUs que são vizinhas, espacial ou temporalmente, à PU atual. Ou seja, no modo de mescla, é construída uma lista de candidatos de parâmetros de movimento (por exemplo, índices de referência, vetores de movimento, etc.) em que um candidato pode ser dos blocos vizinhos espaciais e temporais. Em alguns exemplos, os candidatos também podem incluir um candidato gerado artificialmente.
[0078] Adicionalmente, no do de mescla, o criptografador de vídeo 20 pode selecionar um candidato de mescla da lista de candidatos de mescla e pode usar as informações de movimento indicadas pelo candidato de mescla como as informações de movimento da PU atual. O criptografador de vídeo 20 pode sinalizar a posição na lista de candidatos de mescla do candidato de mescla selecionado. Por exemplo, o criptografador de vídeo 20 pode sinalizar os parâmetros de vetor de movimento selecionados transmitindose um índice na lista de candidatos. O decodificador de vídeo 30 pode obter, do fluxo de bits, o índice na lista de candidatos (isto é, um índice de lista de candidatos). Além disso, o decodificador de vídeo 30 pode gerar a mesma lista de candidatos de mescla e pode determinar, com base na indicação da posição do candidato de mescla selecionado, o candidato de mescla selecionado. Em seguida, o decodificador de vídeo 30 pode usar as informações de movimento do candidato de mescla selecionado para gerar os blocos preditivos para a PU atual. Ou seja, o decodificador de vídeo 30 pode determinar, com base, pelo menos parcialmente, no índice de lista de candidatos, um candidato selecionado na lista de candidatos, em que o candidato selecionado especifica o vetor de movimento para a PU atual. Dessa maneira, no lado do decodificador, uma vez que o índice é decodificado, todos os parâmetros de movimento do bloco correspondente em que os pontos de índice podem ser herdados pela PU atual.
[0079] O modo de pulo é semelhante ao modo de mescla. No modo de pulo, o criptografador de vídeo 20 e o decodificador de vídeo 30 geram e usam uma lista de candidatos de mescla da mesma maneira que o criptografador de vídeo 20 e o decodificador de vídeo 30 usam a lista de candidatos de mescla no modo de mescla. No entanto, quando o criptografador de vídeo 20 sinalizar as informações de movimento de uma PU atual com o uso do modo de pulo, o criptografador de vídeo 20 não sinalizar quaisquer dados residuais para a PU atual. Correspondentemente, o decodificador de vídeo 30 pode determinar, sem uso de dados residuais, um bloco preditivo para a PU com base em um bloco de referência indicado pelas informações de movimento de um candidato selecionado na lista de candidatos de mescla.
[0080] O modo de AMVP é semelhante ao modo de mescla pelo fato de que o criptografador de vídeo 20 pode gerar uma lista de candidatos e pode selecionar um candidato da lista de candidatos. No entanto, quando o criptografador de vídeo 20 sinalizar as informações de movimento de RefPicListX de uma PU atual com o uso do modo de AMVP, o criptografador de vídeo 20 pode sinalizar uma diferença de vetor de movimento RefPicListX (MVD) para a PU atual e um índice de referência de RefPicListX para a PU atual além de sinalizar um sinalizador de MVP de RefPicListX para a PU atual. O sinalizador de MVP de RefPicListX para a PU atual pode indicar a posição de um candidato de AMVP selecionado na lista de candidatos de AMVP. A MVD de RefPicListX para a PU atual pode indicar uma diferença entre um vetor de movimento de RefPicListX da PU atual e um vetor de movimento do candidato de AMVP selecionado. Dessa maneira, o criptografador de vídeo 20 pode sinalizar as informações de movimento de RefPicListX da PU atual sinalizando-se um sinalizador de previsor de vetor de movimento de RefPicListX (MVP), um valor de índice de referência de RefPicListX e uma MVD de RefPicListX. Em outras palavras, os dados no fluxo de bits que representam o vetor de movimento para a PU atual podem incluir dados que representam um índice de referência, um índice para uma lista de candidatos e uma MVD.
[0081] Adicionalmente, quando as informações de movimento de uma PU atual são sinalizadas com o uso do modo de AMVP, o decodificador de vídeo 30 pode obter, a partir do fluxo de bits, uma MVD para uma PU atual e para um sinalizador de MVP. O decodificador de vídeo 30 pode gerar a mesma lista de candidatos de AMVP e pode determinar, com base no sinalizador de MVP, o candidato de AMVP selecionado. O decodificador de vídeo 30 pode recuperar um vetor de movimento da PU atual adicionando-se a MVD ao vetor de movimento indicado pelo candidato de AMVP selecionado. Ou seja, o decodificador de vídeo 30 pode determinar, com base em um vetor de movimento indicado pelo candidato de AMVP selecionado e a MVD, o vetor de movimento da PU atual. Em seguida, o decodificador de vídeo 30 pode usar o vetor de movimento ou vetores de movimento recuperados da PU atual para gerar blocos preditivos para a PU atual.
[0082] Quando o decodificador de vídeo 30 gera uma lista de candidatos de AMVP para uma PU atual, o decodificador de vídeo 30 pode derivar um ou mais candidatos de AMVP com base nas informações de movimento de PUs (isto é, PUs espacialmente vizinhos) que cobrem as localizações que são espacialmente vizinhas ao à PU atual. Uma PU pode cobrir uma localização quando um bloco de predição da PU inclui a localização.
[0083] Um candidato em uma lista de candidatos de mescla ou uma lista de candidatos de AMVP que se baseia nas informações de movimento de uma PU que é temporariamente vizinha a uma PU atual (isto é, uma PU que está em um instante do tempo diferente da PU atual) pode ser denominado de TMVP. Ou seja, um TMVP pode ser usado para aprimorar a eficiência de codificação de HEVC e, diferente de outras ferramentas de codificação, o TMVP pode precisar acessar o vetor de movimento de um quadro em um armazenamento temporário de imagem decodificada, mais especificamente, em uma lista de imagens de referência.
[0084] O uso de TMVPs pode ser habilitado ou desabilitado em uma base de CVS por CVS (sequência de vídeos codificados), em uma base fatia por fatia ou em outra base. Um elemento de sintaxe (por exemplo, sps_temporal_mvp_enable_flag) em um SPS pode indicar se o uso de TMVPs está habilitado para uma CVS. Além disso, quando o uso de TMVPs é habilitado para uma CVS, o uso de TMVPs pode ser habilitado ou desabilitado para fatias particulares dentro da CVS. Por exemplo, um elemento de sintaxe (por exemplo, slice_temporal_mvp_enable_flag) em um cabeçalho de fatia pode indicar se o uso de TMVPs está habilitado para uma fatia. Desse modo, em uma fatia interprevista, quando o TMVP é habilitado para toda uma CVS (por exemplo, o sps_temporal_mvp_enable_flag em um SPS ajustado como 1), o slice_temporal_mvp_enable_flag é sinalizado no cabeçalho de fatia para indicar se o TMVP é habilitado para a atual fatia.
[0085] A fim de determinar um TMVP, um codificador de vídeo pode identificar primeiramente uma imagem de referência que inclui uma PU que está colocalizada com a PU atual. Em outras palavras, o codificador de vídeo pode identificar uma imagem colocalizada. Caso a atual fatia da atual imagem seja uma fatia B (isto é, uma fatia que tem permissão para incluir PUs interprevistas de maneira bidirecional), o criptografador de vídeo 20 pode sinalizar, em um cabeçalho de fatia, um elemento de sintaxe (por exemplo, colocalizados a partir do sinalizador 10) que indica se a imagem colocalizada é da RefPicList0 ou da RefPicList1. Em outras palavras, quando o uso de TMVPs é habilitado para uma fatia atual, e a fatia atual é uma fatia B (por exemplo, uma fatia que tem permissão para incluir as PUs interprevistas de maneira bidirecional), o criptografador de vídeo 20 pode sinalizar um elemento de sintaxe (por exemplo, colocalizado a partir do sinalizador 10) em um cabeçalho de fatia para indicar se a imagem colocalizada está na RefPicList0 ou na RefPicList1. Em outras palavras, a fim de conseguir um TMVP, primeiramente, uma imagem colocalizada deve ser identificada. Caso a imagem atual seja uma fatia B, uma colocalização do sinalizador 10 é sinalizada no cabeçalho de fatia para indicar se a imagem colocalizada é da RefPicList0 ou da RefPicList1.
[0086] Após o decodificador de vídeo 30 identificar a lista de imagens de referência que inclui a imagem colocalizada, o decodificador de vídeo 30 pode usar outro elemento de sintaxe (por exemplo, ref idx colocalizada), que pode ser sinalizado em um cabeçalho de fatia, para identificar uma imagem (isto é, a imagem colocalizada) na lista de imagens de referência identificada. Ou seja, após uma lista de imagens de referência ser identificada, ref idx colocalizada, sinalizada em um cabeçalho de fatia, a mesma é usada para identificar a imagem na lista de imagens de referência.
[0087] O codificador de vídeo pode identificar uma PU colocalizada verificando-se a imagem colocalizada. O TMVP pode indicar tanto as informações de movimento de uma PU direita inferior da CU que contém a PU colocalizada como as informações de movimento da PU direita inferior dentro das PUs centrais da CU que contém essa PU. Desse modo, tanto o movimento da PU direita inferior da CU que contém essa PU, como o movimento da PU direita inferior dentro das PUs centrais da CU que contém essa PU são usados. A PU direita inferior da CU que contém a PU colocalizada pode ser uma PU que cobre uma localização imediatamente abaixo e à direita de uma amostra direita inferior de um bloco de predição da PU. Em outras palavras, o TMVP pode indicar as informações de movimento de uma PU que está na imagem de referência e que cobre uma localização que está colocalizada com um canto direito inferior da PU atual, ou o TMVP pode indicar as informações de movimento de uma PU que está na imagem de referência e que cobre uma localização que é colocalizada com um centro da PU atual.
[0088] Quando os vetores de movimento identificados pelo processo acima (isto é, vetores de movimento de um TMVP) são usados para gerar um candidato de movimento para o modo de mescla ou para o modo de AMVP, o codificador de vídeo pode escalar os vetores de movimento com base na localização temporal (refletida pelo valor de POC). Por exemplo, um codificador de vídeo pode aumentar magnitude de um vetor de movimento em quantidades maiores quando uma diferença entre os valores de POC de uma imagem atual e uma imagem de referência é maior que quando uma diferença entre os valores de POC da imagem atual e a imagem de referência for menor.
[0089] O índice-alvo de referência de todas as possíveis listas de imagens de referência para o candidato de mesclagem temporal derivada de um TMVP pode ser sempre ajustado como 0. No entanto, para o AMVP, o índice-alvo de referência de todas as imagens de referência possíveis é ajustado igual ao índice de referência decodificado. Em outras palavras, o índice-alvo de referência de todas as possíveis listas de imagens de referência para o candidato de mesclagem temporal derivado do TMVP é sempre ajustado como 0 ao passo que, para o AMVP, é sempre ajustado igual ao índice de referência decodificado. Em HEVC, um SPS pode incluir um sinalizador (por exemplo, o sps_temporal_mvp_enable_flag) e o cabeçalho de fatia pode incluir um sinalizador (por exemplo, pic_temporal_mvp_enable_flag) quando sps_temporal_mvp_enable_flag for igual a 1. Quando tanto o pic_temporal_mvp_enable_flag quanto um temporal_id forem iguais a 0 para uma imagem particular, nenhum vetor de movimento das imagens antes dessa imagem particular na ordem de codificação será usado como um TMVP na decodificação da imagem particular ou de uma imagem após a imagem particular na ordem de codificação.
[0090] Na próxima seção, serão discutidas técnicas de codificação de múltiplas vistas (por exemplo, como em H.264/MVC) e de múltiplas vistas mais profundidade (por exemplo, como em 3D-HEVC). Inicialmente, serão discutidas as técnicas de MVC. Conforme verificado acima, a MVC é uma extensão de codificação de múltiplas vistas de ITU-T H.264/AVC. Em MVC, os dados para uma pluralidade de vistas são codificados em uma ordem de primeira vez e, consequentemente, a disposição de ordem de codificação é denominada de codificação de primeiro no tempo. Em particular, os componentes de vista (ou seja, imagens) para cada uma dentre a pluralidade de vistas em um instante do tempo em comum podem ser codificados, em seguida, outro conjunto de componentes de vista para um instante do tempo diferente pode ser codificado, e assim por diante. Uma unidade de acesso pode incluir imagens codificadas de todas as vistas para um instante do tempo de saída. Deve-se entender que a ordem de codificação de unidades de acesso não é necessariamente idêntica à ordem de saída (ou de exibição).
[0091] Uma ordem de codificação MVC típica (isto é, ordem de fluxo de bits) é mostrada na Figura 2. A disposição de ordem de codificação é denominada de codificação de primeiro no tempo. Observa-se que a ordem de codificação de unidades de acesso pode não ser idêntica à ordem de saída ou de exibição. Na Figura 2, S0 a S7 se referem, cada uma, a diferentes vistas do vídeo de múltiplas vistas. T0 a T8 representam, cada um, um instante do tempo de saída. Uma unidade de acesso pode incluir as imagens codificadas de todas as vistas para um instante do tempo de saída. Por exemplo, uma primeira unidade de acesso pode incluir todas as vistas S0 a S7 para o instante do tempo T0, uma segunda unidade de acesso pode incluir todas as vistas S0 a S7 para o instante do tempo T1, e assim por diante.
[0092] Para propósitos de brevidade, a revelação pode usar as seguintes definições:
[0093] componente de vista: Uma representação codificada de uma vista em uma única unidade de acesso. Quando uma vista inclui representações codificadas tanto de textura quanto de profundidade, um componente de vista consiste em um componente de vista de textura e um componente de vista de profundidade.
[0094] componente de vista de textura: Uma representação codificada da textura de uma vista em uma única unidade de acesso.
[0095] componente de vista de profundidade: Uma representação codificada da profundidade de uma vista em uma única unidade de acesso.
[0096] Na Figura 2, cada uma dentre as vistas inclui conjuntos de imagens. Por exemplo, a vista S0 inclui um conjunto de imagens 0, 8, 16, 24, 32, 40, 48, 56 e 64, a vista S1 inclui um conjunto de imagens 1, 9, 17, 25, 33, 41, 49, 57 e 65, e assim por diante. Para codificação de vídeo 3D, por exemplo, 3D-HEVC, cada imagem pode incluir duas imagens de componente: uma imagem de componente é denominada de componente de vista de textura e a outra imagem de componente é denominada de componente de vista de profundidade. O componente de vista de textura e o componente de vista de profundidade dentro de um conjunto de imagens de uma vista pode ser considerado como correspondente um ou ao outro. Por exemplo, o componente de vista de textura dentro de um conjunto de imagens de uma vista é considerado como correspondente ao componente de vista de profundidade dentro do conjunto das imagens da vista, e vice-versa (isto é, o componente de vista de profundidade correspondente ao seu componente de vista de textura no conjunto, e vice-versa). Conforme usado nesta revelação, um componente de vista de textura que corresponde a um componente de vista de profundidade pode ser considerado como o componente de vista de textura, em que o componente de vista de profundidade é parte de uma mesma vista de uma única unidade de acesso.
[0097] O componente de vista de textura inclui o real conteúdo de imagem que é exibido. Por exemplo, o componente de vista de textura pode incluir componentes de luma (Y) e de croma (Cb e Cr). O componente de vista de profundidade pode indicar profundidades relativas dos pixels no componente de vista de textura correspondentes do mesmo. Como um exemplo, o componente de vista de profundidade é uma imagem em escala de cinza que inclui apenas valores de luma. Em outras palavras, o componente de vista de profundidade pode não transportar qualquer conteúdo de imagem, porém, em vez disso, pode fornecer uma medida das profundidades relativas dos pixels no componente de vista de textura.
[0098] Por exemplo, um pixel inteiramente branco no componente de vista de profundidade indica que o pixel ou pixels correspondentes do mesmo no componente de vista de textura correspondentes está mais próxima da perspectiva do espectador, e um pixel inteiramente preto no componente de vista de profundidade indica que o pixel ou pixels correspondentes do mesmo no componente de vista de textura correspondentes está mais distante da perspectiva do espectador. As várias sombras de cinza entre preto e branco indicam diferentes níveis de profundidade. Por exemplo, um pixel muito cinza no componente de vista de profundidade indica que pixel correspondentes do mesmo no componente de vista de textura está mais distante que um pixel levemente cinza no componente de vista de profundidade. Devido ao fato de que apenas a escala de cinza é necessária para identificar a profundidade de pixels, o componente de vista de profundidade não precisa incluir componentes de croma, uma vez que os valores de cor para o componente de vista de profundidade podem não ter propósito algum.
[0099] O componente de vista de profundidade que usa apenas valores de luma (por exemplo, valores de intensidade) para identificar a profundidade é fornecido para propósitos de ilustração e não deve ser considerado como limitativo. Em outros exemplos, qualquer técnica pode ser utilizada para indicar profundidades relativas dos pixels no componente de vista de textura.
[0100] Uma estrutura de predição de MVC típica (incluindo tanto a predição de interimagem dentro de cada vista quanto a predição entre vistas) para a codificação de vídeo de múltiplas vistas é mostrada na Figura 3. As direções de predição são indicadas por setas, em que o objeto apontado usa o objeto de apontamento como a referência de predição. Em MVC, predição entre vistas é suportada pela compensação de movimento de disparidade, que usa a sintaxe da compensação de movimento H.264/AVC, porém, permite uma imagem em uma vista diferente a ser usada como uma imagem de referência.
[0101] No exemplo da Figura 3, as oito vistas (que têm IDs de vista “S0” a “S7”) são ilustradas, e as doze localizações temporais (“T0” a “T11”) são ilustradas para cada vista. Ou seja, cada fileira na Figura 3 corresponde a uma vista, ao passo que cada coluna indica uma localização temporal.
[0102] Embora a MVC tenha uma então chamada vista de base, que é passível de decodificação por decodificações H.264/AVC, e pares de vista estéreos podem ser suportados também pela MVC, a vantagem da MVC é que pode suportar um exemplo que usa mais que duas vistas como uma entrada de vídeo 3D e decodifica esse vídeo 3D representado pelas múltiplas vistas. Um renderizador de um cliente que tem um decodificador de MVC pode esperar o conteúdo de vídeo 3D com múltiplas vistas.
[0103] As imagens na Figura 3 são indicadas na interseção de cada fileira e cada coluna. O padrão H.264/AVC pode usar o termo quadro para representar uma porção do vídeo. Esta revelação pode usar o tempo imagem e quadro de maneira intercambiável.
[0104] As imagens na Figura 3 são ilustradas com o uso de um bloco incluindo uma letra, sendo que a letra indica se a imagem correspondente é intracodificada (ou seja, uma imagem I), ou uma intercodificada em uma direção (ou seja, como uma imagem P) ou em múltiplas direções (ou seja, como uma imagem B). Em geral, as previsões são indicadas por setas, em que as imagens apontadas usam a imagem e apontamento para referência de predição. Por exemplo, a imagem P da vista S2 em uma localização temporal T0 é prevista a partir da imagem I da vista S0 em uma localização temporal T0.
[0105] Conforme a criptação de vídeo de única vista, as imagens de uma sequência de vídeos de codificação de vídeo de múltiplas vistas podem ser criptadas de maneira prevista em relação às imagens em diferentes localizações temporais. Por exemplo, a imagem b da vista S0 na localização temporal T1 tem uma seta apontada para a mesma a partir da imagem I da vista S0 na localização temporal T0, o que indica que a imagem b é prevista a partir da imagem I. No entanto, adicionalmente, no contexto de criptação de vídeo de múltiplas vistas, as imagens podem ser previstas entre vistas. Ou seja, um componente de vista pode usar os componentes de vista em outras vistas para referência. Em MVC, por exemplo, a predição entre vistas é notada como se o componente de vista em outra vista fosse uma referência de interpredição. As referências entre vistas potenciais são sinalizadas na extensão de MVC de Conjunto de Parâmetros de Sequência (SPS) e podem ser modificadas pelo processo de construção de lista de imagens de referência, o que possibilita o ordenamento flexível das referências de interpredição ou de predição entre vistas. A predição entre vistas é também um recurso de uma extensão com múltiplas vistas proposta de HEVC, incluindo 3D-HEVC (múltiplas vistas mais profundidade).
[0106] A Figura 3 fornece vários exemplos de predição entre vistas. As imagens da vista S1, no exemplo da Figura 3, são ilustradas como sendo previstas a partir das imagens em diferentes localizações temporais da vista S1, assim como, previstas entre vistas a partir das imagens das vistas S0 e S2 nas mesmas localizações temporais. Por exemplo, a imagem b da vista S1 na localização temporal T1 é prevista a partir de cada uma dentre as imagens b da vista S1 nas localizações temporais T0 e T2, assim como, as imagens b das vistas S0 e S2 na localização temporal T1.
[0107] Em alguns exemplos, a Figura 3 pode ser vista como ilustrando os componentes de vista de textura. Por exemplo, as imagens I, P, B e b ilustradas na Figura 2 podem ser consideradas como componentes de vista de textura para cada uma das vistas. Em conformidade com as técnicas descritas nesta revelação, para cada um dos componentes de vista de textura ilustrados na Figura 3 há um componente de vista de profundidade correspondente. Em alguns exemplos, os componentes de vista de profundidade podem ser previstos de maneira semelhante àquela ilustradas na Figura 3 para os componentes de vista de textura correspondentes.
[0108] A codificações de duas vistas também podem ser suportadas em MVC. Uma das vantagens de MVC é que um criptografador de MVC pode obter mais que duas vistas como uma entrada de vídeo 3D e um decodificador de MVC pode decodificar tal representação de múltiplas vistas. Como tal, qualquer renderizador com um decodificador de MVC pode esperar conteúdos de vídeo 3D com mais que duas vistas.
[0109] Em MVC, a predição entre vistas é permitida dentre as imagens na mesma unidade de acesso (isto é, com o mesmo instante do tempo). Durante uma imagem em uma dentre as vistas de não base, uma imagem pode ser adicionada a uma lista de imagens de referência caso esteja em uma vista diferente, porém, dentro do mesmo instante do tempo. Uma imagem de referência entre vistas pode ser colocada em qualquer posição de uma lista de imagens de referência, exatamente como qualquer imagem de referência de interpredição. Conforme mostrado na Figura 3, um componente de vista pode usar os componentes de vista em outras vistas para referência. Em MVC, a predição entre vistas é notada como se o componente de vista em outra vista fosse uma referência de interpredição.
[0110] No contexto de codificação de vídeo de múltiplas vistas, em geral, há dois tipos de vetores de movimento. Um é denominado como um vetor de movimento normal. Os pontos de vetor de movimento normal às imagens de referência temporal e a interpredição temporal correspondente é a predição compensada por movimento (MCP). O outro vetor de movimento é um vetor de movimento de disparidade (DMV). Os pontos de DMV para imagens em uma vista diferente (isto é, imagens de referência entre vistas) e a interpredição correspondente é predição compensada por disparidade (DCP).
[0111] Outro tipo de formato de codificação de vídeo de múltiplas vistas apresenta o uso de valores de profundidade (por exemplo, como em 3D-HEVC). Para o formato de dados de profundidade mais vídeo de múltiplas vistas (MVD), que é popular para televisão 3D e vídeos de ponto de vista livre, imagens de textura e mapas de profundidade podem ser codificado com imagens de textura de múltiplas vistas independentemente. A Figura 4 ilustra o formato de dados MVD com uma imagem de textura e seu mapa de profundidade por amostra associado. A faixa de profundidade pode ser restringida para estar na faixa de distância de znear mínimo e z&r máximo a partir da câmera para os pontos 3D correspondentes.
[0112] Parâmetros de câmera e valores de faixa de profundidade podem ser úteis para componentes de vista decodificada por processamento antes da renderização em um visor 3D. Portanto, uma mensagem de informações de intensificação suplementar especial (SEI) é definida para a atual versão de H.264/MVC, isto é, informações SEI de aquisição de múltiplas vistas, que inclui informações que especifica vários parâmetros do ambiente de aquisição. No entanto, não há sintaxes especificadas em H.264/MVC para indicar as informações relacionadas à faixa de profundidade.
[0113] A partição de movimento assimétrico (AMP) e tamanhos de bloco de compensação por movimento de HEVC serão agora discutidos. Em HEVC, os blocos de codificação intercodificados podem ser divididos em uma, duas, ou quatro partições. Vários formatos de tais partições são possíveis. Possibilidades de partição exemplificativas para blocos de codificação interprevistos são retratados na Figura 5.
[0114] A fileira superior de partições na Figura 5 ilustra as denominadas partições assimétricas. Uma partição NxN é simplesmente um bloco de codificação que não foi dividido. Uma partição N/2xN é um bloco de codificação dividido em duas partições retangulares verticais. De modo similar, uma partição NxN/2 é um bloco de codificação dividido em duas partições horizontais retangulares. Uma partição N/2xN/2 é um bloco de codificação dividido em quatro partições quadradas iguais.
[0115] Os menores tipos de quatro partições na Figura 5 são denominados como partições assimétricas e podem ser usados na partição de movimento assimétrico (AMP) para interpredição. Uma partição do modo AMP tem a altura ou largura N/4 e largura ou altura N, respectivamente, e a outra partição consiste no resto do CB tendo uma altura ou largura de 3N/4 e largura ou altura N. Cada partição intercodificada é atribuída um ou dois vetores de movimento e índices de imagem de referência (isto é, um vetor de movimento e índice de referência para predição uni-direcional e dois vetores de movimento e índices de referência para predição bidirecional). Em alguns exemplos, para minimizar a largura de banda de memória de pior caso, partições de tamanho 4x4 não são permitidos para interpredição e partições de tamanhos 4x8 e 8x4 são restringidas a codificação unipreditiva que é baseada em uma lista de dados preditivos.
[0116] Conforme será discutido em mais detalhes abaixo, esta revelação descreve técnicas para AMP quando usadas em conjunto com técnicas de predição de 3D-HEVC, incluindo predição de síntese de vista retrógrada (BVSP).
[0117] A seguir, é descrita a lista de candidatos de mescla em HEVC. Por exemplo, a lista de candidatos de mescla pode ser construída com as seguintes etapas. Para candidatos de mesclagem espacial, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode derivar até quatro candidatos de vetor de movimento espacial a partir de cinco blocos vizinhos espaciais, conforme é ilustrado na Figura 6.
[0118] A ordem na qual o criptografador de vídeo 20 e decodificador de vídeo 30 pode avaliar os blocos vizinhos espaciais é a seguinte: esquerda (A1), superior (B1), superior direita (B0), inferior esquerda (A0), e superior esquerda (B2), conforme mostrado na Figura 6. Em alguns exemplos, um processo de remoção pode ser aplicado para remover os candidatos de vetor de movimento que tem informações de movimento idêntico (por exemplo, vetores de movimento e índices de referência). Por exemplo, os vetores de movimento e índices de referência de B1 podem ser comparados aos vetores de movimento e índices de referência de A1, os vetores de movimento e índices de referência de B0 podem ser comparados aos vetores de movimento e índices de referência de B1, os vetores de movimento e índices de referência de A0 podem ser comparados aos vetores de movimento e índices de referência de A1, e os vetores de movimento e índices de referência de B2 podem ser comparados aos vetores de movimento e índices de referência tanto de B1 quanto de A1. Um dos dois candidatos que têm informações de movimento idêntico pode ser então removido da lista de candidatos de vetor de movimento. Se já houver quatro candidatos disponíveis após o processo de remoção, o candidato B2 não é inserido na lista de candidatos de mescla.
[0119] Um candidato a previsor de vetor de movimento temporal colocalizado (TMVP) de uma imagem de referência, se permitido e disponível, é adicionado à lista de candidatos de vetor de movimento após os candidatos de vetor de movimento espacial.
[0120] Se uma lista de candidatos de vetor de movimento não for completa (por exemplo, tiver menos do que um número predeterminado de inserções, um ou mais candidatos de vetor de movimento artificial podem ser gerados e inseridos ao fim da lista de candidatos de mescla. Tipos exemplificativos de candidatos de vetor de movimento artificial incluem candidatos de mesclagem bipreditiva combinados derivados somente para fatias B, e nenhum candidatos de mesclagem de vetor de movimento se não houver candidatos de mesclagem bipreditiva suficientes (ou outro tipo de candidatos de vetor de movimento artificial) para fornecer o número predeterminado de candidatos de vetor de movimento.
[0121] Quando uma fatia atual for uma fatia B, o processo de derivação de candidatos de mesclagem bipreditiva combinados é invocado. Para cada par de candidatos que já estão na lista de candidatos e têm informações de movimento necessárias, candidatos de vetor de movimento bipreditivos combinados (com um índice indicado por combIdx) são derivados com o uso de uma combinação do vetor de movimento do primeiro candidato (com índice de candidato de mescla igual a l0CandIdx) em referência a uma imagem na lista 0 (se estiver disponível), e o vetor de movimento de um segundo candidato (com índice de candidato de mescla igual a 11CandIdx) em referência a uma imagem na lista 1 (se estiver disponível e tanto a imagem de referência como o vetor de movimento é diferente do primeiro candidato).
[0122] A Figura 7 é uma tabela que indica uma especificação exemplificativa de l0CandIdx e 11CandIdx em 3D-HEVC. Por exemplo, a Figura 7 ilustra as definições de l0CandIdx e 11CandIdx correspondentes a combIdx.
[0123] Para combIdx sendo 0 ... 11, o processo de geração de candidatos de vetor de movimento bipreditivos combinados é terminado quando uma das seguintes condições é verdadeira: (1) combIdx é igual a (numOrigMergeCand * (numOrigMergeCand - 1)) em que numOrigMergeCand indica o número de candidatos na lista de mescla antes de invocar esse processo; (2) o número de total candidatos (incluindo candidatos de mesclagem bipreditiva combinados recém- gerados) na lista de mescla é igual a MaxNumMergeCand.
[0124] Essa seção descreve a derivação de zero candidatos de mesclagem de vetor de movimento. Para cada candidato, zero vetores de movimento e um índice de imagem de referência é ajustado de 0 para o número de índice de imagem de referência disponível menos 1. Se ainda houver menos candidatos do que o número máximo de candidatos de vetor de movimento de mescla (por exemplo, conforme indicado pelo MaxNumMergeCand elemento de sintaxe), a zero índice de referência e vetor de movimento é inserido até que o número total de candidatos seja igual a MaxNumMergeCand.
[0125] A seguir, é descrita a restrição de tamanho de compensação de movimento em HEVC. Para minimizar a largura de banda de memória de pior caso, as partições de tamanho 4x4 não são permitidas para interpredição e partições de tamanhos 4x8 e 8x4 são restringidas à codificação unipreditiva.
[0126] Para satisfazer tal restrição mencionada acima, quando o tamanho de PU atual for igual a 8x4 ou 4x8, o candidato de mesclagem bipreditivo espacial/temporal/combinado gerado, se o mesmo for associado ao modo de bipredição, a PU atual deve ser apagada para usar unipredição modificando-se a direção de predição para a lista 0, e o índice de imagem de referência e vetor de movimento correspondente para RefPicList1 para -1 e (0, 0), respectivamente.
[0127] Conforme mencionado acima, um 3D-HEVC está em desenvolvimento. 3D-HEVC pode aprimorar a eficiência de codificação com o uso de predição de movimento entre vistas e predição residual entre vistas. Em outras palavras, para aprimorar adicionalmente a eficiência de codificação, duas novas tecnologias denominadas “predição de movimento entre vistas” e “predição residual entre vistas” foram adotadas no software de referência. Na predição de movimento entre vistas, um codificador de vídeo (por exemplo, criptografador de vídeo 20 ou decodificador de vídeo 30) pode determinar (isto é, prever) as informações de movimento de uma PU atual com base nas informações de movimento de uma PU em uma vista diferente da PU atual. Na predição residual entre vistas, um codificador de vídeo pode determinar blocos residuais de uma CU atual com base em residual data em uma vista diferente do que a CU atual.
[0128] A derivação de vetor de disparidade baseado em bloco vizinho (NBDV) em 3D-HEVC será agora discutido. A derivação de NBDV é usada como uma técnica de derivação de vetor de disparidade em 3D-HEVC devido ao fato de que 3D-HEVC usa a ordem de codificação de primeira textura para todas as vistas. Visto que o mapa de profundidade correspondente não está disponível para uma imagem de textura atualmente codificada, em NBDV, um vetor de disparidade é derivado dos blocos vizinhos. Em algumas propostas para o projeto de 3D-HEVC, o vetor de disparidade derivado do processo de derivação de NBDV poderia ser adicionalmente refinado recuperando-se os dados de profundidade correspondentes a uma vista de textura de referência.
[0129] O 3D-HEVC inicialmente adotou as técnicas de derivação de NBDV propostas no documento JCT3V- A0097 (3D-CE5.h: Disparity vector generation results, L. Zhang, Y. Chen, M. Karczewicz (Qualcomm)). Vetores de disparidade implícitos foram incluídos com um NBDV simplificado no documento JCTVC-A0126 (3D-CE5.h: Simplification of disparity vector derivation for HEVC-based 3D video coding, J. Sung, M. Koo, S. Yea (LG)). Adicionalmente, em JCT3V-B0047 (3D-CE5.h related: Improvements for disparity vector derivation, J. Kang, Y. Chen, L. Zhang, M. Karczewicz (Qualcomm)), as técnicas de derivação de NBDV foram adicionalmente simplificadas removendo-se os vetores de disparidade implícitos armazenados no armazenamento temporário de imagem decodificada, mas também aprimorou um ganho de codificação com a seleção de imagem de acesso aleatório (RAP). Técnicas adicionais para derivação de NBDV foram descritas no documento JCT3V-D0181 (CE2: CU-based Disparity Vector Derivation em 3D-HEVC, J. Kang, Y. Chen, L. Zhang, M. Karczewicz (Qualcomm)).
[0130] Um vetor de disparidade (DV) é usado como um estimador do deslocamento entre duas vistas. Devido ao fato de que os blocos vizinhos compartilham quase as mesmas informações de movimento/disparidade na codificação de vídeo, o bloco atual pode usar as informações de vetor de movimento em blocos vizinhos como um previsor satisfatório. Seguindo essa ideia, o processo de derivação de NBDV usa as informações de disparidade vizinha para estimar o vetor de disparidade em diferentes vistas.
[0131] Para implantar NBDV, o criptografador de vídeo 20 inicialmente define diversos blocos vizinhos espaciais e temporais. O criptografador de vídeo 20 então verifica cada um dos blocos vizinhos em uma ordem predefinida determinado pela prioridade da correlação entre o bloco atual e o bloco candidato. Uma vez que um vetor de movimento de disparidade (isto é, o vetor de movimento aponta para uma imagem de referência entre vistas) é constatados nos candidatos, o criptografador de vídeo 20 converte o vetor de movimento de disparidade para um vetor de disparidade e o índice de ordem de vista associada é também retornado. Dois conjuntos de blocos vizinhos são utilizados. Um conjunto inclui blocos vizinhos espaciais e o outro conjunto inclui blocos vizinhos temporais.
[0132] Em propostas recentes para 3D-HEVC, dois blocos vizinhos espaciais são usados na derivação de NBDV. Os blocos vizinhos espaciais são os blocos vizinhos esquerdo e superior em relação à unidade de codificação (CU) atual 90, conforme indicado por A1 e B1, respectivamente, na Figura 8. Deve-se observar que os blocos vizinhos retratados na Figura 8 estão no mesmo local que alguns dos blocos vizinhos usados no modo de mescla em HEVC. Portanto, nenhum acesso de memória adicional é exigido. No entanto, deve-se entender que os blocos vizinhos em outros locais em relação à CU atual 90 também podem ser usados.
[0133] Para verificar blocos vizinhos temporais, o criptografador de vídeo 20 primeiro realiza um processo de construção para uma lista de imagens candidatas. Até duas imagens de referência a partir de uma vista atual podem ser tratadas como imagens de candidato. O criptografador de vídeo 20 primeiro adiciona uma imagem de referência colocalizada à lista de imagens candidatas, seguida pelo resto de imagens de candidato na ordem ascendente de índice de referência. Quando as imagens de referência com o mesmo índice de referência em ambas as listas de imagens de referência estão disponíveis, a imagem de referência na mesma lista de imagens de referência como a imagem colocalizada precede a outra imagem de referência que tem o mesmo índice de referência. Para cada imagem candidata na lista de imagens candidatas, o criptografador de vídeo 20 determina o bloco da região colocalizada que cobre a posição central como o bloco vizinho temporal.
[0134] Quando um bloco é codificado com predição de movimento entre vistas, um vetor de disparidade pode ser derivado para selecionar um bloco correspondente em uma vista diferente. O vetor de disparidade derivado na predição de movimento entre vistas processo é denominado como um vetor de disparidade implícito (IDV ou também conhecido como vetor de disparidade derivado). Embora o bloco seja codificado com predição de movimento, o vetor de disparidade derivado não é descartado para o propósito de codificar um bloco seguinte.
[0135] Em um projeto do HTM, durante o processo de derivação de NBDV, um codificador de vídeo (por exemplo, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30) é configurado para verificar os vetores de movimento de disparidade nos blocos vizinhos temporais, vetores de movimento de disparidade nos blocos vizinhos espaciais, e então os IDVs, na ordem. Uma vez que o vetor de movimento de disparidade ou IDV é constatado, o processo é terminado.
[0136] O refinamento do processo de derivação de NBDV (NBDV-R) acessando-se informações de profundidade será agora discutido. Quando um vetor de disparidade é derivado do processo de derivação de NBDV, o vetor de disparidade derivado pode ser adicionalmente refinado recuperando-se os dados de profundidade a partir do mapa de profundidade da vista de referência. O processo de refinamento pode incluir as seguintes técnicas:
[0137] a) Localizar um bloco de profundidade correspondente pelo vetor de disparidade derivado na vista de profundidade de referência anteriormente codificada, tal como a vista de base; o tamanho do bloco de profundidade correspondente é igual ao da PU atual.
[0138] b) Selecionar um valor de profundidade a partir de quatro pixels de canto do bloco de profundidade correspondente e converter o valor de profundidade ao componente horizontal do vetor de disparidade refinado. O componente vertical do vetor de disparidade é inalterado.
[0139] Observe que, em alguns exemplos, o vetor de disparidade refinado pode ser usado para predição de movimento entre vistas enquanto o vetor de disparidade não refinado pode ser usado para predição residual entre vistas. Adicionalmente, o vetor de disparidade refinado pode ser armazenado como o vetor de movimento de uma PU se a PU for codificada com modo de predição de síntese de vista retrógrada. Em algumas propostas para 3D-HEVC, o componente de vista de profundidade de vista de base pode ser acessado independente do valor de índice de ordem de vista derivado do processo de derivação de NBDV.
[0140] As técnicas de predição de síntese de vista retrógrada (BVSP) em 3D-HEVC serão agora discutidas. Uma abordagem de BVSP exemplificativa, conforme proposto por D. Tian, et al. “CEl.h: Backward View Synthesis Prediction Using Neighboring Blocks”, JCT3V-C0152, disponível de http://phenix.it- sudparis.eu/jct2/doc_end_user/current_document.php?id=594, foi adotado na 3a reunião de JCT-3V. A ideia básica de BVSP é similar à predição de síntese de vista baseada em bloco em 3D-AVC. Ambas essas duas técnicas usam predição de síntese de vista de encurvamento retrógrado e baseada em bloco para evitar transmitir as diferenças de vetor de movimento e usar vetores de movimento mais precisos. Os detalhes de implantação de BVSP em 3D-HEVC e 3D-AVC são diferentes devido às diferentes plataformas.
[0141] Em 3D-HEVC, o modo de BVSP é suportado para um bloco intercodificado que é codificado em qualquer modo de passagem ou mescla. Em uma proposta exemplificativa para 3D-HEVC, o modo de BVSP não é permitido para um bloco codificado no modo de predição de vetor de movimento avançado (AMVP). Em vez de transmitir uma sinalização para indicar o uso de modo de BVSP, o criptografador de vídeo 20 pode ser configurado para adicionar um candidato de mesclagem adicional (isto é, candidato de mesclagem de BVSP) à lista de candidatos de mescla e cada candidato é associado a uma sinalização de BVSP. Quando o índice de mescla decodificada corresponde a um candidato de mesclagem de BVSP, o índice de mescla decodificada indica que a unidade de predição (PU) atual usa o modo de BVSP. Para cada sub-bloco dentro da PU atual, um vetor de movimento de disparidade pode ser derivado convertendo-se um valor de profundidade em uma vista de referência de profundidade.
[0142] O ajuste de sinalizações de BVSP é definido conforme a seguir. Quando um bloco vizinho espacial usado para derivar um candidato de mesclagem espacial é codificado com modo de BVSP, as informações de movimento associadas do candidato de mesclagem espacial é herdado pelo bloco atual, como no modo de mesclagem convencional. Adicionalmente, esse candidato de mesclagem espacial é associado a uma sinalização de BVSP igual a 1 (isto é, indicando que o candidato de mesclagem espacial foi codificado com modo de BVSP). Para o candidato de mesclagem de BVSP recém-introduzido, a sinalização de BVSP é ajustada para 1. Para todos os outros candidatos de mesclagem, as sinalizações de BVSP associadas são ajustadas para 0.
[0143] Conforme discutido acima, em 3D-HEVC, o criptografador de vídeo 20 pode ser configurado para derivar e inserir um novo candidato, ou seja, o candidato de mesclagem de BVSP, à lista de candidatos de mescla. Os índices de imagem de referência correspondentes e os vetores de movimento são ajustados pelo método a seguir.
[0144] O primeiro criptografador de vídeo 20 pode ser configurado para obter o índice de vista indicado pelo elemento de sintaxe de índice de vista (por exemplo, refVIdxLX em 3D-HEVC) do vetor de disparidade derivado do processo de derivação de NBDV. O criptografador de vídeo 20 também pode ser configurado para obter a lista de imagens de referência (por exemplo, RefPicListX (tanto RefPicList0 como RefPicList1)) que é associada à imagem de referência com o índice de ordem de vista igual a refVIdxLX. O criptografador de vídeo 20 então usa o índice de imagem de referência e o vetor de disparidade correspondente obtido a partir do processo de derivação de NBDV como as informações de movimento do candidato de mesclagem de BVSP in RefPicListX (isto é, tanto RefPicList0 como RefPicList1).
[0145] Se a fatia atual for a fatia B, o criptografador de vídeo 20 verifica a disponibilidade de uma imagem de referência entre vistas com o índice de ordem de vista indicado por refVIdxLY não igual a refVIdxLX na lista de imagens de referência diferente de RefPicListX, isto é, RefPicListY com Y sendo 1-X. Se tal imagem de referência entre vistas diferente for constatada, o criptografador de vídeo 20 realiza predição de síntese de vista bipreditiva. O criptografador de vídeo 20 pode ser adicionalmente configurado para usar o índice de imagem de referência correspondente da imagem de referência entre vistas diferente e o vetor de disparidade escalonado a partir do processo de derivação de NBDV como as informações de movimento do candidato de mesclagem de BVSP em RefPicListY. O bloco de profundidade a partir da vista que tem um índice de ordem de vista igual a refVIdxLX é usado como as informações de profundidade do bloco atual (no caso de ordem de codificação de primeira textura). O criptografador de vídeo 20 sintetiza as duas diferentes imagens de referência entre vistas (uma de cada lista de imagens de referência) por meio de um processo de encurvamento retrógrado e pondera adicionalmente as imagens de referência sintetizadas para alcançar o previsor de BVSP final.
[0146] Para tipos de fatia diferentes da fatia B (por exemplo, uma fatia P), o criptografador de vídeo 20 aplica predição de síntese de vista unipreditiva com RefPicListX como a lista de imagens de referência para predição.
[0147] Em 3D-HTM, a primeira codificação de textura é aplicada em condições de teste comuns. Visto que o componente de textura de uma vista é codificado antes do componente de profundidade, o componente de profundidade de não base correspondente está indisponível ao decodificar um componente de textura de não base. Portanto, o decodificador de vídeo 30 pode ser configurado para estimar informações de profundidade, e então usar as informações de profundidade estimadas para realizar BVSP. De modo a estimar as informações de profundidade para um bloco, é proposto primeiro derivar um vetor de disparidade a partir de blocos vizinhos (por exemplo, com o uso do processo de derivação de NBDV), e então usar o vetor de disparidade derivado para obter um bloco de profundidade a partir da vista de referência.
[0148] A Figura 9 ilustra técnicas exemplificativas para localizar um bloco de profundidade a partir da vista de referência, e então usar o bloco de profundidade para predição de BVSP. Inicialmente, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem utilizar um vetor de disparidade 104 associado ao bloco vizinho 102. Ou seja, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode acessar informações de vetor de disparidade a partir de blocos vizinhos já criptografados (tal como bloco vizinho 102) e reutilizar quaisquer informações de vetor de disparidade associadas para o bloco atual 100. O vetor de disparidade 104 aponta para o bloco de profundidade 106 in a imagem de profundidade de referência. Quando vetor de disparidade 104 é reutilizado para o bloco atual 100, o vetor de disparidade 104 agora aponta o para bloco de profundidade 108 na imagem de profundidade de referência. O bloco de profundidade 108 corresponde ao bloco atual 100. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode então utilizar as informações de profundidade in imagem de profundidade de referência 108 para sintetizar um bloco em uma imagem de textura de referência com o uso de técnicas de encurvamento retrógrado. A imagem de textura sintetizada pode ser então usada como a imagem de referência para prever o bloco atual 100.
[0149] Em um exemplo desta revelação, para o processo de derivação de NBDV, let (dvx, dvy) indica o vetor de disparidade 104 identificado pelo processo de derivação de NBDV, e indica a posição do bloco atual 100 como (blockx, blocky). Em um exemplo de BVSP unipreditiva, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode ser configurado para buscar um bloco de profundidade 108 que tem uma posição de topo esquerda de (blockx+dvx, blocky+dvy) no componente de vista de profundidade da vista de referência. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para dividir primeiro o bloco atual 100 (por exemplo, uma PU) em diversos sub-blocos, cada um com o mesmo tamanho (por exemplo, igual a W*H). Para cada sub-bloco com o tamanho igual a W*H, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 identifica o valor de profundidade máximo a partir dos quatro pixels de canto do sub-bloco de profundidade 108 correspondente dentro do componente de vista de profundidade buscado, por exemplo, conforme mostrado na Figura 10. A Figura 10 é um diagrama conceitual que ilustra quatro pixels de canto de um bloco de profundidade de 8x8 110. Os quatro pixels de canto podem ser identificados como a pixel esquerdo de topo (TL), um pixel direito de topo (TR), um pixel esquerdo de fundo (BL)), e um pixel direito de fundo (BR). O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 converte o valor de profundidade máximo em um vetor de movimento de disparidade. O vetor de movimento de disparidade derivado para cada sub- bloco é então usado para compensação de movimento.
[0150] Essa seção discutirá BVSP ao realizar predição bidirecional. Quando houver múltiplas imagens de referência entre vistas de diferentes vistas em RefPicList0 e RefPicList1, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 aplica BVSP bipreditivo. Na BVSP de bipredição, dois previsores de predição de síntese de vista (isto é, dois blocos de referência sintetizados) serão gerados a partir de cada lista de referência, conforme descrito acima. Os dois previsores de predição de síntese de vista têm então sua média calculada para obter o previsor de predição de síntese de vista final.
[0151] O tamanho de compensação de movimento, isto é, W*H conforme descrito acima, poderia ser tanto 8x4 como 4x8. Em um exemplo, para determinar o tamanho de compensação de movimento, a regra a seguir é aplicada:
[0152] Para cada bloco de 8x8, quatro cantos do bloco de 8x8 de profundidade correspondente são verificados e:
Figure img0001
[0153] A seguir, é descrito o processo de derivação de candidato entre vistas para o modo de pulo/mescla em uma proposta para 3D-HEVC. Com base no vetor de disparidade derivado do processo de derivação de NBDV, um novo candidato de vetor de movimento, denominado Candidato de Vetor de Movimento Previsto entre Vistas (IPMVC), se estiver disponível, pode ser adicionado ao AMVP e à lista de candidatos de vetor de movimento de modo de pulo/mescla. O vetor de movimento previsto entre vistas, se estiver disponível, é um vetor de movimento temporal. Visto que os modos de pulo têm o mesmo processo de derivação de vetor de movimento como modo de mescla, todas as técnicas descritas nesse documento se aplicam aos modos tanto de mescla quanto de pulo.
[0154] A Figura 11 é um diagrama conceitual que ilustra uma derivação exemplificativa de candidato de vetor de movimento previsto entre vistas para modo de mescla/pulo. Por exemplo, a Figura 11 mostra um exemplo do processo de derivação do candidato de vetor de movimento previsto entre vistas. Para o modo de mescla/pulo, o candidato de vetor de movimento previsto entre vistas é derivado pelas seguintes etapas. Primeiro, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 localiza, com o uso do vetor de disparidade, um bloco correspondente (por exemplo, um bloco de referência) 112 de PU/CU atual 114 em uma vista de referência da mesma unidade de acesso. No exemplo da Figura 11, o bloco atual (PU atual) 114 está na vista VI, enquanto o bloco de referência 112 correspondente está na vista V0. Se o bloco de referência 112 correspondente não for intracodificado e não previsto entre vistas, e sua imagem de referência (nesse exemplo, na vista V0 e tempo T1) tem um valor de POC igual ao de uma entrada na mesma lista de imagens de referência de PU/CU atual 114, as informações de movimento (isto é, direção de predição, índice de imagem de referência, e vetor de movimento) do bloco de referência 112 correspondente são derivadas como o vetor de movimento previsto entre vistas depois de converter o índice de referência com base na POC da imagem de referência.
[0155] O bloco de referência 112 correspondente pode ser definido conforme a seguir. Primeiro indicar um local de luma (xP, yP) da amostra de luma de topo esquerda da unidade de predição atual em relação à amostra de luma de topo esquerda da imagem atual. As variáveis nPSW e nPSH indicam a largura e altura da unidade de predição atual, respectivamente. O índice de ordem de vista de referência é identificado como refViewIdx, e o vetor de disparidade como mvDisp. O local de luma de camada de referência (xRef, yRef) é derivado por:
Figure img0002
[0156] O bloco de referência 112 correspondente é ajustado para a unidade de predição que cobre o local de luma (xRef, yRef) no componente de vista com Viewldx igual a refViewIdx.
[0157] Adicionalmente, o vetor de disparidade pode ser convertido em um vetor de movimento de disparidade entre vistas (IDMVC), que é adicionado à lista de candidatos de mescla em uma posição diferente do IPMVC. O vetor de movimento de disparidade entre vistas também pode ser adicionado na lista de candidatos de AMVP na mesma posição que IPMVC, quando a mesma está disponível. Tanto o IPMVC como o IDMVC podem ser denominados como um “candidato entre vistas” nesse contexto.
[0158] Em um exemplo para o modo de mescla/pulo, o IPMVC, se estiver disponível, é inserido antes de todos os candidatos de mesclagem espaciais e temporais na lista de candidatos de mescla. O IDMVC é inserido antes do candidato de mesclagem espacial derivado de A0.
[0159] A seção a seguir descreve as construções de lista de candidatos de mescla para codificação de textura em 3D-HEVC. Primeiro, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 derivam um vetor de disparidade, por exemplo, com o uso das técnicas de derivação de NBDV descritas acima. Depois de derivar o vetor de disparidade, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para executar o processo de construção de lista de candidatos de mescla em 3D-HEVC conforme descrito abaixo.
[0160] O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem derivar um ou mais IPMVCs com o uso do procedimento descrito acima. Se um IPMVC estiver disponível, o IPMV pode ser inserido na lista de mescla.
[0161] Em seguida, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para derivar candidatos de mescla espacial e inserção de um ou mais IDMVC sem 3D-HEVC. Para derivar os candidatos de mescla espacial, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para verificar as informações de movimento de PUs vizinhas espaciais na seguinte ordem: A1, B1, B0, A0, ou B2, por exemplo, conforme mostrado na Figura 6.
[0162] O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser adicionalmente configurados para realizar remoção restrita. Para realizar a remoção restrita, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para não inserir o candidato de mescla espacial no local A1 na lista de candidatos de mescla se A1 e IPMVC tiverem os mesmos vetores de movimento e os mesmos índices de referência. De outro modo, o candidato de mescla espacial no local A é inserido na lista de candidatos de mescla.
[0163] Se o candidato de mescla no local B1 e o candidato de mescla no local de mescla A1 (ou o IPMVC) tiverem os mesmos vetores de movimento e os mesmos índices de referência, o candidato de mescla no local B1 não é inserido na lista de candidatos de mescla. De outro modo, o candidato de mescla no local B1 é inserido na lista de candidatos de mescla. Se candidato de mescla no local B0 estiver disponível (isto é, for codificado e tiver informações de movimento), o candidato de mescla no local B0 é adicionado à lista de candidatos. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 deriva o IDMVC com o uso do procedimento descrito acima. Se um IDMVC estiver disponível, e as informações de movimento do IDMVC forem diferentes dos candidatos derivados de A1 e B1, o IDMVC é inserido na lista de candidatos.
[0164] Se BVSP for permitido para a imagem total (ou para a fatia atual), então o candidato de mesclagem de BVSP é inserido na lista de candidatos de mescla. Se o candidato de mescla no local A0 estiver disponível, o mesmo é adicionado à lista de candidatos. Se o candidato de mesclagem em B2 estiver disponível, o mesmo é adicionado à lista de candidatos.
[0165] A próxima seção discutirá o processo de derivação para o candidato de mesclagem temporal em 3D-HEVC. A derivação de candidato de mesclagem temporal em 3D-HEVC é similar ao processo de derivação de candidato de mesclagem temporal em HEVC, em que as informações de movimento da PU colocalizada é utilizada. No entanto, para 3D-HEVC, o índice de imagem de referência alvo do candidato de mesclagem temporal pode ser mudado em vez de fixar o índice de imagem de referência como 0. Quando um índice de referência alvo igual a 0 corresponder a uma imagem de referência temporal (na mesma vista), enquanto o vetor de movimento da unidade de predição (PU) colocalizada aponta para uma imagem de referência entre vistas, o índice de referência alvo é mudado para outro índice que corresponde à primeira entrada de uma imagem de referência entre vistas na lista de imagens de referência. Pelo contrário, quando o índice de referência alvo igual a 0 corresponde a uma imagem de referência entre vistas, enquanto o vetor de movimento da unidade de predição (PU) colocalizada aponta para a imagem de referência temporal, o índice de imagem de referência alvo é mudado para outro índice que corresponde à primeira entrada de uma imagem de referência temporal na lista de imagens de referência.
[0166] Um processo de derivação exemplificativo para candidatos de mesclagem bipreditiva combinados em 3D- HEVC será agora discutido. Se o número total de candidatos derivado das duas etapas acima (isto é, a derivação de candidatos de mesclagem espacial e a derivação de temporal candidatos de mesclagem) for menor do que o número máximo de candidatos (que pode ser predefinido), o mesmo processo conforme definido em HEVC, conforme descrito acima, é realizado. No entanto, a especificação de índices de referência l0CandIdx e 11CandIdx é diferente. A Figura 12 é uma tabela que indica uma especificação exemplificativa de l0CandIdx e 11CandIdx em 3D-HEVC. Por exemplo, a relação entre combIdx, l0CandIdx e 11CandIdx é definida na tabela ilustrada na Figura 12.
[0167] Um processo de derivação exemplificativo for zero candidatos de mesclagem de vetor de movimento em 3D-HEV é o mesmo procedimento conforme definido em HEVC. Em um exemplo para 3D-HEVC, o número total de candidatos na lista de candidatos de mescla é até 6, e o elemento de sintaxe five_minus_max_num_merge_cand é gerado no cabeçalho de fatia para especificar o número máximo dos candidatos de mescla subtraídos de 6. Deve-se notar que o valor do elemento de sintaxe five_minus_max_num_merge_cand está na faixa de 0 a 5, inclusive.
[0168] A seguir, é descrita a herança de vetor de movimento (MVI) para codificação de profundidade, por exemplo, em 3D-HEVC. As técnicas de MVI buscam explorar a similaridade das características de movimento entre os componentes de textura de uma imagem e seus componentes de vista de profundidade associados. A Figura 13 é um diagrama conceitual que ilustra uma derivação exemplificativa de um candidato de herança de vetor de movimento para codificação de profundidade. Por exemplo, a Figura 13 mostra um exemplo do processo de derivação do candidato MVI em que o bloco de textura correspondente 120 é selecionado como o bloco 4x4 localizado no fundo direito do centro da PU atual 122 em uma imagem de textura 124. Para a PU atual 126 na imagem de profundidade 128, o candidato MVI reutiliza o uso dos vetores de movimento e índices de referência associados ao bloco de textura correspondente 120 já codificado na imagem de textura 124 correspondente, se tais informações estiverem disponíveis.
[0169] Deve-se observar que vetores de movimento com precisão de número inteiro são usados na codificação de profundidade, enquanto vetores de movimento com precisão de um quarto são utilizados para codificação de textura. Portanto, o vetor de movimento do bloco de textura correspondente pode ser escalonado antes de usar um candidato MVI.
[0170] Com a geração de candidato MVI, a lista de candidatos de mescla para as vistas de profundidade é construída conforme a seguir. Para a inserção de MVI, o MVI é derivado com o uso das técnicas conforme descrito acima, e, se estiver disponível, é inserido na lista de candidatos de mescla.
[0171] O processo de derivação para candidatos de mesclagem espacial e inserção de IDMVC em 3D-HEVC para codificação de profundidade é descrito abaixo. Para derivar os candidatos de mescla espacial, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para verificar as informações de movimento de PUs vizinhas espaciais na seguinte ordem: A1, B1, B0, A0 ou B2.
[0172] O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode, então, realizar remoção restrita conforme a seguir. Se o candidato de vetor de movimento no local A1 e o candidato MVI tiverem os mesmos vetores de movimento e os mesmos índices de referência, o candidato de vetor de movimento em A1 não é inserido na lista de candidatos de mescla. Se o candidato de vetor de movimento no local B1 e o candidato de vetor de movimento na A1/MVI de candidato de local tiverem os mesmos vetores de movimento e os mesmos índices de referência, o candidato de vetor de movimento no local B1 não é inserido na lista de candidatos de mescla. Se o candidato de vetor de movimento no local B0 estiver disponível, o candidato de vetor de movimento no local B0 é adicionado à lista de candidatos de mescla. Se o candidato de vetor de movimento no local A0 estiver disponível, o candidato de vetor de movimento no local Ao é adicionado à lista de candidatos de mescla. Se o candidato de vetor de movimento no local B2 estiver disponível, o candidato de vetor de movimento no local B2 é adicionado à lista de candidatos de mescla.
[0173] O processo de derivação para o candidato de mesclagem temporal em codificação de profundidade de 3D- HEVC é similar ao processo de derivação de candidato de mesclagem temporal em HEVC, em que as informações de movimento da PU colocalizada são utilizadas. No entanto, na codificação de profundidade de 3D-HEVC, o índice de imagem de referência alvo do candidato de mesclagem temporal pode ser mudado, conforme explicado acima, em vez de ser fixado como 0.
[0174] O processo de derivação para candidatos de mesclagem bipreditiva combinados em codificação de profundidade de 3D-HEVC será agora descrito. Se o número total de candidatos derivados das duas etapas acima for menor do que o número máximo de candidatos, o mesmo processo conforme definido em HEVC é realizado, exceto para a especificação de l0CandIdx e 11CandIdx. Por exemplo, a relação entre combIdx, l0CandIdx e 11CandIdx é definida na tabela ilustrada na Figura 12.
[0175] O processo de derivação para zero candidatos de mesclagem de vetor de movimento em codificação de profundidade de 3D-HEVC é igual ao procedimento definido em HEVC.
[0176] A seguir, é descrito técnicas exemplificativas para predição residual avançada (ARP). A ARP aplicada às CUs com modo de partição igual a Part_2Nx2N (por exemplo, NxN na Figura 5) foi adotado na 4a reunião JCT3V, conforme proposto em JCT3V-D0177. O documento JCT3V- D0177 é intitulado “CE4: Advanced residual prediction for multiview coding”, por Zhang et al. O documento JCT3V-D0177 está disponível, na data de 22 de agosto de 2014, a partir de http://phenix.it- sudparis.eu/jct3v/doc_end_user/current_document.php?id=862.
[0177] A Figura 14 ilustra a estrutura de predição de predição residual avançada (ARP) em codificação de vídeo de múltiplas vistas. Conforme mostrado na Figura 14, os blocos a seguir são invocados na predição do bloco atual (“Curr”) 140. O bloco de referência 142 na vista de referência/base 144 derivada pelo vetor de disparidade (DV) 146 é identificado como “Base”. O bloco 148 na mesma vista (vista Vm) que o bloco atual Curr 140, derivado pelo vetor de movimento (temporal) 150 (indicado como TMV) do bloco atual 140 é identificado “CurrTRef”. O bloco 152 na mesma vista que o bloco Base 142 (vista V0), derivado pelo vetor de movimento temporal do bloco atual (TMV) é identificado “BaseTRef”. O bloco de referência BaseTRef 152 é identificado com um vector vetor de TMV+DV 154 em comparação ao bloco atual Curr 140.
[0178] O previsor residual é indicado como BaseTRef-Base, em que a operação de subtração se aplica a cada pixel das matrizes de pixel indicadas. Um fator de ponderação “w” pode ser adicionalmente multiplicado ao previsor residual. Portanto, o previsor final do bloco atual Curr pode ser indicado como CurrTRef+ w*(BaseTRef-Base).
[0179] Observe nas descrições acima e na Figura 14, pressupõe-se que a predição uni-direcional é aplicada. A0 estender para ARP à predição bidirecional, as etapas acima são aplicadas para cada lista de imagens de referência. Quando o bloco atual Curr usa uma imagem de referência entre vistas (em uma vista diferente) para uma das duas listas de imagens de referência, o processo de ARP é desabilitado.
[0180] A seguir, é descrito o processo de decodificação em ARP. Primeiro, decodificador de vídeo 30 obtém um vetor de disparidade (por exemplo, com o uso do processo de derivação de NBDV) que aponta para uma vista de referência alvo. Então, na imagem da vista de referência dentro da mesma unidade de acesso, decodificador de vídeo 30 localiza o bloco correspondente com o uso do vetor de disparidade.
[0181] Decodificador de vídeo 30 pode reutilizar as informações de movimento do bloco atual para derivar as informações de movimento para o bloco de referência. O decodificador de vídeo 30 pode então aplicar compensação de movimento for o bloco correspondente com base no mesmo vetor de movimento de bloco atual, e a imagem de referência derivada, para derivar um bloco de resíduo.
[0182] A Figura 15 é um diagrama conceitual que ilustra um exemplo de relação entre o bloco atual 160, o bloco de referência 162 e os blocos compensados por movimento 164 e 166. A imagem de referência na vista de referência (Vo) que tem o mesmo valor de POC (contagem de ordem de imagem) que a imagem de referência de vista atual (Vm) é selecionada como a imagem de referência de bloco correspondente 162. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode aplicar um fator de ponderação ao bloco de resíduo para obter um bloco de resíduo ponderado e adicionar os valores do bloco de resíduo ponderado às amostras previstas.
[0183] A seguir, é descrito o fator de ponderação. Três fatores de ponderação são usados em ARP, isto é, 0, 0,5 e 1. O fator de ponderação que induz ao custo de distorção de taxa mínimo para a CU atual é selecionado como o fator de ponderação final e o índice de fator de ponderação correspondente (por exemplo, 0, 1 e 2 que correspondem ao fator de ponderação 0, 1, e 0,5, respectivamente) é transmitido no fluxo de bits no nível de CU. Em um exemplo de ARP, todas as previsões de PU em uma CU compartilham o mesmo fator de ponderação. Quando o fator de ponderação for igual a 0, ARP não é usado para a CU atual.
[0184] A seguir, são descritas algumas simplificações adicionais para ARP. Primeiro, a seleção de imagem de referência por meio do escalonamento de vetor de movimento é descrita. Segundo, o filtro de interpolação é descrito.
[0185] Para seleção de imagem de referência via escalonamento de vetor de movimento, em JCT3V-C0049, as imagens de referência de unidades de predição codificadas com fatores de ponderação diferentes de zero podem ser diferentes de bloco para bloco. O documento JCT3V-C0049 é intitulado “3D-CE4: Advanced residual prediction for multiview coding”, por Zhang et al. O documento JCT3V-C0049 está disponível, em 23 de setembro de 2013, de http://phenix.int- evry.fr/jct3v/doc_end_user/current_document.php?id=487.
[0186] Portanto, diferentes Imagens da vista de referência podem precisar ser acessadas para gerar o bloco compensado por movimento (por exemplo, BaseTRef na Figura 14) do bloco correspondente. Propôs-se escalonar os vetores de movimento decodificados da PU atual a uma imagem fixa antes de realizar compensação de movimento para o processo de geração residual quando o fator de ponderação for não igual a 0. Conforme proposto em JCT3V-D0177, a imagem fixa é definida como a primeira imagem de referência de cada lista de imagens de referência se a mesma for da mesma vista. Quando o vetor de movimento decodificado não aponta para a imagem fixa, decodificador de vídeo 30 pode primeiro escalonar o vetor de movimento decodificado e então usar o vetor de movimento escalonado para identificar CurrTRef e BaseTRef. Tal imagem de referência usada para ARP é chamada imagem de referência ARP alvo.
[0187] Para filtros de interpolação, conforme descrito em JCT3V-C0049, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode aplicar um filtro bilinear durante o processo de interpolação do bloco correspondente e seu bloco de predição. Para o bloco de predição da PU atual nas vistas de não base, um filtro 8/4-tap convencional pode ser aplicado. Em outro exemplo, conforme proposto em JCT3V- D0177, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode empregar sempre filtragem bilinear independente de se o bloco está na vista de base ou vista de não base quando ARP é aplicado.
[0188] Em um ou mais exemplos da revelação, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode ser configurado para identificar a vista de referência com o uso do índice de ordem de vista retornada do processo de derivação de NBDV. Em um exemplo de ARP, quando a imagem de referência de uma PU em uma lista de imagens de referência é de uma vista diferente do que a vista atual, ARP é desabilitada para essa lista de imagens de referência.
[0189] Algumas técnicas adicionais para intercodificação de profundidade são descritas nos Pedidos Provisórios no U.S. 61/840,400, depositado em 27 de junho de 2013, e no U.S.61/847,942, depositado em 18 de julho de 2013. Nesses exemplos, ao codificar a imagem de profundidade, um vetor de disparidade é convertido por um valor de profundidade estimado das amostras vizinhas do bloco atual.
[0190] Em outros exemplos para ARP, candidatos de mescla adicionais podem ser derivados por exemplo, acessando-se o bloco de referência da vista de base identificado por um vetor de disparidade.
[0191] A seguir, são descritas técnicas para localizar um bloco para predição de movimento entre vistas. Em 3D-HEVC, um bloco de referência 4x4 é identificado com o uso de duas etapas gerais. A primeira etapa é identificar um pixel em uma vista de referência com um vetor de movimento de disparidade. A segunda etapa é obter o bloco 4x4 correspondente (com um conjunto exclusivo de informações de movimento correspondentes a RefPicList0 ou RefPicList1, respectivamente) e utilizar as informações de movimento para criar um candidato de mescla.
[0192] O pixel (xRef, yRef) na vista de referência é identificado da seguinte maneira:
Figure img0003
[0193] em que (xP, yP) é a coordenada da amostra de topo esquerda da PU atual, mvDisp é o vetor de disparidade e nPSWxnPSH é o tamanho da PU atual e PicWidthInSamplesL e PicHeightInSamplesL definem a resolução da imagem na vista de referência (mesma que a vista atual).
[0194] A seguir, é descrita a predição de movimento entre vistas de nível de sub-PU. Em JCT3V-E0184, foi proposto usar o método de predição de movimento entre vistas de nível de sub-PU para o IPMVC, isto é, o candidato derivado de um bloco de referência na vista de referência. O JCT3V-E0184, “3D-CE3.h related: Sub-PU level inter-view motion prediction”, por An et al., está disponível, de http://phenix.it- sudparis.eu/jct2/doc_end_user/current_document.php?id=1198.
[0195] O conceito básico de predição de movimento entre vistas é descrito acima (por exemplo, em relação a processo de derivação de candidato entre vistas para modo de pulo/mescla), em que somente as informações de movimento do bloco de referência associadas à posição central é usada para a PU atual na vista dependente. No entanto, a PU atual pode corresponder a uma área de referência (com o mesmo tamanho que a PU atual identificada pelo vetor de disparidade) na vista de referência, e a área de referência pode ter informações de movimento (isto é, mais do que no vetor de movimento) abundantes.
[0196] Portanto, um método de predição de movimento entre vistas de nível de sub-PU (SPIVMP) é proposto. A Figura 16 é um diagrama conceitual que ilustra uma predição de movimento entre vistas de unidade de subpredição (PU). Conforme mostrado na Figura 16, a PU atual 170 na vista atual VI pode ser dividida em múltiplas sub-PUs (por exemplo, quatro sub-PUs). Um vetor de disparidade para cada sub-PU pode ser usado para localizar blocos de referência correspondentes em uma vista de referência V0. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode ser configurado para copiar (isto é, reutilizar) vetores de movimento associado a cada um dos blocos de referência para uso com as sub-PUs correspondentes de PU atual 170.
[0197] Em um exemplo, um candidato de mescla entre vistas temporal é derivado conforme a seguir. Primeiro, indicar o tamanho de sub-PU atribuído por NxN. Primeiro, dividir a PU atual em múltiplas sub-PUs com um tamanho menor. Indicar o tamanho da PU atual por nPSW x nPSH e o tamanho da sub-PU por nPSWsub x nPSHSub. nPSWsub = min(N, nPSW) nPSHSub = min(N, nPSH)
[0198] Segundo, ajustar um vetor de movimento padrão tmvLX para (0, 0) e índice de referência refLX para -1 para cada lista de imagens de referência. Para cada sub- PU na ordem de varredura de raster, o seguinte se aplica. Adicionar o DV à posição média de sub-PU atual para obter um local de amostra de referência (xRefSub, yRefSub) por:
Figure img0004
[0199] Um bloco na vista de referência que cobre (xRefSub, yRefSub) é usado como o bloco de referência para sub-PU atual.
[0200] Para o bloco de referência identificado, se o mesmo é codificado com o uso de vetores de movimento temporal, o seguinte se aplica. Se tanto refLO e refLl forem iguais a -1, e a sub-PU atual não for a primeira na ordem de varredura de raster, as informações de movimento do bloco de referência são herdadas por todas as anteriormente sub-PUs anteriores. Os parâmetros de movimento associados podem ser usados como parâmetros de movimento de candidato para a sub- PU atual. O elemento de sintaxe s tmvLX e refLX são atualizados para as informações de movimento da sub-PU atual. De outro modo (por exemplo, se o bloco de referência for intracodificado), as informações de movimento de sub-PU atual são ajustadas para tmvLX e refLX. Diferentes tamanhos de bloco de sub-PU podem ser aplicados, por exemplo, 4x4, 8x8 e 16x16. O tamanho de sub-PU pode ser sinalizado em VPS.
[0201] A seguir, é descrita herança de vetor de movimento de nível de sub-PU para codificação de profundidade. Similar às propostas para predição de movimento entre vistas de nível de sub-PU de uma vista de textura à outra vista de textura, o documento provisório no U.S. 61/858,089, depositado em 24 de julho de 2013, técnicas propostas que se aplicam à predição de movimento de nível de sub-PU de uma vista de textura à vista de profundidade correspondente. Ou seja, uma PU atual pode ser particionada em diversas sub-PUs e cada sub-PU usa as informações de movimento de um bloco de textura colocalizado para compensação de movimento. Nesse caso, o nível de sub-PU MVI é suportado e o vetor de disparidade usado por predição de movimento entre vistas é considerado como sempre zero.
[0202] O projeto atual para BVSP em 3D-HEVC exibe os problemas a seguir. Quando AMP é usado e o tamanho de PU atual é 4x16 ou 16x4, e a PU é prevista de modo unidirecional, BVSP é alcançada derivando-se um vetor de disparidade para a PU inteira. Ou seja, cada sub-bloco na PU usa o mesmo vetor de disparidade para síntese de bloco de referência e compensação de movimento. Sendo assim, para tamanhos de bloco maiores, BVSP pode ser menos eficiente devido ao fato de que o uso do mesmo vetor de disparidade para a síntese de bloco e compensação de movimento para todos os sub-blocos pode ser menos ideal para alguns dos sub- blocos.
[0203] Como outra desvantagem, quando a PU atual é prevista de modo bidirecional, BVSP é permitido com tamanhos de bloco iguais à 4x8 e 8x4. No entanto, em HEVC, a compensação de movimento para blocos que contêm menos do que 64 pixels (por exemplo, 4x8 ou 8x4 blocos) não é permitida (embora compensações de movimento de 16x4 e 4x16 sejam permitidas).
[0204] Em vista dessas desvantagens, esta revelação propõe técnicas relacionadas à predição de síntese de vista em 3D-HEVC, focando em tamanhos de compensação de movimento de BVSB. De acordo com as técnicas desta revelação, para BVSP, cada PU pode ser dividida em sub-blocos, e cada sub-bloco pode ser associado a um vetor de movimento de disparidade diferente e separadamente compensado por movimento. Dessa maneira, a precisão de BVSP pode ser aumentada para blocos particionados com AMP, e desse modo, a eficiência de codificação pode ser aumentada. De acordo com as técnicas da revelação, o tamanho de sub-blocos disponível para uso com BVSP pode ser adicionalmente definido conforme a seguir.
[0205] Em um exemplo da revelação, quando o tamanho de PU atual for 16x4 (ou 4x16), e a PU atual for prevista de modo unidirecional, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode ser configurado para aplicar BVSP e técnicas de compensação de movimento para sub-blocos de 8x4 (ou 4x8) da PU atual. Ou seja, o tamanho da sub-região de BVSP é 8x4 (ou 4x8). Cada um dos sub-blocos pode ser atribuído com um vetor de movimento de disparidade convertido a partir de um bloco de profundidade.
[0206] A Figura 17 é um desenho conceitual que retrata BVSP e técnicas de compensação de movimento desta revelação ao usar AMP. No exemplo da Figura 17, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 particiona de modo assimétrico a PU atual 250 em um bloco de 4x16. Observe que a partição de 4x16 é somente um exemplo, e que as técnicas desta revelação descritas em referência à Figura 17 podem ser aplicadas a outras partições assimétricas, incluindo partições de 16x4. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode ser configurado para subdividir PU 250 em sub-blocos de 4x8 255 e 256.
[0207] No exemplo da Figura 17, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 são configurados para prever de modo unidirecional a PU 250 com o uso de BVSP. A esse respeito o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para derivar um vetor de disparidade para PU 250, por exemplo, com o uso de técnicas de derivação de NBDV. Por exemplo, o vetor de disparidade 261 pode ser derivado do bloco vizinho 252. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser então configurados para reutilizar o vetor de disparidade 261 para localizar um bloco de profundidade correspondente 260 em uma imagem de profundidade de referência. De acordo com as técnicas desta revelação, em vez de usar a totalidade do bloco de profundidade 260 para derivar um único vetor de movimento de disparidade para PU 255, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para derivar um vetor de movimento de disparidade do sub-bloco de 4x8 264 do bloco de profundidade 260 para o sub-bloco 255, e para derivar um vetor de movimento de disparidade do sub- bloco de 4x8 262 de bloco de profundidade 26 para o sub- bloco 256.
[0208] O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem então sintetizar um bloco de referência para cada um dos sub-blocos 255 e 256 com o uso dos vetores de movimento de disparidade derivados correspondentes para realizar a compensação de movimento com a imagem de referência correspondente à imagem de referência entre vistas com uma ordem de vista igual a refVIdxLX. Derivando-se vetores de movimento de disparidade individuais para cada um dos sub-blocos 255 e 256, vistas de referência mais precisas podem ser sintetizadas e o processo de compensação de movimento correspondente pode ser alcançado em ganhos de codificação aumentados.
[0209] Em outro exemplo da revelação, quando o tamanho de PU atual for 16x12 (ou 12x16), e a PU atual for prevista de modo unidirecional, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem ser configurados para particionar a PU atual em sub-blocos de 8x4 (ou 4x8) (também chamados sub-regiões de BVSP) e derivar um vetor de movimento de disparidade para cada sub-bloco com o uso de BVSP.
[0210] Em outro exemplo, o tamanho das sub- regiões de BVS pode ser atribuído para 16x12 ou 12x16. Em ainda outro exemplo, cada 16x12 (ou 12x16) sub-bloco é adicionalmente particionado em um sub-bloco de 16x8 (ou 8x16) e dois sub-blocos de 8x4 (ou 4x8) que são adjacentes à PU de 16x4 (4x16) na mesma CU. Em outro exemplo, os sub-blocos de 16x8 (ou 8x16) podem ser adicionalmente separados em duas de sub-regiões 8x8 ou quatro sub-regiões de 4x8 (ou 8x4) com base, por exemplo, nos 4 cantos de bloco de profundidade correspondente.
[0211] Em outro exemplo da revelação, quando tanto a altura quanto a largura da PU atual são maiores ou iguais à 8, e a PU é prevista de modo bidirecional, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 são configurados para ajustar o tamanho da sub-região de BVSP para 8x8 em vez de 4x8 ou 8x4, como em propostas anteriores para 3D-HEVC. Em outro exemplo, em vez de com o uso de BVSP bipreditivo para PUs com tamanhos iguais a 12x16 ou 16x12, BVSP unipreditiva pode ser aplicada. Nesse caso, o tamanho de compensação de movimento pode ser adicionalmente ajustado para 4x16 ou 16x4. Em outro exemplo, quando o tamanho de PU atual for 16x4 ou 4xl6 e a PU atual for prevista de modo bidirecional, o tamanho da sub-região de BVSP é ajustado igual ao tamanho de PU.
[0212] A predição de movimento de sub-PU pode exibir as desvantagens a seguir. Nesse contexto, predição de movimento de sub-PU pode incluir as técnicas de predição de movimento de sub-PU propostas em JCT3V-E0184, conforme descrito acima, assim como a extensão de predição de movimento de sub-PU para MVI a partir da vista de textura para a vista de profundidade.
[0213] Como uma desvantagem, quando a partição de movimento assimétrico (AMP) for permitida, o tamanho de PU atual é igual, por exemplo, 4x16, 16x4, e o tamanho de bloco de sub-PU sinalizado no VPS é igual a 8x8, com base nas propostas anteriores para predição de movimento de sub- PU, tais PUs serão divididas em dois sub-blocos de 4x8 ou 8x4. Para cada sub-bloco, as informações de movimento de um bloco de referência são herdadas. As informações de movimento podem ser identificadas por um vetor de disparidade em uma vista de textura de referência para predição de movimento entre vistas ou podem ser reutilizadas a partir de bloco de textura colocalizado na vista de textura correspondente para herança de vetor de movimento. Nesse exemplo, bipredição baseada em 4x8 ou 8x4 pode ser invocada, o que não é permitido por HEVC.
[0214] Como outra desvantagem, quando AMP é permitida, o tamanho de PU é igual a, por exemplo, 12x16 ou 16x12, e o tamanho de bloco de sub-PU sinalizado (isto é, tamanho de sub-bloco) em VPS é igual a 8x8, com base em propostas anteriores para predição de movimento de sub-PU, tais PUs serão divididas em dois sub-blocos de 8x8 e dois sub-blocos de 4x8/8x4. Similar ao caso acima, os sub-blocos de 4x8/8x4 sub-blocos podem usar bipredição, o que não é permitido por HEVC.
[0215] Técnicas relacionadas à predição de movimento entre vistas e herança de vetor de movimento (para uma PU de profundidade) são propostas nesta revelação. As técnicas desta revelação podem ser aplicadas no contexto quando um índice de mescla indica a predição de movimento entre vistas ou MVI. Em particular, a predição de movimento entre vistas e/ou técnicas de MVI da revelação incluem técnicas para a partição adicional de PUs de AMP em sub- blocos e obter informações de movimento separadas para cada um dos sub-blocos. Dessa maneira, a precisão de predição de movimento entre vistas e/ou MVI pode ser aprimorada para cada um dos sub-blocos, e desse modo, a eficiência de codificação pode ser aumentada.
[0216] Em um exemplo da revelação, quando uma PU atual é codificada com o uso de predição de movimento entre vistas e/ou MVI, e o tamanho de PU atual é igual a 4x16 ou 16x4, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode ser configurado para dividir a PU em dois sub-blocos de 4x8 ou 8x4. Para cada um dos sub- blocos, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 pode ser configurado para obter somente informações de movimento de um bloco de referência correspondente a uma lista de imagens de referência particular (por exemplo, RefPicList0). As informações de movimento correspondentes a um bloco de referência em RefPicList0 são herdadas para os sub-blocos de 4x8 ou 8x4. Nesse caso, os sub-blocos são previstos de modo unidirecional a partir de uma imagem em RefPicList0.
[0217] A Figura 18 é um diagrama conceitual que ilustra herança de vetor de movimento e técnicas de compensação de movimento para PUs assimetricamente particionadas em tamanhos 4x16 e 16x4. Por exemplo, para uma PU de PU de 4x16, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 são configurados para dividir adicionalmente a PU de 4x16 em dois sub-blocos de 4x8 300 e 302. Informações de movimento para cada um dos sub-blocos 300 e 302 são obtidas a partir de um bloco de referência em uma imagem de referência que pertence a uma lista de imagens de referência particular (por exemplo, RefPicList0). A compensação de movimento é então realizada para cada um dos sub-blocos 300 e 302 em relação a um bloco de referência em RefPicList0. De modo similar, para uma PU de 16x4, o criptografador de vídeo 20 e/ou o decodificador de vídeo 30 são configurados para dividir adicionalmente a PU de 16x5 em dois sub-blocos de 8x4 304 e 306. Informações de movimento para cada um dos sub-blocos 304 e 306 são obtidas a partir de um bloco de referência em uma imagem de referência que pertence a uma lista de imagens de referência particular (por exemplo, RefPicList0). A compensação de movimento é então realizada para cada um dos sub-blocos 304 e 306 em relação a um bloco de referência em RefPicList.
[0218] Em outro exemplo da revelação, quando o tamanho de PU atual for um dentre 16x12, 12x16, 4x16, ou 16x4, o criptografador de vídeo 20 e o decodificador de vídeo 30 são configurados para não usar bipredição para sub-blocos de 8x4/4x8 quando predição de movimento entre vistas de nível de sub-PU e/ou MVI (para profundidade) for aplicada. Ou seja, quando o tamanho de PU atual for um dentre 16x12, 12x16, 4x16, ou 16x4, o criptografador de vídeo 20 e decodificador de vídeo 30 são configurados para usar somente unipredição para sub-blocos de 8x4/4x8 quando predição de movimento entre vistas de nível de sub-PU e/ou MVI (para profundidade) for aplicada.
[0219] Em outro exemplo da revelação, é proposto que, quando a predição de movimento entre vistas de nível de sub-PU ou MVI for aplicada, e o tamanho de PU atual for igual a 4x16 ou 16x4, a PU não é dividida em sub-PUs.
[0220] Em outro exemplo da revelação, é proposto que, quando predição de movimento entre vistas de nível de sub-PU ou MVI for aplicada, e o tamanho de PU atual for igual a 12x16 ou 16x12, a PU é dividida em três blocos de sub-PU de tamanho igual com um tamanho igual a 4x16 ou 16x4. Para cada sub-PU bloco, as informações de movimento do bloco de referência correspondentes são herdadas.
[0221] Em outro exemplo da revelação, quando o tamanho de PU atual for igual a 12x16 ou 16x12, a PU é dividida em dois 8x8 e blocos de sub-PU de 4x16 ou 16x4, em que as sub-PUs de 8x8 formam a metade esquerda ou de topo da CU que contém essa PU. Em outro aspecto desse exemplo, os sub-blocos de 4x16 e 16x4 são adicionalmente divididos em dois blocos de sub-PU de 4x8 ou 8x4. Para cada sub-PU de 4x8 ou 8x4, somente as informações de movimento de um bloco de referência correspondente à lista de imagens de referência (RefPicList0) é obtida e reutizada para a sub-PU de 4x8 ou 8x4. Nesse caso, as sub-PUs são previstas de modo unidirecional a partir de uma imagem em RefPicList0.
[0222] Em outro exemplo da revelação, quando BVSP é usado para uma PU com um tamanho igual a 12x16 ou 16x12, a PU é dividida em três blocos de sub-PU de tamanho igual com tamanhos iguais a 4x16 ou 16x4. O criptografador de vídeo 20 e/ou o decodificador de vídeo 30 podem então derivar um vetor de movimento de disparidade exclusivo para cada sub-PU a partir do bloco de profundidade correspondente.
[0223] A Figura 19 é um diagrama de blocos que ilustra um criptografador de vídeo exemplificativo 20 que pode implantar as técnicas desta revelação. O criptografador de vídeo 20 pode realizar intra e intercodificação (incluindo codificação entre vistas) de blocos de vídeo dentro de fatias de vídeo, por exemplo, fatias de ambas imagens de textura e mapas de profundidade. As informações de textura geralmente incluem informações de luminância (brilho ou intensidade) e crominância (cor, por exemplo, tonalidades de vermelho e tonalidades de azul). Em geral, o criptografador de vídeo 20 pode determinar modos de codificação em relação às fatias de luminância, e reutilizar informações de predição a partir da codificação das informações de luminância para criptar informações de crominância (por exemplo, reutilizando-se informações de partição, seleções de modo de intrapredição, vetores de movimento, ou similares). A intracodificação tem base na predição espacial para reduzir ou remover a redundância espacial no vídeo dentro de um determinado quadro de vídeo ou imagem. A intercodificação tem base na predição temporal para reduzir ou remover a redundância temporal no vídeo dentro de quadros ou imagens adjacentes de uma sequência de vídeo. O intramodo (modo I) pode se referir a qualquer um dentre vários modos de codificação com base em espaço. Os intermodos, como predição monodirecional (modo P) ou bipredição (modo B), podem se referir a qualquer um dentre vários modos de codificação com base em tempo.
[0224] Conforme mostrado na Figura 19, criptografador de vídeo 20 recebe um bloco de vídeo atual (ou seja, um bloco de dados de vídeo, tal como um bloco de luminância, um bloco de crominância, ou um bloco de profundidade) dentro de um quadro de vídeo (por exemplo, uma imagem de textura ou um mapa de profundidade) a ser criptografado. No exemplo da Figura 19, criptografador de vídeo 20 inclui memória de dados de vídeo 40, unidade de seleção de modo 41, armazenamento temporário de imagem decodificada (DPB) 64, somador 50, unidade de processamento de transformada 52, unidade de quantização 54, unidade de filtro de laço 63, e unidade de criptação por entropia 56. A unidade de seleção de modo 41, por sua vez, inclui a unidade de compensação de modo 44, a unidade de estimativa de movimento 42, a unidade de processamento de intrapredição 46 e a unidade de partição 48. Para o bloco de vídeo reconstrução, o criptografador de vídeo 20 também inclui a unidade de quantização inversa 58, a unidade de processamento de transformada inversa 60 e o somador 62. A unidade de filtro de laço 63 pode inclui um filtro de desblocagem e um filtro SAO para filtrar as delimitações de bloco para remover os artefatos de bloqueio do vídeo reconstruído. Filtros adicionais (em laço ou pós-laço) também podem ser usados adicionalmente ao filtro de desbloqueio. Tais filtros não são mostrados para propósitos de brevidade, mas caso desejado, podem filtrar o resultado do somador 50 (como um filtro em laço).
[0225] A memória de dados de vídeo 40 pode armazenar dados de vídeo a serem criptografados pelos componentes de criptografador de vídeo 20. Os dados de vídeo armazenados na memória de dados de vídeo 40 podem ser obtidos, por exemplo, a partir da fonte de vídeo 18. DPB 64 é um exemplo de um DPB que armazena dados de vídeo de referência para o uso em dados de vídeo de criptação pelo criptografador de vídeo 20 (por exemplo, em modos de intra e intercodificação, também chamados de modos de codificação de intra e interpredição). A memória de dados de vídeo 40 e DPB 64 podem ser formados por qualquer um dentre uma variedade de dispositivos de memória, tal como memória dinâmica de acesso aleatório (DRAM), que inclui DRAM síncrona (SDRAM), RAM magnetorresistiva (MRAM), RAM resistiva (RRAM) ou outros tipos de dispositivos de memória. A memória de dados de vídeo 40 e DPB 64 podem ser fornecidos pelo menos dispositivo de memória ou dispositivos de memória separados. Em vários exemplos, a memória de dados de vídeo 40 pode estar no chip com outros componentes de criptografador de vídeo 20, ou fora do chip em relação àqueles componentes.
[0226] Durante o processo de criptação, o criptografador de vídeo 20 recebe um quadro ou fatia de vídeo a ser codificado. O quadro ou fatia pode ser dividido em múltiplos blocos de vídeo. A unidade de estimativa de movimento 42 e a unidade de compensação de movimento 44 realizam codificação interpreditiva do bloco de vídeo recebido em relação a um ou mais blocos em um ou mais quadros de referência para fornecer predição temporal. A unidade de processamento de intrapredição 46 pode realizar de modo alternativo a codificação intrapreditiva do bloco de vídeo recebido em relação a um ou mais blocos vizinhos no mesmo quadro ou fatia que o bloco a ser codificado para fornecer predição espacial. O criptografador de vídeo 20 pode realizar múltiplos passos de codificação, por exemplo, para selecionar um modo de codificação apropriado para cada bloco de dados de vídeo.
[0227] Além do mais, a unidade de partição 48 pode particionar blocos de dados de vídeo em sub-blocos, com base na avaliação de esquemas de partição anteriores em passos de codificação anteriores. Por exemplo, a unidade de partição 48 pode particionar inicialmente um quadro ou fatia em LCUs, e particionar cada uma das LCUs em sub-CUs com base na análise de distorção de taxa (por exemplo, otimização de distorção de taxa). A unidade de seleção de modo 41 pode produzir adicionalmente uma estrutura de dados de árvore quadrática que indica a partição de uma LCU em sub-CUs. As CUs de nó-folha da árvore quadrática podem incluir uma ou mais PUs e uma ou mais TUs.
[0228] A unidade de seleção de modo 41 pode selecionar um dos modos de codificação, intra ou inter, por exemplo, com base em resultados de erro e fornece o bloco intra ou intercodificado resultante para o somador 50 para gerar dados de bloco residuais e para o somador 62 para reconstruir o bloco criptografado para uso como um quadro de referência. A unidade de seleção de modo 41 também fornece elementos de sintaxe, como vetores de movimento, indicadores intramodo, informações de partição e outras tais informações de sintaxe, para a unidade de criptação por entropia 56.
[0229] A unidade de estimativa de movimento 42 e a unidade de compensação de modo 44 podem ser altamente integradas, mas são ilustradas separadamente para propósitos de conceito. A estimativa de movimento, realizada pela unidade de estimativa de movimento 42, é o processo de geração de vetores de movimento, que estima o movimento para blocos de vídeo. Um vetor de movimento, por exemplo, pode indicar o deslocamento de uma PU de um bloco de vídeo dentro de um quadro ou imagem de vídeo atual em relação a um bloco preditivo dentro de um quadro de referência (ou outra unidade codificada) em relação ao bloco atual que está codificado dentro do quadro atual (ou outra unidade codificada).
[0230] Um bloco preditivo é um bloco que se encontra em correspondência muito próxima ao bloco a ser codificado, em termos de diferença de pixels, que pode ser determinado pelo somatório da diferença absoluta (SAD), somatório da diferença quadrada (SSD) ou outras medidas de diferença. Em alguns exemplos, o criptografador de vídeo 20 pode calcular valores para posições de pixel subinteiros de imagens de referência armazenadas na DPB 64. Por exemplo, o criptografador de vídeo 20 pode interpolar valores de posições de um quarto de pixel, posições de um oitavo de pixel ou outras posições fracionadas de pixel da imagem de referência. Portanto, a unidade de estimativa de movimento 42 pode realizar uma busca de movimento em relação a todas as posições de pixel e posições fracionadas de pixel e emitir um vetor de movimento com precisão fracionada de pixel.
[0231] A unidade de estimativa de movimento 42 calcula um vetor de movimento para uma PU de um bloco de vídeo em uma fatia intercodificada pela comparação da posição da PU em relação à posição de um bloco preditivo de uma imagem de referência. A imagem de referência pode ser selecionada a partir de uma primeira lista de imagens de referência (Lista 0) ou uma segunda lista de imagens de referência (Lista 1), cada uma das quais identifica uma ou mais imagens de referência armazenadas no DPB 64. As listas de imagens de referência podem ser construídas com o uso desta revelação. A unidade de estimativa de movimento 42 envia o vetor de movimento calculado para a unidade de criptação por entropia 56 e a unidade de compensação de modo 44.
[0232] A compensação de movimento, realizada pela unidade de compensação de modo 44, pode envolver obter ou gerar o bloco preditivo com base no vetor de movimento determinado pela unidade de estimativa de movimento 42. Novamente, a unidade de estimativa de movimento 42 e a unidade de compensação de modo 44 podem ser integradas de modo funcional, em alguns exemplos. Mediante o recebimento do vetor de movimento para a PU do bloco de vídeo atual, a unidade de compensação de modo 44 pode localizar o bloco preditivo para o qual o vetor de movimento aponta em uma das listas de imagens de referência. O somador 50 forma um bloco de vídeo residual subtraindo-se valores de pixel do bloco preditivo dos valores de pixel do bloco de vídeo atual que está codificado, o que forma a diferença de valores de pixels, conforme discutido abaixo. Em geral, a unidade de estimativa de movimento 42 realiza a estimativa de movimento em relação a componentes de luma, e a unidade de compensação de modo 44 usa vetores de movimento calculados com base nos componentes de luma tanto para os componentes de croma quanto para os componentes de luma. Dessa maneira, a unidade de compensação de movimento 44 pode reutilizar as informações de movimento determinadas para componentes de luma para codificar os componentes de croma de modo que a unidade de estimativa de movimento 42 não precise realizar uma busca de movimento para os componentes de croma. A unidade de seleção de modo 41 também pode gerar elementos de sintaxe associados aos blocos de vídeo e a fatia de vídeo para uso pelo decodificador de vídeo 30 na decodificação dos blocos de vídeo da fatia de vídeo.
[0233] A unidade de processamento intraprevisões 46 pode intraprever um bloco atual, como uma alternativa à intrapredição realizada pela unidade de estimativa de movimento 42 e a unidade de compensação de movimento 44, conforme descrito acima. Em particular, a unidade de processamento de intrapredição 46 pode determinar um modo de intrapredição para usar para codificar um bloco atual. Em alguns exemplos, a unidade de processamento de intrapredição 46 pode codificar um bloco atual com o uso de vários modos intraprevisões, por exemplo, durante passos de codificação separados, e a unidade de processamento de intrapredição 46 (ou unidade de seleção de modo 41, em alguns exemplos) pode selecionar um modo de intrapredição apropriado para usar a partir dos modos testados.
[0234] Por exemplo, a unidade de processamento de intrapredição 46 pode calcular valores de distorção de taxa com o uso de uma análise de distorção de taxa para os vários modos de intrapredição testados, e selecionar o modo de intrapredição que tem as melhores características de distorção de taxa entre os modos testados. A análise de distorção de taxa geralmente determina uma quantidade de distorção (ou erro) entre um bloco codificado e um bloco original não codificado que foi codificado para produzir o bloco codificado, assim como uma taxa de bits (ou seja, vários bits) usados para produzir o bloco codificado. A unidade de processamento de intraprevisões 46 pode calcular razões a partir de distorções e taxas para os vários blocos codificados para determinar qual modo de intrapredição exibe o melhor valor de distorção de taxa para o bloco.
[0235] Após selecionar um modo de intrapredição para um bloco, a unidade de processamento de intrapredição 46 pode fornecer informações que indicam o modo de intrapredição selecionado para o bloco em relação à unidade de criptação por entropia 56. A unidade de criptação por entropia 56 pode codificar as informações que indicam o modo de intrapredição selecionado. O criptografador de vídeo 20 pode incluir nos dados de conimagem de fluxo de bits transmitidos, que podem incluir uma pluralidade de tabelas de índices de modo de intrapredição e uma pluralidade de tabelas de índices de modo de intrapredição modificados (também referidas como tabelas de mapeamento de palavras- código), as definições de codificação de contextos para vários blocos, e indicações de um modo de intrapredição mais provável, uma tabela de índices de modo de intrapredição e uma tabela de índices de modo de intrapredição modificados para usar para cada um dos contextos.
[0236] O criptografador de vídeo 20 forma um bloco de vídeo residual subtraindo-se os dados de predição da unidade de seleção de modo 41 a partir do bloco de vídeo original que está codificado. O somador 50 representa o componente ou os componentes que realizam essa operação de subtração. A unidade de processamento de transformada 52 aplica uma transformada, como uma transformada de cosseno discreta (DCT) ou uma transformada conceitualmente similar, ao bloco residual, o que produz um bloco de vídeo que compreende valores de coeficiente de transformada residuais. A unidade de processamento de transformada 52 pode realizar outras transformadas que sejam conceitualmente similares à DCT. As transformadas de wavelet, transformadas de números inteiros, transformadas de sub-faixa ou outros tipos de transformadas também podem ser usadas. Em todo caso, a unidade de processamento de transformada 52 aplica a transformada ao bloco residual, produzindo um bloco de coeficiente de transformada residual.
[0237] A transformada pode converter as informações residuais provenientes de um domínio de valor de pixel para um domínio de transformada, como um domínio de frequência. A unidade de processamento de transformada 52 pode enviar o coeficiente de transformada resultante para a unidade de quantização 54. A unidade de quantização 54 quantiza o coeficiente de transformada para reduzir ainda mais a taxa de bits. O processo de quantização pode reduzir a profundidade de bits associada a alguns ou todos os coeficientes. O grau de quantização pode ser modificado ajustando-se um parâmetro de quantização. Em alguns exemplos, a unidade de quantização 54, então, pode realizar uma varredura da matriz, incluindo o coeficiente de transformada quantizado. Alternativamente, a unidade de criptação por entropia 56 pode realizar a varredura.
[0238] Após a quantização, a unidade de criptação por entropia 56 codifica por entropia o coeficiente de transformada quantizado. Por exemplo, uma unidade de criptação por entropia 56 pode realizar codificação de comprimento variável adaptativa a contexto (CAVLC), codificação aritmética binária adaptativa a contexto (CABAC), codificação aritmética binária adaptativa a contexto com base em sintaxe (SBAC), codificação por Entropia de partição de Intervalo de Probabilidade (PIPE) ou outra metodologia de codificação por entropia. No caso de codificação por entropia com base em contexto, o contexto pode ter base em blocos vizinhos. Após a codificação por entropia pela unidade de criptação por entropia 56, o fluxo de bits criptografado pode ser transmitido para outro dispositivo (por exemplo, o decodificador de vídeo 30) ou arquivado para transmissão ou recuperação posterior.
[0239] A unidade de quantização inversa 58 e a unidade de processamento de transformada inversa 60 aplicam a quantização inversa e transformada inversa, respectivamente, para reconstruir o bloco residual no domínio de pixels, por exemplo, para uso posterior como um bloco de referência. A unidade de compensação de movimento 44 pode calcular um bloco de referência adicionando-se o bloco residual a um bloco preditivo de um dos quadros de DPB 64. A unidade de compensação de movimento 44 também pode aplicar um ou mais filtros de interpolação ao bloco residual reconstruído para calcular valores de pixel subinteiros para uso na estimativa de movimento. O somador 62 adiciona o bloco residual reconstruído ao bloco de predição compensado de movimento produzido pela unidade de compensação de movimento 44 para produzir um bloco de vídeo reconstruído para o armazenamento na DPB 64. O bloco de vídeo reconstruído pode ser usado pela unidade de estimativa de movimento 42 e pela unidade de compensação de modo 44 como um bloco de referência para intercodificar um bloco em um quadro de vídeo subsequente.
[0240] O criptografador de vídeo 20 pode decodificar mapas de maneira a se assemelhar substancialmente às técnicas de codificação para codificar componentes de luminância, embora sem componentes de crominância correspondentes. Por exemplo, a unidade de processamento de intrapredição 46 pode intraprever blocos de mapas de profundidade, enquanto a unidade de estimativa de movimento 42 e a unidade de compensação de movimento 44 podem interprever os blocos de mapas de profundidade. No entanto, conforme discutido acima, durante a interpredição de mapas de profundidade, a unidade de compensação de movimento 44 pode escalonar (isto é, ajustar) os valos de mapas de profundidade de referência com base nas diferenças nas faixas de profundidade e valores de precisão para as faixas de profundidade. Por exemplo, se os valores de profundidade máxima diferentes no mapa de profundidade atual e um mapa de profundidade de referência correspondem à mesma profundidade do mundo real, o criptografador de vídeo 20 pode escalonar o valor de profundidade máxima do mapa de profundidade de referência para ser igual ao valor de profundidade máxima no mapa de profundidade atual, para propósitos de predição. Adicional ou alternativamente, o criptografador de vídeo 20 pode usar os valores de faixa de profundidade atualizados e os valores de precisão para gerar uma imagem de síntese de vista para predição de síntese de vista, por exemplo, com o uso de técnicas substancialmente semelhantes à predição de intravista.
[0241] Conforme será discutido em maiores detalhes abaixo em relação às Figuras 21 a 23, o criptografador de vídeo 20 pode ser configurado para empregar as técnicas desta revelação descrita acima. Em particular, o criptografador de vídeo 20 pode ser configurado para partição de PUs em sub-blocos quando tais PUs são particionados de acordo com um modo de partição assimétrico. O criptografador de vídeo 20 pode, então, ser configurado para herdar e/ou derivar vetores de movimento ou vetores de movimento de disparidade para cada um dos sub-blocos.
[0242] A Figura 20 é um diagrama de blocos que ilustra um exemplo de um decodificador de vídeo 30 que pode implantar as técnicas desta revelação. No exemplo da Figura 20, o decodificador de vídeo 30 inclui memória de dados de vídeo 79, unidade de decodificação por entropia 70, unidade de compensação de movimento 72, unidade de processamento de intrapredição 74, unidade de quantização inversa 76, unidade de processamento de transformada inversa 78, armazenamento temporário de imagem decodificado (DPB) 82, unidade de filtro de laço 83, e somador 80. O decodificador de vídeo 30 pode, em alguns exemplos, realizar um passo de decodificação geralmente recíproco ao passo de codificação descrito em relação ao criptografador de vídeo 20 (Figura 19). A unidade de compensação de movimento 72 pode gerar dados de predição com base em vetores de movimento recebidos a partir da unidade de decodificação por entropia 70, enquanto a unidade de processamento de intrapredição 74 pode gerar dados de predição com base em indicadores de modo de intrapredição recebidos a partir da unidade de decodificação por entropia 70.
[0243] A memória de dados de vídeo 79 pode armazenar dados de vídeo, tal como um fluxo de bits de vídeo criptografado, a ser decodificado pelos componentes de decodificador de vídeo 30. Os dados de vídeo armazenados na memória de dados de vídeo 79 podem ser obtidos a partir de uma fonte de vídeo local, tal como uma câmera, através de comunicação de rede sem fio ou com fio de dados de vídeo ou através do acesso de meio de armazenamento de dados físicos. A memória de dados de vídeo 79 pode formar um armazenamento temporário de imagem codificada (CPB) que armazena dados de vídeo criptografados a partir de um fluxo de bits de vídeo criptografado. DPB 82 é um exemplo de um DPB que armazena dados de vídeo de referência para o uso em dados de vídeo de decodificação pelo decodificador de vídeo 30 (por exemplo, em modos de intra e intercodificação, também chamados de modos de codificação intra e interpredição). A memória de dados de vídeo 79 e DPB 82 podem ser formados por qualquer um dentre uma variedade de dispositivos de memória, tal como memória dinâmica de acesso aleatório (DRAM), que inclui DRAM síncrona (SDRAM), RAM magnetorresistiva (MRAM), RAM resistiva (RRAM) ou outros tipos de dispositivos de memória. A memória de dados de vídeo 79 e DPB 82 podem ser fornecidos pelo menos dispositivo de memória ou dispositivos de memória separados. Em vários exemplos, a memória de dados de vídeo 79 pode estar no chip com outros componentes de decodificador de vídeo 30, ou fora do chip em relação àqueles componentes.
[0244] Durante o processo de decodificação, o decodificador de vídeo 30 recebe um fluxo de bits de vídeo criptografado que representa blocos de vídeo de uma fatia de vídeo criptada e elementos de sintaxe associados provenientes do criptografador de vídeo 20. A unidade de decodificação por entropia 70 do decodificador de vídeo 30 decodifica por entropia o fluxo de bits para gerar coeficientes quantizados, vetores de movimento ou indicadores de modo de intrapredição e outros elementos de sintaxe. A unidade de decodificação por entropia 70 encaminha os vetores de movimento e outros elementos de sintaxe para a unidade de compensação de modo 72. O decodificador de vídeo 30 pode receber os elementos de sintaxe no nível de fatia de vídeo e/ou no nível de bloco de vídeo.
[0245] Quando a fatia de vídeo for codificada como uma fatia intracodificada (I), a unidade de processo de intrapredição 74 pode gerar dados de predição para um bloco de vídeo da fatia de vídeo atual com base em um modo de intrapredição sinalizado e dados provenientes de blocos decodificados anteriormente do quadro ou imagem atual. Quando o quadro de vídeo for codificado como uma fatia intercodificada (por exemplo, B, P ou GPB), a unidade de compensação de modo 72 produz blocos preditivos para um bloco de vídeo da fatia de vídeo atual com base nos vetores de movimento e outros elementos de sintaxe recebidos a partir da unidade de decodificação por entropia 70. Os blocos preditivos podem ser produzidos a partir de uma das imagens de referência dentro de uma das listas de imagens de referência. O decodificador de vídeo 30 pode construir as listas de quadro de referência, Lista 0 e Lista 1, que usa as técnicas desta revelação com base nas imagens de referência armazenadas no armazenamento temporário de imagem decodificado 82. A unidade de compensação de movimento 72 determina informações de predição para um bloco de vídeo da fatia de vídeo atual analisando-se os vetores de movimento e outros elementos de sintaxe, e usa as informações de predição para produzir os blocos preditivos para o bloco de vídeo atual em decodificação. Por exemplo, a unidade de compensação de modo 72 usa uma parte dos elementos de sintaxe recebidos para determinar um modo de predição (por exemplo, intra ou interpredição) usado para codificar os blocos de vídeo da fatia de vídeo, um tipo de fatia de interpredição (por exemplo, fatia B, fatia P ou fatia GPB), informações de construção para uma ou mais dentre as listas de imagens de referência para a fatia, vetores de movimento para cada bloco codificado intervídeo da fatia, situações de interpredição para cada bloco de vídeo intercriptografado da fatia e outras informações para decodificar os blocos de vídeo na fatia de vídeo atual.
[0246] A unidade de compensação de movimento 72 também pode realizar interpolação com base em filtros de interpolação. A unidade de compensação de movimento 72 por usar filtros de interpolação conforme usado pelo criptografador de vídeo 20 durante a criptação dos blocos de vídeo para calcular valores interpolados para pixels subinteiros de blocos de referência. Nesse caso, a unidade de compensação de modo 72 pode determinar os filtros de interpolação usados pelo criptografador de vídeo a partir dos elementos de sintaxe recebidos e usar os filtros de interpolação para produzir blocos preditivos.
[0247] A unidade de quantização inversa 76 quantiza inversamente, isto é, desquantiza, o coeficiente de transformada quantizado fornecido no fluxo de bits e decodificado pela unidade de decodificação por entropia 70. O processo de quantização inversa pode incluir o uso de um parâmetro de quantização QPy calculado pelo decodificador de vídeo 30 para cada bloco de vídeo na fatia de vídeo para determinar um grau de quantização e, de modo similar, um grau de quantização inversa que deve ser aplicado.
[0248] A unidade processamento de transformada inversa 78 aplica uma transformada inversa, por exemplo, uma DCT inversa, uma transformada de número inteiro inversa ou um processo de transformada inversa conceitualmente similar, ao coeficiente de transformada a fim de produzir blocos residuais no domínio de pixels.
[0249] Após a unidade de compensação de movimento 72 gerar o bloco preditivo para o bloco de vídeo atual com base nos vetores de movimento e outros elementos de sintaxe, o decodificador de vídeo 30 forma um bloco de vídeo decodificado somando-se os blocos residuais provenientes da unidade de processamento de transformada inversa 78 com os blocos preditivos correspondentes gerados pela unidade de compensação de movimento 72. O somador 90 representa o componente ou os componentes que realizam essa operação de soma. A unidade filtro de laço 63 pode incluir um filtro de desblocagem e um filtro SAO para filtrar as delimitações de bloco para remover os artefatos de bloqueio do vídeo reconstruído. Filtros adicionais (em laço ou pós- laço) também podem ser usados adicionalmente ao filtro de desbloqueio. Tais filtros não são mostrados para propósitos de brevidade, mas caso desejado, podem filtrar o resultado do somador 80 (como um filtro em laço). Os blocos de vídeo decodificados em um quadro ou imagem dados são, então, armazenados no armazenamento temporário de imagem decodificada 82, que armazena imagens de referência usadas para a composição de movimento subsequente. O armazenamento temporário de imagem decodificada 82 também armazena o vídeo decodificado para a apresentação posterior em um dispositivo de exibição, tal como dispositivo de exibição 32 da Figura 1.
[0250] Conforme será discutido em maiores detalhes abaixo em relação às Figuras 24 a 26, o decodificador de vídeo 30 pode ser configurado para empregar as técnicas desta revelação descrita acima. Em particular, o decodificador de vídeo 30 pode ser configurado para partição de PUs em sub-blocos quando tais PUs são particionados de acordo com um modo de partição assimétrico. O decodificador de vídeo 30 pode, então, ser configurado para herdar e/ou derivar vetores de movimento ou vetores de movimento de disparidade para cada um dos sub-blocos.
[0251] A Figura 21 é um fluxograma que ilustra um método de criptação exemplificativo da revelação. As técnicas da Figura 21 podem ser implantadas por uma ou mais unidades estruturais de criptografador de vídeo 20, tais como pela unidade de seleção de modo 41, unidade de partição 48 e/ou unidade de compensação de movimento 44.
[0252] Em um exemplo da revelação, o criptografador de vídeo 20 (por exemplo, que usa unidade de seleção de modo 41 e unidade de partição 48) pode ser configurado para gerar um bloco de dados de vídeo com o uso de AMP, em que o bloco de dados de vídeo é previsto unidirecionalmente com o uso de BVSP, e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16 (2100). Em um exemplo da revelação, o bloco de dados de vídeo é uma unidade de predição.
[0253] O criptografador de vídeo 20, que usa unidade de partição 48, pode ser configurado adicionalmente para particionar o bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8 (2110), e deriva (por exemplo, com o uso da unidade de compensação de movimento 44) um vetor de movimento de disparidade respectivo para cada um dos sub-blocos a partir de um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência (2120). O criptografador de vídeo 20 (por exemplo, que usa a unidade de compensação de movimento 44) pode ser configurado adicionalmente para sintetizar um bloco de referência respectivo para cada um dos sub-blocos com o uso dos vetores de movimento de disparidade derivados respectivos (2130), e criptar (por exemplo, com o uso de unidade de compensação de movimento 44) o bloco de dados de vídeo pela realização da compensação de movimento em cada um dos sub-blocos com o uso dos blocos de referência respectivos sintetizados (2140).
[0254] Em outro exemplo da revelação, o criptografador de vídeo 20 pode ser configurado adicionalmente para gerar um ou mais elementos de sintaxe que indicam que a unidade de predição é criptada com o uso de AMP, e que indica que a unidade de predição é prevista unidirecionalmente com o uso de BVSP, e gerar um índice de candidato de mescla que aponta para um candidato de BVSP.
[0255] Em outro exemplo da revelação, o criptografador de vídeo 20 (por exemplo, que usa a unidade de compensação de movimento 44) pode ser configurado para derivar o vetor de movimento de disparidade respectivo para cada um dos sub-blocos derivando-se um vetor de disparidade para o bloco de dados de vídeo, localizar o bloco de profundidade correspondente para cada um dos sub-blocos com o uso do vetor de disparidade derivado, e converter um valor de profundidade selecionado do bloco de profundidade correspondente para cada um dos sub-blocos ao vetor de movimento de disparidade respectivo.
[0256] A Figura 22 é um fluxograma que ilustra outro método de criptação exemplificativo da revelação. As técnicas da Figura 22 podem ser implantadas por uma ou mais unidades estruturais de criptografador de vídeo 20, que incluem unidade de seleção de modo 41, unidade de partição 48 e/ou unidade de compensação de movimento 44.
[0257] Em um exemplo da revelação, o criptografador de vídeo 20 (por exemplo, unidade de seleção de modo 41 e unidade de partição 48) pode ser configurado para gerar um segundo bloco de dados de vídeo com o uso de AMP, em que o segundo bloco de dados de vídeo é criptografado com o uso de pelo menos uma dentre a predição de movimento entre vistas ou MVI, e tem um tamanho de 16x4 ou 4x16 (2200). O criptografador de vídeo 20 (por exemplo, que usa unidade de partição 48) pode ser configurado adicionalmente para particionar o segundo bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8 (2210), e derivar (por exemplo, com o uso da unidade de compensação de movimento 44) informações de movimento para cada um dos sub-blocos de um bloco de referência respectivo (2220). O criptografador de vídeo 20 pode, então, criptar o segundo bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub-blocos que usa as informações de movimento derivadas e uma lista de imagens de referência (2230).
[0258] Em outro exemplo da revelação, o criptografador de vídeo (por exemplo, que usa a unidade de compensação de movimento 44) pode ser configurado para realizar a compensação de movimento pela realização de compensação de movimento unidirecional relativo a uma imagem na uma lista de imagens de referência.
[0259] A Figura 23 é um fluxograma que ilustra outro método de criptação exemplificativo da revelação. As técnicas da Figura 23 podem ser implantadas por uma ou mais unidades estruturais de criptografador de vídeo 20, tais como pela unidade de seleção de modo 41, unidade de partição 48 e/ou unidade de compensação de movimento 44.
[0260] Em um exemplo da revelação, o criptografador de vídeo 20 pode ser configurado para gerar (por exemplo, com o uso da unidade de seleção de modo 41 e da unidade de partição 48) um segundo bloco de dados de vídeo com o uso de AMP, em que o segundo bloco de dados de vídeo é criptografado com o uso de pelo menos uma dentre a predição de movimento entre vistas ou a herança de vetor de movimento, e tem um tamanho de 16x12 ou 12x16 (2300), particionar (por exemplo, com o uso da unidade de partição 48) do segundo bloco de dados de vídeo em múltiplos sub-blocos (2310), e criptar (por exemplo, com o uso de unidade de compensação de movimento 44) de cada um dos múltiplos sub-blocos com predição unipreditiva (2320).
[0261] A Figura 24 é um fluxograma que ilustra um método de decodificação exemplificativo da revelação. As técnicas da Figura 24 podem ser implantadas por uma ou mais unidades estruturais de decodificador de vídeo 30, tais como pela unidade de compensação de movimento 72.
[0262] Em um exemplo da revelação, o decodificador de vídeo 30 pode ser configurado para receber dados residuais correspondentes a um bloco de dados de vídeo, em que o bloco de dados de vídeo é criptografado com o uso de AMP, é previsto unidirecionalmente com o uso de BVSP e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16 (2400). Em um exemplo da revelação, o bloco de dados de vídeo é uma unidade de predição. O decodificador de vídeo 30, pode ser configurado adicionalmente para particionar o bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8 (2410), e deriva um vetor de movimento de disparidade respectivo para cada um dos sub-blocos a partir de um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência (2420).
[0263] O decodificador de vídeo 30 pode ser configurado adicionalmente para sintetizar um bloco de referência respectivo para cada um dos sub-blocos com o uso dos vetores de movimento de disparidade derivados respectivos (2430), e decodificar o bloco de dados de vídeo pela realização da compensação de movimento em cada um dos sub-blocos com o uso dos dados residuais e dos blocos de referência respectivos sintetizados (2440).
[0264] Em outro exemplo da revelação, decodificador de vídeo 30 pode ser configurado adicionalmente para receber um ou mais elementos de sintaxe que indicam que a unidade de predição é criptada com o uso de partição de movimento assimétrico, e que indica que a unidade de predição é prevista unidirecionalmente com o uso de predição de síntese de vista retrógrada, e receber um índice de candidato de mescla que aponta para um candidato de BVSP.
[0265] Em outro exemplo da revelação, o decodificador de vídeo 30 pode ser configurado adicionalmente para derivar o vetor de movimento de disparidade respectivo para cada um dos sub-blocos derivando-se um vetor de disparidade para o bloco de dados de vídeo, localizar o bloco de profundidade correspondente para cada um dos sub-blocos com o uso do vetor de disparidade derivado, e converter um valor de profundidade selecionado do bloco de profundidade correspondente para cada um dos sub-blocos ao vetor de movimento de disparidade respectivo.
[0266] A Figura 25 é um fluxograma que ilustra um método de decodificação exemplificativo da revelação. As técnicas da Figura 23 podem ser implantadas por uma ou mais unidades estruturais de decodificador de vídeo 30, tais como pela unidade de compensação de movimento 72.
[0267] Em um exemplo da revelação, o decodificador de vídeo 30 pode ser configurado para receber dados residuais correspondentes a um segundo bloco de dados de vídeo, em que o segundo bloco de dados de vídeo é criptografado com o uso de pelo menos uma dentre a predição de movimento entre vistas ou a MVI, e tem um tamanho de 16x4 ou de 4x16 (2500), particionar o segundo bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8 (2510), derivar as informações de movimento para cada um dos sub-blocos a partir de um bloco de referência respectivo (2520), e decodificar o segundo bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub-blocos com o uso dos dados residuais, das informações de movimento derivadas, e de uma lista de imagens de referência.
[0268] Em outro exemplo da revelação, o decodificador de vídeo 30 pode ser configurado adicionalmente para realizar a compensação de movimento pela realização de compensação de movimento unidirecional relativo a uma imagem na uma lista de imagens de referência.
[0269] A Figura 26 é um fluxograma que ilustra um método de decodificação exemplificativo da revelação. As técnicas da Figura 23 podem ser implantadas por uma ou mais unidades estruturais de decodificador de vídeo 30, incluindo a unidade de compensação de movimento 72.
[0270] Em um exemplo da revelação, o decodificador de vídeo 30 pode ser configurado adicionalmente para receber dados residuais correspondentes a um segundo bloco de dados de vídeo, em que o segundo bloco de dados de vídeo é criptografado com o uso de pelo menos uma dentre a predição de movimento entre vistas ou a MVI, e tem um tamanho de 16x12 ou de 12x16 (2600), particionar o segundo bloco de dados de vídeo em múltiplos sub-blocos (2610), e decodificar cada um dos múltiplos sub-blocos com predição unipreditiva.
[0271] Conforme explicado acima, as técnicas desta revelação incluem criptação e decodificação de vídeo ao aplicar AMP, BVSP, previsões de movimento entre vistas e/ou MVI nos blocos de dados de vídeo. Em particular, as técnicas desta revelação fornecem codificação mais precisa direcionando-se técnicas de codificação para os sub-blocos de PUs particionados com AMP. Por exemplo, a obtenção de vetores de movimento de disparidade separados para sub- blocos de uma PU particionada com AMP quando tal PU é codificada com o uso de BVSP pode aumentar a precisão de sínteses de vista e predição de movimento, e, desse modo, a eficácia de codificação. Como outro exemplo, a obtenção de informações de movimento separadas para sub-blocos de uma PU particionado com AMP quando tal PU é codificado com o uso de predição de movimento entre vistas e/ou MVI pode aumentar a precisão de predição de movimento, e, desse modo, a eficácia de codificação.
[0272] Deve ser reconhecido que, dependendo do exemplo, certos atos ou eventos de quaisquer uma dentre as técnicas descritas no presente documento podem ser realizados em uma sequência diferente, podem ser adicionados, fundidos ou deixados de fora todos juntos (por exemplo, nem todos os atos e eventos descritos são necessários para a prática das técnicas). Ademais, em certos exemplos, os atos e eventos podem ser realizados de modo concorrente, por exemplo, através de processamento multifiletado, processamento interrupto ou em múltiplos processadores, em vez de sequencialmente.
[0273] Em um ou mais exemplos, as funções descritas podem ser implantadas em hardware, software, firmware ou qualquer combinação dos mesmos. Caso implantado em software, as funções podem ser armazenadas em, ou transmitidas sobre, como uma ou mais instruções ou código em um meio legível por computador e executadas por uma unidade de processamento com base em hardware. As mídias legíveis por computador podem incluir mídias de armazenamento legíveis por computador, que correspondem a uma mídia tangível como mídias de armazenamento de dados ou mídias de comunicação que incluem qualquer mídia que facilite a transferência de um programa de computador proveniente de um lugar para outro, por exemplo, de acordo com um protocolo de comunicação. Desse modo, as mídias legíveis por computador geralmente podem corresponder a (1) mídias tangíveis de armazenamento legíveis por computador que sejam não transitórias ou (2) um meio de comunicação tal como um sinal ou onda portadora As mídias de armazenamento de dados podem ser quaisquer mídias disponíveis que possam ser acessadas por um ou mais computadores ou um ou mais processadores para recuperar instruções, estruturas de código e/ou dados para a implantação das técnicas descritas nessas revelação. Um produto de programa de computador pode incluir uma mídia legível por computador.
[0274] A título de exemplo, e não de limitação, tais mídias de armazenamento legíveis por computador podem compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento de disco óptico, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser usado para armazenar o código de programa desejado na forma de instruções ou estruturas de dados e que possa ser acessado por um computador. Também, qualquer conexão pode ser propriamente denominada um meio legível por computador. Por exemplo, se as instruções forem transmitidas a partir de um sítio da web, servidor ou outra fonte remota com o uso de um cabo coaxial, cabo de fibra óptica, par trançado, linha de inscrição digital (DSL) ou tecnologias sem fio como infravermelho, rádio e micro-onda, então, o cabo coaxial, o cabo de fibra óptica, o par trançado, a DSL ou as tecnologias sem fio como infravermelho, rádio e microonda estão incluídos na definição de mídia. Deve ser entendido, entretanto, que as mídias de armazenamento legíveis por computador e as mídias de armazenamento de dados não incluem conexões, ondas transportadoras, sinais ou outras mídias transitórias, mas são, em vez disso, direcionadas para mídias não transientes e tangíveis. Disco magnético e disco óptico, conforme usado no presente documento, incluem disco compacto (CD), disco laser, disco ótico, disco versátil digital (DVD), disquete e disco blu- ray, em que os discos magnéticos normalmente reproduzem os dados de modo magnético, enquanto os discos ópticos reproduzem os dados de modo óptico com lasers. As combinações dos supracitados também devem ser abrangidas pelo escopo de meios legíveis por computador.
[0275] As instruções podem ser executadas por um ou mais processadores, como um ou mais processadores de sinal digital (DSPs), microprocessadores para propósitos gerais, circuitos integrados de aplicação específica (ASICs), matrizes lógicas programáveis por campo (FPGAs) ou outro conjunto de circuitos lógicos equivalentes integrados ou discretos. Portanto, o termo “processador”, conforme usado no presente documento pode se referir a qualquer uma das estruturas supracitadas ou qualquer outra estrutura adequada para a implantação das técnicas descritas no presente documento. Adicionalmente, em alguns aspectos, a funcionalidade descrita no presente documento pode ser fornecida dentro de módulos dedicados de hardware e/ou software configurados para criptar e decodificar ou incorporados em um codec combinado. Também, as técnicas podem ser totalmente implantadas em um ou mais circuitos ou elementos lógicos.
[0276] As técnicas desta revelação podem ser implantadas em uma ampla variedade de dispositivos ou aparelhos, incluindo um monofone, um circuito integrado (IC) ou um conjunto de ICs (por exemplo, um conjunto de chips). Vários componentes, módulos ou unidades são descritos nesta revelação para enfatizar os aspectos funcionais dos dispositivos configurados para realizar as técnicas reveladas, mas não exigem necessariamente a realização por diferentes unidades de hardware. Em vez disso, conforme descrito acima, várias unidades podem ser combinadas em uma unidade de hardware de codec ou fornecidas por uma coleção de unidades de hardware interoperativos, incluindo um ou mais processadores conforme descrito acima, em conjunto com software e/ou firmware adequados.
[0277] Vários exemplos foram descritos. Esses e outros exemplos estão dentro do escopo das reivindicações a seguir.

Claims (15)

1. Método de decodificação de dados de vídeo, o método caracterizado pelo fato de que compreende: receber dados residuais correspondentes a um bloco de dados de vídeo, em que o bloco de dados de vídeo é codificado com o uso de partição de movimento assimétrico, é previsto unidirecionalmente com o uso de predição de síntese de visão retroativa (BVSP), e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16, e em que o bloco de dados de vídeo é uma unidade de predição de uma unidade de codificação; particionar o bloco de dados de vídeo em sub- blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8; derivar um vetor de movimento de disparidade respectivo para cada um dos sub-blocos a partir de um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência; sintetizar um bloco de referência respectivo para cada um dos sub-blocos que usa os vetores de movimento de disparidade derivados respectivos; e decodificar o bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub- blocos que usa os dados residuais e os blocos de referência respectivos sintetizados.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: receber um ou mais elementos de sintaxe indicando que a unidade de predição está codificada com o uso de partição de movimento assimétrico, e indicando que a unidade de predição está prevista unidirecionalmente com o uso de predição de síntese de visão retroativa; e receber um índice de candidato de fusão que aponta para um candidato de BVSP.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que derivar o vetor de movimento de disparidade respectivo para cada um dos sub-blocos compreende: derivar um vetor de disparidade para o bloco de dados de vídeo; localizar o bloco de profundidade correspondente para cada um dos sub-blocos que usa o vetor de disparidade derivado; e converter um valor de profundidade selecionado do bloco de profundidade correspondente para cada um dos sub- blocos para o vetor de movimento de disparidade respectivo.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o bloco de dados de vídeo é um primeiro bloco de dados de vídeo, o método compreendendo adicionalmente: receber dados residuais correspondentes a um segundo bloco de dados de vídeo, em que o segundo bloco de dados de vídeo é codificado com o uso de pelo menos uma dentre a predição de movimento entre vistas ou a herança de vetor de movimento, e tem um tamanho de 16x4 ou 4x16; particionar o segundo bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8; derivar as informações de movimento para cada um dos sub-blocos a partir de um bloco de referência respectivo; e decodificar o segundo bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub-blocos que usa os dados residuais, as informações de movimento derivadas, e uma lista de imagens de referência.
5. Método, de acordo com a reivindicação 4, caracterizado pelo fato de que a realização de compensação de movimento compreende realizar a compensação de movimento unidirecional em relação a uma imagem em uma lista de imagens de referência.
6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o bloco de dados de vídeo é um primeiro bloco de dados de vídeo, o método compreendendo adicionalmente: receber dados residuais correspondentes a um segundo bloco de dados de vídeo, em que o segundo bloco de dados de vídeo é codificado com o uso de pelo menos uma dentre a predição de movimento entre vistas ou a herança de vetor de movimento, e tem um tamanho de 16x12 ou 12x16; particionar o segundo bloco de dados de vídeo em múltiplos sub-blocos; e decodificar cada um dos múltiplos sub-blocos com predição unipreditiva.
7. Método de codificação de dados de vídeo, o método caracterizado pelo fato de que compreende: gerar um bloco de dados de vídeo que usa partição de movimento assimétrico, em que o bloco de dados de vídeo é previsto unidirecionalmente que usa predição de síntese de visão retroativa, BVSP, e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16, e em que o bloco de dados de vídeo é uma unidade de predição de uma unidade de codificação; particionar o bloco de dados de vídeo em sub- blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8; derivar um vetor de movimento de disparidade respectivo para cada um dos sub-blocos a partir de um bloco de profundidade correspondente em uma imagem de profundidade correspondente a uma imagem de referência; sintetizar um bloco de referência respectivo para cada um dos sub-blocos usando os vetores de movimento de disparidade derivados respectivos; e codificar o bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub- blocos usando os blocos de referência respectivos sintetizados.
8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que compreende adicionalmente: gerar um ou mais elementos de sintaxe que indicam que a unidade de predição é codificada com o uso de partição de movimento assimétrico, e indica que a unidade de predição é prevista unidirecionalmente com o uso de predição de síntese de visão retroativa; e gerar um índice de candidato de fusão que aponta para um candidato de BVSP.
9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que derivar o vetor de movimento de disparidade respectivo para cada um dos sub-blocos compreende: derivar um vetor de disparidade para o bloco de dados de vídeo; localizar o bloco de profundidade correspondente para cada um dos sub-blocos usando o vetor de disparidade derivado; e converter um valor de profundidade selecionado do bloco de profundidade correspondente para cada um dos sub- blocos para o vetor de movimento de disparidade respectivo.
10. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que o bloco de dados de vídeo é um primeiro bloco de dados de vídeo, o método compreendendo adicionalmente: gerar um segundo bloco de dados de vídeo que usa a partição de movimento assimétrico, em que o segundo bloco de dados de vídeo é codificado usando pelo menos uma dentre a predição de movimento entre vistas ou a herança de vetor de movimento, e tem um tamanho de 16x4 ou 4x16; particionar o segundo bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8; derivar as informações de movimento para cada um dos sub-blocos a partir de um bloco de referência respectivo; e codificar o segundo bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub- blocos usando as informações de movimento derivadas e uma lista de imagens de referência.
11. Método, de acordo com a reivindicação 10, caracterizado pelo fato de que a realização de compensação de movimento compreende realizar a compensação de movimento unidirecional em relação a uma imagem em uma lista de imagens de referência.
12. Aparelho configurado para decodificar dados de vídeo, o aparelho caracterizado pelo fato de que compreende: uma memória de vídeo configurada para armazenar informações correspondentes a um bloco de dados de vídeo; e um ou mais processadores configurados para: receber dados residuais correspondentes ao bloco de dados de vídeo, em que o bloco de dados de vídeo é codificado usando partição de movimento assimétrico, é previsto unidirecionalmente usando predição de síntese de visão retroativa, BVSP, e tem um tamanho de 16x12, 12x16, 16x4 ou 4x16, e em que o bloco de dados de vídeo é uma unidade de predição de uma unidade de codificação; particionar o bloco de dados de vídeo em sub- blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8; derivar um vetor de movimento de disparidade respectivo para cada um dos sub-blocos a partir de um sub- bloco correspondente de um bloco de profundidade em uma imagem de profundidade correspondente a uma imagem de referência; sintetizar um bloco de referência respectivo para cada um dos sub-blocos que usa os vetores de movimento de disparidade derivados respectivos; e decodificar o bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub- blocos que usa os dados residuais e os blocos de referência respectivos sintetizados.
13. Aparelho, de acordo com a reivindicação 12, caracterizado pelo fato de que os um ou mais processadores são configurados adicionalmente para: receber um ou mais elementos de sintaxe indicando que a unidade de predição é codificada com o uso de partição de movimento assimétrico, e indicando que a unidade de predição é prevista unidirecionalmente com o uso de predição de síntese de visão retroativa; e receber um índice de candidato de fusão que aponta para um candidato de BVSP.
14. Aparelho, de acordo com a reivindicação 12, caracterizado pelo fato de que os um ou mais processadores são configurados adicionalmente para: derivar um vetor de disparidade para o bloco de dados de vídeo; localizar o bloco de profundidade correspondente para cada um dos sub-blocos que usa o vetor de disparidade derivado; e converter um valor de profundidade selecionado do bloco de profundidade correspondente para cada um dos sub- blocos para o vetor de movimento de disparidade respectivo.
15. Aparelho, de acordo com a reivindicação 12, caracterizado pelo fato de que o bloco de dados de vídeo é um primeiro bloco de dados de vídeo, e em que o um ou mais processadores são configurados adicionalmente para: receber dados residuais correspondentes a um segundo bloco de dados de vídeo, em que o segundo bloco de dados de vídeo é codificado usando pelo menos uma dentre a predição de movimento entre vistas ou a herança de vetor de movimento, e tem um tamanho de 16x4 ou 4x16; particionar o segundo bloco de dados de vídeo em sub-blocos, em que cada sub-bloco tem um tamanho de 8x4 ou 4x8; derivar as informações de movimento para cada um dos sub-blocos a partir de um bloco de referência respectivo; e decodificar o segundo bloco de dados de vídeo pela realização de compensação de movimento em cada um dos sub-blocos que usa os dados residuais, as informações de movimento derivadas, e uma lista de imagens de referência.
BR112016007760-1A 2013-09-13 2014-09-12 Método e aparelho de decodificação de dados de vídeo e método de codificação de dados de vídeo BR112016007760B1 (pt)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201361877793P 2013-09-13 2013-09-13
US61/877,793 2013-09-13
US201361881383P 2013-09-23 2013-09-23
US61/881,383 2013-09-23
US14/483,983 US10244253B2 (en) 2013-09-13 2014-09-11 Video coding techniques using asymmetric motion partitioning
US14/483,983 2014-09-11
PCT/US2014/055456 WO2015038937A1 (en) 2013-09-13 2014-09-12 Video coding techniques using asymmetric motion partitioning

Publications (2)

Publication Number Publication Date
BR112016007760A2 BR112016007760A2 (pt) 2018-07-10
BR112016007760B1 true BR112016007760B1 (pt) 2023-05-09

Family

ID=51626619

Family Applications (1)

Application Number Title Priority Date Filing Date
BR112016007760-1A BR112016007760B1 (pt) 2013-09-13 2014-09-12 Método e aparelho de decodificação de dados de vídeo e método de codificação de dados de vídeo

Country Status (12)

Country Link
US (1) US10244253B2 (pt)
EP (1) EP3044961B1 (pt)
JP (1) JP6535673B2 (pt)
KR (1) KR102099494B1 (pt)
CN (1) CN105637870B (pt)
BR (1) BR112016007760B1 (pt)
CL (1) CL2016000576A1 (pt)
ES (1) ES2799323T3 (pt)
HK (1) HK1220060A1 (pt)
HU (1) HUE048759T2 (pt)
SG (2) SG11201600785VA (pt)
WO (1) WO2015038937A1 (pt)

Families Citing this family (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106231342B (zh) * 2010-04-13 2019-05-31 三星电子株式会社 执行去块滤波的对视频进行解码的方法
CN110650336B (zh) * 2012-01-18 2022-11-29 韩国电子通信研究院 视频解码装置、视频编码装置和传输比特流的方法
US9300977B2 (en) * 2013-10-02 2016-03-29 Amlogic Co., Ltd. Methods for encoding motion vectors
US9906813B2 (en) * 2013-10-08 2018-02-27 Hfi Innovation Inc. Method of view synthesis prediction in 3D video coding
WO2015056719A1 (ja) * 2013-10-16 2015-04-23 シャープ株式会社 画像復号装置、画像符号化装置
WO2015062002A1 (en) * 2013-10-31 2015-05-07 Mediatek Singapore Pte. Ltd. Methods for sub-pu level prediction
WO2015100710A1 (en) * 2014-01-02 2015-07-09 Mediatek Singapore Pte. Ltd. Existence of inter-view reference picture and availability of 3dvc coding tools
US20160048701A1 (en) * 2014-08-18 2016-02-18 Spatial Digital Systems, Inc. Enveloping for remote Digital Camera
WO2016179303A1 (en) * 2015-05-04 2016-11-10 Kamama, Inc. System and method of vehicle sensor management
US10271064B2 (en) * 2015-06-11 2019-04-23 Qualcomm Incorporated Sub-prediction unit motion vector prediction using spatial and/or temporal motion information
US10009620B2 (en) * 2015-06-22 2018-06-26 Cisco Technology, Inc. Combined coding of split information and other block-level parameters for video coding/decoding
US10560718B2 (en) * 2016-05-13 2020-02-11 Qualcomm Incorporated Merge candidates for motion vector prediction for video coding
CN109417629B (zh) * 2016-07-12 2023-07-14 韩国电子通信研究院 图像编码/解码方法以及用于该方法的记录介质
CN109983776B (zh) * 2016-11-18 2023-09-29 株式会社Kt 视频信号处理方法和设备
US11284076B2 (en) 2017-03-22 2022-03-22 Electronics And Telecommunications Research Institute Block form-based prediction method and device
US10595035B2 (en) * 2017-03-22 2020-03-17 Qualcomm Incorporated Constraining motion vector information derived by decoder-side motion vector derivation
CN109327699B (zh) * 2017-07-31 2021-07-16 华为技术有限公司 一种图像的处理方法、终端和服务器
CN109429064B (zh) * 2017-08-22 2021-03-30 华为技术有限公司 一种视频数据的编解码方法、装置和介质
CN118055227A (zh) * 2017-09-29 2024-05-17 Lx 半导体科技有限公司 图像编码/解码方法、存储介质及图像数据的发送方法
US10785494B2 (en) * 2017-10-11 2020-09-22 Qualcomm Incorporated Low-complexity design for FRUC
WO2019234578A1 (en) 2018-06-05 2019-12-12 Beijing Bytedance Network Technology Co., Ltd. Asymmetric weighted bi-predictive merges
WO2019245841A1 (en) * 2018-06-18 2019-12-26 Interdigital Vc Holdings, Inc. Method and apparatus for video encoding and decoding based on asymmetric binary partitioning of image blocks
KR20210028651A (ko) 2018-07-17 2021-03-12 파나소닉 인텔렉츄얼 프로퍼티 코포레이션 오브 아메리카 비디오 코딩을 위한 움직임 벡터 예측
RU2757209C1 (ru) 2018-08-29 2021-10-12 Бейджинг Дацзя Интернет Информейшн Текнолоджи Ко., Лтд. Способы и устройства для кодирования видео с использованием вектора движения временного предсказания на основе субблоков
WO2020070729A1 (en) * 2018-10-06 2020-04-09 Beijing Bytedance Network Technology Co., Ltd. Size restriction based on motion information
WO2020084476A1 (en) 2018-10-22 2020-04-30 Beijing Bytedance Network Technology Co., Ltd. Sub-block based prediction
WO2020084553A1 (en) 2018-10-24 2020-04-30 Beijing Bytedance Network Technology Co., Ltd. Motion candidate derivation based on multiple information in sub-block motion vector prediction
EP3847814A4 (en) * 2018-11-06 2021-07-14 Beijing Bytedance Network Technology Co. Ltd. POSITION DEPENDENT STORAGE, MOVEMENT INFORMATION
CN117459722A (zh) 2018-11-12 2024-01-26 北京字节跳动网络技术有限公司 组合帧间-帧内预测的简化
EP3861742A4 (en) 2018-11-20 2022-04-13 Beijing Bytedance Network Technology Co., Ltd. DIFFERENCE CALCULATION BASED ON SPATIAL POSITION
WO2020103870A1 (en) 2018-11-20 2020-05-28 Beijing Bytedance Network Technology Co., Ltd. Inter prediction with refinement in video processing
KR102660160B1 (ko) 2018-11-22 2024-04-24 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 서브 블록 기반 인터 예측을 위한 조정 방법
KR20210099129A (ko) * 2018-12-21 2021-08-11 샤프 가부시키가이샤 비디오 코딩에서 인터 예측을 수행하기 위한 시스템들 및 방법들
US20220086475A1 (en) * 2019-01-09 2022-03-17 Lg Electronics Inc. Method and device for signaling whether tmvp candidate is available
US11140406B2 (en) * 2019-02-20 2021-10-05 Qualcomm Incorporated Signalling for merge mode with motion vector differences in video coding
WO2020177755A1 (en) 2019-03-06 2020-09-10 Beijing Bytedance Network Technology Co., Ltd. Usage of converted uni-prediction candidate
US10742972B1 (en) * 2019-03-08 2020-08-11 Tencent America LLC Merge list construction in triangular prediction
EP3922014A4 (en) 2019-04-02 2022-04-06 Beijing Bytedance Network Technology Co., Ltd. DECODER SIDE MOTION VECTOR BYPASS
CN114208184A (zh) 2019-08-13 2022-03-18 北京字节跳动网络技术有限公司 基于子块的帧间预测中的运动精度
CN114424553A (zh) 2019-09-22 2022-04-29 北京字节跳动网络技术有限公司 基于子块的帧间预测的缩放方法
US11375231B2 (en) * 2020-01-14 2022-06-28 Tencent America LLC Method and apparatus for video coding

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8769584B2 (en) 2009-05-29 2014-07-01 TVI Interactive Systems, Inc. Methods for displaying contextually targeted content on a connected television
US8648297B2 (en) * 2011-07-21 2014-02-11 Ohio University Coupling of liquid chromatography with mass spectrometry by liquid sample desorption electrospray ionization (DESI)
EP2742690B1 (en) * 2011-08-08 2016-07-27 Google Technology Holdings LLC Residual tree structure of transform unit partitioning
KR102647848B1 (ko) * 2012-02-04 2024-03-15 엘지전자 주식회사 비디오 인코딩 방법, 비디오 디코딩 방법 및 이를 이용하는 장치
JP6787667B2 (ja) * 2012-09-21 2020-11-18 ノキア テクノロジーズ オサケユイチア ビデオコーディングのための方法と装置
US9716899B2 (en) 2013-06-27 2017-07-25 Qualcomm Incorporated Depth oriented inter-view motion vector prediction

Also Published As

Publication number Publication date
CN105637870B (zh) 2018-11-20
EP3044961A1 (en) 2016-07-20
KR102099494B1 (ko) 2020-04-09
US20150078450A1 (en) 2015-03-19
SG11201600785VA (en) 2016-03-30
JP2016530848A (ja) 2016-09-29
EP3044961B1 (en) 2020-03-18
JP6535673B2 (ja) 2019-06-26
CL2016000576A1 (es) 2016-11-18
KR20160055229A (ko) 2016-05-17
HK1220060A1 (zh) 2017-04-21
US10244253B2 (en) 2019-03-26
ES2799323T3 (es) 2020-12-16
WO2015038937A1 (en) 2015-03-19
HUE048759T2 (hu) 2020-08-28
SG10201802026TA (en) 2018-04-27
BR112016007760A2 (pt) 2018-07-10
CN105637870A (zh) 2016-06-01

Similar Documents

Publication Publication Date Title
ES2842109T3 (es) Predicción residual avanzada basada en bloques para la codificación de vídeo 3D
ES2799323T3 (es) Técnicas de codificación de vídeo usando particionamiento de movimiento asimétrica
US10567789B2 (en) Simplified shifting merge candidate and merge list derivation in 3D-HEVC
KR102112900B1 (ko) 심도 지향 인터-뷰 모션 벡터 예측
EP2976884B1 (en) Simplifications on disparity vector derivation and motion vector prediction in 3d video coding
US9609347B2 (en) Advanced merge mode for three-dimensional (3D) video coding
US9699450B2 (en) Inter-view predicted motion vector for 3D video
KR102264104B1 (ko) 백워드 뷰 합성 예측
ES2669399T3 (es) Vector de movimiento predicho entre visualizaciones para vídeo 3D
BR112020014522A2 (pt) Derivação aprimorada de vetor de movimento no lado de decodificador
US20140071235A1 (en) Inter-view motion prediction for 3d video
BR112016006607B1 (pt) Método e dispositivo para processamento de dados de vídeo, e memória legível por computador
BR112016006574B1 (pt) Predição de vetor de movimento temporal com base em unidade de subpredição (pu) em hevc e projeto de sub-pu em 3d-hevc
BR112016000866B1 (pt) Processamento de compensação de iluminação para codificação de vídeo
WO2014205343A1 (en) More accurate advanced residual prediction (arp) for texture coding
KR101672008B1 (ko) 변이 벡터 예측 방법 및 장치
BR112016013489B1 (pt) Sinalização de codificação de profundidade simplificada (sdc) para modos de inter e intrapredição em codificação de vídeo 3d

Legal Events

Date Code Title Description
B06F Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]
B06U Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 12/09/2014, OBSERVADAS AS CONDICOES LEGAIS