BR112021012163A2

BR112021012163A2 - Método de decodificação de dados de vídeo, método de codificação de dados de vídeo, e dispositivo

Info

Publication number: BR112021012163A2
Application number: BR112021012163-3A
Authority: BR
Inventors: Kiran Mukesh Misra; Frank Bossen; Christopher Andrew Segall
Original assignee: Sharp Kabushiki Kaisha; FG Innovation Company Limited
Priority date: 2018-12-21
Filing date: 2019-12-17
Publication date: 2021-08-31
Also published as: KR20210099129A; EP3900354A4; US20230308675A1; US20220078460A1; EP3900354A1; US11706437B2; WO2020129950A1; CN113170188A

Abstract

método de decodificação de dados de vídeo, método de codificação de dados de vídeo, e dispositivo. a presente invenção refere-se a um método de decodificar dados de vídeo por um dispositivo. um sinalizador de sub-bloco de integração especificando se parâmetros de interpredição baseado em sub-bloco para uma unidade de codificação são inferidos a partir de blocos vizinhos é decodificado. um sinalizador de integração de diferença de vetor de movimento é decodificado se um valor do sinalizador de sub-bloco de integração for igual a zero e um valor de um sinalizador de diferença de vetor de movimento for igual a um. o sinalizador de integração de diferença de vetor de movimento especifica um parâmetro de predição com uma diferença de vetor de movimento é usado, e o sinalizador de diferença de vetor de movimento especifica se um modo de integração com diferença de vetor de movimento é usado está habilitado.

Description

Relatório Descritivo da Patente de Invenção para "MÉTO- DO DE DECODIFICAÇÃO DE DADOS DE VÍDEO, MÉTODO DE CO- DIFICAÇÃO DE DADOS DE VÍDEO, E DISPOSITIVO". REFERÊNCIA CRUZADA COM OUTRO(S) PEDIDO(S)

[001] A presente divulgação é um pedido de estágio nacional do Pedido de Patente Internacional PCT/JP2019/049315, depositado em 17 de setembro de 2019, atualmente publicado como WO2020/129950, que reivindica o benefício e prioridade do Pedido de Patente Provisório U.S. de número serial 62/784.014, depositado em 21 de setembro de 2018, os conteúdos do qual são todos aqui incorpo- rados em sua totalidade como referência da presente divulgação.

CAMPO TÉCNICO

[002] A presente invenção refere-se à codificação de vídeo e, mais particularmente, às técnicas para executar interpredição.

ANTECEDENTES DA INVENÇÃO

[003] As capacidades de vídeo digital podem ser incorporadas a uma ampla gama de dispositivos, incluindo televisores digitais, compu- tadores de mesa ou laptop, computadores tipo tablet, dispositivos de gravação digital, reprodutores de mídia digital, dispositivos de video- game, telefones celulares, incluindo os chamados smartphones, dis- positivos de imageamento médico e similares. O vídeo digital pode ser codificado de acordo com um padrão de codificação de vídeo. Os pa- drões de codificação de vídeo podem incorporar técnicas de compres- são de vídeo. Exemplos de padrões de codificação de vídeo incluem ISO/IEC MPEG-4 Visual e UIT-T H.264 (também conhecido como ISO/IEC MPEG-4 AVC) e codificação de vídeo de alta eficiência (HEVC, ou High-Efficiency Video Coding). A HEVC é descrita em High Efficiency Video Coding (HEVC), Rec. ITU-T H.265, dezembro de 2016, que está aqui incorporada a título de referência, e chamada de ITU-T H.265. Extensões e melhorias para UIT-T H.265 estão atual-

mente sendo consideradas para o desenvolvimento da próxima gera- ção de padrões de codificação de vídeo.

Por exemplo, o grupo de es- pecialistas em codificação de vídeo UIT-T (VCEG, ou Video Coding Experts Group) e ISO/IEC (grupo de especialistas em imagens com movimento (MPEG, ou Moving Picture Experts Group)) (coletivamente chamados de equipe conjunta de exploração de vídeo (JVET, ou Joint Video Exploration Team)) estão estudando a potencial necessidade de padronização da tecnologia futura de codificação de vídeo com uma capacidade de compressão que excede significativamente a do padrão HEVC atual.

O modelo de exploração conjunta 7 (JEM 7, ou Joint Ex- ploration Model 7), a descrição do algoritmo do modelo de teste de ex- ploração conjunta 7 (JEM 7), documento ISO/IEC JTC1/SC29/WG11: JVET-G1001, julho de 2017, Turim, IT, que está incorporado a título de referência na presente invenção, descreve os recursos de codificação sob estudo de modelo de teste coordenado pela JVET como potenci- almente aprimorando a tecnologia de codificação de vídeo além das capacidades de ITU-T H.265. Deve-se notar que os recursos de codifi- cação de JEM 7 são implementados no software de referência de JEM.

Como usado na presente invenção, o termo JEM pode se referir coletivamente a algoritmos incluídos em JEM 7 e implementações de software de referência de JEM.

Além disso, em resposta a uma "Cha- mada conjunta para propostas sobre compressão de vídeo com capa- cidades além de HEVC" ("Joint Call for Proposals on Video Compres- sion with Capabilities beyond HEVC"), conjuntamente emitida por VCEG e MPEG, múltiplas descrições de codificação de vídeo foram propostas por vários grupos no 10° Encontro de ISO/IEC JTC1/SC29/WG11, 16 a 20 de abril de 2018, San Diego, CA, EUA.

Como resultado das múltiplas descrições de codificação de vídeo, um texto preliminar de uma especificação de codificação de vídeo é des- crito em "Versatile Video Coding (VVC) (Draft 1)", 10° Encontro de

ISO/IEC JTC1/SC29/WG11, 16 a 20 de abril de 2018, San Diego, CA, EUA, documento JVET-J1001-v2, que está incorporado a título de re- ferência na presente invenção e chamado de JVET-J1001. O "Versati- le Video Coding (Draft 2)", 11° Encontro de ISO/IEC JTC1/SC29/WG11, 10 a 18 de julho de 2018, Ljubljana, Eslovênia, do- cumento JVET-K1001-v7, que está incorporado a título de referência na presente invenção e chamado de JVET-K1001, é uma atualização do JVET-J1001. Além disso, o "Versatile Video Coding (Draft 3)", 12° Encontro de ISO/IEC JTC1/SC29/WG11, 3 a 12 de outubro de 2018, Macau, China, documento JVET-L1001-v6, que está incorporado a tí- tulo de referência na presente invenção e chamado de JVET-L1001, é uma atualização do JVET-K1001.

[004] As técnicas de compressão de vídeo possibilitam que os requisitos de dados para armazenar e transmitir dados de vídeo sejam reduzidos. As técnicas de compressão de vídeo podem reduzir os re- quisitos de dados ao explorarem as redundâncias inerentes em uma sequência de vídeo. As técnicas de compressão de vídeo podem sub- dividir uma sequência de vídeo em porções sucessivamente menores (isto é, grupos de quadros dentro de uma sequência de vídeo, um quadro dentro de um grupo de quadros, regiões dentro de um quadro, blocos de vídeo dentro de uma região e sub-blocos dentro de um bloco de vídeo). As técnicas de codificação de intraprevisão (por exemplo intraimagem (espacial)) e técnicas de interpredição (isto é, interima- gens (temporal)) podem ser usadas para gerar valores de diferença entre uma unidade de dados de vídeo a ser codificada e uma unidade de referência de dados de vídeo. Os valores de diferença podem ser chamados de dados residuais. Os dados residuais podem ser codifi- cados como coeficientes de transformada quantizados. Elementos de sintaxe podem se referir a dados residuais e a uma unidade de codifi- cação de referência (por exemplo índices de modo intraprevisão, veto-

res de movimento e vetores de bloco). Dados residuais e elementos de sintaxe podem ser codificados por entropia. Dados residuais e elemen- tos de sintaxe codificados por entropia podem ser incluídos em um flu- xo de bits compatível. Fluxos de bits compatíveis e metadados associ- ados podem ser formatados de acordo com estruturas de dados.

SUMÁRIO DA INVENÇÃO

[005] Em um exemplo, um método de decodificação de dados de vídeo, sendo que o método compreende: decodificar um sinalizador de sub-bloco integrado que especifica se os parâmetros de interpredição baseados em sub-bloco para uma unidade de codificação são inferidos a partir de blocos vizinhos; e decodificar um sinalizador integrado de diferença de vetor de movimento, se um valor do sinalizador de sub- bloco integrado é igual a zero e um valor de um sinalizador de diferen- ça de vetor de movimento é igual a um, sendo que o sinalizador inte- grado de diferença de vetor de movimento especifica um parâmetro de previsão com uma diferença de vetor de movimento que é utilizado, e o sinalizador de diferença de vetor de movimento especifica se um modo de integração com a diferença de vetor de movimento es- tá habilitado.

[006] Em um exemplo, um método de codificação de dados de vídeo, sendo que o método compreende: codificar um sinalizador de sub-bloco de integração que especifica se parâmetros de interpredição baseados em sub-bloco para uma unidade de codificação são inferidos a partir de blocos vizinhos; e codificar um sinalizador de integração de diferença de vetor de movimento, se um valor do sinalizador de sub- bloco de integração for igual a zero e um valor de um sinalizador de diferença de vetor de movimento for igual a um, sendo que o sinaliza- dor de integração de diferença de vetor de movimento especifica um parâmetro de previsão com uma diferença de vetor de movimento que é utilizado, e o sinalizador de diferença de vetor de movimento especi-

fica se um modo de integração com diferença de vetor de movimento está habilitado.

BREVE DESCRIÇÃO DOS DESENHOS

[007] [Figura 1] a Figura 1 é um diagrama conceitual que ilustra um exemplo de um grupo de imagens codificadas de acordo com um particionamento em árvore quádrupla, múltiplas árvores, de acordo com uma ou mais técnicas da presente divulgação.

[008] [Figura 2A] A Figura 2A é um diagrama conceitual que ilus- tra um exemplo de codificação de um bloco de dados de vídeo, de acordo com uma ou mais técnicas da presente divulgação.

[009] [Figura 2B] A Figura 2B é um diagrama conceitual que ilus- tra um exemplo de codificação de um bloco de dados de vídeo, de acordo com uma ou mais técnicas da presente divulgação.

[0010] [Figura 3] A Figura 3 é um diagrama conceitual que ilustra a posição de blocos de vídeo vizinhos para inclusão em um conjunto de candidatos a preditores de vetores de movimento de acordo com uma ou mais técnicas da presente divulgação.

[0011] [Figura 4] A Figura 4 é um diagrama conceitual que ilustra os blocos de vídeo vizinhos de posição para inclusão em um conjunto de preditores de vetores de movimento candidatos de acordo com uma ou mais técnicas da presente divulgação.

[0012] [Figura 5] A Figura 5 é um diagrama de blocos que ilustra um exemplo de um sistema que pode ser configurado para codificar e decodificar dados de vídeo de acordo com uma ou mais técnicas desta divulgação.

[0013] [Figura 6] A Figura 6 é um diagrama de blocos que ilustra um exemplo de um codificador de vídeo que pode ser configurado pa- ra codificar dados de vídeo de acordo com uma ou mais técnicas desta divulgação.

[0014] [Figura 7] A Figura 7 é um diagrama de blocos que ilustra um exemplo de um decodificador de vídeo que pode ser configurado para decodificar dados de vídeo de acordo com uma ou mais técnicas desta divulgação.

DESCRIÇÃO DAS MODALIDADES

[0015] Em geral, esta divulgação descreve várias técnicas para codificar dados de vídeo. Em particular, esta divulgação descreve téc- nicas para interpredição em codificação de vídeo. Em particular, esta divulgação descreve técnicas para indicar se várias ferramentas de interpredição estão habilitadas ou desabilitadas para codificação de vídeo. A indicação de se várias ferramentas de interpredição estão ha- bilitadas ou desabilitadas, de acordo com as técnicas aqui descritas, pode ser particularmente útil para sinalizar eficientemente a técnica de previsão usada para codificar um bloco de vídeo atual. Deve-se notar que, embora as técnicas desta divulgação sejam descritas com rela- ção a ITU-T H.264, ITU-T H.265, JVET-J1001, JVET-K1001, e JVET- L1001, as técnicas desta divulgação são geralmente aplicáveis a codi- ficação de vídeo. Por exemplo, as técnicas de codificação descritas na presente invenção podem ser incorporadas a sistemas de codificação de vídeo, (incluindo sistemas de codificação de vídeo baseados em futuros padrões de codificação de vídeo) incluindo estruturas em blo- co, técnicas de intraprevisão, técnicas de interpredição, técnicas de transformada, técnicas de filtragem e/ou técnicas de codificação por entropia que não aquelas incluídas em UIT-T H.265. Dessa forma, a referência a ITU-T H.264, ITU-T H.265, JVET-J1001, JVET-K1001, e JVET-L1001 é para propósitos descritivos e não deve ser interpretada como limitadora do escopo das técnicas descritas na presente inven- ção. Além disso, deve-se notar que a incorporação a título de referên- cia de documentos na presente invenção não deve ser interpretada para limitar ou criar ambiguidade com relação a termos usados na pre- sente invenção. Por exemplo, no caso em que uma referência incorpo-

rada fornece uma definição diferente de um termo que outra referência incorporada e/ou como o termo é usado na presente invenção, o termo deve ser interpretado de uma maneira que inclua amplamente cada respectiva definição e/ou de uma maneira que inclua cada uma das definições específicas na alternativa.

[0016] Em um exemplo, um método para executar interpredição para codificação de dados de vídeo compreende determinar se os pa- râmetros de previsão baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, sinalizar um sinalizador que especifica se os parâmetros de previsão baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e sinalizar condicionalmente um sinalizador que especifica se um mo- do de integração com valores de diferença de vetor de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador que especifica se os parâme- tros interpredição baseados em sub-bloco para um bloco de vídeo atu- al são inferidos a partir de blocos vizinhos.

[0017] Em um exemplo, um dispositivo compreende um ou mais processadores configurados para determinar se os parâmetros de in- terpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, sinalizar um sinalizador que espe- cifica se os parâmetros de interpredição com base em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e si- nalizar condicionalmente um sinalizador que especifica se um modo de integração com valores de diferença de vetor de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador que especifica se os parâmetros interpre- dição baseados em sub-bloco para um bloco de vídeo atual são inferi- dos a partir de blocos vizinhos.

[0018] Em um exemplo, uma mídia de armazenamento não transi-

tório legível por computador compreende instruções armazenadas na mesma que, quando executadas, fazem com que um ou mais proces- sadores de um dispositivo determinem se os parâmetros de interpredi- ção baseados em sub-bloco para um bloco de vídeo atual são inferi- dos a partir de blocos vizinhos, sinalizar um sinalizador que especifica se os parâmetros de interpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e sinali- zar condicionalmente um sinalizador que especifica se um modo de integração com valores de diferença de vetor de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador que especifica se os parâmetros de inter- predição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos.

[0019] Em um exemplo, um aparelho compreende meios para de- terminar se os parâmetros de interpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, meios para sinalizar um sinalizador que especifica se os parâmetros de interpredição com base no sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e meios para sinalizar condi- cionalmente um sinalizador que especifica se um modo de integração com valores de diferença de vetores de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador que especifica se os parâmetros de interpredi- ção baseados em sub-blocos para um bloco de vídeo atual são inferi- dos a partir de blocos vizinhos.

[0020] Em um exemplo, um método para executar interpredição para codificação de dados de vídeo compreende analisar um sinaliza- dor que especifica se os parâmetros de interpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e analisar condicionalmente um sinalizador que especifica se um modo de integração com valores de diferença de vetor de movi- mento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador analisado que especifica se os parâmetros de interpredição baseados em um bloco de vídeo atual são inferidos a partir de blocos vizinhos.

[0021] Em um exemplo, um dispositivo compreende um ou mais processadores para analisar um sinalizador que especifica se os pa- râmetros de interpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e analisar condici- onalmente um sinalizador que especifica se um modo de integração com valores de diferença de vetor de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador analisado que especifica se os parâmetros de interpre- dição baseados em um bloco de vídeo atual são inferidos a partir de blocos vizinhos.

[0022] Em um exemplo, uma mídia de armazenamento não transi- tório legível por computador compreende instruções armazenadas na mesma que, quando executadas, fazem com que um ou mais proces- sadores de um dispositivo analisem um sinalizador que especifica se os parâmetros de interpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e analisar con- dicionalmente um sinalizador que especifica se um modo de integra- ção com valores de diferença de vetor de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador analisado que especifica se os parâmetros de interpredição baseados em um bloco de vídeo atual são inferidos a partir de blocos vizinhos.

[0023] Em um exemplo, um aparelho compreende meios para ana- lisar um sinalizador que especifica se os parâmetros de interpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e meios para analisar condicionalmente um sinalizador que especifica se um modo de integração com valores de diferença de vetor de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador analisado que especifica se os parâmetros de interpredição baseados em um bloco de vídeo atual são inferidos a partir de blocos vizinhos.

[0024] Os detalhes de um ou mais exemplos são apresentados nos desenhos em anexo e na descrição abaixo. Outros recursos, obje- tivos e vantagens ficarão evidentes a partir da descrição e dos dese- nhos, bem como a partir das reivindicações.

[0025] O conteúdo de vídeo inclui tipicamente sequências de vídeo que compreendem uma série de quadros (ou figuras). Uma série de quadros pode ser chamada também de grupo de imagens (GOP, ou group of pictures). Cada quadro ou imagem de vídeo pode ser dividido em uma ou mais regiões. As regiões podem ser definidas de acordo com uma unidade de base (por exemplo, um bloco de vídeo) e conjun- tos de regras que definem uma região (por exemplo, uma região preci- sa ser um número inteiro de blocos de vídeo dispostos em um retângu- lo). Como utilizado na presente invenção, o termo bloco de vídeo pode se referir genericamente a uma área de uma imagem ou pode, mais especificamente, se referir à maior matriz de valores de amostra que pode ser preditivamente codificada, subdivisões da mesma e/ou estru- turas correspondentes. Além disso, o termo bloco de vídeo atual pode se referir a uma área de uma imagem sendo codificada ou decodifica- da. Um bloco de vídeo pode ser definido como uma matriz de valores de amostra que podem ser codificados de modo preditivo. Deve-se notar que, em alguns casos, os valores de pixel podem ser descritos como incluindo valores de amostra para os respectivos componentes de dados de vídeo, que podem também ser chamados de componen- tes de cor (por exemplo, componentes luma (Y) e saturação (Cb e Cr)

ou componentes vermelho, verde e azul). Deve-se notar que, em al- guns casos, os termos valor de pixel e valor de amostra são utilizados de forma intercambiável. Adicionalmente, em alguns casos, um pixel ou amostra pode ser chamado de pel. Um formato de amostragem de vídeo, que também pode ser chamado de formato de saturação, pode definir o número de amostras de saturação incluídas em um bloco de vídeo em relação ao número de amostras de componente luma incluí- das em um bloco de vídeo. Por exemplo, para o formato de amostra- gem 4:2:0, a taxa de amostragem para o componente luma é duas ve- zes aquela dos componentes croma para ambas as direções, horizon- tal e vertical. Como resultado, para um bloco de vídeo formatado de acordo com o formato 4:2:0, a largura e altura de uma matriz de amos- tras para o componente luma são duas vezes aquelas de cada matriz de amostras para os componentes de saturação. Para um bloco de vídeo formatado de acordo com o formato 4:2:2, a largura de uma ma- triz de amostras para o componente luma é duas vezes a largura de uma matriz de amostras para cada componente de saturação, mas a altura da matriz de amostras para o componente luma é igual à altura de uma matriz de amostras para cada componente de saturação. Além disso, para um bloco de vídeo formatado de acordo com o formato 4:4:4, uma matriz de amostras para o componente luma tem a mesma largura e altura que uma matriz de amostras para cada componente de saturação.

[0026] Os blocos de vídeo podem ser ordenados dentro de uma imagem e/ou uma região, de acordo com um padrão de varredura (por exemplo uma varredura raster). Um codificador de vídeo pode execu- tar codificação preditiva em blocos de vídeo e subdivisões dos mes- mos. Os blocos de vídeo e subdivisões dos mesmos podem ser cha- mados de nós. ITU-T H.264 especifica um macrobloco que inclui 16x16 amostras de luma. Ou seja, em ITU-T H.264, uma imagem é segmentada em macroblocos. ITU-T H.265 especifica uma estrutura de Unidade de Árvore de Codificação análoga (CTU - Coding Tree Unit) (também chamada de maior unidade de codificação (LCU - lar- gest coding unit)). Em ITU-T H.265, as imagens são segmentadas em CTUs. Em ITU-T H.265, para uma imagem, um tamanho de CTU pode ser definido como incluindo amostras de luma 16x16, 32x32 ou 64x64. Em UIT-T H.265, uma CTU é composta por respectivos Blocos de Ár- vore de Codificação (CTBs - Coding Tree Blocks) para cada compo- nente de dados de vídeo (por exemplo luma (Y) e saturação (Cb e Cr)). Além disso, em UIT-T H.265, uma CTU pode ser particionada de acordo com uma estrutura de particionamento quadtree (QT), o que resulta nos CTBs da CTU sendo particionados em blocos de codifica- ção (CB). Ou seja, em UIT-T H.265, uma CTU pode ser particionada em nós folhas de quadtree. De acordo com UIT-T H.265, um CB de luma juntamente com dois CBs de croma correspondentes e elemen- tos de sintaxe associados são chamados de unidade de codificação (CU, ou coding unit). Em UIT-T H.265, um tamanho mínimo permitido de um CB pode ser sinalizado. Em UIT-T H.265, o menor tamanho mí- nimo permitido de um CB de luma é de amostras de luma de 8x8. Em UIT-T H.265, a decisão de codificar uma área de imagem com o uso de intraprevisão ou interpredição é feita no nível de CU.

[0027] Em UIT-T H.265, uma CU é associada a uma estrutura de unidade de previsão (PU, ou prediction unit) que tem sua raiz na CU. Em UIT-T H.265, estruturas de PU possibilitam que CBs de luma e croma sejam divididos para propósitos de gerar amostras de referência correspondentes. Ou seja, em UIT-T H.265, CBs de luma e croma po- dem ser divididos em respectivos blocos de previsão (PBs, ou predic- tion blocks) de luma e croma, em que um PB inclui um bloco de valo- res de amostra para que a mesma previsão seja aplicada. Em UIT-T H.265, um CB pode ser particionado em 1, 2 ou 4 PBs. UIT-T H.265 suporta tamanhos de PB de amostras de 64 x 64 até amostras de 4 x

4. Em UIT-T H.265, PBs quadrados são suportados para intraprevisão, sendo que um CB pode formar o PB ou o CB pode ser dividido em quatro PBs quadrados (isto é, tipos de PB de intraprevisão incluem M x M ou M/2 x M/2, em que M é a altura e a largura do CB quadrado). Em UIT-T H.265, além dos PBs quadrados, PBs retangulares são su- portadas para interpredição, em que um CB pode ser reduzido pela metade vertical ou horizontalmente para formar PBs (isto é, os tipos de PB de interpredição incluem M x M, M/2 x M/2, M/2 x M ou M x M/2). Além disso, deve-se notar que em UIT-T H.265, para interpredição, quatro partições assimétricas de PB são suportadas, em que o CB é particionado em dois PBs com 1 quarto da altura (no topo ou no fundo) ou da largura (na esquerda ou na direita) do CB (isto é, partições as- simétricas incluem M/4 x M esquerda, M/4 x M direita, M x M/4 topo e M x M/4 fundo). Dados de intraprevisão (por exemplo elementos de sintaxe de modo de intraprevisão) ou dados de interpredição (por exemplo elementos de sintaxe de dados de movimento) corresponden- tes a um PB são usados para produzir valores de amostra previstos e/ou de referência para o PB.

[0028] Conforme descrito acima, cada quadro ou imagem de vídeo pode ser dividido em uma ou mais regiões. Por exemplo, de acordo com a norma ITU-T H.265, cada quadro ou imagem de vídeo pode ser particionado de modo a incluir uma ou mais fatias, e adicionalmente particionado para incluir um ou mais ladrilhos, sendo que cada fatia inclui uma sequência de CTUs (por exemplo, em ordem de varredura raster) e sendo que um ladrilho é uma sequência de CTUs que corres- ponde a uma área retangular de uma imagem. Deve-se notar que uma fatia, em ITU-T H.265, é uma sequência de um ou mais segmentos de fatia começando com um segmento de fatia independente e contendo todos os segmentos de fatia dependentes subsequentes (se houver algum) que precedem o próximo segmento de fatia independente (se houver algum) na mesma unidade de acesso. Um segmento de fatia, como uma fatia, é uma sequência de CTUs. Dessa forma, em alguns casos, os termos fatia e segmento de fatia podem ser utilizados de forma intercambiável para indicar uma sequência de CTUs. Adicional- mente, deve-se notar que em ITU-T H.265, um ladrilho pode consistir em CTUs contidas em mais de uma fatia e uma fatia pode consistir em unidades de árvore de codificação contidas em mais de um ladrilho. No entanto, ITU-T H.265 prevê que uma ou ambas as condições a se- guir devem ser cumpridas: (1) Todas as CTUs em uma fatia pertencem ao mesmo ladrilho; e (2) Todas as CTUs em um ladrilho pertencem à mesma fatia. Com relação a JVET-L1001, são necessárias fatias que consistem de um número inteiro de ladrilhos completos, em vez de ser necessário que consistam apenas de um número inteiro de CTUs completas. Como tal, uma fatia que inclui um conjunto de CTUs que não formam uma região retangular de uma imagem pode ou não ser suportada em algumas técnicas de codificação de vídeo. Além disso, uma fatia que é necessária para consistir em um número inteiro de la- drilhos completos é chamada de grupo de ladrilhos. As técnicas descri- tas na presente invenção podem ser aplicáveis a fatias, ladrilhos e/ou grupos de ladrilhos. A Figura 1 é um diagrama conceitual que ilustra um exemplo de um grupo de imagens que inclui grupos de ladrilhos. No exemplo ilustrado na Figura 1, a Pic3 é ilustrada como incluindo dois grupos de ladrilhos (isto é, Grupo de Ladrilhos1 e Grupo de Ladri- lhos2). Deve-se notar que, em alguns casos, o grupo de ladrilhos1 e o grupo de ladrilhos2 podem ser classificados como fatias e/ou ladrilhos, uma vez que cada um atende aos requisitos de uma fatia e um ladri- lho.

[0029] JEM especifica uma CTU que tem um tamanho máximo de amostras de luma de 256 x 256. JEM especifica uma estrutura de blo-

co de quadtree mais árvore binária (QTBT, ou quadtree plus binary tree). Em JEM, a estrutura QTBT habilita nós folhas de quadtree a se- rem adicionalmente particionados por uma estrutura de árvore binária (BT, ou binary tree). Ou seja, em JEM, a estrutura de árvore binária habilita nós folhas de quadtree a serem recursivamente divididos verti- cal ou horizontalmente. Em JVET-L1001, as CTUs são particionadas de acordo com uma estrutura de "quadtree" mais árvore de múltiplos tipos (QTMT - quadtree plus multi-type tree). A QTMT em JVET-L1001 é similar a QTBT em JEM. Entretanto, em JVET-L1001, além de indi- car divisões binárias, a árvore de múltiplos tipos pode indicar as cha- madas divisões ternárias (ou de árvore tripla (TT - triple tree)). Uma divisão ternária divide um bloco vertical ou horizontalmente em três blocos. No caso de uma divisão TT vertical, um bloco é dividido em um quarto de sua largura a partir da borda esquerda e em um quarto de sua largura a partir da borda direita e no caso de uma divisão TT hori- zontal, um bloco está em um quarto de sua altura a partir da borda su- perior e em um quarto de sua altura a partir da borda inferior. Nova- mente com referência à Figura 1, a Figura 1 ilustra um exemplo de uma CTU sendo dividida em nós de folha da "quadtree" e nós de folha da "quadtree" sendo adicionalmente particionados de acordo com uma divisão BT ou uma divisão TT. Ou seja, na Figura 1, as linhas traceja- das indicam divisões binárias e ternárias adicionais em uma "qua- dtree".

[0030] Conforme descrito acima, dados de intraprevisão ou dados de interpredição são utilizados para produzir valores de amostra de referência para um bloco de vídeo atual. A diferença entre valores de amostra incluídos em uma previsão gerada a partir dos valores de amostra de referência e do bloco de vídeo atual pode ser chamada de dados residuais. Os dados residuais podem incluir as respectivas ma- trizes de valores de diferença correspondentes a cada componente de dados de vídeo. Os dados residuais podem estar no domínio de pixel. Uma transformada, como uma transformada discreta de cosseno (DCT), uma transformada discreta de seno (DST), uma transformada de número inteiro, uma transformada de ondeleta ou uma transforma- da conceitualmente similar, pode ser aplicada a uma matriz de valores de diferença de pixel para gerar coeficientes de transformada. Deve-se notar que em ITU-T H.265 e JVET-L 1001, uma UC é associada a uma estrutura de unidade de transformada (TU, ou transform unit) que tem sua raiz no nível de UC. Ou seja, uma matriz de valores de diferença pode ser particionada para fins de geração de coeficientes de trans- formada (por exemplo, quatro transformadas 8x8 podem ser aplicadas a uma matriz 16x16 de valores residuais). Para cada componente de dados de vídeo, tais subdivisões de valores de diferença podem ser chamadas de blocos de transformação (Tbs - Transform Blocks). De- ve-se notar que em alguns casos, uma transformada de núcleo e uma transformada secundária subsequente podem ser aplicadas (no codifi- cador de vídeo) para gerar coeficientes de transformada. Para um de- codificador de vídeo, a ordem de transformadas é invertida.

[0031] Um processo de quantização pode ser executado em coefi- cientes de transformada. A quantificação essencialmente escala coefi- cientes de transformada para variar a quantidade de dados necessá- rios para representar um grupo de coeficientes de transformação. A quantificação pode incluir divisão de coeficientes de transformação por um fator de escala de quantificação e qualquer função de arredonda- mento associada (por exemplo, arredondamento para o próximo intei- ro). Coeficientes de transformada quantizados podem ser chamados de valores de nível de coeficiente. A quantificação inversa (ou "des- quantificação") pode incluir a multiplicação de valores de nível de coe- ficiente pelo fator de escala de quantificação. Deve-se notar que, como utilizado na presente invenção, o termo processo de quantificação em alguns casos pode se referir à divisão por um fator de escala para ge- rar valores de nível e a multiplicação por um fator de escala para recu- perar coeficientes de transformada em alguns casos. Ou seja, um pro- cesso de quantização pode se referir a quantização em alguns casos e quantização inversa em alguns casos.

[0032] As Figuras 2A e 2 B são diagramas conceituais que ilus- tram exemplos de codificação de um bloco de dados de vídeo. Con- forme ilustrado na Figura 2A, um bloco atual de dados de vídeo é codi- ficado mediante a geração de um resíduo, subtraindo-se um conjunto de valores de previsão do bloco atual de dados de vídeo, realizando- se uma transformação neste residual e quantificando-se os coeficien- tes de transformada para gerar valores de nível. Conforme ilustrado na Figura 2B, o bloco atual de dados de vídeo é decodificado mediante a execução de quantificação inversa em valores de nível, execução de uma transformada inversa e a adição de um conjunto de valores de predição ao residual resultante. Deve-se notar que, nos exemplos nas Figuras 2A e 2B, os valores de amostra do bloco reconstruído diferem dos valores de amostra do bloco de vídeo atual que é codificado. Des- sa maneira, pode-se dizer que a codificação se dá com perdas. Entre- tanto, a diferença nos valores de amostra pode ser considerada acei- tável e/ou imperceptível para um observador do vídeo reconstruído. Adicionalmente, conforme ilustrado nas Figuras 2A e 2B, a alteração de escala é realizada com o uso de uma matriz de fatores de alteração de escala.

[0033] Conforme ilustrado na Figura 2A, os coeficientes de trans- formada quantificados são codificados em um fluxo de bits. Os coefici- entes de transformada quantificados e os elementos de sintaxe (por exemplo, elementos de sintaxe que indicam uma estrutura de codifica- ção para um bloco de vídeo) podem ser codificados por entropia de acordo com uma técnica de codificação por entropia. Exemplos de técnicas de codificação por entropia incluem codificação de compri- mento variável adaptável de conteúdo (CAVLC - content adaptive vari- able length coding), codificação aritmética binária adaptativa de con- texto (CABAC - context adaptive binary arithmetic coding), codificação de entropia de particionamento de intervalo de probabilidade (PIPE - probability interval partitioning entropy coding) e similares.

Coeficientes de transformada quantificados codificados por entropia e elementos de sintaxe codificados por entropia correspondentes podem formar um fluxo de bits compatível que pode ser utilizado para reproduzir dados de vídeo em um decodificador de vídeo.

Um processo de codificação por entropia pode incluir executar uma binarização em elementos de sintaxe.

Binarização se refere ao processo de converter um valor de um valor de sintaxe em uma série de um ou mais bits.

Esses bits po- dem ser chamados de "bins". A binarização é um processo sem per- das e pode incluir uma ou uma combinação das seguintes técnicas de codificação: codificação de comprimento fixo, codificação unária, codi- ficação unária truncada, codificação Rice truncada, codificação de Go- lomb, codificação exponencial de Golomb de ordem k, e codificação de Golomb-Rice.

Por exemplo, a binarização pode incluir representar o valor de número inteiro de 5 para um elemento de sintaxe como 00000101 com o uso de uma técnica de binarização de comprimento fixo de 8 bits ou representar o valor de número inteiro de 5 como 11110 com o uso de uma técnica de binarização de codificação unária.

Como usado aqui, cada um dos termos de codificação de comprimento fixo, codificação unária, codificação unária truncada, codificação de Rice truncada, codificação de Golomb, codificação de Golomb expo- nencial de k-ésima ordem e codificação de Golomb-Rice pode se refe- rir a implementações gerais dessas técnicas e/ou implementações mais específicas dessas técnicas de codificação.

Por exemplo, uma implementação de codificação de Golomb-Rice pode ser especifica-

mente definida de acordo com um padrão de codificação de vídeo, por exemplo, ITU-T H.265.

[0034] Um processo de codificação de entropia inclui adicional- mente codificar valores de escaninho com o uso de algoritmos de compressão de dados sem perdas. No exemplo de um CABAC, para um escaninho específico, um modelo de contexto pode ser seleciona- do dentre um conjunto de modelos de contexto disponíveis associados ao escaninho. Em alguns exemplos, um modelo de contexto pode ser selecionado com base em um escaninho anterior e/ou valores de ele- mentos de sintaxe anteriores. Um modelo de contexto pode identificar a probabilidade de um escaninho ter um valor específico. Por exemplo, um modelo de contexto pode indicar uma probabilidade de 0,7 de codi- ficar um escaninho de valor 0. Após selecionar um modelo de contexto disponível, um codificador de entropia CABAC pode codificar aritmeti- camente um escaninho com base no modelo de contexto identificado. O modelo de contexto pode ser atualizado com base no valor de um escaninho codificado. O modelo de contexto pode ser atualizado com base em uma variável associada armazenada com o contexto, por exemplo, tamanho da janela de adaptação, número de escaninhos co- dificados com o uso do contexto. Deve-se notar que um codificador de entropia CABAC pode ser implementado, de modo que alguns elemen- tos de sintaxe possam ser codificados por entropia com o uso de codi- ficação aritmética sem o uso de um modelo de contexto explicitamente atribuído, sendo que tal codificação pode ser chamada de codificação de desvio.

[0035] Conforme descrito acima, dados de intraprevisão ou dados de interpredição indicam como uma previsão é gerada para um bloco de vídeo atual. Para codificação de intraprevisão, um modo de intra- previsão pode especificar o local de amostras de referência dentro de uma imagem utilizada para gerar uma previsão. Em UIT-T H.265, mo-

dos de intraprevisão possíveis definidos incluem um modo de previsão plano (isto é, encaixe na superfície) (predMode: 0), um modo de previ- são DC (isto é, média geral plana) (predMode: 1) e 33 modos de previ- são angulares (predMode: 2 a 34). Em JVET-L1001, modos de intra- previsão possíveis definidos para luma incluem um modo de previsão plano (predMode: 0), um modo de previsão DC (predMode: 1) e 65 modos de previsão angulares (predMode: 2 a 66). Deve-se notar que modos de previsão plano e DC podem ser chamados de modos de previsão não direcionais e que modos de previsão angulares podem ser chamados de modos de previsão direcionais. Adicionalmente, po- de haver várias maneiras pelas quais os modos de intraprevisão para os componentes de saturação podem ser derivados com base no mo- do de intraprevisão para o componente luma. Deve-se notar que as técnicas descritas na presente invenção podem ser geralmente aplicá- veis independentemente do número de modos de previsão possíveis definidos.

[0036] Para codificação interpredição, uma ou mais imagens de- codificadas anteriormente, isto é, uma imagem de referência é deter- minada e um vetor de movimento (MV - motion vector) identifica amos- tras na imagem de referência que são usadas para gerar uma previsão para um bloco de vídeo atual. Por exemplo, pode ser previsto um blo- co de vídeo atual com o uso de valores de amostra de referência loca- lizados em uma ou mais imagens anteriormente codificadas e um vetor de movimento é utilizado para indicar a localização do bloco de refe- rência em relação ao bloco de vídeo atual. Um vetor de movimento pode descrever, por exemplo, um componente de deslocamento hori- zontal do vetor de movimento (isto é, MVx), um componente de deslo- camento vertical do vetor de movimento (isto é, MVy) e uma resolução para o vetor de movimento (por exemplo, precisão de um quarto de pixel, precisão de meio pixel, precisão de um pixel, precisão de dois pixels, precisão de quatro pixels). As imagens decodificadas anterior- mente, que podem incluir a produção de imagens antes ou depois de uma imagem atual, podem ser organizadas em uma ou mais listas de imagens de referência e identificadas com o uso de um valor de índice de imagem de referência.

Adicionalmente, na codificação interpredi- ção, a uniprevisão se refere a gerar uma previsão com o uso de valo- res de amostra a partir de uma única imagem de referência e a bipre- visão se refere a gerar uma previsão com o uso de respectivos valores de amostra a partir de duas imagens de referência.

Ou seja, em uni- previsão, uma única imagem de referência e vetor de movimento cor- respondente são utilizados para gerar uma previsão para um bloco de vídeo atual, e em biprevisão, uma primeira imagem de referência e um primeiro vetor de movimento correspondente e uma segunda imagem de referência e um segundo vetor de movimento correspondente são utilizados para gerar uma previsão para um bloco de vídeo atual.

Na biprevisão, os respectivos valores de amostra são combinados (por exemplo, adicionados, arredondados e cortados, ou ponderados de acordo com os pesos) para gerar uma previsão.

As imagens e regiões da mesma podem ser classificadas com base em quais tipos de mo- dos de previsão podem ser utilizados para codificar blocos de vídeo da mesma.

Ou seja, para regiões que têm um tipo B (por exemplo, uma fatia B), é possível utilizar os modos biprevisão, uniprevisão e intrapre- visão, para regiões que têm um tipo P (por exemplo, uma fatia P), é possível utilizar os modos de uniprevisão e intraprevisão, e para regi- ões que têm um tipo I (por exemplo, uma fatia I), apenas os modos de intraprevisão podem ser utilizados.

Conforme descrito acima, as ima- gens de referência são identificadas através de índices de referência.

Em ITU-T H.265, para uma fatia P, há uma única lista de imagem de referência, RefPicList0 e para uma fatia B, há uma segunda lista de imagem de referência independente, RefPicList1, em adição a RefPi-

cList0. Deve-se notar que para a uniprevisão em uma fatia B, pode-se usar um dentre RefPicList0 ou RefPicList1 para gerar uma previsão. Adicionalmente, deve-se notar que em ITU-T H.265, durante o proces- so de decodificação, no início da decodificação de uma imagem, a(s) lista(s) de imagem de referência é(são) gerada(s) a partir da imagem decodificada anteriormente armazenada em um buffer de imagem de- codificada (DPB - decoded picture buffer).

[0037] Adicionalmente, um padrão de codificação pode suportar vários modos de previsão de vetor de movimento. A predição do vetor de movimento possibilita que o valor de um vetor de movimento seja derivado com base em outro vetor de movimento. Exemplos de previ- são de vetor de movimento incluem previsão de vetor de movimento avançada (AMVP, ou advanced motion vector prediction), previsão de vetor de movimento temporal (TMVP, ou temporal motion vector pre- diction), o chamado modo de "integração" e a inferência de movimento de "pular" e "direcionar". Adicionalmente, outros exemplos de previsão de vetor de movimento incluem previsão de vetor de movimento tem- poral avançado (PVMTA - advanced temporal motion vector prediction) e previsão de vetor de movimento temporal espacial (PVMTA - Spatial- temporal motion vector prediction). ITU-T H.265 suporta dois modos para predição de vetor de movimento: um modo de integração e a chamada predição de vetor de movimento avançado (AMVP-Advanced Motion Vector Prediction). Em ITU-T H.265, tanto para o modo de inte- gração como para AMVP para um PB atual, é derivado um conjunto de blocos candidatos. Tanto um codificador de vídeo como um decodifi- cador de vídeo executam o mesmo processo para derivar um conjunto de candidatos. Dessa forma, para um bloco de vídeo atual, o mesmo conjunto de candidatos é gerado durante a codificação e decodifica- ção. Um bloco candidato inclui um bloco de vídeo que tem informa- ções de movimento associadas a partir das quais as informações de movimento utilizadas para gerar uma previsão para um bloco de vídeo atual podem ser derivadas. Para o modo de integração em ITU-T H.265, todas as informações de movimento (isto é, valores de deslo- camento de vetor de movimento, índices de imagem de referência e listas de imagem de referência) associadas a um candidato seleciona- do são herdadas como as informações de movimento para o PB atual. Ou seja, em um codificador de vídeo, um bloco candidato é seleciona- do a partir do conjunto derivado de candidatos e um valor de índice incluído no fluxo de bits indica o candidato selecionado e, dessa forma, indica as informações de movimento para o PB atual. Para AMVP em ITU-T H.265, as informações de vetor de movimento para o candidato selecionado são usadas como um preditor de vetor de movimento (MVP - motion vector predictor) para o vetor de movimento do PB atu- al. Ou seja, em um codificador de vídeo, um bloco candidato é seleci- onado a partir do conjunto derivado de candidatos e um valor de índice indicando o candidato selecionado e um valor delta (isto é, um delta do vetor de movimento (MVD)) indicando que a diferença entre o preditor do vetor de movimento e o vetor de movimento para o PB atual, são incluídos no fluxo de bits. Adicionalmente, para AMVP em ITU-T H.265, os elementos de sintaxe que identificam uma imagem de refe- rência são incluídos no fluxo de bits.

[0038] Em ITU-T H.265, um conjunto de blocos candidatos pode ser derivado de blocos vizinhos espaciais e blocos temporais. Adicio- nalmente, as informações de movimento geradas (ou padrão) podem ser usadas para a predição do vetor de movimento. Em ITU-T H.265, se as informações de movimento utilizadas para a previsão de vetor de movimento de um PB atual incluírem informações de movimento asso- ciadas a blocos vizinhos espaciais, as informações de movimento as- sociadas a blocos temporais, ou as informações de movimento gera- das dependerem do número de candidatos a serem incluídos em um conjunto, se a previsão do vetor de movimento temporal estiver habili- tada, da disponibilidade de blocos e/ou se as informações de movi- mento associadas aos blocos são redundantes.

[0039] Para o modo de integração em ITU-T H.265, um número máximo de candidatos que podem ser incluídos em um conjunto de blocos candidatos pode ser definido e sinalizado por um codificador de vídeo e pode ser de até cinco. Adicionalmente, um codificador de ví- deo pode desabilitar o uso de candidatos a vetores de movimento temporal (por exemplo, para reduzir a quantidade de recursos de me- mória necessários para armazenar informações de movimento em um decodificador de vídeo) e sinalizar se o uso de candidatos a vetores de movimento temporal está habilitado ou desabilitado para uma imagem. A Figura 3 ilustra a posição de blocos vizinhos espaciais e do bloco temporal que podem ser incluídos em um conjunto de blocos candida- tos para o modo de integração na ITU-T H.265. A derivação do conjun- to de candidatos para o modo de integração em ITU-T H.265 inclui de- terminar a disponibilidade de A1, B1, B0, A0 e B2. Deve-se notar que um bloco é considerado indisponível se for intraprevisto (isto é, se não tiver informações de movimento correspondentes) ou não estiver inclu- ído na fatia (ou ladrilho) atual. Após determinar a disponibilidade de A1, B1, B0, A0 e B2, é executado um conjunto de comparações (ilus- trado como setas tracejadas na Figura 3) para remover entradas re- dundantes do conjunto de candidatos. Por exemplo, B2 é comparado a B1 e se B1 tiver informações de movimento associadas que são iguais àquelas de B2, ele é removido do conjunto de candidatos. A remoção de entradas de um conjunto de candidatos pode ser chamada de pro- cesso de remoção. Deve-se notar que na Figura 3, para reduzir a complexidade, não é executada uma comparação completa dos candi- datos (por exemplo, A0 não é comparado com B0) e, dessa forma, é possível que entradas redundantes sejam incluídas no conjunto de candidatos.

[0040] Novamente com referência à Figura 3, o bloco denominado Temp se refere ao candidato temporal que pode estar incluído no con- junto de candidatos. Em ITU-T H.265 para modo de integração, para o candidato temporal, uma PU espacialmente colocalizada incluída em uma imagem de referência é definida e o candidato temporal inclui um bloco que tem uma posição logo fora da direita inferior da PU colocali- zada, se disponível, ou o bloco na posição central da PU colocalizada. Conforme descrito acima, um número máximo de candidatos que po- dem estar incluídos em um conjunto de blocos candidatos é definido. Se o número máximo de candidatos for definido como N, N-1 candida- tos espaciais e o candidato temporal for incluído no conjunto, nos ca- sos em que o número de candidatos espaciais disponíveis (após a su- pressão) e o candidato temporal é maior que ou igual a N. Nos casos em que o número de candidatos espaciais disponíveis (após redução) e candidato temporal é menor que N, as informações de movimento geradas são incluídas no conjunto para preencher o conjunto.

[0041] Para AMVP em ITU-T H.265, com referência à Figura 4, a derivação do conjunto de candidatos inclui a adição de um dentre A0 ou A1 (isto é, um candidato esquerdo) e um dentre B0, B1 ou B2 (um candidato acima) ao conjunto com base em sua disponibilidade. Ou seja, o primeiro candidato à esquerda disponível e o primeiro candida- to disponível acima são adicionados ao conjunto. Quando o candidato à esquerda e o candidato acima tiverem componentes vetoriais de movimento redundantes, um candidato redundante é removido do con- junto. Se o número de candidatos incluídos no conjunto for menor que dois, e a previsão de vetor de movimento temporal for habilitada, o candidato temporal (Temp) é incluído no conjunto. Nos casos em que o número de candidatos espaciais disponíveis (após a supressão) e o candidato temporal incluídos no conjunto é menor que dois, um vetor de movimento de valor zero é incluído no conjunto para preencher o conjunto.

[0042] Com relação às equações utilizadas na presente invenção, os operadores aritméticos a seguir podem ser utilizados: + Adição - Subtração * Multiplicação, incluindo multiplicação de matrizes xy Exponenciação. Especifica x à potência de y. Em outros contextos, essa notação é usada para sobrescrito, não des- tinada à interpretação como exponenciação. / Divisão de número inteiro com truncamento do resultado em direção a zero. Por exemplo, 7/4 e -7 / -4 são truncados pa- ra 1 e -7/4 e 7 / -4 são truncados para -1. ÷ Utilizado para denotar a divisão em equações matemáticas em que se pretende que não haja nenhum truncamento ou arredondamento. Utilizado para denotar a divisão em equações matemáticas em que se pretende que não haja nenhum truncamento ou arredondamento. x%y Módulo. Resto de x dividido por y, definido apenas para os números inteiros x e y com x >= 0 e y > 0.

[0043] Além disso, as funções matemáticas a seguir podem ser usadas: Log2(x) logaritmo de x na base 2; Min(x, y) = Maks(x, y) = Ceil(x) o menor número inteiro maior que ou igual a x.

Clip3(x, y, z) = Sinal(x) = Abs(x) =

[0044] Além disso, os operadores lógicos a seguir podem ser utili- zados: x && y lógica booleana "e" de x e y x ǀ ǀ y lógica Booleana "ou" de x e y ! Lógica booleana "não" x ? y : z Se x for VERDADEIRO ou não igual a 0, avalia pa- ra o valor de y; de outro modo, avalia para o valor de z.

[0045] Além disso, os operadores relacionais a seguir podem ser utilizados: > Maior que >= Maior que ou igual a < Menor que <= Menor que ou igual a == Igual a != Não igual a

[0046] Adicionalmente, os seguintes operadores de bit a bit podem ser utilizados: & Bit a bit "e". Durante a operação em argumentos inteiros, opera em uma representação complementar de dois dos valores inteiros. Durante a operação em um argumento binário que contém menos bits do que outro argumento, o argumento mais curto é estendido adicionando-se bits mais significativos iguais a 0.

| Bit a bit "ou". Durante a operação em argumentos inteiros, opera em uma representação complementar de dois dos valores inteiros. Durante a operação em um argumento binário que contém menos bits do que outro argumento, o argumento mais curto é estendido adicionando-se bits mais significativos iguais a 0. ˄ Bit a bit "exclusivo ou". Durante a operação em argumen- tos inteiros, opera em uma representação complementar de dois dos valores inteiros. Durante a operação em um argumento binário que contém menos bits do que outro argumento, o argumento mais curto é estendido adicio- nando-se bits mais significativos iguais a 0. X >> y Deslocamento aritmético para a direita de uma representa- ção de número inteiro complementar de x por y dígitos bi- nários. Essa função é definida apenas para valores de número inteiro não negativos de y. Bits deslocados para os bits mais significativos (MSBs - most significant bits) como resultado do deslocamento para a direita, têm um valor igual ao MSB de x antes da operação de deslocamento. X << y Deslocamento aritmético para a esquerda de uma repre- sentação de número inteiro complementar de x por y dígi- tos binários. Essa função é definida apenas para valores de número inteiro não negativos de y. Bits deslocados pa- ra os bits menos significativos (LSBs - least significant bits) como resultado do deslocamento para a esquerda têm um valor igual a 0.

[0047] JVET-L1001 inclui um modo de integração com base no modo de integração definido em ITU-T H.265 e um modo AMVP com base na AMVP definida em ITU-T H.256. Conforme descrito acima, na ITU-H.265, a previsão do vetor de movimento é realizada para um PB atual, o que pode resultar de uma partição adicional de uma UC. Adi- cionalmente, conforme descrito acima, em JVET-L1001, usa-se QTMT é para particionar uma CTU em CUs. Em alguns casos, em JVET- L1001, pode ser gerada uma previsão para uma UC atual mediante a derivação de informações de movimento em uma base de UC por UC (por exemplo, para cada CB, um único vetor de movimento ou único par de vetores de movimento é derivado e utilizado para gerar uma previsão). Em outros casos, pode ser gerada uma previsão para uma UC atual mediante a derivação de informações de movimento para sub-blocos dentro de uma UC. Por exemplo, uma UC 32x32 pode ser dividida em 64 sub-blocos 4x4 e informações de movimento podem ser derivadas para cada sub-bloco e as respectivas informações de movi- mento para cada sub-bloco podem ser utilizadas para gerar uma pre- visão para a UC. O uso de sub-blocos para gerar uma previsão para uma UC pode ser chamado de interpredição de sub-bloco. Um exem- plo de interpredição de sub bloco inclui o assim chamado modo afim descrito em JVET-L1001. Técnicas de previsão de vetor de movimento podem ser utilizadas para técnicas de interpredição de sub-bloco. Tais técnicas, em alguns casos, podem ser chamadas de previsão de vetor de movimento com base em sub-bloco. Dessa forma, em JVET-L1001 há várias maneiras pelas quais a interpredição pode ser realizada para gerar uma previsão para uma UC atual. As várias maneiras pelas quais a interpredição pode ser feita para gerar uma previsão para uma UC atual podem ser chamadas de ferramentas de interpredição.

[0048] A Tabela 1 ilustra a sintaxe de nível de UC fornecida em JVET-L1001 que é usada para indicar como uma ferramenta de inter- predição específica é utilizada para gerar uma previsão para a UC atual.

Tabela 1 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor if(slice_type != I) { cu_skip_flag[x0][y0] ae(v) if(cu_skip_flag[x0][y0] = = 0) pred_mode_flag ae(v) } … } else {/* MODE_INTER */ if(cu_skip_flag[x0][y0]) { mmvd_flag[x0][y0] ae(v) if(mmvd flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } eise { if(MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } } eise { merge_flag[x0][y0] ae(v) if(merge__flag[x0][y0]) { mmvd_flag[x0][y0] ae(v) if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v)

mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } eise { if(MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] == 1 && MaxNumSubblockMergeCand > 1) mergesubblockidx[x0][y0] ae(v) } if(mmvd_flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] == 0 && (cbWidth * cbHeight)>= 64 && cbWidth <128 && cbHeight <128) { mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0][y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_luma_mpm_flag[x0][y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } } } eise { if(slice_type = = B) inter_pred_idc[x0][y0] ae(v) if(sps_affme_enabled_flag && cbWidth >=16 && cbHeight >= 16){ inter_affine_flag[x0][y0] ae(v) if(sps_affine_type_flag && in- ter_affine_flag[x0][y0]) cu_affine_type_flag[x0][y0] ae(v)

} if(inter_pred_idc[x0][y0] != PRED_L1) { if(num_ref_idx_10_active_minus1 > 0) ref_idx_10[x0][y0] ae(v) mvd_coding(x0, y0, 0, 0) if(MotionModelIdc[x0][y0] > 0) mvd_coding(x0, y0, 0, 1) if(MotionModelIdc[x0][y0] > 1) mvd_coding(x0, y0, 0, 2) mvp_10_flag[x0] [y0] ae(v) } else { MvdL0[x0][y0][0] = 0 MvdL0[x0][y0][1] = 0 } if(inter_pred_idc[x0][y0] != PRED_L0) { if(num_ref_idx_11_active_minus1 > 0) ref_idx11[x0][y0] ae(v) if(mvd_11_zero_flag && in- ter_pred_idc[x0][y0] = = PRED_BI) { MvdL1[x0][y0][0] = 0 MvdL1[x0][y0][1] = 0 MvdCpL1[x0][y0][0][0] = 0 MvdCpL1[x0][y0][0][1] = 0 MvdCpL1[x0][y0][1][0] = 0 MvdCpL1[x0][y0][1][1] = 0 MvdCpL1[x0][y0][2][0] = 0 MvdCpL1[x0][y0][2][1] = 0 } else { mvd_coding(x0, y0, 1, 0) if/ MotionModelIdc[x0][y0] > 0) mvd_coding(x0, y0, 1, 1) if(MotionModelIdc[x0][y0] > 1)

mvd_coding(x0, y0, 1, 2) mvp_11flagf[x0][y0] ae(v) } else { MvdL1[x0][y0][0] = 0 MvdL1[x0][y0][1] = 0 } if(sps_amvr_enabled_flag && inter_affine_flag = = 0 && (MvdL0[x0][y0][0] !=0 || MvdL0[x0][y0][1] != 0 || MvdL1[x0][y0][0] != 0 || MvdL0[x0][y0][1] != 0)) amvr_mode[x0][y0] ae(v) if(sps_gbi_enabled_flag && in- ter_pred_idc[x0][y0] = = PRED_BI && cbWidth * cbHeight >= 256) gbi_idx[x0][y0] ae(v) } } } if(!pcm_flag[x0][y0]) { if(CuPredMode[x0][y0] != MODE_INTRA && cu_skip_flag[x0][y0] = = 0) cu_cbf ae(v) if(cu_cbf) transform_tree(x0, y0, cbWidth, cbHeight, treeType) } }

[0049] Com relação à Tabela 1, JVET-L1001 fornece as seguintes definições dos respectivos elementos de sintaxe:

[0050] cu_omip_Flag[x0][y0] igual a 1 especifica que para a uni- dade de codificação atual, ao decodificar uma fatia P ou B, nenhum elemento de sintaxe, exceto a integração mais o sinalizador de MVD mmvd_flag[x0][y0], a integração mais o índice de MVD mmvd_merge_Flag[x0][y0], a integração mais o índice de distância mmvd distance_idx[x0][y0], a integração mais o índice de direção MVD mmvd_direction_idx[x0][y0], o índice candidato de integração mer- ge_idx[x0][y0], o sinalizador de integração baseado em sub-bloco merge_subblock_flag[x0][y0] e o índice candidato a integração basea- do em sub-bloco merge_subblock_idx[x0][y0] são analisados após cu_skip_flag[x0][y0]. Cu_skip_flag[x0][y0] igual a 0 especifica que a unidade de codificação não é ignorada. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma supe- rior esquerda da imagem.

[0051] Quando cu_skip_flag[x0][y0] não está presente, infere-se como sendo igual a 0.

[0052] pred mode flag igual a 0 especifica que a unidade de codi- ficação atual é codificada em modo de interpredição. Pred_mode_flag igual a 1 especifica que a unidade de codificação atual é codificada em modo de intraprevisão. A variável CuPredMode[x][y] é derivada, como segue, para x = x0..x0 + cbWidth - 1 ed y = y0..y0 + cbHeight - 1:

[0053] - Se pred_mode_flag for igual a 0, CuPredMode[x][y] é defi- nido como sendo igual a MODE_INTER.

[0054] - Caso contrário (pred_mode_flag é igual a 1), CuPredMo- de[x][y] é definido como sendo igual a MODE_INTRA.

[0055] Quando pred_mode_Flag não está presente, a variável CuPredModef x][y] é inferida como sendo igual a MODE_INTRA para x = x0.. x0 + cbWidth - 1 e y = y0.. y0 + cbHeight - 1.

[0056] mmvd_flag[x0][y0] igual a 1 especifica que o modo de in- tegração com a diferença de vetor de movimento é utilizado para gerar os parâmetros interpredição da unidade de codificação atual. Os índi-

ces de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da imagem.

[0057] Quando mmvd_flag[x0][y0] não está presente, infere-se como sendo igual a 0.

[0058] mmvd_merge_flag[x0][y0] especifica se o primeiro (0) ou o segundo (1) candidato na lista de candidatos a integração é utilizado com a diferença do vetor de movimento derivada de mmvd_distance_idx[x0][y0] e mmvd_direction_idx[x0][y0]. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma supe- rior esquerda do bloco de codificação considerado em relação à amos- tra de luma superior esquerda da imagem.

[0059] mmvd distance_idx[x0][y0] especifica o índice utilizado para derivar MmvdDistance[x0][y0] conforme especificado na Tabela 2. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em rela- ção à amostra de luma superior esquerda da imagem. Tabela 2 mmvd_distance_idx[x0][y0] MmvdDistance[x0][y0] 0 1 1 2 2 4 3 8 4 16 5 32 6 64 7 128

[0060] mmvd_direction_idx[x0][y0] especifica o índice utilizado para derivar MmvdSign[x0][y0] conforme especificado na Tabela 3. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de lu- ma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da imagem. Tabela 3 mmvd_direction_idx[x0] MmvdSign[x0][y0][0] MmvdSignt[x0][y0][1] [y0] 0 +1 0 1 -1 0 2 0 +1 3 0 -1

[0061] Ambos os componentes da integração mais o deslocamen- to de MVD MmvdOffset[x0][y0] são derivados da seguinte forma:

[0062] MmvdOffset[x0][y0][0] = (MmvdDistance[x0][y0] << 2) * MmvdSign[x0][y0][0]

[0063] MmvdOffset[x0][y0][1] = (MmvdDistance[x0][y0] << 2) * MmvdSign[x0][y0][1]

[0064] merge_subblock_flag[x0][y0] especifica se os parâmetros de previsão baseados em sub-bloco para a unidade de codificação atual são inferidos a partir de blocos vizinhos. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da imagem. Quando merge_subblock_flag[x0][y0] não está presente, infere-se como sendo igual a 0.

[0065] merge_idx[x0][y0] especifica o índice candidato de integra- ção da lista de candidatos de integração onde x0, y0 especifica o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da ima- gem.

[0066] Quando merge_idx[x0][y0] não está presente, ele é inferido da seguinte forma:

[0067] - Se mmvd_flag[x0][y0] for igual a 1, merge_idx[x0][y0] é inferido como sendo igual a mmvd_merge flag[x0][y0].

[0068] - Caso contrário, (mmvd_flag[x0][y0] é igual a 0), infere-se que merge_idx[x0][y0] é igual a 0.

[0069] merge_subblock_idx[x0][y0] especifica o índice candidato de integração da lista de candidatos de integração onde x0, y0 especi- fica o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior es- querda da imagem.

[0070] Quando merge_subblock_idx[x0][y0] não está presente, in- fere-se como sendo igual a 0.

[0071] merge_flag[x0][y0] especifica se os parâmetros de inter- predição para a unidade de codificação atual são inferidos a partir de uma partição interprevista vizinha. Os índices de matriz x0, y0 especi- ficam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da imagem.

[0072] Quando merge_flag[x0][y0] não está presente, ele é inferido da seguinte forma:

[0073] - Se cu_skip_flag[x0][y0] for igual a 1, infere-se que mer- ge_flag[x0][y0] é igual a 1.

[0074] - Caso contrário, infere-se que merge_Flag[x0] [y0] é igual a

0.

[0075] mh_intra_flag[x0][y0] especifica se a integração interima- gem combinada e a previsão intra-imagem são aplicadas à unidade de codificação atual. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da ima- gem.

[0076] Quando mh_intra_flag[x0][y0] não está presente, infere-se como sendo igual a 0.

[0077] Os elementos de sintaxe mh_intra_luma_mpm_flag[x0][y0], e mh_intra_luma_mpm_idx[x0][y0] especificam o modo de intraprevi- são para amostras de luma utilizadas em integração interimagem combinada e previsão intra-imagem. Os índices de matriz x0, y0 espe- cificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da imagem. O modo de intraprevisão é derivado de acordo com as técnicas fornecidas em JVET-L1001.

[0078] inter_pred_idc[x0][y0] especifica se list0, list1 ou biprevi- são é utilizada para a unidade de codificação atual de acordo com a Tabela 4. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação conside- rado em relação à amostra de luma superior esquerda da imagem. Tabela 4 inter_pred_idc Nome do inter_pred_idc (cbWidth + cbHeight) != 8 (cbWidth + cbHeight) = = 8 0 PRED_L0 PRED_L0 1 PRED_L1 PRED_L1 2 PRED_BI n.a.

[0079] Quando inter_pred_idc[x0][y0] não está presente, infere-se como sendo igual a 0.

[0080] inter_affine_flag[x0][y0] igual a 1 especifica que para a unidade de codificação atual, ao decodificar uma fatia P ou B, a com- pensação de movimento baseada em modelo afim é usada para gerar as amostras de previsão da unidade de codificação atual. In- ter_affine_flag[x0][y0] igual a 0 especifica que a unidade de codifica- ção não é prevista pela compensação de movimento baseada em mo- delo afim. Quando inter_affine_flag[x0][y0] não está presente, infere-se como sendo igual a 0.

[0081] cu_affine_type_flag[x0][y0] igual a 1 especifica que para a unidade de codificação atual, ao decodificar uma fatia P ou B, uma compensação de movimento baseada em um modelo afim de 6 parâ-

metros é usada para gerar as amostras de previsão da unidade de co- dificação atual. Cu_affine_type_flag[x0][y0] igual a 0 especifica que a compensação de movimento baseada em modelo afim de 4 parâme- tros é usada para gerar as amostras de previsão da unidade de codifi- cação atual.

[0082] MotionModelIdc[x][y] representa o modelo de movimento de uma unidade de codificação, conforme ilustrado na Tabela 5. Os índi- ces de matriz x, y especificam o local de amostra da luma (x, y) em relação à amostra da luma superior esquerda da imagem.

[0083] A variável MotionModelIdc[x][y] é derivada conforme a se- guir para x = x0..x0 + cbWidth - 1 e y = y0..y0 + cbHeight - 1:

[0084] - Se merge_flag[x0][y0] for igual a 1, aplica-se o seguinte:

[0085] MotionModelIdcf x][y] = merge_subblock_flag[x0][y0]

[0086] - Caso contrário (merge_flag[x0][y0] é igual a 0), o seguinte se aplica:

[0087] MotionModelIdc[x][y] = inter_affine_flag[x0][y0] + cu_affine_type_flag[x0][y0] Tabela 5 MotionModelIdcf x][y] Modelo de movimento para compensação de movimento 0 Movimento translacional 1 Movimento afim de 4 parâmetros 2 Movimento afim de 6 parâmetros

[0088] ref_idx_10[x0][y0] especifica o índice de imagem de refe- rência da lista 0 para a unidade de codificação atual. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da imagem.

[0089] Quando ref_idx_10[x0][y0] não está presente, infere-se co- mo sendo igual a 0.

[0090] ref_idx_11[x0][y0] tem a mesma semântica que a ref_idx_10, com 10 e a lista 0 substituídas por 11 e pela lista 1, respec- tivamente.

[0091] mvp_10_flag[x0][y0] especifica o índice preditor de vetor de movimento da lista 0, em que x0, y0 especifica o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação conside- rado em relação à amostra de luma superior esquerda da imagem.

[0092] Quando mvp_10_flag[x0][y0] não está presente, infere-se como sendo igual a 0.

[0093] mvp_11_flag[x0][y0] tem a mesma semântica que mvp_10_flag, com 10 e a lista 0 substituídas por 11 e pela lista 1, res- pectivamente.

[0094] amvr_mode[x0][y0] especifica a resolução da diferença do vetor de movimento. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da ima- gem.

[0095] Quando amvr_mode[x0][y0] não está presente, infere-se como sendo igual a 0.

[0096] A variável MvShift é definida como sendo igual a amvr_mode[x0] [y0] << 1 e as variáveis MvdL0[x0][y0][0], MvdL0[x0][y0][1], MvdL1[x0][y0][0], MvdL1[x0][y0][1] são modificadas conforme a seguir:

[0097] MvdL0[x0][y0][0] = MvdL0[x0][y0][0] << (MvShift + 2)

[0098] MvdL0[x0][y0][1] = MvdL0[x0][y0][1] << (MvShift + 2)

[0099] MvdL1[x0][y0][0] = MvdL1[x0][y0][0] << (MvShift + 2)

[00100] MvdL1[x0][y0][1] = MvdL1[x0][y0][1] << (MvShift + 2)

[00101] gbi_idx[x0][y0] especifica o índice de peso de biprevisão com pesos de UC. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em relação à amostra de luma superior esquerda da ima-

gem.

[00102] Quando gbi_idx[x0][y0] não está presente, infere-se como sendo igual a 0.

[00103] cu_cbf igual a 1 especifica que a estrutura de sintaxe trans- form_tree() está presente para a unidade de codificação atual. cu_cbf igual a 0 especifica que a estrutura de sintaxe transform_tree() não está presente para a unidade de codificação atual.

[00104] Quando cu_cbf não está presente, ele é inferido da seguin- te forma:

[00105] - Se cu_skip_flag[x0][y0] for igual a 1, infere-se que cu_cbf é igual a 0.

[00106] - Caso contrário, infere-se que cu_cbf seja igual a 1.

[00107] A sintaxe de nível de UC fornecida em JVET-L1001 para indicar como uma ferramenta de interpredição específica é usada para gerar uma previsão para a UC atual, pode ser menor que o ideal. Por exemplo, algumas ferramentas de interpredição são mutuamente ex- clusivas uma em relação à outra. Dessa forma, se uma ferramenta for sinalizada como, por exemplo, ativada (ON), os elementos de sintaxe de sinalização associados a uma outra ferramenta de interpredição mutuamente exclusiva, pode ser ineficaz.

[00108] Em relação a JVET-L1001, foram propostas modificações em relação às ferramentas de interpredição que podem ser usadas para gerar uma previsão para uma UC atual. Em particular, a Tabela 6 ilustra a sintaxe de nível de UC associada às técnicas implementadas no algoritmo de Modelo de Teste de VVC 3 (VTM3) que é utilizado pa- ra indicar como uma ferramenta de interpredição específica é usada para gerar uma previsão para a UC atual.

Tabela 6 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … } else {/* MODE_INTER */ if(cu_skip_flag[x0][y0]) { mmvd_flag[x0][y0] ae(v) if (mmvd flag[x0][y0] = =0 && MaxNumSub- blockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) } eise { merge_flag[x0][y0] ae(v) if(merge_flag[x0][y0]) { mmvd_flag[x0][y0] ae(v) if (mmvd_flag[x0][y0] = =0 && MaxNumSub- blockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(mmvd_flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] == 0 && (cbWidth * cbHeight)>= 64 && cbWidth <128 && cbHeight < 128) { mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0][y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_lurna_mpm_flag[x0][y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } } if (sps_triangle_mode_flag && slice_type == B && cbWidth*cbHeight >= 64 && merge_subblock_flag[x0][y0] = =0 && mmvd_flag[x0] [y0] = = 0 && mh_intra_flag[x0] [y0] = = 0) triangle_mode_flag[x0][y0] ae(v)

if (cu_skip_flag[x0][y0] || merge_flag[x0][y0] { if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } eise { if(merge_subblock_flag[x0][y0] = =0 && tri- angle__mode__flag[x0][y0] triangle_merge_idx[x0][y0] ae(v) else(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } } } eise { if(slice_type = = B) inter_pred_idc[x0][y0] ae(v) if(sps_affme_enabled_flag && cbWidth>=16 && cbHeight>= 16){ inter_affine_flag[x0][y0] ae(v) if(sps_affine_type flag && iti- ter_afline_flag[x0][y0]) cu_affine_type_flag[x0][y0] ae(v) } if(inter_pred_idc[x0][y0] != PRED_L1) { if(num_ref_idx_10_active_minus1 > 0) ref_idx_10[x0][y0] ae(v) mvd_coding(x0, y0, 0, 0) if(MotionModelIdc[x0][y0] > 0) mvd_coding(x0, y0, 0, 1)

if(MotionModelIdc[x0][y0] > 1) mvd_coding(x0, y0, 0, 2) mvp_10_flag[x0][y0] ae(v) } eise { MvdL0[x0][y0][0] = 0 MvdL0[x0][y0][1] = 0 } if(inter_pred_idc[x0][y0] != PRED_L0) { if(num_ref_idx_11_active_minus1 > 0) ref_idx_11 [x0][y0] ae(v) if(mvd_11_zero_flag && in- ter_pred_idc[x0][y0] = = PRED_BI) { MvdL1[x0][y0][0] = 0 MvdL1[x0][y0][1] = 0 MvdCpL1[x0][y0][0][0] = 0 MvdCpL1[x0][y0][0][1] = 0 MvdCpL1[x0][y0][1][0] = 0 MvdCpL1[x0][y0][1][1] = 0 MvdCpL1[x0][y0][2][0] = 0 MvdCpL1[x0][y0][2][1] = 0 } eise { Mvd_coding(x0, y0, 1, 0) if(MotionModelIdc[x0][y0] > 0) mvd_coding(x0, y0, 1, 1) if(MotionModelIdc[x0][y0] > 1) mvd_coding(x0, y0, 1, 2) mvp_11_flag[x0][y0] ae(v) } eise { MvdL1[x0][y0][0] = 0 MvdL1[x0][y0][1] = 0 } if(sps_amvr_enabled_flag && inter_affine_flag =

= 0 && (MvdL0[x0][y0][0] != 0 || MvdL0[x0][y0][1] != 0 || MvdL1[x0][y0][0] != 0 || MvdL1[x0][y0][1] != 0)) amvr_mode[x0][y0] ae(v) if(sps_gbi_enabled_flag && in- ter_pred_idc[x0][y0] = = PRED_BI && cbWidth * cbHeight >= 256) gbi_idx[x0][y0] ae(v) } } } if(!pcm_flag[x0][y0]) { if(CuPredMode[x0][y0] != MODE_INTRA && cu_skip_flag[x0][y0] == 0) cu_cbf ae(v) if(cu_cbf) transform_tree(x0, y0, cbWidth, cbHeight, treeType) } }

[00109] Em relação à Tabela 6, as definições dos respectivos ele- mentos de sintaxe podem ser conforme fornecidas acima e da seguin- te forma:

[00110] triangle_mode_flag[x0][y0] especifica se a previsão de modo triangular (conforme descrito em "CE10.3.1.b: Triangular predic- tion unit mode", 12th Meeting of ISO/IEC JTC1/SC29/WG11, 3 a 12 de outubro de 2018, Macao, CN, documento JVET-L0124-v2, que é cha- mado aqui de JVET-L0124) é usada para o bloco de codificação atual. Os índices de matriz x0, y0 especificam o local (x0, y0) da amostra de luma superior esquerda do bloco de codificação considerado em rela- ção à amostra de luma superior esquerda da imagem. Quando trian- gle_mode_flag[x0][y0] não está presente, infere-se como sendo igual a

0.

[00111] triangle_merge_idx[x0][y0] especifica o índice candidato de integração da lista de candidatos de integração em modo triangular, onde x0, y0 especifica o local (x0, y0) da amostra de luma superior es- querda do bloco de codificação considerado em relação à amostra de luma superior esquerda da imagem. Quando trian- gle_merge_idx[x0][y0] não está presente, infere-se como sendo igual a

0.

[00112] Dessa forma, a sintaxe ilustrada na Tabela 6 suporta a fer- ramenta de interpredição da previsão de modo triangular. Similar à sin- taxe de nível de UC fornecida em JVET-L1001, a sintaxe de nível de UC correspondente ao algoritmo de VTM3 pode ser menor que o ideal.

[00113] A Figura 5 é um diagrama de blocos que ilustra um exem- plo de um sistema que pode ser configurado para codificar (ou seja, codificar e/ou decodificar) dados de vídeo de acordo com uma ou mais técnicas desta divulgação. O sistema 100 representa um exemplo de um sistema que pode executar codificação de vídeo com o uso de téc- nicas de previsão de vetor de movimento descritas de acordo com um ou mais exemplos da presente divulgação. Conforme ilustrado na Fi- gura 5, o sistema 100 inclui o dispositivo de origem 102, o meio de comunicação 110 e o dispositivo de destino 120. No exemplo ilustrado na Figura 5, o dispositivo de origem 102 pode incluir qualquer disposi- tivo configurado para codificar dados de vídeo e transmitir dados de vídeo codificados para o meio de comunicação 110. O dispositivo de destino 120 pode incluir qualquer dispositivo configurado para receber dados de vídeo codificados através do meio de comunicação 110 e para decodificar dados de vídeo codificados. O dispositivo de origem 102 e/ou o dispositivo de destino 120 podem incluir dispositivos de computação equipados para comunicação com fio e/ou sem fio e po- dem incluir, por exemplo, decodificadores do tipo set-top box, gravado-

res de vídeo digital, televisores, computadores de mesa, laptop ou ta- blet, consoles de jogos, dispositivos móveis, incluindo, por exemplo, smartphones, telefones celulares, dispositivos pessoais de jogo e dis- positivos médicos de imageamento.

[00114] O meio de comunicação 110 pode incluir qualquer combi- nação de meios de comunicação com fio e sem fio e/ou dispositivos de armazenamento. O meio de comunicação 110 pode incluir cabos coa- xiais, cabos de fibra óptica, cabos de par trançado, transmissores e receptores sem fio, roteadores, chaves, repetidores, estações de base ou qualquer outro equipamento que possa ser útil para facilitar a co- municação entre vários dispositivos e locais. O meio de comunicação 110 pode incluir uma ou mais redes. Por exemplo, o meio de comuni- cação 110 pode incluir uma rede configurada para habilitar o acesso à World Wide Web, por exemplo a Internet. Uma rede pode operar de acordo com uma combinação de um ou mais protocolos de telecomu- nicação. Protocolos de telecomunicações podem incluir aspectos pro- prietários e/ou podem incluir protocolos de telecomunicação padroni- zados. Exemplos de protocolos de telecomunicações padronizados incluem os padrões da difusão de vídeo digital (DVB, ou Digital Video Broadcasting), padrões do Comitê de Sistemas de Televisão Avança- do (ATSC, ou Advanced Television Systems Committee), padrões da difusão digital de serviços integrados (ISDB, ou Integrated Services Digital Broadcasting), padrões da especificação de interface de serviço de dados por cabo (DOCSIS, ou Data Over Cable Service Interface Specification), padrões do sistema global para comunicações móveis (GSM, ou Global System Mobile Communications), padrões do acesso múltiplo por divisão de código (CDMA, ou code division multiple ac- cess), padrões do Projeto de Parceria de 3ª Geração (3GPP, ou 3rd Generation Partnership Project), padrões do Instituto Europeu de Nor- mas de Telecomunicações (ETSI, ou European Telecommunications

Standards Institute), padrões de protocolo de Internet (IP, ou Internet Protocol), padrões de protocolo de aplicação sem fio (WAP, ou Wire- less Application Protocol) e padrões do Instituto de Engenheiros Eletri- cistas e Eletrônicos (IEEE, ou Institute of Electrical and Electronics En- gineers).

[00115] Os dispositivos de armazenamento podem incluir qualquer tipo de dispositivo ou mídia de armazenamento capaz de armazenar dados. Uma mídia de armazenamento pode incluir uma mídia legível por computador tangível ou não transitória. Uma mídia legível por computador pode incluir discos ópticos, memória flash, memória mag- nética ou qualquer outra mídia de armazenamento digital adequada. Em alguns exemplos, um dispositivo de memória ou porções do mes- mo pode(m) ser descrito(as) como memória não volátil e, em outros exemplos, porções de dispositivos de memória podem ser descritas como memória volátil. Exemplos de memórias voláteis podem incluir memórias de acesso aleatório (RAM, ou random access memories), memórias de acesso aleatório dinâmicas (DRAM, ou dynamic random access memories), memórias de acesso aleatório estáticas (SRAM, ou static random access memories). Exemplos de memórias não voláteis podem incluir discos rígidos magnéticos, discos ópticos, disquetes, memórias flash ou formas de memórias de leitura eletricamente pro- gramáveis (EPROM, ou electrically programmable read only memori- es) ou memórias de leitura eletricamente apagáveis e programáveis (EEPROM, ou electrically erasable and programmable read only me- mories). O dispositivo (ou dispositivos) de armazenamento pode incluir cartões de memória (por exemplo, um cartão de memória digital segu- ro (SD, ou Secure Digital)), unidades de disco rígido internas/externas e/ou unidades de estado sólido internas/externas. Os dados podem ser armazenados em um dispositivo de armazenamento de acordo com um formato de arquivo definido.

[00116] Novamente com referência à Figura 5, o dispositivo de ori- gem 102 inclui a fonte de vídeo 104, o codificador de vídeo 106, e a interface 108. A fone de vídeo 104 pode incluir qualquer dispositivo configurado para capturar e/ou armazenar dados de vídeo.

Por exem- plo, a fonte de vídeo 104 pode incluir uma câmera de vídeo e um dis- positivo de armazenamento operacionalmente acoplado à mesma.

O codificador de vídeo 106 pode incluir qualquer dispositivo configurado para receber dados de vídeo e gerar um fluxo de bits compatível que represente os dados de vídeo.

Um fluxo de bits compatível pode se referir a um fluxo de bits a partir do qual um decodificador de vídeo pode receber e reproduzir dados de vídeo.

Aspectos de um fluxo de bits compatível podem ser definidos de acordo com um padrão de co- dificação de vídeo.

Quando gera um fluxo de bits compatível, o codifi- cador de vídeo 106 pode comprimir os dados de vídeo.

A compressão pode ser com perdas (discernível ou indiscernível) ou sem perdas.

A Interface 108 pode incluir qualquer dispositivo configurado para rece- ber um fluxo de bits de vídeo compatível e transmitir e/ou armazenar o fluxo de bits de vídeo compatível em uma mídia de comunicação.

A interface 108 pode incluir um cartão de interface de rede, como um cartão Ethernet, e pode incluir um transceptor óptico, um transceptor de radiofrequência ou qualquer outro tipo de dispositivo que possa en- viar e/ou receber informações.

Além disso, a interface 108 pode incluir uma interface de sistema de computador que pode permitir que um fluxo de vídeo compatível seja armazenado em um dispositivo de ar- mazenamento.

Por exemplo, a interface 108 pode incluir um conjunto de chips que suporta protocolos de barramento de interconexão de componentes periféricos (PCI, ou Peripheral Component Interconnect) e de interconexão expressa de componentes periféricos (PCIe, ou Pe- ripheral Component Interconnect Express), protocolos de barramento proprietário, protocolos de barramento serial universal (USB, ou Uni-

versal Serial Bus), I2C ou qualquer outra estrutura lógica e física que possa ser usada para interconectar dispositivos pares.

[00117] Novamente com referência à Figura 5, o dispositivo de des- tino 120 inclui a interface 122, o decodificador de vídeo 124 e a tela

126. A interface 122 pode incluir qualquer dispositivo configurado para receber um fluxo de vídeo compatível de um meio de comunicação. A interface 108 pode incluir um cartão de interface de rede, como um cartão Ethernet, e pode incluir um transceptor óptico, um transceptor de radiofrequência ou qualquer outro tipo de dispositivo que possa re- ceber e/ou enviar informações. Além disso, a interface 122 pode incluir uma interface de sistema de computador que possibilita que um fluxo de bits de vídeo compatível seja recuperado a partir de um dispositivo de armazenamento. Por exemplo, a interface 122 pode incluir um con- junto de chips que suporta protocolos de barramento de PCI e de PCIe, protocolos de barramento proprietário, protocolos de USB, I2C ou qualquer outra estrutura lógica e física que possa ser usada para interconectar dispositivos pares. O decodificador de vídeo 124 pode incluir qualquer dispositivo configurado para receber um fluxo de bits compatível e/ou variações aceitáveis do mesmo e reproduzir dados de vídeo a partir do mesmo. A tela 126 pode incluir qualquer dispositivo configurado para mostrar dados de vídeo. A tela 126 pode compreen- der um dentre uma variedade de dispositivos de exibição como uma tela de cristal líquido (LCD), uma tela de plasma, uma tela de diodo orgânico emissor de luz (OLED) ou um outro tipo de tela. A tela 126 pode incluir uma tela de alta definição ou uma tela de ultra-alta defini- ção. Deve-se notar que, embora no exemplo ilustrado na Figura 5, o decodificador de vídeo 124 seja descrito como emitindo dados para a tela 126, o decodificador de vídeo 124 pode ser configurado para for- necer dados de vídeo para vários tipos de dispositivos e/ou subcom- ponentes dos mesmos. Por exemplo, o decodificador de vídeo 124 po-

de ser configurado para emitir dados de vídeo para qualquer meio de comunicação, conforme descrito na presente invenção.

[00118] A Figura 6 é um diagrama de blocos que ilustra um exem- plo de codificador de vídeo 200 que pode implementar as técnicas pa- ra codificar os dados de vídeo descritos na presente invenção. Deve- se notar que, embora o codificador de vídeo exemplificador 200 seja ilustrado como tendo blocos funcionais distintos, tal ilustração é para propósitos descritivos e não limita o codificador de vídeo 200 e/ou subcomponentes do mesmo a uma arquitetura específica de software ou hardware. As funções do codificador de vídeo 200 podem ser exe- cutadas com o uso de qualquer combinação de implementações de hardware, firmware e/ou software. Em um exemplo, o codificador de vídeo 200 pode ser configurado para codificar dados de vídeo de acordo com as técnicas aqui descritas. O codificador de vídeo 200 po- de executar codificação de intraprevisão e codificação de interpredição de áreas de imagem, e, como tal, pode ser chamado de codificador de vídeo híbrido. No exemplo ilustrado na Figura 6, o codificador de vídeo 200 recebe blocos de vídeo de origem. Em alguns exemplos, os blo- cos de vídeo de origem podem incluir áreas de imagem que foram di- vididas de acordo com uma estrutura de codificação. Por exemplo, os dados de vídeo de origem podem incluir macroblocos, CTUs, CBs, subdivisões dos mesmos e/ou uma outra unidade de codificação equi- valente. Em alguns exemplos, o codificador de vídeo 200 pode ser configurado para executar subdivisões adicionais de blocos de vídeo de origem. Deve-se notar que algumas técnicas descritas na presente invenção podem ser geralmente aplicáveis a codificação de vídeo, in- dependentemente de como os dados de vídeo de origem são particio- nados antes e/ou durante a codificação. No exemplo ilustrado na Figu- ra 6, o codificador de vídeo 200 inclui o somador 202, o gerador de coeficiente de transformada 204, a unidade de quantificação de coefi-

ciente 206, a unidade de processamento de transforma- ção/quantificação inversa 212, o somador 210, a unidade de proces- samento de intraprevisão 212, a unidade de processamento de inter- predição 214, a unidade de filtro 216, e a unidade de codificação por entropia 218.

[00119] Conforme ilustrado na Figura 6, o codificador de vídeo 200 recebe blocos de vídeo de origem e emite um fluxo de bits. O codifica- dor de vídeo 200 pode gerar dados residuais mediante a subtração de um bloco de vídeo preditivo de um bloco de vídeo de origem. O soma- dor 202 representa um componente configurado para executar esta operação de subtração. Em um exemplo, a subtração de blocos de vídeo ocorre no domínio de pixel. O gerador de coeficiente de trans- formada 204 aplica uma transformada, como uma transformada discre- ta de cosseno (DCT - discrete cosine transform), uma transformada discreta de seno (DST - discrete sine transform) ou uma transformada conceitualmente similar, ao bloco residual ou subdivisões do mesmo (por exemplo quatro transformadas de 8x8 podem ser aplicadas a uma matriz de 16x16 de valores residuais) para produzir um conjunto de coeficientes de transformada residuais. O gerador de coeficiente de transformada 204 pode ser configurado para executar quaisquer e to- das as combinações das transformadas incluídas na família de trans- formadas trigonométricas discretas. O gerador de coeficiente de trans- formada 204 pode emitir coeficientes de transformada para a unidade de quantificação de coeficiente 206. A unidade de quantificação de co- eficiente 206 pode ser configurada para executar a quantificação dos coeficientes de transformada. Conforme descrito acima, o grau de quantificação pode ser modificado mediante o ajuste de um parâmetro de quantificação. A unidade de quantificação de coeficiente 206 pode ser adicionalmente configurada para determinar parâmetros de quanti- ficação (QP - quantization parameters) e emitir dados QP (por exem-

plo, dados utilizados para determinar um tamanho de grupo de quanti- ficação e/ou valores delta QP) que podem ser utilizados por um deco- dificador de vídeo para reconstruir um parâmetro de quantificação para realizar quantificação inversa durante a decodificação de vídeo. Deve- se notar que em outros exemplos, um ou mais parâmetros adicionais ou alternativos podem ser utilizados para determinar um nível de quan- tificação (por exemplo, fatores de escala). As técnicas aqui descritas podem ser geralmente aplicáveis à determinação de um nível de quan- tificação para coeficientes de transformada que correspondem a um componente de dados de vídeo com base em um nível de quantifica- ção para coeficientes de transformada que correspondem a outro componente de dados de vídeo.

[00120] Conforme ilustrado na Figura 6, os coeficientes de trans- formada quantificados são produzidos para a unidade de processa- mento de transformada/quantificação inversa 208. A unidade de pro- cessamento de transformada/quantificação inversa 208 pode ser con- figurada para aplicar uma quantificação inversa e uma transformação inversa para gerar dados residuais reconstruídos. Conforme ilustrado na Figura 6, no somador 210, os dados residuais reconstruídos podem ser adicionados a um bloco de vídeo preditivo. Dessa maneira, um bloco de vídeo codificado pode ser reconstruído e o bloco de vídeo reconstruído resultante pode ser usado para avaliar a qualidade de codificação para uma dada previsão, transformação e/ou quantização. O codificador de vídeo 200 pode ser configurado para executar múlti- plas passagens de codificação (por exemplo executar codificação en- quanto varia um ou mais dentre uma previsão, parâmetros de trans- formação e parâmetros de quantificação). A distorção de taxa de um fluxo de bits ou outros parâmetros de sistema pode ser otimizada com base na avaliação de blocos de vídeo reconstruídos. Além disso, blo- cos de vídeo reconstruídos podem ser armazenados e usados como referência para prever blocos subsequentes.

[00121] Conforme descrito acima, um bloco de vídeo pode ser codi- ficado com o uso de um modo intraprevisão. A unidade de processa- mento intraprevisão 212 pode ser configurada para selecionar um mo- do intraprevisão para um bloco de vídeo atual. A unidade de proces- samento de intraprevisão 212 pode ser configurada para avaliar um quadro e/ou uma área da mesma e determinar um modo de intraprevi- são para usar para codificar um bloco atual. Conforme ilustrado na Fi- gura 6, a unidade de processamento de intraprevisão 212 emite dados de intraprevisão (por exemplo elementos de sintaxe) para a unidade de codificação por entropia 218 e para o gerador de coeficiente de transformada 204. Conforme descrito acima, modos de intraprevisão possíveis podem incluir modos de previsão planos, modos de previsão DC e modos de previsão angulares. A unidade de processamento de interpredição 214 pode ser configurada para executar codificação de interpredição para um bloco de vídeo atual. A unidade de processa- mento de interpredição 214 pode ser configurada para receber blocos de vídeo de origem e calcular informações de movimento para PUs de um bloco de vídeo. Um vetor de movimento pode indicar o desloca- mento de uma PU (ou estrutura de codificação similar) de um bloco de vídeo dentro de um quadro de vídeo atual em relação a um bloco pre- ditivo dentro de um quadro de referência. A codificação de interpredi- ção pode usar uma ou mais imagens de referência. Por exemplo, a unidade de processamento de interpredição 214 pode localizar um bloco de vídeo preditivo dentro de um buffer de quadro (não mostrado na Figura 6). Deve-se notar que a unidade de processamento de inter- predição 214 pode ser adicionalmente configurada para aplicar um ou mais filtros de interpolação a um bloco residual reconstruído para cal- cular valores de pixel de subnúmero inteiro para uso na estimativa de movimento. Além disso, a previsão de movimento pode ser uniprediti-

va (usar um vetor de movimento) ou bipreditiva (usar dois vetores de movimento). A unidade de processamento de interpredição 214 pode ser configurada para selecionar um bloco preditivo com o cálculo de uma diferença de pixel determinada, por exemplo, pela soma da dife- rença absoluta (SAD, ou sum of absolute difference), soma da diferen- ça quadrada (SSD, ou sum of square difference) ou outra métrica de diferença. A unidade de processamento de interpredição 214 pode emitir dados de previsão do movimento para um vetor de movimento calculado para a unidade de codificação por entropia 218.

[00122] Conforme descrito acima, uma informação de movimento pode ser determinada e especificada de acordo com técnicas de previ- são de vetor de movimento. A unidade de processamento de interpre- dição 214 pode ser configurada para executar técnicas de previsão de vetor de movimento, conforme descrito acima. Adicionalmente, a uni- dade de processamento de interpredição 214 pode ser configurada para executar previsão de vetor de movimento, de acordo com as téc- nicas descritas acima. Em particular, a unidade de processamento in- terpredição 214 pode ser configurada para executar previsão de vetor de movimento com base em sub-bloco.

[00123] Conforme descrito acima, a sintaxe de nível de UC em JVET-L1001 e a sintaxe de nível de UC correspondente ao algoritmo de VTM3, podem ser menores que o ideal. Em um exemplo, de acordo com as técnicas da presente invenção, mmvd_merge_flag só é sina- lizado se o modo de integração não sub PU for selecionado (isto é, quando merge_subblock_flag for 0). A Tabela 7 ilustra um exemplo em que mmvd_merge_flag só é sinalizado se o modo de integração não sub PU for selecionado de acordo com as técnicas da presente inven- ção. Conforme ilustrado na sintaxe da Tabela 7, a sinalização de mmvd_merge_flag é movida abaixo da recepção de mer- ge_subblock_flag em comparação com a sintaxe na Tabela 1.

Tabela 7 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … } else {/* MODE INTER */ if(cu_skip_flag[x0][y0]) { if(MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 0) mmvd_flag[x0][y0] ae(v) if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } else { if(merge subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } } else { merge_flag[x0][y0] ae(v) if(merge_flag[x0][y0]) { if(MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 0) mmvd_flag[x0][y0] ae(v) if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v)

mmvd_direction_idx[x0][y0] ae(v) } else { if(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] == 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } if(mmvd_flag[x0][y0] = = 0 && merge_subblock_flag[x0][y0] == 0 && (cbWidth * cbHeight) >= 64 && cbWidth < 128 && cbHeight <128) { mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0][y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_luma_mpm_flag[x0][y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } } } else { … }

[00124] Em relação à Tabela 7, as definições dos respectivos ele- mentos de sintaxe podem ser conforme fornecidas acima.

[00125] A Tabela 8 ilustra um exemplo em que mmvd_merge_flag só é sinalizado se o modo de integração não sub PU for selecionado de acordo com as técnicas da presente invenção. Conforme ilustrado na sintaxe da Tabela 8, a sinalização de mmvd_merge_flag é movida abaixo da recepção de merge_subblock_flag em comparação com a sintaxe na Tabela 6.

Tabela 8 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … } else {/* MODEINTER */ if(cu_skip_flag[x0][y0]) { if (MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if (merge_subblock_flag[x0][y0] = = 0) mmvd_flag[x0][y0] ae(v) } else { merge_flag[x0][y0] ae(v) if(merge_flag[x0][y0]) { if (MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if (merge_subblock_flag[x0][y0] = = 0) mmvd_flag[x0][y0] ae(v) if(mmvd flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] = = 0&& (cbWidth * cbHeight)>= 64 && cbWidth <128 && cbHeight < 128){ mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0][y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_luma_mpm_flag[x0][y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } } if (sps_triangle_mode_flag && slice_type == B && cbWidth*cbHeight >=64 && merge_subblock_flag[x0][y0] = = 0 && mmvd_flag[x0] [y0] = =0 && mh_intra_flag[x0][y0] = = 0) triangle_mode_flag[x0][y0] ae(v)

if (cu_skip_flag[x0][y0] merge_flag[x0][y0] { if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } else { if(merge_subblock_flag[x0][y0] = = 0 && triangle_mode_flag[x0][y0] triangle_merge_idx[x0] [y0] ae(v) else(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 1 && MaxNumSubblockMergeCand > 1) merge subblock_idx[x0][y0] ae(v) } } } else { … }

[00126] Em relação à Tabela 8, as definições dos respectivos ele- mentos de sintaxe podem ser conforme fornecidas acima.

[00127] Em um exemplo, de acordo com as técnicas da presente invenção, a integração interimagem e a sinalização de previsão intrai- magem combinadas são espelhadas no ramo if(cu_skip_flag[x0] [y0]){...}. Isso permite o uso de previsão de múltiplas hipóteses quando o modo de omissão é utilizado, o que pode melhorar a eficiência de codificação. A Tabela 9 ilustra um exemplo em que a integração inte- rimagem combinada e a sinalização de previsão intraimagem são es- pelhadas no ramo if(cu_skip_flag[x0][y0]) {...} em comparação com a sintaxe na Tabela 1. A Tabela 10 ilustra um exemplo em que a inte- gração interimagem combinada e a sinalização de previsão intraima-

gem são espelhadas no ramo if(cu_skip_flag[x0][y0]) {...} em compara- ção com a sintaxe na Tabela 6. Tabela 9 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … } else {/* MODE_INTER */ if(cu_skip_flag[x0][y0]) { mmvd_flagl [x0][y0] ae(v) if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0] [y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } eise { if(MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(merge subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } if(mmvd_flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] = = 0 && (cbWidth * cbHeight)>= 64 && cbWidth <128 && cbHeight < 128) { mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0] [y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_lurna_mpm_flag[x0] [y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } }

} eise { merge_flag[x0][y0] ae(v) if(merge_flag[x0][y0]) { mmvd_flag[x0][y0] ae(v) if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } else { if(MaxNumSubblockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] == 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } if(mmvd_flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] = = 0 && (cbWidth * cbHeight) >= 64 && cbWidth < 128 && cbHeight <128) { mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0][y0]) { mh intra_luma_mpm_flag [x0][y0] ae(v) if(mh_intra_luma_mpm_flag[x0][y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } } } else { ,,, }

Tabela 10 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … } else {/* MODE_INTER */ if(cu_skip_flag[x0][y0]) { mmvd_flag[x0][y0] ae(v) if (mmvd_flag[x0][y0] = =0 && MaxNumSub- blockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(mmvd_flag[x0][y0] = = 0 && merge_subblock_flag[x0][y0] = = 0&& (cbWidth * cbHeight)>= 64 && cbWidth < 128 && cbHeight < 128){ mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0][y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_luma_mpm_flag[x0][y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } } } eise { merge_flag[x0][y0] ae(v) if(merge_flag[x0][y0]) { mmvd_flag[x0][y0] ae(v) if (mmvd_flag[x0][y0] = =0 && MaxNumSub- blockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0][y0] ae(v) if(mmvd_flag[x0][y0] = = 0 && merge_subblock_flag[x0][y0] = = 0 &&

(cbWidth * cbHeight) >= 64 && cbWidth < 128 && cbHeight <128) { mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0] [y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_luma_mpm_flag[x0][y0]) mh_intra_luma_mpm_idx[x0] [y0] ae(v) } } if (sps_triangle_mode_flag && slice__type == B && cbWidth*cbHeight >= 64 && merge_subblock_flag[x0][y0] = = 0 && mmvd_flag[x0][y0] = = 0 && mh_intra_flag[x0][y0] = =0) triangle_mode_flag[x0][y0] ae(v) if (cu_skip_flag[x0][y0] || merge_flag[x0][y0] { if(mmvd_flag[x0][y0] = = 1) { mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } else { if(merge_subblock_flag[x0] [y0] = = 0 && triangle_mode_flag[x0][y0] triangle_merge_idx[x0][y0] ae(v) else(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } }

} else { … }

[00128] Em relação à Tabela 9 e à Tabela 10, as definições dos respectivos elementos de sintaxe podem ser conforme fornecidas aci- ma.

[00129] Em um exemplo, de acordo com as técnicas da presente invenção, a seguinte condição para a sinalização de integração interi- magem combinada e previsão intraimagem (isto é, a previsão de múl- tiplas hipóteses): if(mmvd_flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] == 0 && (cbWidth * cbHeight)>= 64 && cbWidth<128 && cbHeight < 128) {

[00130] pode ser adicionalmente condicionado em um sinalizador de alto nível (ou seja, um sinalizador em um nível mais alto que o nível de UC) da seguinte forma: if(sps_mh_intra_flag && mmvd_flag[x0][y0] == 0 && mer- ge_subblock_flag[x0][y0] == 0 && (cbWidth * cbHeight) >= 64 && cbWidth 128 && cbHeight < 128) {

[00131] Adicionalmente, em um exemplo, de acordo com as técni- cas da presente invenção, um sinalizador de alto nível pode indicar se uma dentre a sinalização de previsão de múltiplas hipóteses ou a sina- lização de modo triangular, é sinalizada. Ou seja, as seguintes condi- ções: if(mmvd_flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] == 0 && (cbWidth * cbHeight) >= 64 && cbWidth < 128 && cbHeight < 128) {

AND if (sps_triangle_mode flag && slice type == B && cbWidth*cbHeight >= 64 && merge_subblock_flag[x0][y0] = =0 &&

mmvd_flag[x0][y0] = =0 && mh_intra_flag[x0][y0] = = 0) podem ser modificadas da seguinte forma: if(use_mh_or_triangle_flag == MH && mmvd_flag[x0][y0] = = 0 && merge_subblock_flag[x0][y0] = = 0 && (cbWidth * cbHeight) >= 64 && cbWidth < 128 && cbHeight < 128) {

AND if (use_mh_or_triangle_flag == TRIANGLE && slice_type == B && cbWidth*cbHeight >= 64 && merge_subblock_flag[x0][y0] = =0 && mmvd_flag[x0][y0] = = 0 && mh_intra_flag[x0][y0] = = 0) onde, use_mh_or_triangle_flag pode ser igual a um dentre MH ou TRIANGLE.

[00132] Em um exemplo, de acordo com as técnicas da presente invenção, a sinalização de modo triangular é espelhada para a ramifi- cação não intermitente/não integrada. Isso possibilita o uso de previ- são triangular quando o modo de não intermitente/não integração é utilizado, o que pode melhorar a eficiência de codificação. Deve-se no- tar que não intermitente/não integração pode também ser chamada de ramificação AMVP. A Tabela 11 ilustra um exemplo em que a sinaliza- ção de modo triangular é espelhada na ramificação não intermiten- te/não integrada em comparação com a sintaxe na Tabela 6. Tabela 11 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … } else {/* MODE_INTER */ if(cu_skip_flag[x0][y0]) { … } eise { merge_flag[x0][y0] ae(v) if(merge_flag[x0][y0]) {

… } eise { if(slice_type = = B) inter_pred_idc[x0][y0] ae(v) if(sps_affine_enabled_flag && cbWidth >=16 && cbHeight >= 16){ inter_affine_flag[x0][y0] ae(v) if(sps_affine_type flag && in- ter_affine_flag[x0][y0]) cu_affine_type_flag[x0][y0] ae(v) } if(inter_pred_idc[x0][y0] != PRED_L1) { if(num_ref_idx_10_active_minus1 > 0) ref_idx_10[x0][y0] ae(v) mvd_coding(x0, y0, 0, 0) if(MotionModelIdc[x0][y0] > 0) mvd_coding(x0, y0, 0, 1) if(MotionModelIdc[x0][y0] > 1) mvd_coding(x0, y0, 0, 2) mvp_10_flag[x0][y0] ae(v) } eise { MvdL0[x0][y0][0] = 0 MvdL0[x0][y0][1] = 0 } if(inter_pred_idc[x0][y0] != PRED_L0) { if(num_ref_idx_11_active_minus1 > 0) ref_idx_11[x0][y0] ae(v) if(mvd_11_zero_flag && in- ter_pred_idc[x0][y0] = = PRED_BI) { MvdL1[x0][y0][0] = 0 MvdL1[x0][y0][1] = 0 MvdCpL1[x0][y0][0][0] = 0

MvdCpL1[x0][y0][0][1] = 0 MvdCpL1[x0][y0][l][0] = 0 MvdCpL1[x0][y0][1][1] = 0 MvdCpL1[x0][y0][2][0] = 0 MvdCpL1[x0][y0][2][1] = 0 } else { mvd_coding(x0, y0, 1, 0) if(MotionModelIdc[x0][y0] > 0) mvd_coding(x0, y0, 1, 1) if(MotionModelIdc[x0][y0] > 1) mvd_coding(x0, y0, 1, 2) mvp_11_flag[x0][y0] ae(v) } else { MvdL1[x0][y0][0] = 0 MvdL1[x0][y0][1] = 0 } if(sps_amvr_enabled_flag && inter affine flag = = 0 && (MvdL0[x0][y0][0] !=0 || MvdL0[x0][y0][1] != 0 || MvdL1[x0][y0][0] != 0 || MvdL1[x0][y0][1] != 0)) amvr_mode[x0][y0] ae(v) if (sps_triangle__mode_flag && in- ter__pred_idc[x0][y0] = = PRED BI && cbWidth*cbHeight >= 64) triangle_mode_flag[x0][y0] // vetores ae(v) de movimento utilizados para cada parte serão os ex- plicitamente sinalizados.

Pode haver um pedido de part0 que usa List0 e part1 que usa o vetor de movi- mento List 1. Nenhum elemento de sintaxe trian- gle_merge_index precisa ser sinalizado nessa parte da sintaxe if(sps_gbi enabled flag && in- ter_pred_idc[x0][y0] = = PRED_BI && cbWidth * cbHeight >= 256)

gbi_idx[x0][y0] ae(v) } } } if(!pcm_flag[x0][y0]) { if(CuPredMode[x0][y0] != MODE_INTRA && cu_skip_flag[x0][y0] = = 0) cu_cbf ae(v) if(cu_cbf) transform_tree(x0, y0, cbWidth, cbHeight, tree- Type) } }

[00133] Em relação à Tabela 11, as definições dos respectivos ele- mentos de sintaxe podem ser conforme fornecidas acima.

[00134] Com relação à Tabela 6, no momento, o processo de cons- trução da lista de integração triangular é separado do processo de construção da lista de integração de sub-blocos e do processo de construção da lista de integração de não sub-blocos. Em um exemplo, de acordo com as técnicas da presente invenção, a lista de integração de não sub-bloco pode ser usada como a lista de integração para o modo triangular. No caso em que tal seleção é feita, então, pode ser aceitável tornar a binarização de índice de integração triangular igual à binarização de índice de integração (por exemplo, não sub-bloco). Quando a binarização é igual, em um exemplo, o contexto selecionado para codificação por entropia do índice de integração triangular pode ser diferente do contexto do índice de integração não sub-bloco. Em um exemplo, o índice de integração não sub-bloco se refere ao ele- mento de sintaxe merge_idx[x0][y0]. Em um exemplo, o índice de in- tegração triangular se refere ao elemento de sintaxe trian- gle_merge_idx[x0][y0].

[00135] Em um exemplo, de acordo com as técnicas da presente invenção, a sintaxe pode ser modificada para sinalizar ao sinalizador mh_intra_flag[x0][y0] após o sinalizador triangle_mode_flag[x0][y0] quando triangle_mode_flag[x0][y0] é igual a 0 e não sinalizar ao sina- lizador mh_intra_flag[x0][y0] após o triangle_mode_flag[x0][y0] quando triangle_mode_flag[x0][y0] é igual a 1. Em um exemplo, quando não estiver presente o valor de multi-hypothesis flag, infere- se que seja 0. A tabela 12 ilustra um exemplo em que o sinalizador mh_intra_flag[x0][y0] é condicional presente após o sinalizador trian- gle_mode_flag[x0][y0]. Tabela 12 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … mmvd_flag[x0][y0] ae(v) if (mmvd_flag[x0][y0] = =0 && MaxNumSub- blockMergeCand > 0 && cbWidth >= 8 && cbHeight >= 8) merge_subblock_flag[x0] [y0] ae(v) if (sps_triangle_mode_flag && slice_type == B && cbWidth*cbHeight >= 64 && merge_subblock_flag[x0][y0] = = 0 && mmvd_flag[x0][y0] = =0) triangle_mode_flag[x0][y0] ae(v) if(triangle_mode[x0][y0] = = 0 && mmvd_flag[x0][y0] == 0 && merge_subblock_flag[x0][y0] = = 0 && (cbWidth * cbHeight) >= 64 && cbWidth <128 && cbHeight < 128){ mh_intra_flag[x0][y0] ae(v) if(mh_intra_flag[x0][y0]) { mh_intra_luma_mpm_flag[x0][y0] ae(v) if(mh_intra_luma_mpm_flag[x0] [y0]) mh_intra_luma_mpm_idx[x0][y0] ae(v) } } …

[00136] Em relação à Tabela 12, as definições dos respectivos ele- mentos de sintaxe podem ser conforme fornecidas acima.

[00137] Em um exemplo, de acordo com as técnicas da presente invenção, triangle_mode_flag[x0][y0] pode ser utilizado para indicar informações de movimento (por exemplo, dados (MV0, refldx0), (MV1, refldx1), InterDir e MMVD) a serem usadas no processamento de mo- do triangular. Em relação à Tabela 6, no presente modo triangular faz uso de informações de movimento em uma lista de integração. Em um exemplo, com a adição de MMVD, as informações de movimento na lista de integração podem ser adicionalmente modificadas. Em um exemplo, pode ser eficaz o modo triangular usar essas informações de movimento modificadas em vez das informações de movimento dire- tamente da lista de integração. Isso permitiria que as ferramentas fun- cionassem eficazmente em conjunto. Em um exemplo, para possibilitar tal abordagem, o modo triangular não teria sua própria lista de integra- ção, mas usaria a lista de integração e a sinalização de MMVD para o modo de não sub-bloco. A Tabela 13 ilustra um exemplo no qual o modo triangular não teria sua própria lista de integração, mas usaria a lista de integração e a sinalização de MMVD para o modo de não sub- bloco, de acordo com as técnicas da presente invenção. Tabela 13 coding_unit(x0, y0, cbWidth, cbHeight, treeType) { Descritor … } } if (sps_triangle_mode_flag && slice_type = B && cbWidth*cbHeight >= 64 && merge_subblock_flag[x0][y0] = = 0) triangle_mode_flag[x0][y0] ae(v) if (cu_skip_flag[x0][y0] || merge_flag[x0][y0] { if(mmvd_flag[x0][y0] = = 1) {

mmvd_merge_flag[x0][y0] ae(v) mmvd_distance_idx[x0][y0] ae(v) mmvd_direction_idx[x0][y0] ae(v) } else { else(merge_subblock_flag[x0][y0] = = 0 && MaxNumMergeCand > 1) merge_idx[x0][y0] ae(v) if(merge_subblock_flag[x0][y0] = = 1 && MaxNumSubblockMergeCand > 1) merge_subblock_idx[x0][y0] ae(v) } } …

[00138] Em relação à Tabela 13, as definições dos respectivos ele- mentos de sintaxe podem ser conforme fornecidas acima.

[00139] Novamente com referência à Figura 6, conforme ilustrado na Figura 6, a unidade de processamento interpredição 214 pode re- ceber bloco de vídeo reconstruído através da unidade de filtro 216, que pode ser parte de um processo de filtragem em circuito. A unidade de filtro 216 pode ser configurada para executar desbloqueio e/ou fil- tragem de deslocamento adaptável de amostra (SAO - Sample Adapti- ve Offset). O desbloqueio se refere ao processo de suavização dos limites de blocos de vídeo reconstruídos (por exemplo, tornar os limites menos perceptíveis para um observador). A filtragem SAO é um ma- peamento de amplitude não linear que pode ser usada para melhorar a reconstrução mediante a adição de um deslocamento aos dados de vídeo reconstruídos. A unidade de codificação por entropia 218 recebe coeficientes de transformada quantificados e dados de sintaxe prediti- vos (isto é, dados intraprevisão de movimento, dados QP etc.). A uni- dade de codificação por entropia 218 pode ser configurada para exe- cutar codificação por entropia de acordo com uma ou mais dentre as técnicas descritas na presente invenção. A unidade de codificação de entropia 218 pode ser configurada para emitir um fluxo de bits compa- tível, isto é, um fluxo de bits que um decodificador de vídeo pode rece- ber e reproduzir dados de vídeo a partir do mesmo. Dessa maneira, o codificador de vídeo 200 representa um exemplo de um dispositivo configurado para determinar se os parâmetros de previsão baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, sinalizar um sinalizador que especifica se os parâme- tros de previsão baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e sinalizar condicionalmente um sinalizador que especifica se um modo de integração com valores de diferença de vetor de movimento é utilizado para gerar parâmetros interpredição do bloco de vídeo atual com base no valor do sinalizador que especifica se os parâmetros interpredição baseados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos.

[00140] A Figura 7 é um diagrama de blocos que ilustra um exem- plo de um decodificador de vídeo que pode ser configurado para de- codificar dados de vídeo de acordo com uma ou mais técnicas desta divulgação. Em um exemplo, o decodificador de vídeo 300 pode ser configurado para reconstruir dados de vídeo com base em uma ou mais das técnicas descritas acima. Ou seja, o decodificador de vídeo 300 pode operar de maneira recíproca ao codificador de vídeo 200 descrito acima. O decodificador de vídeo 300 pode ser configurado para executar decodificação de intraprevisão e decodificação de inter- predição e, como tal, pode ser chamado de decodificador híbrido. No exemplo ilustrado na Figura 7, o decodificador de vídeo 300 inclui uma unidade de decodificação por entropia 302, uma unidade de quantifi- cação inversa 304, unidade de processamento de transformação in- versa 306, unidade de processamento de intraprevisão 308, uma uni- dade de processamento de interpredição 310, um somador 312, uma unidade de filtragem 314 e um buffer de referência 316. O decodifica-

dor de vídeo 300 pode ser configurado para decodificar dados de ví- deo de uma maneira consistente com um sistema de codificação de vídeo, que pode implementar um ou mais aspectos de um padrão de codificação de vídeo. Deve-se notar que, embora o decodificador de vídeo exemplificador 300 seja ilustrado como tendo blocos funcionais distintos, tal ilustração é para propósitos descritivos e não limita o de- codificador de vídeo 300 e/ou subcomponentes do mesmo a uma ar- quitetura específica de software ou hardware. As funções do decodifi- cador de vídeo 300 podem ser executadas com o uso de qualquer combinação de implementações de hardware, firmware e/ou software.

[00141] Conforme ilustrado na Figura 7, a unidade de decodificação por entropia 302 recebe um fluxo de bits codificado por entropia. A unidade de decodificação por entropia 302 pode ser configurada para decodificar elementos de sintaxe quantificados e coeficientes quantifi- cados a partir do fluxo de bits, de acordo com um processo recíproco para um processo de codificação por entropia. A unidade de decodifi- cação por entropia 302 pode ser configurada para executar decodifica- ção por entropia de acordo com qualquer uma dentre as técnicas de codificação por entropia descritas acima. A unidade de decodificação por entropia 302 pode analisar um fluxo de bits codificado de uma ma- neira consistente com um padrão de codificação de vídeo. O decodifi- cador de vídeo 300 pode ser configurado para analisar um fluxo de bits codificado onde o fluxo de bits codificado é gerado com base nas téc- nicas descritas acima. A unidade de quantização inversa 304 recebe coeficientes de transformada quantificados (isto é, valores de nível) e dados de parâmetro de quantização a partir da unidade de decodifica- ção de entropia 302. Os dados de parâmetro de quantificação podem incluir qualquer uma e todas as combinações de valores delta QP e/ou valores de tamanho de grupo de quantificação e similares descritos acima. O decodificador de vídeo 300 e/ou a unidade de quantificação inversa 304 podem ser configurados para determinar os valores de QP utilizados para quantificação inversa com base em valores sinalizados por um codificador de vídeo e/ou através de propriedades de vídeo e/ou parâmetros de codificação. Ou seja, a unidade de quantificação inversa 304 pode operar de uma maneira recíproca à unidade de quantificação de coeficiente 206 descrita acima. A unidade de quantifi- cação inversa 304 pode ser configurada para aplicar uma quantifica- ção inversa. A unidade de processamento de transformada inversa 306 pode ser configurada para executar uma transformação inversa para gerar dados residuais reconstruídos. As técnicas respectivamente executadas pela unidade de quantificação inversa 304 e pela unidade de processamento de transformada inversa 306 podem ser similares às técnicas executadas pela unidade de processamento de quantifica- ção/transformada inversa 208 descritas acima. A unidade de proces- samento de transformada inversa 306 pode ser configurada para apli- car uma DCT inversa, uma DST inversa, uma transformada de número inteiro inversa, uma transformada secundária não separável (NSST - Non-Separable Secondary Transform) ou processos de transformada inversa conceitualmente similares aos coeficientes de transformada a fim de produzir blocos residuais no domínio de pixel. Adicionalmente, conforme descrito acima, o fato de uma transformada específica (ou tipo de transformada específica) ser executada, pode depender de um modo intraprevisão. Conforme ilustrado na Figura 7, os dados residu- ais reconstruídos podem ser fornecidos ao somador 312. O somador 312 pode adicionar dados residuais reconstruídos a um bloco de vídeo preditivo e gerar dados de vídeo reconstruídos.

[00142] Conforme descrito acima, pode ser determinado um bloco de vídeo preditivo de acordo com uma técnica de vídeo preditivo (isto é, intraprevisão e interpredição de quadro). A unidade de processa- mento de intraprevisão 308 pode ser configurada para receber ele-

mentos de sintaxe de intraprevisão e recuperar um bloco de vídeo preditivo do buffer de referência 316. O buffer de referência 316 pode incluir um dispositivo de memória configurado para armazenar um ou mais quadros de dados de vídeo. Elementos de sintaxe de intraprevi- são podem identificar um modo de intraprevisão, como os modos de intraprevisão descritos acima. Em um exemplo, a unidade de proces- samento intraprevisão 308 pode reconstruir um bloco de vídeo de acordo com uma ou mais das técnicas de codificação intraprevisão aqui descritas. A unidade de processamento de interpredição 310 po- de receber elementos de sintaxe de interpredição e gerar vetores de movimento para identificar um bloco de previsão em um ou mais qua- dros de referência armazenados no buffer de referência 316. A unida- de de processamento de interpredição 310 pode produzir blocos com- pensados de movimento, que executam possivelmente interpolação com base em filtros de interpolação. Identificadores para filtros de in- terpolação para serem usados para estimativa de movimento com pre- cisão de subpixel podem estar incluídos nos elementos de sintaxe. A unidade de processamento de interpredição 310 pode usar filtros de interpolação para calcular valores interpolados para pixels de subnú- mero inteiro de um bloco de referência.

[00143] Conforme descrito acima, o decodificador de vídeo 300 po- de analisar um fluxo de bits codificado em que o fluxo de bits codifica- do é gerado com base nas técnicas descritas acima e conforme des- crito acima, o codificador de vídeo 200 pode gerar um fluxo de bits de acordo com as técnicas de previsão de vetor de movimento descritas acima. Dessa forma, o decodificador de vídeo 300 pode ser configura- do para executar a previsão do vetor de movimento de acordo com as técnicas descritas acima. Dessa maneira, o decodificador de vídeo 300 representa um exemplo de um dispositivo configurado para analisar um sinalizador que especifica se os parâmetros de interpredição base-

ados em sub-bloco para um bloco de vídeo atual são inferidos a partir de blocos vizinhos, e analisar condicionalmente um sinalizador que especifica se um modo de integração com valores de diferença de ve- tor de movimento é utilizado para gerar parâmetros de interpredição do bloco de vídeo atual com base no valor do sinalizador analisado que especifica se os parâmetros de interpredição baseados em um bloco de vídeo atual são inferidos a partir de blocos vizinhos.

[00144] Novamente com referência à Figura 7, a unidade de filtra- gem 314 pode ser configurada para executar filtragem em dados de vídeo reconstruídos. Por exemplo, a unidade de filtro 314 pode ser configurada para executar desbloqueio e/ou filtragem SAO, conforme descrito acima em relação à unidade de filtro 216. Além disso, deve-se notar que, em alguns exemplos, a unidade de filtragem 314 pode ser configurada para executar filtragem discricionária proprietária (por exemplo aprimoramentos visuais). Conforme ilustrado na Figura 7, um bloco de vídeo reconstruído pode ser emitido pelo decodificador de vídeo 300.

[00145] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware ou qualquer combi- nação dos mesmos. Se implementadas em software, as funções po- dem ser armazenadas em, ou transmitidas como, uma ou mais instru- ções ou código em uma mídia legível por computador e executadas por uma unidade de processamento baseada em hardware. A mídia legível por computador pode incluir mídia de armazenamento legível por computador, que corresponde a uma mídia tangível, como mídia de armazenamento de dados, ou meios de comunicação que incluam qualquer meio que facilite a transferência de um programa de compu- tador de um local para outro, por exemplo, de acordo com um protoco- lo de comunicação. Dessa maneira, a mídia legível por computador pode corresponder geralmente a (1) mídia de armazenamento tangível legível por computador que é não transitória ou (2) um meio de comu- nicação como um sinal ou uma onda portadora. A mídia de armaze- namento de dados pode ser qualquer mídia disponível que possa ser acessada por um ou mais computadores ou um ou mais processado- res para recuperar instruções, código e/ou estruturas de dados para implementação das técnicas descritas nesta divulgação. Um produto de programa de computador pode incluir uma mídia legível por compu- tador.

[00146] A título de exemplo, e sem limitação, essa mídia de arma- zenamento legível por computador pode compreender dispositivos de armazenamento RAM, ROM, EEPROM, CD-ROM ou outro armaze- namento de disco óptico, armazenamento de disco magnético ou ou- tros dispositivos de armazenamento magnético, memória flash ou qualquer outra mídia que pode ser usada para armazenar o código de programa desejado na forma de instruções ou estruturas de dados e que pode ser acessada por um computador. Além disso, qualquer co- nexão é adequadamente denominada mídia legível por computador. Por exemplo, se instruções forem transmitidas a partir de um site da Web, servidor ou outra fonte remota com o uso de um cabo coaxial, cabo de fibra óptica, par trançado, linha digital de assinantes (DSL, ou digital subscriber line), ou tecnologias sem fio como infravermelho, rá- dio e micro-ondas, então o cabo coaxial, o cabo de fibra óptica, o par trançado, a DSL ou tecnologias sem fio como infravermelho, rádio e micro-ondas estão incluídos na definição de meio. Deve ser entendido, no entanto, que a mídia de armazenamento legível por computador e a mídia de armazenamento de dados não incluem conexões, ondas por- tadoras, sinais ou outras mídias transitórias, mas, em vez disso, são direcionadas a mídia de armazenamento tangível não transitória. Os termos "disco magnético" e "disco óptico", como usados na presente invenção, incluem disco compacto ("CD" - Compact Disc), disco de laser, disco óptico, disco versátil digital ("DVD" - Digital Versatile Disc), disquete e disco Blu-ray, sendo que discos magnéticos normalmente reproduzem dados magneticamente, enquanto discos ópticos reprodu- zem dados opticamente com lasers. Combinações do exposto acima devem ser incluídas também no escopo de mídias legíveis por compu- tador.

[00147] As instruções podem ser executadas por um ou mais pro- cessadores, como um ou mais processadores digitais de sinal (DSPs), microprocessadores de propósito geral, circuitos integrados de aplica- ção específica (ASICs), matrizes de portas programáveis em campo (FPGAs) ou outros circuitos lógicos distintos ou integrados equivalen- tes. Consequentemente, o termo "processador", como usado na pre- sente invenção, pode se referir a qualquer dentre a estrutura anterior- mente mencionada ou qualquer outra estrutura adequada para imple- mentação das técnicas descritas na presente invenção. Além disso, em alguns aspectos, a funcionalidade descrita na presente invenção pode ser fornecida em módulos de software e/ou hardware dedicado configurados para codificar e decodificar, ou incorporados em um co- dec combinado. Além disso, as técnicas poderiam ser totalmente im- plementadas em um ou mais circuitos ou elementos lógicos.

[00148] As técnicas desta divulgação podem ser implementadas em uma ampla variedade de dispositivos ou aparelhos, incluindo um mono- fone sem fio, um circuito integrado (IC, ou integrated circuit) ou um con- junto de ICs (por exemplo um conjunto de chips). Vários componentes, módulos ou unidades são descritos nesta divulgação para enfatizar as- pectos funcionais de dispositivos configurados para executar as técnicas divulgadas, mas não necessariamente precisam de realização por uni- dades de hardware diferentes. 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 inte-

roperacionais, incluindo um ou mais processadores conforme descrito acima, em conjunto com software e/ou firmware adequado.

[00149] Além disso, cada bloco funcional ou vários recursos do dis- positivo de estação-base e do dispositivo terminal usados em cada uma das modalidades anteriormente mencionadas podem ser imple- mentados ou executados por um circuito, que é tipicamente um circuito integrado ou uma pluralidade de circuitos integrados. O conjunto de circuitos projetado para executar as funções descritas no presente re- latório descritivo pode incluir um processador de propósito geral, um processador digital de sinais (DSP), um circuito integrado de aplicação específica (ASIC) ou de aplicação geral, uma matriz de portas progra- mável em campo (FPGA), ou outros dispositivos lógicos programáveis, portas distintas ou lógica de transistor, ou um componente de hardwa- re distinto, ou uma combinação desses itens. O processador de propó- sito geral pode ser um microprocessador ou, alternativamente, pode ser um processador convencional, um controlador, um microcontrola- dor ou uma máquina de estado. O processador de propósito geral ou cada circuito descrito acima pode ser configurado por um circuito digi- tal ou pode ser configurado por um circuito analógico. Além disso, quando surgir uma tecnologia de fabricação de um circuito integrado que substitua os atuais circuitos integrados devido aos avanços em uma tecnologia de semicondutor, também poderá ser usado o circuito integrado resultante dessa tecnologia.

[00150] Vários exemplos foram descritos. Esses e outros exemplos estão dentro do escopo das reivindicações a seguir. Referência cruzada

[00151] Este pedido não provisório reivindica a prioridade sob 35 U.S.C.§ 119 sobre o pedido provisório n° 62/784.014 em sexta-feira, 21 de dezembro de 2018, cuja totalidade do conteúdo está aqui incor- porada a título de referência.

Claims

REIVINDICAÇÕES

1. Método de decodificação de dados de vídeo, caracteri- zado pelo fato de que compreende: decodificar um sinalizador de sub-bloco de integração es- pecificando se parâmetros de interpredição baseados em sub-bloco para uma unidade de codificação são inferidos a partir de blocos vizi- nhos; e decodificar um sinalizador de integração de diferença de vetor de movimento se um valor do sinalizador de sub-bloco de inte- gração for igual a zero e um valor de um sinalizador de diferença de vetor de movimento for igual a um, em que: o sinalizador de integração de diferença de vetor de movi- mento especifica que um parâmetro de predição com uma diferença de vetor de movimento é utilizado, e o sinalizador de diferença de vetor de movimento especifica se um modo de integração com diferença de vetor de movimento está habilitado.

2. Método de codificação de dados de vídeo, caracterizado pelo fato de que compreende: codificar um sinalizador de sub-bloco de integração especi- ficando se parâmetros de interpredição baseados em sub-bloco para uma unidade de codificação são inferidos a partir de blocos vizinhos; e codificar um sinalizador de integração de diferença de vetor de movimento se um valor do sinalizador de sub-bloco de integração for igual a zero e um valor de um sinalizador de diferença de vetor de movimento for igual a um, em que:

o sinalizador de integração de diferença de vetor de movi- mento especifica que um parâmetro de predição com uma diferença de vetor de movimento é utilizado, e o sinalizador de diferença de vetor de movimento especifica se um modo de integração com diferença de vetor de movimento está habilitado.

3. Dispositivo, caracterizado pelo fato de que compreen- de: um ou mais processadores; e um dispositivo de armazenamento acoplado ao um ou mais processadores e armazenando um programa que, quando executado por ao menos um ou mais processadores, leva o dispositivo a: decodificar um sinalizador de sub-bloco de integração es- pecificando se parâmetros de interpredição baseados em sub-bloco para uma unidade de codificação são inferidos a partir de blocos vizi- nhos; e decodificar um sinalizador de integração de diferença de vetor de movimento se um valor do sinalizador de sub-bloco de inte- gração for igual a zero e um valor de um sinalizador de diferença de vetor de movimento for igual a um, em que: o sinalizador de integração de diferença de vetor de movi- mento especifica que um parâmetro de predição com uma diferença de vetor de movimento é utilizado, e o sinalizador de diferença de vetor de movimento especifica se um modo de integração com diferença de vetor de movimento está habilitado.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende:

decodificar um sinalizador de combinação especificando se uma integração interimagem combinada e predição intraimagem é aplicada para uma unidade de codificação com o uso do sinalizador de sub-bloco de integração e um sinalizador para a integração interima- gem combinada e predição intraimagem.

5. Método, de acordo com a reivindicação 2, caracterizado pelo fato de que ainda compreende: codificar um sinalizador de combinação especificando se uma integração interimagem combinada e predição intraimagem é aplicada para uma unidade de codificação com o uso do sinalizador de sub-bloco de integração e um sinalizador para a integração interima- gem combinada e predição intraimagem.

6. Dispositivo, de acordo com a reivindicação 3, caracteri- zado pelo fato de que o programa, quando executado pelo ao menos um ou mais processadores, ainda leva o dispositivo a: decodificar um sinalizador de combinação especificando se uma integração interimagem combinada e predição intraimagem é aplicada para uma unidade de codificação com o uso do sinalizador de sub-bloco de integração e um sinalizador para a integração interima- gem combinada e predição intraimagem.

7. Dispositivo, de acordo com a reivindicação 3, caracteri- zado pelo fato de que o programa, quando executado pelo ao menos um ou mais processadores, ainda leva o dispositivo a: codificar um sinalizador de sub-bloco de integração especi- ficando se parâmetros de interpredição baseados em sub-bloco para uma unidade de codificação são inferidos a partir de blocos vizinhos; e codificar um sinalizador de integração de diferença de vetor de movimento se um valor do sinalizador de sub-bloco de integração for igual a zero e um valor de um sinalizador de diferença de vetor de movimento for igual a um.