BRPI1013146B1

BRPI1013146B1 - Método para enviar dados de vídeo possuindo uma pluralidade de vistas de acordo com o padrão de codificação multivista em um fluxo de bits mpeg-2, equipamento para gerar dados de vídeo multivista de acordo com um padrão de codificação multivista e memória legível por computador

Info

Publication number: BRPI1013146B1
Application number: BRPI1013146-9A
Authority: BR
Inventors: Ying-Chen; Marta Karczewicz
Original assignee: Qualcomm Incorporated
Priority date: 2009-06-12
Filing date: 2010-06-11
Publication date: 2021-09-28

Abstract

CODIFICAÇÃO DE VÍDEO MULTIVISTA ATRAVÉS DE SISTEMAS MPEG-2 Um multiplexador pode produzir uma corrente de bits padrão do sistema MPEG-2 (Motion Picture Experts Group - Grupo de Especialistas em Películas Cinematográficas) compre-endendo vistas com índices de ordem de vistas não consecutivos. Como exemplo, um equipamento compreende um codifica-dor de vídeo que codifica uma pluralidade de quadros de uma cena, um multiplexador que monta uma estrutura de dados para sinalizar que uma correspondente corrente de bits (bitstream) padrão do sistema MPEG-2 (Motion Picture Experts Group - Grupo de Especialistas em Películas Cinematográficas) compre-ende uma primeira vista dentre a pluralidade de vistas da cena associada a um primeiro índice de ordem de vistas e uma segunda vista dentre à pluralidade de vistas da cena associada a um segundo índice de ordem de vistas, em que o primeiro índice de ordem de vistas e o segundo índice de ordem de vistas não são consecutivos, e uma interface que emite a estrutura de dados.

Description

Pedidos Correlacionados

[0001] O presente pedido de patente reivindica a prioridade dos Pedidos Provisórios de Patente U.S. Nos de Série 61/221 449, depositado em 29 de junho de 2009, e 61/186 613, depositado em 12 de junho de 2009, a totalidade de ambos sendo aqui expressamente incorporada pela presente referência.

Referência Cruzada a Pedidos Correlacionados

[0002] O presente pedido de patente está relacionado ao Pedido Co-pendente de Patente U.S. intitulado “ASSEMBLING MULTIVIEW VÍDEO CODING SUB BITSTREAMS IN MPEG-2 SYSTEMS”, em nome de Ying Chen, referência do agente No 092652, depositado junto a este, em nome da Requerente do presente e expressamente aqui incorporado pela presente referência.

Campo Técnico

[0003] A presente invenção está relacionada ao transporte de dados de vídeo codificados.

Fundamentos

[0004] Recursos de vídeo digital podem ser incorporados a uma ampla gama de dispositivos, incluindo televisores digitais, sistemas digitais de difusão direto, sistemas de difusão sem fio, assistentes de dados pessoais (PDAs), computadores desktop ou laptop, câmeras digitais, dispositivos de gravação digitais, reprodutores de mídia digitais, dispositivos de vídeo jogos, consoles de vídeo jogos, rádio telefones celulares ou por satélites, dispositivos de teleconferência por vídeo e similares. Os dispositivos de vídeo digitais implementam técnicas de compressão de vídeo tais como aquelas descritas nas normas definidas em MPEG-2, MPEG-4, ITU-T, H.263 ou ITU-T H.264/MPEG-4, Seção 4, codificação de vídeo avançada (AVC - Advanced Video Coding) e extensões de tais normas, para a transmissão e recepção mais eficientes de informações de vídeo digital.

[0005] As técnicas de compressão de vídeo efetuam a predição espacial e/ou predição temporal de modo a reduzir ou remover a redundância inerente em sequências de vídeo. Para a codificação de vídeo baseada em blocos, um quadro ou “fatia” de vídeo pode ser particionado em macroblocos. Cada macrobloco pode ser adicionalmente particionado. Os macroblocos em um quadro ou fatia intra- codificados (I) são codificados usando-se predição espacial com relação aos macroblocos vizinhos. Os macroblocos em um quadro ou fatia inter-codificados (P ou B) podem utilizar predição espacial com relação a macroblocos vizinhos no mesmo quadro, ou predição temporal com relação a outros quadros de referência.

[0006] Após os dados de vídeo terem sido codificados, os dados de vídeo podem ser colocados em pacotes por um multiplexador para transmissão ou armazenamento. A norma MPEG-2 inclui uma seção sobre “Sistemas” que define um nível de transporte para várias normas de codificação. Os sistemas de nível de transporte MPEG-2 podem ser usados por codificadores de vídeo MPEG-2, ou outros codificadores de vídeo que estejam de acordo com diferentes normas de codificação de vídeo. Como exemplo, a MPEG-4 prescreve metodologias de codificação e decodificação diferentes daquelas da MPEG-2, porém os codificadores de vídeo que implementam as técnicas da norma MPEG-4 podem ainda utilizar os métodos de nível de transporte da MPEG-2. De um modo geral, as referências aos “sistemas MPEG-2” dizem respeito ao nível de transporte de dados de vídeo prescrito pela MPEG-2. o nível de transporte prescrito pela MPEG-2 é também designado nesta descrição como um “fluxo de transporte MPEG-2” ou simplesmente um “fluxo de transporte”. De forma similar, o nível de transporte de sistemas MPEG-2 inclui também fluxos de programas. Os fluxos de transporte e fluxos de programas incluem de um modo geral diferentes formatos para o deslocamento de dados similares, em que um fluxo de transporte compreende um ou mais “programas” incluindo tanto dados de áudio como de vídeo, enquanto que os fluxos de programas incluem um programa que inclui tanto dados de áudio como de vídeo.

[0007] A especificação dos Sistemas MPEG-2 descreve como fluxos de dados multimídia (de vídeo e áudio) comprimidos podem ser multiplexados com outros dados para formar um único fluxo de dados adequado para armazenamento ou transmissão digital. A especificação mais recente de sistemas MPEG-2 está descrita em “Information Technology - Generic Coding of Moving Pictures and Associated Audio: Systems, Recommendation H.222.0; International Organization for standardization, ISO/IEC JTC 1/SC 29/WG 11; Coding of Moving Pictures and Associated Audio,” de maio de 2006. O MPEG emitiu recentemente a norma de transporte de MVC através de sistemas MPEG-2 e a versão mais recente de tal especificação é “Study of ISO/IEC 13818-1: 2007/FPDAM4 Transport of MVC”, MPEG doc. N10572, MPEG of ISO/IEC JTC 1/SC 29/WG 11, Maui, Hawaii, EUA, abril de 2009.

Sumário

[0008] De um modo geral, a presente descrição revela técnicas para melhoria da codificação de vídeo multivista em sistemas MPEG-2 (Motion Picture Experts Group - Grupo de Especialistas em Películas Cinematográficas). As técnicas da presente invenção de um modo geral expandem as capacidades do nível de transporte MPEG-2, por exemplo os fluxos de transporte MPEG-2 e fluxos de programas MPEG-2, com relação à codificação de vídeo multivista (MVC). Como exemplo, as técnicas da presente invenção permitem a transmissão de quadros não consecutivos de um fluxo de vídeo MVC a ser transmitido no nível de transporte. As técnicas da presente invenção permitem também que subfluxos de bits do fluxo de transporte (ou programa) incluam, cada um, quadros não consecutivos. As técnicas permitem também a um dispositivo receptor, quando da recepção de um fluxo de nível de transporte compreendendo uma pluralidade de subfluxos de bits, cada uma possuindo vistas não consecutivas, rearranjar os quadros nos subfluxos de bits de forma a que o fluxo de transporte seja ordenado apropriadamente, isto é, na ordem crescente em termos de índices de ordem de vistas, de forma a que um decodificador possa decodificar apropriadamente os quadros de cada uma das vistas.

[0009] Como exemplo, um método compreende construir, com um dispositivo de origem/fonte, uma estrutura de dados para sinalizar que um correspondente fluxo de bits padrão do sistema MPEG-2 (Motion Picture Experts Group - Grupo de Especialistas em Películas Cinematográficas) compreende uma primeira vista de uma cena associada a um primeiro índice de ordem de vistas e um segundo quadro da cena associado a um segundo índice de ordem de vistas, em que o primeiro índice de ordem de vistas e o segundo índice de ordem de vistas não são consecutivos. O método inclui também emitir a estrutura de dados, por exemplo transmitir a estrutura de dados para um dispositivo de destino, ou armazenar a estrutura de dados em um meio legível por computador.

[00010] Como outro exemplo, um equipamento inclui um codificador de vídeo que codifica uma pluralidade de vistas de uma cena; um multiplexador que constrói uma estrutura de dados para sinalizar que um correspondente fluxo de bits padrão do sistema MPEG-2 (Grupo de Especialistas em Películas Cinematográficas) compreende uma primeira vista dentre a pluralidade de vistas da cena associada a um primeiro índice de ordem de vistas e um segundo quadro dentre a pluralidade de vistas da cena associada a um segundo índice de ordem de vistas, em que o primeiro índice de ordem de vistas e o segundo índice de ordem de vistas não são consecutivos; e uma interface de saída que emite a estrutura de dados.

[00011] Como outro exemplo, um equipamento inclui meios para construir, com um dispositivo de origem, uma estrutura de dados para sinalizar que um correspondente fluxo de bits padrão do sistema MPEG-2 (Grupo de Especialistas em Películas Cinematográficas) compreende uma primeira vista de uma cena associada a um primeiro índice de ordem de vistas e um segundo quadro da cena associado a um segundo índice de ordem de vistas, em que o primeiro índice de ordem de vistas e o segundo índice de ordem de vistas não são consecutivos; e meios para emitir a estrutura de dados.

[00012] Como outro exemplo, um meio de armazenamento legível por computador é codificado com instruções para levar um processador a construir uma estrutura de dados para sinalizar que um correspondente fluxo de bits padrão do sistema MPEG-2 (Grupo de Especialistas em Películas Cinematográficas) compreende uma primeira vista de uma cena associada a um primeiro índice de ordem de vistas e um segundo quadro da cena associado a um segundo índice de ordem de vistas, em que o primeiro índice de ordem de vistas e o segundo índice de ordem de vistas não são consecutivos; e emitir a estrutura de dados.

[00013] Como outro exemplo, um método inclui produzir, com um dispositivo cliente, um fluxo de bits de acordo com a norma de codificação de vídeo multivista (MVC) a partir de um fluxo de bits recebido compreendendo um subfluxo de bits primário/principal e um subfluxo de bits embutido do subfluxo de bits primário, em que a produção do fluxo de bits de acordo com a norma MVC inclui determinar se um componente de vista do subfluxo de bits primário possui um índice de ordem de vistas que é maior que um índice de ordem de vistas de um componente de vista da subfluxo de bits embutida, quando o índice de ordem de vistas do componente de vista da subfluxo de bits primário for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits, adicionar o componente de vista do subfluxo de bits embutido ao fluxo de bits produzido, e quando o índice de ordem de vistas do componente de vistas do subfluxo de bits primário não for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits embutido, adicionar o componente de vista do subfluxo de bits primário ao fluxo de bits produzido. O método compreende também emitir o fluxo de bits produzido para um decodificador de vídeo.

[00014] Como outro exemplo, um equipamento inclui um receptor que recebe um fluxo de bits compreendendo um subfluxo de bits primário e um subfluxo de bits embutido do subfluxo de bits primário, um demultiplexador que produz um fluxo de bits de acordo com a norma de codificação de vídeo multivista (MVC) a partir do fluxo de bits recebido, em que, para produzir o fluxo de bits de acordo com a norma MVC, o demultiplexador determina se um componente de vista do subfluxo de bits primário possui um índice de ordem de vistas que é maior que um índice de ordem de vistas de um componente de vista do subfluxo de bits embutido, adicionar o componente de vista do subfluxo de bits embutido ao fluxo de bits produzido quando o índice de ordem de vistas do componente de vista do subfluxo de bits primário for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits, e adicionar o componente de vista do subfluxo de bits primária ao fluxo de bits produzido quando o índice de ordem de vistas do componente de vistas do subfluxo de bits primário não for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits embutido; e um decodificador de vídeo que decodifica o fluxo de bits produzida pelo demultiplexador.

[00015] Como outro exemplo, um equipamento inclui meios para produzir um fluxo de bits de acordo com a norma de codificação de vídeo multivista (MVC) a partir de um fluxo de bits recebida compreendendo um subfluxo de bits primário/principal e um subfluxo de bits embutido do subfluxo de bits primário, meios para determinar se um componente de vista do subfluxo de bits primária possui um índice de ordem de vistas que é maior que um índice de ordem de vistas de um componente de vista do subfluxo de bits embutido, meios para adicionar o componente de vista do subfluxo de bits embutido ao fluxo de bits produzido quando o índice de ordem de vistas do componente de vista do subfluxo de bits primário for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits, e meios para adicionar o componente de vista do subfluxo de bits primário ao fluxo de bits produzido quando o índice de ordem de vistas do componente de vistas do subfluxo de bits primário não for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits embutido, e meios para emitir o fluxo de bits produzido para um decodificador de vídeo.

[00016] Como outro exemplo, um meio de armazenamento legível por computador é codificado com instruções para levar um processador programável a produzir, com um dispositivo cliente, um fluxo de bits de acordo com a norma de codificação de vídeo multivista (MVC) a partir de um fluxo de bits recebido compreendendo um subfluxo de bits primário/principal e um subfluxo de bits embutido do subfluxo de bits primário, compreendendo instruções para determinar se um componente de vista do subfluxo de bits primário possui um índice de ordem de vistas que é maior que um índice de ordem de vistas de um componente de vista do subfluxo de bits embutido, quando o índice de ordem de vistas do componente de vista do subfluxo de bits primário for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits, adicionar o componente de vista do subfluxo de bits embutido ao fluxo de bits produzido, e quando o índice de ordem de vistas do componente de vistas do subfluxo de bits primário não for maior que o índice de ordem de vistas do componente de vista do subfluxo de bits embutido, adicionar o componente de vista do subfluxo de bits primário ao fluxo de bits produzido, e emitir o fluxo de bits produzido para um decodificador de vídeo.

[00017] Os detalhes de um ou mais exemplos são apresentados nos desenhos anexos e na descrição que se segue. Outros recursos, características, objetivos e vantagens ficarão claros através da descrição e desenhos e das reivindicações.

Breve Descrição dos Desenhos

[00018] A Figura 1 é um diagrama de blocos que ilustra um exemplo de sistema em que um dispositivo de origem de áudio/vídeo (A/V) transporta dados de áudio e vídeo para um dispositivo A/V de destino.

[00019] A Figura 2 é um diagrama de blocos que ilustra um exemplo de disposição de componentes de um multiplexador.

[00020] A Figura 3 é um diagrama de blocos que ilustra um exemplo de conjunto de tabelas de informações específicas por programas.

[00021] A Figura 4 é um diagrama de blocos que ilustra um exemplo de conjunto de dados que podem ser incluídos em um descritor de extensão de codificação de vídeo multivista (MVC).

[00022] A Figura 5 é um diagrama de blocos que ilustra um exemplo de conjunto de dados que podem ser incluídos em um descritor de hierarquia.

[00023] A Figura 6 é um diagrama conceitual que ilustra um exemplo de padrão ou configuração de predição MVC.

[00024] A Figura 7 é um fluxograma que ilustra um exemplo de um método para enviar um fluxo de sistemas MPEG-2 possuindo um subconjunto de vistas com índices de ordem de vistas não consecutivos de um servidor para um cliente.

[00025] A Figura 8 é um fluxograma que ilustra um exemplo de um método para montagem de componentes de quadros de dois ou mais subfluxos de bits para produzir um fluxo de bits tal que os componentes de quadros apresentem índices de ordem de vistas crescentes.

Descrição Detalhada

[00026] As técnicas da presente invenção estão de um modo geral voltadas para a melhoria de sistemas de codificação de vídeo multivista em MPEG-2, isto é, sistemas que estejam de acordo com a norma MPEG-2 com referência aos detalhes de nível de transportes. Como exemplo, o MPEG-4 propicia normas para a codificação de vídeo, porém de um modo geral presume que os codificadores de vídeo de acordo com a norma MPEG-4 irão utilizar sistemas de nível de transporte MPEG-2. Assim sendo, as técnicas da presente invenção podem ser aplicadas a codificadores de vídeo que esteja de acordo com as normas MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, ou qualquer outra norma de codificação de vídeo que utilize fluxos de transporte e/ou fluxos de programas MPEG-2.

[00027] Em particular, as técnicas da presente invenção podem ser usadas para modificar elementos de sintaxe no nível de transporte para fluxos de transporte e fluxos de programas MPEG-2. Como exemplo, as técnicas da presente invenção incluem um descritor que é transmitido no fluxo de transporte para identificar especificamente cada quadro de dados de vídeo multivista que seja enviado no fluxo de transporte. Como exemplo, um dispositivo servidor pode prover vários serviços, cada um dos quais compreende os respectivos subconjuntos de quadros específicos de dados de vídeo de codificação de vídeo multivista, em que o subconjunto de vistas do serviço pode ser selecionado com base em um aplicativo executado por um dispositivo de cliente, na capacidade de decodificadores executados pelo dispositivo cliente, nas preferências expressadas pelo dispositivo cliente, ou outros critérios de seleção.

[00028] De acordo com as técnicas da presente invenção, o dispositivo servidor pode prover um subconjunto de vistas possuindo índices de ordem de vistas não consecutivos. Como exemplo, o dispositivo servidor sinaliza especificamente cada um dos quadros que serão incluídos no fluxo de transporte em um descritor de extensão MVC que pode ser incluído em uma tabela de mapas de programa (PMT) ou um mapa de fluxos de programa (PSM).

[00029] Em alguns exemplos, o dispositivo servidor pode enviar uma pluralidade de subfluxos de bits em um único fluxo de transporte ou fluxo de programa. Por permitir que os quadros de um fluxo de bits sejam não consecutivos, as técnicas da presente invenção também permitem que os índices de ordem de vistas correspondentes aos quadros de cada subfluxo de bits sejam não consecutivos. Apesar de tais técnicas permitirem índices de ordem de vistas não consecutivos em cada subfluxo de bits, os índices de ordem de vistas devem ainda ser crescentes em um subfluxo de bits, de modo a estar de acordo com as normas de fluxos de bits existentes, por exemplo a norma dos sistemas MPEG-2. No entanto, dado que os quadros de um primeiro subfluxo de bits e de um segundo subfluxo de bits podem ser, em cada uma, não consecutivos, os quadros podem chegar ao dispositivo cliente fora de ordem com relação aos índices de ordem de vistas. As técnicas da presente invenção também permitem ao dispositivo cliente processar tal fluxo de transporte para reordenar de forma eficiente os quadros do primeiro subfluxo de bits e do segundo subfluxo de bits de forma a que os índices de ordem de vistas dos quadros sejam crescentes. Combinações de quadros possuindo índices de ordem de vistas não consecutivos podem ser usadas para escalonamento de quadros, o que pode ser útil para adaptação de amplitude de banda, eficiência de decodificadores e para prover outras vantagens semelhantes. Como exemplo, ao contrário das técnicas convencionais, que demandariam o envio de todos os quadros para um dispositivo cliente e que o dispositivo cliente decodificasse cada quadro, possuindo índices de ordem de vistas consecutivos, as técnicas da presente invenção permitem o envio apenas dos quadros que são especificamente requeridos pelo dispositivo cliente, mesmo quando isto resulta em quadros possuindo índices de ordem de vistas não consecutivos. Dessa forma, um dispositivo de cliente pode receber apenas os quadros que forem necessários para um serviço específico, em lugar de todos os quadros com os índices de ordem de vistas intervenientes.

[00030] Apesar de várias seções na presente descrição poderem fazer referência individualmente a um “fluxo de transporte” ou a um “fluxo de programa”, deve ficar claro que as técnicas da presente invenção podem de um modo geral ser aplicadas a uma ou ambas dentre os fluxos de transporte e fluxos de programaMPEG-2. De um modo geral, a presente invenção descreve exemplos de descritores para efetuar as técnicas da presente invenção. Os descritores são usados para estender a funcionalidade de um fluxo. Os descritores da presente invenção podem ser usados tanto por fluxos de transporte e fluxos de programas para implementar as técnicas da presente invenção.

[00031] A presente invenção utiliza também os termos que se seguem, e propõe a inclusão de tais termos em uma revisão a norma de sistemas MPEG-2 atual, juntamente com as semânticas dos termos tal como indicado: • Subfluxo de bits de vídeo AVC: o quadro/vista base do fluxo de bits MVC. • Subfluxo de bits de vídeo AVC de MVC: o quadro base do fluxo de bits MVC descartando as unidades NAL de prefixo. • Subfluxo de bits de quadro base MVC: ou subfluxo de vídeo AVC ou subfluxo de bits de vídeo AVC de MVC. • Subconjunto de componente-quadro MVC: as unidades NAL de um componente de vista. • Subconjunto MVC view_id: as unidades NAL de um quadro. • Subfluxo de bits de vídeo MVC: as unidades NAL dos quadros não base.

[00032] A Figura 1 é um diagrama de blocos que ilustra um sistema 10 exemplar em que um dispositivo de origem/fonte de áudio/vídeo (A/V) 20 transporta dados de áudio e vídeo para um dispositivo A/V de destino 40. O sistema 10 da Figura 1 pode corresponder a um sistema de teleconferência em vídeo, um sistema servidor/cliente, um sistema de difusão/receptor, ou qualquer outro sistema em que dados de vídeo sejam enviados a partir de um dispositivo fonte/de origem, tal como o dispositivo de origem A/V 20, para um dispositivo de destino, tal como o dispositivo de destino A/V 40. Em alguns exemplos, o dispositivo de origem A/V 20 e o dispositivo A/V de destino 40 podem efetuar a troca de informações bidirecional. Isto é, o dispositivo A/V de origem 20 e o dispositivo A/V de destino 40 podem ser capazes de tanto codificar como decodificar (e transmitir e receber) dados de áudio e vídeo. Em alguns exemplos, o codificador de áudio 26 pode compreender um codificador de voz, também designado como um vocoder.

[00033] O dispositivo A/V de origem 20 no exemplo da Figura 1, compreende a fonte de áudio 22 e a fonte de vídeo 24. A fonte de áudio pode compreender, por exemplo, um microfone que produz sinais elétricos representativos de dados de áudio captados para serem codificados pelo codificador de áudio 26. Alternativamente, a fonte de áudio 22 pode compreender um meio de armazenamento que armazena dados de áudio gravados anteriormente, um gerador de dados de áudio, tal como um sintetizador computadorizado, ou qualquer outra fonte de dados de áudio. A fonte de vídeo 24 pode compreender uma câmera de vídeo que produz dados de vídeo a serem codificados pelo codificador de vídeo 28, um meio de armazenamento codificado com dados de vídeo gravados anteriormente, uma unidade de geração de vídeo, ou qualquer outra fonte de dados de vídeo. Os dados de áudio e vídeo não processados podem compreender dados analógicos ou digitais. Os dados analógicos podem ser digitalizados antes de serem codificados pelo codificador de áudio 26 e/ou o codificador de vídeo 28. A fonte de áudio 22 pode obter dados de áudio a partir de um participante que fala enquanto o participante que fala estiver falando, enquanto a fonte de vídeo 24 pode simultaneamente obter dados de vídeo do participante que fala. Como outro exemplo, a fonte de áudio 22 pode compreender um meio de armazenamento legível por computador compreendendo dados de áudio armazenados, enquanto a fonte de vídeo 24 pode compreender um meio de armazenamento legível por computador compreendendo dados de vídeo armazenados. Dessa forma, as técnicas da presente invenção aqui descritas podem ser aplicadas a dados de áudio e vídeo ao vivo, em streaming, em tempo real, ou a dados de áudio e vídeo pré-gravados arquivados.

[00034] Os quadros de áudio que correspondem a quadros de vídeo são de um modo geral quadros de áudio contendo dados de áudio que foram captados pela fonte de áudio 22 concomitantemente com dados de vídeo captados pela fonte de vídeo 24 e que estão contidos nos quadros de vídeo. Como exemplo, enquanto um participante que fala de um modo geral produz dados de áudio falando, a fonte de áudio 22 capta os dados de áudio e a fonte de vídeo 24 capta dados de vídeo do participante que fala simultaneamente, isto é, enquanto a fonte de vídeo 24 capta os dados de vídeo do participante que fala concomitantemente, isto é, enquanto a fonte de áudio 22 está captando os dados de áudio. Portanto, um quadro de áudio pode temporariamente corresponder a um ou mais quadros de vídeo específicos. Assim sendo, um quadro de áudio correspondente a um quadro de vídeo de um modo geral corresponde a uma situação em que dados de áudio e dados de vídeo foram captados ao mesmo tempo e para os quais um quadro de áudio e um quadro de vídeo compreendem, respectivamente, os dados de áudio e os dados de vídeo que foram captados ao mesmo tempo.

[00035] Como exemplo, o codificador de áudio 26 pode codificar uma marca de tempo em cada quadro de áudio codificado que representa um instante em que os dados de áudio para o quadro de áudio codificado foram gravados, e, de forma similar, o codificador de vídeo 28 pode codificar uma marca de tempo em cada quadro de vídeo codificado que representa um instante em que os dados de vídeo para o quadro de vídeo codificado foram gravados. Em tal exemplo, um quadro de áudio correspondente a um quadro de vídeo pode compreender um quadro de áudio compreendendo uma marca de tempo e um quadro de vídeo compreendendo a mesma marca de tempo. O dispositivo A/V de origem 20 pode incluir um relógio interno a partir do qual o codificador de áudio 26 e/ou o codificador de vídeo 28 podem gerar as marcas de tempo, ou que a fonte de áudio 26 e/ou o codificador de vídeo 28 podem usar para associar dados de áudio e vídeo, respectivamente, com uma marca de tempo. Em alguns exemplos, a fonte de áudio 22 pode enviar dados para o codificador de vídeo 26 correspondentes a um instante em que dados de áudio foram gravados, enquanto a fonte de vídeo 24 pode enviar dados para o codificador de vídeo 28 correspondentes a um instante em que dados de vídeo foram gravados. Em alguns exemplos, o codificador de áudio 26 pode codificar um identificador de sequência em dados de áudio codificados para indicar uma ordenação temporal relativa de dados de áudio codificados porém sem necessariamente indicar uma ordenação temporal relativa em que os dados de áudio foram gravados e, de forma similar, o codificador de vídeo 28 pode também usar identificadores de sequências para indicar uma ordenação temporal relativa de dados de vídeo codificados. De forma similar, em alguns exemplos, um identificador de sequência pode ser mapeado, ou de outra forma correlacionado, com uma marca de tempo.

[00036] As técnicas da presente invenção estão de um modo geral direcionadas ao transporte de dados de multimídia codificados (por exemplo, áudio e vídeo) e à recepção e subsequente interpretação e decodificação dos dados multimídia transportados. As técnicas da presente invenção podem ser especificamente aplicadas ao transporte de dados de codificação de vídeo multivista (MVC), isto é, dados de vídeo compreendendo uma pluralidade de vistas ou quadros. Tal como apresentado no exemplo da Figura 1, a fonte de vídeo 24 pode prover uma pluralidade de vistas ou quadros de uma cena para o codificador de vídeo 28. O MVC pode ser útil para a geração de dados de vídeo tridimensional a serem usados por um display ou monitor tridimensional, tal como display tridimensional estereoscópico ou auto estereoscópico.

[00037] O dispositivo A/V de origem/fonte 20 pode prover um “serviço” para o dispositivo A/V de destino 40. um serviço de um modo geral corresponde a um subconjunto de vistas/quadros disponíveis de dados de MVC. Como exemplo, os dados de MVC podem estar disponíveis para oito vistas, ordenadas de zero a sete. Um serviço pode corresponder a um vídeo estéreo possuindo duas vistas, enquanto que outro serviço pode corresponder a quatro vistas, e mais outro serviço pode corresponder a todas as oito vistas. De um modo geral, um serviço corresponde a qualquer combinação (isto é, qualquer subconjunto) das vistas disponíveis. Um serviço pode também corresponder a uma combinação de vistas disponíveis bem como a dados de áudio.

[00038] O dispositivo A/V de origem/fonte 20 de acordo com as técnicas da presente invenção é capaz de prover serviços que correspondem a um subconjunto de vistas que incluem índices de ordem de vista não consecutivos. De um modo geral, uma vista é representada por um identificador de vista, também designado como um “view_id”. Os identificadores de vistas compreendem de um modo geral elementos de sintaxe que podem ser usados para identificar uma vista. Um codificador de MVC provê o view_id de uma vista quando a vista é codificada. O view_id pode ser usado por um decodificador de MVC para predição entre vistas, ou por outras unidades para outros propósitos, por exemplo para renderização.

[00039] A predição entre vistas constitui uma técnica para codificar dados de vídeo MVC de um quadro com referência a um ou mais quadros em uma localização temporal comum como o quadro codificado de diferentes vistas. A Figura 6, que será comentada em maiores detalhes mais adiante, propicia um exemplo de esquema de codificação para predição entre vistas. De um modo geral, um quadro codificado de dados de vídeo MVC pode ser codificado previsivelmente de forma espacial, temporal e/ou com referência a quadros de outras vistas em uma localização temporal comum. Assim sendo, vistas de referência, a partir das quais são preditas outras vistas, são de um modo geral decodificadas antes das vistas para as quais as vistas de referência atuam como referência, de forma que tais vistas decodificadas podem ser usadas para referência quando da decodificação de vistas referenciais. A ordem de decodificação não corresponde necessariamente à ordem dos view_ids. Portanto, a ordem de decodificação de vistas é descrita usando-se os índices de ordem de vistas. Os índices de ordem de vistas são índices que indicam a ordem de decodificação de componentes de vistas correspondentes em uma unidade de acesso.

[00040] Cada fluxo de dados individual (sejam de áudio ou vídeo) é designado como um fluxo elementar. Um fluxo elementar é um componente único, digitalmente codificado (possivelmente comprimido) de um programa. Como exemplo, a parte de vídeo ou áudio codificada do programa pode ser um fluxo elementar. Um fluxo elementar pode ser convertido em um fluxo elementar empacotado (PES) antes de ser multiplexado para um fluxo de programa ou fluxo de transporte. Dentro do mesmo programa, é usada uma ID de fluxo para diferenciar os pacotes PES pertencentes a um fluxo elementar dos outros. A unidade básica de dados de um fluxo elementar é um pacote de fluxo elementar empacotado (PES). Dessa forma, cada vista de dados de vídeo MVC corresponde aos respectivos fluxos elementares. De forma similar, dados de áudio correspondem a um respectivo fluxo elementar. No exemplo da Figura 1, o multiplexador 30 recebe fluxos elementares compreendendo dados de vídeo provenientes do codificador de vídeo 28 e fluxos elementares compreendendo dados de áudio provenientes do codificador de áudio 26. Como exemplo, o codificador de vídeo 28 e o codificador de áudio 26 podem incluir, cada um, empacotadores para a formação de pacotes PES a partir de dados codificados. Como outro exemplo, o codificador de vídeo 28 e o codificador de áudio 26 podem, cada um, interagir com respectivos empacotadores para a formação de pacotes PES a partir de dados codificados. Como mais outro exemplo, o multiplexador 30 pode incluir empacotadores para formar pacotes PES a partir de dados de vídeo e áudio codificados.

[00041] O termo “programa”, tal como é usado na presente descrição, pode compreender uma combinação de dados de áudio e dados de vídeo, por exemplo um fluxo elementar de áudio e um subconjunto de vistas disponíveis entregues por um serviço do dispositivo A/V de origem/fonte 20. Cada pacote PES inclui um stream_id que identifica o fluxo elementar à qual pertence o pacote PES. O multiplexador 30 é responsável por reunir os fluxos elementares em fluxos de programa ou fluxos de transporte constituintes. Um fluxo de programa e um fluxo de transporte constituem dois multiplexados colimando diferentes aplicativos.

[00042] De um modo geral, um fluxo de programa consiste de dados para um programa, enquanto um fluxo de transporte pode compreender dados para um ou mais programas. O multiplexador 30 pode codificar um, ou ambos, dentre um fluxo de programa ou um fluxo de transporte, com base em um serviço que está sendo provido, um meio para o qual o fluxo será passado, um certo número de programas a ser enviado, ou outras considerações. Como exemplo, quando os dados de vídeo devem ser codificados em um meio de armazenamento, o multiplexador 30 mais provavelmente formará um fluxo de programa, enquanto que quando os dados de vídeo devem ser enviados através de uma rede, irradiados em difusão, ou enviados como parte de vídeo telefonia, o multiplexador 30 mais provavelmente usará um fluxo de transporte.

[00043] O multiplexador 30 pode ser levado a tender a usar um fluxo de programa para o armazenamento e apresentação de um único programa proveniente de um serviço de armazenamento digital. Um fluxo de programa se destina ao uso em ambientes livres de erros, ou ambientes menos suscetíveis ao encontro de erros, dado que os fluxos de programas são bastante suscetíveis a erros. Um fluxo de programa compreende simplesmente os fluxos elementares a ela pertencentes e usualmente contém pacotes com comprimentos de pacote diferentes. Em um fluxo de programa, os pacotes PES que são derivados a partir dos fluxos elementares contribuintes são organizados em “packs” ou grupos. Um pack compreende um cabeçalho de pack, um cabeçalho de sistema opcional e qualquer número de pacotes PES tomados a partir de quaisquer dos fluxos elementares contribuintes, em qualquer ordem. O cabeçalho de sistema contém um resumo das características do fluxo de programa, tais como sua taxa de dados máxima, o número de fluxos elementares de vídeo e áudio contribuintes, outras informações de temporização, ou outras informações. Um decodificador pode usar as informações contidas em um cabeçalho de sistema para determinar se o decodificador é capaz de decodificar o fluxo de programa ou não.

[00044] O multiplexador 30 pode usar um fluxo de transporte para a entrega simultânea de uma pluralidade de programas através de canais potencialmente sujeitos a erros. Um fluxo de transporte é um multiplexado desenvolvido para aplicativos de múltiplos programas, tais como difusão, de forma a que um único fluxo de transporte possa acomodar vários programas independentes. Um fluxo de transporte compreende uma sucessão de pacotes de transporte, cada um dos pacotes de transporte possuindo comprimento de 188 bytes. O uso de pacotes curtos de comprimento fixo significa que o fluxo de transporte é menos suscetível a erros que o fluxo de programa. Além disso, cada pacote de transporte com 188 bytes de comprimento pode receber proteção adicional contra erros através do processamento do pacote através de um processo de proteção contra erros padrão, tal como a codificação Reed-Solomon. A maior flexibilidade face a erros do fluxo de transporte significa que ela possui uma melhor chance de sobreviver nos canais sujeitos a erros que são encontrados, por exemplo, em um ambiente de difusão.

[00045] Pode parecer que o fluxo de transporte é, claramente, o melhor dos dois multiplexados, com sua maior resistência a erros e capacidade de portar vários programas simultaneamente. No entanto, o fluxo de transporte é um multiplexado mais sofisticado que o fluxo de programa, sendo consequentemente de criação e demultiplexação mais difíceis. O primeiro byte de um pacote de transporte é um byte de sincronização possuindo um valor de 0x47 (hexadecimal 47, binário 01000111, decimal 71). Um único fluxo de transporte pode portar vários programas diferentes, cada programa compreendendo muitos fluxos elementares empacotados. O multiplexador 30 pode usar um campo de treze bits de identificador de pacote (PID) para distinguir pacotes de transporte contendo os dados de um fluxo elementar daqueles portando os dados de outros fluxos elementares. Constitui responsabilidade do multiplexador assegurar que cada fluxo elementar receba um valor de PID exclusivo. O último byte de um pacote de transporte é o campo de contagem de continuidade. O multiplexador 30 incrementa o valor do campo de contagem de continuidade entre pacotes de transporte sucessivos pertencentes ao mesmo fluxo elementar. Isto permite a um decodificador ou outra unidade de um dispositivo de destino, tal como o dispositivo A/V de destino 40, detectar a perda ou ganho de um pacote de transporte e, espera-se, ocultar os erros que poderiam de outra forma resultar de tal evento.

[00046] O multiplexador 30 recebe os pacotes PES para fluxos elementares de um programa a partir do codificador de áudio 26 e do codificador de vídeo 28 e forma as correspondentes unidades de camada de abstração de rede (NAL) a partir dos pacotes PES. No exemplo da H.246/AVC (codificação de vídeo avançada), os segmentos de vídeo codificados são organizados em unidades NAL, as quais propiciam uma representação de vídeo “amigável para redes” (“network-friendly”) abordando aplicações tais como vídeo telefonia, armazenamento, difusão ou streaming. As unidades NAL podem ser categorizadas como unidades NAL de camada de codificação de vídeo (VCL) e unidades NAL não VCL. As unidades VCL contêm a “máquina” núcleo de compressão e podem compreender níveis de bloco, macrobloco e/ou fatia. Outras unidades NAL são unidades NAL não VCL.

[00047] O multiplexador 30 pode formar unidades NAL compreendendo um cabeçalho que identifica um programa ao qual pertence a NAL, bem como uma carga útil, por exemplo dados de áudio, dados de vídeo, ou dados que descrevem o fluxo de transporte ou programa à qual corresponde a unidade de NAL. Como exemplo, na H.264/AVC, uma unidade NAL inclui um cabeçalho de 1 byte e uma carga útil de tamanho variável. Como exemplo, um cabeçalho de uma unidade NAL compreende um elemento de priority_id, um elemento temporal_id, um elemento anchor_pic_flag, um elemento view_id, um elemento non_idr_flag, e um elemento inter_view_flag. No MVC convencional, a unidade NAL definida pela H.264 é retida, exceto por unidades NAL de prefixo e unidades NAL de fatia codificadas em MVC, as quais incluem um cabeçalho de unidade MVC NAL de 4 bytes e a carga útil da unidade NAL.

[00048] O elemento priority_id de um cabeçalho NAL pode ser usado para um processo simples de adaptação de fluxo de bits de uma via. O elemento temporal_id pode ser usado para especificar o nível temporal da unidade NAL correspondente, quando diferentes níveis temporais correspondem a diferentes taxas de quadros. O elemento anchor_pic_flag pode indicar se uma imagem é uma imagem âncora ou uma imagem não âncora.

[00049] As imagens âncora e todas as imagens que a sucedem na ordem de saída (isto é, a ordem de apresentação) podem ser decodificadas corretamente sem decodificar as imagens anteriores na ordem de decodificação (isto é, a ordem do fluxo de bits), podendo, portanto, ser usadas como pontos de acesso aleatório. As imagens âncora e imagens não âncora podem possuir diferentes dependências, ambas sendo sinalizadas no conjunto de parâmetros de sequência. Outros sinalizadores deverão ser comentados e usados nas seções que se seguem da presente seção. Tal imagem âncora pode também ser designada como um ponto de acesso a um GOP (grupo de imagens - Group Of Pictures) aberto, enquanto um ponto de acesso GOP fechado é também suportado quando o elemento non_idr_flag for igual a zero. O elemento non_idr_flag indica se uma imagem é uma imagem instantânea de renovação (refresh) de decodificador (IDR) ou IDR de vista (V-IDR). De um modo geral, uma imagem IDR, bem como todas as imagens que a sucedem em ordem de emissão ou ordem de fluxo de bits, podem ser decodificadas corretamente sem a decodificação de imagens anteriores, seja em ordem de decodificação ou ordem de apresentação.

[00050] O elemento view_id compreende informações de sintaxe que podem ser usadas para identificar uma vista, que podem ser usadas para interatividade de dados no interior de um decodificador MVC, por exemplo para predição entre vistas, e fora de um decodificador, por exemplo para reprodução. O elemento inter_view_flag pode especificar se a unidade NAL correspondente é usada por outras vistas para predição entre vistas. Para transportar as informações de cabeçalho de unidade NAL de 4 bytes para uma vista base, que pode estar de acordo com o AVC, é definida uma unidade NAL de prefixo no MVC. No contexto do MVC, a unidade de acesso de vista base inclui as unidades VCL NAL do caso de instante fluxo da vista, bem como sua unidade NAL de prefixo, que contém apenas o cabeçalho de unidade NAL. Um decodificador H.264/AVC pode ignorar a unidade NAL de prefixo.

[00051] Uma unidade NAL incluindo dados de vídeo em sua carga útil pode compreender vários níveis de granulação de dados de vídeo. Como exemplo, uma unidade NAL pode compreender um bloco de dados de vídeo, um macrobloco, uma pluralidade de macroblocos, uma fatia de dados de vídeo, ou todo um quadro de dados de vídeo. O multiplexador 30 pode receber dados de vídeo codificados a partir do codificador de vídeo 28 na forma de pacotes PES de fluxos elementares. O multiplexador 30 pode associar cada fluxo elementar a um programa correspondente através do mapeamento de stream_ids para programas correspondentes, por exemplo em uma base de dados ou outra estrutura de dados, tal como uma tabela de mapas de programa (PMT) ou mapa de fluxos de programa (PSM).

[00052] O multiplexador 30 pode também reunir unidades de acesso provenientes de uma pluralidade de unidades NAL. De um modo geral, uma unidade de acesso pode compreender uma ou mais unidades NAL para representar um quadro de dados de vídeo, bem como dados de áudio correspondentes ao quadro quando tais dados de áudio estão disponíveis. Em um exemplo correspondente à H.264/AVC, uma unidade de acesso pode compreender uma imagem codificada em um instante, a qual pode ser apresentada como uma imagem primária codificada. Assim sendo, uma unidade de acesso pode compreender todos os quadros de áudio e vídeo de uma instância temporal comum, por exemplo todas as vistas correspondentes ao instante X. A presente invenção também se refere a uma imagem codificada de uma vista específica como um “componente de vista”. Isto é, um componente de vista compreende uma imagem (ou quadro) codificada para uma vista específica e um instante específico. Assim sendo, uma unidade de acesso pode ser definida como compreendendo todos os componentes de vista de uma instância temporal comum.

[00053] O multiplexador 30 pode também embutir dados referentes um programa em uma unidade NAL. Como exemplo, o multiplexador 30 pode criar uma unidade NAL compreendendo uma tabela de mapas de programa (PMT) ou um mapa de fluxos de programa (PSM). De um modo geral, uma PMT é usada para descrever um fluxo de transporte, enquanto um PSM é usado para descrever um fluxo de programa. Tal como descrito em maiores detalhes com relação ao exemplo da Figura 2 mais adiante, o multiplexador 30 pode compreender ou interagir com uma unidade de armazenamento de dados que associa fluxos elementares recebidos a partir do codificador de áudio 26 e do codificador de vídeo 28 com programas e, assim sendo, com os respectivos fluxos de transporte e/ou fluxos de programa.

[00054] A norma dos sistemas MPEG-2 permite extensões do sistema por meio de “descritores”. Tanto os PSM como as PMT incluem loops/enlaces descritores em que podem ser inseridos um ou mais descritores. De um modo geral, um descritor compreende uma estrutura que pode ser usada para estender a definição de programas e/ou elementos de programas. A presente invenção descreve dois descritores para efetuar as técnicas da presente invenção: um descritor de extensão de MVC e um descritor de hierarquia. De um modo geral, o descritor de extensão de MVC da presente invenção amplia o descritor de extensão de MVC convencional por identificar especificamente os índices de ordem de vista de vistas ou quadros que estão embutidas em uma fluxo de programa ou fluxo de transporte; enquanto o descritor de hierarquia da presente invenção inclui um flag ou sinalizador que indica se um elemento de programa associado aumenta o número das vistas do fluxo de bits resultante do elemento de programa que é referenciado por um elemento do descritor de hierarquia.

[00055] As normas de compressão de vídeo, tais como a ITU-T H.261, H.263, MPEG-1, MPEG-2 e H.264/MPEG-4 seção 10, fazem uso de predição temporal compensada por movimento para reduzir a redundância temporal. O codificador usa uma predição compensada por movimento proveniente de algumas imagens previamente codificadas (também aqui designadas como quadros) para prever as imagens codificados de fluxos de acordo com vetores de movimento. Existem três tipos de imagem principais na típica codificação de vídeo. Elas são a imagem intracodificada (“I-imagens” ou “I-quadros”), imagens preditas (“P-imagens” ou “P-quadros) e imagens preditas bidirecionais (“B-imagens” ou “B-quadros”). As p-imagens usam apenas a imagem de referência antes da imagem atual na ordem temporal. Em uma b-imagem, cada bloco da b-imagem pode ser predita a partir de uma ou duas imagens de referência. Tais imagens de referência poderiam estar localizadas antes ou após a imagem fluxo em ordem temporal.

[00056] De acordo com a norma de codificação H.264, por exemplo, as b-imagens usam duas listas de imagens de referência previamente codificadas, a lista 0 e a lista 1. Essas duas listas podem, cada uma, conter imagens codificadas passadas e/ou futuras em ordem temporal. Os blocos em uma b-imagem pode ser predita de diversas formas: predição compensada em movimento a partir de uma imagem de referência de lista 0, predição compensada em movimento a partir de uma imagem de referência de lista 1, ou predição compensada em movimento a partir da combinação de imagens de referência de lista 0 e lista 1. para obter a combinação de imagens de referência de lista 0 e lista 1, são obtidas duas áreas de referência compensadas em movimento a partir da imagem de referência da lista 0 e da lista 1 respectivamente. Tal combinação será usada para prever o bloco atual.

[00057] A norma ITU-T H.264 dá suporte à intrapredição em vários tamanhos de blocos, tais como 16 por 16, 8 por 8, ou 4 por 4 para componentes luma, e 8 x 8 para componentes chroma, bem como a interpredição em vários tamanhos de blocos, tais como 16 x 16, 16 x 8, 8 x 16, 8 x 8, 8 x 4, 4 x 8 e 4 x 4, para componentes luma, e tamanhos escalonados correspondentes para componentes chroma. Na presente descrição, “x” e “por” podem ser usados de forma intercambiável para fazer referência às dimensões em pixels do bloco em termos de suas dimensões vertical e horizontal, por exemplo 16 x 16 pixels, ou 16 por 16 pixels. De um modo geral, um bloco 16 x 16 possuirá 16 pixels em uma direção vertical (y = 16) e 16 pixels em uma direção horizontal (x = 16). De forma similar, um bloco N x N possui de um modo geral N pixels em uma direção vertical e N pixels em uma direção horizontal, em que N representa um valor inteiro e não negativo. Os pixels em um bloco podem ser dispostos em fileiras e colunas.

[00058] Os tamanhos de blocos que são menores que 16 por 16 podem ser designados como partições de um macrobloco de 16 por 16. Os blocos de vídeo podem compreender blocos de dados de pixels no domínio dos pixels, ou blocos de coeficientes de transformadas no domínio das transformadas, por exemplo após a aplicação de uma transformada tal como uma transformada de cosseno individual (DCT), uma transformada de integração, uma transformada de ondulação, ou uma transformada conceitualmente similar aos dados de bloco de vídeo residuais representando diferenças de pixels entre blocos de vídeo codificados e blocos de vídeo preditivos. Em alguns casos, um bloco de vídeo pode compreender blocos de coeficientes de transformadas quantificados no domínio das transformadas.

[00059] Blocos de vídeo menores podem prover melhor resolução, podendo ser usados para locais de um quadro de vídeo que inclui níveis elevados de detalhes. De um modo geral, os macroblocos e as diversas partições, algumas vezes designadas como sub-blocos, podem ser considerados como blocos de vídeo. Além disso, uma fatia pode ser considerada como sendo uma pluralidade de blocos de vídeo, tais como macroblocos e/ou sub-blocos. Cada fatia pode ser uma unidade independentemente decodificável de um quadro de vídeo. Alternativamente, os próprios quadros podem ser unidades decodificáveis, ou outras partes de um quadro podem ser definidas como unidades decodificáveis. O termo “unidade codificada”, ou “unidade de codificação”, pode se referir a qualquer unidade independentemente decodificável de um quadro de vídeo tal como todo um quadro, uma fatia de um quadro, um grupo de imagens (GOP), também designado como uma sequência, ou outra unidade independentemente decodificável definida de acordo com técnicas de codificação aplicáveis.

[00060] O termo macrobloco se refere a uma estrutura de dados para codificar dados de imagem e/ou vídeo de acordo com um arranjo bidimensional de pixels que compreende 16 x 16 pixels. Cada pixel compreende uma componente de crominância e uma componente de luminância. Assim sendo, o macrobloco pode definir quatro blocos de luminância, cada um compreendendo um arranjo bidimensional de 8 x 8 pixels, dois blocos de crominância, cada um compreendendo um arranjo de 16 x 16 pixels, e um cabeçalho compreendendo informações de sintaxe, tais como um arranjo ou disposição de bloco codificado (CBP), um modo de codificação (por exemplo, modos de intra (I), ou inter (P ou B) codificação), um tamanho de partição para partições de um bloco intracodificado (por exemplo, 16 x 16, 16 x 8, 8 x 16, 8 x 8, 8 x 4, 4 x 8, ou 4 x 4), ou um ou mais vetores de movimento para um macrobloco intercodificado.

[00061] O codificador de vídeo 28, o decodificador de vídeo 48, o codificador de áudio 26, o decodificador de áudio 46, o multiplexador 30 e o demultiplexador 38, podem, cada um, ser implementados na forma de qualquer um dentre uma variedade de circuitos de codificador ou decodificador, conforme se aplique, tal como um ou mais microprocessadores, processadores de sinais digitais (DSP), circuitos integrados específicos para aplicação (ASIC), arranjos de porta programáveis no campo (FPGA), circuitos lógicos individuais, software, hardware, firmware, ou quaisquer combinações de tais. Cada codificador de vídeo 28 e decodificador de vídeo 48 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um codificador/decodificador (CODEC) combinado de vídeo. De forma similar, cada um dentre o codificador de áudio 26 e o decodificador de áudio 46 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um codificador/decodificador (CODEC) combinado de áudio. Um equipamento incluindo o codificador de vídeo 28, o decodificador de vídeo 48, o codificador de áudio 26, o decodificador de áudio 46, o multiplexador 30 e/ou o demultiplexador 38 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, tal como um telefone celular.

[00062] As técnicas da presente invenção podem oferecer certas vantagens em relação às técnicas convencionais para subfluxos de bits de MVC, as quais desabilitam o suporte das características de sinalização de alguns pontos de operação. Ao contrário das técnicas convencionais, os elementos de sintaxe e a semântica do descritor de extensão MVC da presente invenção permitem valores não consecutivos de índices de ordem de vista, dessa forma tornando possível dar suporte a um fluxo de bits ou a um subfluxo de bits de acordo com a MVC e com valores de índice de ordem de vista que não são consecutivos. A presente invenção propõe também um descritor de hierarquia para sinalização de ampliação de vista, o que permite a um decodificador determinar que uma subfluxo de bits MVC se baseia em outras vistas para uma decodificação bem-sucedida.

[00063] Para prover um melhor suporte de sinalização de características, os valores de índices de ordem de vista, tal como sinalizados no descritor de extensão MVC proposto, podem opcionalmente ser não consecutivos. Além disso, os valores de índices de ordem de vistas ou os valores de view_id podem ser sinalizados no descritor de extensão MVC.

[00064] Como uma alternativa, pode ser usado um mecanismo de re-mapeamento de índices de ordem de vista o qual mapeia os valores de índices de ordem de vista das vistas de um subfluxo de bits MVC conforme com ele para valores consecutivos de índices de ordem de vista, por modificação da ordem de vista definida na extensão ativa convencional do conjunto de parâmetros de sequência (SPS) de MVC, antes que tal subfluxo de bits MVC seja multiplexada. Em tal mecanismo, o descritor de extensão MVC convencional é usado para sinalizar IDs de vistas, em lugar dos índices de ordem de vista, e portanto um codificador pode ser reconfigurado para codificar as vistas como possuindo diferentes IDs de vistas, enquanto o decodificador pode ser reconfigurado para interpretar o descritor de extensão MVC convencional de forma diferente, de acordo com a ordem de codificação reconfigurada. Como exemplo, vamos supor que existam três vistas com view_ids 0, 1 e 2, possuindo índices de ordem de vista 0, 1 e 2, respectivamente. Vamos também presumir que um serviço requer apenas a vista 0 e a vista 2. O codificador pode codificar as vistas em uma ordem correspondente aos IDs de vista 0, 2, 1, de tal forma que o descritor de extensão SPS MVC convencional pode ser usado para sinalizar os valores de view_id com uma ordem de 0, 2, 1. Dessa forma, a vista 2 pode possuir um índice de ordem de vista como 1, de forma a que a combinação da vista 0 e da vista 2 possua índices de ordem de vista consecutivos.

[00065] Adicionalmente, para evitar duplicações da unidade NAL de prefixo quando está presente ao subfluxo de bits de vídeo AVC de MVC, a presente invenção propõe que deve ser definida um subfluxo de bits MVC de prefixo e que, em alguns exemplos, tal subfluxo de bits MVC de prefixo seja incluída quando existir pelo menos um subfluxo de bits MVC. Além disso, a presente invenção propõe que as mensagens SEI específicas de MVC, isto é, as mensagens SEI que estão definidas no Anexo H da especificação AVC, pertencentes à vista base, ou as mensagens MVC SEI que se aplicam a todas as vistas do subfluxo de bits MVC, podem ser associadas no interior de tal “subfluxo de bits MVC de prefixo” para permitir armazenamento e transporte eficientes, em termos de tamanho de armazenamento ou otimização de amplitude de banda. A presente invenção propõe também que a mesma ideia pode ser aplicada ao transporte de vídeo escalonável através de sistemas MPEG-2, também designado como a Amendment 3 of Information Technology - Generic Coding of Moving Pictures and Associated Audio Information: Systems (designados na presente descrição como “Sistemas MPEG-2” ou “norma de Sistemas MPEG-2”).

[00066] Após o multiplexador 30 ter montado uma unidade NAL e/ou uma unidade de acesso a partir de dados recebidos, o multiplexador 30 passa a unidade para a interface de saída 32 para emissão. A interface de emissão 32 pode compreender, por exemplo, um transmissor, um transreceptor, um dispositivo para gravar dados em um meio legível por computador, tal como, por exemplo, um drive óptico, um drive de mídia magnética (por exemplo, um drive de disquete), uma porta USB (Universal Serial Bus), uma interface de rede, ou outra interface de emissão. A interface de emissão/saída 32 emite a unidade NAL ou unidade de acesso para um meio legível por computador 34, tal como, por exemplo, um sinal de transmissão, um meio magnético, um meio óptico, uma memória, um drive flash, ou outro meio legível por computador.

[00067] Eventualmente, a interface entrada 36 recupera os dados a partir do meio legível por computador 34. A interface de alimentação 36 pode compreender, por exemplo, um drive óptico, um drive de mídia magnética, uma porta USB, um receptor, um transreceptor, ou outra interface de meio legível por computador. A interface de alimentação 36 pode prover a unidade NAL ou unidade de acesso para o demultiplexador 38. O demultiplexador 38 pode demultiplexar um fluxo de transporte ou fluxo de programa em seus fluxos PES constituintes, desempacotar os fluxos PES para recuperar os dados codificados e enviar os dados codificados para o decodificador de áudio 46 ou para o decodificador de vídeo 48, dependendo de se os dados codificados fazem parte de um fluxo de áudio ou vídeo, por exemplo tal como indicado pelos cabeçalhos de pacote PES do fluxo. O decodificador de áudio 46 decodifica os dados de áudio codificados e envia os dados de áudio decodificados para a saída de áudio 42, enquanto o decodificador de vídeo 48 decodifica os dados de vídeo codificados e envia os dados de vídeo decodificados, os quais podem incluir uma pluralidade de vistas de um fluxo, para a saída de vídeo 44. A saída de vídeo 44 pode compreender um display que usa uma pluralidade de vistas de uma cena, por exemplo um display estereoscópico ou auto estereoscópico que apresenta cada vista de uma cena simultaneamente.

[00068] Além disso, o demultiplexador 38 pode reordenar as vistas de um ou mais subfluxos de bits de tal forma que os índices de ordem de vista do fluxo apresentem uma ordem estritamente crescente, por exemplo, quando pelo menos uma vista de uma subfluxo de bits embutido possui uma vista com um índice de ordem de vista que é menor que um índice de ordem de vista de uma vista de um subfluxo de bits primário em que o subfluxo de bits embutido está embutida. Dessa forma, o dispositivo A/V de destino 40 pode corresponder a um equipamento compreendendo um demultiplexador que produz um fluxo de bits de acordo com a norma MVC a partir de um fluxo de bits recebido.

[00069] A Figura 2 é um diagrama de blocos que ilustra um exemplo de disposição de componentes do multiplexador 30 (da Figura 1). No exemplo da Figura 2, o multiplexador 30 inclui a unidade de gerenciamento de fluxos 60, a interface de alimentação de vídeo 80, a interface de alimentação de áudio 82, a interface de saída de fluxo multiplexado 84 e tabelas de informações específicas de programa 88. A unidade de gerenciamento de fluxos 60 inclui o construtor de unidade NAL 62, o construtor de PMT 64, a unidade de consulta de identificador de fluxo (ID de fluxo) 66 e a unidade de designação de identificador de programa (PID) 68.

[00070] No exemplo da Figura 2, a interface de alimentação de vídeo 80 e a interface de alimentação de áudio 82 incluem respectivos empacotadores para a formação de unidades PES a partir de dados de vídeo codificados e dados de áudio codificados. Como outro exemplo, os empacotadores de vídeo e/ou áudio podem estar presentes externamente ao multiplexador 30. com referência ao exemplo da Figura 2, a interface de alimentação de vídeo 80 pode formar pacotes PES a partir de dados de vídeo codificados recebidos a partir do codificador de vídeo 28 e a interface de alimentação de áudio 82 pode formar pacotes PES a partir de dados de áudio codificados recebidos a partir do codificador de áudio 26.

[00071] A unidade de gerenciamento de fluxos 60 recebe pacotes PES provenientes da interface de alimentação de vídeo 80 e da interface de alimentação de áudio 82. Cada pacote PES inclui um ID de fluxo que identifica o fluxo elementar à qual pertence o pacote PES. A unidade de consulta de ID de fluxo 66 pode determinar um programa ao qual corresponde o pacote PES inquirindo as tabelas de informações específicas de programas 88. Isto é, a unidade de consulta de ID de fluxo 66 pode determinar a qual programa corresponde um pacote PES recebido. Cada programa pode compreender uma pluralidade de fluxos elementares, enquanto que, de um modo geral, um fluxo elementar corresponde a apenas um programa. No entanto, em alguns exemplos um fluxo elementar pode ser incluído em uma pluralidade de programas. Cada pacote PES pode ser incluído em uma pluralidade de fluxos emitidos a partir do multiplexador 30, dado que vários serviços podem incluir, cada um, vários subconjuntos de fluxos de áudio e vídeo disponíveis. Assim sendo, a unidade de consulta de ID de fluxo 66 pode determinar se um pacote PES deve ser incluído em um ou mais fluxos de saída (por exemplo, uma ou mais fluxos de transporte ou programa) e em particular em quais dos fluxos de saída incluir o pacote PES.

[00072] Como exemplo, cada fluxo elementar corresponde a um programa. O multiplexador 30 pode ser responsável por assegurar que cada fluxo elementar esteja associado a um programa específico e, assim sendo, a um ID de programa (PID). Quando um pacote PES é recebido incluindo um ID de fluxo que não é reconhecido pelo multiplexador 30 (por exemplo, um ID de fluxo não armazenado nas tabelas de informações específicas de programas 88), a unidade de designação de PID 68 cria uma ou mais novas entradas nas tabelas de informações específicas de programas 88 para associar o novo ID de fluxo a um PID não utilizado.

[00073] Após determinar um programa ao qual corresponde um pacote PES, o construtor de unidades NAL 62 forma uma unidade NAL compreendendo o pacote PES, por exemplo encapsulando o pacote PES com um cabeçalho de unidade NAL, incluindo o PID do programa ao qual corresponde o ID de fluxo do pacote PES. Como exemplo, o construtor de unidade NAL 62, ou outra subunidade da unidade de gerenciamento de fluxo 60, pode formar uma unidade de acesso compreendendo uma pluralidade de unidades NAL.

[00074] O construtor de PMT 64 cria tabelas de mapas de programas (PMTs) para um fluxo de saída correspondente do multiplexador 30 usando informações provenientes das tabelas de informações específicas de programas 88. Como outro exemplo, a unidade de gerenciamento de fluxo 60 pode compreender um construtor de PSM para criar mapas de fluxo de programa para um fluxo de programa emitida pelo multiplexador 30. Em alguns exemplos, o multiplexador 30 pode compreender tanto o construtor de PMT 64 como um construtor de PSM, e emitir qualquer um, ou ambos, dentre um fluxo de transporte e um fluxo de programa. No exemplo da Figura 2, o construtor de PMT 64 pode construir um PMT incluindo os descritores prescritos na presente invenção, por exemplo um descritor de ampliação de MVC e um descritor de hierarquia, bem como quaisquer outros descritores e dados de PMT necessários para a PMT. O construtor de PMT 64 pode enviar periodicamente, por exemplo após um certo período de tempo, ou após a transmissão de uma certa quantidade de dados, um PMT subsequente para o fluxo de transporte. O construtor de PMT 64 pode passar os PMTs criados para o construtor de unidades NAL 62 para formar uma unidade NAL compreendendo o PMT, por exemplo por encapsulamento da PMT com um cabeçalho de unidade NAL correspondente, incluindo o PID correspondente.

[00075] A interface de saída de fluxo multiplexado 84 pode receber uma ou mais unidades NAL e/ou unidades de acesso provenientes da unidade de gerenciamento de fluxos 60, por exemplo unidades NAL compreendendo pacotes PES (por exemplo, dados de áudio ou vídeo) e/ou unidades NAL compreendendo um PMT. Como exemplo, a interface de saída de fluxo multiplexado 84 pode formar unidades de acesso a partir de uma ou mais unidades NAL correspondentes a uma localização temporal comum após as unidades NAL serem recebidas a partir da unidade de gerenciamento de fluxos 60. A interface de saída de fluxo multiplexado 84 transmite as unidades NAL ou unidades de acesso como saída em um correspondente fluxo de transporte ou fluxo de programa.

[00076] A Figura 3 é um diagrama de blocos que ilustra um exemplo de conjunto de tabelas de informações específicas por programas 88. O fluxo elementar à qual pertence um pacote de transporte pode ser determinada com base no valor de PID do pacote de transporte. Para que um decodificador decodificar apropriadamente os dados recebidos, o decodificador deve ser capaz de determinar quais fluxos elementares pertencem a cada programa. As informações específicas de programa, tal como incluídas na tabela de informações específicas por programa 88, podem especificar explicitamente as relações entre os programas e os fluxos elementares componentes. No exemplo da Figura 3, as tabelas de informações específicas por programas 88 incluem a tabela de informações de rede 100, a tabela de acesso condicional 102, a tabela de acesso de programa 104 e a tabela de mapas de programa 106. Para o exemplo da Figura 3 é presumido que a fluxo de saída compreende um fluxo de transporte MPEG-2. Em um exemplo alternativo, a fluxo de saída pode compreender um fluxo de programa, caso este em que a tabela de mapas de programa 106 pode ser substituída por um mapa de fluxos de programa.

[00077] A especificação de sistemas MPEG-2 especifica que cada programa portado em um fluxo de transporte possui uma tabela de mapas de programa, tal como a tabela de mapas de programa 106, a ele associada. A tabela de mapas de programa 106 pode incluir detalhes a respeito do programa e os fluxos elementares que o programa inclui. Como exemplo, o programa, identificado como o programa número 3, pode conter um fluxo elementar de vídeo com PID 33, um fluxo de áudio em inglês com PID 57, e um fluxo de áudio em chinês com PID 60. É permitido a um PMT inclui mais de um programa.

[00078] A tabela de mapas de programa básico especificada pela especificação dos sistemas MPEG-2 pode ser acrescida com alguns dentre os vários descritores, por exemplo os descritores 108, especificados na especificação dos sistemas MPEG-2. Os descritores 108 podem incluir qualquer um, ou todos, os descritores especificados da especificação dos sistemas MPEG-2. De um modo geral, os descritores, tais como os descritores 108, portam outras informações a respeito de um programa ou de seus fluxos elementares componentes. Os descritores podem incluir parâmetros de codificação de vídeo, parâmetros de codificação de áudio, identificação de idioma, informações de pesquisa e varredura (pan-and-scan) detalhes de acesso condicional, informações sobre copyright, ou outras informações similares. Um difusor ou outro usuário pode definir descritores privados adicionais.

[00079] A presente invenção utiliza dois descritores de modo a permitir que índices de ordem de vista não consecutivos sejam portados em um fluxo de saída, tal como um fluxo de transporte ou um fluxo de programa. Tal como ilustrado na Figura 2, os dois descritores da presente invenção incluem o descritor de extensão MVC 110 e o descritor de hierarquia 112. Nos fluxos elementares componentes relacionados a vídeo existe também um descritor de hierarquia, que provê informações para identificar os elementos de programa contendo componentes de fluxos de vídeo, áudio e privadas hierarquicamente codificadas.

[00080] Em um exemplo em que a saída do multiplexador 30 compreende um fluxo de programa, as tabelas de informações específicas por programas 88 podem incluir um mapa de fluxos de programa (PSM). Um PSM pode prover uma descrição dos fluxos elementares no fluxo de programa correspondente e as relações mutuas dos fluxos elementares. Em alguns exemplos, um mapa de fluxos de programa pode também corresponder a um fluxo de transporte. Quando transportada em um correspondente fluxo de transporte, a estrutura PSM não deve ser modificada. O multiplexador 30 pode indicar que um PSM está presente em um pacote PES ajustando o valor stream_id do pacote PES para 0xBC, isto é, o valor hexadecimal BC, que corresponde ao valor binário 10111100, ou ao valor decimal 188.

[00081] O multiplexador 30 mantém uma lista completa de todos os programas disponíveis em um fluxo de transporte na tabela de associação de programas 104. O multiplexador 30 pode também embutir tabelas de associação de programas nas unidades NAL. O multiplexador 30 pode indicar que uma unidade NAL inclui uma tabela de associação de programas por designação à unidade NAL de um valor PID de 0. O multiplexador 30 pode listar cada programa, juntamente com o valor PID dos pacotes de transporte que contêm a tabela de mapas de programa correspondente, na tabela de associação de programas 104. Usando o mesmo exemplo acima mencionado, a tabela de mapas de programas exemplar que especifica os fluxos elementares do programa número 3 possui um PID de 1001 e outro PMT possui outro PID de 1002. Tal conjunto de informações pode ser incluído na tabela de associação de programas 104.

[00082] Na tabela de informações de rede (NIT) e na tabela de acesso condicional (CAT) o número de programa zero, especificado na PAT possui significado especial. Em particular, o programa número zero é usado para apontar o caminho para a tabela de informações de rede. A tabela é opcional e quando presente se destina a prover informações a respeito da rede física que porta o fluxo de transporte, tal como frequências de canal, detalhes de transponder de satélite, características de modulação, originador de serviço, nome de serviço e detalhes de redes alternativas disponíveis.

[00083] Caso quaisquer dos fluxos elementares dentro de um fluxo de transporte sejam embaralhadas, então deve estar presente uma tabela de acesso condicional. A tabela provê detalhes dos sistemas de embaralhamento em uso e provê os valores PID de pacotes de transporte que contêm as informações de gerenciamento de acesso condicional e habilitação. O formato de tais informações não está especificado na MPEG-2.

[00084] A Figura 4 é um diagrama de blocos que ilustra um exemplo de conjunto de dados que podem ser incluídos em um descritor de extensão de codificação de vídeo multivista (MVC) 110. No exemplo da Figura 4, o descritor de extensão MVC 110 inclui um campo de tag de descritor 120, um campo de comprimento de descritor 122, um campo de taxa de bits média 124, um campo de taxa de bits máxima 126, um campo reservado 128, um campo de início de identificador (ID) temporal 130, um campo de final de ID temporal 132, um campo de nenhuma unidade NAL de informações de ampliação suplementar (SEI) NAL 134, um ou mais campos de índice de ordem de vista 136, e um ou mais campos de bits terminais reservados 138. O descritor de extensão MVC 110 também especifica um ponto de operação, que corresponde a um subfluxo de bits MVC. As profundidades de bits dos campos do descritor de extensão MVC 110 a seguir correspondem a um exemplo de um descritor de extensão MVC. Outros exemplos podem incluir outras profundidades de bits, valores, ou faixas para sinalizar individualmente cada índice de ordem de vista de cada vista incluída no fluxo de bits ou subfluxo de bits correspondente.

[00085] O campo de tag de descritor 120 corresponde a um campo de tag de descritor de oito bits que é incluído em cada descritor, tal como determinado pela norma dos sistemas MPEG-2, para identificar especificamente o descritor. A norma dos sistemas MPEG-2 define certos tags de descritor e marca outros valores de tag de descritor, por exemplo os valores 36 a 63, como “reservados”. As técnicas da presente invenção propõem ajustar o valor do campo de tag de descritor 120 para o descritor de extensão MVC 110 para “49”, o que corresponde a um dos tags de descritor reservados tal como especificado na norma dos sistemas MPEG-2.

[00086] O campo de comprimento de descritor 122 corresponde a um campo de comprimento de descritor de oito bits que também é incluído em cada descritor, tal como determinado pela norma dos sistemas MPEG-2. O multiplexador 30 pode ajustar o valor do campo de comprimento de descritor 122 como igual ao número de bytes do descritor de extensão MVC 110 imediatamente após o campo de comprimento de descritor 122. Dado que o descritor de extensão MVC 110 pode compreender um comprimento variável, por exemplo com base em um número de índices de ordem de vista 136 incluídos na instância específica do descritor de extensão MVC 110 , o multiplexador 30 calcula o tamanho da instância do descritor de extensão MVC 110 e ajusta adequadamente o valor do campo de comprimento de descritor 122 da instância do descritor.

[00087] O campo de taxa de bits média 124 compreende um campo de dezesseis bits que indica a taxa de bits média, em kilobits por segundo, de um fluxo de vídeo AVC reagrupado. Isto é, o campo de taxa de bits média 124 descreve a taxa de bits média para um fluxo de vídeo quando o fluxo de vídeo é montado a partir das partes constituintes do fluxo de transporte ou fluxo de programa à qual o descritor de extensão MVC 110 corresponde. Em alguns exemplos, o multiplexador 30 pode ajustar o valor do campo de taxa de bits média 124 para zero para indicar que a taxa de bits média não está indicada pelo descritor de extensão MVC 110.

[00088] O campo de taxa de bits máxima 126 compreende um campo de dezesseis bits que indica a taxa de bits máxima, em kilobits por segundo, de um fluxo de vídeo AVC reagrupada. Isto é, o campo de taxa de bits máxima 126 descreve a taxa de bits máxima para um fluxo de vídeo quando o fluxo de vídeo é montado a partir das partes constituintes do fluxo de transporte ou fluxo de programa à qual o descritor de extensão MVC 110 corresponde. Em alguns exemplos, o multiplexador 30 pode ajustar o valor do campo de taxa de bits máxima 126 para zero para indicar que a taxa de bits média não está indicada pelo descritor de extensão MVC 110.

[00089] O campo de início de ID temporal 130 compreende um campo de três bits que indica o valor mínimo do temporal_id do elemento de sintaxe de cabeçalho de unidade NAL de todas as unidades NAL contidas no subfluxo de bits de vídeo MVC associada. Isto é, um valor de ID temporal é incluído em um cabeçalho para cada unidade NAL. De um modo geral, o valor de ID temporal corresponde a uma taxa de quadros específica, em que valores de ID temporal relativamente maiores correspondem a taxas de quadros mais elevadas. Como exemplo, um valor de “0” para um ID temporal pode corresponder a uma taxa de quadros de 15 quadros por segundo (fps), um valor de “1” para um ID temporal pode corresponder a uma taxa de quadros de 30 fps. Dessa forma, a reunião de todas as imagens possuindo um ID temporal de 0, neste exemplo, em um conjunto pode ser usada para a formação de um segmento de vídeo possuindo uma taxa de quadros de 15 fps, enquanto que a reunião de todas as imagens possuindo um ID temporal de 1 em um conjunto diferente pode ser usada para a formação de um segmento de vídeo diferente possuindo uma taxa de quadros de 30 fps. O multiplexador 30 determina a menor ID temporal de todas as unidades NAL do subfluxo de bits de vídeo MVC e ajusta o valor do campo de início de ID temporal 130 como igual a tal valor menor de ID temporal determinado.

[00090] O campo de final de ID temporal 132 compreende um campo de três bits que indica o valor máximo do ID temporal do elemento de sintaxe de cabeçalho de unidade NAL dentre todas as unidades NAL contidas no subfluxo de bits de vídeo MVC associada. Assim sendo, o multiplexador 30 determina o maior ID temporal de todas as unidades NAL do subfluxo de bits de vídeo MVC e ajusta o valor do campo de início de ID temporal 130 como igual a tal maior valor de ID temporal determinado.

[00091] O campo de nenhuma unidade SEI NAL presente 134 compreende um flag de um bit que, quando ajustado para “1”, indica que nenhuma unidade NAL de informações de ampliação suplementares está presente no subfluxo de bits de vídeo associado. O multiplexador 30 pode determinar se uma ou mais unidades NAL de informações de ampliação suplementares foram posicionados no fluxo de bits e ajustar o valor do campo de nenhuma unidade SEI NAL presente 134 para um valor de “1” quando não existam quaisquer unidades SEI NAL no fluxo de bits, ou ajustar o valor do campo de nenhuma unidade SEI NAL presente 134 para um valor de “0” quando pelo menos uma unidade SEI NAL esteja presente no fluxo de bits.

[00092] Em um aspecto, as técnicas da presente invenção descrevem a modificação de descritores de extensão MVC convencionais de modo a incluir um ou mais campos de índice de ordem de vista 136, representados pelo uso de um loop tal como apresentado na Tabela 1 mais adiante. Cada um dos campos de índice de ordem de vista 136 compreende um campo de 10 bits que indica o valor do índice de ordem de vista de uma unidade correspondente dentre as unidades NAL contidas no subfluxo de bits de vídeo MVC associado. O multiplexador 30 pode ajustar os valores dos campos de índice de ordem de vista 136 de acordo com os índices de ordem de vista das vistas incluídas no subfluxo de bits de vídeo MVC. Além disso, os valores dos campos de índice de ordem de vista 136 podem ser sinalizados em ordem ascendente. Dessa forma, o descritor de extensão MVC 110 pode descrever índices de ordem de vista não consecutivos de vistas incluídas no subfluxo de bits de vídeo MVC.

[00093] No exemplo da Figura 4, o descritor de extensão MVC 110 compreende também campos de bits terminais reservados 138. A presente invenção descreve a reserva de tais bits para um propósito futuro, sem especificar como tais valores serão necessariamente usados. Em vários exemplos, os bits terminais reservados podem ser representados na forma de um único segmento contínuo reservado de bits do descritor de extensão MVC 110, ou como um loop sobre uma pluralidade de bits individuais.

[00094] A Tabela 1 a seguir descreve os elementos de sintaxe do descritor de extensão MVC 110 da presente invenção. A Tabela 1 descreve também, para cada elemento de sintaxe, um certo número de bits usados para representar o elemento de sintaxe e um elemento mnemônico que descreve um tipo para o elemento de sintaxe. O número de bits corresponde ao número de bits que são alocados para o correspondente elemento de sintaxe quando o descritor de extensão MVC 110 é transmitido em um fluxo de bits codificado. Mnemônicos são usados na norma de sistemas MPEG-2 para descrever diferentes tipos de dados que são usados no fluxo de bits codificado. Os mnemônicos usados na presente invenção incluem “uimsbf”, que a norma dos sistemas MPEG-2 define como um número inteiro não assinado possuindo o bit mais significativo em primeiro lugar, e “bslbf”, que a norma dos sistemas MPEG-2 define como um string de bits com o bit esquerdo em primeiro lugar, em que “esquerdo” é a ordem em que os strings de bits são escritos na norma dos sistemas MPEG-2. Cada um dos elementos de sintaxe no exemplo da Tabela 1 corresponde a um respectivo elemento dentre os elementos de sintaxe acima descritos com referência ao descritor de extensão MVC 110. em particular, a presente invenção provê o loop “for” na Tabela 1 para índices de ordem de vista particulares para cada vista de um fluxo de programa ou um fluxo de transporte. Dessa forma, o loop “for” no descritor de extensão MVC da Tabela 1 pode ser usado para sinalizar que um fluxo de bits da norma do sistema MPEG-2 correspondente compreende uma primeira vista de uma cena associada a um primeiro índice de ordem de vista e uma segunda vista da cena associada a um segundo índice de ordem de vista, em que o primeiro índice de ordem de vista e o segundo índice de ordem de vista não são consecutivos. TABELA 1 - Descritor de extensão MVC

[00095] Em outro exemplo, os bits terminais reservados podem em lugar disto ser individualmente sinalizados. A Tabela 2 a seguir ilustra um exemplo de descritor de extensão MVC que sinaliza cada um dos bits terminais reservados individualmente. TABELA 2 - Descritor de extensão MVC com bits terminais individualmente sinalizados

[00096] A Figura 5 é um diagrama de blocos que ilustra um exemplo de conjunto de dados que podem ser incluídos em um descritor de hierarquia 112. No exemplo da Figura 5, o descritor de hierarquia 112 inclui o campo de tag de descritor 150, o campo de comprimento de descritor 152, o campo de flag de ampliação de vista 154, o campo de flag de escalonamento temporal 156, o campo de flag de escalonamento espacial 158, o campo de flag de escalonamento de qualidade, o campo de tipo de hierarquia 162, o campo reservado 164, o campo de índice de camada de hierarquia 166, o campo de flag de TREF presente 168, o campo reservado 170, o campo de índice de camada embutida de hierarquia 172, o campo reservado 174 e o campo de canal de hierarquia 176. Para melhorar a sinalização, a relação de escalonamento de vista e/ou dependência de vista, as técnicas da presente invenção podem prover que um flag seja sinalizado no descritor de hierarquia, o que indica se o elemento de programa associado aumenta o número das vistas do fluxo de bits resultante do elemento de programa referenciado pelo índice de camada embutida de hierarquia.

[00097] Como foi acima mencionado, a especificação dos sistemas MPEG-2 especifica que cada descritor inclua um campo de flag de descritor e um campo de comprimento de descritor. Assim sendo, o descritor de hierarquia 112 inclui o campo de tag de descritor 150 e o campo de comprimento de descritor 152. De acordo com a norma dos sistemas MPEG-2, o multiplexador 30 pode ajustar o valor do campo de tag de descritor 150 para um valor de “4” para o descritor de hierarquia 112.

[00098] O comprimento do descritor de hierarquia 112 pode ser determinado a priori, pois cada instância do descritor de hierarquia 112 deve incluir a mesma quantidade de dados. Como exemplo, com referência à Tabela 3 mais adiante, o multiplexador 30 pode ajustar o valor do campo de comprimento de descritor 152 para um valor de 32, indicativo do número de bits em uma instância do descritor de hierarquia 112 seguindo-se ao final do campo de comprimento de descritor 152.

[00099] As técnicas da presente invenção propõem a adição de um campo de flag de ampliação de vista 154 ao descritor de hierarquia convencional, De acordo com as técnicas da presente invenção, o campo de flag de ampliação de vista 154 pode compreender um flag de um bit, o qual, quando ajustado para “0” indica que o elemento de programa associado amplia o número de vistas do fluxo de bits resultante do elemento de programa referenciado por um índice de camada embutido de hierarquia. As técnicas da presente invenção propõem também reservar o valor de “1” para o campo de flag de ampliação de vista 154.

[000100] O campo de tipo de hierarquia 162 descreve a relação hierárquica entre a camada de hierarquia associada e sua camada embutida de hierarquia. Como exemplo, o multiplexador 30 ajusta o valor do campo de tipo de hierarquia 162 com base na relação hierárquica, por exemplo tal como descrito pela Tabela 4 mais adiante. Como exemplo, quando o escalonamento se aplica em mais de uma dimensão, o multiplexador 30 pode ajustar o campo de tipo de hierarquia 162 para um valo de “8” (“escalonamento combinado”, tal como ilustrado na Tabela 4), e o multiplexador 30 ajusta os valores do campo de flag de escalonamento 156, do campo de flag de escalonamento espacial 158, e do campo de flag de escalonamento de qualidade 160, de acordo com dados recuperados a partir de pacotes PES e cabeçalhos de pacotes PES dos respectivos fluxos. De um modo geral, o multiplexador 30 pode determinar dependências entre os diferentes fluxos correspondentes às várias vistas e/ou fluxos de dados de áudio. O multiplexador 30 pode também determinar se um fluxo dependente que compreende uma camada de ampliação é uma camada espacial, uma camada de ampliação de razão de sinal para ruído (SNR), uma camada de ampliação de qualidade, ou outro tipo de camada de ampliação.

[000101] Como outro exemplo, para subfluxos de bits de vídeo MVC, o multiplexador 30 pode ajustar o campo de tipo de hierarquia 162 para um valor de “9” (“MVC”, tal como ilustrado na Tabela 4) e pode ajustar os valores de cada um dentre os campos de flag de escalonamento 156, flag de escalonamento espacial 158 e flag de escalonamento de qualidade 160, para “1”. Como outro exemplo, para subfluxos de bits de vista base MVC, o multiplexador 30 pode ajustar o valor do campo de tipo de hierarquia 162 para um valor de “15” e pode ajustar os valores dos campos de flag de escalonamento 156, flag de escalonamento espacial 158 e flag de escalonamento de qualidade 160, para “1”. Como outro exemplo, para subfluxos de bits de prefixo MVC, o multiplexador 30 pode ajustar o valor do campo de tipo de hierarquia 162 para um valor de “14” e pode ajustar os valores dos campos de flag de escalonamento 156, flag de escalonamento espacial 158 e flag de escalonamento de qualidade 160, para “1”.

[000102] O campo de índice de camada de hierarquia 166 pode compreender um campo de seis bits que define um índice exclusivo do elemento de programa associado em uma tabela de hierarquias de camadas de codificação. Os índices podem ser exclusivos dentro de uma única definição de programa. Para subfluxos de bits de vídeo de AVC, os fluxos de vídeo de acordo com um ou mais perfis definidos no Anexo G da ITU-T Rec. H.264 ISO/IEC 14496-10, este é o índice de elemento de programa, o qual é designado de forma a que a ordem do fluxo de bits estará correta caso as representações de dependência SVC dos subfluxos de bits de vídeo da mesma unidade de acesso sejam reagrupadas em ordem crescente de índice de camada de hierarquia. Para subfluxos de bits de vídeo MVC de fluxos de vídeo AVC de acordo com um ou mais perfis definidos no Anexo H da ITU-T Rec. H.264 ISO/IEC 14496-10, este é o índice de elemento de programa, o qual é designado de forma a que tais valores são maiores que o valor de índice de camada de hierarquia especificado no descritor de hierarquia para o subfluxo de bits MVC de prefixo.

[000103] O campo de índice de camada embutida de hierarquia 172 pode compreender um campo de seis bits que define o índice de tabela de hierarquia do elemento de programa que deve ser acessado antes da decodificação do fluxo elementar associado à instância correspondente do descritor de hierarquia 112. A presente invenção deixa o valor do campo de índice de camada embutida de hierarquia 172 indefinido para quando o campo de tipo de hierarquia 162 possui um valor de 15 (isto é, um valor correspondente à camada base).

[000104] O campo de canal de hierarquia 176 pode compreender um campo de seis bits que indica o número de canal tencionado para o elemento de programa associado em um conjunto ordenado de canais de transmissão. O canal de transmissão mais firme é definido pelo valor mais baixo do campo de canal de hierarquia 176, com relação à definição geral de hierarquia de transmissão. Note-se que um dado canal de hierarquia pode ser designado ao mesmo tempo para vários elementos de programa.

[000105] Os campos reservados 164, 170 e 174 ficam reservados para uso futuro por desenvolvimento futuro de normas. As técnicas da presente invenção não propõem, neste momento, designar um significado semântico aos valores dos campos reservados 164, 170 e 174.

[000106] O campo de flag de referência de marca de tempo (TREF) 168 é um campo de um bit que indica se um campo TREF está presente no cabeçalho de pacote PES correspondente. Um campo TREF em um pacote PES consiste de um número de 33 bits codificado em três campos separados. O campo TREF indica o valor do instante de decodificação, no decodificador do sistema alvo tal como indicado pelo DTS ou, na ausência do DTS, pelo PTS do cabeçalho PES da mesma jaunidade de acesso em uma correspondente fluxo elementar n.

[000107] A Tabela 3 mais adiante descreve os elementos de sintaxe do descritor de hierarquia 112 da presente invenção. A Tabela 3 provê também, para cada elemento de sintaxe, um número de bits usado para representar o elemento de sintaxe, e um elemento mnemônico que descreve um tipo para o elemento de sintaxe. O número de bits corresponde ao número de bits que são alocados para o correspondente elemento de sintaxe quando o descritor de hierarquia 112 é transmitido em um fluxo de bits codificado. Os mnemônicos são usados na norma dos sistemas MPEG-2 para descrever os diferentes tipos de dados que são usados no fluxo de bits codificado. Os mnemônicos usados na presente invenção incluem “uimsbf”, que a norma dos sistemas MPEG-2 define como um número inteiro não assinado possuindo o bit mais significativo em primeiro lugar, e “bslbf”, que a norma dos sistemas MPEG-2 define como um string de bits com o bit esquerdo em primeiro lugar, em que “esquerdo” é a ordem em que os strings de bits são escritos na norma dos sistemas MPEG-2. Cada um dos elementos de sintaxe no exemplo da Tabela 3 corresponde a um respectivo elemento dentre os elementos de sintaxe acima descritos com referência ao descritor de hierarquia 112. Tabela 3 - Descritor de hierarquia

[000108] A Tabela 4 mais adiante descreve vários valores potenciais para o campo de tipo de hierarquia 162 do descritor de hierarquia 112, bem como o significado para cada valor. A presente invenção propõe adicionar um valor potencial de “14” para o campo de tipo de hierarquia 162, que compreende uma descrição de “subfluxo de bits MVC de prefixo” como a descrição do correspondente fluxo de bits. As técnicas da presente invenção definem o subfluxo de bits MVC de prefixo como compreendendo todas as unidades NAL de prefixo com NAL_unit_type (isto é, um valor de tipo da unidade NAL) igual a 20 e unidades NAL não VCL associadas que, após reagrupadas com o subfluxo de bits de vídeo AVC de MVC, está de acordo com um ou mais perfis definidos no anexo H da ITU-T Rec. H.264 ISO/IEC 14496-10. As técnicas da presente invenção propõem também que, quando o subfluxo de bits de vídeo AVC de MVC estiver presente, o subfluxo de bits MVC de prefixo deve também estar presente. Tabela 4 - Valores do campo de tipo de hierarquia

[000109] Em alguns exemplos, o descritor de hierarquia 112 pode ser usado para sinalizar um subfluxo de bits MVC sinalizado por um subfluxo de bits incremental e subfluxos de bits embutidos. Os subfluxos de bits embutidos incluem o subfluxo de bits dependente direto correspondente ao índice de camada embutida de hierarquia e todas os subfluxos de bits embutidas de tal subfluxo de bits dependente direta. Na presente invenção, as vistas que estão explicitamente contidas são designadas como vistas de ampliação, enquanto as vistas que estão embutidas são denominadas como vistas dependentes.

[000110] A Figura 6 é um diagrama conceitual que ilustra um exemplo de padrão ou configuração de predição de MVC. No exemplo da Figura 6, estão ilustradas oito vistas (possuindo IDs de vistas “S0” a “S7”) e doze localizações temporais (“T0” a “T11”) para cada vista. Isto é, cada fileira na Figura 6 corresponde a uma vista, enquanto cada coluna indica uma localização temporal.

[000111] Apesar de o MVC possuir uma chamada vista base que pode ser decodificada por decodificadores H.264/AVC e par de vistas estéreo poderia ser também suportado por MVC, a vantagem de MVC é a de que ele poderia dar suporte a um exemplo que utilize mais de duas vistas como uma alimentação de vídeo 3D e decodifica tal vídeo 3D representado pelas múltiplas vistas. Um reprodutor de um cliente que possua um decodificador MVC pode esperar conteúdo de vídeo 3D com múltiplas vistas.

[000112] Os quadros na Figura 6 são indicados na indicação de cada fileira e cada coluna na Figura 6 pelo uso de um bloco sombreado incluindo uma letra, designando se o quadro correspondente é intracodificado (isto é, um quadro I), ou intercodificado em uma direção (isto é, um quadro P), ou em múltiplas direções (isto é, um quadro B). De um modo geral, as previsões são indicadas por setas, em que o quadro apontado usa o ponto a partir do objeto como referência de predição. Como exemplo, o quadro P da vista S2 na localização temporal T0 é previsto a partir do quadro I da vista S0 na localização temporal T0.

[000113] Tal como na codificação de vídeo de vista única, os quadros de uma sequência de vídeo de codificação de vídeo de múltiplas vistas podem ser preditivamente codificados com relação a quadros em diferentes localizações temporais. Como exemplo, o quadro b da vista S0 na localização temporal T1 possui uma seta apontada pare ele a partir o quadro I da vista S0 na localização temporal T0, indicando que o quadro b é previsto a partir do quadro I. No entanto, adicionalmente, no contexto da codificação de vídeo de múltiplas vistas, os quadros podem ser preditos intervistas. Isto é, um componente de vista pode usar os componentes de vista em outras vistas como referência. No MVC, por exemplo, a predição intervistas é efetuada como se o componente de vista em outra vista fosse uma referência interpredição. As referências potenciais de intervistas são sinalizadas na extensão SPS (conjunto de parâmetros de sequência) MVC e podem ser modificadas pelo processo de construção da lista de imagem de referência, o que permite a ordenação flexível das referências de predição interpredição ou intervista. A Tabela 5 a seguir provê uma definição exemplar para um conjunto de parâmetros de sequência de extensão MVC. Tabela 5

[000114] A Figura 6 provê vários exemplos de predição intervista. Os quadros da vista S1, no exemplo da Figura 6, estão ilustrados como sendo preditos a partir de quadros em diferentes localizações temporais da vista S1, bem como preditos intervista a partir de quadros das vistas S0 e S2 nas mesmas localizações temporais. Como exemplo, o quadro b da vista S1 na localização temporal T1 é previsto a partir de cada um dos quadros B da vista S1 nas localizações temporais T0 e T2, bem como os quadros b das vistas S0 e S2 na localização temporal T1.

[000115] No exemplo da Figura 6, “B” maiúsculo e “b” minúsculo tencionam indicar diferentes relações hierárquicas entre quadros, e não metodologias de codificação diferentes. De um modo geral, os quadros “B” maiúsculo estão relativamente acima na hierarquia de predição do que quadros “b” minúsculos. A Figura 6 também ilustra variações na hierarquia de predição pelo uso de diferentes níveis de sombreamento, em que quadros com uma maior quantidade de sombra (isto é, relativamente mais escuros) estão mais alto na hierarquia de predição que quadros possuindo menos sombreamento (isto é, relativamente mais claros). Como exemplo, todos os quadros I na Figura 6 estão ilustrados com sombreamento total, enquanto os quadros P possuem um sombreamento um pouco mais claro e os quadros B (e quadros b minúsculo) possuem diferentes níveis de sombreamento uns em relação aos outros, porém sempre mais claros que o sombreamento dos quadros P e dos quadros I.

[000116] De um modo geral, a hierarquia de predição está relacionada a índices de ordem de vista, pelo fato de que os quadros relativamente mais altos na hierarquia de predição devem ser decodificados antes da decodificação de quadros que estão relativamente mais baixos na hierarquia, de tal forma que aqueles quadros relativamente mais altos na hierarquia podem ser usados como quadros de referência durante a decodificação dos quadros relativamente mais baixos na hierarquia. Um índice de ordem de vista é um índice que indica a ordem de decodificação de componentes de vista em uma unidade de acesso. Os índices de ordem de vista estão implícitos na extensão SPS MVC, tal como especificado no Anexo H da H.264/ AVC (emenda MVC). No SPS, para cada índice i, está sinalizado o correspondente view_id. A decodificação dos componentes de vista deve seguir a ordem ascendente do índice de ordem de vista. Caso todas as vistas sejam apresentadas, então os índices de ordem de vista estão em uma ordem consecutiva de 0 até num_views_minus_1.

[000117] Dessa forma, os quadros usados como quadros de referência podem ser decodificados antes de decodificar os quadros que estão codificados com referência aos quadros de referência. Um índice de ordem de vista é um índice que indica a ordem de decodificação de componentes de vista em uma unidade de acesso. Para cada índice de ordem de vista i, é sinalizado o correspondente view_id. A decodificação dos componentes de vista segue a ordem crescente dos índices de ordem de vista. Caso todas as vistas sejam apresentadas, então os índices de ordem de vista constituem um conjunto ordenado consecutivamente de zero até um menos que o número total de vistas.

[000118] Para certos quadros em níveis iguais na hierarquia, a ordem de decodificação de uns em relação aos outros pode não ser relevante. Como exemplo, o quadro I da vista S0 na localização temporal T0 é usado como um quadro de referência para o quadro P da vista S2 na localização temporal T0, o qual por sua vez é usado como um quadro de referência para o quadro P da vista S4 na localização temporal T0. Assim sendo, o quadro I da vista S0 na localização temporal T0 deve ser codificado antes do quadro P da vista S2 na localização temporal T0, o qual deve ser decodificado antes do quadro P da vista S4 na localização temporal T0. No entanto, entre as vistas S1 e S3 a ordem de decodificação não importa, pois as vistas S1 e S3 não dependem uma da outra para a predição, mas são preditas apenas a partir de vistas que estão mais altas na hierarquia de predição. Além disso, a vista S1 pode ser decodificada antes da vista S4, contanto que a vista S1 seja decodificada após as vistas S0 e S2.

[000119] Dessa forma, uma ordenação hierárquica pode ser usada para descrever as vistas S0 a S7. A notação AS > SB significa que a vista AS deve ser decodificada antes da vista SB. Utilizando tal notação, S0 > S2 > S4, S6 > S7, no exemplo da Figura 6. Além disso, com relação ao exemplo da Figura 6, S0 > S1, S2 > S1, S2 > S3, S4 > S3, S4 > S5 e S6 > S5. Qualquer ordem de decodificação para as vistas que não violem tais exigências é possível. Assim sendo, são possíveis várias ordens de decodificação diferentes, com apenas algumas limitações. A seguir, são apresentadas duas ordens de decodificação exemplares, apesar de que deve ficar claro que outras ordens de decodificação sejam possíveis. Como exemplo, ilustrado na Tabela 6 a seguir, as vistas são decodificadas tão logo possível. Tabela 6

[000120] O exemplo da Tabela 6 reconhece que a vista S1 pode ser decodificada imediatamente após as vistas S0 e S2 terem sido decodificadas, a vista S3 pode ser decodificada imediatamente após as vistas S2 e S4 terem sido decodificadas e a vista S5 pode ser decodificada imediatamente após as vistas S4 e S6 terem sido decodificadas.

[000121] A Tabela 7 a seguir provê outra ordem de decodificação exemplar em que a ordem de decodificação é tal que qualquer vista que é usada como uma referência para outra vista é decodificada antes de vistas que não são usadas como referência para qualquer outra vista. Tabela 7

[000122] O exemplo da Tabela 7 reconhece que os quadros das vistas S1, S3, S5 e S7 não atuam como quadros de referência para quadros de quaisquer outras vistas e, portanto, as vistas S1, S3, S5 e S7 são decodificadas após os quadros de tais vistas que são usados como quadros de referência, isto é, as vistas S0, S2, S4 e S6, no exemplo da Figura 6. As vistas S1, S3, S5 e S7 com relação umas às outras, podem ser decodificadas em qualquer ordem. Assim sendo, no exemplo da Tabela 7, a vista S7 é decodificada antes de cada uma das vistas S1, S3 e S5.

[000123] Para esclarecer, pode existir uma relação hierárquica entre quadros de cada vista, bem como as localizações temporais dos quadros de cada vista. Com relação ao exemplo da Figura 6, os quadros na localização temporal T0 são intrapreditos ou preditos intervistas a partir de quadros de outras vistas na localização temporal T0. De forma similar, os quadros na localização temporal T8 são intrapreditos ou preditos intervistas a partir de quadros de outras vistas na localização temporal T8. Assim sendo, com relação a uma hierarquia temporal, as localizações T0 e T8 estão no topo da hierarquia temporal.

[000124] Os quadros na localização temporal T4, no exemplo da Figura 6, estão mais baixos na hierarquia temporal do que quadros das localizações temporais T0 e T8 pois os quadros da localização T4 são codificados B com referência aos quadros das localizações temporais T0 e T8. Os quadros nas localizações temporais T2 e T6 estão mais baixos na hierarquia temporal do que quadros da localização temporal T4. finalmente, os quadros nas localizações T1, T3, T5 e T7 estão mais baixos na hierarquia temporal do que quadros das localizações temporais T2 e T6.

[000125] No MVC, um subconjunto de todo um fluxo de bits pode ser extraído para formar um subfluxo de bits que ainda se conforme ao MVC. Existem muitos subfluxos de bits possíveis que aplicativos específicos podem requerer com base, por exemplo, em um serviço provido por um servidor, a capacidade, suporte e capacidades de decodificadores de um ou mais clientes e/ou a preferência de um ou mais clientes. Como exemplo, um cliente poderia requerer apenas três vistas e poderiam existir dois cenários. Como exemplo, um cliente pode requerer uma experiência de audiência suave ou contínua e poderia dar preferência a vistas com valores de view_id S0, S2 e S4. caso originalmente os view_ids estejam ordenados com relação ao exemplo da Tabela 6, os valores de índices de ordem de vista são {0, 1, 2} e {0, 1, 4} nestes dois exemplos, respectivamente. Note-se que tais subfluxos de bits podem ser decodificados como fluxos de bits MVC independentes e podem ser suportados simultaneamente.

[000126] A Figura 7 é um fluxograma que ilustra um exemplo de um método para enviar um fluxo de sistemas MPEG-2 possuindo um subconjunto de vistas com índices de ordem de vistas não consecutivos de um servidor para um cliente. O método da Figura 7 é descrito, com o propósito de ilustração, com referência ao dispositivo A/V de origem 20 e ao dispositivo A/V de destino 40, devendo entretanto ficar claro que outros exemplos podem efetuar o método da Figura 7. No exemplo da Figura 7, as ações atribuídas ao “servidor” podem ser efetuadas pelo dispositivo A/V de origem 20, enquanto as ações efetuadas pelo “cliente” podem ser efetuadas pelo dispositivo A/V de destino 40.

[000127] No exemplo da Figura 7, o dispositivo A/V de origem 20 inicialmente determina um subconjunto de vistas disponíveis para envio a um dispositivo A/V de destino 40 com base em um serviço provido pelo dispositivo A/V de origem 20 (em 200). Como foi acima descrito, um serviço compreende de um modo geral uma seleção de vistas. Com referência ao exemplo da Figura 6, um serviço pode compreender as vistas S0, S2 e S4. Presumindo que os índices de ordem de vista de tais vistas sejam os índices de ordem de vista prescritos pela Tabela 6, os índices de ordem de vista podem por exemplo para as vistas S0, S2 e S4 compreender os índices de ordem de vista 0, 1 e 3. A descrição restante do método da Figura 7 usa tais IDs de vista e índices de ordem de vista como exemplo para os propósitos da explanação.

[000128] O dispositivo A/V de origem 20 pode a seguir preparar uma tabela de mapas de programa (PMT) com base nas vistas que foram determinadas a serem enviadas como parte do provimento do serviço (em 202). Em particular, o construtor de PMT 64 do multiplexador 30 pode preparar uma PMT com base em informações recuperadas a partir das tabelas de informações específicas de programas 88 para um ou mais programas correspondentes ao serviço provido pelo dispositivo A/V de origem 20. De acordo com as técnicas da presente invenção, a preparação da PMT inclui a geração do descritor de extensão MVC 110 e do descritor de hierarquia 112.

[000129] Para gerar o descritor de extensão MVC 110, o construtor de PMT 64 do multiplexador 30 ajusta o campo de tag de descritor 120 como igual a “49”. O construtor de PMT 64 ajusta os valores do campo de taxa de bits média 124, do campo de taxa de bits máxima 126, do campo de início de ID temporal 130, do campo final de ID temporal 132 e do campo de nenhuma unidade SEI NAL presente 134 de acordo com os dados específicos de programa do programa tal como armazenados pelas tabelas de informações específicas de programa 88. O construtor de PMT 64 também ajusta o valor dos campos de índices de ordem de vista 136 de acordo com os índices de ordem de vista das vistas selecionadas. No exemplo acima descrito, o construtor de PMT 64 inclui três valores de campos de índices de ordem de vista representativos dos índices de ordem de vista 0, 1 e 3. Dessa forma, este exemplo provê um descritor de extensão de MVC que indica individualmente cada índice de ordem de vista das vistas do programa. Ademais, dado que o índice de ordem de vista “2” é “pulado”, este exemplo constitui um exemplo em que os índices de ordem de vista são não consecutivos.

[000130] Para gerar o descritor de hierarquia 112, o construtor de PMT 64 ajusta os valores dos campos do descritor de hierarquia 112 de acordo com as tabelas de informações específicas de programas 88. De acordo com as técnicas da presente invenção, o construtor de PMT 64 pode também ajustar o valor do campo de flag de ampliação de vista 154 para um valor de “0” para indicar que o elemento de programa associado amplia o número de vistas do fluxo de bits resultante do elemento de programa referenciado pelo valor do campo de índice de camada embutida de hierarquia 172.

[000131] Após a geração da PMT, o dispositivo A/V de origem 20 pode transmitir a PMT para o dispositivo A/V de destino 40, por exemplo na forma de uma unidade NAL (em 204). Como exemplo, o dispositivo A/V de origem 20 pode reenviar a PMT periodicamente para o dispositivo A/V de destino 40, por exemplo após um intervalo de tempo predeterminado, ou após uma quantidade específica de dados ter sido enviada. O dispositivo A/V de destino 40 pode gravar as informações de programa provenientes da PMT em um meio de armazenamento na ponta do cliente (em 208), o que pode essencialmente refletir as tabelas de informações específicas de programa 88 do multiplexador 30. Como exemplo, o demultiplexador 38 pode compreender um conjunto de tabelas de informações específicas de programas similares às tabelas de informações específicas de programas 88 do multiplexador 30. Ao receber as informações específicas de programas, tais como a PMT transmitida, o demultiplexador 38 pode atualizar as tabelas de informações específicas de programas do demultiplexador 38.

[000132] O multiplexador 30 pode a seguir receber pacotes PES de um ou mais programas associados ao serviço provido pelo dispositivo A/V de origem 20 (em 210). O multiplexador 30 pode determinar que os pacotes PES devem ser incluídos no fluxo de transporte para o dispositivo A/V de destino 40 efetuando uma consulta sobre os IDs de fluxo de pacotes PES. Quando o ID de fluxo de um pacote PES estiver de acordo com uma vista a ser incluída no fluxo de transporte, o multiplexador 30 pode formar uma unidade NAL a partir do pacote PES, por exemplo por encapsulamento do pacote PES com um ID de programa (PID) correspondente ao programa (em 212). O multiplexador 30 pode também formar uma unidade de acesso a partir de uma pluralidade de tais unidades NAL (em 214) e enviar a unidade de acesso para o dispositivo A/V de destino 40 (em 216).

[000133] O dispositivo A/V de destino 40 pode a seguir receber a unidade de acesso a partir do dispositivo A/V de origem 20 (em 218) e associar a unidade de acesso ao programa (em 220), por exemplo por referência ao PID da unidade de acesso. O demultiplexador 38 do dispositivo A/V de destino 40 pode demultiplexar a unidade de acesso em suas unidades NAL constituintes e correspondentes pacotes PES, que o demultiplexador 38 pode eventualmente passar para o decodificador de áudio 46 e/ou para o decodificador de vídeo 48. O decodificador de vídeo 48 pode decodificar cada uma das vistas e enviar as vistas decodificadas para a saída de vídeo 44, a qual pode consistir de um display de vídeo estereoscópico ou auto estereoscópico ou outro dispositivo de display requerendo uma pluralidade de vistas. De forma similar, o decodificador de áudio 46 pode decodificar quadros de áudio para formar dados de áudio decodificados e enviar os dados de áudio para a saída de áudio 42, por exemplo um alto falante. Dessa forma, o dispositivo A/V de destino 40 pode decodificar e apresentar os dados recebidos (em 222).

[000134] A Figura 8 é um fluxograma que ilustra um exemplo de um método para montagem de componentes de quadros de dois ou mais subfluxos de bits para produzir um fluxo de bits tal que os componentes de quadros apresentem índices de ordem de vistas crescentes. O método pode ordenar os subfluxos de bits sem referência aos IDs de vista dos respectivos subfluxos de bits e componentes de vista. Vamos supor, com relação ao exemplo da Figura 6, que um primeiro subfluxo de bits de uma fluxo de transporte (ou fluxo de programa) inclua os componentes de vistas S0, S2 e S4, enquanto que um segundo subfluxo de bits do fluxo de transporte (correspondente a um subfluxo de bits embutido do primeiro subfluxo de bits) inclua os componentes de vista das vistas S1 e S3. A presente invenção pode também fazer referência a subfluxos de bits embutidos como “subfluxos de bits dependentes”. De forma similar, a presente invenção pode fazer referência a subfluxos de bits em que subfluxos de bits dependentes estejam embutidos como subfluxos de bits primários. Assim sendo, o primeiro subfluxo de bits da Figura 8 pode ser designado como um subfluxo de bits primário, enquanto o segundo subfluxo de bits pode ser designado como um subfluxo de bits embutido ou dependente.

[000135] Presumindo-se que os índices de ordem de vista para este exemplo sejam tal como definidos com referência ao exemplo da Tabela 6, os índices de ordem de vista dos componentes de vista no primeiro subfluxo de bits são 0, 1 e 3 respectivamente, enquanto os índices de ordem de vista para o segundo subfluxo de bits são 2 e 4. Assim sendo, caso os componentes de vista do primeiro fluxo de bits neste exemplo fossem inteiramente decodificados antes dos componentes de vista do segundo subfluxo de bits, a ordem de decodificação, em termos dos índices de ordem de vista iriam corresponder a 0, 1, 3, 2, 4. Dado que os índices de ordem de vista devem descrever a ordem de decodificação, tal ordem de decodificação iria constituir uma violação da especificação MVC. Assim sendo, o método da Figura 8 pode ser usado para reordenar os componentes de vista em termos dos índices de ordem de vista, de tal forma que a ordem de decodificação dos componentes de vista fique de acordo com a especificação MVC.

[000136] O método da Figura 8corresponde de um modo geral a um exemplo de método que inclui, quando da montagem dos subfluxos de bits, os componentes de vista em cada unidade de acesso seguindo a ordem crescente de índices de ordem de vista tal como portada no subfluxo de bits fluxo e em seus subfluxos de bits embutidos. As técnicas da presente invenção podem tornar possível a montagem de um subfluxo de bits MVC em conformidade sem checar o elemento de sintaxe view_id no cabeçalho da unidade NAL das unidades NAL e seu mapeamento para o índice de ordem de vista. O método da Figura 8 pode ser usado para produzir uma lista, designada como a “lista de índices de camada de hierarquia” (HLI) que compreende os índices correspondentes a view_ids dos subfluxos de bits em uma ordem de acordo com a norma MVC.

[000137] Inicialmente, um dispositivo cliente, tal como um dispositivo A/V de destino 40, recebe uma unidade de acesso possuindo componentes de vista de dois subfluxos de bits (em 250). É presumido, apenas como exemplo, que o segundo subfluxo de bits compreende um subfluxo de bits embutido ou dependente do primeiro subfluxo de bits. O método exemplar da Figura 8 será descrito com referência a dois subfluxos de bits. No entanto, as técnicas da Figura 8 podem também ser aplicadas a exemplos possuindo mais do que dois subfluxos de bits. Além disso, o método da Figura 8 é descrito como exemplo e com o propósito de explanação, com referência ao demultiplexador 38 do dispositivo A/V de destino 40. No entanto, deve ficar claro que o método da Figura 8 pode ser efetuado por qualquer dispositivo, módulo, unidade, ou combinação de componentes de firmware, hardware e/ou software, para reorganizar vistas de dois ou mais subfluxos de bits para que se conformem com a norma MVC.

[000138] É presumido que os componentes de cada subfluxo de bits são ordenados de acordo com a norma MVC. Portanto, o demultiplexador 38 determina quais dos componentes de vista dos subfluxos de bits possui o menor índice de ordem de vista (em 252). O demultiplexador 38 pode a seguir adicionar um índice do componente de vista (o qual pode compreender uma ou mais unidades NAL) à lista HLI na próxima posição disponível (em 254). Em alguns exemplos, um componente de vista pode compreender uma ou mais unidades NAL compreendendo dados de multimídia, bem como uma unidade NAL delimitadora que pode ser usada para distinguir um componente de vista de outro componente de vista subsequente. O demultiplexador 38 pode a seguir determinar se restam quaisquer componentes de vista para o primeiro subfluxo de bits (em 256).

[000139] Quando restarem componentes de vista para o primeiro subfluxo de bits (no ramo “SIM” DE 256), o demultiplexador 38 pode determinar se restam também componentes de vista para o segundo subfluxo de bits (em 258). Quando o primeiro subfluxo de bits e o segundo subfluxo de bits incluem pelo menos um componente de vista (no ramo “SIM” de 258), o demultiplexador 38 retorna à etapa 252 para determinar o menor índice de ordem de vista dos componentes de vista e adicionar o índice de vista do menor componente de vista à lista HLI. No entanto, quando restarem componentes de vista apenas para o primeiro subfluxo de bits e não para o segundo (no ramo “NÃO” em 258), o demultiplexador 38 pode adicionar os componentes de vista restantes do primeiro subfluxo de bits à lista HLI (em 260).

[000140] Por outro lado, quando nenhum componente de vista restar para o primeiro subfluxo de bits (no ramo “NÃO” em 256), o demultiplexador pode determinar se restam componentes de vista para o segundo subfluxo de bits (em 262). Quando o segundo subfluxo de bits possui componentes de vista restantes, o demultiplexador 38 pode adicionar os componentes de vista restantes do segundo subfluxo de bits à lista HLI (em 264).

[000141] Após a lista HLI compreender IDs de vistas na ordem dos respectivos índices de ordem de vista (por exemplo, após terminadas as etapas 260, 264, ou no ramo “não” de 262), o demultiplexador 38 pode formar um novo fluxo de bits, compreendendo os subfluxos de bits na ordem determinada de acordo com a lista HLI. Isto é, para uma unidade de acesso do novo fluxo de bits, em que a unidade de acesso compreende uma pluralidade de componentes de vistas, os componentes de vistas são ordenados no novo fluxo de bits de tal forma que um índice de ordem de vista de cada um dos componentes de vista seja maior do que todos os índices de ordem de vista precedentes e menor que todos os índices de ordem de vista subsequentes. Tal fluxo de bits pode a seguir ser repassado para, por exemplo, o decodificador de vídeo 48, para decodificação dos componentes de vista e, eventualmente, apresentação dos componentes de vista.

[000142] Os exemplos de algoritmos que se seguem propiciam um exemplo de processo para ordenar subfluxos de bits para que fiquem de acordo com a norma MVC. Nos exemplos existe uma lista de valores de índice de camada de hierarquia (HLIList) que ou corresponde ao subfluxo de bits MVC fluxo ou aos subfluxos de bits embutidos. Como foi acima mencionado, um componente de vista pode compreender, ou ser seguido por uma unidade NAL delimitadora para diferenciar cada componente de vista de outro componente de vista.

[000143] O processo para a montagem de um novo subfluxo de bits pode ser definido como se segue: 1) Ajustar o subfluxo de bits dependente como o subfluxo de bits que não possui um subfluxo de bits embutido. 2) Na ordem crescente de índice de camada de hierarquia. O que se segue se aplica de forma interativa: 1. Montar um subfluxo de bits em conformidade com o MVC e descrita no descritor de hierarquia com índice de camada de hierarquia igual a HLI: 2. Tal processo possui o seguinte como alimentação: i. o subfluxo de bits de ampliação que apresenta explicitamente; ii. o subfluxo de bits dependente. Note-se que está de acordo com a MVC e, portanto, possui os componentes de vista posicionados na ordem crescente de índice de ordem de vista em cada unidade de acesso; iii. uma lista dos índices de ordem de vista na subfluxo de bits de ampliação; iv. uma lista dos índices de ordem de vista na subfluxo de bits dependente; 3. O processo possui o seguinte como saída: i. um novo subfluxo de bits que possui todos os componentes de vista agrupados e, portanto, está de acordo com a MVC e formam um ponto de operação completo correspondente ao HLI definido no descritor de hierarquia; ii. Uma lista de índices de ordem de vista na nova subfluxo de bits; 4. Ajustar o novo subfluxo de bits gerado na etapa 3 como o subfluxo de bits dependente; 5. Caso HLI seja o último na lista da HLIList, ajustar o subfluxo de bits dependente como o subfluxo de bits MVC montada final e finalizar todo o processo de montagem.

[000144] O algoritmo que se segue descreve um exemplo de processo para montar um subfluxo de bits com base em um subfluxo de bits dependente e um subfluxo de bits de ampliação, tal como requerido na etapa 2 do algoritmo exemplar acima: 1. A alimentação do processo de montagem consiste de duas listas e dois subfluxos de bits, cada uma das quais já estão ordenadas na ordem ascendente de índices de ordem de vista. Cada uma das duas listas contém os índices de ordem de vista na ordem crescente, as duas listas são VOIdxListE e VOIdxListD. Os dois subfluxos de bits são o subfluxo de bits dependente e o subfluxo de bits de ampliação. Uma nova lista é VOIdxListNew, que está vazia no início. 2. Para cada unidade de acesso, aplicar o seguinte: i. Ajustar a VOIdxE como o primeiro valor de VOIdxListE e VOIdxD como o primeiro valor da VOIdxListD; ii. Caso VOIdxE seja menor que VOIdxD, montar um componente de vista a partir do subfluxo de bits de ampliação, ajustar VOIdxE para o próximo valor na VOIdxListE, VOIdxCurr é ajustado para VOIdxE. Caso contrário, montar um componente de vista a partir do subfluxo de bits dependente, ajustar VOIdxD para o próximo valor na VOIdxListD, VOIdxCurr é ajustado para VOIdxD. Adicionar VOIdxCurr a VOIdxListNew • Ao montar um componente de vista a partir de um subfluxo de bits, as unidades NAL são adicionadas até ser encontrada uma unidade NAL delimitadora. iii. Caso VOIdxE não esteja no final de VOIdxListE e VOIdxD não esteja no final de VOIdxListD, terminar todo o processo. Caso contrário, ir para a etapa iv. iv. Caso VOIdxE esteja no final da VOIdxListE, montar todos os componentes de vista restantes no subfluxo de bits dependente, adicionar todos os valores restantes na VOIdxListD em VOIdxListNew e ajustar VOIdxD para o final da VOIdxListD. v. Caso contrário, se VOIdxD estiver no final da VOIdxListD, montar todos os componentes de vista restantes no subfluxo de bits de ampliação, adicionar todos os valores restantes na VOIdxListE em VOIdxListNew e ajustar VOIdxE para o final da VOIdxListE. vi. Caso contrário, volte à etapa ii.

[000145] Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware, ou quaisquer combinações de tais. Caso implementadas em software as funções podem ser armazenadas ou transmitidas através de uma ou mais instruções ou código e um meio legível por computador. Os meios legíveis por computador podem incluir meios para armazenamento de dados de computador ou meios de comunicação, incluindo qualquer meio que facilite a transferência de um programa de computador de um local para outro. Os meios para armazenamento de dados podem ser quaisquer meios disponíveis que possam ser acessados por um ou mais computadores, ou um ou mais processadores para a recuperação de instruções, códigos e/ou estruturas de dados para implementação das técnicas aqui descritas. Como exemplo, mas não limitação, tais meios legível por computador podem incluir RAM, ROM, EEPROM, CD-ROM, ou outro armazenamento em disco óptico, armazenamento em disco magnético, ou outros dispositivos magnéticos de armazenamento, memória flash, ou qualquer outro meio que possa ser usado para portar ou armazenar um código de programa desejado na forma de instruções ou estruturas de dados e que possa ser acessado por um computador. Além disso, qualquer conexão é apropriadamente designada como um meio legível por computador. Como exemplo, caso o software seja transmitido a partir de um website, servidor, ou outra fonte remota usando-se um cabo coaxial, cabo de fibra óptica, par torcido, linha de assinante digital (DSL), ou tecnologias sem fio tais como infravermelho, rádio e microondas,então o cabo coaxial, cabo de fibra óptica, par torcido, linha de assinante digital (DSL), ou tecnologias sem fio se incluem na definição de meio. O termo disco, tal como é aqui utilizado, inclui discos compactos (CD), discos laser, discos ópticos, DVD, disquetes e discos Blu-ray. Combinações destes também devem ser incluídas no escopo de meios legível por computador.

[000146] O código pode ser executado por um ou mais processadores, tais como um ou mais processadores de sinais digitais (DSP), microprocessadores de uso geral, circuitos integrados específicos para aplicação (ASIC), arranjos de porta programáveis no campo (FPGA), ou outros circuitos lógicos integrados ou individuais. Assim sendo, o termo “processador”, tal como é aqui utilizado, pode se referir a quaisquer das estruturas acima, ou qualquer outra estrutura adequada para a implementação das técnicas aqui descritas. Além disso, em alguns aspectos, a funcionalidade aqui descrita pode ser provida em módulos de hardware e/ou software dedicados configurados para codificar e decodificar, ou incorporados em um CODEC combinado. Além disso, as técnicas poderiam ser completamente implementadas em um ou mais circuitos ou elementos lógicos.

[000147] As técnicas da presente invenção podem ser implementadas em uma ampla gama de dispositivos ou equipamentos, incluindo um telefone sem fio, um circuito integrado (IC), ou um conjunto de ICS (por exemplo, um conjunto de chips). Vários componentes, módulos, ou unidades foram aqui descritos para enfatizar aspectos funcionais de dispositivos configurados para efetuar as técnicas descritas, porém não requerem necessariamente a concretização por diferentes unidades de hardware. Ao contrário, e tal como foi acima descrito, várias unidades podem ser combinadas em uma unidade de hardware de CODEC, ou providas por uma coletânea de unidades de hardware interoperastes, incluindo um ou mais processadores tal como foi acima descrito, em conjunto com software e/ou firmware adequados.

[000148] Foram descritos vários exemplos. Estes e outros exemplos se inserem no escopo das reivindicações que se seguem.

Claims

1. Método para enviar dados de vídeo possuindo uma pluralidade de vistas de acordo com o padrão de codificação multivista em um fluxo de bits MPEG-2, o método compreendendo: determinar um subconjunto de vistas disponíveis para enviar a um dispositivo de destino; e enviar o fluxo de bits compreendendo o subconjunto de vistas disponíveis a partir de um dispositivo de origem para o dispositivo de destino; caracterizadopelo fato de construir, com o dispositivo de origem, uma estrutura de dados para sinalizar que o fluxo de bits compreende uma primeira vista de uma cena associada a um primeiro índice de ordem de vistas e uma segunda vista da cena associada a um segundo índice de ordem de vistas, a estrutura de dados incluindo um descritor de extensão de codificação de vídeo multivista (MVC) compreendendo valores individuais de índice de ordem de vistas para cada vista incluída no fluxo de bits, em que os valores individuais de índice de ordem de vistas compreendem valores para um primeiro índice de ordem de vista e um segundo índice de ordem de vista, em que o primeiro índice de ordem de vistas e o segundo índice de ordem de vistas não são consecutivos, em que os valores de índice de ordem de vista são dispostos em ordem crescente e em que os valores de índice de ordem de vistas compreendem um primeiro valor de índice de ordem de vista e um segundo valor de índice de ordem de vista, em que o segundo valor de índice de ordem de vista ocorre imediatamente após o primeiro valor de índice de ordem de vista no descritor de extensão MVC; e transmitir a estrutura de dados para o dispositivo de destino.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a estrutura de dados compreende uma tabela de mapas de programa e o fluxo de bits compreende um fluxo de transporte MPEG-2; ou a estrutura de dados compreende um mapa de fluxos de programa e o fluxo de bits compreende um fluxo de programa MPEG-2.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que construir a estrutura de dados compreende adicionalmente construir um descritor de hierarquia compreendendo um valor para um campo de flag de ampliação de vista que indica que um elemento de programa associado amplia um certo número de vistas do fluxo de bits resultante do elemento de programa referenciado por um valor de um campo de índice de camada embutido de hierarquia do descritor de hierarquia.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que compreende adicionalmente determinar que o fluxo de bits inclui uma vista base de codificação de vídeo avançada (AVC) de MVC, em que construir o descritor de hierarquia compreende ajustar um valor de um campo de tipo de hierarquia no descritor de hierarquia para um valor indicativo de que o fluxo de bits inclui um subfluxo de bits MVC de prefixo compreendendo todas as unidade de camada de abstração de rede (NAL) de prefixo compreendendo um valor de tipo igual a vinte.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: construir uma unidade de acesso compreendendo um componente de vista da primeira vista e um componente de vista da segunda vista, em que o componente de vista da primeira vista ocorre na unidade de acesso imediatamente anterior ao componente de vista da segundo vista de tal forma que o primeiro índice de ordem de vista e o segundo índice de ordem de vista para os componentes de vista ocorram de forma não sequencial na unidade de acesso; e emitir a unidade de acesso.

6. Equipamento para gerar dados de vídeo multivista de acordo com um padrão de codificação multivista, o equipamento compreendendo: meios para determinar um subconjunto de vistas disponíveis para enviar a um dispositivo de destino; e meios para enviar o fluxo de bits compreendendo o subconjunto de vistas disponíveis de um dispositivo de origem para o dispositivo de destino; caracterizado pelo fato de que compreende: meios para construir, com o dispositivo de origem, uma estrutura de dados para sinalizar que o fluxo de bits compreende uma primeira vista de uma cena associada a um primeiro índice de ordem de vistas e uma segunda vista da cena associada a um segundo índice de ordem de vistas, a estrutura de dados incluindo um descritor de extensão de codificação de vídeo multivista (MVC) compreendendo valores individuais de índice de ordem de vistas para cada vista incluída no fluxo de bits, em que os valores individuais de índice de ordem de vistas compreendem valores para um primeiro índice de ordem de vista e um segundo índice de ordem de vista, em que o primeiro índice de ordem de vistas e o segundo índice de ordem de vistas não são consecutivos, em que os valores de índice de ordem de vista são dispostos em ordem crescente e em que os valores de índice de ordem de vistas compreendem um primeiro valor de índice de ordem de vista e um segundo valor de índice de ordem de vista, em que o segundo valor de índice de ordem de vista ocorre imediatamente após o primeiro valor de índice de ordem de vista no descritor de extensão MVC; e meios para transmitir a estrutura de dados para o dispositivo de destino.

7. Equipamento, de acordo com a reivindicação 6, caracterizado pelo fato de que a estrutura de dados compreende uma tabela de mapas de programa e o fluxo de bits compreende um fluxo de transporte MPEG-2; ou a estrutura de dados compreende um mapa de fluxos de programa e o fluxo de bits compreende um fluxo de programa MPEG-2.

8. Equipamento, de acordo com a reivindicação 6, caracterizado pelo fato de que os meios para construir a estrutura de dados compreendem adicionalmente meios para construir um descritor de hierarquia compreendendo um valor para um campo de flag de ampliação de vista que indica que um elemento de programa associado amplia um número de vistas do fluxo de bits resultante do elemento de programa referenciado por um valor de um campo de índice de camada embutido na hierarquia do descritor de hierarquia.

9. Equipamento, de acordo com a reivindicação 8, caracterizado pelo fato de que compreende adicionalmente meios para determinar que o fluxo de bits inclui uma vista base de codificação de vídeo avançada (AVC) de MVC, em que os meios para construir o descritor de hierarquia compreendem meios para ajustar um valor de um campo de tipo de hierarquia no descritor de hierarquia para um valor indicativo de que o fluxo de bits inclui um subfluxo de bits MVC de prefixo compreendendo todas as unidade de camada de abstração de rede (NAL) de prefixo compreendendo um valor de tipo igual a vinte.

10. Equipamento, de acordo com a reivindicação 6, caracterizado pelo fato de que compreende adicionalmente: construir uma unidade de acesso compreendendo um componente de vista da primeira vista e um componente de vista da segunda vista, em que o componente de vista da primeira vista ocorre na unidade de acesso imediatamente anterior ao componente de vista da segunda vista de tal forma que o primeiro índice de ordem de vista e o segundo índice de ordem de vista para os componentes de vista ocorram de forma não sequencial na unidade de acesso; e emitir a unidade de acesso.

11. Memória legível por computador caracterizada pelo fato de que contém gravado na mesma o método conforme definido em qualquer uma das reivindicações 1 a 5.