BR112012002259B1

BR112012002259B1 - características de sinalização de um ponto de operação mvc

Info

Publication number: BR112012002259B1
Application number: BR112012002259-8A
Authority: BR
Inventors: Ying Chen; Peisong Chen; Marta Karczewicz
Original assignee: Qualcomm Incorporated
Priority date: 2009-08-07
Filing date: 2010-08-06
Publication date: 2021-05-25
Also published as: RU2012108618A; CA2768618A1; ES2650220T3; EP2462742B1; ZA201201474B; BR112012002259A2; CA2768618C; HK1169247A1; US20110032999A1; EP2462742A1; IL217436A; HUE037168T2; US8948241B2; KR101293425B1; TW201112769A; MY180768A; JP5602854B2; RU2530740C2; CN102474655A; AU2010279256A1

Abstract

CARACTERÍSTICAS DE SINALIZAÇÃO DE UM PONTO DE OPERAÇÃO MVC Dispositivos de vídeo de origem e de destino podem utilizar estruturas de dados que sinalizam detalhes de um ponto de operação para um fluxo de bits de Sistema MPEG-2 (Grupo de Especialistas em Imagens em Movimento). Em um exemplo, um aparelho inclui um multiplexador que constrói uma estrutura de dados correspondendo a um ponto de operação de codificação de vídeo multivista (MVC) de um fluxo de bits de padrão de Sistema MPEG-2 (Grupo de Especialistas em Imagens em Movimento), no qual a estrutura de dados sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser preenchida por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, e que inclui a estrutura de dados como parte do fluxo de bits, e uma interface de saída que emite o fluxo de bits compreendendo a estrutura de dados.

Description

Campo da Invenção

Esta revelação se refere a transporte de dados de 5 vídeo codificados.

Descrição da Técnica Anterior

Capacidades de vídeo digital podem ser incorporadas em uma ampla variedade de dispositivos, incluindo televisores digitais, sistemas digitais de 10 difusão direta, sistemas de difusão sem fio, assistentes digitais pessoais (PDAs), computadores desktop ou laptop, câmeras digitais, dispositivos de gravação digital, reprodutores de mídia digital, dispositivos de jogos de vídeo, consoles de jogos de vídeo, telefones de rádio via satélite ou celulares, dispositivos de teleconferência de vídeo, e assim por diante. Dispositivos de vídeo digital implementam técnicas de compressão de vídeo, tais como as descritas nos padrões definidos por MPEG-2, MPEG-4, H.263 da ITU-T ou H.264/MPEG-4 Part 10, Codificação de Vídeo Avançada (AVC), da ITU-T, e extensões de tais padrões, para transmitir e receber informações de vídeo digital de forma mais eficiente.

Técnicas de compressão de vídeo realizam predição espacial e/ou predição temporal para reduzir ou remover redundâncias inerentes em sequências de vídeo. Para codificação de vídeo com base em blocos, uma fatia ou um quadro de vídeo podem ser particionados em macroblocos. Cada macrobloco pode ser particionado mais ainda. Macroblocos em uma fatia ou um quadro intracodificados (I) são codificados utilizando predição espacial com relação a macroblocos vizinhos. Macroblocos em uma fatia ou um quadro intercodifiçados (P ou B) podem utilizar predição espacial com relação a macroblocos vizinhos no mesmo quadro ou fatia ou predição temporal com relação a outros quadros de referência.

Depois que os dados de vídeo forem codificados, os dados de vídeo podem ser empacotados por um multiplexador para transmissão ou armazenamento. MPEG-2 inclui uma seção "Systems" que define um nível de transporte para vários padrões de codificação de vídeo. Sistemas de nível de transporte de MPEG-2 podem ser utilizados por codificadores de vídeo MPEG-2 ou outros codificadores de vídeo, de acordo com diferentes padrões de codificação de vídeo. Por exemplo, MPEG-4 prescreve metodologias de codificação e decodificação diferentes das do MPEG-2, mas codificadores de vídeo implementando as técnicas do padrão MPEG-4 ainda podem utilizar as metodologias de nível de transporte de MPEG-2.

Em geral, referências a "sistemas MPEG-2" nesta revelação referem-se ao nível de transporte de dados de vídeo prescrito por MPEG-2. O nível de transporte prescrito por MPEG-2 também é referido nesta revelação como um "fluxo de transporte de MPEG-2" ou, simplesmente, um "fluxo de transporte". Da mesma forma, o nível de transporte de sistemas MPEG-2 também inclui fluxos de programas. Fluxos de transporte e fluxos de programas geralmente incluem formatos diferentes para entregar dados similares, onde um fluxo de transporte compreende um ou mais "programas" incluindo dados de áudio e vídeo, enquanto que fluxos de programa incluem um programa incluindo dados de áudio e vídeo.

Esforços têm sido feitos para desenvolver novos padrões de codificação de vídeo com base em H.264/AVC. Um desses padrões é o padrão de codificação de vídeo escalável (SVC), que é a extensão escalável para H.264/AVC. Outro padrao é a codificação de vídeo multivista (M\7C), que se torna a extensão multivista para H.264/AVC. A especificação de Sistemas MPEG-2 descreve como fluxos de dados (áudio de video) multimídia comprimidos podem ser multiplexados em conjunto com outros dados para formar um único fluxo de dados adequado para armazenamento ou transmissão digital. A última especificação de sistemas MPEG-2 é especificada em "Tecnologia da Informação - Codificação Genérica de Figuras em Movimento e Sistemas de Áudio Associados, Recomendação H.222.0; Organização Internacional para Padronização, ISO/IEC JTC1/SC29/WG11; Codificação de Imagens em Movimento e Áudio Associado", Maio de 2006. MPEG projetou recentemente o padrão de transporte de MVC em sistemas MPEG-2, e a versão mais recente desta especificação é "Estudo da ISO/IEC 13818-1:2007/FPDAM4 Transporte de MVC", MPEG doc. N10572, MPEG da ISO/IEC JTC1/SC29/WG11, Maui, Havaí, EUA, Abril de 2009.

Sumário da Invenção

Em geral, esta revelação descreve técnicas para melhorar codificação de vídeo multivista em sistemas MPEG-2 (Grupo de Especialistas em Imagens em Movimento). Em particular, as técnicas desta revelação são direcionadas a uma estrutura de dados para um ponto de operação de um fluxo de bits de Sistema MPEG-2, onde a estrutura de dados sinaliza uma capacidade de renderização para um dispositivo de recepção, uma capacidade de decodificação para o dispositivo de recepção e, em alguns exemplos, uma taxa de bits para o ponto de operação. A estrutura de dados pode corresponder a um descritor de ponto de operação que está incluído no fluxo de bits do Sistema MPEG-2.

Para exibir e decodificar corretamente dados de vídeo de um ponto de operação, um dispositivo de recepção deve satisfazer as propriedades descritas pela capacidade de renderização e pela capacidade de decodificação sinalizadas na estrutura de dados. Fluxos de dados de Sistemas MPEG-2 podem incluir uma pluralidade de pontos de operação que correspondam a várias vistas de um programa. Utilizar diferentes pontos de operação para um programa 5 permite que vários dispositivos clientes realizem adaptação, isto é, dispositivos clientes com capacidades diferentes de decodificação e renderização podem extrair vistas a partir do mesmo programa para exibir dados de vídeo bidimensional ou tridimensional. Os dispositivos 10 clientes também podem negociar com um dispositivo servidor para recuperar dados de taxas de bits que variam para se adaptar a mídia de transporte de várias capacidades de largura de banda.

Em um exemplo, um método inclui construir, com um 15 dispositivo de origem, uma estrutura de dados correspondente a um ponto de operação de codificação de vídeo multivista (MVC) de um fluxo de bits de padrão de Sistema MPEG-2, no qual a estrutura de dados sinaliza um valor de capacidade de renderização que descreve uma 20 capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação 25 MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, e no qual a estrutura de dados é incluída como parte do fluxo de bits, e emitir o fluxo de bits compreendendo a estrutura de dados.

Em outro exemplo, um aparelho inclui um 30 multiplexador que constrói uma estrutura de dados correspondente a um ponto de operação MVC de um fluxo de bits de padrão de Sistema MPEG-2, no qual a estrutura de dados sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, e que inclui a estrutura de dados como parte do fluxo de dados, e uma interface de saída que emite o fluxo de bits compreendendo a estrutura de dados.

Em outro exemplo, um aparelho inclui mecanismos para construir uma estrutura de dados correspondente a um ponto de operação MVC de um fluxo de bits de padrão de Sistema MPEG-2, no qual a estrutura de dados sinaliza um valor de capacidade de renderização qüe descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, e no qual a estrutura de dados é incluída como parte do fluxo de dados, e mecanismos para emitir o fluxo de bits compreendendo a estrutura de dados.

Em outro exemplo, um meio legível por computador compreende instruções que fazem com que um processador de um dispositivo de origem construa uma estrutura de dados correspondente a um ponto de operação MVC de um fluxo de bits de padrão de Sistema MPEG-2, no qual a estrutura de dados sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, e no qual a estrutura de dados é incluída como parte do fluxo de bits, e fazer com que uma interface de saída emita o fluxo de bits compreendendo a estrutura de dados.

Em outro exemplo, um método inclui receber, com um dispositivo de destino, uma estrutura de dados correspondente a um ponto de operação MVC de um fluxo de bits de padrão de Sistema MPEG-2 (Grupo de Especialistas em Imagens em Movimento) do sistema, no qual a estrutura de dados sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, determinar se um decodificador de vídeo do dispositivo de destino é capaz de decodificar vistas correspondentes ao ponto de operação MVC com base na capacidade de decodificação sinalizada pela estrutura de dados, determinar se o dispositivo de destino é capaz de renderizar as vistas correspondentes ao ponto de operação MVC com base na capacidade de renderização sinalizada pela estrutura de dados, e enviar as vistas correspondentes ao ponto de operação MVC para o decodificador de vídeo do dispositivo de destino quando o decodificador de vídeo do dispositivo de destino estiver determinado a ser capaz de decodificar e renderizar as vistas correspondentes ao ponto de operaçao MVC.

Em outro exemplo, um aparelho inclui uma interface de entrada configurada para receber uma estrutura de dados correspondente a um ponto de operação MVC de um fluxo de bits de padrão de Sistema MPEG-2, no qual a 5 estrutura de dados sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação 10 a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, um decodificador de vídeo configurado para decodificar dados de vídeo; e um demultiplexador configurado para determinar 15 se o decodificador de vídeo é capaz de decodificar vistas correspondentes ao ponto de operação MVC com base na capacidade de decodificação sinalizada pela estrutura de dados, para determinar se o aparelho é capaz de renderizar as vistas correspondentes ao ponto de operação MVC com base 20 na capacidade de renderização sinalizada pela estrutura de dados, e para enviar as vistas correspondentes ao ponto de operação MVC para o decodificador de vídeo quando o decodificador de vídeo estiver determinado a ser capaz de decodificar e renderizar as vistas correspondentes ao ponto 25 de operação MVC.

Em outro exemplo, um aparelho inclui mecanismos para receber uma estrutura de dados correspondente a um ponto de operação MVC de um fluxo de bits de padrão de Sistema MPEG-2, no qual a estrutura de dados sinaliza um 30 valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, mecanismos para determinar se um decodificador de vídeo do aparelho é capaz de decodificar vistas correspondentes ao ponto de operação MVC com base na capacidade de decodificação sinalizada pela estrutura de dados, mecanismos para determinar se o aparelho é capaz de renderizar as vistas correspondentes ao ponto de operação MVC com base na capacidade de renderização sinalizada pela estrutura de dados, e mecanismos para enviar as vistas correspondentes ao ponto de operação MVC para o decodificador de vídeo do aparelho quando o decodificador de vídeo do aparelho estiver determinado a ser capaz de decodificar e renderizar as vistas correspondentes ao ponto de operação MVC.

Em outro exemplo, um meio de armazenamento legível por computador compreende instruções que fazem com que um processador de um dispositivo de destino receba uma estrutura de dados correspondente a um ponto de operação MVC de um fluxo de bits e padrão de Sistema MPEG-2, no qual a estrutura de dados sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC, determinar se um decodificador de vídeo do dispositivo de destino é capaz de decodificar vistas correspondentes ao ponto de operação MVC com base na capacidade de decodificação sinalizada pela estrutura de dados, determinar se o dispositivo de destino é capaz de renderizar as vistas correspondentes ao ponto de operação MVC com base na capacidade de renderização sinalizada pela estrutura de dados, e enviar as vistas correspondentes ao ponto de operação MVC para o decodificador de vídeo do dispositivo de destino quando o decodificador de vídeo do dispositivo de destino estiver determinado a ser capaz de decodificar e renderizar as vistas correspondentes ao ponto de operação MVC. Os detalhes de um ou mais exemplos são estabelecidos nos desenhos que acompanham e na descrição abaixo. Outros recursos, objetos e vantagens serão evidentes a partir da descrição e dos desenhos, e a partir das reivindicações.

BreveDescricãodosDesenhos

A figura 1 é um diagrama de blocos que ilustra um sistema exemplar, no qual um dispositivo de origem de áudio/vídeo (A/V) transporta dados de áudio e vídeo para um dispositivo de destino A/V.

A figura 2 é um diagrama de blocos que ilustra um arranjo exemplar de componentes de um multiplexador consistente com esta revelação.

A figura 3 é um diagrama de blocos que ilustra um conjunto exemplar de tabelas de informações específicas de 25 programa consistente com esta revelação.

As figuras 4 a 6 são diagramas conceituais que ilustram vários exemplos de conjuntos de dados que podem ser incluídos em um descritor de ponto de operação.

A figura 7 é um diagrama conceituai que ilustra 30 um padrão de predição MVC exemplar.

A figura 8 é um fluxograma que ilustra um método exemplar para utilizar uma estrutura de dados que sinaliza características de um ponto de operação.

Descrição Detalhada da Invenção

As técnicas desta revelação são geralmente direcionadas para aprimorar Codificação de Video Multivista (MVC) em sistemas MPEG-2 (Grupo de Especialistas em Imagens em Movimento), isto é, sistemas que estejam em conformidade com MPEG-2 com relação a detalhes de nível de transporte. MPEG-4, por exemplo, fornece padrões para codificação de vídeo, mas geralmente assume que codificadores de vídeo em conformidade com o padrão MPEG-4 utilizará sistemas de nível de transporte de MPEG-2. Portanto, as técnicas desta revelação são aplicáveis a codificadores de vídeo que estejam em conformidade com MPEG-2, MPEG-4, H.263 da ITU-T, H.264/MPEG-4 da ITU-T, ou qualquer outro padrão de codificação de vídeo que utilize fluxos de transporte de MPEG-2 e/ou fluxos de programa.

Em particular, as técnicas dessa revelação podem modificar elementos de sintaxe no nível de transporte para fluxos de transporte de MPEG-2 e fluxos de programa. Por exemplo, as técnicas desta revelação incluem um descritor, que é transmitido no fluxo de transporte, para descrever recursos de um ponto de operação. Um dispositivo servidor, por exemplo, pode fornecer vários pontos de operação em um fluxo de bits de camada de transporte de MPEG-2, cada um dos quais correspondendo a um respectivo subconjunto de vistas particulares de dados de vídeo de codificação de vídeo multívista. Isto é, um ponto de operação geralmente corresponde a um subconjunto de vistas de um fluxo de bits. Em alguns exemplos, cada vista de um ponto de operação inclui dados de vídeo na mesma taxa de quadros.

Um dispositivo de destino pode utilizar descritores de ponto de operação incluídos em um fluxo de bits para selecionar um dos pontos de operação a ser decodificado e finalmente apresentado (por exemplo, exibido) a um usuário. Ao invés de passar dados para todas as vistas a um decodificador de vídeo após recebimento, o dispositivo de destino pode enviar somente as vistas de um ponto de operação selecionado para o decodificador de vídeo. Desta forma, o dispositivo de destino pode descartar dados para vistas que não serão decodificadas. 0 dispositivo de destino pode selecionar um ponto de operação com base naquele de qualidade suportada mais alta dentre os pontos de operação para um fluxo de bits. 0 dispositivo servidor pode enviar uma pluralidade de subfluxos de bits (cada um dos quais podendo corresponder a um ponto de operação) em um único fluxo de transporte ou fluxo de programa. Embora, em várias seções, esta revelação possa se referir individualmente a um "fluxo de transporte" ou a um "fluxo de programa", deve-se compreender que as técnicas desta revelação são geralmente aplicáveis a um ou ambos dentre fluxos de transporte de MPEG-2 e fluxos de programa. Em geral, esta revelação descreve o uso de descritores como estruturas de dados exemplares para realização das técnicas desta revelação. Descritores são utilizados para estender a funcionalidade de um fluxo. Os descritores desta revelação podem ser utilizados tanto por fluxos de transporte quanto por fluxos de programa para implementar as técnicas de divulgação das informações. Embora esta revelação se concentre principalmente em descritores, como um exemplo, estrutura de dados que possa ser utilizada para sinalizar um valor de capacidade de renderização para um ponto de operação, um valor de capacidade de decodificação para o ponto de operação, e um valor de taxa de bits para o ponto de operação, deve ser entendido que outras estruturas de dados também podem ser utilizadas para realizar estas técnicas.

De acordo com as técnicas desta revelação, dispositivo de origem 20 pode construir um descritor de ponto de operação que descreva características de um ponto de operação. As características podem incluir, por exemplo, que visões são incluídas em um ponto de operação e taxas de quadros para as vistas do ponto de operação. O descritor de ponto de operação pode especificar uma capacidade de renderização, que deve ser suportada por um decodificador de vídeo, a fim de receber e decodificar o ponto de operação, uma capacidade de decodificação, que deve ser suportada pelo decodificador de vídeo, a fim de receber e decodificar o ponto de operação, e uma taxa de bits para o ponto de operação.

As técnicas desta revelação podem geralmente representar cada ponto de operação como se o ponto de operação fosse seu próprio programa, sinalizado por uma tabela de mapa de programa em um fluxo de transporte ou um mapa de fluxo de programa em um fluxo de programa. Alternativamente, quando um. programa contém múltiplos pontos de operação, as técnicas desta revelação fornecem informações sobre como os pontos de operação devem ser remontados em descritores de ponto de operação. Os descritores de ponto de operação podem ainda sinalizar dependências de pontos de operação, que pode salvar bits.

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

Dispositivo de origem 20, no exemplo da figura 1, compreende fonte de áudio 22 e fonte de vídeo 24. Fonte de áudio 2 2 pode compreender, por exemplo, um microfone que produz sinais elétricos representativos de dados de áudio capturados a ser codificados por codificador de áudio 26. Alternativamente, fonte de áudio 22 pode compreender um meio de armazenamento armazenando dados de áudio previamente gravados, um gerador de dados de áudio, tal como um sintetizador computadorizado ou qualquer outra fonte de dados de áudio. Fonte de vídeo 24 pode compreender uma câmara de vídeo que produz dados de vídeo a ser codificado por codificador de vídeo 28, um meio de armazenamento codificado com dados de vídeo previamente gravados, uma unidade de geração de dados de vídeo ou qualquer outra fonte de dados de vídeo.

Dados brutos de áudio e vídeo podem incluir dados analógicos ou digitais. Dados analógicos podem ser digitalizados antes de serem codificados por codificador de áudio 26 e/ou codificador de vídeo 28. Fonte de áudio 22 pode obter dados de áudio a partir de um participante que estiver falando enquanto o participante que estiver falando estiver falando, e fonte de vídeo 24 pode obter simultaneamente dados de vídeo do participante que estiver falando. Em outros exemplos, fonte de áudio 22 pode compreender um meio de armazenamento legível por computador compreendendo dados de áudio armazenados, e fonte de vídeo 24 pode compreender um meio de armazenamento legível por computador compreendendo dados de vídeo armazenados. Desta forma, as técnicas descritas nesta revelação podem ser aplicadas a dados de áudio e vídeo ao vivo, de fluxo contínuo, em tempo real, ou a dados de áudio e vídeo arquivados, pré-gravados.

Quadros de áudio que correspondem a quadros de vídeo são geralmente quadros de áudio contendo dados de áudio que foram capturados por fonte de áudio 22 contemporaneamente com dados de vídeo capturados por fonte de vídeo 24, que está contida dentro dos quadros de vídeo. Por exemplo, enquanto um participante que está falando geralmente produz dados de áudio por falar, fonte de áudio 22 captura os dados de áudio, e fonte de vídeo 24 captura dados de vídeo do participante que está falando ao mesmo tempo, isto é, enquanto fonte de áudio 22 está capturando os dados de áudio. Disso, um quadro de áudio pode temporariamente corresponder a um ou mais quadros de vídeo particulares. Consequentemente, um quadro de áudio correspondente a um quadro de vídeo geralmente corresponde a uma situação, na qual dados de áudio e dados de vídeo foram capturados ao mesmo tempo, e para a qual um quadro de áudio e um quadro de vídeo compreendem, respectivamente, os dados de áudio e os dados de vídeo que foram capturados ao mesmo tempo.

Em alguns exemplos, codificador de áudio 26 pode codificar um estampa de tempo em cada quadro de áudio codificado que representa um momento no qual os dados de áudio para o quadro de áudio codificado forem gravados, e, semelhantemente, codificador de vídeo 28 pode codificar uma estampa de tempo em cada quadro de vídeo codificado que representa um momento no qual os dados de vídeo para quadro de vídeo codificado forem gravados. Em tais exemplos, um quadro de áudio correspondente a um quadro de vídeo pode compreender um quadro de áudio compreendendo uma estampa de tempo e um quadro de vídeo compreendendo a mesma estampa de tempo. Dispositivo de origem A/V 20 pode incluir um relógio interno, a partir do qual codificador de áudio 26 e/ou codificador de vídeo 28 podem gerar as estampas de tempo, ou que fonte de áudio 22 e fonte de vídeo 24 podem utilizar para associar dados de áudio e vídeo, respectivamente, com uma estampa de tempo.

Em alguns exemplos, fonte de áudio 22 pode enviar dados para codificador de áudio 26 corresponde a um tempo no qual dados de áudio foram gravados, e fonte de vídeo 24 pode enviar dados para codificador de vídeo 28 corresponde a um tempo no qual dados de vídeo foram gravados. Em alguns exemplos, 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, mas sem indicar necessariamente um tempo absoluto no qual os dados de áudio foram gravados, e, semelhantemente, codificador de vídeo 28 também pode utilizar identificadores de sequência para indicar uma ordenação temporal relativa de dados de vídeo codificados. Semelhantemente, em alguns exemplos, um identificador de sequência pode ser mapeado ou, de outro modo, correlacionado com uma estampa de tempo.

As técnicas desta revelação são direcionadas geralmente para o transporte de dados multimídia (por exemplo, áudio e vídeo) codificados e recepção, e subsequente interpretação e decodificação, dos dados mulitmídia transportados. As técnicas desta revelação são aplicáveis particularmente a transporte de dados de

Codificação de Vídeo Multivista (MVC), isto é, dados de vídeo compreendendo uma pluralidade de vistas. Como mostrado no exemplo da figura 1, fonte de vídeo 24 pode fornecer uma pluralidade de vistas de uma cena para codificador de vídeo 28. MVC pode ser útil para gerar dados de vídeo tridimensionais a ser utilizados por um visor tridimensional, tal como um visor tridimensional estereoscópico ou auto-estereoscópico.

Dispositivo de origem A/V 20 pode fornecer um "serviço" para dispositivo de destino A/V 40. Um serviço geralmente corresponde a um subconjunto de vistas disponíveis de dados MVC. Por exemplo, dados MVC podem estar disponíveis para oito vistas, ordenados de zero a sete. Um serviço pode corresponder a vídeo estéreo possuindo duas vistas, enquanto que outro serviço pode corresponder a quatro vistas, e ainda outro serviço pode corresponder a todas as oito vistas. Em geral, um serviço corresponde a qualquer combinação (isto é, qualquer subconjunto) das vistas disponíveis. Um serviço também pode corresponder a uma combinação de vistas disponíveis, assim como dados de áudio. Um ponto de operação pode corresponder a um serviço de tal forma que dispositivo de origem A/V 20 possa fornecer adicionalmente um descritor de ponto de operação para cada serviço fornecido por dispositivo de origem A/V 20.

Dispositivo de origem A/V 20, de acordo com as técnicas desta revelação, é capaz de fornecer serviços que correspondam a um subconjunto de vistas. Em geral, uma vista é representada por um identificador de vista, também referido como um "view_id". Identificadores de vista geralmente compreendem elementos de sintaxe que podem ser utilizados para identificar uma vista. Um codificador MVC fornece o view_id de uma visão quando a visão é encodificada. 0 view_id pode ser utilizado por um decodificador MVC para predição de intervista ou por outras unidades para outros propósitos, por exemplo, para renderização.

Predição de intervista é uma técnica para codificar dados de vídeo MVC de um quadro com referência a um ou mais quadros em um local temporal comum como o quadro codificado de diferentes vistas. A figura 7, que é discutida em maiores detalhes a seguir, fornece um esquema 10 de codificação exemplar para predição de intervista. Em geral, um quadro codificado de dados de vídeo MVC pode ser, de modo preditivo, codificado espacialmente, temporalmente e/ou com referência a quadros de outras vistas em uma localização temporal comum. Consequentemente, vistas de 15 referência, a partir das quais ostras vistas são preditas, são geralmente decodificadas antes das vistas para as quais as vistas de referência atuam como referência, de modo que estas vistas decodificadas possam ser utilizadas para referência quando decodificar vistas de referencia. A ordem 20 de decodificação não corresponde necessariamente à ordem dos view_ids. Por isso, a ordem de decodificação de vistas é descrita utilizando índices de ordem de vista. índices de ordem de vista são índices que indicam a ordem de decodificação de componentes de vista correspondentes em 25 uma unidade de acesso.

Cada fluxo individual de dados (seja áudio ou vídeo) é referido como um fluxo elementar. Um fluxo elementar é um único componente codificado digitalmente (possivelmente comprimido) de um programa. Por exemplo, o 30 vídeo ou parte de áudio codificados do programa podem ser um fluxo elementar. Um fluxo elementar pode ser convertido em um fluxo elementar empacotado (PES) antes de ser multiplexado em um fluxo de programa ou fluxo de transporte. Dentro do mesmo programa, um ID de fluxo é utilizado para distinguir os pacotes PES pertencentes a um fluxo elementar de outro. A unidade básica de dados de um fluxo elementar é um pacote de fluxo elementar empacotado (PES). Assim, cada vista de dados de vídeo MVC corresponde a fluxos elementares respectivos. Semelhantemente, dados de áudio correspondem a um ou mais fluxos elementares respectivos.

Uma sequência de vídeo codificado MVC pode ser separada em vários subfluxos de bits, cada um dos quais é um fluxo elementar. Cada subfluxo de bits pode ser identificado utilizando-se um subconjunto de view_id de MVC. Com base no conceito de cada subconjunto de view_id de MVC, um subfluxo de bits é definido. Um subfluxo de bits de vídeo MVC contém as unidades NAL das vistas listadas no subconjunto de view_id de MVC. Um fluxo de programa geralmente contém apenas as unidades NAL que são daqueles dos fluxos elementares. Ele também é projetado para que quaisquer dois fluxos elementares não possam conter uma vista idêntica.

No exemplo da figura 1, multiplexador 30 recebe fluxos elementares compreendendo dados de vídeo provenientes de codificador de vídeo 28 e fluxos elementares compreendendo dados de áudio provenientes de codificador de áudio 26. Em alguns exemplos, codificador de vídeo 28 e codificador de áudio 26 podem incluir, cada um, empacotadores para formar pacotes PES a partir de dados codificados. Em outros exemplos, codificador de vídeo 28 e codificador de áudio 26 podem, cada um, ligar interface com respectivos empacotadores para formar pacotes PES a partir de dados codificados. Em ainda outros exemplos, multiplexador 30 pode incluir empacotadores para formar pacotes PES a partir de dados de áudio e vídeo codificados.

Um "programa", conforme utilizado nesta revelaçã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 entregue por um serviço de dispositivo de origem A/V 20. Cada pacote PES inclui um stream_id que identifica o fluxo elementar ao qual o pacote PES pertence. Multiplexador 30 é responsável por montar fluxos elementares em fluxos de transporte ou fluxos de programa constitutivos. Um fluxo do programa e um fluxo de transporte são dois multiplexes alternativos visando aplicações diferentes.

Em geral, um fluxo de programa inclui dados para um programa, enquanto que um fluxo de transporte pode incluir dados para um ou mais programas. Multiplexador 30 pode codificar um ou ambos dentre um fluxo de programa ou um. fluxo de transporte, com base em um serviço sendo fornecido, um meio no qual o fluxo será passado, um número de programas a ser enviados ou outras considerações. Por exemplo, quando os dados de vídeo estão para ser codificados em um meio de armazenamento, multiplexador 30 pode estar mais propenso a formar um fluxo de programa, ao passo que, quando os dados de vídeo estão para ser fluídos por uma rede, difundidos ou enviados como parte de telefonia de vídeo, multiplexador 30 pode estar mais propensos a utilizar um fluxo de transporte.

Multiplexador 30 pode ser influenciado em favor do uso de um fluxo de programa para o armazenamento e exibição de um único programa a partir de um serviço de armazenamento digital. Um fluxo de programa é pretendido para se utilizar em ambientes livres de erros ou ambientes menos suscetíveis a encontrar erros, porque fluxos programa são bastante suscetíveis a erros. Um fluxo de programa simplesmente compreende os fluxos elementares pertencentes a ele e usualmente contém pacotes de comprimentos variáveis. Em um fluxo de programa, pacotes PES que são derivados a partir dos fluxos elementares contribuintes são organizadas em "pacotes". Um pacote compreende um cabeçalho de pacote, um cabeçalho de sistema opcional, e qualquer número de pacotes PES tomados a partir de qualquer um dos fluxos elementares contribuintes, em qualquer ordem. O cabeçalho de sistema contém um sumário das características do fluxo de programa, tais como sua taxa de dados máxima, o número de fluxos elementares de áudio e vídeo contribuintes, informações de temporização adicionais ou outras informações. Um decodificador pode utilizar as informações contidas em um cabeçalho de sistema para determinar se o decodificador é capaz ou não de decodificar o fluxo de programa.

Multiplexador 30 pode utilizar um fluxo de transporte para a entrega simultânea de uma pluralidade de programas sobre canais potencialmente propensos a erros. Um fluxo de transporte é um multiplex concebido para aplicações multiprograma, tais como difusão, de modo que um fluxo de transporte único possa acomodar muitos programas independentes. Um fluxo de transporte pode compreender uma sucessão de pacotes de transporte, com cada um dos pacotes de transporte sendo de 188 bytes de comprimento. O uso de pacotes curtos, de tamanho fixo, faz com que o fluxo de transporte seja menos suscetível a erros do que o fluxo de programa. Além disso, a cada pacote de transporte de 188 bytes de comprimento pode ser dado proteção de erro adicional pelo processamento do pacote através de um processo de proteção de erro padrão, tal como a codificação Reed-Solomon. A resiliência de erro melhorada do fluxo de transporte significa que ele tem uma chance melhor de sobreviver aos canais propensos a erros a ser encontrado em um ambiente de difusão, por exemplo.

Pode parecer que o fluxo de transporte é melhor do que um fluxo de programa devido a sua resiliência de erro aumentada e habilidade de portar muitos programas simultâneos. No entanto, o fluxo de transporte é um multiplex mais sofisticado do que o fluxo de programa e é consequentemente mais difícil de criar e mais complicado de demultiplexar do que um fluxo de programa. O primeiro byte de um pacote de transporte pode ser um byte de sincronização possuindo um valor de 0x47 (hexadecimal 47, binário "01000111", decimal 71). Um único fluxo de transporte pode portar muitos programas diferentes, cada programa compreendendo muitos fluxos elementares empacotados. Multiplexador 30 pode utilizar um campo de Identificador de Pacote (PID) de treze bits para distinguir pacotes de transporte contendo os dados de um fluxo elementar proveniente daqueles que carregam os dados de outros fluxos elementares. É a responsabilidade do multiplexador garantir que a cada fluxo elementar seja concedido um valor PID único. O último byte de um pacote de transporte pode ser o campo de contagem de continuidade. Multiplexador 30 incrementa o valor do campo de contagem de continuidade entre sucessivos pacotes de transporte pertencentes ao mesmo fluxo elementar. Isto permite a um decodificador ou outra unidade de um dispositivo de destino, tal como um dispositivo de destino A/V 40, detectar a perda ou o ganho de um pacote de transporte e esperançosamente ocultar os erros que, de outro modo, poderiam se resultar de um evento como esse.

Multiplexador 30 recebe pacotes PES para fluxos elementares de um programa a partir de codificador de áudio 26 e de codificador de vídeo 28 e forma unidades de camada de abstração de rede (NAL) correspondentes a partir dos pacotes PES. No exemplo de H.264/AVC (Codificação de Video Avançada), segmentos de vídeo codificados são organizados em unidades NAL, que proporcionam uma representação de vídeo de "rede amigável" endereçando aplicações, tais como telefonia de vídeo, armazenamento, difusão ou fluxo contínuo. Unidades NAL podem ser categorizadas por unidades NAL de Camada de Codificação de Vídeo (VCL) e unidades NAL não-VCL. Unidades VCL contêm o motor de compressão de núcleo e pode compreender níveis de bloco, macrobloco e/ou fatia. Outras unidades NAL são unidades NAL não-VCL.

Multiplexador 30 pode formar unidades NAL compreendendo um cabeçalho que identifica um programa ao qual NAL pertença, assim como uma carga útil, por exemplo, dados de áudio, dados de vídeo ou dados que descrevam o fluxo de programa ou transporte, para o qual a unidade NAL corresponde. Por exemplo, em H.264/AVC, uma unidade NAL inclui um cabeçalho de 1 byte e uma carga útil de tamanho variável. Em um exemplo, um cabeçalho de unidade NAL compreende um elemento 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_f lag. Em MVC convencional, a unidade NAL definida por H.264 é retida, exceto por unidades NAL de prefixo e unidades NAL fatia codificada MVC, que incluem um cabeçalho de unidade NAL MVC de 4 bytes e a carga útil de unidade NAL. O elemento priority_id de um cabeçalho NAL pode ser utilizado para um único processo de adaptação de fluxo de bits de único caminho. O elemento t emporal_id pode ser utilizado para especificar o nível temporal da unidade NAL correspondente, onde diferentes níveis temporais correspondem a diferentes taxas de quadro. 0 elemento anchor_pic_flag pode indicar se uma imagem é uma imagem âncora ou uma imagem não-âncora. Imagens âncoras e todas as imagens as sucedendo na ordem de saida (isto é, a ordem de exibição) podem ser corretamente 5 decodificadas sem decodificação de imagens anteriores na ordem de decodificação (isto é, a ordem de fluxo de bits), e, assim, podem ser utilizadas como pontos de acesso aleatórios. Imagens âncoras e imagens não-âncora podem possuir dependências diferentes, ambos os quais são 10 sinalizados no conjunto de parâmetros de sequência. Outras bandeiras devem ser discutidas e utilizados nas seções seguintes deste capítulo. Tal imagem âncora também pode ser referida como um ponto de acesso GOP (Grupo de Imagens) aberto, enquanto que um ponto de acesso GOP próximo também 15 é suportado quando o elemento non_idr_flag for igual a zero. O elemento non_idr_flag indica se uma imagem é uma imagem de atualização de decodificador instantâneo (IDR) ou IDR de vista (V-IDR). Em geral, uma imagem IDR, e todas as imagens sucedendo-a em ordem de saída ou em ordem de fluxo 20 de bits, pode ser corretamente decodificada sem decodificação de imagens anteriores em ordem de decodificação ou ordem de exibição. O elemento view_id pode compreender informações de sintaxe que podem ser utilizadas para identificar uma 25 vista, que pode ser utilizada para interatividade de dados dentro de um decodificador MVC, por exemplo, para predição de intervista, e fora de um decodificador, por exemplo, para renderização. O elemento inter_view_flag pode especificar se a unidade NAL correspondente é utilizada por 30 outras vistas para predição de intervista. Para transportar as informações de cabeçalho de unidade NAL de 4 bytes para uma vista de base, que pode ser compatível com AVC, uma unidade NAL de prefixo é definida em MVC. No contexto de MVC, a unidade de acesso de vista de base inclui as unidades NAL VCL da instância de tempo atual da vista, assim 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.

A unidade NAL incluindo dados de vídeo em sua carga útil pode compreender vários níveis de granularidade de dados de vídeo. Por exemplo, uma unidade NAL pode compreender dados de um bloco de vídeo, um macrobloco, uma pluralidade de macroblocos, uma fatia de dados de vídeo ou um quadro inteiro de dados de vídeo. Multiplexador 30 pode receber dados de vídeo codificados a partir de codificador de vídeo 28 na forma de pacotes PES de fluxos elementares. Multiplexador 30 pode associar cada fluxo elementar a um programa correspondente pelo mapeamento de stream_ids a programas correspondentes, por exemplo, em um banco de dados ou outra estrutura de dados, tal como uma Tabela de Mapa de Programa (PMT) ou Mapa de Fluxo de Programa (PSM).

Multiplexador 30 também pode montar unidades de acesso a partir de uma pluralidade de unidades NAL. Em geral, uma unidade de acesso pode compreender uma ou mais unidades NAL para representar dados de um quadro de vídeo, além de dados de áudio correspondentes ao quadro quando tais dados de áudio estiverem disponíveis. Uma unidade de acesso geralmente inclui todas as unidades NAL para uma instância de tempo de saída, por exemplo, todos os dados de áudio e vídeo para uma instância de tempo. Por exemplo, se cada vista possui uma taxa de quadros de 20 quadros por segundo (fps), então, cada instância de tempo pode corresponder a um intervalo de tempo de 0,05 segundos. Durante este intervalo de tempo, os quadros específicos para todas as vistas da mesma unidade de acesso (a mesma instância de tempo) podem ser renderizados simultaneamente.

Em um exemplo correspondente a H.264/AVC, uma unidade de acesso pode compreender uma imagem codificada em uma instância de tempo, que pode ser apresentada como uma imagem codificada primária. Consequentemente, 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 tempo X. Esta revelação também se refere a uma imagem encodificada de uma vista particular como uma "componente de vista". Isto é, um componente de visualização pode compreender uma imagem (ou quadro) encodificada para uma vista particular em um tempo particular. Consequentemente, uma unidade de acesso pode ser definida como compreendendo todos os componentes de vista de uma instância temporal comum. A ordem de decodificação de unidades de acesso não precisa ser necessariamente a mesma que a ordem de exibição ou saída.

Multiplexador 30 também pode incorporar dados em relação a um programa em uma unidade NAL. Por exemplo, multiplexador 30 pode criar uma unidade NAL compreendendo uma Tabela de Mapa de Programa (PMT) ou um Mapa de Fluxo de Programa (PSM). Em geral, uma PMT é utilizada para descrever um fluxo de transporte, enquanto que um PSM é utilizado para descrever um fluxo de programa. Conforme descrito em maiores detalhes com respeito ao exemplo da figura 2, abaixo, multiplexador 30 pode compreender ou interagir com uma unidade de armazenamento de dados que associa fluxos elementares recebidos a partir de codificador de áudio 26 e codificador de vídeo 28 com programas e, consequentemente, com respectivos fluxos de transporte e/ou fluxos de programa.

Tal como com a maioria dos padrões de codificação de vídeo, H.264/AVC define os processos de sintaxe, semântica e decodificação para fluxos de bits livre de erros, qualquer um dos quais obedecem a um certo perfil ou nível. H.264/AVC não especifica o codificador, mas o codificador é encarregado de garantir que os fluxos de bits gerados sejam compatíveis com o padrão para um decodificador. No contexto do padrão de codificação de vídeo, um "perfil" corresponde a um subconjunto de algoritmos, recursos ou ferramentas, e restrições que se aplicam a eles. Como definido pelo padrão H.264, por exemplo, um "perfil" é um subconjunto da sintaxe de fluxo de bits inteira que é especificado pelo padrão H.264. Um "nível" corresponde às limitações do consumo de recursos de decodificador, tais como, por exemplo, computação e memória de decodificador, que são relacionados à resolução das imagens, taxa de bits e taxa de processamento de macrobloco (MB) . O padrão H.264, por exemplo, reconhece que, dentro dos limites impostos pela sintaxe de um dado perfil, ainda é possível requerer uma variação grande no desempenho de codificadores e decodificadores, dependendo dos valores tomados por elementos de sintaxe no fluxo de bits, tais como o tamanho especificado das imagens decodificadas. 0 padrão H.264 ainda reconhece que, em muitas aplicações, não é nem prático nem econômico implementar um decodificador capaz de lidar com todas as utilizações hipotéticas da sintaxe dentro de um perfil particular. Consequentemente, o padrão H.264 define um "nível" como um conjunto específico de restrições impostas em valores dos elementos de sintaxe no fluxo de bits. Estas restrições podem ser simples limites em valores. Alternativamente, estas restrições podem tomar a forma de restrições em combinações aritméticas de valores (por exemplo, largura de imagem multiplicada pela altura de imagem multiplicada pelo número de imagens decodificadas por segundo). O padrão H.264 prevê ainda que implementações individuais podem suportar um nível diferente para cada perfil suportado.

Um decodificador em conformidade com um perfil suporta ordinariamente todos os recursos definidos no perfil. Por exemplo, como um recurso de codificação, codificação B de imagem não é suportada no perfil de linha de base de H.264/AVC, mas é suportada em outros perfis de H.264/AVC. Um decodificador em conformidade com um nível deve ser capaz de decodificar qualquer fluxo de bits que não requer recursos além dos limites definidos no nível. Definições de perfis e níveis podem ser úteis para interpretabilidade. Por exemplo, durante transmissão de vídeo, um par de definições de nível e perfil pode ser negociado e concordado para uma sessão de transmissão inteira. Mais especificamente, em H.264/AVC, um nível pode definir, por exemplo, limitações do número de macroblocos que precisam ser processados, tamanho de armazenador de imagem decodificada (DPB), tamanho de armazenador de imagem codificada (CPB), alcance de vetor de movimento vertical, número máximo de vetores de movimento por dois MBs consecutivos, e se um bloco B pode possuir subpartições de macroblocos menores de 8x8 pixels. Desta forma, um decodificador pode determinar se o decodificador é capaz de decodificar corretamente o fluxo de bits.

Conjuntos de parâmetro geralmente contêm informações de cabeçalho de camada de sequência em conjuntos de parâmetros de sequência (SPS) e as informações do cabeçalho de camada de figura infrequentemente mudando em conjuntos de parâmetros de imagem (PPS). Com conjuntos de parâmetros, estas informações infrequentemente mudando não precisam ser repetidas para cada sequência ou imagem; disso, eficiência de codificação pode ser melhorada. Mais além, a utilização de conjuntos de parâmetros pode permitir transmissão fora da faixa de informações de cabeçalho, evitando a necessidade de transmissões redundantes para alcançar resiliência de erro. Em transmissão fora da faixa, unidades NAL de conjunto de parâmetros são transmitidas em um canal diferente das outras unidades NAL. O padrão de Sistemas MPEG-2 permite extensões do sistema por meio de "descritores". PMTs e PSMs incluem laços de descritores, nos quais um ou mais descritores podem ser inseridos. Em geral, um descritor pode compreender uma estrutura de dados que pode ser utilizada para estender a definição de programas e/ou elementos de programa. Esta revelação descreve descritores de um ponto de operação para realizar as técnicas desta revelação. Em geral, o descritor de ponto de operação desta revelação melhora o descritor de extensão MVC convencional pela descrição de uma capacidade de renderização, uma capacidade de decodificação e um taxa de bits de um ponto de operação. Um dispositivo de destino, tal como um dispositivo de destino A/V 40, pode utilizar descritores de ponto de operação para cada ponto de operação para selecionar um dos pontos de operação de um fluxo de bits para ser decodificado.

Cada PMT ou PSM pode incluir um descritor de ponto de operação que descreve características de um ponto de operação. Por exemplo, dispositivo de origem 20 pode fornecer o descritor de ponto de operação para fornecer um valor de capacidade de renderização que descreve uma capacidade de renderização para dispositivo cliente 40. Para que dispositivo cliente 40 renderize corretamente (por exemplo, exibição) dados de vídeo do ponto de operação, dispositivo cliente 40 deve satisfazer as capacidades de renderização sinalizadas pelo valor de capacidade de renderização. O valor de capacidade de renderização pode descrever, por exemplo, um número de vistas a ser exibido (por exemplo, um número de vistas direcionadas para renderização) e/ou a taxa de quadros de dados de vídeo para as vistas. Assim, dispositivo cliente 40 pode determinar que as capacidades de renderização são satisfeitas quando saída de vídeo 44 de dispositivo cliente 40 for capaz de exibir o número de vistas do ponto de operação na taxa de quadros especificada pelo descritor de ponto de operação.

Nos exemplos nos quais dispositivo de origem 20 transmite um fluxo de bits MVC utilizando protocolos de difusão ou multidifusão, dispositivo de origem 20 pode empacotar os fluxos de bits MVC inteiros em fluxos de transporte, que podem ser recebidos por dispositivos clientes possuindo várias capacidades de renderização. Por exemplo, alguns programas tridimensionais podem possuir diferentes números de vistas (por exemplo, duas vistas, quatro vistas, seis vistas ou oito vistas), e vários dispositivos podem ser capazes de utilizar qualquer um entre um e quatro pares de vistas. Assim, cada dispositivo cliente pode determinar qual ponto de operação utilizar com base no número suportado de vistas que pode ser exibido pelo dispositivo cliente. Por exemplo, dispositivo cliente 40 pode determinar qual dos pontos de operação utilizar pela determinação de um número de vistas que pode ser exibido por saída de vídeo 44 e uma taxa de quadros na qual saída de vídeo 44 seja capaz de exibir dados de vídeo e determinar qual dos pontos de operação deve ser utilizado com base nas capacidades de renderização de saída de vídeo 44.

Nos exemplos nos quais o dispositivo de origem transmite um fluxo de bits MVC utilizando um protocolo de unidifusão, dispositivo cliente 40 pode estabelecer uma sessão correspondente a um programa com um número aceitável de vistas pela verificação da capacidade de renderização especificada em descritores de ponto de operação correspondentes. Semelhantemente, em exemplos nos quais o fluxo de bits MVC é codificado em um meio de armazenamento 5 legível por computador para reprodução local, dispositivo cliente 40 pode selecionar um programa adequado pela verificação da capacidade de renderização especificada nos descritores de ponto de operação dos PMTs ou PSMs.

Dispositivo de origem 20 também pode fornecer um 10 valor de capacidades de decodificação em um descritor de ponto de operação. 0 número de vistas a ser decodificadas pode não ser necessariamente o mesmo que o número de vistas a ser exibidas. Por isso, o descritor de ponto de operação pode sinalizar separadamente o número de vistas a ser 15 exibidas e o número de vistas a ser decodifiçadas para o ponto de operação. Além de que, o descritor de ponto de operação pode identificar especificamente as vistas correspondentes ao ponto de operação. Certos dispositivos clientes podem preferir vistas particulares para vários 20 propósitos, por exemplo, com base em ângulo de visão.

Consequentemente, dispositivo cliente 40 pode ser configurado para selecionar um ponto de operação com base em quais vistas estão disponíveis no ponto de operação.

Em alguns exemplos, as capacidades de 25 decodificação assinaladas no ponto de operação podem adicionalmente ou alternativamente especificar um perfil e um nível para o qual o ponto de operação corresponda. Nos exemplos nos quais dispositivo de origem 20 transmite os fluxos de bits utilizando protocolos de difusão ou 30 multidifusão, vários dispositivos clientes com diferentes capacidades de decodificação podem receber o fluxo de bits. Por exemplo, alguns decodificadores só poderiam ser capazes de decodificar duas vistas com 30 fps, embora alguns possam ser capazes de decodificar quatro vistas com 60 fps. Nos exemplos nos quais dispositivo de origem 20 transmite o fluxo de bits utilizando um protocolo de unidifusão, dispositivo cliente 40 pode estabelecer uma sessão adequada (para um programa tridimensional específico) depois de verificar a capacidade de decodificação especificada nos descritores em PMTs. Semelhantemente, para reprodução local, dispositivo cliente 40 pode selecionar um programa adequado pela verificação da capacidade de descodificação especificada nos descritores de ponto de operação de PMTs ou PSMs.

Dispositivo de origem 20 pode sinalizar adicionalmente informações de taxa de bits no descritor de ponto de operação. As informações de taxa de bits podem descrever uma ou ambas dentre a taxa de bits média e/ou a taxa de bits máxima para o ponto de operação. Por exemplo, quando dispositivo de origem 20 transmite o fluxo de bits utilizando um protocolo de unidifusão, o canal utilizado para transmitir o fluxo de bits pode ser limitado em termos de largura de banda. Consequentemente, dispositivo cliente 40 pode selecionar um ponto de operação possuindo uma taxa de bits média ou máxima tolerável para o canal de comunicacão. 4

Em alguns exemplos, dispositivo de origem 20 ainda pode especificar a taxa de quadros do ponto de operação no descritor de ponto de operação. Certas vistas do ponto de operação podem ter taxas de quadros que não casam com a taxa de quadros do ponto de operação. Assim, dispositivo cliente 40 pode determinar a taxa de quadros do ponto de operação e a taxa de quadros de tal vista para facilitar o processo de remontar os dados de vídeo decodificados para os propósitos de exibir os dados de vídeo. Em vários exemplos, quando as taxas de quadros de dois pontos de operação não casam, dispositivo cliente 40 pode deixar cair quadros a partir de vistas do ponto de operação possuindo a maior taxa de quadros ou quadros interpolados a partir de vistas do ponto de operação possuindo a menor taxa de quadros.

Tipicamente, um fluxo elementar inclui sinalizadores "no_sei_nal_unit_present" e "no_prefix_nal_unit_present" que descrevem, respectivamente, se o fluxo elementar inclui unidades NAL de mensagens SEI e de prefixo. Esta revelação propõe que dispositivos de cliente, tais como dispositivo cliente 40, deduzam se unidades NAL de prefixo e/ou mensagens SEI estão presentes dentro de um ponto de operação, ao invés de sinalizar explicitamente estes valores para o ponto de operação. Para determinar se mensagens SEI estão presentes em um ponto de operação, dispositivo cliente 40 pode determinar se o valor máximo dos valores no_sei_nal_unit_present dos fluxos elementares para o ponto de operação é igual a um. Semelhantemente, para determinar se unidades de prefixo NAL estão presentes no ponto de operação, dispositivo cliente 40 pode determinar se o valor máximo dos valores no_prefix_nal_unit_present dos fluxos elementares para o ponto de operação é igual a um.

Os exemplos discutidos acima têm se concentrado em descritores de ponto de operação incluídos para cada ponto de operação de um fluxo de bits MVC. Como uma alternativa, dispositivo de origem 20 pode fornecer descritores de extensão MVC que sinalizam dados similares. Por exemplo, dispositivo de origem 20 pode associar mais de um descritor de extensão MVC a um subfluxo de bits de vídeo MVC que corresponde a um fluxo elementar. Dispositivo de origem 20 pode especificar, no descritor de extensão MVC para um subfluxo de bits, uma taxa de quadros, um subconjunto de view_id das vistas a ser exibidas e um número de vistas a ser decodificadas. Dispositivo de origem 20 ainda pode sinalizar um mapeamento entre os descritores de extensão MVC e o ponto de operação correspondente.

Padrões de compressão de vídeo, tais como H.261, H.262 e H.263 da ITU-T, MPEG-1, MPEG-2 e H.264/MPEG-4 part 10 fazem uso de predição temporal compensada de movimento para reduzir redundância temporal. O codificador utiliza uma predição compensada de movimento proveniente de algumas imagens previamente encodifiçadas (também referidas aqui como quadros) para predizer as imagens codificadas atuais de acordo com vetores de movimento. Existem três tipos principais de imagem em codificação de vídeo típica. Elas são imagens Intracodifiçadas ("imagens I" ou "quadros I"), imagens Preditas ("imagens P" ou "quadros P") e imagens preditas Bidimensionais ("imagens B" ou "quadros B"). Imagens P utilizam apenas a imagem de referência antes da imagem atual em ordem temporal. Em uma imagem B, cada bloco da imagem B pode ser predita a partir de uma ou duas imagens de referência. Estas imagens de referência poderiam ser localizadas antes ou depois da imagem atual em ordem temporal.

De acordo com o padrão de codificação H.264, como um exemplo, imagens B utilizam duas listas de imagens de referência previamente codificadas, lista 0 e lista 1. Estas duas listas podem conter, cada uma, imagens codificadas passadas e/ou futuras em ordem temporal. Blocos em uma imagem B podem ser preditos em um dentre vários modos: predição compensada de movimento a partir de uma imagem de referência de lista 0, predição compensada de movimento a partir de uma imagem de referência de lista 1 ou predição compensada de movimento a partir da combinação de imagens de referência de ambas lista 0 e lista 1. Para obter a combinação de imagens de referência de ambas lista 0 e lista 1, duas áreas de referência compensadas de movimento são obtidas a partir de imagens de referência de lista 0 e lista 1, respectivamente. Suas combinações serão 5 utilizadas para predizer o bloco atual. 0 padrão H.264 da ITU-T suporta intrapredição em vários tamanhos de blocos, tais como 16 por 16, 8 por 8 ou 4 por 4 para componentes de luma e 8x8 para componentes de croma, assim como interpredição em vários tamanhos de 10 bloco, tais como 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 e 4x4 para componentes de luma e tamanhos de escala correspondentes para componentes de croma. Nesta revelação, "x" e "por" podem ser utilizados indistintamente para se referir às dimensões em pixels do bloco em termos de 15 dimensões vertical e horizontal, por exemplo, 16x16 pixels ou 16 por 16 pixels. Em geral, um bloco de 16x16 terá 16 pixels em uma direção vertical (y = 16) e 16 pixels em uma direção horizontal (x = 16). Da mesma forma, um bloco NxN tem geralmente N pixels em uma direção vertical e N pixels 2 0 em uma direção horizontal, onde N representa um valor inteiro não-negativo. Os pixels em um bloco podem ser arranjados em linhas e colunas.

Tamanhos de bloco que são menores do que 16 por 16 podem ser referidos como partições de um macrobloco de 25 16 por 16. Blocos de vídeo podem compreender blocos de dados de pixel no domínio do pixel ou blocos de transformar coeficientes no domínio da transformada, por exemplo, aplicação seguinte de uma transformada, tal como uma transformada discreta de cosseno (DCT), uma transformada 30 integral, uma transformada wavelet ou uma transformada conceitualmente similar aos dados de bloco de vídeo residual representando diferenças de pixel 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 transformada quantizados no domínio da transformada.

Blocos de vídeo menores podem fornecer resolução melhor e podem ser utilizados para localizações de um quadro de vídeo que inclua altos níveis de detalhe. Em geral, macroblocos e as várias partições, algumas vezes referidas como sub-blocos, podem ser considerados blocos de vídeo. Em adição, uma fatia pode ser considerada como uma pluralidade de blocos de vídeo, tais como macroblocos e/ou sub-blocos. Cada fatia pode ser uma unidade decodificável independente de um quadro de vídeo. Alternativamente, frames em si podem ser unidades decodificáveis, ou outras partes de um quadro podem ser definidas como unidades decodificáveis. Os termos "unidade codificada" ou "unidade de codificação" podem se referir a qualquer unidade independentemente decodificável de um quadro de vídeo, tal como um quadro inteiro, uma fatia de um quadro, um grupo de imagens (GOP), também referido como uma sequência, ou outra unidade independentemente decodificável definida de acordo com técnicas de codificação aplicáveis. O termo macrobloco se refere a uma estrutura de dados para codificar dados de imagem e/ou vídeo de acordo com um arranjo de pixels bidimensional que compreende 16x16 pixels. Cada pixel compreende um componente de crominância e um componente de luminância. Consequentemente, o macrobloco pode definir quatro blocos de luminância, cada um compreendendo um arranjo bidimensional de 8x8 pixels, dois blocos de crominância, cada um compreendendo um arranjo bidimensional de 16x16 pixels, e um cabeçalho compreendendo informações de sintaxe, tais como um padrão de bloco codificado (CBP), um modo de codificação (por exemplo, modos de codificação intra (I) ou inter (P ou B)), um tamanho de partição para partições de um bloco intracodifiçado (por exemplo, 16x16, 16x8, 8x16, 8x8, 8x4, 4x8 ou 4x4) ou um ou mais vetores de movimento para um macrobloco intercodifiçado.

Codificador de vídeo 28, decodificador de vídeo 48, codificador de áudio 26, decodificador de áudio 46, multiplexador 30 e demultiplexador 38 podem ser, cada um, implementados como qualquer um de uma variedade de conjunto de circuitos de codificador ou decodificador adequados, conforme o caso, tal como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), arranjos de portas programáveis em campo (FPGAs), conjunto de circuitos de lógica discreta, software, hardware, firmware ou qualquer combinações dos mesmos. Cada um dentre codificador de vídeo 28 e decodificador de vídeo 48 pode ser incluído em um ou mais codificadores ou decodificadores, um dos quais pode ser integrado como parte de um codificador/decodificador de vídeo combinado (CODEC). Da mesma forma, cada um dentre codificador de áudio 26 e decodificador de áudio 46 podem ser incluídos em um ou mais codificadores ou decodificadores, um dos quais pode ser integrado como parte de um CODEC combinado. Um aparelho incluindo codificador de vídeo 28, decodificador de vídeo 48, codificador de áudio 26, decodificador de áudio 46, multiplexador 30 e/ou demultiplexador 38 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, tal como um telefone celular.

As técnicas desta revelação podem oferecer certas vantagens sobre as técnicas convencionais para subfluxos de bits MVC, que não fornecem características para sinalização de pontos de operação. Cada subfluxo de bits pode incluir uma ou mais vistas do fluxo de bits correspondente. Em alguns casos, um ponto de operação pode corresponder a vistas de diferentes fluxos de bits. As técnicas desta revelação fornecem um descritor de ponto de operação que identifica as vistas do ponto de operação correspondente.

Depois que multiplexador 30 tiver montado uma unidade NAL e/ou uma unidade de acesso a partir de dados recebidos, multiplexador 30 passa a unidade para interface de saída 32 para saída. Interface de saída 32 pode compreender, por exemplo, um transmissor, um transceptor, um dispositivo para escrever dados para um meio legível por computador, tal como, por exemplo, um drive óptico, um drive de mídia magnética (por exemplo, drive de disquete), uma porta de barramento serial universal (USB), uma interface de rede ou outra interface de saída. Interface de saída 32 emite a unidade NAL ou a unidade de acesso a 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, uma unidade flash ou outro meio legível por computador.

Enfim, interface de entrada 36 recupera os dados provenientes de meio legível por computador 34. Interface de entrada 36 pode compreender, por exemplo, um drive óptico, um drive de mídia magnética, uma porta USB, um receptor, um transceptor ou outra interface de meio legível por computador. Interface de entrada 36 pode fornecer a unidade NAL ou unidade de acesso a demultiplexador 38. Demultiplexador 38 pode demultiplexar um fluxo de transporte ou fluxo do programa em fluxos PES constituintes, desempacotar os fluxos PES para recuperar dados codificados, e enviar os dados codificados para decodificador de áudio 46 ou decodificador de vídeo 48, dependendo em se os dados codificados são parte de um fluxo de áudio ou vídeo, por exemplo, como indicado por cabeçalhos de pacotes PES do fluxo. Decodificador de áudio 46 decodifica dados de áudio codificados e envia os dados de áudio decodificados para saída de áudio 42, enquanto que decodificador de vídeo 48 decodifica dados de vídeo codificados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de vistas de um fluxo, para saída de vídeo 44. Saída de vídeo 44 pode compreender um visor que utiliza uma pluralidade de vistas de uma cena, por exemplo, um visor estereoscópico ou autostereoscópico que apresenta cada vista de uma cena simultaneamente.

Em particular, demultiplexador 38 pode selecionar um ponto de operação de um fluxo de bits recebido. Por exemplo, demultiplexador 38 pode comparar características de pontos de operação do fluxo de bits para selecionar um ponto de operação apropriado para ser utilizado por dispositivo de destino A/V 40. Em geral, demultiplexador 38 pode tentar selecionar um dos pontos de operação que proporcionariam a experiência de visualização de maior qualidade por um usuário que possa ser decodificado por decodificador de vídeo 48. Por exemplo, demultiplexador 38 pode comparar as capacidades de renderização e capacidades de decodificação de decodificador de vídeo 48 para as capacidades de renderização e decodificação sugeridas sinalizadas pelos descritores de ponto de operação do fluxo de bits. Dos pontos de operação que demultiplexador 38 determina que poderiam ser corretamente decodificados por decodificador de vídeo 48, demultiplexador 38 pode selecionar um ponto de operação que fornecerá os dados de vídeo de qualidade mais alta, por exemplo, as taxa de bits e/ou taxa de quadros mais altas. Em outros exemplos, demultiplexador 38 pode selecionar um dos pontos de operação suportados com base em outras considerações, tais como, por exemplo, consumo de energia.

A figura 2 é um diagrama de blocos que ilustra um arranjo exemplar de componentes de multiplexador 30 (figura 1). No exemplo da figura 2, multiplexador 30 inclui unidade de gerenciamento de fluxo 60, interface de entrada de vídeo 80, interface de entrada de áudio 82, interface de saída de fluxo multiplexado 84 e tabelas de informações específicas de programa 88. Unidade de gerenciamento de fluxo 60 inclui construtor de unidade NAL 62, construtor de PMT 64, unidade de consulta de identificador de fluxo (fluxo de ID) 66 e unidade de atribuição de identificador de programa (PID) 68.

No exemplo da figura 2, interface de entrada de vídeo 80 e interface de entrada de áudio 82 incluem respectivos empacotadores para formar unidades PES a partir de dados de vídeo codificados e dados de áudio codificados. Em outros exemplos, empacotadores de áudio e/ou vídeo podem ser incluídos em uma unidade ou módulo que seja externa ao multiplexador 30. Com respeito ao exemplo da figura 2, interface de entrada de vídeo 80 pode formar pacotes PES a partir de dados de vídeo codificados a partir de codificador de vídeo 28, e interface de entrada de áudio 82 pode formar pacotes PES a partir de dados de áudio codificados recebidos a partir de codificador de áudio 26.

Unidade de gerenciamento de fluxo 60 recebe pacotes PES a partir de interface de entrada de vídeo 80 e interface de entrada de áudio 82. Cada pacote PES inclui um ID de fluxo identificando o fluxo elementar para o qual o pacote PES pertence. Unidade de consulta de ID de fluxo 66 pode determinar um programa para o qual o pacote PES correspondente pela consulta de tabelas de informações específicas de programa 88. Isto é, unidade de consulta de ID de fluxo 66 pode determinar para qual programa um pacote PES recebido corresponde. Cada programa pode incluir uma pluralidade de fluxos elementares, enquanto em geral, um fluxo elementar corresponde a apenas um programa. Entretanto, em alguns exemplos, um fluxo elementar pode ser incluído em uma pluralidade de programas. Cada pacote PES 5 pode ser incluído em uma pluralidade de saídas de fluxos provenientes de multiplexador 30, assim como vários serviços podem incluir, cada um, vários subconjuntos de fluxos de áudio e vídeo disponíveis. Consequentemente, unidade de consulta de ID de fluxo 66 pode determinar se um 10 pacote PES deve ser incluído em um ou mais fluxos de saída (por exemplo, um ou mais fluxos de transporte ou programa), e, particularmente, em qual dos fluxos de saída incluir o pacote PES.

Em um exemplo, cada fluxo elementar corresponde a 15 um programa. Multiplexador 30 pode ser responsável por garantir que cada fluxo elementar é associado a um programa particular, e, consequentemente, 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, 20 um ID de fluxo nào-armazenado em tabelas de informações específicas de programa 88), unidade de atribuição de PID 6 8 cria uma ou mais novas entradas em tabelas de informações específicas de programa 88 para associar o novo ID de fluxo com um PID não-utilizado. 25 Depois de determinar um programa ao qual um pacote PES corresponda, construtor de unidade NAL 62 forma uma unidade NAL compreendendo o pacote PES, por exemplo, pelo encapsulamento do pacote PES com um cabeçalho de unidade NAL, incluindo o PID do programa para o qual o 30 fluxo de ID do pacote PES corresponde. Em alguns exemplos, construtor de unidade NAL 62, ou de outra subunidade de unidade de gerenciamento de fluxo 60, pode formar uma unidade de acesso compreendendo uma pluralidade de unidades NAL. Construtor de PMT 64 cria Tabelas de Mapa de Programa (PMTs) para um fluxo de saída correspondente de multiplexador 30 utilizando informações provenientes de tabelas de informações específicas de programa 88. Em outro exemplo, unidade de gerenciamento de fluxo 60 pode compreender um construtor de PSM para criar mapas de fluxo de programa para uma saída de fluxo de programa por multiplexador 30. Em alguns exemplos, multiplexador 30 pode compreender tanto construtor de PMT 64 quanto um construtor de PSM e emitir um ou ambos dentre um fluxo de transporte e um fluxo de programa. No exemplo da figura 2, construtor de PMT 64 pode construir um PMT incluindo os novos descritores descritos por esta revelação, por exemplo, um descritor de ponto de operação, assim como quaisquer outros descritores e dados PMT necessários para o PMT. Construtor de PMT 64 pode, periodicamente, por exemplo, depois de um certo período de tempo ou depois que uma certa quantidade de dados tenha sido transmitida, enviar um PMT subsequente para o fluxo de transporte. Construtor PMT 64 pode passar PMTs criados para construtor de unidade NAL 62 para formar uma unidade NAL compreendendo a PMT, por exemplo, pelo encapsulamento do PMT com um cabeçalho de unidade NAL correspondente, incluindo o PID correspondente. Construtor de PMT 64 pode criar uma estrutura de dados, tal como um descritor de ponto de operação, para cada ponto de operação de um programa. A estrutura de dados criada por construtor de PMT 64 pode sinalizar um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação, e um valor de taxa de bits que descreve um taxa de bits do ponto de operação. Por exemplo, construtor de PMT 64 pode determinar um número de vistas a ser exibido para um ponto de operação e uma taxa de quadros para as vistas do ponto de operação com base em informações armazenadas por tabelas de informações específicas de programa 88 ou informações recebidas a partir de codificador de vídeo 28 através de interface de entrada de vídeo 80. Construtor de PMT 64 pode sinalizar um ou ambos dentre o número de vistas e a taxa de quadros para as vistas do ponto de operação utilizando o valor de capacidade de renderização da estrutura de dados. Construtor de PMT 64 também pode determinar um número de vistas a ser decodificadas para o ponto de operação e um valor de nível para um perfil, para o qual as opiniões do ponto de operação correspondem. Por exemplo, construtor de PMT 64 pode determinar um número de macroblocos que precisam ser processados, um tamanho de armazenador de imagem decodificada, um tamanho de armazenador de imagem codificada, um alcance de vetor de movimento vertical, um número máximo de vetores de movimento por dois macroblocos consecutivos, e/ou se um bloco B pode possuir partições de submacroblocos menores do que 8x8 pixels, e utilizar essas determinações para determinar o nível para o ponto de operação. Construtor de PMT 64 pode receber esta informação a partir de codificador de vídeo 28 através de interface de entrada de vídeo 80. Construtor de PMT 64 pode, então, representar o número de vistas a ser decodificadas e/ou o valor do nível do perfil utilizando o valor de capacidade de decodificação para o ponto de operação. Construtor de PMT 64 pode ainda determinar um valor de taxa de bits para o ponto de operação e codificar o valor taxa de bits na estrutura de dados. 0 valor de taxa de bits pode corresponder a uma taxa de bits média ou uma 5 taxa de bits máxima para o ponto de operação. Construtor de PMT 64 pode calcular a taxa de bits para o ponto de operação ou receber uma indicação da taxa de bits a partir de codificador de vídeo 28.

Interface de saída de fluxo multiplexado 84 pode 10 receber uma ou mais unidades NAL e/ou unidades de acesso provenientes de unidade de gerenciamento de fluxo 60, por exemplo, unidades NAL compreendendo pacotes PES (por exemplo, dados de áudio ou vídeo) e/ou unidades NAL. compreendendo um PMT. Em alguns exemplos, interface de 15 saída de fluxos multiplexados 84 podem formar unidades de acesso a partir de uma ou mais unidades NAL correspondentes a um local temporal comum após as unidades NAL serem recebidas a partir de unidade de gerenciamento de fluxo 60. Interface de saída de fluxo multiplexado 84 transmite as 20 unidades NAL ou unidades de acesso como saída em um fluxo de transporte correspondente ou fluxo de programa. Interface de saída de fluxo multiplexado 84 também pode receber a estrutura de dados a partir de construtor de PMT 64 e incluir a estrutura de dados como parte do fluxo de 25 bits.

A figura 3 é um diagrama de blocos que ilustra um conjunto exemplar de tabelas de informações específicas de programa 88. 0 fluxo elementar para o qual um pacote de transporte pertence pode ser determinado com base no valor 30 PID do pacote de transporte. Para que um decodif icador decodifique corretamente dados recebidos, o decodificador deve ser capaz de determinar quais fluxos elementares pertencem a cada programa. Informações específicas de programa, como incluído em tabela de informações específicas de programa 88, podem especificar explicitamente relações entre os programas e fluxos elementares de componente. No exemplo da figura 3, tabelas 5 de informações específicas de programa 88 incluem tabela de informações de rede 100, tabela de acesso condicional 102, tabela de acesso de programa 104 e tabela de mapa de programa 106. Para o exemplo da figura 3, presume-se que o fluxo de saída compreende um fluxo de transporte de MPEG-2. 10 Em um exemplo alternativo, o fluxo de saída pode compreender um fluxo de programa, caso no qual tabela de mapa de programa 106 pode ser substituída por um mapa de fluxo de programa.

A especificação de Sistemas MPEG-2 especifica que 15 todos os programas portados em um fluxo de transporte possuem uma tabela de mapa de programa, tal como tabela de mapa de programa 106, associada a ele. Tabela de mapa de programa 106 pode incluir detalhes sobre o programa e os fluxos elementares que o programa inclui. Como um exemplo, 2 0 um programa, identificado como programa de número 3, pode conter um fluxo de vídeo elementar com PID 33, um fluxo de áudio Inglês com PID 57 e um fluxo de áudio Chinês com PID 60. É permitido para uma PMT incluir mais de um programa.

A tabela de mapa de programa básica especificada 25 pela especificação de sistemas MPEG-2 pode ser embelezada com alguns dos muitos descritores, por exemplo, descritores 108, especificado dentro da especificação de sistemas MPEG- 2. Descritores 108 podem incluir qualquer um ou todos os descritores especificados da especificação de sistemas 30 MPEG-2. Em geral, descritores, tais como descritores 108, transportam informações adicionais sobre um programa ou seus subfluxos de bits ou fluxos elementares de componente. Os descritores podem incluir parâmetros de codificação de vídeo, os parâmetros de codificação de áudio, identificação de linguagem, informações de pan-and-scan, detalhes de acesso condicional, informações de direitos autorais ou outras informações. Um difusor ou outro usuário podem definir descritores privados adicionais.

Esta revelação fornece um descritor de ponto de operação para descrever características de um ponto de operação em um fluxo de bits de conformidade de sistemas MPEG-2. Descritores 108 podem incluir descritores de ponto de operação para cada ponto de operação do fluxo de bits correspondente. Como mostrado na figura 3, descritores 108 incluem descritores de extensão MVC 110, descritor de hierarquia 112 e descritores de ponto de operação 114. Cada um dos descritores de ponto de operação 114 podem corresponder a um ponto de operação particular de um fluxo de bits e sinal, para o ponto de operação, um valor de capacidade de renderização que descreve um valor de capacidade de renderização a ser satisfeito por um dispositivo de recepção para utilizar o ponto de operação, um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação. Nos fluxos elementares de componentes relacionados a vídeo, há também um descritor de hierarquia, que fornece informações para identificar os elementos do programa contendo componentes de vídeo, áudio e fluxos privados codificados hierarquicamente.

A Tabela 1 abaixo fornece um exemplo de dados incluídos em descritores de extensão MVC 110. Os vários campos e profundidades de bits dos campos, mostrados na Tabela 1, são meramente um exemplo. Em um exemplo, cada subfluxo de bits de vídeo MVC é associado a um correspondente dos descritores de extensão MVC 110 que especifica as características dos subfluxos de bits de vídeo MVC correspondentes. Um subfluxo de bits de vídeo MVC pode precisar montar outro subfluxo de bits de vídeo MVC. Isto é, a fim de decodificar e apresentar um subfluxo de bits particular, um dispositivo cliente pode precisar extrair e decodificar dados de vídeo a partir de outros subfluxos de bits de um fluxo de bits comum que inclua os dois subfluxos de bits. Tabela 1 — Descritor de extensão MVC

No exemplo da Tabela 1, o campo de etiqueta de descritor pode corresponder a um campo de etiqueta de descritor de oito bits que está incluído em cada descritor, conforme estabelecido pelo padrão de Sistemas MPEG-2, para particularmente identificar o descritor. O padrão de Sistemas MPEG-2 define certas etiquetas de descritor e marca outros valores de etiqueta de descritor, por exemplo, valores de 36 a 63, como "reservados". Alteração 4 ao padrão de Sistemas MPEG-2 propõe, entretanto, ajustar o descritor de extensão MVC para "49", o que corresponde a uma das etiqueta de descritor reservadas, conforme especificado na especificação de Sistemas MPEG-2. Esta revelação, assim, propõe ajustar o valor do descriptor_tag de descritores de extensão MVC 110 para um valor de "49". Novamente, o campo de comprimento de descritor pode corresponder a um campo de comprimento de descritor de oito bits que também está incluído em cada descritor, conforme estabelecido pelo padrão de Sistemas MPEG-2. Multiplexador 30 pode ajustar o valor do campo de comprimento de descritor igual ao número de bytes do correspondente de descritores de extensão MVC 110 imediatamente seguindo o campo de comprimento de descritor. Devido ao comprimento de um descritor de extensão MVC não mudar, multiplexador 30 pode ajustar o valor do campo de comprimento de descritor para cada um dos descritores de extensão MVC 110 para um valor oito, para representar a presença de oito bytes de informações seguindo o campo de comprimento de descritor.

O campo de taxa de bit médio pode compreender um campo de dezesseis bits que indica a taxa de bits média, em kilobits por segundo, de um fluxo de vídeo AVC remontado. Isto é, o campo de taxa de bits média descreve a taxa de bits média para um fluxo de vídeo quando o fluxo de vídeo é montado a partir de partes constituintes do fluxo de transporte ou fluxo do programa para o qual um dentre os descritores de extensão MVC 110 corresponde. Em alguns exemplos, multiplexador 30 pode ajustar o valor do campo de taxa de bits média a zero para indicar que a taxa de bits média não é indicada pelo um dentre os descritores de extensão MVC 110.

O campo de taxa de bits máxima pode compreender um campo de dezesseis bits que indica a taxa de bits máxima, em kilobits por segundo, do fluxo de vídeo AVC remontado. Isto é, o campo de taxa de bits máxima descreve a taxa de bits máxima para um fluxo de vídeo quando o fluxo de vídeo é montado a partir de partes constituintes do fluxo de transporte ou fluxo do programa para o qual o um dentre os descritores de extensão MVC 110 corresponde. Em alguns exemplos, multiplexador 30 pode ajustar o valor do campo de taxa de bits máxima a zero para indicar que a taxa de bits máxima não é indicada pelo um dentre os descritores de extensão MVC 110.

O campo de mínimo índice de ordem de vista pode compreender um campo de dez bits que indica o valor mínimo do índice de ordem de vista de todas as unidades NAL contidas no subfluxo de bits de vídeo MVC associado. Semelhantemente, o campo máximo de índice de ordem de vista é um campo de dez bits que indica o valor máximo do índice de ordem de vista de todas as unidades NAL contidas no subfluxo de bits de vídeo MVC associado.

O campo de início de ID temporal pode compreender 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 associado. Isto é, um valor de ID temporal é incluído em um cabeçalho para cada unidade NAL. Em geral, o valor de ID temporal corresponde a uma taxa de quadros particular, onde valores de ID temporal maiores correspondem relativamente a taxas de quadros mais altas. Por exemplo, um valor de 'O'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. Desta forma, reunir todas imagens possuindo um ID temporal de 0, neste exemplo, em um conjunto pode ser utilizado para formar um segmento de vídeo possuindo uma taxa de quadros de 15 fps, enquanto que reunir todas imagens possuindo um ID temporal de 0 e todas imagens possuindo um ID temporal de 1 em um conjunto diferente pode ser utilizado para formar um segmento de vídeo diferente possuindo uma taxa de quadros de 30 fps. Multiplexador 30 determina o menor ID temporal de todas unidades NAL do subfluxo de bits de vídeo MVC e ajusta o valor do campo de início de ID temporal igual a este valor de menor ID temporal determinado.

O campo de final de ID temporal pode compreender um campo de três bits que indica o valor máximo do ID temporal do elemento de sintaxe de cabeçalho de unidades NAL de todas as unidades NAL contidas no subfluxo de bits de vídeo MVC associado. Consequentemente, 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 igual a este valor de maior ID temporal determinado.

O campo no_sei_nal_unit_present pode compreender um sinalizador de um bit que, quando ajustado para '1', indica que nenhuma unidade NAL de informações de aprimoramento suplementar está presente no subfluxo de bits de vídeo MVC associado. Multiplexador 30 pode determinar se uma ou mais unidades NAL de informações de aprimoramento suplementar têm sido colocadas no fluxo de bits e ajustar o valor do campo no_sei_nal_unit_present para um valor de quando não houver unidades NAL SEI no fluxo de bits, mas pode ajustar o valor do campo no_sei_nal_unit_present para um valor de '0' quando pelo menos uma unidade NAL SEI estiver presente no fluxo de bits.

A tabela 2 abaixo fornece um exemplo de dados incluídos em descritor de hierarquia 112. Em sistemas MPEG- 2, um descritor de hierarquia pode ser definido para um fluxo de programa de vídeo que contém um fluxo de programa de vídeo embutido. Os vários campos e profundidades de bits dos campos, mostrados na Tabela 2, são fornecidos como um exemplo. O valor de hierarchy_layer_index identifica o índice de camada do fluxo de programa atual, e o valor de hierarchy_embedded_layer_index identifica uma camada dependente. No projeto MVC, um fluxo de programa pode depender de outro fluxo de programa utilizando o descritor de hierarquia. Isto é, dependências entre fluxos de programa podem ser determinadas com base em dados incluídos no descritor de hierarquia. Tabela 2 — Descritor de hierarquia

Como observado acima, a especificação de Sistemas MPEG-2 especifica que cada descritor inclui um campo de etiqueta de descritor e um campo de comprimento de descritor. Consequentemente, descritor de hierarquia 112 5 inclui um campo de etiqueta de descritor e um campo de comprimento de descritor. De acordo com a especificação de Sistemas MPEG-2, multiplexador 30 pode ajustar o valor do campo de etiqueta de descritor para um valor de "4" para descritor de hierarquia 112.

O comprimento de descritor de hierarquia 112 pode ser determinado a priori, porque cada instância de descritor de hierarquia 112 deve incluir a mesma quantidade de dados. Em um exemplo, multiplexador 30 pode ajustar o valor do campo de comprimento de descritor para um valor de 15 quatro, indicativo de quatro bytes em uma instância de descritor de hierarquia 112 após o final do campo de comprimento de descritor.

O campo de tipo de hierarquia descreve a relação hierárquica entre a camada de hierarquia associada e sua 20 camada incorporada de hierarquia. Em um exemplo, multiplexador 30 ajusta o valor do campo de tipo de hierarquia com base na relação hierárquica, por exemplo, como descrito pela Tabela 3, abaixo. Como um exemplo, quando escalabilidade se aplica em mais de uma dimensão, 25 multiplexador 30 pode ajustar o campo de tipo de hierarquia para um valor de "8" ("Escalabilidade Combinada", conforme mostrado na Tabela 3), e multiplexador 30 ajusta valores do campo de sinalizador de escalabilidade temporal, do campo de sinalizador de escalabilidade espacial, e do campo de sinalizador de escalabilidade de qualidade de acordo com dados recuperados a partir de pacotes PES e cabeçalhos de pacotes PES dos fluxos respectivos. Em geral, multiplexador 30 pode determinar dependências entre os diferentes fluxos correspondentes a várias vistas e/ou fluxos de dados de áudio. Multiplexador 30 também pode determinar se um fluxo dependente que compreende uma camada de aprimoramento é uma camada espacial, uma camada de aprimoramento de sinal-ruido (SNR), uma camada de aprimoramento da qualidade ou outro tipo de camada de aprimoramento. Como outro exemplo, para subfluxos de bits de vídeo MVC, multiplexador 30 pode ajustar o campo de tipo de hierarquia para um valor de "9" ("MVC", conforme mostrado na Tabela 3) e pode ajustar os valores de cada um dentre o campo de sinalizador de escalabilidade, o campo de sinalizador de escalabilidade espacial e o campo de sinalizador de escalabilidade de qualidade para "1". Como ainda outro exemplo, para subfluxos de bits de vista de base de MVC, multiplexador 30 pode ajustar o valor do campo de tipo de hierarquia para um valor de "15" e pode ajustar valores do campo de sinalizador de escalabilidade, do campo de sinalizador de escalabilidade espacial e do campo de sinalizador de escalabilidade de qualidade para "1". Como ainda outro exemplo, para subfluxo de bits MVC de Prefixo, multiplexador 30 pode ajustar o campo de tipo de hierarquia para um valor de "14" e pode ajustar o campo de sinalizador de escalabilidade, o campo de sinalizador de escalabilidade espacial e o campo de sinalizador de escalabilidade de qualidade para "1".

O campo de índice de hierarquia de camada pode compreender um campo de seis bits que define um índice único do elemento de programa associado em uma tabela de hierarquias de camada de codificação. índices podem ser únicos dentro de uma única definição de programa. Para vídeo subfluxos de bits de vídeo AVC, fluxos de vídeo em conformidade com um ou mais perfis definidos em Anexo G da ITU-T Rec. H.264 | ISO/IEC 14496-10, este é o índice de elemento de programa, que é atribuído de uma forma que a ordem de fluxo de bits será correta se representações de dependência de SVC associadas dos subfluxos de bits de vídeo da mesma unidade de acesso sejam remontados em ordem crescente de hierarchy_layer_index. Para subfluxos de bits de vídeo MVC de fluxos de vídeo AVC em conformidade com um ou mais perfis definidos em Anexo H da ITU-T Rec. H.264 | ISO/IEC 14496-10, este é o índice de elemento de programa, que é atribuído de uma forma que qualquer um destes valores sejam maiores do que o valor de hierarchy_layer_index especificado no descritor de hierarquia para o subfluxo de bits de MVC de prefixo.

O campo de índice de incorporada de hierarquia pode compreender um campo de seis bits que define o índice de tabela de hierarquia do elemento de programa que necessita ser acessado antes de decodificar o fluxo elementar associado à instância correspondente do descritor de hierarquia 112. Esta revelação deixa o valor para o campo de índice de camada incorporada de hierarquia indefinido para quando o campo de tipo de hierarquia tiver um valor de "15” (isto é, um valor correspondente à camada de base).

O campo de canal de hierarquia pode compreender um campo de seis bits que indica o número de canais destinados ao elemento de programa associado em um conjunto ordenado de canais de transmissão. 0 canal de transmissão mais robusto é definido pelo valor mais baixo do campo canal de hierarquia, com respeito à definição de hierarquia de transmissão geral. Note-se que um dado canal de 5 hierarquia pode, ao mesmo tempo, ser atribuído a vários elementos de programa.

Campos reservados das Tabelas 1 e 2 são reservados para uso futuro por desenvolvimento de padrões futuros. As técnicas desta revelação não propõem, neste 10 momento, atribuir significado semântico a valores dos campos reservados.

A tabela 3 abaixo ilustra os valores de potencial para o campo de tipo de hierarquia descrito acima. Tabela 3 — Valores de campo de tipo de hierarquia

15 Em alguns exemplos, descritor de hierarquia 112 pode ser utilizado para sinalizar um subfluxo de bits MVC sinalizado por subfluxo de bits incremental e subfluxos de bits incorporados. Os subfluxos de bits incorporados incluem o subfluxo de bits diretamente dependente correspondente ao hierarchy_embedded_layer_index e a todos os subfluxos de bits embutidos deste subfluxo de bits diretamente dependente. Nesta revelação, as vistas que estão explicitamente contidas são chamadas de vistas aprimoradas, enquanto que as vistas que são incorporadas são chamadas de vistas dependentes.

Em um exemplo no qual a saída de multiplexador 30 compreende um fluxo de programa, tabelas de informações específicas de programa 88 podem incluir um mapa de fluxo de programa (PSM). Um PSM pode fornecer uma descrição dos fluxos elementares no fluxo de programa correspondente e as relações dos fluxos elementares, umas às outras. Em alguns exemplos, um mapa de fluxo de programa também pode corresponder a um fluxo de transporte. Quando portadas em um Fluxo de transporte correspondente, a estrutura PSM não deve ser modificada. Multiplexador 30 pode indicar que um PSM está presente em um pacote PES pelo ajuste do valor de stream_id do pacote PES para OxBC, isto é, o valor hexadecimal BC, que corresponde ao valor binário 10111100 ou ao valor decimal 188.

Multiplexador 30 mantém uma lista completa de todos os programas disponíveis em um fluxo de transporte em tabela de associação de programa 104. Multiplexador 30 também pode incorporar tabelas de associação do programa em unidades NAL. Multiplexador 30 pode indicar que uma unidade NAL inclui uma tabela de associação de programa pela atribuição na unidade NAL de um valor de PID de 0. Multiplexador 30 pode listar cada programa, juntamente com o valor de PID dos pacotes de transporte que contém a tabela de mapa de programa correspondente, em tabela de associação de programa 104. Utilizando-se o mesmo exemplo mencionado acima, a tabela de mapa de programa exemplar que especifica os fluxos elementares de número de programa 3 possui um PID de 10011 e outro PMT possui outro PID de 1002. Este ou conjuntos similares de informação podem ser incluídos em tabela de associação de programa 104. Tabelas de informações específicas de programa 88 também incluem tabela de informações de rede (NIT) 100 e tabela de acesso condicional (CAT) 102. Número do programa zero, conforme especificado em PAT, possui um significado especial. Em particular, número de programa zero pode ser utilizado para apontar o caminho para tabela de informações de rede 100. A tabela é opcional e, quando presente, a tabela pode fornecer informações sobre a rede física portando o fluxo de transporte, tais 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.

Se quaisquer fluxos elementares dentro de um fluxo de transporte forem embaralhados, então, uma tabela de acesso condicional 102 deve estar presente. Tabela de acesso condicional 102 fornece detalhes do(s) sistema(s) de embaralhamento em uso e fornece os valores de PID dos pacotes de transporte que contêm o gerenciamento de acesso condicional e informações de direito. O formato desta informação não é especificado dentro do padrão de Sistemas MPEG-2.

A figura 4 é um diagrama de blocos que ilustra um conjunto exemplar de dados que podem ser incluídos em um dos descritores de ponto de operação 114 (figura 3). No exemplo da figura 4, descritor de ponto de operação 118 inclui campo de etiqueta de descritor 120, campo de comprimento de descritor 122, campo de taxa de quadros 124, número de campo de vistas de exibição 126, número de campo de vistas de decodificação 128, campos de identificador de vista 130, campo de taxa de bits média 132, campo de taxa de bits máxima 134, campo de identificador temporal 136 e campos de bit de fuga reservados 138.

No exemplo da figura 4, campo de taxa de quadros 124 e número de campo de vistas de exibição 126 correspondem a uro valor de capacidade de renderização exemplar, número de campo de vistas de decodificação 128 corresponde a um valor de capacidade de decodificação exemplar, e campo de taxa de bits médio 132 e campo de taxa de bits máximo 134 correspondem a um valor de taxa de bits exemplar. Descritor de ponto de operação 118 é meramente um exemplo de uma estrutura de dados que pode ser utilizada para sinalizar características de um ponto de operação, tais como uma capacidade de renderização, uma capacidade de decodificação e uma taxa de bits. As figuras 5 e 6 abaixo fornecem exemplos alternativos de descritores de ponto de operação que sinalizam estas características.

Como descrito acima, a especificação de Sistemas MPEG-2 especifica que cada descritor possui um campo de etiqueta de descritor e um campo de comprimento de descritor, cada um de 8 bits. Assim, multiplexador 30 (figura 1) pode atribuir um valor para campo de etiqueta de descritor 120 indicativo de um descritor de ponto de operação MVC. Multiplexador 30 também pode determinar um número de vistas para o ponto de operação e um número de bits reservados para o descritor de ponto de operação, e, então, calcular o comprimento de descritor de ponto de operação 118 em bytes que seguem campo de comprimento de descritor 122. Multiplexador 30 pode atribuir este valor de comprimento calculado para campo de comprimento de descritor 122 ao instanciar descritor de ponto de operação 118.

Campo de taxa de quadros 124 pode compreender um campo de 16 bits que indica a taxa de quadros máxima, em quadros / 256 segundos, do fluxo de vídeo AVC remontado. Isto é, multiplexador 30 pode calcular a taxa de quadros máxima de um período de tempo de 256 segundo para ajustar o valor do campo de taxa de quadros 124. Em alguns exemplos, dividir por 256 pode resultar em uma conversão de um valor de ponto flutuante para um valor inteiro. Em outros exemplos, períodos de tempo diferentes de 256 segundos podem ser utilizados. 0 período de tempo de 256 segundos, com respeito ao campo de taxa de quadros 124, é meramente um exemplo potencial para que a taxa de quadros máxima de um ponto de operação pode ser calculada.

Número de campo de vistas de exibição 126 pode compreender um campo de dez bits que indica o valor do número das vistas direcionadas para emitir o fluxo de vídeo AVC remontado. Em geral, número de campo de vistas de exibição 126 representa um número de vistas a ser exibidas para um ponto de operação correspondente. Devido a visores diferentes serem capazes de exibir um número diferente de vistas, um dispositivo cliente pode utilizar o valor de número de campo de vistas de exibição 126 para selecionar um ponto de operação que possui tantas vistas a ser exibidas quanto são possíveis no visor para o dispositivo cliente. Por exemplo, se um dispositivo cliente é capaz de exibir quatro vistas, o dispositivo cliente pode selecionar um ponto de operação com um número de campo de vistas de exibição possuindo um valor indicando que quatro vistas serão exibidas para o ponto de operação correspondente. Consequentemente, número de campo de vistas de exibição 126 pode ser incluído como parte de um valor de capacidade de renderização. Da mesma forma, multiplexador 30 pode ajustar o valor de número de campo de vistas de exibição 126 de acordo com um número de vistas a ser exibidas para um ponto de operação.

Número de campo de vistas de decodificação 128 pode compreender um campo de dez bits que indica o valor do número de vistas necessárias para decodificar o fluxo de vídeo AVC remontado. Este valor pode diferir do número de vistas a ser exibidas, indicado pelo número de campo de vistas de exibição 126. Isto pode se resultar de certas vistas serem requeridas para decodificação, devido a dependências de vista, mas não serem atualmente exibidas.

Referindo-se brevemente à figura 7, como um exemplo, vistas S0 e SI podem ser vistas que devem ser exibidas para um ponto de operação. Vista S0 pode ser decodificada diretamente sem decodificar quaisquer outras vistas. Entretanto, para decodificar vista Sl, vista S2 também deve ser decodificada, porque vista Sl inclui dados de predição referentes a vista S2. Por isso, neste exemplo, número de campo de vistas de exibição 126 teria um valor de dois, mas número de campo de vistas de decodificação 128 teria um valor de três. Em alguns exemplos, uma vista a ser exibida pode ser interpolada a partir de uma ou mais outras vistas, tal que o número de vistas a ser exibidas pode ser maior que o número de vistas a ser decodificadas, isto é, utilizando uma vista de base e informações de profundidade, decodificador de vídeo 48 (figura 1) pode interpolar uma segunda vista. Decodificador de vídeo 48 pode utilizar duas ou mais vistas para calcular informações de profundidade para interpolar uma nova vista, ou decodificador de vídeo 48 pode receber informações detalhadas para uma vista a partir de dispositivo de origem 20.

Número de campo de vistas de decodificação 128 pode corresponder a um valor de capacidade de decodificação, em que um decodificador de um dispositivo cliente (tal como o decodificador de vídeo 48 de dispositivo de destino 40) deve ser capaz de decodificar um número de vistas igual ao valor de número de campo de vistas de decodificação 128. Consequentemente, o dispositivo cliente pode selecionar um ponto de operação possuindo um número de campo de vistas de decodificação representativo de um número de vistas que um decodificador de vídeo do dispositivo cliente é capaz de decodificar.

Descritor de ponto de operação 118 da figura 4 também inclui campos de identificador de vista 130. Cada um dos campos de identificador de vista 130 pode compreender um campo de bits dez que indica o valor do view id das unidades NAL contidas no fluxo de bits de vídeo AVC remontado. Assim, os identificadores de vista de cada vista exibida para um ponto de operação são sinalizados utilizando campos de identificador de vista 130. Isto é, os identificadores de vista de campos de identificador de vista 130 correspondem às vistas exibidas. Assim, vistas que são decodificadas, mas não são exibidas, não são sinalizadas pelos campos de identificador de vista 130, no exemplo da figura 4.

Campo de taxa de bits média 132 pode compreender um campo de dezesseis bits que indica a taxa de bits média, em kilobits por segundo, do fluxo de vídeo AVC remontado. Quando ajustado para 0, a taxa de bits média não é indicada. Isto é, um valor de zero para o campo de taxa de bits média 132 implica que o campo de taxa de bits média 132 não deve ser utilizado para determinar a taxa de bits média do fluxo de vídeo AVC remontado.

Campo de taxa de bits máximo 134 pode compreender um campo de dezesseis bits que indica a taxa de bits máxima, em kbits por segundo, do fluxo de vídeo AVC remontado. Quando ajustado para 0, a taxa de bits máxima não é indicado. Isto é, quando o valor de campo de taxa de bits máxima 134 é ajustado para zero, campo de taxa de bits máxima 134 não deve ser utilizado para determinar a taxa de bits máxima do fluxo de vídeo AVC remontado.

Campo de identificador temporal 136 pode compreender um campo de três bits que indica o valor do 5 temporal_id, correspondendo à taxa de quadros do fluxo de vídeo AVC remontado. Isto é, o temporal_id pode ser utilizado para determinar a taxa de quadros do fluxo de vídeo AVC remontado, como discutido acima.

Descritor de ponto de operação exemplar 118 10 também inclui campos de bit de fuga reservado 138. Em um exemplo, por exemplo, como mostrado na Tabela 4, abaixo, o número de bits de fuga reservados pode ser utilizado tanto para sinalização adicional quanto para encher descritor de ponto de operação 118, de tal modo que descritor de ponto 15 de operação 118 termine em um limite de byte. Por exemplo, como discutido acima, descritor de ponto de operação 118 pode utilizar dez bits para representar o identificador de vista de cada vista exibida. O número estático de bits além dos bits utilizados para os identificadores de vista e para 20 os bits de fuga reservados é de 87, neste exemplo. Assim, para garantir que descritor de ponto de operação 118 termine em um limite de bytes (isto é, ter um número de bits que é divisível uniformemente por oito), multiplexador 30 pode adicionar um número de bits de fuga de acordo com a 25 seguinte fórmula: bits de fuga = (1+6 * num_display_views) 8% onde "%" representa o operador de módulo matemático. Isto é, A % B resulta no resto de A dividido por B, de tal forma que o resto esteja na faixa de números 30 inteiros entre 0 e B-l.

A Tabela 4 resume um conjunto exemplar de dados que podem ser incluídos no exemplo de descritor de ponto de operação 118 da figura 4. Tabela 4 — Descritor de ponto de operação MVC

A figura 5 é um diagrama de blocos que ilustra um conjunto exemplar alternativo de dados que podem ser incluídos em um dos descritores de ponto de operação 114 5 (figura 3). Em geral, cada um dos descritores de ponto de operação 114 deve ter um formato comum, de modo que um dispositivo cliente possa ser configurado para receber descritores de ponto de operação de um único formato. Assim, cada um dos descritores de ponto de operação 114 pode ter um formato similar ao do descritor de ponto de operação da figura 4, da figura 5 ou da figura 6 ou outro formato comum, que inclui dados de sinalização similares.

No exemplo da figura 5, descritor de ponto de operação 140 inclui campo de etiqueta de descritor 142, campo de comprimento de descritor 144, campo de profile_idc 146, campo de level_idc 148, campo de taxa de quadros 149, número de campo de vistas de exibição 150, número de campos de vistas de decodificação 152, campo de taxa de bits média 154, campo de taxa de bits máxima 156, campo de identificador temporal 158, campo de bits reservados 160, campos de índice de ordem de vista 162, campos de identificador de vista 164 e campos de bit de fuga reservado 166. IDC significa "indicador". Como explicado abaixo, o exemplo de descritor de ponto de operação 140 sinaliza explicitamente os valores de profile_idc e level_idc para um ponto de operação, assim como informações sobre como um ponto de operação é montado.

Número de campo de vistas de exibição 150 e campo de taxa de quadros 149 correspondem a um valor de capacidades de renderização sinalizado por descritor de ponto de operação 140. Campo de profile_idc 146, campo de level_idc 148 e número de campo de vistas de decodificação 152, no exemplo da figura 5, representam exemplos de dados que podem corresponder a um valor de capacidade de decodificação sinalizado por descritor de ponto de operação 140. Campo de taxa de bits média 154 e campo de taxa de bits máxima 156 correspondem a um valor de taxa de bits sinalizado por descritor de ponto de operação 140.

Como descrito acima, a especificação de Sistemas MPEG-2 especifica que cada descritor possui um campo de etiqueta de descritor e um campo de comprimento de descritor, cada um dos quais pode ser de 8 bits de comprimento. Assim, multiplexador 30 (figura 1) pode atribuir um valor campo de etiqueta de descritor 142, 5 indicativo de um descritor de ponto de operação MVC.

Multiplexador 30 também pode determinar um número de vistas para o ponto de operação e um número de bits reservados para o descritor de ponto de operação e, em seguida, calcular o comprimento de descritor de ponto de operação 10 140, em bytes, que segue campo de comprimento de descritor 144. Multiplexador 30 pode atribuir este valor a campo de comprimento de descritor 144 ao instanciar descritor de ponto de operação 140.

Campo de profile_idc 146 pode compreender um 15 campo de oito bits que indica o profile_idc do ponto de operação remontado pelas informações dadas em descritor de ponto de operação 140. Campo level_idc 148 pode compreender um campo de oito bits que indica o level_idc do ponto de operação remontado pelas informações dadas em descritor de 20 ponto de operação 140.

Campo de taxa de quadros 149 pode compreender um campo de 16 bits que indica a taxa de quadros máxima, em quadro / 256 segundos, do fluxo de vídeo AVC remontado. Isto é, multiplexador 30 pode calcular a taxa de quadros 25 máxima de um período de tempo de 256 segundos para ajustar o valor de campo de taxa de quadros 149. Como em campo de taxa de quadros 124, em outros exemplos para campo de taxa de quadros 14 9, outros períodos de tempo além de 25 6 segundos podem ser utilizados. 30 Número de campo de vistas de exibição 150 pode compreender um campo de bits dez que indica o valor do número de vistas direcionadas para emitir o fluxo de vídeo AVC remontado. Em geral, número de campo de vistas de exibição 150 representa um número de vistas a ser exibidas para um ponto de operação correspondente. Número de campo de vistas de decodificação 152 pode compreender um campo de dez bits que indica o valor do número de vistas requeridas para decodificar o fluxo de vídeo AVC remontado. Este valor pode diferir do número de vistas a ser exibidas, indicado pelo número de campo de vistas de exibição 150. Isto pode se resultar de certas vistas serem requeridas para decodificação, devido a dependências de vista, mas não serem atualmente visualizadas, por exemplo, como descrito acima com respeito a número de campo de vistas de decodificação 128.

Campo de taxa de bits média 154 pode compreender um campo de dezesseis bits que indica a taxa de bits média, em kilobits por segundo, do fluxo de vídeo AVC remontado. Quando ajustado para 0, a taxa de bits média não é indicada. Isto é, um valor de zero para campo de taxa de bits médio 154 implica que campo de taxa de bits médio 154 não deve ser utilizado para determinar a taxa de bits média do fluxo de vídeo AVC remontado. Campo de taxa de bits máximo 156 pode compreender um campo de dezesseis bits que indica a taxa de bits máxima, em kbits por segundo, do fluxo de vídeo AVC remontado. Quando ajustado para 0, a taxa de bits máxima não é indicada. Isto é, quando o valor de campo de taxa de bits máximo 156 é ajustado para zero, campo de taxa de bits máximo 156 não deve ser utilizado para determinar a taxa de bits máxima de fluxo de vídeo AVC remontado.

Campo de identificador temporal 158 pode compreender um campo de três bits que indica o valor do temporal_id, correspondendo à taxa de quadros do fluxo de vídeo AVC remontado. Isto é, o temporal id pode ser utilizado para determinar a taxa de quadros do fluxo de vídeo AVC remontado, como discutido acima.

Descritor de ponto de operação 140 também inclui campos de índice de ordem de vista 162 e campos de identificador de vista 164. Cada um dos campos de índice de ordem de vista 162 pode compreender um campo de dez bits que indica o valor do índice de ordem de vista das unidades NAL contidas no ponto de operação. Um dispositivo cliente pode remontar as unidades NAL correspondentes a todos os valores de view_order_index sinalizados em descritor de ponto de operação 140 por campos de índice de ordem de vista 162. Campos de índice de ordem de vista 162 incluem campos de índice de ordem de vista para cada uma das vistas a ser decodificadas. D do um valor de view_order_index, um dispositivo cliente pode extrair as unidades NAL correspondentes a partir dos fluxos elementares, porque o descritor de extensão MVC diz o alcance dos valores de índice de ordem de vista, em que fluxo elementar e alcance cobrem o valor de view_order_index sinalizado no descritor de ponto de operação.

Cada um dos campos de identificador de vista 164 pode compreender um campo de dez bits que indica o valor do view_id das unidades NAL contidas no fluxo de bits de vídeo AVC remontado. Assim, os identificadores de vista de cada vista exibida para um ponto de operação são sinalizados utilizando-se campos de identificador de vista 164. Isto é, os identificadores de vista de campos de identificador de vista 164 correspondem às vistas exibidas. Assim, vistas que são decodificadas, mas não exibidas, não são sinalizadas por campos de identificador de vista 164, no exemplo da figura 5.

Descritor de ponto de operação 140 também inclui campos de bit de fuga reservado 166. Descritor de ponto de operação 140 pode incluir bits de fuga como preenchimento, de tal forma que o número de bits em descritor de ponto de operação 140 é divisível uniformemente por oito. Devido ao número de campos de índice de ordem de vista e aos campos 5 de identificador de vista poderem variar, o número de bits de fuga que multiplexador 30 inclui em descritor de ponto de operação 140 pode consequentemente variar. Por exemplo, o número de bits de fuga pode ser determinado de acordo com a seguinte fórmula: 10 bits de fuga = (6* (num_display_views + num_decode_views)) % 8 onde "%" representa o operador de módulo.

A Tabela 5 resume um conjunto exemplar de dados que podem ser incluídos no descritor de ponto de operação 15 140 exemplar da figura 5. Tabela 5 — Descritor de ponto de operação MVC

A figura 6 é um diagrama de blocos que ilustra outro conjunto exemplar alternativo de dados que podem ser incluídos em um dos descritores de ponto de operação 114 (figura 3). No exemplo da figura 6, descritor de ponto de 5 operação 170 inclui campo de etiqueta de descritor 172, campo de comprimento de descritor 174, campo de profile_idc 176, campo de level_idc 178, campo de taxa de quadros 180, número de campo de vistas de exibição 182, número de campo de vistas de decodificação 184, campo de taxa de bits média 10 186, campo de taxa de bits máxima 188, campo de identificador temporal 190, campo de bits reservados 192, campo de identificador de ponto de operação 194, campo de sinalizador independente de ponto de operação 196, campo de identificador de ponto de operação dependente opcional 198, 15 campos de índice de ordem de vista 200, campos de identificador de vista 202 e campos de bit de fuga reservado 204. Como descrito abaixo, descritor de ponto de operação 170 fornece um descritor de ponto de operação exemplar para um ponto de operação que depende de outro ponto de operação e que sinaliza vistas extra necessárias para decodificação.

Número de campo de vistas de exibição 182 e campo de taxa de quadros 180 correspondem a um valor de capacidade de renderização sinalizado por descritor de ponto de operação 140. Campo de profile_idc 176, campo de level_idc 178 e número de campo de vistas de decodificação 184, no exemplo da figura 6, representam exemplos de dados que podem corresponder a um valor de capacidade de decodificação sinalizado por descritor de ponto de operação 140. Campo de taxa de bits média 154 e campo de taxa de bits máxima 156 correspondem a um valor de taxa de bits sinalizado por descritor de ponto de operação 140.

Como descrito acima, a especificação de Sistemas MPEG-2 especifica que cada descritor possui um campo de etiqueta de descritor e um campo de comprimento de descritor, cada um de 8 bits. Assim, multiplexador 30 (figura 1) pode atribuir um valor para campo de etiqueta de descritor 172, indicativo de um descritor de ponto de operação MVC. Multiplexador 30 também pode determinar um número de vistas para o ponto de operação e um número de bits reservados para o descritor de ponto de operação e, então, calcular o comprimento de descritor de ponto de operação 170, em bytes, que segue campo de comprimento de descritor 174. Multiplexador 30 atribui este valor de comprimento calculado para campo de descritor de comprimento 174 quando instanciar descritor de ponto de operação 140.

Campo de profile_idc 176 pode compreender um campo de oito bits que indica o profile_idc do ponto de operação remontado pelas informações dadas em descritor de ponto de operação 170. Campo de level_idc 178 pode compreender um campo de oito bits que indica o level_idc do ponto de operação remontado pelas informações dadas em descritor de ponto de operação 170.

Campo de taxa de quadros 180 pode compreender um campo de 16 bits que indica a taxa de quadros máxima, em quadro / 256 segundos, do fluxo de video AVC remontado. Isto é, multiplexador 30 pode calcular a taxa de quadros máxima de um período de tempo de 256 segundos para ajustar o valor de campo de taxa de quadros 149. Tal como com campo de taxa de quadros 124, em outros exemplos para campo de taxa de quadros 180, outros períodos de tempo além de 256 segundos podem ser utilizados.

Número de campo de vistas de exibição 182 pode compreender um campo de bits dez que indica o valor do número das vistas direcionadas para emitir o fluxo de vídeo AVC remontado. Em geral, número de campo de vistas de exibição 182 representa um número de vistas a ser exibidas para um ponto de operação correspondente. Número de campo de vistas de decodificação 184 pode compreender um campo de bits dez que indica o valor do número de vistas requeridas para decodificar o fluxo de vídeo AVC remontado. Este valor pode diferir do número de vistas a ser exibidas, indicado pelo número de campo de vistas de exibição 182. Isto pode se resultar de certas vistas serem requeridas para decodificação, devido a dependências de vista, mas não serem atualmente visualizadas, por exemplo, como descrito acima com respeito a número de campo de vistas de decodificação 128.

Campo de taxa de bits média 186 pode compreender um campo de dezesseis bits que indica a taxa de bits média, em kilobits por segundo, do fluxo de vídeo AVC remontado.

Quando ajustado para 0, a taxa de bits média não é indicado. Isto é, um valor de zero para campo de taxa de bits média 186 implica que campo de taxa de bits média 186 não deve ser utilizado para determinar a taxa de bits média do fluxo de vídeo AVC remontado. Campo taxa de bits máxima 188 pode compreender um campo de dezesseis bit que indica a taxa de bits máxima, em kbits por segundo, do fluxo de vídeo AVC remontado. Quando ajustado para 0, a taxa de bits máxima não é indicada. Em particular, quando o valor de campo de taxa de bits máxima 188 é ajustado para zero, campo de taxa de bits máxima 188 não deve ser utilizado para determinar a taxa de bits máxima do fluxo de vídeo AVC remontado.

Campo de identificador temporal 190 pode compreender um campo de três bits qüe indica o valor do temporal_id, correspondendo à taxa de quadros do fluxo de vídeo AVC remontado. Isto é, o temporal_id pode ser utilizado para determinar a taxa de quadros do fluxo de vídeo AVC remontado, como discutido acima. Campo de bit reservado 192 corresponde a um único bit, que é reservado para uso futuro.

Descritor de ponto de operação 170 também inclui campo de identificador de ponto de operação 194 e campo de sinalizador dependente de ponto de operação 196. Campo de identificador de ponto de operação 194 pode compreender um campo de dez bits que indica o identificador do ponto de operação descrito por descritor de ponto de operação 170. Campo de sinalizador dependente de ponto de operação 196 é um único sinalizador de bit que indica se uma dependência do ponto de operação atual em outro ponto de operação é sinalizada. Se sinalizador dependente de ponto de operação 196 possuir um valor de um (ou verdadeiro), a dependência é sinalizada; se o valor de sinalizador dependente de ponto de operação 196 for zero (ou falso), a dependência não é sinalizada.

Quando o valor de sinalizador dependente de ponto de operação 196 for verdadeiro ou um, descritor de ponto de 5 operação 170 inclui adicionalmente campo de identificador de ponto de operação dependente 198. Quando presente, campo de identificador de ponto de operação 198 pode compreender um campo de dez bits que indica o identificador do ponto de operação que o descritor atual depende. Isto é, quando 10 multiplexador 30 determina que descritor de ponto de operação 170 corresponde a um ponto de operação que depende de outro ponto de operação, multiplexador 30 ajusta o valor de sinalizador dependente de ponto de operação para verdadeiro ou um e, então, sinaliza o identificador do 15 ponto de operação no qual o ponto de operação correspondente a descritor de ponto de operação 170 depende.

Descritor de ponto de operação 170 também inclui campos de índice de ordem de vista 200 e campos de 20 identificador de vista 202. Cada um dos campos de índice de ordem de vista 2 02 pode compreender um campo de dez bits que indica o valor do índice de ordem de vista das unidades NAL contidas no ponto de operação atual com um identificador de operation_point_id, mas não contidas no 25 ponto de operação com um identificador de dependent_operation_point_id. Um dispositivo cliente pode remontar as unidades NAL correspondentes a todos os valores de view_order_index sinalizados em descritor de ponto de operação 170 por campos de índice de ordem de vista 200. 30 Campos de índice de ordem de vista 200 incluem campos de índice de ordem de vista para cada uma das vistas a ser decodificadas. Dado um valor de view_order_index, um dispositivo cliente pode extrair as unidades NAL correspondentes a partir dos fluxos elementares, porque o descritor de extensão MVC diz o alcance dos valores de índice de ordem de vista nos quais fluxo elementar e o alcance cobrem o valor de view_order__index sinalizado no descritor de ponto de operação. O ponto de operação sinalizado em descritor de operação de ponto 170 é remontado pelas unidades NAL correspondentes a todos os valores de view_order_index sinalizados de campos de índice de ordem de vista 200 e as unidades NAL contidas pelo ponto de operação com identificador de dependent_operation_point_id.

Cada um dos campos de identificador de vista 202 pode compreender um campo de dez bits que indica o valor do view_id das unidades NAL contidas no fluxo de bits de vídeo AVC remontado. Assim, os identificadores de vista de cada vista exibida para um ponto de operação são sinalizados utilizando campos de identificador de vista 202. Isto é, os identificadores de vista de campos de identificador de vista 164 correspondem às vistas exibidas. Assim, vistas que são decodificados, mas não exibidas, não são sinalizadas pelos campos de identificador de vista 202, no exemplo da figura 5.

Descritor de ponto de operação 170 também inclui campos de bit de fuga reservados 204. Descritor de ponto de operação 170 pode incluir bits de fuga como preenchimento, de tal forma que o número de bits em descritor de ponto de operação 170 é divisível uniformemente por oito. Devido ao número de campos de índice de ordem de vista e aos campos de identificador de vista poderem variar, o número de bits de fuga que multiplexador 30 inclui em descritor de ponto de operação 170 pode consequentemente variar. Por exemplo, o número de bits de fuga pode ser determinado de acordo com a seguinte fórmula: bits de fuga = (6*(num_display_views + num_decode_views)) % 8 onde "%"representa o operador de módulo. A Tabela 6 abaixo resume um conjunto exemplar de 5 dados que podem ser incluidos no descritor de ponto de operação 170 exemplar da figura 6. Tabela 6 — Descritor de ponto de operação MVC

Como ainda outra alternativa, dispositivo de origem 20 (figura 1) sinaliza características de um ponto de operação utilizando uma estrutura de dados além de um descritor de ponto de operação. Por exemplo, dispositivo de 5 origem 20 pode sinalizar um valor capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, um valor de capacidade de decodificação que descreve uma capacidade de decodificação 10 a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC utilizando descritor de extensão MVC modificado. A Tabela 7 abaixo ilustra um exemplo de tal descritor de extensão MVC 15 modificada. Tabela 7 — Descritor de extensão MVC

Multiplexador 30 (figura 2) pode construir descritores de extensão MVC 110 de acordo com a sintaxe definida pela Tabela 7. Em geral, a semântica dos elementos sintáticos da Tabela 7 é a mesma que a dos elementos 5 comumente nomeados descritos com respeito à Tabela 1 acima. 0 exemplo da Tabela 7 inclui elementos adicionais sobre os da Tabela 1, a saber, um campo de taxa de quadros, um número de campo de vistas de exibição, um número de campo de vistas de decodificação e campos de identificador de vista para cada vista de um ponto de operação para o qual o descritor de extensão MVC corresponde. 0 campo de taxa de quadros pode compreender um campo de dezesseis bits que indica a taxa de quadros máxima, em quadros / 256 segundos, do fluxo de video AVC remontado. O número de campo de vistas de exibição "num_display_views" pode compreender um campo de dez bits que indica o valor do número das vistas direcionadas para emitir o fluxo de vídeo AVC remontado. 0 número de campo de vistas de decodificação "num_decode_views" pode compreender um campo de dez bits que indica o valor do número das vistas requeridas para decodificar o fluxo de vídeo AVC remontado. Cada um dos campos de identificador de vista "viewid" pode compreender um campo de dez bits que indica o valor do view_id das unidades NAL para uma vista correspondente contida no fluxo de bits de vídeo AVC remontado.

Em alguns exemplos, um ou mais descritores de ponto de operação podem incluir valores que indicam um valor de identificador temporal máximo e um valor de taxa de quadros máxima de todos os pontos de operação MVC de um fluxo de bits. Em alguns exemplos, o valor de identificador temporal máximo e o valor de taxa de quadros máxima de todos os pontos de operação MVC do fluxo de bits podem ser sinalizados em um descritor de ponto de operação MVC.

A figura 7 é um diagrama conceituai que ilustra um padrão de predição MVC exemplar. No exemplo da figura 7, oito vistas (possuindo IDs de vista de "SO" a "S7") são ilustradas, e doze localizações temporais (de "TO" a "Til") são ilustrados para cada exibição. Isto é, cada linha na figura 7 corresponde a uma vista, enquanto que cada coluna indica uma localização temporal.

Embora MVC possua uma assim chamada vista de base, que é decodificável por decodificadores H.264/AVC, e par de vista estéreo também possa ser suportado por MVC, a vantagem do MVC é que ele possa suportar um exemplo que utiliza mais de duas vistas como uma entrada de vídeo 3D e decodifica este vídeo 3D representado pelas múltiplas vistas. Um renderizador de um cliente possuindo um decodificador MVC pode esperar conteúdo de vídeo 3D com múltiplas vistas.

Quadros na figura 7 são indicados na indicação de cada linha e de cada coluna na figura 7 utilizando um bloco sombreado incluindo uma letra, designando se o quadro correspondente é intracodifiçado (isto é, um quadro I) ou intercodifiçado em uma direção (isto é, como um quadro P) ou em múltiplas direções (isto é, como um quadro B). Em geral, predições são indicadas por setas, onde o quadro apontado utiliza o objeto que aponta como referência de predição. Por exemplo, o quadro P de vista S2 em localização temporal TO é predito a partir do quadro I de vista S0 em localização temporal TO.

Tal como com codificação de vídeo de única vista, quadros de uma sequência de vídeo de codificação de vídeo multivista podem ser codificados preditivamente com respeito a quadros em diferentes localizações temporal. Por exemplo, o quadro b de vista S0 em localização temporal T1 possui uma seta apontada para ele a partir do quadro I de vista S0 em localização temporal TO, indicando que o quadro b é predito a partir do quadro I. Adicionalmente, no entanto, no contexto de codificação de vídeo multivista, quadros podem ser intervista predita. Isto é, um componente de vista pode utilizar componentes de vista em outras vistas por referência. Em MVC, por exemplo, predição de intervista é realizada como se o componente de vista em outra vista fosse uma referência de interpredição. As referências de intervistas potenciais são sinalizadas na extensão MVC de Conjunto de Parâmetros de Sequência (SPS) e podem ser modificadas pelo processo de construção de lista 5 de imagem de referência, que permite ordenação flexível das referências de predição intervista ou interpredição. A Tabela 8 abaixo fornece uma definição exemplar para um conjunto de parâmetros de sequência de extensão MVC. Tabela 8

A figura 7 fornece vários exemplos de predição de intervista. Quadros de vista Sl, no exemplo da figura 7, são ilustrados como sendo preditos a partir de quadros em diferentes localizações temporais de vista Sl, assim como 5 intervista predita a partir de quadros de quadros de vistas SO e S2 nos mesmos localizações temporais. Por exemplo, o quadro b de vista Sl em localização temporal TI é predito a partir de cada um dos quadros B de vista Sl em localizações temporais TO e T2, assim como os quadros b de vistas S0 e S2 em localização temporal Tl.

No exemplo da figura 7, "B" maiúsculo e "b" minúsculo se destinam a indicar diferentes relações hierárquicas entre quadros, em vez de metodologias de codificação diferentes. Em geral, quadros de "B" maiúsculo são relativamente maiores na hierarquia de predição que quadros de "b" minúsculo. A figura 7 também ilustra variações na hierarquia de predição utilizando diferentes níveis de sombreamento, onde uma quantidade maior de quadros de sombreamento (isto é, relativamente mais escuro) é maior na hierarquia de predição do que aqueles quadros possuindo menos sombreamento (isto é, relativamente mais claro). Por exemplo, todos os quadros I na figura 7 são ilustrados com sombreamento total, enquanto que quadros P possuem um sombreamento um pouco mais leve e quadros B (e quadro de b minúsculo) possuem vários níveis de sombreamento em relação uns aos outros, mas sempre mais claro que o sombreamento dos quadros P e quadros I.

Em geral, a hierarquia de predição está relacionada a índices de ordem de vista, em que quadros relativamente maiores na hierarquia de predição devem ser decodificado antes de quadros de decodificação que são relativamente menores na hierarquia, de tal modo que quadros relativamente maiores na hierarquia possam ser utilizados como quadros de referência durante decodificação dos quadros relativamente menores 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 são implícitos na extensão MVC de SPS, conforme especificado em Anexo H de H.264/AVC (alteração MVC). No SPS, para cada índice i, o view_id correspondente é sinalizado. A decodificação dos componentes de vista seguirá a ordem ascendente do índice de ordem de vista. Se todas as vistas forem apresentadas, em seguida, os índices de ordem de vista estão em uma ordem consecutiva de 0 a num_views_minus_l.

Desta maneira, quadros utilizados como quadros de referência podem ser decodificado antes de decodificar os quadros que sã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 10 uma unidade de acesso. Para cada índice de ordem de vista i, o view_id correspondente é sinalizado. A decodificação dos componentes de vista segue a ordem crescente dos índices de ordem de vista. Se todos as vistas forem apresentadas, em seguida, o conjunto de índices de ordem de 15 vista pode compreender um conjunto consecutivamente ordenado ajustado de zero a um menos o número total de vistas.

Para certos quadros em níveis iguais da hierarquia, ordem de decodificação pode não importar em 20 relação uns aos outros. Por exemplo, o quadro I de vista S0 em localização temporal TO é utilizado como um quadro de referência para o quadro P de vista S2 em localização temporal TO, que, por sua vez, é utilizado como um quadro de referência para o quadro P de vista S4 em localização 25 temporal TO. Consequentemente, o quadro I de vista S0 em localização temporal TO deve ser decodificado antes do quadro P de vista S2 em localização temporal TO, que deve ser decodificado antes do quadro P de vista S4 em localização temporal TO. Entretanto, entre vistas SI e S3, 30 uma ordem de decodificação não importa, porque vistas SI e S3 não confiam uma na outra para predição, mas, em vez disso, são preditos apenas a partir de vistas que são maiores na hierarquia de predição. Além do mais, vista SI pode ser decodificada antes de vista S4, desde que vista Sl seja decodificada depois de vistas SO e S2.

Desta maneira, uma ordenação hierárquica pode ser utilizada para descrever vistas de SO a S7. Deixe a notação 5 SA >SB significar que vista SA deve ser decodificada antes de vista SB. Usando esta notação, SO > S2 > S4 > S6 > S7 no exemplo da figura 7. Também, com respeito ao exemplo da figura 7, SO > Sl, S2 > Sl, S2 > S3, S4 > S3, S4 > S5 e S6 > S5. Qualquer ordem de decodificação para as vistas que não viole estes requisitos é possível. Consequentemente, muitas ordens de decodificação diferentes são possíveis, com apenas certas limitações. Duas ordens de decodificação exemplares são apresentados abaixo, embora deve ser entendido que muitas outras ordens de decodificação são possíveis. Em um exemplo, ilustrado na Tabela 9, abaixo, vistas são decodificadas o mais rápido possível. Tabela 9

O exemplo da Tabela 9 reconhece que vista Sl pode ser decodificada imediatamente depois de vistas SO e S2 20 forem decodificadas, vista S3 pode ser decodificada imediatamente depois de vistas S2 e S4 forem decodificadas, e vista S5 pode ser decodificada imediatamente após vistas S4 e S6 forem decodificadas.

A Tabela 10 abaixo apresenta outra ordem de 25 decodificação exemplar, na qual a ordem de decodificação é tal que qualquer vista que for utilizada como referência para outra vista é decodificada antes de vistas que não são utilizadas como referência para qualquer outro vista. Tabela 10

O exemplo da Tabela 10 reconhece que quadros de vistas Sl, S3, S5 e S7 não agem como quadros de referência para quadros de quaisquer outras vistas e, portanto, vistas 5 Sl, S3, S5 e S7 podem ser decodificadas após quadros daquelas vistas que são utilizadas como quadros de referência, isto é, vistas S0, S2, S4 e S6, no exemplo da figura 7. Em relação umas às outras, vistas Sl, S3, S5 e S7 podem ser decodificadas em qualquer ordem. 10 Consequentemente, no exemplo da Tab ela 10, vista S7 é decodificada antes de cada uma das vistas Sl, S3 e S5. Para ser claro, pode haver uma relação hierárquica entre quadros de cada vista, assim como as localizações temporais dos quadros de cada vista. Com 15 respeito ao exemplo da figura 7, quadros a localização temporal TO são intrapreditos ou intervistas preditas a partir de quadros de outras vistas em localização temporal TO. Semelhantemente, quadros em localização temporal T8 são intrapreditos ou intervistas preditas a partir de quadros 20 de outras vistas em localização temporal T8. Consequentemente, com respeito a uma hierarquia temporal, localizações temporais T0 e T8 estão no topo da hierarquia temporal.

Quadros em localização temporal T4, no exemplo da 25 figura 7, são menores na hierarquia temporal do que quadros de localizações temporais TO e T8, porque quadros de localização temporal T4 são codificados B com referência a quadros de localizações temporais TO e T8. Quadros em localizações temporais T2 e T6 são menores na hierarquia 30 temporal do que quadros em localização temporal T4. Finalmente, quadros em localizações temporais Tl, T3, T5 e T7 são menores na hierarquia temporal do que quadros de localizações temporais T2 e T6. Em MVC, um subconjunto de um fluxo de bits 5 completo pode ser extraído para formar um subfluxo de bits que ainda esteja em conformidade com MVC. Existem muitas subfluxos de bits possíveis que aplicações específicas possam requerer, com base, por exemplo, em um serviço fornecido por um servidor, a capacidade, suporte e 10 capacidades de decodificadores de um ou mais clientes, e/ou a preferência de um ou mais clientes. Por exemplo, um cliente pode requerer somente três vistas, e pode haver dois cenários. Em um exemplo, um cliente pode requerer experiência de visualização suave e pode preferir vistas 15 com valores de view_id SO, SI e S2, enquanto outro outro cliente pode requerer escalabilidade de vista e preferir vistas com valores de view_id SO, S2 e S4. Se, originalmente, os view_ids são ordenados com r espeito ao exemplo da Tabela 9, os valores de índice de ordem de vista 20 são {0, 1, 2} e {0, 1, 4} nesses dois exemplos, respectivamente. Note que ambos os subfluxos de bits podem ser decodificados como fluxos de bit MVC independentes e podem ser suportados simultaneamente.

Podem haver muitos subfluxos de bits MVC que são 25 decodificáveis por decodificadores MVC. Em teoria, qualquer combinação de vistas que satisfaça as duas seguintes propriedades podem ser decodificados por um decodificador MVC compatível com um certo perfil ou nível: (1) os componentes vista em cada unidade de acesso são ordenados 30 em uma ordem crescente de índice de ordem de vista, e (2) para cada vista na combinação, suas vistas dependentes também são incluídas na combinação.

A figura 8 é um fluxograma ilustrando um método exemplar para utilizar uma estrutura de dados que sinaliza características de um ponto de operação. Isto é, o método de figura 8 inclui construção de estruturas de dados para cada ponto de operação de um fluxo de bits de Sistemas MPEG-2 por um dispositivo de origem, por exemplo, dispositivo de origem 20 (figura 1). O método de figura 8 também inclui o uso de estruturas de dados recebidos para selecionar um ponto de operação para recuperar os dados de multimídia para decodificar e exibir por um dispositivo de destino, tais como dispositivo de destino 40 (figura 1). Inicialmente, no exemplo da figura 8, dispositivo de origem 20 determina pontos de operação para um programa (210). Por exemplo, dispositivo de origem 20 pode selecionar vários subconjuntos de vistas de um programa para criar vários pontos de operação que representam dispositivos clientes possuindo várias capacidades, por exemplo, capacidades de renderização e decodificação. Um administrador pode interagir com dispositivo de origem 20, por exemplo, para selecionar vistas e criar pontos de operação que representam dispositivos clientes que possuem diferentes capacidades de renderização e decodificação, ou diferentes pontos de operação poderiam ser criados automaticamente por dispositivo de origem 20.

Depois de determinar os pontos de operação para um programa, dispositivo de origem 20 pode gerar estruturas de dados para cada um dos pontos de operação em uma tabela de mapa de programa (212), por exemplo, quando o fluxo de bits for difundido como um fluxo de transporte de Sistemas MPEG-2. Alternativamente, o dispositivo de origem 20 pode gerar as estruturas de dados em um mapa de fluxo de programa quando o fluxo de bits for difundido como um fluxo de programa de Sistemas MPEG-2. Em qualquer caso, dispositivo de origem 2 0 pode gerar, para cada ponto de operação, uma estrutura de dados que representa características do ponto de operação correspondente. A estrutura de dados pode compreender um descritor de ponto de operação correspondente a um dos exemplos das figuras 4 a 6, por exemplo. Desta maneira, a estrutura de dados pode sinalizar características de renderização, características de decodif icação e uma taxa de bits para o ponto de operação correspondente. Dispositivo de origem 20 pode, então, emitir as estruturas de dados (214), por exemplo, dentro da PMT no exemplo da figura 8, para um dispositivo cliente, por exemplo, dispositivo de destino 40 (figura 1). Desta maneira, dispositivo de origem 20 pode emitir as estruturas de dados como parte do fluxo de bits. Dispositivo de origem 20 pode emitir o fluxo de bits na forma de uma difusão, unidifusão, multidifusão, difusão qualquer ou outro protocolo de comunicação através de uma rede, por exemplo, através de uma rede sem fio ou com fio, ou difusão através de frequências de televisão, por exemplo, de acordo com sinais em conformidade com padrões de Comitê de Sistemas de Televisão Avançados (ATSC) ou padrões de Comitê de Sistema de Televisão Nacional (NTSC). Alternativamente, dispositivo de origem 2 0 pode codificar o fluxo de bits em um meio de armazenamento legível por computador, tal como um DVD-ROM, disco Blu-ray, drive flash, disco magnético ou outro meio de armazenamento, no caso em que dispositivo de origem 20 pode formar um PSM que inclui as estruturas de dados para os pontos de operação e codificar o PSM no meio de armazenamento legível por computador. Dispositivo de destino 40 pode finalmente receber a PMT (ou o PSM) a partir de dispositivo de origem 20 (216). Dispositivo de destino 40 pode, então, selecionar um dos pontos de operação com base em características dos pontos de operação sinalizados pelas estruturas de dados incluídas na PMT ou no PSM (218). Em geral, dispositivo de destino 40 pode selecionar um ponto de operação para a qual 5 dispositivo de destino 40 satisfaça as capacidades de renderização e decodificação sinalizadas pela estrutura de dados correspondente. Por exemplo, dispositivo de destino 40 pode determinar se saída de vídeo 44 é capaz de renderizar um número de vistas indicado pela estrutura de 10 dados como o número de vistas a ser exibidas, a uma taxa de quadros em conformidade com o valor das capacidades de renderização sinalizadas pela estrutura de dados para o ponto de operação. Da mesma forma, dispositivo de destino 40 pode determinar se decodificador de vídeo 48 é capaz de 15 decodificar um número de vistas a ser decodificadas para o ponto de operação, como sinalizado pela estrutura de dados de valor de capacidade de decodificação do ponto de operação. Além do mais, em alguns exemplos, dispositivo de destino 40 pode utilizar a taxa de bits sinalizada na 20 estrutura de dados para selecionar um ponto de operação que é adequado para um meio de transporte, por exemplo, com base em limitações de largura de banda do meio de transporte a partir do qual dispositivo de destino 40 recebe o fluxo de bits. 25 Quando dispositivo de destino 40 determina que dispositivo de destino 40 é capaz de renderizar e decodificar mais de um ponto de operação, dispositivo de destino 40 pode selecionar um ponto de operação de qualidade mais alta para decodificação e renderização. Por 30 exemplo, dispositivo de destino 40 pode selecionar um ponto de operação possuindo o número mais alto de vistas, o número de taxa de bits mais alto, a taxa de quadro mais alta ou outras indicações de qualidade para um ponto de operação para determinar qual ponto de operação selecionar.

Depois de selecionar um ponto de operação, dispositivo de destino 40 pode recuperar dados para o ponto de operação a partir do fluxo de bits (220). Isto é, dispositivo de destino 40 pode extrair dados para cada uma das vistas correspondentes ao ponto de operação a partir do programa incluído no fluxo de bits. Em alguns exemplos, dispositivo de destino 40 seleciona dados a partir de um ou mais subfluxos de bits do fluxo de bits para extrair dados para o ponto de operação. Depois de extrair os dados, dispositivo de destino pode decodificar e exibir os dados para o ponto de operação selecionado (222). Decodificador de vídeo 48 pode decodificar cada uma das vistas que devem ser decodificadas para o ponto de operação, enquanto saída de vídeo 44 pode exibir cada um. das vistas que devem ser exibidas para o ponto de operação. As vistas exibidas podem não ser necessariamente as vistas que são decodificadas, como descrito acima.

Em um ou mais exemplos, as funções descritas podem ser implementadas em hardware, software, firmware ou qualquer combinação destes. Se implementadas em software, as funções podem ser armazenadas ou transmitidas através de uma ou mais instruções ou código em um meio legível por computador. Meios legíveis por computador podem incluir meios de armazenamento legíveis por computador, tais como meios de armazenamento de dados ou meios de comunicação, incluindo qualquer meio que facilite transferir de um programa de computador a partir de um lugar para outro. Meios de armazenamento de dados podem ser quaisquer meios disponíveis que possam ser acessados por um ou mais computadores ou um ou mais processadores para recuperar instruções, código e/ou estruturas de dados para implementação das técnicas descritas nesta revelação. Por meio de exemplo, e não limitação, tais meios de armazenamento legíveis por computador podem compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco ótico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, memória flash ou qualquer outro meio que possa ser utilizado para armazenar código do programa desejado na forma de estruturas de dados ou instruções e que possam ser acessados por um computador. Também, qualquer conexão é apropriadamente denominada de um meio legível por computador. Por exemplo, se instruções são transmitidas a partir de um site da rede, servidor ou outra fonte remota utilizando um cabo coaxial, cabo de fibra óptica, par trançado, linha de assinante digital (DSL) ou tecnologias sem fio, tais como infravermelho, rádio e micro-ondas, então, o cabo coaxial, o cabo de fibra óptica, o par trançado, a DSL ou as tecnologias sem fio, tais como infravermelho, rádio e micro-ondas, são incluídas na definição de meio. Deve ser entendido, entretanto, que um meio de armazenamento legível por computador e um meio de armazenamento de dados não incluem conexões, ondas portadoras, sinais ou outros meios transitórios. Disco (disk) e disco (disc), como utilizado aqui, incluem disco compacto (CD), disco laser, disco óptico, disco versátil digital (DVD), disquete e disco blu-ray, onde discos (disks) normalmente reproduzem dados magneticamente, enquanto que discos (discs) reproduzem dados opticamente com lasers. Combinações dos anteriores também devem ser incluídos no escopo de meios legíveis por computador. Instruções podem ser executadas por um ou mais processadores, tais como um ou mais processadores de sinal digital (DSPs), microprocessadores de uso geral, circuitos integrados de aplicação específica (ASICs), arranjos lógicos programáveis em campo (FPGAs) ou outros conjuntos de circuitos lógicos discretos ou integrados equivalentes. Consequentemente, o termo "processador", como utilizado aqui pode se referir a qualquer uma das estruturas 5 anteriores ou a quaisquer outras estruturas adequadas para implementação das técnicas descritas aqui. Em adição, em alguns aspectos, a funcionalidade descrita aqui pode ser fornecida dentro de hardware dedicado e/ou módulos de software configurados para codificação e decodificação ou 10 incorporado em um codec combinado. Também, as técnicas podem ser completamente implementadas em um ou mais circuitos ou elementos de lógica.

As técnicas desta revelação podem ser implementadas em uma ampla variedade de dispositivos ou 15 aparelhos, incluindo um fone sem fio, um circuito integrado (IC) ou um conjunto de ICs (por exemplo, um conjunto de chips). Vários componentes, módulos ou unidades são descritos nesta revelação para enfatizar aspectos funcionais de dispositivos configurados para realizar as 20 técnicas reveladas, mas que não necessariamente requerem realização por diferentes unidades de hardware. Em vez disso, como descrito acima, várias unidades podem ser combinadas em uma unidade de hardware de codec ou fornecidas por uma coleção de unidades de hardware 25 interoperativas, incluindo um ou mais processadores, como descrito acima, em conjunto com firmware e/ou software adequados. Vários exemplos foram descritos. Estes e outros exemplos estão dentro do escopo das reivindicações a 30 seguir.

Claims

1. Método caracterizadopelo fato de que compreende: construir, com um dispositivo de origem, uma pluralidade de descritores de ponto de operação de codificação de vídeo multivista (MVC) (114, 140) cada um correspondendo a um ponto de operação MVC, em que cada descritor de ponto de operação MVC é inserido nos laços de descritores de Tabela de Mapa de Programa (PMT) ou Mapa de Fluxo de Programa (PSM) de um fluxo de bits de padrão de Sistema MPEG-2 (Grupo de Especialistas em Imagens em Movimento), em que cada descritor de ponto de operação MVC (114, 140) sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC correspondente, e um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC correspondente, em que o valor capacidade de renderização descreve pelo menos um número de vistas direcionadas para renderização (150) para o ponto de operação MVC correspondente, uma taxa de quadros para dados de vídeo (149) do ponto de operação MVC correspondente, e um valor de identificador temporal (158) para o ponto de operação MVC correspondente; em que o valor de capacidade de decodificação descreve pelo menos um número de vistas a serem decodificadas (152) para o ponto de operação MVC correspondente, um valor de nível (148) correspondente ao ponto de operação MVC, e um valor de perfil (146) correspondente ao ponto de operação MVC; e emitir o fluxo de bits compreendendo a pluralidade de descritores de ponto de operação MVC (114) 140).

2. Método, de acordo com a reivindicação 1, caracterizadopelo fato de que construir cada descritor de ponto de operação MVC compreende construir o descritor de ponto de operação MVC para fazer com que um ou mais dispositivos de exibição bidimensionais e dispositivos de exibição tridimensionais adaptem o fluxo de bits para o um ou mais dispositivos de exibição bidimensionais e dispositivos de exibição tridimensionais e para acomodar mídia de transporte de várias larguras de banda para o um ou mais dispositivos de exibição bidimensionais e dispositivos de exibição tridimensionais.

3. Método, de acordo com a reivindicação 1, caracterizadopelo fato de que construir a pluralidade de descritores de ponto de operação MVC compreende construir a pluralidade de descritores de ponto de operação MVC para sinalizar um valor de taxa de bits que descreve uma taxa de bits do ponto de operação MVC correspondente, em que o valor de taxa de bits descreve uma dentre uma taxa de bits média para o ponto de operação MVC correspondente e a taxa de bits máxima para o ponto de operação MVC correspondente.

4. Método, de acordo com a reivindicação 1, caracterizadopelo fato de que construir cada descritor de ponto de operação MVC compreende: incluir um valor de taxa de quadros no descritor de ponto de operação que descreve uma taxa de quadros máxima para dados de vídeo incluídos em um número de vistas para o ponto de operação MVC; incluir valores de identificador de vista no descritor de ponto de operação para um número de vistas direcionadas para renderização do ponto de operação MVC, em que cada um dos valores de identificador de vista corresponde a uma das vistas direcionadas para renderização; incluir valores de identificador de vista no descritor de ponto de operação para um número de vistas a serem decodificadas para o ponto de operação MVC, em que cada um dos valores de identificador de vista corresponde a uma das vistas a ser decodificada; e incluir um valor identificador temporal no descritor de ponto de operação que corresponde a uma taxa de quadros para um fluxo de vídeo montado a partir dos dados de vídeo das vistas para o ponto de operação MVC.

5. Aparelho, caracterizadopelo fato de que compreende: meios para construir uma pluralidade de descritores de ponto de operação de codificação de vídeo multivista (MVC) cada um correspondendo a um ponto de operação MVC, em que os meios inserem cada descritor de ponto de operação MVC é inserido nos laços de descritor de Tabela de Mapa de Programa (PMT) ou Mapa de Fluxo de Programa (PSM) de um fluxo de bits de padrão de Sistema MPEG-2 (Grupo de Especialistas em Imagens em Movimento), em que cada descritor de ponto de operação MVC sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC correspondente, e um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC correspondente, em que o valor capacidade de renderização descreve pelo menos um número de vistas direcionadas para renderização para o ponto de operação MVC correspondente, uma taxa de quadros para dados de vídeo do ponto de operação MVC correspondente, e um valor de identificador temporal para o ponto de operação MVC correspondente; em que o valor de capacidade de decodificação descreve pelo menos um número de vistas a serem decodificadas para o ponto de operação MVC correspondente, um valor de nível correspondente ao ponto de operação MVC, e um valor de perfil correspondente ao ponto de operação MVC; e meios para emitir o fluxo de bits compreendendo a pluralidade de descritores de ponto de operação MVC.

6. Aparelho, de acordo com a reivindicação 5, caracterizadopelo fato de que os meios para construir cada descritor MVC compreendem adicionalmente: meios para incluir um valor de taxa de quadros no descritor de ponto de operação que descreve uma taxa de quadros máxima para dados de vídeo incluídos em um número de vistas para o ponto de operação MVC; meios para incluir valores de identificador de vista no descritor de ponto de operação para um número de vistas direcionadas para renderização do ponto de operação MVC, em que cada um dos valores de identificador de vista corresponde a uma das vistas direcionada para renderização; meios para incluir valores de identificador de vista no descritor de ponto de operação para um número de vistas a serem decodificadas para o ponto de operação MVC, em que cada um dos valores de identificador de vista corresponde a uma das vistas a ser decodificada; e meios para incluir um valor identificador temporal no descritor de ponto de operação que corresponde a uma taxa de quadros para um fluxo de vídeo montado a partir dos dados de vídeo das vistas para o ponto de operação MVC.

7. Aparelho, de acordo com a reivindicação 5, caracterizadopelo fato de que um multiplexador constrói cada descritor de ponto de operação MVC, e em que cada ponto de operação MVC corresponde a um subconjunto de um número de vistas do fluxo de bits, e em que, para construir cada descritor de ponto de operação MVC, o multiplexador inclui um valor de taxa de quadros no descritor de ponto de operação que descreve uma taxa de quadros máxima para dados de vídeo incluídos nas vistas para o ponto de operação MVC correspondente, inclui valores de identificador de vista no descritor de ponto de operação para vistas direcionadas para renderização do ponto de operação MVC correspondente, em que cada um dos valores de identificador de vista corresponde a uma das vistas direcionadas para renderização, inclui valores de identificador de vista no descritor de ponto de operação para vistas a serem decodificadas para o ponto de operação MVC correspondente, em que cada um dos valores de identificador de vista corresponde a uma das vistas a ser decodificada, e inclui um valor de identificador temporal no descritor de ponto de operação que corresponde a uma taxa de quadros para um fluxo de vídeo montado a partir de dados de vídeo das vistas para o ponto de operação MVC correspondente.

8. Método caracterizadopelo fato de que compreende: receber, com um dispositivo de destino, em laços de descritores de uma Tabela de Mapa de Programa (PMT) ou Mapa de Fluxo de Programa (PSM) de um fluxo de bits de padrão de Sistema MPEG-2 (Grupo de Especialistas em Imagens em Movimento), uma pluralidade de descritores de codificação de vídeo multivista (MVC) cada correspondente a um ponto de operação MVC, em que cada descritor de ponto de operação MVC sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, em que o valor capacidade de renderização descreve pelo menos um número de vistas direcionadas para renderização para o ponto de operação MVC correspondente, uma taxa de quadros para dados de vídeo do ponto de operação MVC correspondente, e um valor de identificador temporal para o ponto de operação MVC correspondente, em que o valor de capacidade de decodificação descreve pelo menos um número de vistas a serem decodificadas para o ponto de operação MVC correspondente, um valor de nível correspondente ao ponto de operação MVC, e um valor de perfil correspondente ao ponto de operação MVC; determinar para cada descritor de ponto de operação MVC se um decodificador de vídeo do dispositivo de destino é capaz de decodificar o número de vistas correspondentes ao ponto de operação MVC com base na capacidade de decodificação sinalizada pelo descritor de ponto de operação MVC; determinar para cada descritor de ponto de operação MVC se o dispositivo de destino é capaz de renderizar as vistas correspondentes ao ponto de operação MVC com base na capacidade de renderização sinalizada pelo descritor de ponto de operação MVC; selecionar um ponto de operação com base no descritor de ponto de operação MVC correspondente, em que selecionar compreende determinar que o decodificador de vídeo é capaz de decodificar e renderizar vistas correspondentes ao ponto de operação selecionado; e enviar as vistas correspondentes ao ponto de operação MVC selecionado para o decodificador de vídeo do dispositivo de destino.

9. Método, de acordo com a reivindicação 8, caracterizadopelo fato de que cada descritor de ponto de operação MVC compreende um valor de taxa de quadros que descreve uma taxa de quadros máxima para dados de vídeo incluídos nas vistas para o ponto de operação MVC, valores de identificador de vistas para um número de vistas direcionadas para renderizar o ponto de operação MVC, em que cada um dos valores de identificador de vista corresponde a uma das vistas direcionadas para renderização, valores de identificador de vista para um número de vistas a ser decodificado para o ponto de operação MVC, em que cada um dos valores de identificador de vista corresponde a uma das vistas a ser decodificada, e um valor de identificador temporal que corresponde a uma taxa de quadros para um fluxo de vídeo montado a partir dos dados de vídeo das vistas para o ponto de operação MVC.

10. Método, de acordo com a reivindicação 9, caracterizadopelo fato de que determinar se o decodificador de vídeo é capaz de decodificar as vistas compreende determinar se o decodificador de vídeo é capaz de decodificar um número de vistas equivalente ao número de vistas a serem decodificadas na taxa de quadros indicada pelo valor de taxa de quadros.

11. Método, de acordo com a reivindicação 8, caracterizadopelo fato de que o dispositivo de destino é configurado com um número suportado de vistas que descreve um número suportado de vistas que podem ser renderizadas pelo dispositivo de destino e um valor de taxa de quadros que descreve uma taxa de quadros de dados de vídeo que podem ser exibidos pelo dispositivo de destino, em que determinar se o dispositivo de destino é capaz de renderizar as vistas correspondentes ao ponto de operação MVC compreende: comparar um número de vistas correspondentes ao ponto de operação MVC para o número de vistas suportado; e comparar uma taxa de quadros das vistas correspondentes ao ponto de operação MVC para o valor de taxa de quadros, em que enviar as vistas correspondentes ao ponto de operação MVC para o decodificador de vídeo compreende enviar as vistas correspondentes ao ponto de operação MVC para o decodificador de vídeo quando o número de vistas correspondentes ao ponto de operação MVC for menor ou igual ao número suportado de vistas e quando a taxa de quadros das vistas correspondentes ao ponto de operação MVC for menor ou igual ao valor de taxa de quadros.

12. Método, de acordo com a reivindicação 11, caracterizadopelo fato de que o número suportado de vistas é inversamente proporcional ao valor de taxa de quadros.

13. Aparelho caracterizadopelo fato de que compreende: meios para receber uma pluralidade de descritores de codificação de vídeo multivista (MVC) em laços de descritores de uma Tabela de Mapa de Programa (PMT) ou Mapa de Fluxo de Programa (PSM) de um fluxo de bits de padrão de Sistema MPEG-2 (Grupo de Especialistas em Imagens em Movimento), cada descritor de ponto de operação MVC correspondendo a um ponto de operação MVC, em que cada descritor de ponto de operação MVC sinaliza um valor de capacidade de renderização que descreve uma capacidade de renderização a ser satisfeita por um dispositivo de recepção para utilizar o ponto de operação MVC, e um valor de capacidade de decodificação que descreve uma capacidade de decodificação a ser satisfeita pelo dispositivo de recepção para utilizar o ponto de operação MVC, em que o valor capacidade de renderização descreve pelo menos um número de vistas direcionadas para renderização para o ponto de operação MVC correspondente, uma taxa de quadros para dados de vídeo do ponto de operação MVC correspondente, e um valor de identificador temporal para o ponto de operação MVC correspondente, em que o valor de capacidade de decodificação descreve pelo menos um número de vistas a serem decodificadas para o ponto de operação MVC correspondente, um valor de nível correspondente ao ponto de operação MVC, e um valor de perfil correspondente ao ponto de operação MVC; meios para determinar para cada descritor de ponto de operação MVC se um decodificador de vídeo do aparelho é capaz de decodificar um número de vistas correspondentes ao ponto de operação MVC com base na capacidade de decodificação sinalizada pelo descritor de ponto de operação MVC; meios para determinar para cada descritor de ponto de operação MVC se o aparelho é capaz de renderizar as vistas correspondentes ao ponto de operação MVC com base na capacidade de renderização sinalizada pelo descritor de ponto de operação MVC; meios para selecionar um ponto de operação com base no descritor de ponto de operação MVC correspondente, em que selecionar compreende determinar que o decodificador de vídeo é capaz de decodificar e renderizar vistas correspondentes ao ponto de operação selecionado; e meios para enviar as vistas correspondentes ao ponto de operação MVC selecionado para o decodificador de vídeo do aparelho.

14. Memória, caracterizadapelo fato de que compreende instruções armazenadas na mesma, as instruções sendo executadas por um computador para realizar o método conforme definido em qualquer uma das reivindicações 1 a 4 5 ou 8 a 12.