BRPI1013339B1

BRPI1013339B1 - Método e aparelho para codificar vídeo, método e aparelho para decodificar vídeo, sinal de vídeo formatado para incluir informações e mídia legível por processador

Info

Publication number: BRPI1013339B1
Application number: BRPI1013339-9A
Authority: BR
Inventors: Dong Tian; Po-Lin Lai; Jiancong Luo
Original assignee: Interdigital Madison Patent Holdings
Priority date: 2009-02-19
Filing date: 2010-02-19
Publication date: 2021-09-21
Also published as: US20110298895A1; EP2399394B1; CN105657405A; CN102326390A; CN102326390B; HK1224496A1; EP2399394A1; CN105657405B; WO2010096189A1; JP6159849B2; CN105744284A; KR20160107357A; KR20110116239A; US12120326B2; CN105657404A; KR101940023B1; JP6159507B2; JP2012518367A; BRPI1013339A2; JP2016213842A

Abstract

método, aparelho, meio legível por processador, sinal de vídeo formatado para incluir informações e estrutura de sinal de vídeo para formatos de vídeo 3d. várias implementações se relacionam com formatos de vídeo 3d. uma ou mais implementações oferecem adaptações ao mvc e ao svc para permitir que formatos de vídeos 3d sejam usados. de acordo com aspecto geral, um conjunto de imagens incluindo de imagens incluindo vídeo e profundidade é codificado. o conjunto de imagens é relacionado de acordo com um formato de vídeo 3d específico, e é codificado de uma forma que explora a redundância entre o conjunto de imagens. as imagens codificadas são dispostas em um fluxo de bits em uma ordem especifica, com base no formato de vídeo 3d em particular que se relaciona com as imagens, a ordem específica é indicada no fluxo de bits usando informações de sinalização. de acordo com outro aspecto geral, acessa-se um fluxo de bits que inclui o conjunto codificado de imagens. as informações de sinalização também são acessadas. o conjunto de imagem é codificado usando as informações de sinalização.

Description

REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS

[001] O presente pedido reivindica o benefício da data de depósito do Pedido U.S. Provisório de No. 61/208,013, depositado em 19 de fevereiro de 2009, intitulado "3D Video Formats", cujo conteúdo é incorporado aqui por referência em sua totalidade para todos os fins.

CAMPO TÉCNICO

[002] São descritas implementações que se relacionam com sistemas de codificação. Várias implementações particulares referem-se a formatos de vídeo tridimensional (3D).

ANTECEDENTES DA INVENÇÃO

[003] Para facilitar novas aplicações de vídeo, como a televisão tridimensional (3DTV) e o vídeo com ponto de vista livre (FW), podem-se utilizar s formatos de dados de Vídeo 3D (3DV) que incluem tanto vídeo bidimensional (2D) convencional quanto vídeo com profundidade, de modo que vistas de vídeo adicionais possam ser processadas no terminal do usuário. Exemplos de tais formatos 3DV incluem o formato 2D com profundidade (2D+Z) (que incluem um vídeo 2D e o mapa de profundidade correspondente) e vídeo com profundidade em camadas (LDV) (que inclui dados em 2D+Z mais um vídeo de oclusão e uma profundidade de oclusão). O Multiview plus depth (MVD - Múltiplas vistas com profundidade, numa tradução livre) é uma extensão do 2D+Z, que consiste em vários 2D+Z a partir de diferentes pontos de vista. O Disparity enhanced stereo (DES) é outro formato que é equivalente a dois LDV a partir de duas vistas diferentes. A forma em que esses dados são transportados (codificados e transmitidos) é uma questão importante, uma vez que diferentes componentes precisam ser usados em conjunto no terminal do usuário.

SUMÁRIO

[004] De acordo com um aspecto geral, um conjunto de imagens é codificado. O conjunto de imagens inclui uma imagem de vídeo e uma imagem de profundidade correspondendo à imagem de vídeo. As imagens no conjunto de imagens são relacionadas de acordo com um formato de vídeo 3D em particular. O conjunto de imagens é codificado de uma maneira que explora a redundância entre as imagens no conjunto de imagens. As imagens codificadas são dispostas em um fluxo de bits em uma ordem específica, com base no formato de vídeo 3D em particular que se relaciona com as imagens. A ordem específica é indicada no fluxo de bits usando informações de sinalização.

[005] De acordo com outro aspecto geral, acessa-se um fluxo de bits é acessado que inclui um conjunto codificado de imagens, o conjunto de imagens incluindo uma imagem de vídeo e uma imagem de profundidade correspondendo à imagem de vídeo. O conjunto de imagens está relacionado de acordo com um formato de vídeo 3D em particular. O conjunto de imagens é codificado de uma maneira que explora a redundância entre as imagens no conjunto de imagens. Acessam-se informações de sinalização que indicam uma ordem específica em que o conjunto codificado de imagens é disposto no fluxo de bits. A ordem particular está baseada no formato de vídeo 3D em particular que se relaciona ao conjunto de imagens. O conjunto de imagens é decodificado usando as informações de sinalização.

[006] De acordo com outro aspecto geral, um sinal de vídeo é formatado para incluir informações. O sinal de vídeo inclui uma seção de sinalização que inclui informações de sinalização. As informações de sinalização indicam uma ordem específica em que o conjunto codificado de imagens é disposto em um fluxo de bits. A ordem específica está baseada em um formato de vídeo 3D específico que se relaciona ao conjunto de imagens.

[007] Os detalhes de uma ou mais implementações são apresentados nos desenhos concomitantes e na descrição a seguir. Mesmo se descritas de uma maneira particular, deve ficar claro que as implementações podem ser configuradas ou incorporadas de várias maneiras. Por exemplo, uma implementação pode ser realizada como um método ou incorporada como um aparelho, como, por exemplo, um apare- lho configurado para executar um conjunto de operações ou um aparelho que armazena instruções para realizar um conjunto de operações, ou incorporada em um sinal. Outros aspectos e características se tornarão aparentes a partir da descrição detalhada seguinte, considerada em conjunto com os desenhos apensos e as reivindicações.

DESCRIÇÃO RESUMIDA DOS DESENHOS

[008] A Figura 1 é um exemplo de um mapa de profundidade.

[009] A Figura 2 é um exemplo que mostra os quatro componentes do formato LDV.

[010] A Figura 3 é um diagrama de uma implementação de um codificador 3DV.

[011] A Figura 4 é um diagrama de uma implementação de um decodificador 3DV.

[012] A Figura 5 é um diagrama de uma implementação de um sistema de transmissão de vídeo.

[013] A Figura 6 é um diagrama de uma implementação de um sistema de recepção de vídeo.

[014] A Figura 7 é um diagrama de uma implementação de um dispositivo de processamento de vídeo.

[015] A Figura 8 é um diagrama que mostra um exemplo de codificação do formato MVD na estrutura MVC.

[016] A Figura 9 é um diagrama que mostra um exemplo de codificação do formato LDV na estrutura MVC.

[017] A Figura 10 é um diagrama que mostra um exemplo de codificação do formato DES na estrutura MVC.

[018] A Figura 11 é um diagrama de uma implementação de um primeiro processo de codificação.

[019] A Figura 12 é um diagrama de uma implementação de um primeiro processo de codificação.

[020] A Figura 13 é um diagrama que mostra outro exemplo de codificação do formato MVD na estrutura MVC.

[021] A Figura 14 é um diagrama que mostra outro exemplo de codificação do formato LDV na estrutura MVC.

[022] A Figura 15 é um diagrama que mostra outro exemplo de codificação do formato DES na estrutura MVC.

[023] A Figura 16 é um diagrama de uma implementação de um segundo processo de codificação. A Figura 17 é um diagrama de uma implementação de um segundo processo de decodificação. A Figura 18 é um diagrama que mostra um exemplo de codificação do formato LDV na estrutura SVC.

[024] A Figura 19 é um diagrama de uma implementação de um terceiro processo de codificação. A Figura 20 é um diagrama de uma implementação de um terceiro processo de decodificação. A Figura 21 é um diagrama de uma implementação de um quarto processo de codificação. A Figura 22 é um diagrama de uma implementação de um quarto processo de decodificação.

DESCRIÇÃO DETALHADA

[025] Formatos de dados 3DV, como os que incluem tanto vídeo 2D convencional quanto com profundidade, podem ser utilizados de tal forma que, por exemplo, vistas de vídeos adicionais possam ser processadas no terminal do usuário. No entanto, os inventores determinaram que existe uma desvantagem, já que os formatos 3DV não são atualmente suportados nos padrões atuais, como a codificação de vídeo escalo- nável (SVC) e a codificação de vídeo com múltiplas vistas (MVC). Uma sequência de vídeo com múltiplas vistas é um conjunto de duas ou mais sequências de vídeo que captura a mesma cena de diferentes pontos de vista.

[026] Assim, em pelo menos uma implementação, propomos a reutilização das extensões MVC ou SVC existentes na codificação de vídeo avançada (AVC) para transmitir o conteúdo 3DV com o auxílio da sinalização para extrair o conteúdo 3DV corretamente. A sinalização pode ser feita em qualquer sintaxe de alto nível, incluindo mas sem a isto se limitar, por exemplo, o conjunto de parâmetros de sequência (SPS), o conjunto de parâmetros de imagem (PPS), o cabeçalho de fatia, uma mensagem de informação de aprimoramento suplementar (SEI), e assim por diante. Ou- tros esquemas de sinalização também são possíveis e são contemplados no presente pedido.

[027] Em pelo menos uma implementação, propomos o uso da estrutura da SVC ou MVC para codificar os componentes 3DV sem a necessidade de sincronização no nível do sistema. Usando as técnicas em SVC ou MVC, os presentes princípios podem explorar a redundância entre os componentes de forma mais eficiente. Além disso, a retrocompatibilidade é mais flexível, uma vez que o vídeo 2D convencional pode ser transmitido / decodificado com apenas parte do fluxo de bits inteiro (por exemplo, a camada de base para SVC, ou a vista de base em MVC).

[028] Em pelo menos uma implementação, propomos ainda o uso de sintaxe de alto nível para sinalizar a maneira em que as vistas (na MVC) ou camadas (na SVC) devem ser compreendidas no contexto do 3DV de tal forma que uma exibição 3D possa usar as informações corretamente.

[029] Em pelo menos uma implementação, propomos uma "mensagem SEI de formato 3DV" no âmbito da estrutura da MVC e da SVC para sinalização de vários formatos 3DV. Tal implementação pode ter um ou mais, e possivelmente todas, das seguintes vantagens:• Evita a necessidade de sincronização para diferentes componentes no nível do sistema, como eles serão associados em camadas (SVC) ou em vistas simultâneas (MVC).• Melhor aproveitamento da redundância entre componentes: as predições entre componentes serão possibilitadas pelo SVC / MVC, que pode potencialmente oferecer melhor eficiência de codificação, em comparação com o AVC com métodos de intercalação.• Retrocompatibilidade com melhor flexibilidade: apenas dados parciais são necessários para aplicações de vídeo 2D convencionais no terminal do usuário.

[030] Deve-se apreciar que, embora pelo menos uma implementação envolva uma mensagem SEI, os presentes princípios, como mencionado acima, não estão limitados ao uso de uma mensagem SEI. Assim, por exemplo, outra sintaxe de alto nível, incluindo, mas não limitado a SPS, o PPS, o cabeçalho de fatia, e assim por diante.

[031] Os formatos de representação de Vídeo 3D (3DV) incluem tanto componentes de vídeo como de profundidade, tal como 2D+Z (MVD) e LDV (DES), que se tornam cada vez mais importante, à medida que as aplicações 3DV atraem mais interesse de mercado. A Figura 1 mostra um mapa de profundidade 100 ilustrativo correspondendo a uma sequência de teste MPEG conhecida como "Leaving_Laptop", ao qual os presentes princípios podem ser aplicados de acordo com uma concretização dos presentes princípios. A Figura 2 mostra os quatro componentes no formato LDV, ao qual os presentes princípios podem ser aplicados de acordo com uma concretização dos presentes princípios. Em particular, a parte superior esquerda 201 mostra uma vista de vídeo 2D, a parte superior direita 202 mostra a profundidade, a parte inferior esquerda 203 mostra a camada de vídeo de oclusão, e a parte inferior direita 204 mostra a camada de profundidade de oclusão. A codificação e transmissão dos formatos de dados acima são essenciais para várias aplicações, além de ser um desafio. Além da eficiência de codificação, funcionalidades como sincronização e retrocompatibilidade (para vídeo 2D monoscópico convencional) devem ser consideradas, de modo que um decodificador herdado possa mostrar algo do fluxo de bits.

[032] Uma solução relativamente simples é a transmissão simultânea (simulcast), na qual cada componente é codificado e transmitido de forma independente. As implementações típicas desta abordagem requerem vários codificadores / decodifica- dores e sincronização no nível do sistema ou no nível de aplicação. Em outras palavras, o custo da transmissão simultânea pode ser simplesmente multiplicado pelo número de componentes 3DV. Além disso, uma vez que diferentes componentes são codificados separadamente, qualquer redundância entre os componentes não serão exploradas.

[033] O MPEG-C Parte 3 (ISO / IEC 23002-3) especifica uma estrutura de sistema para 2D+Z. O MPEG-3 Parte C também exige sincronização no nível do sistema en- tre o vídeo e a profundidade. O vídeo e a profundidade podem ser codificados usando qualquer padrão de codificação de vídeo existente, no entanto, a codificação do vídeo e da profundidade é dissociada e nenhum benefício de codificação é obtido entre os dois componentes. O formato LDV (DES) não é especificado no MPEG-C Parte 3. As soluções de codificação para 2D+Z (MVD) e LDV (DES) ainda estão sendo exploradas, por exemplo, dentro do grupo 3DV do MPEG.

[034] Para incorporar os formatos 2D+Z (MVD) e LDV (DES) nos esquemas de codificação existentes, como SVC e MVC, em pelo menos uma implementação, propomos a utilização de alguma sintaxe de alto nível para sinalizar como os componentes 3DV podem ser extraídos dos fluxos de bits SVC ou MVC. Esta abordagem tem a vantagem de que não há necessidade de sincronização entre os diferentes componentes 3DV no nível do sistema, uma vez que serão acoplados no fluxo de bits codificado (tais como as camadas de base / aprimoramento no SVC, ou como diferentes vistas no MVC). Outro possível benefício é que a redundância entre componentes pode ser removida quando a codificação é realizada desta maneira.

Terminologia:

[035] Uma "vista 3DV", aqui, define-se como um conjunto de dados de uma posição de vista, que é diferente da "vista” usada no MVC. Para o formato 2D+Z, uma vista 3DV inclui duas sequências de componentes, ou seja, uma vista 2D mais seu mapa de profundidade. Para o formato LDV, uma vista 3DV inclui quatro sequências de componentes, ou seja, uma vista 2D, um mapa de profundidade, uma vista de oclusão, e um mapa de profundidade de oclusão.

[036] Quando um decodificador MVC (SVC) recebe um fluxo de bits incluindo as mensagens SEI propostas, o decodificador MVC (SVC) pode compor os dados 3DV de uma forma que um meio de exibição 3D possa gerar imagens adequadas.

[037] A FIG. 3 é um diagrama de uma implementação de um codificador 3DV 300 ao qual os presentes princípios podem ser aplicados, de acordo com uma concretização dos presentes princípios. O codificador 300 inclui um compositor de componente de vista 3D 355 tendo uma primeira saída em comunicação de sinal com uma entrada de um codificador MVC / SVC 305. Uma saída do codificador MVC/SVC 305 é conectada, em comunicação por sinais, com uma primeira entrada de um multiple- xador de fluxo de bits 360. Uma segunda saída do compositor de componente de vista 3D 355 é conectada, em comunicação por sinal, com uma primeira entrada de um compositor de mensagem SEI 365. Uma saída do compositor de mensagem SEI 365 é conectada, em comunicação por sinais, com uma segunda entrada do multi- plexador de fluxo de bits 360. Uma entrada do compositor de componente de vista 3D 355 está disponível como uma entrada do codificador 300, para receber conteúdo 3DV (por exemplo, uma vista 2D(s), profundidade, uma ou mais vistas de oclusão, profundidade de oclusão, um ou mais mapas de transparência, etc). Uma saída do multiplexador de fluxo de bits 360 está disponível como uma saída do codificador 300, para gerar um fluxo de bits 3DV.

[038] Com esta implementação, cada codificador de componente 3DV (não ilustrado) dentro do codificador MVC/SVC 305 é um codificador MVC ou um codificador SVC. No caso em que um codificador MVC é usado, cada codificador de componente 3DV é um codificador MVC para uma vista MVC. No caso em que um codificador SVC é usado, cada codificador de componente 3DV é um codificador SVC para uma camada SVC. O compositor de componente de vista 3D 355 é um despachante que envia componentes 3DV para vistas MVC ou camadas SVC e envia tais informações de controle ao compositor de mensagem SEI 365. O compositor de mensagem SEI 365 irá compor uma mensagem SEI para sinalização no fluxo de bits. O multiplexa- dor de fluxo de bits 360 irá multiplexar o fluxo de bits.

[039] A Figura 4 é um diagrama de uma implementação de um decodificador 3DV 400 ao qual os presentes princípios podem ser aplicados, de acordo com uma concretização dos presentes princípios. O decodificador 400 inclui um demultiplexador de fluxo de bits 460 tendo uma saída conectada, em comunicação por sinais, a uma entrada de um analisador de mensagem SEI 465 e a uma entrada de um decodifica- dor MVC / SVC 405. Uma saída do analisador de mensagem SEI 465 é conectada, em comunicação por sinais, a uma primeira entrada de um decompositor de compo- nente de vista 3D 455. Uma saída do decodificador MVC/SVC 405 é conectada, em comunicação por sinais, a uma segunda entrada do decompositor de componente de vista 3D 455. Uma entrada do demultiplexador de fluxo de bits 460 está disponível como uma entrada do decodificador 400, para receber um fluxo de bits 3DV. Uma saída do decompositor de componente de vista 3D 455 está disponível como uma saída do codificador 400, para gerar conteúdo 3DV formatado (por exemplo, uma ou mais vistas 2D, profundidade, uma ou mais vistas de oclusão, profundidade de oclusão, um ou mais mapas de transparência, etc).

[040] As Figuras 3 e 4 mostram implementações particulares, mas outras implementações são contempladas. Por exemplo, outra implementação não tem entradas separadas em um ou mais dos blocos da Figura 3 (ou Figura 4). Em vez disso, uma única entrada é usada para receber múltiplos sinais. Como um exemplo específico, o multiplexador de fluxo de bits 360 pode ter apenas uma única entrada. A entrada única recebe a saída do codificador MVC / SVC 305, bem como a saída do compositor de mensagens SEI 365. Além disso, outra implementação do compositor de componente de vista 3D 355 só tem uma única saída que fornece tanto o sinal para o compositor de mensagem SEI 365 como o sinal para o codificador MVC / SVC 305. Adaptações semelhantes são contempladas para a implementação da Figura 4, bem como outras figuras e implementações descritas ao longo deste pedido.

[041] A Figura 5 mostra um sistema de transmissão de vídeo 700 ilustrativo, ao qual os presentes princípios podem ser aplicados de acordo com uma implementação dos presentes princípios. O sistema de transmissão vídeo 700 pode ser, por exemplo, um sistema de transmissão head-end para a transmissão de um sinal usando qualquer um dentre uma variedade de meios, como, por exemplo, satélite, cabo, linha telefônica ou transmissão terrestre. A transmissão pode ser obtida através da Internet ou por alguma outra rede.

[042] O sistema de transmissão de vídeo 700 é capaz de gerar e distribuir, por exemplo, conteúdo de vídeo e profundidade. Isso é obtido por meio da geração de um ou mais sinais codificados incluindo informações de profundidade ou informa- ções capazes de serem usadas para sintetizar as informações de profundidade em um terminal receptor que pode, por exemplo, incluir um decodificador.

[043] O sistema de transmissão de vídeo 700 inclui um codificador 710 e um transmissor 720 capaz de transmitir o sinal codificado. O codificador 710 recebe informações de vídeo e gera um ou mais sinais codificados com base nas informações de vídeo e / ou nas informações de profundidade. O codificador 710 pode ser, por exemplo, o codificador 300 descrito em detalhes acima. O codificador 710 pode incluir submódulos, incluindo, por exemplo uma unidade de montagem para receber e montar várias unidades de informação em um formato estruturado para armazenamento ou transmissão. Os vários segmentos de informação podem incluir, por exemplo, vídeo codificado ou não codificado, informação de profundidade codificada ou não codificada, e elementos codificados ou não codificados, como, por exemplo, vetores de movimento, indicadores de modo de codificação e elementos de sintaxe.

[044] O transmissor 720 pode ser, por exemplo, adaptado para transmitir um sinal de programa contendo um ou mais fluxos de bits representando imagens codificadas e / ou informações relacionadas a elas. Os transmissores típicos desempenham funções como, por exemplo, um ou mais dentre proporcionar codificação de correção de erros, intercalar os dados no sinal, aleatorizar a energia no sinal, e modular o sinal em uma ou mais portadoras. O transmissor pode incluir, ou fazer interface com, uma antena (não ilustrada). Logo, as implementações do transmissor 720 podem incluir, ou ser limitadas a, um modulador.

[045] A Figura 6 mostra um sistema de recepção de vídeo 800 ilustrativo, ao qual os presentes princípios podem ser aplicados de acordo com uma concretização dos presentes princípios. O sistema de recepção de vídeo 800 pode ser configurado para receber sinais por de uma variedade de meios, como, por exemplo, transmissão via satélite, cabo, linha telefônica, ou terrestre. Os sinais podem ser recebidos através da Internet ou por alguma outra rede.

[046] O sistema de recepção de vídeo 800 pode ser, por exemplo, um telefone celular, um computador, um decodificador de sinais, uma televisão, ou outro dispositivo que recebe vídeo codificado e fornece, por exemplo, vídeo decodificado para exibição a um usuário ou para armazenamento. Assim, o sistema de recepção de vídeo 800 pode fornecer sua saída, por exemplo, a uma tela de uma televisão, a um monitor de computador, a um computador (para armazenamento, processamento, ou exibição), ou algum outro dispositivo de armazenamento, processamento ou exibição.

[047] O sistema de recepção de vídeo 800 é capaz de receber e processar conteúdo de vídeo incluindo informações de vídeo. O sistema de recepção de vídeo 800 inclui um receptor 810 capaz de receber um sinal codificado, como por exemplo, os sinais descritos nas implementações deste pedido, e um decodificador 820 capaz de decodificar o sinal recebido.

[048] O receptor 810 pode ser, por exemplo, adaptado para receber um sinal de programa tendo uma pluralidade de fluxos de bits representando imagens codificadas. Os receptores típicos desempenham funções como, por exemplo, um ou mais dentre receber um sinal de dados modulado e codificado, demodular o sinal de dados de uma ou mais portadoras, desaleatorizar a energia no sinal, desintercalar os dados no sinal, e codificar o sinal com correção de erros. O receptor 810 pode incluir, ou fazer interface com, uma antena (não ilustrada). As implementações do receptor 810 podem incluir, ou ser limitadas a, um demodulador.

[049] O decodificador 820 gera sinais de vídeo incluindo informações de vídeo e informações de profundidade. O codificador 820 pode ser, por exemplo, o codificador 400 descrito em detalhes acima.

[050] A Figura 7 mostra um dispositivo de processamento de vídeo 900 ilustrativo, ao qual os presentes princípios podem ser aplicados, de acordo com uma concretização dos presentes princípios. O dispositivo de processamento de vídeo 900 pode ser, por exemplo, um decodificador de sinais, ou outro dispositivo que receba vídeo codificado e forneça, por exemplo, vídeo decodificado para exibição a um usuário ou para armazenamento. Assim, o dispositivo de processamento de vídeo 900 pode fornecer sua saída a uma televisão, monitor de computador ou a um computador ou outro dispositivo de processamento.

[051] O dispositivo de processamento de vídeo 900 inclui um dispositivo de frontend (FE) 905 e um decodificador 910. O dispositivo de front-end 905 pode ser, por exemplo, um receptor adaptado para receber um sinal de programa tendo uma pluralidade de fluxos de bits representando imagens codificadas, e selecionar um ou mais fluxos de bits para decodificação a partir da pluralidade de fluxos de bits. Os receptores típicos desempenham funções como, por exemplo, um ou mais dentre receber um sinal de dados modulado e codificado, demodular o sinal de dados, decodificar uma ou mais codificações (por exemplo, codificação de canal e / ou codificação de fonte) do sinal de dados e / ou correção de erros do sinal de dados. O dispositivo de front-end 905 pode receber o sinal de programa a partir, por exemplo, uma antena (não ilustrada). O dispositivo de front-end 905 fornece um sinal de dados recebido ao decodificador 910.

[052] O decodificador 910 recebe um sinal de dados 920. O sinal de dados 920 pode incluir, por exemplo, um ou mais fluxos compatíveis com Codificação de Vídeo Avançada (AVC), Codificação de Vídeo Escalonável (SVC), ou Codificação de Vídeo com Múltiplas vistas (MVC).

[053] O AVC se refere, mais especificamente, ao padrão existente Codificação de Vídeo Avançada (AVC) Parte 10 do Moving Picture Experts Group-4 (MPEG-4) da Organização Internacional de Normalização/Comissão Eletrotécnica Internacional (ISO/IEC) / à Recomendação H.264 do Telecommunication Union standard / International (ITU-T) (doravante chamado de “Padrão AVC MPEG-4/H.264” ou suas variantes, tal como o “padrão AVC” ou simplesmente “AVC”).

[054] O MVC se refere mais especificamente a uma extensão de codificação de vídeo com Múltiplas vistas ("MVC") (Anexo H) do padrão AVC, chamada de extensão MVC do H.264/MPEG-4 AVC ("extensão MVC" ou simplesmente "MVC").

[055] O SVC se refere, mais especificamente, a uma extensão de codificação de vídeo escalonável ("MVC") (Anexo G) do padrão AVC, chamada de extensão SVC do H.264/MPEG-4 AVC ("extensão SVC" ou simplesmente "SVC").

[056] O decodificador 910 decodifica todo o sinal recebido 920 ou parte dele e fornece, como saída, um sinal de vídeo decodificado 930. O vídeo decodificado 930 é fornecido a um seletor 950. O dispositivo 900 também inclui uma interface do usu-ário 960 que recebe uma entrada do usuário 970. A interface do usuário 960 fornece um sinal de seleção de imagem 980, com base na entrada do usuário 970, ao seletor 950. O sinal de seleção de imagem 980 e a entrada do usuário 970 indicam qual das várias imagens, sequências, versões escalonáveis, vistas ou outras seleções dos dados disponíveis decodificados o usuário deseja que seja exibido. O seletor de 950 fornece a(s) imagem(ns) selecionada(s) como uma saída 990. O seletor 950 usa as informações de seleção de imagem 980 para selecionar qual das imagens no vídeo decodificado 930 para fornecer como a saída 990.

[057] Em várias implementações, o seletor 950 inclui a interface do usuário 960, e em outras implementações, nenhuma interface do usuário 960 é necessária, pois o seletor 950 recebe a entrada do usuário 970 diretamente, sem uma função de interface separada sendo realizada. O seletor 950 pode ser implementado em software ou como um circuito integrado, por exemplo. Em uma implementação, o seletor 950 é incorporado com o decodificador 910, e em outra implementação, o decodificador 910, o seletor 950 e a interface do usuário 960 são todos integrados.

[058] Em uma aplicação, o front-end 905 recebe uma transmissão de vários programas de televisão e seleciona um para processamento. A seleção de um programa é baseada na entrada do usuário de um canal que se deseja assistir. Embora a entrada do usuário para o dispositivo de front-end 905 não seja ilustrada na Figura 7, o dispositivo de front-end 905 recebe a entrada do usuário 970. O front-end 905 recebe a transmissão e processa o programa desejado por meio da demodulação da parte relevante do espectro de transmissão, e pela decodificação de qualquer codificação externa do programa demodulado. O front-end 905 fornece o programa decodificado ao decodificador 910. O decodificador 910 é uma unidade integrada que inclui os dispositivos 960 e 950. O decodificador 910, portanto, recebe a entrada do usuário, que é uma indicação fornecida pelo usuário de uma vista que se deseja assistir no programa. O decodificador 910 decodifica a vista selecionada, bem como quaisquer imagens de referência necessários a partir de outras vistas, e fornece a vista decodificada 990 para exibição em uma televisão (não ilustrada).

[059] Dando continuidade à aplicação acima, o usuário pode desejar trocar a vista que é exibida e pode então fornecer uma nova entrada ao decodificador 910. Depois de receber uma "alteração de vista" do usuário, o decodificador 910 decodifica tanto a vista antiga como a vista nova, bem como quaisquer vistas que estejam entre a vista antiga e nova vista. Ou seja, o decodificador 910 decodifica as vistas que são obtidas por câmeras que estão fisicamente localizadas entre a câmera que tirou a vista antiga e a câmera que está tirando a nova vista. O dispositivo de front-end 905 também recebe as informações que identificam a vista antiga, a nova vista, e as vistas entre estas. Tal informação pode ser fornecida, por exemplo, por um controlador (não ilustrado na Figura 7) com informações sobre as localizações das vistas, ou pelo decodificador 910. Outras implementações podem usar um dispositivo de frontend que tem um controlador integrado ao dispositivo de front-end.

[060] O decodificador 910 fornece todas essas vistas decodificadas como a saída 990. Um pós-processador (não ilustrado na Figura 7) realiza a interpolação entre as vistas para proporcionar uma transição suave da antiga vista para a nova vista e exibe esta transição para o usuário. Após realizar a transição para a nova vista, o pós- processador informa (através de um ou mais links de comunicação, não ilustrados) o decodificador 910 e o dispositivo front-end 905 de que somente a nova vista é necessária. Em seguida, o decodificador 910 só fornece como saída 990 a nova vista.

[061] O sistema 900 pode ser usado para receber múltiplas vistas de uma se-quência de imagens e apresentar uma única vista para exibição, e para alternar entre as várias vistas de maneira suave. A forma suave pode envolver interpolação entre as vistas para passar para outra vista. Além disso, o sistema 900 pode permitir que o usuário gire um objeto ou cena, ou de alguma outra forma visualize uma representação tridimensional de um objeto ou uma cena. A rotação do objeto, por exemplo, pode corresponder à passagem entre vistas, e interpolação entre as vistas para obter uma transição suave entre as vistas ou para simplesmente obter uma re- presentação tridimensional. Ou seja, o usuário pode "selecionar" uma vista interpolada como a "vista" que está para ser exibida.

[062] Deve ficar claro que o sistema de transmissão de vídeo 700, o sistema de recepção de vídeo 800 e o dispositivo de processamento de vídeo 900 podem ser adaptados para uso com as várias implementações descritas no presente pedido. Por exemplo, os sistemas 700, 800 e 900 podem ser adaptados para operar com dados em um dos formatos 3DV discutidos, bem como com as informações de sinalização associadas.Concretização 1: Mensagem SEI de formato 3DV para MVC

[063] Na estrutura do MVC, as sequências de componentes 3DV são codificadas como diferentes "vistas". Assim, a redundância entre componentes pode ser removida por predição intervistas, que é uma característica do MVC. Por exemplo, a redundância entre a vista 2D e as vistas de oclusão poderia ser removida de maneira eficiente. A TABELA 1 mostra a sintaxe proposta para uma mensagem SEI de formato 3DV para MVC pertencente à Concretização 1. Note que o fluxo de bits MVC pode incluir mais vistas além das sequências de componentes 3DV nesta concretização.

[064] A semântica dos elementos de sintaxe da TABELA 1 são como se segue.three_dv_format_id inclui um número de identificação que pode ser usado para identificar o uso da mensagem SEI de formato 3DV. O valor deverá estar na faixa de 0 a 232- 2, inclusive. Deve-se notar que valores de 0 a 255 e de 512 a 231 - 1 podem ser usados, conforme determinado pela aplicação. Os valores de 256 a 511 e de 231 a 232 - 2 são reservados para uso futuro. Os decodificadores deverão ignorar (remover do fluxo de bits e descartar) todas as mensagens SEI de formato 3DV que incluam um valor de three_dv_format_id na faixa de 256 a 511 ou na faixa de 231 a 232 - 2, e os fluxos de bits não deverão incluir tais valores.three_dv_format_cancel_flag igual a 1 indica que a mensagem SEI de for-mato 3DV cancela a persistência de qualquer mensagem SEI de formato 3DV ante-rior na ordem de saída. three_dv_format_cancel_flag igual a 0 indica que se seguem informações de formato 3DV.num_three_dv_view_minus1 mais 1 indica o número de vistas que possuem dados 3DV. Cada vista tem um número de ID único no contexto do formato 3DV, 3dv_view_id, variando de 0 a num_three_dv_view_minus1, inclusive. Deve-se notar que 3dv_view_id é diferente de view_id no contexto do MVC. Para os dados 3DV de uma vista, tal como uma vista 2D, seu mapa de profundidade, e assim por diante, são tratados como vistas diferentes no MVC e têm diferentes view_id's, mas compartilham o mesmo 3dv_view_id, uma vez que correspondem a diferentes sequências de componentes da mesma posição de vista.basic_three_dv_format_type_id indica o tipo de formato 3DV básico incluso no fluxo de bits MVC. O formato 3DV pode ser de dois tipos: 2D+Z; ou LDV. O for-mato 2D+Z inclui uma vista 2D mais seu mapa de profundidade a partir de uma po-sição de vista. O formato LDV inclui uma vista 2D, seu mapa de profundidade, uma vista de oclusão, e um mapa de profundidade da oclusão de uma posição de vista.basic_three_dv_format_type_id igual a 0 indica que o fluxo de bits MVC in-clui (num_three_dv_view_minus1 + 1) conjuntos de dados 2D+Z. Cada conjunto de dados corresponde a uma posição de vista, num_three_dv_view_minus1 igual a 0 representa o formato 2D+Z. num_three_dv_view_minus1 igual ou maior do que 1 representa o formato MVD.basic_three_dv_format_type_id igual a 1 indica que o fluxo de bits MVC in-clui (num_three_dv_view_minus1 + 1) conjuntos de dados LDV. Cada conjunto de dados corresponde a uma posição de vista, num_three_dv_view_minus1 igual a 0 representa o formato LDV. num_three_dv_view_minus1 igual a 1 representa o for-mato DES. Deve-se notar que valores maiores do que 1 não são permitidos. video_present_flag[3dv_view_id] indica se o componente de vídeo 2D está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de vista 2D. Um valor igual a 0 indica a ausência do componente de vista 2D.video_id[3dv_view_id] indica o view_id no fluxo de bits MVC que corresponde à vista 3DV com 3dv_view_id. Um valor igual a -1 indica que nenhum componente de vista 2D para a vista 3DV está disponível no fluxo de bits.video_present_flag[3dv_view_id] indica se o componente de mapa de pro-fundidade está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de mapa de profundidade. Um valor igual a 0 indica a ausência do componente de mapa de profundidade.depth_id[3dv_view_id] indica o view_id no fluxo de bits MVC que corresponde ao componente de profundidade 3DV com 3dv_view_id. Um valor igual a -1 indica que nenhum componente de profundidade para a vista 3DV está disponível no fluxo de bits.occlusion_video_present_flag[3dv_view_id] indica se o componente de vídeo de oclusão está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de vídeo de oclusão. Um valor igual a 0 indica a ausência do componente de vídeo de oclusão.occlusion_video_id[3dv_view_id] indica o view_id no fluxo de bits MVC que corresponde ao componente de vídeo de oclusão com 3dv_view_id. Um valor igual a -1 indica que nenhum componente de vídeo de oclusão para a vista 3DV está disponível no fluxo de bits.occlusion_depth_present_flag[3dv_view_id] indica se o componente de profundidade de oclusão está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de profundidade de oclusão. Um valor igual a 0 indica a ausência do componente de profundidade de oclusão.occlusion_depth_id[3dv_view_id] indica o view_id no fluxo de bits MVC que corresponde ao componente de profundidade de oclusão com 3dv_view_id. Um valor igual a -1 indica que nenhum componente de profundidade de oclusão para a vis- ta 3DV está disponível no fluxo de bits.three_dv_format_repetition_period especifica a persistência da mensagem SEI de formato 3DV e pode especificar um intervalo de contagem de ordem de ima-gem dentro do qual outra SEI de formato 3DV com o mesmo valor de three_dv_format_id ou pode especificar que o final da sequência de vídeo codificada está presente no fluxo de bits. Assim, esta sintaxe especifica o intervalo de tempo quando a SEI é válida. Uma implementação exemplificativa envolve o uso do intervalo POC (contagem de ordem de imagem). O POC pode ser entendido como um índice de quadros sendo codificados, que é ascendente com o aumento do tempo de exibição. O valor de three_dv_format_repetition_period deverá estar na faixa de 0 a 16384, inclusive. three_dv_format_repetition_period igual a 0 especifica que a mensagem SEI de formato 3DV se aplica apenas à imagem atual decodificada. three_dv_format_repetition_period igual a 1 especifica que a mensagem SEI de formato 3DV persiste na ordem de saída até que qualquer uma das condições seguintes seja verdadeira:

[065] Uma nova sequência de vídeo codificada começa.

[066] Uma imagem em uma unidade de acesso incluindo uma mensagem SEI de formato 3DV com o mesmo valor de three_dv_format_id é gerada com PicOrderCnt() maior do que PicOrderCnt( CurrPic).three_dv_format_repetition_period igual a 0 ou igual a 1 indica que outra mensagem SEI de formato 3DV com o mesmo valor de three_dv_format_id pode ou não estar presente. three_dv_format_repetition_period maior do que 1 especifica que a mensagem SEI de formato 3DV persiste até que qualquer uma das condições seguintes seja verdadeira:

[067] Uma nova sequência de vídeo codificada começa.

[068] Uma imagem em uma unidade de acesso incluindo uma mensagem SEI de formato 3DV com o mesmo valor de three_dv_format_id é gerada com PicOrderCnt() maior do que PicOrderCnt( CurrPic) e menor ou igual a PicOrderCnt( CurrPic ) + three_dv_format_repetition_period. three_dv_format_repetition_period maior do que 1 indica que outra mensa-gem SEI de formato 3DV com o mesmo valor de three_dv_format_id deverá estar presente para uma imagem em uma unidade de acesso que é gerada com PicOr- derCnt() maior do que PicOrderCnt( CurrPic ) e menor do que ou igual a PicOr- derCnt( CurrPic ) + three_dv_format_repetition_period, a menos que o fluxo de bits ou uma nova sequência de vídeo codificada comece sem a saída de tal imagem.additionalextensionflag igual a 0 indica que nenhum dado adicional seguirá dentro da mensagem SEI de formato 3DV. O valor de additional_extension_flag de-verá ser igual 0. Um valor de 1 para additional_extension_flag é reservado para uso futuro pelo ITU-T e ISO / IEC. Os descodificadores que estejam em conformidade com a Norma H. 264 deverão ignorar todos os dados que seguem o valor de 1 para additional_extension_flag em uma mensagem SEI de imagens especialmente inter-calada.

[069] Três exemplos são apresentados abaixo.

[070] Exemplo 1: A Figura 8 é um diagrama que mostra um exemplo 1000 de codi-ficação do formato MVD na estrutura MVC. Há duas vistas 3DV neste exemplo. 3dv_view_id da vista esquerda é 0 e 3dv_view_id da vista direita é 1. A vista esquer-da é tratada como a vista de base, que pode ser decodificada por um decodificador compatível com AVC, view_id da vista esquerda 1010 é 1. view_id da profundidade esquerda 1005, da vista direita 1015 e da profundidade direita 1020 é 0, 2 e 3, res-pectivamente. A TABELA 2 mostra um exemplo de uma mensagem SEI 3DV para MVC correspondendo ao Exemplo 1 da Concretização 1.

[071] Note que as informações de dependência de vista, como mostra a Figura 8, são sinalizada através da extensão SPS para H.264 Anexo H (também conhecida como a extensão MVC do H. 264 ou, simplesmente, como extensão MVC).

[072] Exemplo 2: A Figura 9 é um diagrama que mostra um exemplo 1100 de co-dificação do formato LDV na estrutura MVC. Há apenas uma vista 3DV neste exem-plo. A vista 2D é tratada como a vista de base, que pode ser decodificada por um decodificador compatível com AVC. O view_id da vista 2D 1110 é 1. o view_id do mapa de profundidade 1105, do vídeo de oclusão 1115, e do mapa de profundidade de oclusão 1120 é 0, 2 e 3, respectivamente. A TABELA 3 mostra um exemplo LDV de uma mensagem SEI 3DV para MVC correspondendo à Concretização 1, Exemplo 2.

[073] Exemplo 3: A Figura 10 é um diagrama que mostra um exemplo 1200 de codificação do formato DES na estrutura MVC. Há duas vistas 3DV neste exemplo. A vista 2D da esquerda é tratada como a vista de base, que pode ser decodificada por um decodificador compatível com AVC, view_id da vista 2D 1220 da esquerda é 3. O view_id do mapa de profundidade 1215, do vídeo de oclusão 1210, e do mapa de profundidade de oclusão 1205 a partir da esquerda é 2, 1 e 0, respectivamente, o view_id da vista 2D 1225, o mapa de profundidade 1230, o vídeo de oclusão 1235, e a profundidade de oclusão 1240 a partir da direita é 4, 5, 6 e 7, respectivamente. A TABELA 4 mostra um exemplo DES de uma mensagem SEI 3DV para MVC corres-pondendo à Concretização 1, Exemplo 3.

[074] Note que, nos três exemplos anteriores, além das vistas 3DV, algumas ou-tras vistas, que possuem apenas dados de vídeo 2D, podem ser intercaladas no mesmo fluxo de bits. O decodificador pode ainda extrair as vistas 3DV corretas do fluxo de bits corretamente. Vistas adicionais podem ser usadas, por exemplo, para melhorar a qualidade de renderização no terminal receptor.

[075] A Figura 11 é um diagrama de fluxo de dados que mostra um método exemplificativo 1300 para codificação de formatos 3DV, de acordo com uma concretização dos presentes princípios. A Figura 11 está direcionada à Concretização 1, e coletivamente abrange os exemplos 1 a 3 correspondendo a ela. Na etapa 1305, o elemento de sintaxe three_dv_format_id é codificado. Na etapa 1310, o elemento de sintaxe three_dv_format_cancel_flag é codificado. Na etapa 1315, determina-se se three_dv_format_cancel_flag = 0 ou não. Se sim, então o controle é passado para uma etapa 1385. Caso contrário, o controle é passado para uma etapa 1320. Na etapa 1320, o elemento de sintaxe num_three_dv_view_minus1 é codificado. Na etapa 1325, o elemento de sintaxe basic_three_dv_format_type_id é codificado. Na etapa 1330, inicia-se um loop para 3dv_view_id = 0; 3dv_view_id <= num_three_dv_view_minus1; e 3dv_view_id++. Na etapa 1335, o elemento de sinta- xe video_present_flag[3dv_view_id] é codificado se 3dv_view_id! = 0; senão, supõe- se que o elemento de sintaxe 3dv_view_id seja igual a 1. Na etapa 1340, o elemento de sintaxe video_id[3dv_view_id] é codificado se video_present_flag[3dv_view_id! == 1. Na etapa 1345, o elemento de sintaxe depth_present_flag[3dv_view_id] é codificado. Na etapa 1350, o elemento de sintaxe depth_id[3dv_view_id] é codificado se depth_present_flag[3dv_view_id] == 1. Na etapa 1355, o elemento de sintaxe occlu- sion_video_present_flag[3dv_view_id] é codificado se ba- sic_three_dv_format_type_id ==1; caso contrário, presume-se que o elemento de sintaxe basic_three_dv_format_type_id seja igual a 0. Na etapa 1360, o elemento de sintaxe occlusion_video_id[3dv_view_id] é codificado se occlusi- on_video_present_flag[3dv_view_id]!= 0. Na etapa 1365, o elemento de sintaxe oc- clusion_depth_present_flag[3dv_view_id] é codificado se basic_three_dv_format ==1; caso contrário, presume-se que o elemento de sintaxe basic_three_dv_format seja igual a 0. Na etapa 1370, o elemento de sintaxe occlusi- on_depth_id[3dv_view_id] é codificado se occlusi-on_depth_present_flag[3dv_view_id]!= 0. Na etapa 1375, termina-se o loop para 3dv_view_id = 0, 3dv_view_id <= num_three_dv_view_minus1 e 3dv_view_id++. Na etapa 1380, o elemento de sintaxe three_dv_format_repetition é codificado. Na etapa 1385, o elemento de sintaxe additional_extension_flag é codificado.

[076] A Figura 12 é um diagrama de fluxo de dados que mostra um método exemplificativo 1400 para decodificação de formatos 3DV, de acordo com uma con-cretização dos presentes princípios. A Figura 12 está direcionada à Concretização 1, e coletivamente abrange os exemplos 1 a 3 correspondendo a ela. Na etapa 1405, o elemento de sintaxe three_dv_format_id é codificado. Na etapa 1410, o elemento de sintaxe three_dv_format_cancel_flag é decodificado. Na etapa 1415, determina-se se three_dv_format_cancel_flag == 0 ou não. Neste caso, então o controle passa para uma etapa 1485. Caso contrário, o controle é passado para uma etapa 1420. Na etapa 1420, o elemento de sintaxe num_three_dv_view_minus1 é decodificado. Na etapa 1425, o elemento de sintaxe basic_three_dv_format_type_id é decodifica- do. Na etapa 1430, inicia-se um loop para 3dv_view_id = 0; 3dv_view_id <= num_three_dv_view_minus1, e 3dv_view_id++. Na etapa 1435, o elemento de sinta-xe video_present_flag[3dv_view_id] é decodificado se 3dv_view_id! = 0; senão, su-põe-se que o elemento de sintaxe 3dv_view_id seja igual a 1. Na etapa 1440, o ele-mento de sintaxe video_id[3dv_view_id] é decodificado se vi- deo_present_flag[3dv_view_id!] == 1. Na etapa 1445, o elemento de sintaxe de- pth_present_flag[3dv_view_id] é decodificado. Na etapa 1450, o elemento de sintaxe depth_id[3dv_view_id] é decodificado se depth_present_flag[3dv_view_id] == 1. Na etapa 1455, o elemento de sintaxe occlusion_video_present_flag[3dv_view_id] é decodificado se basic_three_dv_format_type_id ==1; caso contrário, presume-se que o elemento de sintaxe basic_three_dv_format_type_id seja igual a 0. Na etapa 1460, o elemento de sintaxe occlusion_video_id[3dv_view_id] é decodificado se occlusi- on_video_present_flag[3dv_view_id]!= 0. Na etapa 1465, o elemento de sintaxe oc- clusion_depth_present_flag[3dv_view_id] é decodificado se ba- sic_three_dv_format_type_id ==1; caso contrário, presume-se que o elemento de sintaxe basic_three_dv_format_type_id seja igual a 0. Na etapa 1470, o elemento de sintaxe occlusion_depth_id[3dv_view_id] é decodificado se occlusi- on_depth_present_flag[3dv_view_id]!= 0. Na etapa 1475, termina-se o loop para 3dv_view_id = 0, 3dv_view_id <= num_three_dv_view_minus1 e 3dv_view_id++. Na etapa 1480, o elemento de sintaxe three_dv_format_repetition_period é decodifica-do. Na etapa 1485, o elemento de sintaxe additional_extension_flag é decodificado.Concretização 2: Mensagem SEI de formato 3DV simplificada para MVC

[077] Note que, em outra concretização, pode ser desejado mapear o view_id pa-ra 3d_view_id de forma implícita e a sintaxe pode ser simplificada a partir da Concretização 1. A TABELA 5 mostra uma mensagem SEI de formato 3DV simplificada para MVC.TABELA 5

[078] Com a mensagem SEI simplificada, os view_id são mapeados para 3dv_view_id’d da seguinte maneira implícita. Quando basic_3dv_format_type_id é 0, os view_id’s em ordem crescente são mapeados para 3dv_view_id’s, conforme mostra na TABELA 6. Quando basic_3dv_format_type_id é 1, os view_id’s em ordem ascendente são mapeados para 3dv_view_id’s, conforme mostra a TABELA 7.

Exemplo 1:

[079] A Figura 13 é um diagrama que mostra outro exemplo 1500 de codificação do formato MVD na estrutura MVC em que o mapeamento de view_id para 3d_view_id da TABELA 6 é usado. Os numerais V0, V1, V2, e V3 respectivamente ilustrados nas caixas 1505, 1510, 1515 e 1520 representam o view_id correspondente para esta caixa. O 3dv_view_id correspondente para cada caixa é respectivamente indicado abaixo de cada caixa. A seta aponta de uma vista de referência para uma vista a ser predita. A caixa 1505 indica o vídeo 2D da vista esquerda. A caixa 1510 indica a profundidade da vista esquerda. A caixa 1515 indica o vídeo 2D da vista direita. A caixa 1520 indica a profundidade da vista direita.

Exemplo 2:

[080] A Figura 14 é um diagrama que mostra outro exemplo 1600 de codificação do formato LDV na estrutura MVC em que o mapeamento de view_id para 3d_view_id da TABELA 7 é usado. Os numerais V0, V1, V2, e V3 respectivamente ilustrados nas caixas 1605, 1610, 1615 e 1620 representam o view_id correspondente para esta caixa. Abaixo de cada caixa está uma indicação do papel desta caixa no contexto de 3DV. A seta aponta de uma vista de referência para uma vista a ser predita. A caixa 1605 indica o vídeo 2D. A caixa 1610 indica a profundidade correspondente. A caixa 1615 indica o vídeo de oclusão correspondente. A caixa 1620 indica a profundidade de oclusão correspondente.

Exemplo 3:

[081] A Figura 15 é um diagrama que mostra outro exemplo 1700 de codificação do formato DES na estrutura MVC em que o mapeamento de view_id para 3d_view_id da TABELA 7 é usado. Os numerais V0, V1, V2, V3, V4, V5, V6 e V7 respectivamente ilustrados nas caixas 1705, 1710, 1715, 1720, 1725, 1730, 1735 e 1740 representam o view_id correspondente para essa caixa. Abaixo de cada caixa está uma indicação do papel desta caixa no contexto de 3DV. A seta aponta de uma vista de referência para uma vista a ser predita. A caixa 1705 indica o vídeo 2D da vista esquerda. A caixa 1710 indica a profundidade correspondente da vista esquer- da. A caixa 1715 indica o vídeo de oclusão correspondente da vista esquerda. A caixa 1720 indica a profundidade de oclusão correspondente da vista esquerda. A caixa 1725 indica o vídeo 2D da vista direita. A caixa 1730 indica a profundidade correspondente da vista direita. A caixa 1735 indica o vídeo de oclusão correspondente da vista direita. A caixa 1740 indica a profundidade de oclusão correspondente da vista direita.

[082] A Figura 16 é um diagrama de fluxo de dados que mostra um método exem- plificativo 1800 para codificação de formatos 3DV, de acordo com uma concretização dos presentes princípios. A Figura 16 está direcionada à Concretização 2, e coletivamente abrange os exemplos 1 a 3 correspondendo a ela. Na etapa 1805, o elemento de sintaxe three_dv_format_id é codificado. Na etapa 1810, o elemento de sintaxe three_dv_format_cancel_flag é codificado. Na etapa 1815, determina-se se three_dv_format_cancel_flag == 0 ou não. Se sim, então o controle é passado para uma etapa 1835. Caso contrário, o controle é passado para uma etapa 1820. Na etapa 1820, o elemento de sintaxe num_three_dv_view_minus1 é codificado. Na etapa 1825, o elemento de sintaxe basic_three_dv_format_type_id é codificado. Na etapa 1830, o elemento de sintaxe three_dv_format_repetition é codificado. Na etapa 1835, o elemento de sintaxe additional_extension_flag é codificado.

[083] A Figura 17 é um diagrama de fluxo de dados que mostra um método exemplificativo 1900 para decodificação de formatos 3DV, de acordo com uma con-cretização dos presentes princípios. A Figura 17 está direcionada à Concretização 2, e coletivamente abrange os exemplos 1 a 3 correspondendo a ela. Na etapa 1905, o elemento de sintaxe three_dv_format_id é codificado. Na etapa 1910, o elemento de sintaxe three_dv_format_cancel_flag é decodificado. Na etapa 1915, determina-se se three_dv_format_cancel_flag == 0 ou não. Se sim, então o controle é passado para uma etapa 1935. Caso contrário, o controle é passado para uma etapa 1920. Na etapa 1920, o elemento de sintaxe num_three_dv_view_minus1 é decodificado. Na etapa 1925, o elemento de sintaxe basic_three_dv_format_type_id é decodifica-do. Na etapa 1930, o elemento de sintaxe three_dv_format_repetition_period é de- codificado. Na etapa 1935, o elemento de sintaxe additional_extension_flag é deco-dificado.Concretização 3: SEI de formato 3DV para SVC

[084] Como outra extensão ao AVC, o SVC suporta uma estrutura de codificação em camadas de modo a oferecer escalabilidade nos domínios temporal, espacial ou de qualidade. Nesta concretização, propomos uma mensagem SEI de formato 3DV para SVC para sinalizar o formato 3DV, como mostra a TABELA 8. Uma das vantagens do uso do SVC é que a predição entre camadas pode ser explorada para remover a redundância entre componentes, por exemplo, a redundância entre o movimento no vídeo e o movimento no mapa de profundidade.

video_present_flag[3dv_view_id] indica se o componente de vídeo 2D está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de vista 2D. Um valor igual a 0 indica a ausência do componente de vista 2D.video_dependency_id[3dv_view_id], video_quality_id[3dv_view_id] e vi- deo_temporal_id[3dv_view_id] indicam, respectivamente, o dependency_id, qua- lity_id, e temporal_id da sequência de componentes de vista 2D a partir de uma vista 3DV com um 3dv_view_id especificado. As respectivas definições de dependen- cy_id, quality_id e temporal_id são especificadas no H. 264 Anexo G.depth_present_flag[3dv_view_id] indica se o componente de mapa de pro-fundidade está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de mapa de profundidade. Um valor igual a 0 indica a ausência do componente de mapa de profundidade.depth_dependency_id[3dv_view_id], depth_quality_id[3dv_view_id] e de- pth_temporal_id[3dv_view_id] indicam, respectivamente, o dependency_id, qua- lity_id, e temporal_id da sequência de componentes de vista 3DV com um 3dv_view_id especificado. As respectivas definições de dependency_id, quality_id e temporal_id são especificadas no H. 264 Anexo G.occlusion_video_presente_flag[3dv_view_id] indica se o componente de vídeo de oclusão está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de vídeo de oclusão. Um valor igual a 0 indica a ausência do componente de vídeo de oclusão.occlusion_video_dependency_id[3dv_view_id], occlusi-on_video_quality_id[3dv_view_id] e occlusion_video_temporal_id[3dv_view_id] indicam, respectivamente, o dependency_id, quality_id, e temporal_id da sequência de componentes de vista de oclusão de uma vista 3DV com um 3dv_view_id especificado. As respectivas definições de dependency_id, quality_id e temporal_id são especificadas no H. 264 Anexo G.occlusion_depth_present_flag[3dv_view_id] indica se o componente de profundidade de oclusão está presente para a vista 3D atual. Um valor igual a 1 indica a presença do componente de profundidade de oclusão. Um valor igual a 0 indica a ausência do componente de profundidade de oclusão.occlusion_dependency_dependency_id[3dv_view_id], occlusi-on_depth_quality_id[3dv_view_id] e occlusion_depth_temporal_id[3dv_view_id] indicam, respectivamente, o dependency_id, quality_id, e temporal_id da sequência de componentes de mapa de profundidade de oclusão a partir de uma vista 3DV com um 3dv_view_id especificado. As respectivas definições de dependency_id, qua- lity_id e temporal_id são especificadas no H. 264 Anexo G.

[085] Deve-se apreciar que todos os três exemplos (relativos à Figura 8 à Figura 10) listados na Concretização 1 podem ser mapeados para a estrutura SVC. Por exemplo, o formato LDV pode ser implementado em SVC na Figura 18, que corres-ponde à Figura 9, na Concretização 1. Os numerais L3, L2, L1 e L0 respectivamente ilustrados nas caixas 2005, 2010, 2015 e 2020 representam o dependency_id cor-respondente para esta caixa. À esquerda das caixas são a indicação do papel no contexto do 3DV. A seta aponta de uma camada de referência para uma camada a ser predita. A caixa 2020 indica o vídeo 2D. A caixa 2015 indica a profundidade cor-respondente. A caixa 2010 indica o vídeo de oclusão correspondente. A caixa 2005 indica a profundidade de oclusão correspondente.

[086] A TABELA 9 mostra um exemplo de uma mensagem SEI de formato 3DV para SVC, de acordo com uma concretização dos presentes princípios.

[087] A Figura 19 é um diagrama de fluxo de dados que mostra um método exem- plificativo 2100 para codificação de formatos 3DV, de acordo com uma concretização dos presentes princípios. A Figura 19 está direcionada à Concretização 3. Na etapa 2105, o elemento de sintaxe three_dv_format_id é codificado. Na etapa 2110, o elemento de sintaxe three_dv_format_cancel_flag é codificado. Na etapa 2115, determina-se se three_dv_format_cancel_flag == 0 ou não. Se sim, então o controle é passado para uma etapa 2185. Caso contrário, o controle é passado para uma etapa 2120. Na etapa 2120, o elemento de sintaxe num_three_dv_view_minus1 é codificado. Na etapa 2125, o elemento de sintaxe basic_three_dv_format_type_id é codificado. Na etapa 2130, inicia-se um loop para 3dv_view_id = 0, 3DV_view_id <= num_three_dv_view_minus1 e 3dv_view_id++. Na etapa 2135, o elemento de sintaxe video_present_flag[3dv_view_id] é codificado se 3dv_view_id!= 0; senão, supõe- se que o elemento de sintaxe 3dv_view_id seja igual a 1. Na etapa 2140, os elementos de sintaxe video_dependency_id[3dv_view_id], video_quality_id[3dv_view_id] e video_temporal_id[3dv_view_id] são codificados se video_present_flag[3dv_view_id] ==1. Na etapa 2145, o elemento de sintaxe depth_present_flag[3dv_view_id] é codificado. Na etapa 2150, os elementos de sintaxe video_dependency_id[3dv_view_id], depth_quality_id[3dv_view_id] e depth_temporal_id[3dv_view_id] são codificados se depth_present_flag[3dv_view_id] ==1. Na etapa 2155, o elemento de sintaxe occlu- sion_video_present_flag[3dv_view_id] é codificado se ba- sic_three_dv_format_type_id ==1; caso contrário, presume-se que o elemento de sintaxe basic_three_dv_format_type_id seja igual a 0. Na etapa 2160, os elementos de sintaxe occlusion_video_dependency_id[3dv_view_id], occlusi- on_video_quality_id[3dv_view_id], e occlusion_video_temporal_id[3dv_view_id] são codificados se occlusion_video_present_flag[3dv_view_id] ==1. Na etapa 2165, o elemento de sintaxe occlusion_depth_present_flag[3dv_view_id] é codificado se ba- sic_three_dv_format_type_id ==1; senão, supõe-se que o elemento de sintaxe oc- clusion_depth_present_flag[3dv_view_id] seja igual a 0. Na etapa 2170, os ele-mentos de sintaxe occlusion_depth_dependency_id[3dv_view_id], occlu- sion_depth_quality_id[3dv_view_id], e occlusion_depth_temporal_id[3dv_view_id] são codificados se occlusion_depth_present_flag[3dv_view_id] ==1. Na etapa 2175, termina-se o loop para 3dv_view_id = 0, 3dv_view_id <=num_three_dv_view_minus1 e 3dv_view_id++. Na etapa 2180, o elemento de sinta-xe three_dv_format_repetition é codificado. Na etapa 2185, o elemento de sintaxe additional_extension_flag é codificado.

[088] A Figura 20 é um diagrama de fluxo de dados que mostra um método exemplificativo 2200 para decodificação de formatos 3DV, de acordo com uma con-cretização dos presentes princípios. A Figura 20 está direcionada à Concretização 3. Na etapa 2205, o elemento de sintaxe three_dv_format_id é codificado. Na etapa 2210, o elemento de sintaxe three_dv_format_cancel_flag é decodificado. Na etapa 2215, determina-se se three_dv_format_cancel_flag == 0 ou não. Se sim, então o controle é passado para uma etapa 2285. Caso contrário, o controle é passado para uma etapa 2120. Na etapa 2220, o elemento de sintaxe num_three_dv_view_minus1 é decodificado. Na etapa 2225, o elemento de sintaxe ba- sic_three_dv_format_type_id é decodificado. Na etapa 2230, inicia-se um loop para 3dv_view_id = 0, 3DV_view_id <= num_three_dv_view_minus1 e 3dv_view_id++. Na etapa 2235, o elemento de sintaxe video_present_flag[3dv_view_id] é decodificado se 3dv_view_id! = 0; senão, supõe-se que o elemento de sintaxe 3dv_view_id seja igual a 1. Na etapa 2240, os elementos de sintaxe vi- deo_dependency_id[3dv_view_id], video_quality_id[3dv_view_id] e vi- deo_temporal_id[3dv_view_id] são decodificados se vi- deo_present_flag[3dv_view_id] ==1. Na etapa 2245, o elemento de sintaxe de- pth_present_flag[3dv_view_id] é decodificado. Na etapa 2250, os elementos de sin-taxe video_dependency_id[3dv_view_id], depth_quality_id[3dv_view_id] e de- pth_temporal_id[3dv_view_id] são decodificados se depth_present_flag[3dv_view_id] ==1. Na etapa 2255, o elemento de sintaxe occlusi- on_video_present_flag[3dv_view_id] é decodificado se ba- sic_three_dv_format_type_id ==1; caso contrário, presume-se que o elemento de sintaxe basic_three_dv_format_type_id seja igual a 0. Na etapa 2260, os elementos de sintaxe occlusion_video_dependency_id[3dv_view_id], occlusi- on_video_quality_id[3dv_view_id], e occlusion_video_temporal_id[3dv_view_id] são decodificados se occlusion_video_present_flag[3dv_view_id] ==1. Na etapa 2265, o elemento de sintaxe occlusion_depth_present_flag[3dv_view_id] é decodificado se basic_three_dv_format_type_id ==1; senão, supõe-se que o elemento de sintaxe occlusion_depth_present_flag[3dv_view_id] seja igual a 0. Na etapa 2270, os elementos de sintaxe occlusion_depth_dependency_id[3dv_view_id], occlu- sion_depth_quality_id[3dv_view_id], e occlusion_depth_temporal_id[3dv_view_id] são decodificados se occlusion_depth_present_flag[3dv_view_id] ==1. Na etapa 2275, termina-se o loop para 3dv_view_id = 0, 3dv_view_id <==num_three_dv_view_minus1 e 3dv_view_id++. Na etapa 2280, o elemento de sinta-xe three_dv_format_repetition_period é decodificado. Na etapa 2285, o elemento de sintaxe additional_extension_flag é decodificado. Concretização 4: SEI de formato 3DV para SVC / MVC

[089] Nas três concretizações anteriores, cada componente 3DV é tratado sepa-radamente, quer como uma vista MVC ou uma camada no SVC. Nesta concretiza-ção, propõe-se realizar uma intercalação espacial em alguns componentes 3DV pri-meiro, e, depois, tratar os componentes espaciais intercalados como uma vista no MVC ou uma camada no SVC.

[090] Pode haver muitas combinações diferentes na implementação. No caso do formato de representação MDV, um exemplo consiste em colocar o 2D e seu lado de profundidade lado a lado, e então tratar cada sequências de imagens 2D+Z como uma vista no MVC (ou uma camada no SVC). Em outro exemplo, as duas imagens 2D são dispostas primeiro lado a lado, e os dois mapas de profundidade também lado a lado. Em seguida, tratamos a sequência de imagens 2D combinada como uma vista (ou uma camada) e os mapas de profundidade combinados como outra vista (ou outra camada).

[091] Deve-se apreciar que, dados os ensinamentos dos presentes princípios aqui apresentados, os versados nesta técnica e nas técnicas relacionadas podem prontamente estender os presentes princípios ao caso LDV com várias implementações correspondentes.

[092] O entrelaçamento espacial pode ser lado a lado, de cima para baixo, em xa-drez, intercalação de linhas, intercalação de colunas, entre outros.

[093] Os métodos de sinalização das concretizações anteriores também podem ser aplicados ou adaptados a essas concretizações.

[094] A Figura 21 é um diagrama de fluxo de dados que mostra um método exem- plificativo 2300 para codificação de formatos 3DV, de acordo com uma concretização dos presentes princípios. A Figura 21 está direcionada à Concretização 4. Na etapa 2305, a intercalação espacial é realizada para alguns componentes 3DV, sendo a intercalação espacial, por exemplo, lado a lado, de cima para baixo, em xadrez, intercalação de linhas ou intercalação de colunas. Na etapa 2310, determina-se se os componentes 3DV espaciais intercalados devem ser tratados como uma vista sob o MVC. Se sim, então o controle é passado para uma etapa 2315. Caso contrário, o controle é passado para uma etapa 2320. Na etapa 2315, as "vistas" intercaladas são codificadas com um codificador MVC. Na etapa 2320, determina-se se os com-ponentes 3DV espaciais intercalados devem ser tratados como uma vista sob o SVC. Se sim, então o controle é passado para um bloco de etapas 2325. Caso con-trário, o controle é passado para uma etapa 2330. Na etapa 2325, as "camadas" in-tercaladas são codificadas com um codificador SVC. Na etapa 2330, o processo está reservado para outros codificadores.

[095] A Figura 22 é um diagrama de fluxo de dados que mostra um método exemplificativo 2400 para decodificação de formatos 3DV, de acordo com uma con-cretização dos presentes princípios. A Figura 22 está direcionada à Concretização 4. Na etapa 2405, determina-se se os componentes 3DV espaciais intercalados devem ser tratados como uma vista sob o MVC. Se sim, então o controle é passado para uma etapa 2410. Caso contrário, o controle é passado para uma etapa 2415. Na etapa 2410, as "vistas" intercaladas são decodificadas com um decodificador MVC. Na etapa 2415, determina-se se os componentes 3DV espaciais intercalados devem ser tratados como uma vista sob o SVC. Se sim, então o controle é passado para uma etapa 2420. Caso contrário, o controle é passado para uma etapa 2425. Na etapa 2420, as "camadas" intercaladas são decodificadas com um decodificador SVC. Na etapa 2425, o processo está reservado para outros decodificadores. Na etapa 2430, efetua-se a desintercalação espacial para alguns componentes 3DV. A desintercalação espacial é, por exemplo, lado a lado, de cima para baixo, em xadrez, por intercalação de linhas ou intercalação de colunas.

[096] Dessa forma, oferecemos uma ou mais implementações com características e aspectos específicos. No entanto, as características e aspectos das implementações descritas também podem ser adaptados a outras implementações.

[097] Além disso, as implementações descritas podem ser adaptadas de várias maneiras. Por exemplo, as implementações podem expandir o número de pontos de vistas 3DV e / ou o número de tipos de formato 3DV preditos na sintaxe e semântica de várias implementações descritas. Além disso, as implementações podem realizar a predição temporalmente. Por exemplo, um componente 3DV pode ser preditos a partir de uma referência no mesmo componente 3DV (como na Figura 8, por exemplo), de um componente 3DV diferente (como na V4 da Figura 10 na vista 3DV direita sendo predita a partir de V3 na vista 3DV esquerdo, por exemplo), e / ou um componente 3DV diferente ocorrendo em um ponto diferente no tempo. Por exemplo, a imagem de profundidade esquerda 1005 da Figura 8 pode ser predita a partir de uma referência que é uma imagem de profundidade esquerda de uma vista 3DV que ocorreu anteriormente.

[098] Várias das implementações e dos aspectos descritos no presente pedido podem ser usadas no contexto do Padrão H.264/MPEG-4 AVC (AVC), ou do padrão AVC com a extensão MVC, ou do padrão AVC com a extensão SVC. No entanto, estas implementações e recursos podem ser usados no contexto de outro padrão (existente ou futuro), ou em um contexto que não envolve um padrão. Dessa forma, oferecemos uma ou mais implementações com características e aspectos específi-cos. No entanto, as características e aspectos das implementações descritas tam-bém podem ser adaptados a outras implementações.

[099] As implementações podem sinalizar informações usando uma variedade de técnicas, incluindo mas não limitado a mensagens SEI, cabeçalhos de fatia, outra sintaxe de alto nível, sintaxe de nível não tão alto, informações fora de banda, dados de fluxo e sinalização implícita. Assim, embora as implementações descritas neste documento possam ser descritas em um contexto particular, tais descrições não deverão em caso algum ser interpretadas como limitações aos aspectos e conceitos para tais implementações ou contextos.

[0100] Além disso, muitas implementações podem ser implementadas em um ou mais dentre um codificador, um decodificador, uma saída de processamento pós- processador a partir de um decodificador, ou um pré-processador que fornece entrada para um codificador. Além disso, outras implementações são contempladas pela presente revelação.

[0101] Referências, no presente relatório, a “uma concretização” ou “uma imple-mentação” dos presentes princípios, assim como a outras variações destes, significam que um aspecto, estrutura ou característica em particular, e assim por diante, descrito em conexão com a concretização, está incluso em pelo menos uma concretização dos presentes princípios. Dessa forma, as ocorrências da expressão "em uma concretização" ou “em uma implementação”, bem como quaisquer outras variações, que surgem em vários trechos do relatório descritivo, não se referem necessariamente à mesma concretização.

[0102] Deve-se apreciar que o uso dos termos “/”, “e/ou” e “pelo menos um den-tre”, por exemplo, no casos de “A/B”, “A e/ou B” e “pelo menos um dentre A e B”, pretende abranger ou a seleção somente da primeira opção listada (A), ou a seleção somente da segunda opção listada (B), ou a seleção das duas opções (A e B). Como outro exemplo, nos casos de “A, B e/ou C” e “pelo menos um dentre A, B e C” e “pelo menos um dentre A, B ou C”, tais expressões pretendem abranger a seleção somente da primeira opção listada (A), ou a seleção somente da segunda opção listada (B), ou a seleção somente da terceira opção listada (C), ou a seleção somente da primeira e da segunda opções listadas (A e B), ou a seleção somente da primeira e terceira opções listadas (A e C), ou a seleção somente da segunda e terceiras opções listadas (B e C), ou a seleção de todas as três opções (A e B e C). Isto poderá ser estendido, como será imediatamente apreciado pelos versados nesta técnica e nas técnicas relacionadas, a quanto itens forem listados.

[0103] Além disso, como empregada aqui, a palavra "imagem" é usados indistin-tamente e refere-se, por exemplo, à totalidade ou parte (uma parte) de uma imagem fixa ou à totalidade ou parte (uma parte) de uma imagem a partir de uma sequência de vídeo. De modo mais geral, uma imagem se refere, por exemplo, a qualquer con-junto de dados de imagem ou vídeo. Uma imagem pode ser, por exemplo, um pixel, um macrobloco, uma fatia, um quadro, um campo, uma imagem inteira, uma região delimitando um objeto na imagem, o primeiro plano da imagem, o segundo plano da imagem, ou um conjunto específico de coordenadas (x, y) na imagem. De modo si milar, uma “parte” de uma imagem pode ser, por exemplo, um pixel, um macrobloco, uma fatia, um quadro, um campo, uma região que delimita um objeto na imagem, o primeiro plano da imagem, o segundo plano da imagem, ou um conjunto específico de coordenadas (x, y) na imagem. Como outro exemplo, uma imagem de profundidade (imagem de profundidade) pode ser, por exemplo, um mapa de profundidade completo ou um mapa de profundidade parcial que inclui apenas informações de profundidade para, por exemplo, um único macrobloco de um quadro de vídeo correspondente.

[0104] Além disso, este pedido, ou suas reivindicações, podem se referir à "de-terminação" de várias unidades de informação. O ato de determinar a informação pode incluir um ou mais dentre, por exemplo, estimar a informação, calcular a infor-mação, predizer a informação, ou recuperar a informação da memória.

[0105] Da mesma forma, "acessar" pretende ser um termo amplo. O ato de aces-sar um segmento de informação pode incluir qualquer operação que, por exemplo, use, armazene, envie, transmita, receba, recupere, modifique ou forneça a informa-ção.

[0106] As implementações descritas aqui podem ser implementadas, por exem-plo, em um método ou processo, em um aparelho, programa de software, fluxo de dados ou sinal. Mesmo se discutida apenas no contexto de uma única forma de im-plementação (por exemplo, discutida somente como um método), a implementação dos aspectos discutidos também podem ser implementada em outras formas (por exemplo, um aparelho ou um programa). Um aparelho pode ser implementado, por exemplo, em hardware, software e firmware apropriado. Os métodos podem ser im-plementados, por exemplo, em um aparelho, tal como, por exemplo, um processa-dor, que se refere aos dispositivos de processamento em geral, incluindo, por exemplo, um computador, um microprocessador, um circuito integrado ou um dispositivo de lógica programável. Os processadores também incluem dispositivos de comunicação, tal como, por exemplo, computadores, telefones celulares, assistentes digitais pessoais/portáteis (“PDAs”) e outros dispositivos que facilitam a comunicação de informações entre os usuários finais.

[0107] As implementações dos vários processos e aspectos aqui descritos podem ser concretizadas em uma variedade de equipamentos ou aplicações diferentes, particularmente, por exemplo, equipamentos ou aplicações associadas à codificação e decodificação de dados. Exemplos de tais equipamentos incluem um codificador, um descodificador, um pós-processador processando a saída de um decodificador, um pré-processador que fornece entrada a um codificador, um codificador de vídeo, um decodificador de vídeo, um codec de vídeo, um servidor da Rede, um decodificador de sinais, um laptop, um computador pessoal, um telefone celular, um PDA e outros dispositivos de comunicação. Como ficará claro, o equipamento pode ser móvel e até mesmo instalado em um veículo móvel.

[0108] Além disso, os métodos podem ser implementados por instruções execu-tadas por um processador, e tais instruções (e/ou valores de dados produzidos por uma implementação) podem ser armazenadas em um meio legível por processador, tal como, por exemplo, um circuito integrado, um meio portador de software ou outro dispositivo de armazenamento, tal como, por exemplo, um disco rígido, um disquete compacto, uma memória de acesso aleatório (“RAM”) ou uma memória somente para leitura (“ROM”). As instruções podem formar um programa aplicativo incorporado de maneira tangível em um meio legível por processador. As instruções podem ser, por exemplo, em hardware, firmware, software, ou uma combinação. As instruções podem ser encontradas, por exemplo, em um sistema operacional, em um aplicativo separado, ou uma combinação dos dois. Um processador pode ser caracterizado, portanto, como, por exemplo, tanto um dispositivo configurado para realizar um processo como um dispositivo que inclui um meio legível por processador (tal como um dispositivo de armazenamento), contendo instruções para a execução de um processo. Além disso, um meio legível por processador pode armazenar, além de ou em vez de instruções, valores de dados produzidos por uma implementação.

[0109] Como ficará evidente aos versados na técnica, as implementações tam-bém podem produzir uma variedade de sinais formatados para transmitir informa- ções que podem, por exemplo, ser armazenadas ou transmitidas. As informações podem incluir, por exemplo, instruções para realizar um método, ou dados produzi-dos por uma das implementações descritas. Por exemplo, um sinal pode ser forma-tado para transportar como dados as regras para escrita ou leitura da sintaxe de uma concretização descrita, ou para transportar os dados como os valores de sintaxe reais escritos por uma concretização descrita. Tal sinal pode ser formatado, por exemplo, como uma onda eletromagnética (por exemplo, usando uma parte de radiofrequência do espectro) ou como um sinal de banda básica. A formatação pode incluir, por exemplo, a codificação de um fluxo de dados e a modulação de uma portadora com o fluxo de dados codificado. A informação que o sinal transmite pode ser, por exemplo, informação analógica ou digital. O sinal pode ser transmitido por uma variedade de links com ou sem fio diferentes, como de praxe. O sinal pode ser armazenado em um meio legível por processador.

[0110] Diversas concretizações foram descritas. Contudo, deve-se compreender que várias modificações são possíveis. Por exemplo, os elementos das diferentes implementações podem ser combinados, complementados, modificados ou removidos para produzir outras implementações. Além disso, as operações podem ser in- tercambiadas entre os blocos funcionais. Além disso, os especialistas da área entenderão que outras estruturas e processos podem substituir estes revelados e que as implementações resultantes desempenharão pelo menos essencialmente a(s) mesma(s) função(ões), pelo menos substancialmente da mesma forma, para atingir pelo menos basicamente o(s) mesmo(s) resultado(s) das implementações reveladas. Sendo assim, estas e outras implementações são contempladas pelo presente pedido e estão dentro do escopo das reivindicações a seguir.

[0111] Da mesma forma, deve-se apreciar que, na descrição acima das imple-mentações, vários aspectos são algumas vezes agrupados em uma única implementação, figura, ou descrição com o objetivo de dinamizar a revelação e auxiliar na compreensão de um ou mais dos vários aspectos. Esse método de revelação, no entanto, não deve ser interpretado como refletindo a intenção de que a invenção rei- vindicada exige mais aspectos do que os expressamente mencionados em cada reivindicação. Em vez disso, como refletem as reivindicações seguintes, os aspectos inventivos podem resistir em menos do que todos os aspectos de uma única concretização revelada. Sendo assim, entende-se que cada uma das reivindicações também constitui uma implementação separada.

Claims

1. Método (1300, 2300) compreendendo:codificar (2315, 2325, 2330) todos os componentes de vídeo 3D de um formato de vídeo 3D em um fluxo de bits estruturado com base em vista ou camada, todas as camadas ou vistas do referido fluxo de bits sendo codificadas em conjunto usando codificação de múltiplas vistas ou codificação de vídeo escalonável, cada um dos componentes de vídeo 3D sendo atribuídos a uma vista ou uma camada, uma ou mais vistas ou camadas sendo capazes de ser usadas como uma referência para pelo menos uma outra vista ou camada para explorar a redundância entre elas;dispor (2305) conjuntos de componentes de vídeo 3D codificados no fluxo de bits estruturado com base em vista ou camada em uma primeira ordem com base no formato de vídeo 3D; ecodificar (1305) informações de sinalização do fluxo de bits estruturado com base em vista ou camada, as informações de sinalização indicando a primeira ordem com base no formato de vídeo 3D;CARACTERIZADO pelo fato de que as informações de sinalização compreendem um primeiro elemento de sintaxe indicando que o formato de vídeo 3D inclui:- vídeo 2D e componentes de profundidade correspondentes; ou- vídeo 2D e componentes de profundidade correspondentes, componente de vídeo de oclusão 2D correspondente e componente de vídeo de oclusão de profundidade correspondente.

2. Método de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente:um segundo elemento de sintaxe que indica se um primeiro componente de vídeo 3D do conjunto de componentes de vídeo 3D está presente no fluxo de bits estruturado com base em vista ou camada; eum terceiro elemento de sintaxe que indica uma primeira vista ou camada no fluxo de bits que corresponde ao primeiro componente de vídeo 3D de um conjunto de componentes de vídeo 3D que está presente no fluxo de bits estruturado com base em vista ou camada.

3. Método de acordo com a reivindicação 2, CARACTERIZADO pelo fato de que o primeiro componente de vídeo 3D é um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, um componente de profundidade correspondente a um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, componente de vídeo de oclusão 2D de um conjunto de componentes de vídeo 2D ou um componente de vídeo de oclusão de profundidade correspondente a um componente de vídeo de oclusão de um conjunto de componentes de vídeo 3D.

4. Método de acordo com a reivindicação 1 ou 2, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente um quarto elemento de sintaxe que indica se a persistência das indicações fornecidas pelos primeiro, segundo e/ou terceiro elementos de sintaxe está cancelada.

5. Aparelho (300) compreendendo meios para:codificar (305) todos os componentes de vídeo 3D de um formato de vídeo 3D em um fluxo de bits estruturado com base em vista ou camada, todas as camadas ou vistas do fluxo de bits sendo codificadas em conjunto usando codificação de múltiplas vistas ou codificação de vídeo escalonável, cada um dos componentes de vídeo 3D sendo atribuídos a uma vista ou uma camada, uma ou mais vistas ou camadas sendo capazes de ser usadas como uma referência para pelo menos uma outra vista ou camada para explorar a redundância entre elas;dispor (360) conjuntos de componentes de vídeo 3D codificados no fluxo de bits estruturado com base em vista ou camada em uma primeira ordem com base no formato de vídeo 3D; ecodificar (365) informações de sinalização do fluxo de bits estruturado com base em vista ou camada, as informações de sinalização indicando a primeira ordem;CARACTERIZADO pelo fato de que as informações de sinalização compreendem um primeiro elemento de sintaxe indicando que o formato de vídeo 3D inclui:- vídeo 2D e componentes de profundidade correspondentes; ou - vídeo 2D e componentes de profundidade correspondentes, componente de vídeo de oclusão 2D correspondente e componente de vídeo de oclusão de profundidade correspondente.

6. Aparelho de acordo com a reivindicação 5, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente:um segundo elemento de sintaxe que indica se um primeiro componente de vídeo 3D do conjunto de componentes de vídeo 3D está presente no fluxo de bits estruturado com base em vista ou camada; eum terceiro elemento de sintaxe que indica uma primeira vista ou camada no fluxo de bits que corresponde ao primeiro componente de vídeo 3D de um conjunto de componentes de vídeo 3D que está presente no fluxo de bits estruturado com base em vista ou camada.

7. Aparelho de acordo com a reivindicação 6, CARACTERIZADO pelo fato de que o primeiro componente de vídeo 3D é um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, um componente de profundidade correspondente a um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, componente de vídeo de oclusão 2D de um conjunto de componentes de vídeo 2D ou um componente de vídeo de oclusão de profundidade correspondente a um componente de vídeo de oclusão de um conjunto de componentes de vídeo 3D.

8. Aparelho de acordo com a reivindicação 5 ou 6, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente um quarto elemento de sintaxe que indica se a persistência das indicações fornecidas pelos primeiro, segundo e/ou terceiro elementos de sintaxe está cancelada.

9. Método (1400, 2400) compreendendo:acessar (460) um fluxo de bits estruturado com base em vista ou camada que inclui todos os componentes de vídeo 3D de um formato de vídeo 3D, todas as camadas ou vistas do fluxo de bits sendo codificadas em conjunto usando codificação de múltiplas vistas ou codificação de vídeo escalonável, cada um dos componentes de vídeo 3D sendo atribuídos a uma vista ou uma camada, uma ou mais vis tas ou camadas sendo capazes de ser usadas como uma referência para pelo menos uma outra vista ou camada para explorar a redundância entre elas,acessar (465, 1405) informações de sinalização do fluxo de bits estruturado com base em vista ou camada, as informações de sinalização indicando uma primeira ordem na qual conjuntos de componentes de vídeo 3D codificados são dispostos no fluxo de bits, a primeira ordem sendo baseada no formato de vídeo 3D, edecodificar (405, 2410, 2420, 2425) conjuntos de componentes de vídeo 3D codificados usando as informações de sinalização,CARACTERIZADO pelo fato de que as informações de sinalização compreendem um primeiro elemento de sintaxe indicando que o formato de vídeo 3D inclui:- vídeo 2D e componentes de profundidade correspondentes; ou- vídeo 2D e componentes de profundidade correspondentes, componente de vídeo de oclusão 2D correspondente e componente de vídeo de oclusão de profundidade correspondente.

10. Método de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente:um segundo elemento de sintaxe que indica se um primeiro componente de vídeo 3D do conjunto de componentes de vídeo 3D está presente no fluxo de bits estruturado com base em vista ou camada; eum terceiro elemento de sintaxe que indica uma primeira vista ou camada no fluxo de bits estruturado com base em vista ou camada que corresponde ao primeiro componente de vídeo 3D de um conjunto de componentes de vídeo 3D que está presente no fluxo de bits estruturado com base em vista ou camada.

11. Método de acordo com a reivindicação 10, CARACTERIZADO pelo fato de que o primeiro componente de vídeo 3D é um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, um componente de profundidade correspondente a um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, componente de vídeo de oclusão 2D de um conjunto de componentes de vídeo 2D ou um componente de vídeo de oclusão de profundidade correspondente a um com- ponente de vídeo de oclusão de um conjunto de componentes de vídeo 3D.

12. Método de acordo com a reivindicação 9 ou 10, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente um quarto elemento de sintaxe que indica se a persistência das indicações fornecidas pelos primeiro, segundo e/ou terceiro elementos de sintaxe está cancelada.

13. Método de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que as informações de sinalização são incluídas em uma mensagem SEI.

14. Método de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que o fluxo de bits estruturado com base em vista ou camada é compatível com uma extensão de codificação de vídeo múltiplas vistas ou uma extensão de codificação de vídeo escalonável da Organização Internacional de Normalização/Comissão Eletrotécnica Internacional de Padrão de Codificação de Vídeo Avançada Parte 10 do Moving Picture Experts Group-4 do Telecommunication Union stan- dard/International, à Recomendação H.264 do setor de telecomunicações.

15. Aparelho (400) compreendendo meios para:acessar (460) um fluxo de bits estruturado com base em vista ou camada que inclui todos os componentes de vídeo 3D de um formato de vídeo 3D, todas as camadas ou vistas do fluxo de bits sendo codificadas em conjunto usando codificação de múltiplas vistas ou codificação de vídeo escalonável, cada um dos componentes de vídeo 3D sendo atribuídos a uma vista ou uma camada, uma ou mais vistas ou camadas sendo capazes de ser usadas como uma referência para pelo menos uma outra vista ou camada para explorar a redundância entre elas,acessar (465) informações de sinalização do fluxo de bits estruturado com base em vista ou camada, as informações de sinalização indicando uma primeira ordem na qual conjuntos de componentes de vídeo 3D são dispostos no fluxo de bits, a primeira ordem sendo baseada no formato de vídeo 3D, edecodificar (405) os conjuntos de componentes de vídeo 3D codificados usando as informações de sinalização,CARACTERIZADO pelo fato de que as informações de sinalização compre- endem um primeiro elemento de sintaxe indicando que o formato de vídeo 3D inclui:- vídeo 2D e componentes de profundidade correspondentes; ou- vídeo 2D e componentes de profundidade correspondentes, componente de vídeo de oclusão 2D correspondente e componente de vídeo de oclusão de profundidade correspondente.

16. Aparelho de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente:um segundo elemento de sintaxe que indica se um primeiro componente de vídeo 3D do conjunto de componentes de vídeo 3D está presente no fluxo de bits estruturado com base em vista ou camada; eum terceiro elemento de sintaxe que indica uma primeira vista ou camada no fluxo de bits estruturado com base em vista ou camada que corresponde ao primeiro componente de vídeo 3D de um conjunto de componentes de vídeo 3D que está presente no fluxo de bits estruturado com base em vista ou camada.

17. Aparelho de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que o primeiro componente de vídeo 3D é um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, um componente de profundidade correspondente a um componente de vídeo 2D de um conjunto de componentes de vídeo 3D, componente de vídeo de oclusão 2D de um conjunto de componentes de vídeo 2D ou um componente de vídeo de oclusão de profundidade correspondente a um componente de vídeo de oclusão de um conjunto de componentes de vídeo 3D.

18. Aparelho de acordo com a reivindicação 15 ou 16, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente um quarto elemento de sintaxe que indica se a persistência das indicações fornecidas pelos primeiro, segundo e/ou terceiro elementos de sintaxe está cancelada.

19. Aparelho de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que as informações de sinalização são incluídas em uma mensagem SEI.

20. Aparelho de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que o fluxo de bits estruturado com base em vista ou camada é compatível com uma extensão de codificação de vídeo múltiplas vistas ou uma extensão de codificação de vídeo escalonável da Organização Internacional de Normaliza- ção/Comissão Eletrotécnica Internacional de Padrão de Codificação de Vídeo Avançada Parte 10 do Moving Picture Experts Group-4 do Telecommunication Union standard/International, à Recomendação H.264 do setor de telecomunicações.

21. Mídia legível por processador CARACTERIZADO pelo fato de que tem armazenado nela um conjunto de instruções para fazer com que um processador execute pelo menos um dentre os métodos conforme definido nas reivindicações 1-4 e 9-14.

22. Sinal de vídeo formatado para incluir informações, o sinal de vídeo compreendendo uma seção de sinalização que inclui informações de sinalização indicando uma primeira ordem na qual conjuntos de componentes de vídeo 3D codificados são dispostos, o sinal de vídeo compreendendo todos os componentes 3D de um formato de vídeo 3D em um fluxo de bits estruturado com base em vista ou camadas, todas as camadas ou vistas do fluxo de bits sendo codificadas em conjunto usando codificação de múltiplas vistas ou codificação de vídeo escalonável, cada um dos componentes de vídeo 3D sendo atribuídos a uma vista ou uma camada, uma ou mais vistas ou camadas sendo capazes de ser usado como uma referência para pelo menos uma outra vista ou camada para explorar a redundância entre elas, CARACTERIZADO pelo fato de que as informações de sinalização compreender um primeiro elemento de sintaxe (1305) indicando se o formato de vídeo 3D inclui:- vídeo 2D e componentes de profundidade correspondentes; ou- vídeo 2D e componentes de profundidade correspondentes, componente de vídeo de oclusão 2D correspondente e componente de vídeo de oclusão de profundidade correspondente.

23. Sinal de vídeo, de acordo com a reivindicação 22, CARACTERIZADO pelo fato de que o sinal de vídeo compreende adicionalmente:um segundo elemento de sintaxe que indica se um primeiro componente de vídeo 3D do conjunto de componentes de vídeo 3D está presente no fluxo de bits estruturado com base em vista ou camada; eum terceiro elemento de sintaxe que indica a primeira vista ou camada no fluxo de bits que corresponde ao primeiro componente de vídeo 3D de um conjunto de componentes de vídeo 3D que está presente no fluxo de bits estruturado com base em vista ou camada.

24. Sinal de vídeo, de acordo com a reivindicação 22, CARACTERIZADO pelo fato de que o primeiro componente de vídeo 3D é um vídeo 2D de um conjunto de componentes de vídeo 3D, um componente de profundidade correspondente a um vídeo 2D de um conjunto de componentes de vídeo 3D, componente de vídeo de oclusão 2D de um conjunto de componentes de vídeo 2D ou um componente vídeo de oclusão de profundidade correspondente a um componente de vídeo de oclusão de um conjunto de componentes de vídeo 3D.

25. Sinal de vídeo, de acordo com a reivindicação 22, CARACTERIZADO pelo fato de que as informações de sinalização compreendem adicionalmente um quarto elemento de sintaxe que indica se a persistência das indicações fornecidas pelos primeiro, segundo e/ou terceiro elementos de sintaxe está cancelada.

26. Mídia legível por processador tendo armazenado nela uma estrutura de sinal de vídeo, o sinal de vídeo compreendendo uma seção de sinalização incluindo informações de sinalização indicando uma primeira ordem na qual conjuntos de componentes de vídeo 3D codificados são dispostos, o sinal de vídeo compreendendo todos os componentes 3D de um formato de vídeo 3D em um fluxo de bits estruturado com base em vista ou camada, todas as camadas ou vistas do fluxo de bits sendo codificadas em conjunto usando codificação de múltiplas vistas ou codificação de vídeo escalonável, cada um dos componentes de vídeo 3D sendo atribuídos a uma vista ou uma camada, uma ou mais vistas ou camadas sendo capazes de serem usadas como uma referência para pelo menos uma outra vista ou camada para explorar a redundância entre elas, CARACTERIZADA pelo fato de que as informações de sinalização compreendem um primeiro elemento de sintaxe (1305) indicando que o formato de vídeo 3D inclui: - vídeo 2D e componentes de profundidade correspondentes; ou- vídeo 2D e componentes de profundidade correspondentes, componente de vídeo de oclusão 2D correspondente e componente de vídeo de oclusão de profundidade correspondente.

27. Mídia legível por processador, de acordo com a reivindicação 26, CARACTERIZADA pelo fato de que o sinal de vídeo compreende adicionalmente:um segundo elemento de sintaxe que indica se um primeiro componente de vídeo 3D do conjunto de componentes de vídeo 3D está presente no fluxo de bits estruturado com base em vista ou camada; eum terceiro elemento de sintaxe que indica a primeira vista ou camada no fluxo de bits que corresponde ao primeiro componente de vídeo 3D de um conjunto de componentes de vídeo 3D que está presente no fluxo de bits estruturado com base em vista ou camada.

28. Mídia legível por processador, de acordo com a reivindicação 27, CARACTERIZADA pelo fato de que o primeiro componente de vídeo 3D é um vídeo 2D de um conjunto de componentes de vídeo 3D, um componente de profundidade correspondente a um vídeo 2D de um conjunto de componentes de vídeo 3D, componente de vídeo de oclusão 2D de um conjunto de componentes de vídeo 2D ou um componente vídeo de oclusão de profundidade correspondente a um componente de vídeo de oclusão de um conjunto de componentes de vídeo 3D.

29. Mídia legível por processador, de acordo com a reivindicação 27, CARACTERIZADA pelo fato de que as informações de sinalização compreendem adicionalmente um quarto elemento de sintaxe que indica se a persistência das indicações fornecidas pelos primeiro, segundo e/ou terceiro elementos de sintaxe está cancelada.