BRPI0718206A2

BRPI0718206A2 - Método para codificar um pluralidade de visões de uma cena; método de decodificação de uma sequência de bits de vídeo codificada; aparelho; método de decodificação de uma sequência de bits de vídeo codificada; produto de programa de um computador contido em uma mídia legível por computador para a decodificação de uma sequência de bits de um vídeo codificada.

Info

Publication number: BRPI0718206A2
Application number: BRPI0718206-6A
Authority: BR
Inventors: Ying Chen; Ye-Kui Wang; Miska Hannuksela
Original assignee: Nokia Corp
Priority date: 2006-10-16
Filing date: 2007-10-15
Publication date: 2013-11-12
Also published as: TWI396451B; CN104093031B; AU2007311476C1; WO2008047303A2; EP3379834A2; AU2007311476B2; EP2087741B1; US8396121B2; EP2642756B1; US8165216B2; TWI488507B; ES2702704T3; US20080117985A1; EP3379834A3; KR101120648B1; CN101548550B; KR20090079932A; EP2642756A3; EP2642756A2; MX337935B

Description

“MÉTODO PARA CODIFICAR UMA PLURALIDADE DE VISÕES DE UMA CENA; MÉTODO DE DECODIFICAÇÃO DE UMA SEQÜÊNCIA DE BITS DE VÍDEO CODIFICADA; APARELHO; MÉTODO DE DECODIFICAÇÃO DE UMA SEQÜÊNCIA DE BITS DE VÍDEO CODIFICADA; PRODUTO DE 5 PROGRAMA DE COMPUTADOR CONTIDO EM UMA MÍDIA LEGÍVE L POR COMPUTADOR PARA A DECODIFICAÇÃO DE UMA SEQÜÊNCIA DE BITS DE VÍDEO CODIFICADA”.

CAMPO DA INVENÇÃO A presente invenção refere-se à codificação de vídeo em geral. Mais especificamente, a presente invenção se refere ao gerenciamento de memória temporári a de imagem codificada em codificação de vídeo de multivisão.

FUNDAMENTOS DA INVENÇÃO Esta seção tem por objetivo proporcionar os fundamentos ou contexto para a invenção relacionada nas reivindicações. A descrição aqui contida pode incluir 15 conceitos a serem possivelmente seguidos, mas não são necessariamente aqueles que foram previamente concebidos ou buscados. Desta forma, salvo indicação de forma diferente aqui contida, o que é descrito nesta seção não é conhecimento anterior a esta descrição e reivindicações nesta requisição e não é admitido ser conhecimento anterior pela sua inclusão nesta seção.

Em codificação de vídeo de multivisão, seqüências de saídas de vídeo

provenientes de várias câmeras, cada uma correspondendo a diferentes visões de uma cena, é codificada dentro de um fluxo de bits. Apósa decodificação, para exibir uma certa visão, a imagem codificada pertencente a aquela visão é reconstruída e exibida.

A codificação de vídeo multivisão possui uma grande variedade de 25 aplicações, televisão/vídeo com ponto de vista livre, TV tri-dimensional e aplicações de vigilâ ncia. Atualmente o Joint Video Team (JVT) da International Standardization Organization (ISO), Motion Picture Experts Group (MPEG) do International Engineering Consortium (IEC) e o T-Video Coding Expert Group da International Telecommunication Union (ITU) estão trabalhando para desenvolver um padrão de codificação de vídeo 30 multivisão (MVC), o qual está se tornando uma extensão do padrão ITU-T H.264, também conhecido como ISO/IEC MPEG-4 Part-10. Estes esboços de padrões serão referenciados daqui em diante como MVC e AVC, respectivamente. O último esboço do padrão MVC é descrito no JVT-T208, “Joint Multiview Video Model (JMVM) 1.0”, do 20° congresso JVT, ocorrido em julho de 2006 em Klagenfurt na Áustria, e pode ser 5 encontrado em ftp3.itu.ch/av-arch/jvt-site/2006_07Klagenfurt/JVT-T208.zip, e é incorporado daqui em diante integralmente neste documento como referência.

No JMVM 1.0, para cada grupo de imagens (GOP), as imagens de qualquer visão são contíguas na ordem de decodificação. Isto é representado na figura 1, onde a direção horizontal denota tempo (sendo cada instante de tempo representado por TM) e a 10 direção vertical denota visão (sendo cada visão representada por Sn). As imagens de cada visão são agrupadas dentro dos GOPs, por exemplo, as imagens Tl a T8 na figura 1 para cada visão formam um GOP. Esta disposição na ordem de decodificação é referenciada como codificação com prioridade na visão. Pode ser observado que, para as imagens dentro de uma visão e dentro de um GOP, embora sua ordem de decodificação seja 15 contínua sem nenhuma outra imagem inserida entre quaisquer duas imagens, internamente a ordem de decodificação pode mudar.

Também é possível obter uma ordem de decodificação diferente daquela apresentada como codificação com prioridade em visão. Por exemplo, as imagens podem ser dispostas de forma que as imagens de qualquer locação temporal sejam contíguas na 20 ordem de decodificação. Esta disposição é apresentada na figura 2. Esta disposição na ordem de decodificação é referenciada como codificação com prioridade no tempo. Também pode ser notado que a ordem de decodificação das unidades de acesso pode não ser idêntica à ordem te mporal.

Uma típica estrutura de predição (incluindo ambas as predições: predição 25 inter imagem dentro de cada visão e predição inter visão) para codificação de vídeo multivisão é apresentada na figura 2, onde as predições são indicadas por setas, e os objetos apontados usam os objetos dos quais são apontados para referência de predição. A predição inter imagem dentro de uma visão também é referenciada como predição temporal, predição intravisão, ou, simplesmente, predição inter. Uma imagem de Atualização Instantânea de Decodificação (IDR) é uma imagem de codificação do tipo intra que faz com que o processo de decodificação marque todas as imagens de referência como “não usada para referência” imediatamente após decodificar a imagem IDR. Após a decodificação de uma imagem IDR, todas as imagens codificadas seguintes na ordem de decodificação podem ser decodificados sem o uso de predição inter a partir de qualquer imagem decodificada anterior à imagem IDR. No AVC e MVC, parâmet ros que se mantêm inalterados ao longo de uma seqüência de vídeo codificada são incluídos em um conjunto de parâmetro s da seqüência. Adicionalmente aos parâmetros que são essenciais ao processo de decodificação, o conjunto de parâmetr os da seqüência pode opcionalmente conter Informação de Usabilidade do Vídeo (VUI), o qual inclui parâmetros que são importantes para definição de memória temporária, temporização de saída de imagens, renderização e alocação de recursos. São especificadas duas estruturas para portar os conjuntos de parâmetros da seqüência: a unidade NAL de conjunto de parâmetros de seqüência que contém todos os dados para as imagens AVC na seqüência e a extensão do conjunto de parâmetros da seqüência para o MVC. Um conjunto de parâmetros da seqüência contém aqueles parâmetros os quais se espera manterem-se inalterados em algumas imagens codificadas. Os dados no nível de imagem que mudam frequentemente são repetidos nos cabeçalhos de cada fatia, e os conjuntos de parâ metros de imagens portam os parâmetros do nível de imagem remanescentes. A sintaxe H.264/AVC permite muitas instâncias de seqüências e conjuntos de parâmetros de imagem, e cada instância é identificada com um identificador único. Cada cabeçalho de fatia inclui o identificador o identificador do conjunto de parâmetros da imagem que está ativa para a decodificação da imagem que contém a fatia, e cada conjunto de parâmetros da imagem contém o identificador do conjunto de parâmetros da seqüência ativo. Consequentemente, a transmissão dos conjuntos de parâmetros da seqüência e de imagem não precisam estar sincronizados precisamente com a transmissão de fatias, em vez disso, é suficiente que o conjunto de parâmetros da seqüência e da imagem ativos sejam recebidos em qualquer momento antes de serem referenciados, o que permite que os conjuntos de parâmet ros utilizem um protocolo de transmissão mais confiável do que os protocolos utilizados na transmissão dos dados de fatia. Por exemplo, conjuntos de parâmetros podem ser incluídos como um parâmetro MIME na descrição da sessão para as sessões de Protocolo de Tempo Real (RTP) H.264/AVC. Recomenda-se a utilização de um mecanismo confiável de transmissão fora da banda, sempre que possível na aplicação em uso. Se os conjuntos de 5 parâmetros forem transmitidos dentro da banda, eles podem ser repetidos como forma de aumentar sua resistência contra erros.

Tal como tratado neste documento, uma imagem âncora é uma imagem codificada na qual todas as fatias referenciam apenas fatias com o mesmo índice temporal, por exemplo, apenas fatias em outras visões e não fatias em imagens anteriores da visão 10 corrente. Uma imagem âncora é sinalizada ao se inserir o valor 1 no campo anchor_pic_flag. Após a decodificação de uma imagem âncora , todas as imagens subsequentes na ordem de exibição são capazes de ser codificados sem o uso de predição inter a partir de qualquer imagem decodificada antes da imagem âncora. Se uma imagem em uma visão é uma imagem âncora então todas as imagens com o mesmo índice 15 temporal em outras visões também são imagens âncoras. Por conseqüência, a decodificação de qualquer visão pode ser iniciada a partir de um índice temporal que corresponde às imagens âncoras.

A temporização de saída de imagens, tal como a estampa da hora de saída, não são incluídas na parte integral dos fluxos de bits AVC ou MVC. Embora, um valor 20 de contador de ordem de imagem (POC) seja atribuído para cada imagem e seja não decrescente com a posição crescente da imagem na ordem de saída relativa à imagem IDR prévia ou a uma imagem contendo uma operação de controle de gerenciamento de memória marcando todas as imagens como “não usada para referência”, portanto o POC indica a ordem de saída das imagens. Isto também é usado no processo de decodificação 25 para a quantização implícita de vetores de movimento nos modos diretos de fatias bipreditivas, para o peso atribuído implicitamente na predição ponderada, e para a inicialização da lista de imagens de referência das fatias B. Além disso, o POC também é usado na verificação de conformidade da ordem de saída.

Os valores do POC podem ser codificados com um dos três modos sinalizados no conjunto de parâmetros da seqüência ativo. No primeiro modo, o número selecionado dos bits menos significativos do valor do POC são incluídos no cabeçalho da fatia, no segundo modo os incrementos relativos do POC como uma função da posição da imagem na ordem de decodificação dentro da seqüência de vídeo codificada, são codificados no conjunto de parâmetros da seqüência. Adicionalmente, desvios 5 provenientes do valor do POC atribuído a partir do conjunto de parâmetros de seqüência pode ser indicado nos cabeçalhos de fatias. No terceiro modo, o valor do POC é atribuído a partir da ordem de decodificação, assumindo-se que a ordem de decodificação e de saída são idênticas. Adicionalmente, apenas uma imagem que não seja de referência pode ocorrer consecutivamente quando o terceiro modo é usado.

O nalrefidc é um elemento sintá tico de dois bits dentro do cabeçalho da

unidade NAL. O valor do nal_ref_idc indica a relevância da unidade NAL para a reconstrução dos valores de amostra. Valores diferentes de zero no nal ref idc têm que ser usados para fatias codificadas e unidades NAL de partição de dados de fatia das imagens de referência, tal como para o conjunto de parâmetros das unidades NAL. O valor do nal ref idc tem que ser igual a O para as fatias e partições de dados de fatias de imagens que não são de referência e para unidades NAL que não afetam a reconstrução dos valores de amostra, tais como as unidades NAL de informação de ganho suplementar. No projeto de alto nível do H.264/AVC, foi permitido que especificações externas (por exemplo, qualquer sistema ou especificação usando ou se referindo ao H.264/AVC) especifiquem uma interpretação para os valores diferentes de zero do nal ref idc. Por exemplo, o formato da carga útil para H.264/AVC, Request for Comments (RFC) 3984 (o qual pode ser encontrado em www.ietf.org/rfe/rfe3984.txt e está incorporado neste documento por referência) especificou fortes recomendações para o uso do nal ref idc. Em outras palavras, alguns sistemas têm estabelecido métodos para atribuir e interpretar valores diferentes de zero no nal ref idc. Por exemplo, um misturador RTP poderia atribuir valores ao nal_ref_idc de acordo com o tipo de unidade NAL, por exemplo, o valor 3 é atribuído ao nal ref idc para unidades NAL IDR. Como o MVC é uma extensão inadvertidamente compatível do padrão H.264/AVC, é desejável que os elementos de sistemas existentes cientes do H.264/AVC também sejam capazes de manipular as seqüências MVC. Desta forma é indesejável para a semântica de um valor particular diferente de zero do nal_ref_idc ser especificado diferente dentro da especificação MVC comparado a qualquer outro valor diferente de zero do nal_ref_idc.

Imagens decodificadas usadas para a predição de imagens codificadas subsequentes e para saída futura, são armazenadas em memória temporária (Buffered) em 5 uma memória temporária (buffer) de imagem decodificada (DPB), Para a utilização eficaz da memória temporária (buffer), os processos de gerenciamento de DPB, incluindo o processo de armazenamento de imagens decodificadas dentro do DPB, o processo de marcação das imagens de referência, saída e processo de remoção de imagens decodificadas da DPB, deveriam ser especificados.

O processo para a marcação de imagem de referência dentro do AVC se dá

geralmente como a seguir. O número máximo de imagens de referência usadas para a predição inter, referenciado como M, é assinalado no conjunto de parâmetros de seqüência ativo. Quando uma imagem de referência é decodificada, ela é marcada como “usada para referência”. Se a decodificação daquela imagem de referência faz com que 15 mais do que M imagens estejam marcadas como “usada para referência”, então ao menos uma imagem tem que ser marcada como “não usada para referência”. O processo de remoção do DPB poderia então remover imagens marcadas como “não usada para referência” do DPB se elas também não forem necessárias para saída.

Existem dois tipos de operações para a marcação de imagens de referência: controle de memória adaptativo e janelas deslizantes. O modo de operação para a marcação de imagem de referência é selecionado com base na imagem. O controle de memória adaptativo requer a presença de comandos de operação de controle do gerenciamento de memória(MMCO) dentro do fluxo de bits. As operações de controle de gerenciamento de memória permitem a sinalização explícita de quais imagens são marcadas como “não usada para referência”, a mudança de sinalização de índices de imagens de referência de longo termo para curto termo, o armazenamento da imagem corrente como imagem de longo termo, a mudança de imagem de curto termo para imagem de longo termo e a sinalização do índice máximo de longo termo permitido (MaxLongTermFrameid) para imagens de longo termo. Se o modo de operação de janelas deslizantes estiver em uso e M imagens estiverem marcadas como “usada para referência” então a imagem decodificada mais cedo como de curto termo dentre aquelas imagens que estão marcados como “usada para referência” é marcada como “não usada para referência”. Em outras palavras, o modo de operação de janelas deslizantes resulta em uma operação, primeiro a entrar/primeiro a sair entre as imagens de referência de 5 curto termo.

Cada imagem de curto termo é associada com a variável PicNum que é derivada do elemento sintático framenum. Cada imagem de longo termo é associada com a variável LongTermPicNum que é derivada do elemento sintátic o long term frame idx, o qual é assinalado pelo comando MMCO. PicNum é derivado do 10 elemento sintá tico FrameNumWrap, dependendo de qual dos dois, quadro ou campo, é codificado ou decodificado. Para quadros onde PicNum é igual a FrameNumWrap, FrameNumWrap é derivado de FrameNum, e FrameNum é derivado diretamente do frame num. Por exemplo, na codificação de quadros AVC, FrameNum é assinalado com o mesmo valor de frame_num, e FrameNumWrap é definido como segue:

Se (FrameNum > frame_num)

FrameNumWrap = FrameNum - MaxFrameNum ou então

FrameNumWrap = FrameNum

LongTermPicNum é derivado do índice de quadro de longo termo 20 (LongTermFrameIdx) assinalado para a imagem. Para quadros onde LongTermPicNum é igual ao LongTermFrameIdx, frame num é um elemento sintático dentro de cada cabeçalho de fatia. O valor de frame num para um quadro ou um par de campos complementares essencialmente incrementa de um, em módulo aritmético, relativo ao frame num do quadro de referência prévio ou do par de campo complementar de 25 referência. Nas imagens IDR, o valor de frame_num é zero. Para imagens contendo uma operação de controle de gerenciamento de memória marcando todas as imagens como “não usada para referência” o valor de frame_num deve ser zero após a decodificação da imagem.

Os comandos MMCO usam PicNum e LongTermPicNum para indicar a imagem alvo para o comando como segue. Para marcar uma imagem de curto termo como “não usada para referência”, a diferença entre o PicNum da imagem corrente p e a imagem destino y é sinalizada no comando MMCO. Para marcar uma imagem de longo termo como “não usada para referência” o LongTermPicNum da imagem a ser removida r é sinalizado no comando MMCO. Para armazenar a imagem corrente p como uma 5 imagem de longo termo, um long term frame idx é assinalado com o comando MMCO. Este índice é atribuído a imagem de longo termo recém armazenado como o valor de LongTermPicNum. Para mudar uma imagem r de imagem de curto termo para imagem de longo termo, uma diferença entre a imagem correte p e a imagem r é assinalada no comando MMCO, o long_term_frame_idx é sinalizado no comando MMCO, e o índice á 10 atribuído a esta imagem de longo termo.

Quando imagens de referência múltipla poderiam ser usadas, cada imagem de referência deve ser identificada. No AYC, a identificação de uma imagem de referência usada para um bloco codificado é feita como segue. Inicialmente, todas as imagens de referência armazenadas na DPB para referência de predição de imagens 15 futuras são marcadas como “usadas para referência de curto termo” (imagens de curto termo) ou “usadas para referência de longo termo” (imagens de longo termo). Quando se decodifica uma fatia codificada, uma lista de imagens de referência é construída. Se a fatia codificada é uma fatia bipredita, então uma segunda lista de referência também é construída. Uma imagem de referência usada pelo bloco codificado é então identificada 20 pelo índice da imagem de referência usada, na lista de imagens de referência. O índice é codificado dentro de um fluxo de bits quando mais de uma imagem de referência pode ser usada.

O processo de construção da lista de imagens de referência é feito como descrito a seguir. Para simplificação, é assumido que apenas uma lista de imagens de 25 referência é necessária. Inicialmente, é construída uma lista de imagens de referência inicial incluindo todas as imagens de curto termo e de longo termo. Quando o cabeçalho da fatia contém um comando RPLR é realizada uma reordenação das imagens de referência (RPLR). O processo pode reordenar as imagens de referência em uma ordem diferente da ordem da lista inicial. Finalmente, a lista final é construída, permanecendo 30 apenas um número de imagens no começo da lista reordenada de possíveis, sendo este número indicado por outro elemento sintát ico contido no cabeçalho da fatia ou no conjunto de parâmetros de imagem referenciado pela fatia.

Durante o processo de inicialização, todas as imagens de curto termo e de longo termo, são consideradas como candidatas para as listas de imagens de referência para a imagem corrente. Independentemente de a imagem corrente ser uma imagem B ou P, as imagens de longo termo são posicionadas após as imagens de curto termo na RefPicListO (e RefPicList disponível para as fatias B). Para as imagens P, a lista de imagens de referência inicial para RefPicListO contém todas as imagens de referência de curto termo ordenadas em ordem descendente de PicNum. Para imagens B, aquelas imagens de referência obtidas de todas as imagens de curto termo são ordenadas por uma regra relacionada ao número POC corrente e o número POC da imagem de referência para RefPicList), imagens de referência com POCs menores (comparados ao POC corrente) são consideradas prioritár ias e inseridas na RefPicListO em ordem descendente do POC. Então as imagens com POCs maiores são anexadas em ordem ascendente do POC. Para a RefPicListl (se disponível), imagens de referência com POCs maiores ( comparados ao POC corrente) são consideradas prioritárias e inseridas na RefPicListl em ordem ascendente de POC. Imagens com POCs menores são então anexadas em ordem descendente de POC. Depois de considerar todas as imagens de referência de curto termo, as imagens de referência de longo termo são anexadas em ordem ascendente de LongTermPicNum, tanto as imagens P como B.

O processo de reordenação é solicitado por comandos RPLR contínuos, os quais incluem quatro tipos. O primeiro tipo o primeiro comando é para especificar uma imagem de curto termo com o PIcNum menor (comparado com um PicNum predito temporário) para ser movida. O segundo tipo é um comando que especifica uma imagem 25 de curto termo com o PicNum maior para ser movida. O terceiro tipo é um comando que especifica uma imagem de longo termo com um certo Long TermPicNum para ser movida e o fim do laço RPLR. Se a imagem corrente é bipredita, então existem dois laços, um para lista de referência de avanço e outra para uma lista de referência de recuo.

A PicNum predita, chamada de picNumLXPred é inicializada como a PicNum da imagem codificada corrente. A esta é atribuído o valor de PicNum da imagem recém-movida após cada processo de reordenação para as imagens de curto termo. A diferença entre o PicNum da imagem corrente sendo reordenada e o Pic NumLXPred, deve ser assinalada no comando RPLR. A imagem indicada para ser reordenada é movida para o início da lista de imagens de referência. Após o processo de reordenação ser 5 completado, uma lista de imagens de referência completa deve ser truncada com base no tamanho da lista de imagens de referência, que é o num_ref_idx_IX_active_minusl +1 (X igual a 0 ou 1 corresponde a RefPicListO e RefPicListl respectivamente).

O decodificador de referência hipotética (HRD), especificado no Anexo C do padrão H.264/AVC, é usado para verificar o fluxo de bits e a conformidade da 10 decodificação. O HRD contém uma memória temporária (buffer) de imagem codificada (CPB), um processo de decodificação instantâneo, uma memória temporária (buffer) de imagem decodificada (DPB), e um bloco de corte de imagem de saída. A CPB e o processo de decodificação instantâneo são especificados similarmente a qualquer outro padrão de codificação de vídeo, e o bloco de corte de imagem de saída simplesmente 15 corta aquelas amostras da imagem decodificada que estão fora da dimensão da imagem de saída assinalada. A DPB foi introduzida no H.264/AVC para controlar os recursos de memória requeridos paraa decodificação de fluxos de bits conformes.

Existem duas razões para imagens decodificadas em memória temporária (buffer), para referências em predição inter e para a reordenação das imagens na ordem 20 de saída. Como o padrão H.264/AVC fornece um grande desafio de flexibilidade para ambas as marcações de imagens e reordenação de saída, memórias temporárias (buffers) separadas para armazenamento temporário (buffering) de imagens de referência e reordenação de saída poderia ser um desperdício de recursos de memórã. Desta forma, a DPB inclui um processo de armazenamento temporário de imagens decodificadas 25 unificado para imagens de referência e reordenação de saída. Uma imagem decodificada é removida da DPB quando não é mais usada como referência ou necessária para a saída. O tamanho máximo da DPB que os fluxos de bits são autorizados a usar é especificado nas definições de nível (Anexo A) do padrão H. 264/AVC.

Existem dois tipos de conformação para decodificadores: conformação de temporização de saída e conformação de ordem de saída. Para a conformação de temporização de saída, um decodificador deve sair com as imagens em tempos idênticos comparados ao HRD. Para a conformação de ordem de saída, apenas a ordem correta das imagens de saída é levada em conta. Presume-se que o DPD de ordem de saída contenha um número máximo permitido de memórias temporárias (buffers) de quadros. Um 5 quadro é removido da DPB quando não é mais usado como referência e não é mais necessário para a saída. Quando a DPB fica cheia, o primeiro quadro na ordem de saída é saído até pelo menos uma memória tsnporária (buffer) de quadro ficar desocupada.

A escalabilidade temporal é realizada pela estrutura hierárq uica GOP de imagens B usando apenas ferramentas AVC. Uma típica escalabilidade temporal GOP 10 usualmente inclui uma imagem chave a qual é codificada como um quadro I ou P, e outras imagens as quais são codificadas como imagens B. Estas imagens B são codificadas hierarquicamente baseadas no POC. A codificação de um GOP precisa apenas das imagens chave do GOP prévio além daquelas imagens dentro do GOP. O número POC relativo (POC menos a imagem âncora POC prévia) é referenciado como POCLdLnGOP 15 na implementação. Todo POCLdLnGOP uma fórmula de POCLdLnGOP=(2**x)y (sendo que y é um número ímpar). As imagens com os mesmos valores de x pertencem ao mesmo nível temporal, o qual é conhecido como L-x (onde L = Iog 2(GOP_length)). Apenas as imagens com os níveis temporais mais altos L não são armazenadas como imagens de referência. Normalmente, imagens em um nível temporal podem somente usar 20 imagens em níveis temporais menores como referências para suportar a escalabilidade temporal, por exemplo, imagens de níveis temporais mais altos podem ser baixadas sem que sejam afetadas as decodificações de imagens de menor nível temporal. De forma similar, a mesma estrutura hierárqu ica pode ser aplicada na dimensão de visão para a escalabilidade de visão.

Dentro do corrente JMVM, o frame num é codificado separadamente e

assinalado para cada visão, por exemplo, o valor de frame num é incrementado relativamente ao quadro de referência prévio ou ao par de campos complementares de referência dentro da mesma visão da imagem corrente. Desta forma, as imagens em todas as visões compartilham a mesma memória temporária (buffer) DPB. A fim de globalmente manusear a construção da lista de imagens de referência e o gerenciamento de imagens de referência, a geração do FrameNum e do POC é redefinida como descrito a seguir:

FrameNum - frame_num*( 1 + num_views_minus_ 1)+view_id PicOrderCntO = PicOrderCntO *( 1 + num_views_minus_ 1)+view_id;

JMVM basicamente segue a mesma marcação de imagem de referência que

aquela usada pela AVC. A única diferença é que no JMVM o FrameNum é redefinido tal como o FrameNumWrap é redefinido como segue:

if(FrameNum > frame_num*(l+num_views_minus_l)+view_id)

FrameNumWrap = FrameNum - MaxFrameNum*(l+num_views_minus_l)+

view_id else

FrameNumWrape= FrameNum

No padrão JMVM corrente, as imagens de referência intervisão são implicitamente especificadas dentro da extensão SPS (Conjunto de Parâmetros de 15 Seqüência), na qual o número ativo de listas de referência de intervisão e o id de visão daquelas imagens são especificados. Esta informação é compartilhada por todas as imagens referentes ao mesmo SPS. A construção da lista de imagens de referência processa primeiramente a inicialização da lista de imagens de referência, reordenação e truncamento da mesma forma que na AVC, mas levando em conta todas as imagens de 20 referência armazenadas dentro da DPB. As imagens com ids de visão especificados dentro da SPS e dentro do mesmo eixo temporal (por exemplo, tendo o mesmo tempo de captura/saída) são então anexadas à lista de referência na ordem em que são listados na SPS.

Infelizmente, o projeto JSVM acima leva a uma série de problemas. Inicialmente, algumas vezes é desejável que alternância entre visões decodificada (por um decodificador), transmitida (por um transmissor) ou enviada (por um portal de mídia ou MANE) pudesse ocorrer dentro de um índice de tempos diferente daquele correspondente às imagens âncoras. Por exemplo, uma visão base pode ser comprimida para maior eficácia na codificação (predição temporal é usada de forma pesada) e imagens âncoras são codificadas com pouca frequência. Consequentemente, imagens âncora para outras visões também ocorrem com pouca frequência, pois elas são sincronizadas através das visões. A sintaxe JMVM corrente, não inclui a sinalização de 5 uma imagem a partir da qual a decodificação de uma certa visão possa ser iniciada ( a menos que todas as visões daquele índice de tempo contenham uma imagem âncora) .

Segundo, as visões de referência para predição intervisão são especificadas por cada visão (e separadamente para imagens âncora e não âncora). Embora dependendo da similaridade entre uma imagem sendo codificada e uma imagem potencial no mesmo eixo temporal e dentro de uma potencial visão de referência, a predição intervisão pode ser ou não realizada dentro do codificador. O padrão corrente JMVM usa o nal_ref_idc para indicar quando uma imagem é usada para predição intravisão ou intervisão, mas isto isoladamente não consegue indicar se uma imagem é usada para predição intravisão e/ou predição intervisão. Adicionalmente, de acordo com a JMVM 1.0, para as visões compatíveis com AVC, o nal_ref_idc tem que ser sinalizados com valor diferente de 0 mesmo se a imagem não é usada para predição temporal quando ela é usada apenas para referência de predição intervisão. Por conseqüência, se apenas aquela visão é decodificada e saída, um tamanho de DPB adicional é necessário para o armazenamento daquelas imagens quando aquelas imagens podem ser saídas tão logo elas sejam decodificadas.

Terceiro, é notado que o processo de marcação das imagens de referência especificado no JMVM 1.0 é basicamente idêntico ao processo AVC, exceto pela redefinição de FrameNum, FrameNumWrap e, consequentemente PicNum. Desta forma, uma quantidade de problemas aparece. Por exemplo, este processo não consegue 25 manipular com eficácia o gerenciamento de imagens decodificadas que são requeridas para serem armazenadas em memória temporária para a predição intervisão, particularmente quando aquelas imagens não são usadas para referência de predição temporal. A razão é que o processo de gerenciamento de DPB especificado no padrão AVC foi desenvolvido para a codificação de visão simples. Na codificação de visão 30 simples tal como no padrão AVC, imagens decodificadas que precisam ser armazenadas em memória temporária para referência de predição temporal e futura saída podem ser removidas da memória temporária (buffer) quando não são mais necessárias para a referência de predição temporal e saída futura. Para permitir a remoção de uma imagem de referência tão logo ela se torne inútil para a referência de predição temporal e saída 5 futura, o processo de marcação de imagem de referência é especificado de forma que isto seja conhecido imediatamente após uma imagem de referência se tornar inútil para a referência de predição temporal. Entretanto, quando se trata de imagens para a referência de predição intervisão, não existe uma forma de se saber imediatamente após uma imagem tornar-se inútil para referência de predição intervisão. Por conseqüência, 10 imagens para referência de predição intervisão podem ser desnecessariamente armazenadas em memória temporária dentro da DPB, o que reduz a eficácia no uso de memória temporária.

Em outro exemplo, visto que o caminho para recalcular o PicNum, se o modo de operação de janelas deslizantes está em uso e o número de imagens de curto termo e longo termo é igual ao máximo, a imagem de referência de curto termo que tem o menor FrameNumWrap é marcada como “não usada para referência”. Entretanto, devido ao fato de que esta imagem não é necessariamente a imagem codificada mais cedo porque a ordem de FrameNum na JMVM corrente não segue a ordem de decodificação, a marcação da imagem de referência na janela deslizante não opera de forma otimizada na JMVM corrente. Ainda mais longe, devido ao fato de que o PicNum é derivado do FrameNUmWrap quantizado e redefinido, a diferença entre os valores de PicNum de duas imagens codificadas poderia ser quantizado pela média. Por exemplo, assumindo que existam duas imagens na mesma visão com framenum iguais a 3 e 5, respectivamente. Quando há apenas uma visão, por exemplo, quando o fluxo de bits é um fluxo AVC, então a diferença dos dois valores de PicNum seria 2. Quando codificando a imagem cujo frame num é igual a 5, se um comando MMCO é requerido para marcar a imagem cujo PicNum é igual a 3 como “não usada como referência”, então a diferença dos dois valores menos 1 é igual a 1, o que é sinalizado dentro do MMCO. Este valor precisa de 3 bits. Entretanto, se existirem 256 visões, então a diferença dos dois valores de PicNum menos 1 seria 511, Neste caso, são necessários 19 bits para sinalizar o valor. Por conseqüência, os comandos MMCO são codificados de forma muito menos eficaz. Tipicamente, o acréscimo no número de bits é igual a 2*log2(número de visões) para um comando MMCO na JMVM corrente comparado a codificação de visão simples da H.264/A VC.

5 Um quarto conjunto de problemas cerca o processo de construção da lista

de imagens de referência especificado na JMVM 1.0. O processo de inicialização da lista de imagens de referência considera imagens de referência de todas as visões antes do processo de reordenação. Entretanto, devido ao fato de que imagens de outras visões, usadas para predição intervisão são anexados a lista após o truncamento da lista, imagens 10 de referência de outras visões não aparecem na lista de imagens de referência após a reordenação e truncamento de qualquer forma. Sendo assim, não é necessário se considerar aquelas imagens no processo de inicialização. Além disso, imagens de referência ilegais (tais como imagens que tem um view_id diferente daquele da imagem corrente e não estão temporariamente alinhados com a imagem corrente) e imagens de 15 referência de intervisão repetidas podem aparecer ao final na lista de imagens de referência construída.

O processo de inicialização da lista de imagens de referência opera como listado nas seguintes etapas: (I) Todas as imagens de referência são incluídas na lista inicial, independente de seus View_id e de estarem ou não temporariamente alinhadas 20 com a imagem corrente. Em outras palavras, a lista de imagens de referência inicial pode conter imagens de referência ilegais (tais como imagens que tem um view id diferente daquele da imagem corrente e não estão temporariamente alinhados com a imagem corrente). Entretanto, na codificação com prioridade na visão, o começo da lista inicial contém imagens de referência da mesma visão da imagem corrente. (2) Ambas as imagens 25 de referência de intravisão e imagens intervisão podem ser reordenadas. Após a reordenação, o começo da lista pode ainda conter imagens de referência ilegais. (3) A lista é truncada, mas a lista truncada ainda pode conter imagens de referência ilegais. (4) As imagens de referência de intervisão são anexadas à lista na ordem em que aparecem na extensão MVC da SPS. Adicionalmente, o processo de reordenação da lista de imagens de referência especificado no JMVM 1.0 não permite a reordenação e quadros intervisão, os quais são sempre colocados no final da lista na ordem em que aparecem na extensão MVC da SPS. Isto causa menos flexibilidade para a construção da lista de imagens de 5 referência, o que resulta em redução de eficácia na compressão, quando a ordem primária dos quadros de referência de intervisão não é ótima ou alguns quadros de referência de intervisão são preferíveis a alguns quadros de referência intravisão para serem usados na predição. Ainda mais longe, similar aos comandos MMCO, devido ao fato de que o PicNum é derivado do FrameNumWrap quantizado e redefinido, palavras de 10 codificação VLC mais longas são requeridas para codificar os comandos RPLR envolvendo a sinalização da diferença entre o valor PicNum menos 1 comparado a codificação de visão sim pies do padrão H.264/AVC.

SUMÁRIO DA INVENÇÃO A presente invenção proporciona um sistema e um método aperfeiçoados para a implantação de um gerenciamento de memória temporária (buffer) de imagem decodificada eficaz em codificação de vídeo multivisão. Em uma modalidade, um novo campo sinalizador é utilizado para indicar quando a decodificação de uma visão pode ou não ser iniciada a partir de uma certa imagem. Em uma modalidade mais particular, este campo sinalizador é assinalado dentro do cabeçalho da unidade NAL. Em outra modalidade, um novo campo sinalizador é usado para indicar quando um imagem é usada ou não para a referência de predição intervisão, enquanto o elemento sintát ico nal ref idc apenas indica quando a imagem é usada ou não para referência de predição temporal. Este campo sinalizador pode também ser assinalado dentro do cabeçalho da unidade NAL. Em uma terceira modalidade, um conjunto de novos métodos de marcação de imagem de referência é usado para gerenciar de forma eficaz as imagens decodificadas. Estes métodos podem incluir ambos os mecanismos de janela deslizante e controle de memória adaptativo. Em uma quarta modalidade, um conjunto de novos métodos de construção da lista de imagens de referência é usado e inclui tanto a inicialização da lista de imagens de referência como a reordenação. Estas e outras vantagens e características da invenção, em conjunto com a organização e forma de operação da mesma, ficarão claros a partir da descrição detalhada que segue quando entendido em conjunto com os desenhos em anexo, os quais têm elementos e números exatamente como as descrições abaixo.

BREVE DESCRIÇÃO DOS DESENHOS

Figura 1 é uma disposição de imagens em uma disposição de codificação com prioridade em visão;

Figura 2 é uma disposição de imagens em uma disposição de codificação com prioridade em tempo;

Figura 3 e uma representação de um exemplo de MVC temporal e estrutura

de predição intervisão;

Figura 4 é um diagrama de visão geral de um sistema dentro do qual a presente invenção pode ser implementada;

Figura 5 é uma visão perspectiva de um dispositivo móvel que pode ser usado na implementação da presente invenção; e

Figura 6 é uma representação esquemática do conjunto de circuito do dispositivo móvel da figura 5.

DESCRIÇÃO DETALHADA DAS VÁRIAS MODALIDADES A figura 4 mostra um sistema de comunicações multimídia genérico para uso com a presente invenção. Como mostrado na figura 4, uma fonte de dados 100 fornece uma fonte de sinal de formato analógco, digital sem compressão, ou digital comprimido, ou qualquer combinação destes formatos. Um codificador 110 codifica o sinal fonte em um fluxo de bits de mídia codificada. O codificador 110 pode ser capaz de codificar mais do que um tipo de mídia, tal como áudio, vídeo ou mais do que um codificador pode ser necessário para codificar os diferentes tipos de mídia do sinal fonte. O codificador 110 pode também receber entrada produzida sinteticamente, tais como gráficos ou textos, ou pode ser capaz de produzir fluxos de bits codificados de mídia sintética. A seguir, apenas o processamento de um fluxo de bits de mídia codificada de um tipo de mídia é considerado para simplificar a descrição. Deve ser notado, contudo, que os serviços típicos de difusão em tempo real compreendem alguns fluxos (tipicamente pelo menos um fluxo de áudio, de vídeo e de texto de legenda). Deve ser notado também que o sistema pode incluir muitos decodificadores, mas a seguir um único codificador 110 é considerado para a simplificação da descrição s em uma perda de generalidade.

O fluxo de bits de mídia codificada é transferido para um dispositivo de armazenamento 120. O dispositivo de armazenamento 120 pode compreender qualquer tipo de memória de massa para armazenar o fluxo de bits de mídia codificada. O formato do fluxo de bits de mídia codificada dentro do dispositivo de armazenamento 120 pode ser um formato de fluxo de bits reservado elementar, ou um ou mais fluxos de bits de mídia codificados podem ser encapsulados em um arquivo receptor. Alguns sistemas operam “ao vivo”, por exemplo, omitem o dispositivo de armazenamento e transferem o fluxo de bits de mídia codificada do codificador diretamente ao transmissor 130. O fluxo de bits de mídia codificada é então transferido para o emissor 130, também referenciado como servidor, dependendo do contexto. O formato usado na transmissão pode ser um formato de fluxo de bits reservado elementar, um formato de fluxo empacotado, ou um ou mais fluxos de bits de mídia codificados podem ser encapsulados em um arquivo receptor. O codificador 110, o dispositivo de armazenamento 120, e o transmissor 130, podem residir em um mesmo dispositivo físico ou podem ser incluídos em dispositivos separados. O codificador 110 e o transmissor 130 podem operar ao vivo com conteúdo em tempo real, caso em que o fluxo de bits de mídia codificada tipicamente não é armazenado permanentemente, mas apenas armazenado temporariamente por curtos períodos de tempo no codificador de conteúdo 110 e/ou no transmissor 130 para suavizar as variações nos atrasos de processamento, atrasos de transferência taxa de transferência de bits da mídia codificada.

O transmissor 130 envia o fluxo de bits de mídia codificada usando uma 25 pilha de protocolo de comunicação. A pilha pode incluir, mas não está limitada ao Real- Time Transport Protocol (RTP), User Datagram Protocol (UDP), e Internet Protocol (IP). Quando a pilha de protocolo de comunicação é orientada a pacote, o transmissor 130 encapsula o fluxo de bits de mídia codificada dentro de pacotes. Por exemplo, quando RTP é usado, o transmissor encapsula o fluxo de bits de mídia codificada dentro de 30 pacotes RTP de acordo com um formato de carga útil RTP. Tipicamente, cada tipo de mídia tem um formato payload RTP dedicado. Deve também ser notado que um sistema pode conter mais do que um transmissor 130, mas em benefício da simplicidade, a seguinte descrição considera apenas um emissor 130.

O transmissor 130 pode ou não estar conectado a um conector de passagem 140 ao longo da rede de comunicação. O conector de passagem pode realizar diferentes tipos de funções, tais como traduções de fluxo de pacotes de acordo com uma pilha de protocolo de comunicação para outra pilha de protocolo de comunicação, fusão e particionamento de fluxos de dados, e manipulação de fluxos de dados de acordo com a conexão de envio e/ou características do receptor, tais como controle da taxa de bits do fluxo enviado de acordo com as condições predominantes na conexão de envio da rede. Exemplos de conector de passagem incluem unidades de controle de conferência multiponto (MCUs), conectores de passagem entre redes de telefonia e vídeo comutadas por circuitos e comutadas por pacotes, servidores aperte-fale sobre celular (PoC), encapsuladores IP em sistemas de difusão de vídeo digital portáv el (DVB-H), ou equipamentos empilháv eis que fazem a difusão de transmissões localmente em redes sem fio caseiras. Quando é usado RTP, o conector de passagem 140 é chamado de misturador RTP e age como um ponto final de uma conexão RTP.

O sistema inclui um ou mais receptores 150, tipicamente capazes de receber, demodular, e desencapsular o sinal transmitido dentro de um fluxo de bits de 20 mídia codificada. O fluxo de bits de mídia codificada é tipicamente processado adicionalmente por um decodificador 160, do qual saem um ou mais fluxos de mídia descomprimidos. Deve ser notado que o fluxo de bits para ser decodificado pode ser recebido de um dispositivo remoto localizado dentro de virtualmente qualquer tipo de rede. Adicionalmente, o fluxo de bits pode ser recebido de um hardware ou software 25 locais. Finalmente, um renderizador 170 pode reproduzir os fluxos de mídia descomprimidos com um auto falante ou uma tela, por exemplo. O receptor 150, decodificador 160, e renderizador 170 podem residir no mesmo dispositivo físico ou podem ser incluídos em dispositivos separados.

Escalabilidade em termos de taxa de transferência de bits, complexidade de decodificação, e tamanho da imagem é uma propriedade desejada para ambientes e heterogêneos e propensos a erro. Esta propriedade é desejada para enfrentar limitações tais como restrições em taxas de transferência de bits, resolução de tela, banda de rede, e poder computacional em um dispositivo receptor.

Deve ser entendido que, embora o texto e os exemplos contidos aqui 5 possam descrever especificamente um processo de decodificação, um conhecedor da técnica deveria prontamente entender que os mesmos conceitos e princípios também se aplicam ao processo correspondente de decodificação e vice versa. Deve ser notado que o fluxo de bits para ser decodificado pode ser recebido de um dispositivo remoto localizado dentro de virtualmente qualquer tipo de rede. Adicionalmente, o fluxo de bits pode ser 10 recebido de um hardware ou software locais.

Dispositivos de comunicação da presente invenção podem comunicar-se usando várias tecnologias de transmissão incluindo, mas não limitados a, Code Division Multiple Access (CDMA), Global Systems for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Time Division Multiple Access (TDMA), 15 Frequency Division Multiple Access (FDMA), Transmission Control Protocol/Internet Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia Messaging Service (MMS), e-mail, Instant Messaging Service (IMS), Bluetooth, IEEE 802.11, etc. Um dispositivo de comunicação pode comunicar-se usando varias mídias incluindo, mas não limitado a, radio, infravermelho, laser, conexão via cabo, e outras semelhantes.

As figuras 5 e 6 mostram um dispositivo móvel representativo 12 no qual a

presente invenção pode ser implementada. Deve ser entendido, entretanto, que a presente invenção não tem o propósit) de estar limitada a um tipo particular de dispositivo móvel 12 ou outro dispositivo eletrônico. Algumas ou todas as características representadas nas figuras 5 e 6 poderiam ser incorporadas em qualquer ou em todos os dispositivos que possam ser utilizados no sistema mostrado na figura 4.

O dispositivo mcyel 12 das figuras 5 e 6 inclui um invólucro30, uma tela 32 na forma de uma tela de cristal líquido, um teclado 34, um microfone 36, um fone de ouvido 38, uma bateria 40, uma porta infravermelho 42, uma antena 44, um cartão inteligente 46 na forma de uma UICC de acordo com uma modalidade da invenção, um leitor de cartão 48, circuito de interface de rádi o 52, circuito codificador e decodificador 54, uma controladora 56 e uma memória 58. Circuitos individuais e elementos são todos de um tipo bem conhecido na técnica atual, por exemplo, dentro dos dispositivos móves da marca Nokia.

A presente invenção proporciona um sistema e um método aperfeiçoados para a implantação de um gerenciamento de memória temporária (buffer) em codificação de vídeo multivisão. Para enfrentar o problema que cerca o fato de que a sintaxe JMVM corrente não inclui a sinalização de uma imagem a partir da qual a decodificação de uma certa visão pode ser iniciada (a menos que todas as visões daquele índice temporal contenham uma imagem âncora), um novo campo sinalizador é assinalado indicando quando uma visão pode ou não ser iniciada a partir de uma certa imagem. Em uma modalidade da invenção, este campo sinalizador é assinalado no cabeçalho da unidade NAL. A seguir um exemplo da sintaxe e semâ ntica do campo sinalizador de acordo com uma modalidade particular. Entretanto, também é possível mudar a semântica do elemento sintá tico anchor_pic_flag de forma similar ao invés de incluir um novo elemento sintá tico.

nal unit header svc mvc extension() { C Descriptor svc_mvc flag Todos u(l) se (!svc_mvc_flag) { priorityid Todos u(6) discardable flag Todos u(l) temporallevel Todos u(3) dependency id Todos u(3) quality_level Todos u(2) layer base flag Todos u(l) use_base_prediction_flag Todos u(l) fragmentedflag Todos u(l) last_fragmented_flag Todos u(l) fragmented_order Todos u(2) reserved zero two bits Todos u(2) } ou então { view refresh flag Todos u(l) viewsubsetid Todos u(2) view levei Todos u(3) anchor_pic_flag Todos u(l) vew id Todos u(10) reserved zero five bits Todos u(6) } nalUnitHeaderBytes + =3 } Para certa imagem em uma visão, todas as imagens na mesma locação

temporal de outras visões que são usadas para predição intervisão são referenciadas como “a imagem de visão de dependência direta” e todas as imagens de mesma locação temporal de outras visões que são requeridas para a decodificação da imagem corrente são referenciadas como “a imagem de visão de dependência direta”.

A semântica da view_refresh_flag pode ser especificada por quatro caminhos em uma modalidade. O primeiro caminho para especificar a semântica da view refresh flag implica em ter a view_refresh_flag indicando que a imagem corrente e todas as imagens subsequentes na ordem de saída na mesma visão podem ser corretamente decodificadas quando todas as imagens de visão de dependência direta da imagem corrente e subsequentes estão na mesma visão e também estão (possivelmente parcialmente) decodificadas sem a decodificação de qualquer imagem precedente na mesma visão ou em outras visões. Isto implica em que (1) nenhuma das imagens de visão de dependência conta com qualquer imagem precedente na ordem de decodificação em qualquer visão, ou (2) se qualquer das imagens de visão de dependência conta com qualquer imagem precedente na ordem de decodificação em qualquer visão, então apenas as áreas restritas as codificadas intra, das imagens de dependência direta da imagem corrente e subsequentes dentro da mesma visão, são usadas na predição intervisão. Uma área restrita a codificação intra não usa dados provenientes de á reas vizinhas de codificação inter, para predição intra. Um segundo caminho para especificar a semâ ntica da view refresh flag implica em ter a view refresh flag indicando que a imagem corrente e todas as imagens subsequentes na ordem de decodificação na mesma visão podem ser corretamente decodificadas quando todas as imagens de visão de dependência direta da imagem 5 corrente e imagens subsequentes dentro da mesma visão também estão completamente ou, em uma modalidade, parcialmente decodificadas sem a decodificação de qualquer imagem precedente.

Um terceiro caminho para especificar a semântica da view refresh flag implica em ter a view refresh flag indicando que a imagem corrente e todas as imagens 10 subsequentes na ordem de saída na mesma visão podem ser corretamente decodificadas quando todas as imagens de visão de dependência direta da imagem corrente e imagens subsequentes dentro da mesma visão também estão completamente ou, em uma modalidade, parcialmente decodificadas. Esta definição é análoga a uma imagem intrainiciando uma GOP aberta em codificação de visão simples. Em termos de 15 especificação textual, esta opção pode ser descrita como segue: Uma view refresh flag igual a 1 indica que a imagem corrente e qualquer imagem subsequente na ordem de decodificação dentro da mesma visão da imagem corrente e seguindo a imagem corrente na ordem de saída não têm referências a imagens que precedem a imagem corrente na ordem de decodificação no processo de predição inter. Uma view refresh flag igual a 0 20 indica que a imagem corrente ou uma imagem subsequente na ordem de decodificação dentro da mesma visão da imagem corrente e seguindo a imagem corrente na ordem de saída pode ter referências a imagens que precedem a imagem corrente na ordem de decodificação no processo de predição inter.

Um quarto caminho para especificar a semân tica da view_refresh_flag 25 implica em ter a view refresh flag indicando que a imagem corrente e todas as imagens subsequentes na ordem de decodificação na mesma visão podem ser corretamente decodificadas quando todas as imagens de visão de dependência direta da imagem corrente e imagens subsequentes dentro da mesma visão também estão completamente ou, em uma modalidade, parcialmente decodificadas. . Esta definição é análoga a uma 30 imagem intrainiciando uma GOP aberta em codificação de visão simples. A view refresh flag pode ser usada em um sistema tal como o descrito na Figura 4. Nesta situação, o receptor 150 recebe, ou o decodificador 160 decodifica, apenas um certo subconjunto M de todas as visões disponíveis N, o subconjunto excluindo a visão A. Atendendo a uma ação do usuário, por exemplo, o receptor 150 ou o decodificador 160 poderiam querer receber ou decodificar, respectivamente, a visão A de agora em diante. O decodificador pode iniciar a decodificação da visão A a partir da primeira imagem, tendo a view refresh flag igual a 1 dentro da visão A. Se a visão A não foi recebida, então o receptor 150 pode sinalizar para o conector de passagem 140 ou o transmissor 130 para incluir as imagens codificadas da visão A dentro do fluxo de bits transmitido. O conector de passagem 140 ou o transmissor podem esperar até a próxima imagem contendo uma view_refresh_flag igual a 1 dentro da visão A antes de enviar qualquer imagem da visão A para evitar a transmissão de imagens desnecessárias da visão A que o decodificador 160 poderia não decodificar com sucesso.

Para enfrentar o segundo problema tratado previamente, um novo campo sinalizador é assinalado para indicar quando uma visão é usada ou não para referência de predição intervisão, e o elemento sintático nal_ref_idc indica apenas quando uma imagem é usada ou não para referência de predição temporal. Em uma modalidade particular, este campo sinalizador pode ser assinalado no cabeçalho da unidade NAL. A seguir um exemplo da sintaxe e semântica do ca mpo sinalizador.

nal_unit_header svc_mvc_extension() { C Descriptor svc _mvc_flag Todos u(l) se (!svc_mvc flag) { priority id Todos u(6) discardable flag Todos u(l) temporal levei Todos u(3) dependency id Todos u(3) quality levei Todos u(2) layer_base_flag Todos u(l) use_base_prediction_flag Todos u(l) fragmented flag Todos u(l) last_fragmented_flag Todos u(l) fragmentedorder Todos u(2) reserved zero two bits Todos u(2) } ou então { interviewreferenceflag Todos u(l) view_subset_id Todos u(2) view levei Todos u(3) anchor_pic flag Todos u(l) vew id Todos u(10) reserved zero five bits Todos u(6) } nalUnitHeaderBytes + =3 } Uma inter view reference flag igual a O indica que a imagem corrente

não é usada como imagem de referência intervisão. Uma inter_view_reference_flag igual a 1 indica que a imagem corrente é usada como uma imagem de referência intervisão. O valor da interviewreferenceflag é inferido para ser igual a 1 quando profile_ide indica 5 um perfil MVC e o view id é 0. Quando decodifica-se uma imagem, todas as imagens que tem uma inter view reference flag igual ale estão no mesmo eixo temporal da imagem corrente são referenciadas como imagens intervisão da imagem corrente.

A inter_view_reference_flag pode ser usada em um conector de passagem 140, também referenciado como elemento de rede independente de mídia (MANE). 10 Quando uma imagem não é usada como referência intervisão e referência intravisão (inter view flag é igual a 0 e nal_ref_idc é igual a 0), um MANE pode ou não transmitir esta sem conseqüências na decodificação do fluxo de bits restante. Quando uma imagem não é usada como referência intervisão, mas é usada como referência intravisão, um MANE poderia descartar a imagem apenas se descartasse também a transmissão das 15 visões dependentes. Quando uma imagem não é usada como referência intervisão, mas é usada como referência intravisão, um MANE poderia descartar a imagem apenas se esta não é requerida ou desejada para a decodificação da visão em que a imagem reside. Com relação ao problema do processo de marcação de imagens de referência especificado no JMVM 1.0 não ser capaz de gerenciar de forma eficaz a manipulação de imagens decodificadas que tem que ser armazenadas em memória temporária para a predição intervisão, o campo sinalizador inter_view_reference_flag é 5 reusado. Imagens com uma inter_view_reference_flag igual a 1 podem ser marcadas usando qualquer um de três métodos.

Um primeiro método para a marcação de imagens com uma inter_view_reference_flag igual a 1 implica em armazenar imagens de referência intervisão temporariamente como imagens de longo termo. No processo de codificação,

cada imagem usada para predição intervisão é indicada no fluxo de bits para ser marcada como “usada para referência de longo termo”. Um caminho para indicar a marcação como “usada para referência de longo termo” é a inter view reference flag. O decodificador responde a indicação marcando a imagem como “usada para referência de longo termo” e “referência multivisão de longo termo temporária”. Qualquer operação 15 de controle de gerenciamento de memória direcionado a uma imagem marcada como “usada para referência de longo termo” e “referência multivisão de longo termo temporária” é armazenada em memória temporária. Quando todas as imagens dentro de um eixo temporal são codificadas ou decodificadas, todas as imagens marcadas como “usada para referência de longo termo” e “referência multivisão de longo termo 20 temporária” não são mais marcadas como “usada para referência de longo termo” e “referência multivisão de longo termo temporária” e a marcação de imagem de referência é refeita para elas na sua ordem de decodificação usando tanto operações de janela deslizante como operações de controle de gerenciamento de memória temporária (sempre que aplicáveis a uma imagem particular). Por exemplo, se uma imagem é usada 25 para predição inter (por exemplo, o valor do nal_ref_idc é maior do que 0), ela é marcada de volta como “usada para referência de curto termo”. Se uma imagem não é usada para predição inter (por exemplo, o valor do nal_ref_idc é igual a 0), ela é marcada como “não usada para referência”. Usualmente, existem apenas duas possibilidades para uma imagem dentro de um eixo temporal: todas as imagens são imagens de referência para 30 predição inter, ou nenhuma imagem é referência para predição inter. Esta última operação pode ser realizada após a decodificação da última unidade NAL VCL dentro do eixo temporal, ou antes que a próxima unidade de acesso ou a próxima imagem no eixo temporal subsequente sejam decodificadas, No processo de decodificação, a operação neste estág io pode ser disparada implicitamente pela mudança no eixo temporal, ou isto 5 pode ser explicitamente sinalizado, por exemplo, como um comando MMCO. Com este método, as imagens de referência intervisão têm a mesma influência que as imagens de longo termo para predição balanceada e no modo temporal direto.

Um segundo método para a marcação de imagens com uma inter_view_reference_flag igual a 1 implica na marcação das imagens de referência 10 intervisão como “usada para referência intervisão”. Com este método, a marcação da imagem de referência para predição inter (marcação como “usada para referência de curto termo” ou “ usada como referência de longo termo”) não é alterada comparada com o padrão AVC. Para os processos relacionados com o modo temporal direto e predição ponderada, imagens marcadas como “usada para referência intervisão”, por exemplo,

aquelas imagens de referência intervisão que compartilham o mesmo eixo temporal com a imagem corrente são tratadas de forma idêntica as imagens de referência de longo termo. Quando todas as imagens dentro do eixo temporal são codificadas ou decodificadas, todas as imagens marcadas como “usada para referência intervisão” não são mais marcadas como “usada para referência intervisão”.

Deve ser notado que a remoção da marcação “usada para referência

intervisão ” após todas as imagens dentro do eixo temporal serem processadas é apenas uma modalidade da invenção. A marcação como “usada para referência intervisão” poderia também ser removida em outros instantes do processo de decodificação. Por exemplo, a marcação como “usada para referência intervisão” de uma imagem particular 25 pode ser removida tão logo a imagem corrente ou qualquer imagem subsequente não depender mais direta ou indiretamente da imagem de acordo com a sinalização de dependência da visão incluída na extensão MVC da SPS.

A operação de se ter as imagens apropriadas não mais sendo marcadas como “usada para referência intervisão” pode ser feita após a última unidade VCL NAL no eixo temporal ser codificada, ou antes que a próxma unidade de acesso ou a próxima imagem no eixo temporal subsequente sejam decodificadas. No processo de decodificação, a operação neste estágio pode ser disparada implicitamente pela mudança no eixo temporal, ou isto pode ser explicitamente sinalizado, por exemplo, como um comando MMCO.

5 Com este método particular, as imagens de referência intervisão têm a

mesma influência que as imagens de longo termo para predição balanceada e no modo temporal direto. Em outras palavras, este método tem o mesmo efeito que o primeiro método tratado previamente para predição ponderada e no modo temporal direto.

Neste método, um mecanismo de janela deslizante aperfeiçoado pode ser usado para remover a marcação de “usada para referência intervisão” das imagens usadas apenas para predição intervisão, por exemplo, para imagens que tem o nal_ref_idc igual a O e marcadas como “usada para referência intervisão”. Este mecanismo de janela deslizante aperfeiçoado usa uma variáv el, por exemplo, nomeada como num inter view ref frames, preferencialmente assinalada na extensão SPS para MVC, desta forma quando o número de imagens marcadas como “usad a para referência intervisão ” e tendo o nal_ref_idc igual a O é igual ao num_inter_view_ref_frames então a que foi decodificada primeiro torna-se não marcada como “usada para referência intervisão ”. Por conseqüência, se a imagem também não é necessária para saída (saída anteriormente ou intencionalmente não usada para saída), o decodificador pode recorrer a um processo para remover a imagem da DPB para que desta forma uma nova imagem decodificada possa ser armazenada na DPB.

Um terceiro método para a marcação de imagens com uma inter view reference flag igual a 0 implica em marcar as imagens após a decodificação de todas as imagens do mesmo eixo temporal/índice temporal. Ao invés de marcar uma 25 imagem imediatamente após sua decodificação, este método é baseado na idéia de que as imagens sejam marcadas após a decodificação de todas as imagens do mesmo eixo temporal (por exemplo, o mesmo índice temporal). Janela deslizante ou marcação de imagem de referência adaptativa como indicado em cada imagem codificada é realizada na ordem em que as imagens foram decodificadas. Para processos relacionados ao modo 30 temporal direto e predição ponderada, imagens marcadas do mesmo eixo temporal da imagem corrente são tratadas de forma idêntica as imagens de referência de longo termo. As imagens de referência intervisão do mesmo eixo temporal da imagem corrente são incluídas na construção da lista de imagens de referência inicial e podem ser reordenadas baseadas nos seus view id ou são inicialmente marcadas como índices de referência e 5 podem então ser re mapeadas baseado no índice de referência long term.

Como tratado previamente, dado um caminho para recalcular o PicNum, se o modo de operação de janela deslizante está em uso e o número de imagens de curto termo e longo termo é igual ao máximo, a imagem de referência de curto termo que tem o menor Frame Num Wrap é marcada como “não usada para referência”. Entretanto, devido ao fato de que esta imagem não é necessariamente a imagem codificada mais cedo porque a ordem de FrameNum na JMVM corrente não segue a ordem de decodificação, a marcação de imagem de referência pela janela deslizante não funciona de forma otimizada no JMVM corrente. Para enfrentar este problema, e comparando ao padrão JMVM, as variáveis FrameNum e FrameNum Wrap não são redefinidas/quantizadas, por exemplo, suas definições são mantidas sem mudanças comparadas ao padrão AVC. Faz parte do projeto a possibilidade de que as imagens de curto termo possam ser gerenciadas automaticamente pelo mecanismo primeiro a entrar/primeiro a sair de janela deslizante. Apenas uma leve modificação do mecanismo de janela deslizante comparado ao JMVM 1.0, é requerido. As modificações são como segue, com o novo texto representado em itál ico:

G. 8.2.5.3 Processo de marcação de imagem de referência decodificada janela deslizante Este processo é solicitado quando adaptive_ref_pic_marking_mode_flag é igual a 0.

Apenas as imagens de referência que tem o mesmo view Jd que a fatia corrente são consideradas no processo, incluindo o cálculo d o numShortTerm e numLong Term, e o valor aplicado de num_ref Jrames.

No método acima, o número total de quadros de referência para o fluxo de bits MVC inteiro, o qual indica o tamanho da memória temporá ria (buffer) para armazenamento de imagens usadas para referência intravisão ou intervisão de um fluxo de bits MVC inteiro, deveria ser igual à soma dos valores de numrefframes aplicados para todas as visões contidas no fluxo de bits MVC mais o número máximo de quadros de referência intervisão para decodificação do fluxo de bits MVC. Como alternativa, a janela deslizante pode ser executada globalmente para todas as imagens em todas as visões.

Para codificação com prioridade em tempo, o processo de janela deslizante 5 é definido como a seguir, com o novo texto para o JMVM 1.0 representado em itálico:

Quando numShortTerm + numLongTerm é igual a Max( num ref frames, 1), a condição de que numShortTerm é maior do que 0 deveria ser preenchida, e o quadro de referência de curto termo, campo emparelhado de referência complementar ou campo não emparelhado de referência que é selecionado pela seguinte 10 regra é marcado como “não usado para referência”. Quando este é um quadro ou um campo emparelhado complementar, ambos estes campos são também marcados como “não usado para refer ência”.

* A regra de seleção é: de todas aquelas imagens da visão mais cedo decodificada, aquela com o menor FrameNumWrap é selecionada. A ordem de decodificação da visão pode ser indicada pelo valor de Vieyvjd, ou a informação de dependência da visão si nalizado no SPS da extensão MVC.

Como tratado previamente, devido ao fato de que PicNum é derivado do FrameNumWrap redefinido e quantizado, a diferença entre os valores de PicNum de duas imagens codificadas poderia ser quantizado em média. Por exemplo, é útil assumir em se 20 tendo duas imagens na mesma visão tendo frame_num iguais a 3 e 5 respectivamente. Quando há apenas uma visão, por exemplo quando o fluxo de bits é um fluxo AVC, então a diferença dos dois valores de PicNum seria 2. Quando codificando a imagem cujo framenum é igual a 5, se um comando MMCO é requerido para marcar a imagem cujo PicNum é igual a 3 como “não usada como referência”, então a diferença dos dois 25 valores menos 1 é igual a 1, o que é sinalizado dentro do MMCO. Este valor precisa de 3 bits. Entretanto, se existirem 256 visões, então a diferença dos dois valores de PicNum menos 1 seria 511, Neste caso, são necessários 19 bits para sinalizar o valor. Por conseqüência, os comandos MMCO são codificados de forma muito menos eficaz. Tipicamente, o acréscimo no número de bits é igual a 2*log2(número de visões) para um comando MMCO na JMVM corrente comparado a codificação de visão simples da

H.264/AVC.

Para enfrentar este problema e em contraste ao padrão JMVM, as variáveis FrameNum e FrameNumWrap não são redefinidas/quantizadas o que é o 5 mesmo como no padrão AVC. Na maioria dos casos, pelo ponto de vista do tamanho da DPB, não é requerido que uma imagem contendo um comando MMCO remova uma imagem a qual não pertence à mesma visão nem tampouco ao mesmo eixo temporal da imagem corrente. Eventualmente algumas das imagens se tornam não mais necessárias para referência e nestes casos podem ser marcadas como “não usada para referência”.

Neste caso, a marcação pode ser realizada pelo uso do processo de janela deslizante ou ser postergado até a prexima imagem codificada com o mesmo view id. Desta forma, os comandos MMCO ficam restritos a marcar como “não usada para referência” apenas imagens pertencentes à mesma visão ou ao mesmo eixo temporal , ainda que a DPB possa conter imagens de visões diferentes ou eixos temporais diferentes.

A modificação na JMVM 1.0 para a marcação de imagem de referência

intravisão se dá como a seguir, com as mudanças apresentadas em itálic o:

G. 8.2.5.4.1 Processo de marcação de imagem de referência de curto termo como “não usada para referência”

Este processo é solicitado quando adaptie_ref_pic_marking_mode_flag é igual a 1.

Apenas as imagens de referência que tem o mesmo view id da fatia corrente são consideradas no processo.

A sintaxe e semântica para a marcação de imagem de referência interview

pode ser como segue:

slice_header() { C Descritor Se ( nal ref ide ! = 0 ) dec_ref_pic_marking() 2 Se (inter view reference flag) dec view ref_pic marking mvc() 2 } dec view ref_pic marking mvc() { C Descritor adaptive view ref_pic mrking mode flag 2 u(l) Se ( adaptive_view_ref_pic_marking mode flag) fazer { view_memory_management_control operation 2 ue(v) Se (viewmemorymanagement control operation = = 1 viewmemorymanagement control operation = = 2) abs_difference_of_view_id_minusl 2 ue(v) } while(view_memory_management_control_operation !=0) } } Operação de controle de ger enciamento de memória

valores de (view memory management control o jeration) como segue view memory management control operation Operação de Controle de Gerenciamento de Memória 0 Termina o laço view_memory_management_control_operation 1 Remove a marcação de “usada para referência intervisão” ou marca uma imagem como “não usada como referência”, abs difference of view id minusl está presente e corresponde a diferença a subtrair da view_id corrente 2 Remove a marcação de “usada para referência intervisão” ou marca uma imagem como “não usada como referência”, abs_difference_of_view_id_minus 1 está presente e corresponde a diferença a somar a view id corrente A adaptive_view_ref_pic_marking_mode_flag especifica quando o mecanismo de janela deslizante (quando igual a 0) ou processo de marcação de imagem de referência adaptativo (quando igual a 1) são usados.

O processo de decodificação modificado para a marcação de imagem de referência intervisão é como segue:

8.2.5.5.2 Marcação de imagens intervisão Este processo é chamado quando view_memory_management_control_operation é igual a

1.

Permita-se viewIDX ser especificado como segue.

se(view_memory_management_control_operation=1)

viewIDX = CurrViewId - ( difference_of_view_id_minusl + 1 ) ou então se (view_memory_management_control_operation=2)

viewIDX = CurrViewId + (difference_of_view_id_minus 1 + 1 )

Para permitir a escalabilidade, por exemplo, a possibilidade de escolher 15 quais visões são transmitidas, enviadas ou decodificadas, as operações de controle de gerenciamento de memcria podem ser restritas como segue. Se currTemporalLevel for igual a temporal_level da imagem corrente e dependentView for um conjunto de visões que depende da visão corrente, um comando MMCO pode apenas ser direcionado para uma imagem que tenha um temporal level igual a ou maior do que currTemporalLevel e 20 esteja dentro de dependentViews. Para permitir isto, os comandos MMCO são anexados com uma indicação da view id ou são especificados novos comandos MMCO com uma indicação da view_id.

Com o objetivo de enfrentar os problemas relativos ao processo de construção da lista de imagens de referência, descritos anteriormente, as variáveis 25 FrameNum e FrameNumWrap não são redefinidas/quantizadas. Esta mesma ação ocorre como no padrão AVC e contrasta com padrão JMVM, onde as variáveis são redefinidas/quantizadas. A modificação no JMVM 1.0 é como segue, com as alterações apresentadas em itálico:

Em 8.2.4.3.1 Processo de reordenação das listas de imagens de referência para imagens de referência de curto termo, o 8-38 deveria ser mudado para: Para ( cldx = num_ref_idx_IX_active_minusl + 1; cldx > refldxLX; cldx- ) RefPicListXf cldx ] = RefPicListX[ cldx - 1]

ReiPicListX [ refldxLX + + ] = imagem de referência de curto termo com PicNum igual a picNumLX e view id igual a CurrViewID nldx = refldxLX

para (cldx = refldxLX; cldx < = num_ref_idx_IX_active_minus 1 + 1; cldx+ + ) (8- 38)

//if( PicNumF(RefPicListX[ cldx J ) ! = picNumLX )

//if( PicNumF(RefPicListX[ cldx J ) ! = picNumLX \ \ ViewID (RefPicListX[ cldx J)

/ = CurrViewlD)

RefPicListX [ nldx + + ] = RefPicListX [ cldx ]

Onde CurrViewID é o view id da imagem de decodificação corrente.

Com relação aos problemas associados ao processo de inicialização da lista de Imagens de referência tratados previamente, estes problemas podem ser enfrentados se 15 notarmos que apenas quadros, campos ou pares de campos pertencentes à mesma visão da fatia corrente podem ser adicionados ao início de cada uma das subcláusulas 8.2.4.2.1 “Processo de inicialização para lista de imagens de referência para fatias P e SP em quadros” até 8.2.4.2.5 “Processo de inicialização para listas de imagens de referência em campos”.

Com relação aos outros problemas relacionados ao processo de construção

da lista de imagens de referência, uma quantidade de métodos pode ser usada pra reordenar de forma eficaz tanto as imagens intervisão como as imagens usadas para predição intra. O primeiro destes métodos compreende colocar as imagens de referência inter visão na frente das imagens de referência intravisão na lista, como também 25 especificar processos RPLR separados para imagens inter visão e imagens para predição intravisão. As imagens usadas para predição intravisão também são referenciadas como imagens intravisão. Neste método, o processo de inicialização da lista de imagens de referência para imagens intravisão tal como especificado acima é executado, seguido pelo processo de reordenação RPLR e o processo de truncamento da lista para as imagens 30 intravisão. A seguir, as imagens intervisão são anexadas a lista após as imagens intravisão. Finalmente, cada imagem intervisão pode ser selecionada adiante e colocada em uma entrada especificada da lista de imagens de referência usando a seguinte sintaxe, semântica e processo de decodificação, modificados a partir da JMVM 1.0. O método é aplicável tanto a refPic ListO como a refPicLIstl, quando presentes.

ref_pic_list_reordering() { C Descriptor Se (slice_type ! = I && slice type ! = SI) { } Se (svc mvc flag) { view_ref_pic Iist reordering flag 10 2 u(l) Se (view_ref_pic_list_reordering_flag_10) fazer { view_reorderind ide 2 ue(v) Se ( view_reorderind ide = = 0 | | viewreorderindidc = = 1) abs_diff_view idx minusl 2 ue(v) ref idx 2 ue(v) } enquanto ( view_reorderind_idc! = 2 ) view_ref_pic_list_reordering_flag_ll 2 u(l) Se (view ref_pic Iist reordering flag 11) fazer { view reorderind ide 2 ue(v) Se ( view_reorderind_idc = = 0 | | viewreorderindidc = = 1 ) abs diff view idx minusl 2 ue(v) ref idx 2 ue(v) } enquanto ( view_reorderind_idc! = 2 ) } Com relação a sintaxe, uma view_ref_pic_list_reordering_flagIX (X é 0 ou 1) igual a 1 especifica que o elemento sintático view_reordering_idc está presente para refPicListX. Uma view_ref_pic_list_reordering_flagIX igual a O especifica que o elemento sintá tico view reordering idc não está presente para refPicListX. O refidx indica a 5 entrada que deve ser atribuída a imagem inter visão na lista de imagens de referência.

O abs diff view idx minus 1 mais 1 especifica a diferença absoluta entre o índice da visão da imagem para atribuir a entrada na lista de imagens de referência indicado pelo refidx e o valor de predição do índice de visão. O abs diff view idx minusl está na faixa de O a num_multiview_refs_for_listX[view_id]- I. O num_multiview_refs_for_listX[ ] refere-se a

anchor_reference_view_for_list_X[curr_view_id][ ] para uma imagem âncora e non_anchor_reference_view_for_list_X[curr_view_id][ ] para uma imagem que não é âncora,onde o curr_view_id é igual ao view_id da visão que contém a fatia corrente. Um índice de visão de uma imagem intervisão indica a ordem de view_id da imagem 15 intervisão contida na extensão SPS do MVC. Para uma imagem com o índice de visão igual ao viewindex, o viewindex é igual a num_multiview_refs_for_listX[view_index].

O abs_diff_view_idx_minusl mais 1 especifica a diferença absoluta entre o índice da visão da imagem sendo movida para o índice corrente da lista e o valor de predição do índice de visão. O abs_diff_view_idx_minusl está na faixa de 0 a 20 num_multiview_refs_for_listX[view_id]- I. O num_multiview_refs_for_listX[ ] refere-se a anchor_reference_view_for_list_X[curr_view_id][ ] para uma imagem âncora e non_anchor_reference_view_for_list_X[curr_view_id][ ] para uma imagem que não é âncora, onde o curr view id é igual ao view_id da visão que contém a fatia corrente. Um índice de visão de uma imagem intervisão indica a ordem de view_id da imagem 25 intervisão contida na extensão SPS do MVC. Para uma imagem com o índice de visão igual ao view index, o view_index é igual a num_multiview_refs_for_listX[view_index].

O processo de decodificação é tal como a seguir:

A definição do NumRefldxLXActive é feita após o truncamento para as imagens intravisão: NumRefIdxLXActive = num_ref_idx_IX_active_minusl + I + num_multiview_refs_for_listX[view_id]

G.8.2.4.3.3 Processo de reordenação das listas de imagens de referência para imagens inter visão

As entradas para este processo são a lista de imagens de referência

RefPicListX (sendo ο X igual a 0 ou I). As saídas deste processo são um lista de imagens de referência possivelmente modificada RefPicListX (sendo X igual a 0 ou 1).

A variável picViewIdxL X é derivada como a seguir:

Se view reordering idc é igual a 0 picViewIdxLX = pic ViewIdxLXPred - (abs_diff_view_idx_minus 1 + 1 )

De outra forma (view reordering idc é igual a 1),

pic_ViewIdxLX = pic ViewIdxLXPred + ( abs_diff_view_idx_minus 1 + 1 )

O picViewIdxLX Pred é o valor de predição para a variável pic ViewIdxLX. Quando o processo especificado nesta subclausula é solicitado pela 15 primeira vez para uma fatia (ou seja, para a primeira ocorrência de view reordering idc igual a 0 ou 1 na sintaxe refjpic_list_reordering()), picViewIdxPred e picViewIdxLIPred são inicializadas com o valor 0. Após cada atribuição a picViewIdxLX, o valor de picViewIdxLX é atribuído a picViewIdxLXPred.

O procedimento descrito a seguir é realizado para colocar a imagem inter visão com o índice de visão igual a picViewIdxLX dentro da posição do índice ref idx e deslocar a posição de alguma outra imagem remanescente para trás na lista, como a seguir.

for( cldx = NumRefIdxLXActive; cldx > ref idx; cldx- )

RefPicListX[ cldx ] = RefPicListX[ cldx - 1 ]

RefPicListX[ref_idx] = imagem de referência inter visão com view id igual a

reference_view_for_list_X[picViewIdxLX]

nldx = ref_idx+l;

for( cldx = refldxLX; cldx < = NumRefIdxLXActive; cldx + + ) if( ViewID(refPicListX[ cldx } ) != TargetViewID j | Time(refPicListX[ cldx ])! =TargetTime)

RefPicListX[ nldx + + ] = RefPicListX[ cldx ] preV iewid=PicV iewIDLX 5 O TargetViewID e o TargetTime indicam o valor de view_id ou do eixo temporal da imagem de referência selecionada para ser reordenada, e Time(pic) retorna o valor do eixo temporal da imagem pic.

De acordo com o segundo método para reordenar de forma eficaz tanto as imagens de inter visão como as imagens usadas para predição intra, o processo de 10 inicialização da lista de imagens de referência para imagens intravisão como especificado acima é executado, e então as imagens intervisão são anexadas ao final da lista na ordem em que elas aparecem na extensão SPS do MVC. Subsequentemente, um processo de reordenação RPLR para ambas as imagens intravisão e inter visão á aplicado, seguido por um processo de truncamento da lista. Amostras de sintaxe, semânt ica e processo de 15 decodificação, modificados com base no JMVM 1.0, são apresentados a seguir.

Sintaxe da reordenação da lista de imagens de referência

ref_pic_list_reordering() { C Descriptor se (slice type ! = I && slice type ! = SI) { ref_pic_list_reordering_flag 10 2 u(l) if(ref_pic_list reordering flag 10 ) do { reordering_of_pic_nums_idc 2 ue(v) if(reordering_of_pic_nums_idc = = 0 | | reordering of_pic_nums_idc = = 1 ) abs_diff_pic_num_minus 1 2 ue(v) else if(reordering_of_pic_nums_idc = = 2 ) Iong _term_pic_num_minus 1 2 ue(v) if(reordering_of_pic_nums_idc = = 4 | | reordering_of_pic_nums_idc = = 5 ) abs diff_pic num minusl 2 ue(v) } while( reordering_of_pic_nums_idc ! = 3 ) } if(slice_type = = B | | slice type = = EB ) { ref_pic_list_reordering_flag_l 1 2 u(l) if(refjpic_list_reordering_flag_l 1 ) do { reordering_of_pic nums_idc 2 ue(v) if(reordering_of_pic_nums_idc = = 0 | | reordering_of_pic_nums_idc = = 1) absdiffjicnumminus 1 2 ue(v) else if(reordering_of_pic_nums_idc ---= 2) Iong term_pic num minusl 2 ue(v) if(reordering_of_pic_nums_idc = = 4 | | reordering_of_pic_nums_idc = = 5 ) abs_diff_pic_num_minus 1 2 ue(v) } while( reordering_of_pic_nums ide ! = 3 ) } } G 7.4.3.1 Semântica da reordenação da lista de imagens de referência

Tabela

Operações Reordering_of_pic_nums_idc para reordenação das listas de i magens de referência

reordering of pic nums ide Reordenação esp ecificada O abs_diff_pic_num_minusl está presente e corresponde à diferença a subtrair de um valor de predição de número de imagem 1 abs_diff_pic_num_minusl está presente e corresponde à diferença a somar a um valor de predição de número de imagem 2 Iong term_pic num está presente e espe cifica o número de imagem de longo termo para uma imagem de referência 3 Final de laço para reordenação da lista de imagens de referência inicial 4 absdiffviewminusl está presente e corresponde à diferença a subtrair de um valor de predição de índice de visão abs_diff_view_minusl está presente e corresponde à diferença a somar a um valor de predição de índice de visão O reordering_of_pic_nums_idc, juntamente com

abs_diff_pic_num_minusl ou long_term_pic_num, especifica quais das imagens de referência são remapeadas. O reordering_of_pic_nums_idc, juntamente com abs_diff_pic_num_minusl ou abs_diff_view_idx_minus 1, especifica quais das imagens de referência intervisão são remapeadas. Os valores da reordering_ofPic_nums_idc são especificados na tabela acima. O valor da primeira reordering_of_pic_nums_idc que vem imediatamente após ref_pic_list_reordering_flag_10 ou ref_jnc_list_reordering_flag_ll não é igual a 3.

O abs diff view idx minusl mais 1 especifica a diferença absoluta entre o índice da visão da imagem para atribuir ao índice corrente na lista de imagens de referência e o valor de predição do índice de visão. O abs_diff_view_idx_minusl está na faixa de 0 a num_multiview_refs_for_listX[view_id] - I. O num_multiview_refs_for_listX[ ] refere-se a

anchor_reference_view_for_list_X[curr_view_id][ ] para uma imagem âncora e non_anchor_reference_view_for_list_X[curr_view_id][ ] para uma imagem que não é âncora, onde o curr view id é igual ao view id da visão que contém a fatia corrente. Um índice de visão de uma imagem intervisão indica a ordem da view id da imagem intervisão contida na extensão SPS do MVC. Para uma imagem com o índice de visão igual ao view index, o view id é igual ao num_multiview_refs_for_listX[view_index]. O processo de reordenação pode ser descrito como a seguir.

G.8.2.4.3.3 Processo de reordenação de listas de imagens de referência para imagens de referência inter visão

A entrada para este processo é um índice re fldxLX (sendo X igual a 0 ou 1).

A saída deste processo é um índice incrementado refldxLX.

A variável picViewIdxL X é derivada como a seguir.

Se reordering_of_pic_nums_idc é igual a 4

picViewIdxLX = picViewIdxLXPred - ( abs_diff_view_idx_minus 1 +1)

De outra forma ( reordering_of_pic_nums_idc é igual a 5),

picViewIdxLX = picViewIdxLXPred + ( abs diff view idx minusl +1)

picViewIdxLXPred é o valor de predição para a variável picViewIdxLX. Quando o processo especificado nesta subcláus ula é solicitado pela primeira vez para uma fatia (ou seja, para a primeira ocorrência de reordering_pic_nums_idc igual a 4 ou 5 na sintaxe ref_pic_list_reordering()), pic ViewIdxLOPred e picViewIdxL IPred são 15 inicializados com o valor 0. Após cada atribuição de picViewIdxLX, o valor de picViewIdxLX é atribuído a picViewIdxLXPred.

O procedimento descrito a seguir é realizado para colocar a imagem inter visão com o índice de visão igual a picViewIdxLX dentro da posição de índice refldxLX, deslocar a posição de alguma outra imagem remanescente para trás na lista e incrementar o valor de refldxLX.

for(cIdx = num ref idx lX active minusl + 1; cldx > refldxLX; cldx- )

RefPicListX[ cldx ] = RefPicListX[ cldx - 1 ]

RefPicListX[ refldxLX + + ] = imagem inter visão com view id igual a

reference_view_for_list_X[picViewIdxLX]

nldx = refldxLX

para (c Idx = refldxLX; cldx < = num_ref_idx_IX_active_minus 1 +1, cldx + + )

if( ViewID(RefPicListX[ cldx ]) ! = TargetViewID | | Time(RefPicListX[ cldx ])! = TargetTime)

RefPicList[ nldx + + ] = RefPicList[ cldx ] Onde TargetViewID e TargetTime indicam o view_id ou o valor do eixo temporal da imagem de referência selecionada para ser reordenada, e Time(pic) retorna o valor do eixo temporal da imagem pic.

De acordo com um terceiro método para reordenar de forma eficaz tanto as imagens inter visão como imagens usadas para predição intra, a lista de imagens de referencia inicial contém imagens marcadas como “usada como referência de curto termo” ou “usada como referência de longo termo” e tendo o mesmo view id da imagem corrente. Adicionalmente, a lista de imagens de referência inicial contém as imagens que podem ser usadas para predição inter visão. As imagens usadas para a predição intervisão são inferidas a partir da extensão do conjunto de parâmetros de seqüência para o MVC e também podem ser inferidas a partir da inter view reference flag. Para a decodificação das imagens usadas para previsão inter visão, lhes são atribuídos certos índices de referência de longo termo. Os índices de referência de longo termo atribuídos para as imagens de referência intervisão podem, por exemplo, ser os primeiros N índices de referência, e os índices para imagens de longo termo intravisão podem ser modificados para se igualarem ao seu valor prévio + N para o processo de decodificação destas imagens, onde N representa o número de imagens de referência inter visão. Alternativamente, os índices de referência de longo termo atribuídos podem estar na faixa de MaxLongTermrameIdx + Ia MaxLongTermFrameIdx +N, inclusive. Alternativamente, a extensão do conjunto de parâmetros de seqüência para o MVC pode conter um elemento sintático, aqui referenciado como startltindexforrplr, e os índices de longo termo atribuídos alocam a faixa start_lt_index_for_rplr, inclusive, até start lt index for rplr + N, exclusive. Os índices de longo termo disponíveis para imagens de referência intervisão podem ser alocados na ordem de view id, ordem de câmera, ou na ordem em que as dependências de visão são listadas dentro da extensão do conjunto de parâmetro s de seqüência para o MVC. Os comandos RPLR (sintaxe e semântica) perman ecem inalterados comparados ao padrão H.264/AVC.

Para processamento relacionado diretamente ao tempo, por exemplo, para quantização vetorial do movimento, se ambas as imagens de predição são imagens de predição inter (predição intravisão) (por exemplo, as imagens de referência que não estão marcadas como “ usadas para referência inter visão”), então é seguido o processo de decodificação AVC. Se uma das duas imagens de referência é uma imagem de predição inter e a outra é uma imagem de predição inter visão, a imagem de predição intervisão é tratada como imagem de referência de longo termo. De outra forma (se 5 ambas as imagens são imagens inter visão), os valores de view_id ou do indicador de ordem de câmera são usados ao invés dos valores POC para quantização vetorial do movimento.

Para a derivação dos pesos da predição para a predição ponderada, o processo descrito a seguir é realizado. Se ambas as imagens de predição são imagens de 10 predição inter (predição intravisão) (por exemplo, as imagens de referência que não estão marcadas como “ usadas para referência inter visão”), então é seguido o processo de decodificação AVC. Se uma das duas imagens de referência é uma imagem de predição inter e a outra é uma imagem de predição inter visão, a imagem de predição intervisão é tratada como imagem de referência de longo termo. De outra forma (se 15 ambas as imagens são imagens inter visão), os valores de view id ou do indicador de ordem de câmera são usados ao invés dos valores POC para derivação dos parâmetros de predição ponderada.

A presente invenção é descrita etapa a etapa em seu contexto geral, o que pode ser implementado em uma modalidade por um produto de programa incluindo instruções executáveis em computador, tal como um códig) de programa, contido em uma mídia legível por computador e executado por computadores dentro de ambientes de rede. Exemplos de mídias legíveis por computador podem incluir, mas não estão limitadas a, dispositivos eletrônicos de unidades de memóri^ memória de acesso randômico (RAM), memória não gravável (ROM), discos compactos (CDs), discos digitais versáteis (DVDs) e outros dispositivos de armazenamento internos ou externos. Geralmente, módulos de programas incluem rotinas, programas, objetos, componentes, estruturas de dados, etc. os quais realizam tarefas particulares ou implementam tipos de dados abstratos particulares. Instruções executáveis em computador, associadas a estruturas de dados, e módulos de programa representam exemplos do código de programa para a execução das etapas dos métodos discutidos aqui. A seqüência particular destas instruções executáveis ou estruturas de dados associadas representam exemplos de ações para a implementação das funções descritas nestas etapas.

Software e implementações web da presente invenção poderiam ser obtidas com técnicas de programação padrão, com lógica baseada em regras e outras lógicas para 5 obter as várias etapas de pesquisa em bases de dados, etapas de correlação, etapas de comparação e etapas de decisão. Também deveria ser notado que as palavras “componente” e “módulo” como usadas aqui e nas reivindicações pretendem compreender implementações usando uma ou mais linhas de códgo de software, e/ou implementações de hardware, e/ou equipamentos para recepção de entradas manuais.

As descrições precedentes das modalidades da presente invenção foram

apresentadas com o propósit) de ilustração e descrição. Não se pretendeu ser exaustivo, ou limitar a presente invenção de forma precisa ao formato exposto, e modificações e variações são possíveis à luz das instruções acima ou podem ser obtidas pela prá tica da presente invenção. As modalidades foram escolhidas e descritas com o objetivo de 15 explicar os princípio s da presente invenção e sua aplicação prá tica para permitir a alguém conhecedor da técnica, utilizar a presente invenção em várias modalidades e com várias modificações que as adapte m ao uso particular contemplado.

Claims

1. Método para codificar uma pluralidade de visões de uma cena, sendo que o método é CARACTERIZADO pelo fato de que compreende: fornecer um elemento sinalizador correspondente a uma imagem de uma 5 visão, em que o elemento sinalizador é usado para representar se a imagem da visão é usada como referência para qualquer outra imagem pertencente a uma visão diferente.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o elemento sinalizador é um campo de alerta e é assinalado em um cabeçalho da unidade de camada de abstração de rede (NAL) correspondente à imag em.

3. Método de decodificação de uma seqüência de bits de vídeo codificada, a qual é uma representação codificada de uma pluralidade de visões de uma cena, sendo que o método é CARACTERIZADO pelo fato de que compreende: recuperar um elemento sinalizador correspondente a uma imagem de uma visão proveniente da seqüência de bits de vídeo codificada, em que o elemento sinalizador representa se a imagem correspondente à visão é usada como referência para alguma outra imagem pertencente a uma visão diferente.

4. Método, de acordo com a reivindicação 3, em que o método é adicionalmente CARACTERIZADO pelo fato de que compreende: caso o elemento sinalizador indique que a imagem da visão não é utilizada como referência por alguma outra imagem pertencente a uma visão diferente, a omissão da transmissão de uma p arte de seqüência de bits codificada que corresponde à imagem .

5. Método, de acordo com a reivindicação 3, em que o método é adicionalmente CARACTERIZADO pelo fato de que compreende: caso o elemento sinalizador indique que a imagem da visão não é utilizada como referência por alguma outra imagem pertencente a uma visão diferente, a omissão de uma parte da seqüência de bits codificada que corresponde à imagem.

6. Método, de acordo com a reivindicação 3, CARACTERIZADO pelo fato de que o elemento sinalizador é um campo de alerta e é recuperado a partir de um cabeçalho da unidade de camada de abstração de rede (NAL) correspondente à imagem.

7. Aparelho, CARACTERIZADO pelo fato de que compreende: um processador; e uma unidade de memória conectada ao processador permitindo a comunicação, sendo que o aparelho é configurado para fornecer um elemento sinalizador correspondente a uma imagem de uma visão, em que o elemento sinalizador é usado para representar se a imagem da visão associada é usada ou não como referência para qualquer outra imagem pertencente a uma visão diferente.

8. Aparelho, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que o elemento sinalizador é um campo de alerta e é sinalizado em um cabeçalho da unidade de camada de abstração de rede (NAL) correspondente à imag em.

9. Aparelho, CARACTERIZADO pelo fato de que compreende: um processador; e uma unidade de memória conectada ao processador permitindo a comunicação, sendo que o aparelho é configurado para recuperar um elemento sinalizador correspondente a uma imagem de uma visão proveniente da seqüência de bits de vídeo codificada, em que o elemento sinalizador é usado para representar se a imagem da visão associada é usada como referência para alguma outra imagem pertencente a uma visão diferente.

10. Aparelho, de acordo com a reivindicação 9, em que o aparelho é adicionalmente CARACTERIZADO por ser configurado para: omitir a transmissão de uma parte da seqüência de bits codificada que corresponde à imagem, caso o elemento sinalizador indique que a imagem da visão não é utilizada como referência para alguma outra imagem pertencente a uma visão diferente.

11. Aparelho, de acordo com a reivindicação 9, em que o aparelho é adicionalmente CARACTERIZADO por ser configurado para: omitir a decodificação de uma parte da seqüência de bits codificada que corresponde à imagem, caso o elemento sinalizador indique que a imagem da visão não é utilizada como referência para alguma outra imagem pertencente a uma visão diferente,

12. Aparelho, de acordo com a reivindicação 9, CARACTERIZADO pelo fato de que o elemento sinalizador é um campo de alerta e é recuperado de um cabeçalho da unidade de camada de abstração de rede (NAL) correspondente à imag em.

13. Método de codificação de uma pluralidade de visões de uma cena, sendo que o método é CARACTERIZADO pelo fato de que compreende: interpretar uma lista de referência inicial de imagens, com base ao menos em parte, em imagens com referências a intra-visão e imagens com referências a inter- visão, fornecer um elemento sinalizador para reordenar as imagens com referências a inter-visão com relação à lista inicial de imagens de referência, em que o elemento sinalizador é ao menos em parte derivado com base em um valor identificador da visão.

14. Método, de acordo com a reivindicação 13, CARACTERIZADO pelo fato de que o elemento sinalizador representa uma diferença entre o índice da visão da imagem para atribuir ao índice atual na lista de referência de imagens e um valor de índice da visão de predi ção.

15. Método de decodificação de uma seqüência de bits de vídeo codificada, a qual é uma representação codificada de uma pluralidade de visões de uma cena, sendo que o método é CARACTERIZADO pelo fato de que compreende: interpretar uma lista de referência inicial de imagens baseada ao menos em parte em imagens com referências a intra-visão e imagens com referências a inter-visão, reordenar as imagens com referências a inter-visão, com relação à lista inicial de imagens de referência com base ao menos em parte em uma sinalização recuperada a partir do elemento da seqüência de bits codificada e em um valor de identificação da visão.

16. Método, de acordo com a reivindicação 15, CARACTERIZADO pelo fato de que o elemento sinalizador representa uma diferença entre o índice de visão da imagem para atribuir ao índice atual na lista de referência de imagens e um valor de índice da visão de predi ção.

17. Aparelho CARACTERIZADO pelo fato de que compreende: um processador e; uma unidade de memória conectada ao processador permitindo a comunicação, sendo que o aparelho é configurado para: interpretar uma lista de referência inicial de imagens com base ao menos em parte em imagens com referências a intra-visão e imagens com referências a inter-visão, e fornecer um elemento de sinalização para a reordenação das imagens com referências a inter-visão, com relação à lista inicial de referência de imagens, sendo o elemento sinalizador derivado com base ao menos em parte em um valor de identificação da visão.

18. Aparelho, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de que o elemento sinalizador representa a diferença entre o í ndice da visão da imagem para atribuir ao índice atual na lista de referência de imagens e um valor de índice da visão de predi ção.

19. Aparelho CARACTERIZADO pelo fato de que compreende: um processador; e uma unidade de memória conectada ao processador permitindo comunicação, sendo que o aparelho é configurado para: interpretar uma lista de referência inicial de imagens com base, ao menos, em parte, em imagens com referências a intra-visão e imagens com referências a inter- visão, e reordenar as imagens com referências a inter-visão, com relação à lista inicial de imagens de referência, com base, ao menos, em parte, em uma sinalização recuperada do elemento da seqüência de bits codificada e em um valor de identificação da visão.

20. Aparelho, de acordo com a reivindicação 19, CARACTERIZADO pelo fato de que o elemento sinalizador representa uma diferença entre o índice da visão da imagem para atribuir ao índice atual na lista de referência de imagens e um valor de índice da visão de predi ção.

21. Produto de programa de computador, contido em uma mídia legível por computador, para a decodificação de uma seqüência de bits de vídeo codificada, a qual é uma representação codificada de uma pluralidade de sinais de cena que representam uma pluralidade de visões de uma cena, CARACTERIZADO pelo fato de que compreende: um código computacional para interpretar uma lista de referência inicial de imagens com base, ao menos, em parte, em imagens com referências a intra-visão e imagens com referências a inter-visão, um código computacional para reordenar as imagens com referências a inter-visão, com relação à lista inicial de imagens de referência, com base ao menos em parte, em uma sinalização recuperada do elemento da seqüência de bits codificada e em um valor de identificação da visão.

22. Produto programa de computador, de acordo com a reivindicação 21, CARACTERIZADO pelo fato de que o elemento sinalizador representa uma diferença 10 entre o índice da visão da imagem para atribuir ao índice atual na lista de referência de imagens e um valor de índice da visão de predição.

23. Produto de programa de computador, contido em uma mídia legível por computador, para a decodificação de uma seqüência de bits de vídeo codificada, a qual é uma representação codificada de uma pluralidade de visões de uma cena, 15 CARACTERIZADO pelo fato de que compreende: um código computacional para recuperar um elemento sinalizador correspondente a uma imagem de uma visão proveniente da seqüência de bits de vídeo codificada, em que o elemento sinalizador representa se a imagem da visão associada é usada como referência para alguma outra imagem pertencente a uma visão diferente.

24. Produto de programa de computador, de acordo com a reivindicação 23, adicionalmente CARACTERIZADO pelo fato de que compreende: um código computacional para omitir a transmissão de uma parte da seqüência de bits codificada que corresponde à imagem caso o elemento sinalizador indique que a imagem da visão não é utilizada como referência para alguma outra imagem pertencente a uma visão diferente.

25. Produto programa de computador, de acordo com a reivindicação 23, adicionalmente CARACTERIZADO pelo fato de que compreende: um código computacional para omitir a decodificação de uma parte da seqüência de bits codificada que corresponde à imagem caso o elemento sinalizador indique que a imagem da visão não é utilizada como uma referência para alguma outra imagem pertencente a uma visão diferente.

26. Produto de programa de computador, de acordo com a reivindicação 23, CARACTERIZADO pelo fato de que o elemento sinalizador é um campo de alerta e é recuperado a partir de um cabeçalho da unidade de camada de abstração de rede (NAL) correspondente à imagem.