BR112017007298B1 - Método e dispositivo para processamento de um fluxo de bits incluindo dados de vídeo de codificação de vídeo de alta eficiência, hevc, e memória legível por computador - Google Patents

Abstract

PONTO DE OPERAÇÃO PARA TRANSPORTE DE FLUXO DE BITS HEVC EM CAMADAS. Trata-se de um dispositivo para processamento de um fluxo de bits que inclui dados de vídeo, tal como um multiplexador, que extrai um descritor a partir do fluxo de bits, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separados do descritor, de modo que cada ponto de operação inclua uma ou mais camadas de dados de vídeo, e em que o descritor inclui um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que associam cada uma das camadas de cada um dos pontos de operação a uma das estruturas de PTL correspondentes, extraia dados de vídeo para um dos pontos de operação a partir do fluxo de bits com base pelo menos em parte nas estruturas PTL às quais as camadas de um dos pontos de operação correspondem, e forneça os dados de vídeo extraído a um decodificador de vídeo.

Description

[0001] O presente pedido reivindica o benefício do Pedido Provisório no U.S.61/062.681, depositado em 10 de outubro de 2014 e do Pedido Provisório no U.S.61/064.428, depositado em 15 de outubro de 2014,estando todos os conteúdos de cada um desses se encontram incorporados a título de referência no presente documento.

CAMPO DA TÉCNICA

[0002] A presente revelação refere-se à codificação de vídeo e, mais particularmente, ao transporte de dados de vídeo codificados.

FUNDAMENTOS

[0003] As capacidades de vídeo digital podem ser incorporadas em uma ampla gama de dispositivos, incluindo televisões digitais, sistemas de difusão avançar digital, sistemas de difusão sem fio, assistentes digitais pessoais (PDAs), computadores do tipo laptop ou desktop, computadores do tipo tablet, leitores de e-book, câmeras digitais, dispositivos de gravação digitais, reprodutores de mídia digitais, dispositivos de vídeo jogo, consoles de vídeo jogo, celular ou telefones de rádio-satélite, conhecidos como “smartphones”, dispositivos de teleconferência por vídeo, dispositivos de difusão por vídeo e similares. Os dispositivos de vídeo digitais implantam técnicas de codificação de vídeo, tais como as descritas nos padrões definidos por MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Parte 10, Codificação de Vídeo Avançada (AVC), Codificação de Vídeo de Alta Eficiência (HEVC) e extensões de tais padrões. Os dispositivos de vídeo podem transmitir, receber, encriptar, decodificar e/ou armazenar informações de vídeo digital de maneira mais eficiente implantando-se tais técnicas de codificação de vídeo.

[0004] As técnicas de codificação de vídeo incluem previsão espacial (intraimagem) e/ou previsão temporal (interimagem) para reduzir ou remover a redundância inerente em sequências de vídeo. Para a codificação de vídeo com base em bloco, uma fatia de vídeo (por exemplo, um quadro de vídeo ou uma porção de um quadro de vídeo) pode ser particionada em blocos de vídeo, que também podem ser denominados de blocos em árvore, unidades de codificação (CUs) e/ou nós de codificação. Os blocos de vídeo em uma fatia intracodificada (I) de uma imagem são criptados com o uso de uma previsão espacial em relação às amostras de referência em blocos vizinhos na mesma imagem. Os blocos de vídeo em uma fatia intercodificada (P ou B) de uma imagem podem usar previsão espacial em relação às amostras de referência em blocos vizinhos na mesma previsão de imagem ou temporal em relação às amostras de referência em outras imagens de referência. As imagens podem ser referidas como quadros e as imagens de referência podem ser referidas como quadros de referência.

[0005] A previsão espacial ou temporal resulta em um bloco previsto para um bloco a ser codificado. Os dados residuais representam diferenças de pixel entre o bloco original a ser codificado e o bloco previsto. Um bloco intercodificado é criptado de acordo com um vetor de movimento que aponta para um bloco de amostras de referência que formam o bloco preditivo e os dados residuais indicam a diferença entre o bloco codificado e o bloco preditivo. Um bloco intracodificado é encriptado de acordo com um modo de intracodificação e os dados residuais. Para compressão adicional, os dados residuais podem ser transformados do domínio de pixel para um domínio de transformada, resultando em coeficientes residuais que podem, em seguida, ser quantizados. O coeficiente de transformada quantizado, disposto inicialmente em uma matriz bidimensional e pode ter sua varredura realizada a fim de produzir um vetor monodimensional de coeficiente de transformada, e a codificação por entropia pode ser aplicada para conseguir ainda mais compressão.

SUMÁRIO

[0006] Em geral, esta revelação descreve técnicas para transportar dados de vídeo codificados de acordo com, por exemplo, sistemas de MPEG-2 (Grupo de Especialistas de Imagens em Movimento). O transporte de dados de vídeo codificados também pode ser denominado como condução de dados de vídeo codificados. Por exemplo, a revelação descreve técnicas exemplificadoras, que podem ser aprimoramentos, do descritor de Fluxo de Transporte MPEG-2 (TS) que é usado para a sinalização de informações de dependência entre camadas de fluxos de bits de HEVC em camadas (Codificação de Vídeo de Alta Eficiência). As técnicas desta revelação podem ser usadas para transporte de dados de vídeo codificados para uma extensão de um padrão de codificação de vídeo, por exemplo, uma extensão do padrão de HEVC. Tais extensões podem incluir extensões em múltiplas vistas (por exemplo, MV-HEVC), extensões escaláveis (por exemplo, SHVC), e extensões tridimensionais (por exemplo, 3D-HEVC).

[0007] Em um exemplo, um método de processamento de um fluxo de bits incluindo dados de vídeo inclui extrair um descritor do fluxo de bits, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separado do descritor, de modo que cada ponto de operação inclua uma ou mais camadas de dados de vídeo, e em que o descritor inclua um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de PTL correspondentes, extraindo dados de vídeo para um dos pontos de operação do fluxo de bits com base pelo menos em parte nas estruturas de PTL às quais as camadas de um ou mais pontos de operação correspondem, e fornecendo os dados de vídeo extraídos a um decodificador de vídeo.

[0008] Em outro exemplo, um dispositivo de processamento de um fluxo de bits incluindo dados de vídeo inclui uma memória para armazenar dados extraídos do fluxo de bits e uma ou mais unidades de processamento configuradas para extrair um descritor do fluxo de bits, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separado do descritor, de modo que cada ponto de operação inclua uma ou mais camadas de dados de vídeo, e em que o descritor inclua um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de PTL correspondentes, extrair dados de vídeo para um dos pontos de operação do fluxo de bits com base pelo menos em parte nas estruturas de PTL às quais as camadas de um ou mais pontos de operação correspondem, e fornecer os dados de vídeo extraídos a um decodificador de vídeo.

[0009] Em outro exemplo, um dispositivo de processamento de dados de vídeo inclui meios para extrair um descritor do fluxo de bits, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separado do descritor, de modo que cada ponto de operação inclua uma ou mais camadas de dados de vídeo, e em que o descritor inclua um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de PTL correspondentes, meios para extrair dados de vídeo para um dos pontos de operação do fluxo de bits com base pelo menos em parte nas estruturas de PTL às quais as camadas de um ou mais pontos de operação correspondem, e meios para fornecer os dados de vídeo extraídos a um decodificador de vídeo.

[0010] Em outro exemplo, um meio de armazenamento legível por computador tendo instruções armazenadas no mesmo que, quando executadas, fazem com que um processador extraia um descritor de um fluxo de bits que inclui dados de vídeo, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separado do descritor, de modo que cada ponto de operação inclua uma ou mais camadas de dados de vídeo, e em que o descritor inclua um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de PTL correspondentes, extraia dados de vídeo para um dos pontos de operação do fluxo de bits com base pelo menos em parte nas estruturas de PTL às quais as camadas de um ou mais pontos de operação correspondem, e forneçam os dados de vídeo extraídos a um decodificador de vídeo.

[0011] Os detalhes de um ou mais exemplos são apresentados nos desenhos anexos e na descrição abaixo. Outros atributos, objetivos e vantagens serão evidentes a partir da descrição e dos desenhos e a partir das reivindicações.

BREVE DESCRIÇÃO DOS DESENHOS

[0012] A Figura 1 é um diagrama de blocos que ilustra um sistema de criptação e decodificação de vídeo exemplificador que pode utilizar técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo.

[0013] A Figura 2 é um diagrama de blocos que ilustra um exemplo de um criptador de vídeo que pode implantar técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo.

[0014] A Figura 3 é um diagrama de blocos que ilustra um exemplo de um decodificador de vídeo que pode implantar técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo.

[0015] A Figura 4 é um diagrama de blocos que ilustra um sistema exemplificador no qual um dispositivo de fonte de áudio/vídeo (A/V) transporta dados de áudio e vídeo a um dispositivo de destino de A/V.

[0016] A Figura 5 é um diagrama conceitual que ilustra um exemplo de dependência entre fluxos elementares.

[0017] A Figura 6 é outro diagrama conceitual que ilustra um exemplo de dependência entre fluxos elementares.

[0018] A Figura 7 é outro diagrama conceitual que ilustra um exemplo de dependência entre fluxos elementares.

[0019] A Figura 8 é um diagrama conceitual que ilustra um exemplo de múltiplas camadas de dados de vídeo.

[0020] A Figura 9 é um fluxograma que ilustra um método exemplificador de acordo com as técnicas desta revelação.

DESCRIÇÃO DETALHADA

[0021] Em geral, esta revelação descreve técnicas relacionadas aos dados de nível de Sistemas de Grupo de Especialistas de Imagem em Movimento (MPEG)-2 para dados de mídia. Sistemas de MPEG-2 descreve geralmente como dois ou mais fluxos de dados são multiplexados entre si para formar um único fluxo de dados. Esta revelação descreve técnicas relacionadas a dados de sistemas de MPEG- 2 para dados de vídeo de múltiplas camadas. Mais particularmente, esta revelação descreve um descritor de Fluxo de Transporte MPEG-2 (TS) que pode ser usado para sinalizar as informações de dependência entre as camadas de fluxos de bits de HEVC em camadas (por exemplo, descrevem a dependência (ou relação) entre as camadas de fluxos de bits de HEVC em camadas, que podem consistir em aprimoramentos em relação a algumas técnicas existentes). O documento padrão finalizado está publicado como ITU-T H.265, Série H: Sistemas Audiovisuais e Multimídia, Infraestrutura de serviços audiovisuais - Codificação de vídeo em movimento, Codificação de vídeo de alta eficiência, Setor de Padronização de Telecomunicações de União Internacional de Telecomunicações (ITU), abril de 2015.

[0022] As técnicas desta revelação são geralmente direcionadas à condução (por exemplo, transporte) de dados de vídeo codificados de acordo com uma extensão a um padrão de codificação de vídeo (por exemplo, uma extensão ao padrão de Codificação de Vídeo de Alta Eficiência (HEVC), também denominada como ITU-T H.265). Tais extensões podem incluir extensões de múltiplas vistas, tridimensionais e/ou escaláveis. Desse modo, as técnicas desta revelação podem ser aplicadas ao HEVC de múltiplas vistas (MV-HEVC), HEVC tridimensional (3D-HEVC) e HEVC escalonável (SHVC).

[0023] Dados de vídeo de múltiplas camadas, por exemplo, dados de vídeo de múltiplas vistas e/ou dados de vídeo com múltiplas camadas escaláveis, podem incluir pontos de operação designados. Em geral, um ponto de operação descreve um subconjunto de camadas (por exemplo, vistas) de um conjunto completo de camadas de dados de vídeo de múltiplas camadas. O ponto de operação também pode identificar camadas de saída alvo, ou seja, camadas para os quais dados devem ser emitidos. Em alguns casos, dados de uma camada podem ser incluídos em um ponto de operação somente para uso como uma camada de referência e, portanto, tal camada não seria considerada uma camada de saída alvo.

[0024] Um tipo de dimensão escalonável é a dimensão temporal. Por exemplo, em escalabilidade temporal, um conjunto de dados de vídeo pode suportar várias taxas de quadro ou taxas de reprodução, por exemplo, 15 quadros por segundo (FPS), 30 FPS, 60 FPS e 120 FPS. Um dado nível temporal pode incluir todas as imagens nesse nível ou níveis inferiores. Por exemplo, continuando o exemplo anterior, um nível temporal de 0 pode corresponder a 15 FPS, um nível temporal de 1 pode incluir imagens de nível temporal 0 assim como imagens em nível temporal para suportar 30 FPS, um nível temporal de 2 pode incluir imagens de níveis temporais 0 e 1 assim como imagens em nível temporal 2 para suportar 60 FPS e assim por diante. Um temporal_identifier, ou TemporallD, pode ser sinalizado como representativo do nível temporal ao qual uma imagem particular pertence.

[0025] Um dispositivo de destino pode usar descritores de ponto de operação incluídos em um fluxo de bits para selecionar um dos pontos de operação a ser decodificados e apresentados por último (por exemplo, exibidos) a um usuário. Em vez de passar dados para todas as vistas a um decodificador de vídeo mediante recebimento, o dispositivo de destino pode enviar somente as vistas de um ponto de operação selecionado ao decodificador de vídeo. Dessa maneira, o dispositivo de destino pode descartar dados para vistas que não serão decodificados. Adicional ou alternativamente, um dispositivo de rede intermediário pode descartar dados para visualizações que não correspondem a um ponto de operação solicitado, por exemplo, para utilizar melhor a largura de banda. O dispositivo de destino pode selecionar um ponto de operação com base na maior qualidade suportado em um dos pontos de operação para um fluxo de bits e/ou com base em uma quantidade disponível de largura de banda de rede.

[0026] Dados de vídeo também podem ser descritos por perfis, camadas e faixas. Um “perfil” é um subconjunto de uma sintaxe de fluxo de bits inteira que é especificada por um padrão de codificação de vídeo aplicável. Um “nível” corresponde às limitações do consumo de recurso de decodificador, tais como, por exemplo, memória e decodificação e computação, que são relacionadas à resolução das imagens, taxa de bits e taxa de processamento de bloco.

[0027] Os padrões de codificação de vídeo incluem ITU-T H.261, ISO/IEC MPEG- -1 Visual, ITU-T H.262 ou ISO/IEC MPEG-2 Visual, ITU-T H.263, ISO/IEC MPEG-4 Visual e ITU-T H.264 (também chamado de ISO/IEC MPEG-4 AVC), incluindo suas extensões de Codificação de Vídeo Escalonável (SVC) e de Codificação de Vídeo de Múltiplas Vistas (MVC).

[0028] Recentemente, o design de um novo padrão de codificação de vídeo, denominado Codificação de Vídeo de Alta Eficiência (HEVC), extensão multivista para HEVC, denominado MV-HEVC, e extensão escalonável para HEVC, denominada SHVC, foi finalizado pela Equipe de Colaboração em Codificação de Vídeo (JCT-VC) de Grupo de Especialistas em Codificação de Vídeo ITU-T (VCEG) e Grupo de Especialistas de Imagem em Movimento ISO/IEC (MPEG).

[0029] A última especificação de rascunho de HEVC intitulada “Draft high efficiency video coding (HEVC) version 2, combined format range extensions (RExt), scalability (SHVC), and multi-view (MV-HEVC) extensions” for JCT-VC of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 18th Meeting: Sapporo, JP, 30 de junho a 9 de julho de 2014 (JCTVC-R1013_v6), está disponível a partir de phenix.int-evry.fr/jct/doc_end_user/documents/18_Sapporo/wg 11 /JCT VC-R1013 -v6.zip .

[0030] A especificação de rascunho de MV-HEVC mais recente intitulada “MV-HECV Draft Text 9” for Joint Collaborative Team on 3D Video Coding Extensions of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 9th Meeting:Sapporo, JP, 3 a 9 de julho de 2014 (JCT3V-I1002- v7), está disponível a partir de phenix.int-evry .fr/j ct3 v/ doc_end_user/ documents/9_Sapporo/wg 11 /JCT3 V-11002- v7.zip.

[0031] A especificação de rascunho de SHVC intitulada “High efficiency video coding (HEVC) scalable extension Draft 7” for JCT-VC of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 18th Meeting: Sapporo, JP, 30 de junho a 9 de julho de 2014 (JCTVC-R1008v7) está disponível a partir de phenix.int-evry.fr/jct/doc_end_user/documents/18_Sapporo/wgl l/JCTVC- R1008-v7.zip.

[0032] Tecnologias de Sistemas de MPEG-2 (Grupo de Especialistas de Imagens em Movimento) podem ser empregadas para transportar dados de vídeo. Sistemas de MPEG-2 são algumas vezes denominados como MPEG-2 TS. A especificação de MPEG-2 TS mais recente é a recomendação de ITU-T H.222.0, versão junho de 2012, disponível a partir de www.itu.int/rec/T-REC-H.222.0-201206-I/en, com taxa. Essa especificação fornece suporte para a AVC e extensões de AVC.

[0033] A modificação de MPEG-2 TS para HEVC foi desenvolvida. O último documento é “Text of ISO/IEC 13818-1: 2013/Final Draft Amendment 3 - Transport of HEVC video over MPEG-2 Systems”, no documento de MPEG wl3656, julho de 2013. Recentemente, uma modificação de MPEG-2 TS para transporte de HEVC em camadas foi iniciada. O documento mais recente é “Text of ISO/IEC 13818-1:2013 / Study of PDAM 7 -Carriage of Layered HEVC”, no documento MPEG wl4562, julho de 2014 e será chamado de rascunho L- HEVC TS nesse documento. Um exemplo do design de MPEG-2 TS para transporte de extensões de HEVC é descrito no Pedido de patente provisório US n° 61/925.191, depositado em 8 de janeiro de 2014, e incorporado a título de referência no presente documento. Outro exemplo do design de MPEG-2 TS para transporte de extensões de HEVC é descrito no Pedido de patente provisório US n° 62/025.432, depositado em 16 de junho de 2014.

[0034] A especificação de sistemas de MPEG-2 descreve como fluxos de dados de multimídia comprimida (Vídeo e Áudio) podem ser multiplexados em conjunto com outros dados para formar um único fluxo de dados adequados para transmissão digital ou armazenamento. Sistemas de MPEG-2 descrevem um fluxo elementar, que é um único, componente digitalmente codificado (possivelmente comprimido por MPEG) de um programa (também algumas vezes pronunciado “programa”). Por exemplo, a parte de vídeo e áudio codificado do programa pode ser um fluxo elementar. Um fluxo elementar é primeiramente convertido em um fluxo elementar (PES) empacotado antes multiplexados em um fluxo de programa ou um fluxo de transporte. Dentro do mesmo programa, um elemento de sintaxe de id de fluxo é usado para distinguir os pacotes de PES que pertencem a um fluxo elementar uns dos outros.

[0035] Fluxos de programa e fluxos de transporte são dois multiplexes alternativos que almejam diferentes aplicações. O fluxo de programa é desviado para o armazenamento e exibição de um único programa de um serviço de armazenamento digital e um fluxo de programa é destinado para uso em ambientes sem erro devido ao fato de que o mesmo pode ser suscetível a erros. Um fluxo de programa inclui os fluxos elementares que pertencem ao mesmo e geralmente contém pacotes com pacotes de comprimento variável. Em um fluxo de programa, os pacotes PES que são derivados dos fluxos elementares contribuintes são organizados em ‘pacotes’. Um pacote inclui um cabeçalho de pacote, um leitor de sistema opcional e qualquer número de pacotes PES obtido de qualquer um dos fluxos elementares contribuintes, em qualquer ordem. O cabeçalho de sistema contém um resumo das características do fluxo de programa tais como: sua taxa de dados máxima; o número de fluxos elementares de vídeo e áudio de contribuição; informações de temporização adicionais. Um decodificador pode usar as informações contidas em um cabeçalho de sistema para determinar se o decodificador tem capacidade de decodificar o fluxo de programa ou não.

[0036] O fluxo de transporte é destinado à entrega simultânea de um número de programas através de canais potencialmente propensos a erros. O mesmo é um multiplex elaborado para aplicações de múltiplos programas tais como transmissão contínua, de modo que um único fluxo de transporte possa acomodar muitos programas independentes.

[0037] Um fluxo de transporte inclui uma sucessão de pacotes de transporte, e cada um dos pacotes de transporte tem 188 bytes de comprimento. O uso de pacotes de comprimento curto fixo significa que o fluxo de transporte não é tão suscetível a erros quanto o fluxo de programa. Além disso, cada pacote de transporte de 188 bytes de comprimento é facilmente dado à proteção adicional contra erros processando-se o mesmo através de um processo de proteção contra erros padrão, tais como criptação Reed- Solomon. A resiliência de erros aprimorada do fluxo de transporte significa que o mesmo tem uma chance melhor de sobreviver aos canais de erros a serem constatados em um ambiente de difusão, por exemplo.

[0038] Pode-se observar que o fluxo de transporte é claramente o melhor dois multiplexes com sua resiliência a erros aumentada e capacidade de conduzir 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 demultiplexar.

[0039] O primeiro byte de um pacote de transporte é um byte de sincronização, que é 0x47 (ou seja, valor hexadecimal 47, ou 0100 0111). Um único fluxo de transporte pode transportar muitos programas diferentes, em que cada um compreende muitos fluxos elementares empacotados. Um campo de identificador de pacote (PID) de 13 bits é usado para distinguir pacotes de transporte que contêm os dados de um fluxo elementar daqueles que conduzem os dados de outros fluxos elementares. O multiplexador tem a responsabilidade de garantir que cada fluxo elementar seja privilegiado em um valor de PID único. O último byte de um pacote de transporte é um campo de contagem de continuidade. O mesmo é acrescentado entre sucessivos pacotes de transporte pertencentes ao mesmo fluxo elementar. Isso permite que um decodificador detecte a perda ou ganho de um pacote de transporte e esperançosamente oculte os erros que podem, de outro modo, se resultar de tal evento.

[0040] Embora o valor de PID torne claro ao qual o fluxo elementar um pacote de transporte pertence, o decodificador também precisa ter capacidade de determinar quais fluxos elementares pertencem a qual programa. As informações específicas de programa são usadas para especificar explicitamente a relação entre programas e fluxos elementares de componente. As informações específicas de programa podem incluir uma tabela de mapa de programa (PMT), um mapa de fluxo de programa (PSM), uma tabela de associação de programa (PAT), uma tabela de informações de rede (NIT), e/ou uma tabela de acesso condicional (CAT).

[0041] Cada programa conduzido em um fluxo de transporte tem uma tabela de mapa de programa associada ao mesmo. Essa tabela fornece detalhes acerca do programa e os fluxos elementares que formam o programa. Por exemplo, pode haver um programa com número 3 que contém vídeo com PID 33, áudio em inglês com PID 57, e áudio em chinês com PID 60. Permite-se que um PMT inclua mais do que um programa. A tabela básica de mapa de programa pode ser acrescida com alguns dos muitos descritores especificados dentro da especificação de sistemas de MPEG-2. Os descritores conduzem informações adicionais acerca de um programa ou seus fluxos elementares de componente. Os descritores podem incluir, por exemplo, parâmetros de criptação de vídeo, parâmetros de criptação de áudio, identificação de linguagem, informações de pan & scan, detalhes de acesso condicionais, informações de direitos autorais, e assim por diante. Um transmissor contínuo ou outro usuário pode definir descritores adicionais privados se for exigido. Em fluxos elementares de componente relacionados a vídeo, há também um descritor de hierarquia, que fornece informações para identificar os elementos de programa que contêm componentes de fluxos de vídeo, áudio e privados codificados de modo hierárquico.

[0042] O PSM fornece uma descrição dos fluxos elementares no fluxo de programa e sua relação um com o outro. Quando conduzido em um fluxo de transporte, essa estrutura não deve ser modificada, pela especificação de sistemas de MPEG-2. O PSM está presente como um pacote de PES quando o valor de id de fluxo é OxBC (valor hexadecimal BC, ou 1011 1100).

[0043] Uma lista complexa de todos os programas disponíveis em um fluxo de transporte é mantida na Tabela de Associação de Programa. Essa tabela pode ser facilmente constatada, à medida que a mesma tem sempre o valor de PID 0. Cada programa é listado junto ao valor de PID dos pacotes de transporte que contêm sua tabela de mapa de programa. Com o uso do mesmo exemplo mencionado acima, a PMT que especifica os fluxos elementares de programa número 3 tem um PID de 1001 e outra PMT tem outro PID de 1002. Esse conjunto de informações é incluído na PAT.

[0044] O programa número zero, especificado na PAT, tem um significado especial. Esse programa é usado para apontar o caminho à tabela de informações de rede. A NIT é opcional. Quando presente, a NIT é destinada a fornecer informações acerca da rede física que realiza 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.

[0045] Se quaisquer fluxos elementares dentro de um fluxo de transporte forem embaralhados, então uma tabela de acesso condicional precisa estar presente, pela especificação de sistemas de MPEG-2. A CAT fornece detalhes do(s) sistema(s) de embaralhamento em uso e fornece os valores de PID de pacotes de transporte que contêm as informações de gerenciamento e direito de acesso condicional. O formato dessas informações não é especificado dentro da especificação de sistemas de MPEG-2.

[0046] Em MPEG-2 TS, um descritor de hierarquia é projetado para sinalizar a hierarquia de subfluxos de bits em diferentes fluxos elementares. O descritor de hierarquia fornece informações para identificar os elementos de programa que contêm componentes de fluxos de vídeo, áudio e privados codificados de modo hierárquico. A tabela 2-49 da especificação de sistemas de MPEG-2 é reproduzida abaixo: Conforme descrito em mais detalhe, em alguns exemplos, a revelação descreve um descritor de hierarquia aperfeiçoado, e uma atualização na Tabela 2-49 mostrada imediatamente abaixo. A Tabela 2-49 atualizada para o descritor de hierarquia aperfeiçoado é descrita em mais detalhe adicionalmente abaixo.TABELA 2-49 - DESCRITOR DE HIERARQUIA

[0047] Semântica para os elementos de sintaxe da tabela 2-49 de sistemas de MPEG-2 é fornecida abaixo:

[0048] temporal_scalability_flag - Um sinalizador de 1-bit, que quando definidas para “0” indica que o elemento de programa associado aprimora a taxa de quadro do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado.

[0049] spatial_scalability_flag - Um sinalizador de 1-bit, que, quando ajustado para “0”, indica que o elemento de programa associado aprimora a resolução espacial do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado.

[0050] quality_scalability_flag - Um sinalizador de 1-bit, que, quando ajustado para “0”, indica que o elemento de programa associado aprimora a qualidade de SNR ou fidelidade do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado.

[0051] hierarchy_type - A relação hierárquica entre a camada hierárquica associada e sua camada embutida de hierarquia é definida na tabela 2-50. Se a escalabilidade se aplicar em mais do que uma dimensão, esse campo deve ser ajustado para o valor de “8” (“escalabilidade combinada”), e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados de acordo. Para os subfluxos de bits de vídeo de MVC, esse campo deve ser ajustado para o valor de “9” (“subfluxo de bits de vídeo de MVC”) e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados para “1”. Para os subfluxos de bits de vista de base de MVC, esse campo deve ser ajustado para o valor de “15” e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados para “1”.

[0052] hierarchy_layer_index - O índice de camada de hierarquia é um campo de 6 bits que define um índice exclusivo do elemento de programa associado em uma tabela de hierarquias de camada de codificação. Os índices devem ser exclusivos dentro de uma única definição de programa. Para subfluxos de bits de vídeo de fluxos de vídeo de AVC que se conformam a um ou mais perfis definidos em Annex G de Rec. ITU-T H.264|ISO/IEC 14496-10, esse é o índice de elemento de programa, que é atribuído de modo que a ordem de fluxo de bits seja correta se representações de dependência de SVC associadas dos subfluxos de bits de vídeo da mesma unidade de acesso forem remontadas de maneira crescente de índice de camada de hierarquia. Para subfluxos de bits de vídeo de MVC de fluxos de vídeo de AVC que se conformam a um ou mais perfis definidos em Annex H de Rec. ITU-T H.264|ISO/IEC 14496-10, esse é o índice de elemento de programa, que é atribuído de modo que a ordem de fluxo de bits seja correta se subconjuntos de componente de vista de MVC associados dos subfluxos de bits de vídeo de MVC da mesma unidade de acesso forem remontadas de maneira crescente de índice de camada de hierarquia.

[0053] tref_present_flag - Um sinalizador de 1-bit, que, quando ajustado para “0”, indica que o campo de TREF pode estar presente nos cabeçalhos de pacote de PES no fluxo elementar associado. O valor de “1” “para esse sinalizador é reservado.

[0054] hierarchy_embedded_layer_index - O hierarchy_embedded_layer_index é um campo de 6 bits que define o índice de camada de hierarquia do elemento de programa que precisa ser acessado e estar presente na ordem de decodificação antes da decodificação do fluxo elementar associado a esse descritor de hierarquia. Esse campo é indefinido se o valor de hierarchy_type for 15.

[0055] hierarchy_channel - O hierarchy_channel é um campo de 6 bits que indica o número de canal destinado para o elemento de programa associado em um conjunto ordenado de canais de transmissão. O canal de transmissão mais robusta é definido pelo menor valor desse campo em relação à definição de hierarquia de transmissão geral. Um dado hierarchy_channel pode ser, ao mesmo tempo, atribuído aos diversos elementos de programa.

[0056] A tabela 2-50 da especificação de sistemas de MPEG-2 é reproduzida abaixo: Em alguns exemplos, a revelação descreve atualizações na Tabela 2-50 como parte da revelação de um descritor de hierarquia aperfeiçoado. A Tabela 2-50 é descrita em mais detalhe adicionalmente abaixo.TABELA 2-50 - VALORES DE CAMPO DE HIERARCHYTYPE

[0057] Em MPEG-2 TS, dois descritores são projetados para sinalizar características dos subfluxos de bits para SVC e MVC respectivamente: O descritor de extensão de SVC e descritor de extensão de MVC. SVC e MVC são as extensões de codificação de vídeo escalonável e codificação de vídeo de múltiplas vistas de ITU-T H.264/AVC. Adicionalmente, em MPEG-2 TS, há um descritor de ponto de operação de MVC que descreve as características de pontos de operação. A sintaxe e semântica dos três descritores são fornecidas abaixo.

[0058] A Tabela 2-96 abaixo ilustra elementos de sintaxe para o descritor de extensão de SVC de sistemas de MPEG-2. Para os subfluxos de bits de vídeo de fluxos de vídeo de AVC que se conformam a um ou mais perfis definidos em Annex G de Rec. ITU T H.264|ISO/IEC 14496-10, o descritor de extensão de SVC da tabela 2-96 fornece informações acerca do fluxo de vídeo de AVC resultante da remontagem (até) o subfluxo de bits de vídeo associado e fornece informações acerca de escalabilidade e a remontagem do subfluxo de bits de vídeo associado. Pode haver um descritor de extensão de SVC associado a qualquer um dos subfluxos de bits de vídeo de um fluxo de vídeo de AVC que se conforma a um ou mais perfis definidos em Annex G de Rec. ITU-T H.264|ISO/IEC 14496-10.TABELA 2-96 - DESCRITOR DE EXTENSÃO DE SVC

[0059] A semântica para os elementos de sintaxe da Tabela 2-96 de acordo com a especificação de sistemas de MPEG-2 é fornecida abaixo:

[0060] width - Esse campo de 16 bits indica a resolução de largura de imagem máxima, em pixels, do fluxo de vídeo de AVC remontado.

[0061] height - Esse campo de 16 bits indica a resolução de altura de imagem máxima, em pixels, do fluxo de vídeo de AVC remontado.

[0062] frame_rate - Esse campo de 16 bits indica a taxa de quadro máxima, em quadros/256 segundos, do fluxo de vídeo de AVC remontado.

[0063] average_bitrate - Esse campo de 16 bits indica a taxa de bits média, em kbit por segundo, do fluxo de vídeo de AVC remontado.

[0064] maximum_bitrate - Esse campo de 16 bits indica a taxa de bits máxima, em kbits por segundo, do fluxo de vídeo de AVC remontado.

[0065] dependency_id - Esse campo de 3 bits indica o valor de id de dependência associada ao subfluxo de bits de vídeo.

[0066] quality_id_start - Esse campo de 4 bits indica o valor máximo do id de qualidade do elemento de sintaxe de cabeçalho de unidade de NAL de todas as unidades de NAL contidas no subfluxo de bits de vídeo associado.

[0067] quality_id_end - Esse campo de 4 bits indica o valor máximo do id de qualidade do elemento de sintaxe de cabeçalho de unidade de NAL de todas as unidades de NAL contidas no subfluxo de bits de vídeo associado.

[0068] temporal_id_start - Esse campo de 3 bits indica o valor mínimo de o temporal_id do elemento de sintaxe de cabeçalho de unidade de NAL de todas as unidades de NAL contidas no subfluxo de bits de vídeo associado.

[0069] temporal_id_end - Esse campo de 3 bits indica o valor máximo do temporal_id do elemento de sintaxe de cabeçalho de unidade de NAL de todas as unidades de NAL contidas no subfluxo de bits de vídeo associado.

[0070] no_sei_nal_unit_present - Esse sinalizador de 1-bit, quando ajustado para “1”, indica que nenhuma unidade de NAL SEI está presente no subfluxo de bits de vídeo associado. No caso em que o sinalizador no_sei_nal_unit_present é ajustado para “1” para todos os subfluxos de bits de vídeo de SVC e não é ajustado para “1” ou não está presente para o subfluxo de bits de vídeo de AVC de SVC, quaisquer unidades de NAL SEI, se estiverem presentes, são incluídas no subfluxo de bits de vídeo de AVC de SVC. Se o descritor de extensão de SVC estiver ausente para todos os subfluxos de bits de vídeo, unidades de NAL SEI podem estar presentes em qualquer representação de dependência de SVC de um SVC subfluxo de bits de vídeo, e podem exigir a reordenação para a ordem de unidades de NAL dentro de uma unidade de acesso conforme definido em Rec. ITU-T H.264|ISO/IEC 14496-10 antes da remontagem de unidade de acesso.

[0071] A tabela 2-97 abaixo fornece sintaxe para o descritor de extensão de MVC da especificação de sistemas de MPEG-2. Para os subfluxos de bits de vídeo de MVC de fluxos de vídeo de AVC que se conformam a um ou mais perfis definidos em Annex H de Rec. ITU-T H.264|ISO/IEC 14496-10, o descritor de extensão de MVC fornece informações acerca do fluxo de vídeo de AVC resultante da remontagem (até) o subfluxo de bits de vídeo de MVC associado e fornece informações acerca do subfluxo de bits de vídeo de MVC contido e para a remontagem do subfluxo de bits de vídeo de MVC associado. Pode haver um descritor de extensão de MVC associado a qualquer um dos subfluxos de bits de vídeo de MVC (com tipo de fluxo igual a 0x20) de um fluxo de vídeo de AVC que se conforma a um ou mais perfis definidos em Annex H de Rec. ITU-T H.264|ISO/IEC 1449610. Quando o subfluxo de bits de vídeo de MVC é um subfluxo de bits de vista de base de MVC, o descritor de extensão de MVC deve estar presente no PMT ou PSM associado para o tipo de fluxo igual a 0x1B.TABELA 2-97 - DESCRITOR DE EXTENSÃO DE SVC

[0072] A semântica para os elementos de sintaxe da Tabela 2-97 de acordo com a especificação de sistemas de MPEG-2 é fornecida abaixo:

[0073] average_bitrate - Esse campo de 16 bits indica a taxa de bits média, em kbit por segundo, do fluxo de vídeo de AVC remontado. Quando ajustada para 0, a taxa de bits média não é indicada.

[0074] maximum_bitrate - Esse campo de 16 bits indica a taxa de bits máxima, em kbits por segundo, do fluxo de vídeo de AVC remontado. Quando ajustada para 0, a taxa de bits máxima não é indicada.

[0075] view_order_index_min - Esse campo de 10 bits indica o valor mínimo do índice de ordem de vista de todas as unidades de NAL contidas no subfluxo de bits de vídeo de MVC associado.

[0076] view_order_index_max - Esse campo de 10 bits indica o valor máximo do índice de ordem de vista de todas as unidades de NAL contidas no subfluxo de bits de vídeo de MVC associado.

[0077] temporal_id_start - Esse campo de 3 bits indica o valor mínimo do temporal_id do elemento de sintaxe de cabeçalho de unidade de NAL de todas as unidades de NAL contidas no subfluxo de bits de vídeo de MVC associado.

[0078] temporal_id_end - Esse campo de 3 bits indica o valor máximo do temporal_id do elemento de sintaxe de cabeçalho de unidade de NAL de todas as unidades de NAL contidas no subfluxo de bits de vídeo de MVC associado.

[0079] no_sei_nal_unit_present - Esse sinalizador de 1-bit, quando ajustado para “1”, indica que nenhuma unidade de NAL SEI está presente no subfluxo de bits de vídeo associado. No caso em que o sinalizador no_sei_nal_unit_present é ajustado para “1” para todos os subfluxos de bits de vídeo de MVC e não é ajustado para “1” ou não está presente para o subfluxo de bits de vídeo de AVC de MVC, quaisquer unidades de NAL SEI, se estiverem presentes, são incluídas no subfluxo de bits de vídeo de AVC de MVC. Se o descritor de extensão de MVC estiver ausente para todos os subfluxos de bits de vídeo de MVC, as unidades de NAL SEI podem estar presentes em qualquer subconjunto de componente de vista de MVC de um subfluxo de bits de vídeo de MVC, e pode exigir a reordenação à ordem de unidades de NAL dentro de uma unidade de acesso conforme definido em Rec. ITU-T H.264|ISO/IEC 14496-10 antes da remontagem de unidade de acesso.

[0080] no_prefix_nal_unit_present - Esse sinalizador de 1-bit, quando ajustado para “1” indica que nenhuma unidade de prefixo NAL está presente em nenhum dentre o subfluxo de bits de vídeo de AVC de MVC ou subfluxos de bits de vídeo de MVC. Quando esse bit é ajustado para “0”, o mesmo indica que as unidades de prefixo NAL estão presentes no subfluxo de bits de vídeo de AVC de MVC somente.

[0081] A Tabela 2-100 abaixo fornece sintaxe para o descritor de ponto de operação de MVC da especificação de sistemas de MPEG-2. O descritor de ponto de operação de MVC (consultar a tabela 2-100) fornece um método para indicar o perfil e nível para um ou mais pontos de operação, cada um constituído por um conjunto de um ou mais subfluxos de bits de vídeo de MVC. Se estiver presente, o descritor de ponto de operação de MVC deve ser incluído no grupo de elementos de dados seguidos imediatamente do campo program_info_length no program_map_section. Se um descritor de ponto de operação de MVC está presente dentro de uma descrição de programa, pelo menos um descritor de hierarquia deve estar presente para cada subfluxo de bits de vídeo de MVC presente no mesmo programa. De acordo com a especificação de sistemas de MPEG-2, de modo a indicar diferentes perfis, um descritor de ponto de operação de MVC por perfil é usado.TABELA 2-100 - DESCRITOR DE PONTO DE OPERAÇÃO DE MVC

[0082] A semântica para os elementos de sintaxe da Tabela 2-100 de acordo com a especificação de sistemas de MPEG-2 é fornecida abaixo:

[0083] profile_idc - Esse campo de 8 bits indica o perfil, conforme definido em Rec. ITU-T H.264|ISO/IEC 14496-10, de todos os pontos de operação descritos dentro desse descritor para o fluxo de bits de MVC.

[0084] constraint_setO_flag,constraint_setl_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag - Esses campos devem ser codificados de acordo com a semântica para esse campos definidos em Rec. ITU-T H.264|ISO/IEC 14496-10.

[0085] AVC_compatible_flags - A semântica de sinalizadores compatíveis com AVC são exatamente iguais à semântica do(s) campo(s) definido(s) para os 2 bits entre o sinalizador constraint_set2 e o campo level_idc no parâmetro de sequência ajustado, conforme definido em Rec. ITU-T H.264|ISO/IEC 14496-10.

[0086] level_count - Esse campo de 8 bits indica o número de níveis para os quais os pontos de operação são descritos.

[0087] leve_idc - Esse campo de 8 bits indica o nível, conforme definido em Rec. ITU-T H.264|ISO/IEC 14496-10, do fluxo de bits de MVC para os pontos de operação descritos pelos grupos de elementos de dados a seguir.

[0088] operation_points_count - Esse campo de 8 bits indica o número de pontos de operação descritos pela lista incluída no grupo de elementos de dados a seguir.

[0089] applicable_temporal_id - Esse campo de 3 bits indica o maior valor do temporal_id das unidades de NAL VCL no fluxo de vídeo de AVC remontado.

[0090] num_target_output_views - Esse campo de 8 bits indica o valor do número das vistas almejadas para saída para o ponto de operação associado.

[0091] ES_count - Esse campo de 8 bits indica o número de valores de referência de ES incluídos no grupo de elementos de dados a seguir. Os fluxos elementares indicados no grupo de elementos de dados a seguir formam em conjunto um ponto de operação do fluxo de bits de vídeo de MVC. O valor Oxff é reservado.

[0092] ES_reference - Esse campo de 6 bits indica o índice de camada de hierarquia valor presente no descritor de hierarquia que identifica um subfluxo de bits de vídeo. O perfil e nível para um único ponto de operação, por exemplo, o fluxo de bits de vídeo de MVC inteiro, pode ser sinalizado com o uso do descritor de vídeo de AVC. Além disso, MVC permite decodificar diferentes subconjuntos de vista que podem exigir diferentes perfis e/ou níveis. A especificação do descritor de ponto de operação de MVC suporta a indicação de diferentes perfis e níveis para múltiplos pontos de operação.

[0093] A tabela Amd7-1 abaixo fornece sintaxe para o descritor de vídeo de HEVC de acordo com a especificação de sistemas de MPEG-2. Para um fluxo de vídeo de HEVC, o descritor de vídeo de HEVC fornece informações básicas para identificar parâmetros de codificação, tais como parâmetros de perfil e nível desse fluxo de vídeo de HEVC. Para um subfluxo de bits de vídeo temporal de HEVC ou um subconjunto de vídeo temporal de HEVC, o descritor de vídeo de HEVC fornece informações tais como a maior representação de subcamada temporal de HEVC associada contida no fluxo elementar a qual o mesmo se aplica.

[0094] No rascunho de L-HEVC TS, informações de perfil, categoria, e nível (PTL) e informações de ponto de operação são sinalizados em um descritor de extensão de HEVC e um descritor de ponto de operação de HEVC.TABELA AMD7-1 - DESCRITOR DE VÍDEO DE HEVC

[0095] A semântica para os elementos de sintaxe da Tabela X-1 de acordo com a especificação de sistemas de MPEG-2 é fornecida abaixo:

[0096] Profile_space, tier_flag, profile_idc,profile_compatibility_indication, progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag,frame_only_constraint_flag, reserved_zero_44bits, level_idc - Quando o descritor de vídeo HEVC se aplicar a um fluxo de vídeo HEVC ou a uma representação temporal completa HEVC, esses campos devem ser codificados de acordo com a semântica definida em Rec. ITU-T H.265 |ISO/IEC 23008-2 para general_profile_space, general_tier_flag, general_profile_idc, general_profile_compatibility_flag[i], general_progressive_source_flag, general_interlaced_source_flag, general_non_packed_constraint_flag, general_frame_only_constraint_flag, general_reserved_zero_44bits, general_level_idc, respectivamente, para o fluxo de vídeo de HEVC correspondente ou representação temporal completa de HEVC, e o fluxo de vídeo de HEVC inteiro ou representação temporal completa de HEVC à qual o descritor de vídeo de HEVC é associado devem se conformar às informações sinalizadas por esses campos.

[0097] Quando o descritor de vídeo de HEVC se aplicar a um subfluxo de bits de vídeo temporal de HEVC ou subconjunto de vídeo temporal de HEVC cuja a maior representação de subcamada temporal de HEVC correspondente não é uma representação temporal completa de HEVC, esses campos devem ser codificados de acordo com a semântica definida em Rec. ITU-T H.265 | ISO/IEC 23008-2 para sub_layer _profile_space, sub_layer_tier_flag, sub_layer _profile_idc, sub_layer_profile_compatibility_flag[i],sub_layer_progressive_source_flag, sub_layerJnterlaced_source_flag, sub_layer_ion_packed_constraint_flag, sub_layer_frame_only_constraint_flag, sub_layer_reserved_zero_44bits, sub_layerjeveljdc, respectivamente, para cada representação de subcamada temporal superior HEVC correspondente, e a representação de subcamada temporal superior HEVC à qual o descritor de vídeo HEVC é associado deve se adequar às informações sinalizadas por esses campos.

[0098] Em uma ou mais sequências no fluxo de vídeo de HEVC, o nível pode ser menor do que o nível sinalizado no descritor de vídeo de HEVC, enquanto também pode ocorrer um perfil que é um subconjunto do perfil sinalizado no descritor de vídeo de HEVC. No entanto, no fluxo de vídeo de HEVC inteiro, somente subconjuntos da sintaxe de fluxo de bits inteira devem ser usados que são incluídos no perfil sinalizado no descritor de vídeo de HEVC, se estiver presente. Se o parâmetro de sequência ajustar em um sinal de fluxo de vídeo de HEVC diferentes perfis, e nenhuma restrição adicional for sinalizada, então o fluxo pode precisar exame para determinar qual perfil, se houver, o fluxo inteiro se conforma. Se um descritor de vídeo de HEVC tiver de ser associado a um fluxo de vídeo de HEVC que não se conforma a um único perfil, então o fluxo de vídeo de HEVC deve ser particionado em dois ou mais subfluxos, de modo que os descritores de vídeo de HEVC possa sinalizar um único perfil para cada tal subfluxo.

[0099] temporal_layer_subset_flag – Esse sinalizador de 1-bit, quando ajustado para '1', indica que os elementos de sintaxe que descrevem um subconjunto de camadas temporais são incluídos nesse descritor. Esse campo deve ser ajustado para 1 para subconjuntos de vídeo temporais de HEVC e para subfluxos de bits de vídeo temporais de HEVC. Quando ajustado para '0', os elementos de sintaxe temporal id min e temporal id max não estão incluídas nesse descritor.

[0100] HEVC_still_present_flag - Esse campo de 1 bit, quando ajustado para '1', indica que o fluxo de vídeo de HEVC ou a maior representação de subcamada temporal de HEVC pode incluir imagens estáticas de HEVC. Quando ajustado para “0”, então o fluxo de vídeo de HEVC associado não deve conter imagens estáticas de HEVC. De acordo com Rec. ITU-T H.265 |ISO/IEC 23008-2, imagens de IDR são sempre associadas a um valor de Temporalld igual a 0, consequentemente, se o descritor de vídeo de HEVC se aplicar a um subconjunto de vídeo temporal de HEVC, imagens estáticas de HEVC pode ser somente presente no subfluxo de bits de vídeo temporal de HEVC associado.

[0101] HEVC_24_hour_picture_present_flag - Esse sinalizador de 1-bit, quando ajustado para '1', indica que o fluxo de vídeo de HEVC associado ou a maior representação de subcamada temporal de HEVC pode conter imagens de HEVC de 24 horas. Para a definição de uma imagem de HEVC de 24 horas, consultar 2.1.97. Se esse sinalizador for ajustado para “0”, o fluxo de vídeo de HEVC associado não deve conter nenhuma imagem de HEVC de 24 horas.

[0102] temporal_id_min - Esse campo de 3 bits indica o valor mínimo do Temporalld, conforme definido em Rec. ITU-T H.265 |ISO/IEC 23008-2, de todas as unidades de acesso de HEVC no fluxo elementar associado.

[0103] temporal_id_max - Esse campo de 3 bits indica o valor máximo do Temporalld, conforme definido em Rec. ITU-T H.265 |ISO/IEC 23008-2, de todas as unidades de acesso de HEVC no fluxo elementar associado.TABELA AMD7-2 - DESCRITOR DE PONTO DE OPERAÇÃO DE HEVC

[0104] Hendry et al, “TRANSPORT STREAM FOR CARRIAGE OF VIDEO CODING EXTENSIONS” Pedido no U.S. 14/800.498, depositado em 15 de julho de 2015, descreve detalhes referentes a um design de MPEG-2 TS para transporte de extensões de HEVC.

[0105] As técnicas desta revelação podem ser usadas para superar certos problemas com as técnicas existentes para sinalizar descritores usados para informações de dependência entre camadas de fluxos de bits de HEVC em camadas, como aqueles discutidos abaixo.

[0106] Esta revelação reconhece uma sobreposição de funcionalidade do descritor de hierarquia e do descritor de extensão de hierarquia. No Texto do Estudo de ISO/IEC 13818-1:2013/PDAM7, há dois descritores para sinalização de informações de dependência; ou seja, o descritor de hierarquia e o descritor de extensão de hierarquia. Os dois descritores têm funcionalidade sobreposta como são ambos capazes de descrever o tipo espacial, qualidade e multivista de dependência. No rascunho de L-HEVC TS, é possível que ambos os descritores estejam presentes e associados ao mesmo fluxo elementar. Isso poderia criar confusão e acrescentar complexidade desnecessária para a implementação do padrão.

[0107] Embora o descritor de hierarquia e o descritor de extensão de hierarquia tenham funcionalidade sobreposta, por si, cada um desses não pode ser usado para descrever todos os tipos possíveis de dependência intercamada em SHVC e MV-HEVC. O descritor de hierarquia não é capaz de descrever a dependência de uma imagem auxiliar enquanto o descritor de extensão de hierarquia não é capaz de descrever a dependência temporal.

[0108] Esta revelação também reconhece que há uma descrição ausente de quando o descritor de extensão de hierarquia deve estar presente. No Texto de Estudo de ISO/IEC 13818-1:2013/PDAM7, a presença do descritor de hierarquia ou do descritor de extensão de hierarquia não é obrigatória. A seguir descreve-se quando o descritor de hierarquia deve estar presente, porém não há descrição de quando o descritor de extensão de hierarquia deve estar presente: Quando um programa ITU-T Rec. H.222.0 \ ISO/IEC 13818-1 inclui mais de um subconjunto temporal de vídeo de HEVC, ou mais de um subfluxo de bits de vídeo temporal de HEVC e pelo menos um subconjunto temporal de vídeo de HEVC ou pelo menos um subparticionamento de aperfeiçoamento de HEVC, um ou mais descritor(es) de hierarquia conforme definido em 2.6.7 devem estar presentes para todos os fluxos elementares associados com stream_type igual a 0x24, 0x25 ou 0x27 a 0x2 A. Os descritores de hierarquia devem ser usados para indicar as dependências de todos os subfluxos de bits de vídeo temporais de HEVC, subconjuntos de vídeo temporais de HEVC e subparticionamentos de HEVC.

[0109] Além disso, esta revelação reconhece que há uma descrição ausente de referência de fluxo elementar quando nem o descritor de hierarquia nem o descritor de extensão de hierarquia está presente. Para a sinalização de pontos de operação, uma referência a um fluxo elementar é feita usando o valor de hierarchy_layer_index que é sinalizado no descritor de hierarquia e no descritor de extensão de hierarquia. Quando nenhum dentre o descritor de hierarquia e o descritor de extensão de hierarquia está presente em um programa, não há descrição de como a referência a um fluxo elementar para sinalização de ponto de operação pode ser resolvida.

[0110] Esta revelação também reconhece que há problemas referentes à sinalização de informações de perfil, categoria e nível (PTL). No 9a JCT3V e no 18a reuniões de JCT-VC, foi acordado que as informações de PTL serão sinalizadas para cada camada no fluxo de bits de HEVC em camadas (ou seja, SHVC ou MV-HEVC). Consequentemente, toda a sintaxe e semântica de informações de PTL são desenhadas para camada. Por outro lado, no rascunho L-HEVC TS, a sinalização de informações de PTL é sinalizada para cada ponto de operação em vez de para cada camada incluída em cada ponto de operação. Tal sinalização não está correta visto que a sinalização no rascunho L-HEVC TS não especifica sintaxe e semântica diferentes para informações de PTL, porém simplesmente se refere à sintaxe e semântica de informações de PTL definidas nas especificações de rascunho de SHVC / MV-HEVC.

[0111] Esta revelação reconhece adicionalmente que há uma ineficiência de sinalização de informações de PTL. Uma camada em um fluxo de bits de HEVC em camadas pode ser parte de um ou mais pontos de operação. Considerando-se que as informações de PTL devem estar associadas a camadas dentro de pontos de operação, é provável que as mesmas estruturas de PTL sejam sinalizadas repetidamente se as estruturas de PTL forem sinalizadas usando o descritor de extensão de HEVC ou o ponto de operação de HEVC. Portanto, a eficiência de sinalização de informações de PTL deve ser aprimorada evitando-se repetir a sinalização das mesmas informações.

[0112] Ademais, esta revelação reconhece que certas informações estão faltando na sinalização de ponto de operação. A sinalização de ponto de operação atual em cada descritor de extensão de HEVC ou descritor de ponto de operação de HEVC é desprovida de informações importantes, como a indicação do conjunto de camadas de saída associadas e o esquema de particionamento. Essas duas informações são essenciais para determinar os parâmetros de HRD aplicáveis para fluxos elementares em cada ponto de operação. Conforme especificado no Annex F of Rec. ITU-T H.265 I ISO/IEC 23008-2, o parâmetro de HRD aplicável para um particionamento é determinado pelo valor de bsp_hrd_idx, que é indexado por um índice para o conjunto de camadas de saída alvo (TargetOlsIdx), esquema de particionamento (TargetPsIdx), id temporal mais alto (HighestTid), índice de agenda de entrega (SchedSelCombldx) bem como um índice para o particionamento (partitionldx). Para o transporte de fluxo de bits de HEVC em camadas, o HighestTid é atribuído com base no id temporal aplicável / máximo de um ponto de operação, SchedSelCombldx é atribuído com base no SchedSelldx descrito em temporização de HEVC e descritor de HRD, e partitionldx é atribuído com base no índice do subparticionamento. Entretanto, não há valor sinalizado / derivado em qualquer descritor dentro do Texto de Estudo de ISO/IEC 13818-1:2013/PDAM7 que possa ser usado para atribuir TargetOhldx e TargetPsIdx.

[0113] Esta revelação também reconhece que há a possibilidade de informações de perfil ausente, categoria ausente e/ou nível ausente para um programa. De acordo com a descrição de agregação de fluxo elementar na subcláusula 2.17.4 de rascunho de L-HEVC TS, a presença de descritor de extensão de HEVC e descritor de ponto de operação de HEVC não é obrigatória. Quando nem o descritor de extensão de HEVC nem o descritor de ponto de operação de HEVC estão presentes, não há informações associadas a fluxos elementares no programa. A presença de informações de PTL é importante por dois motivos. Primeiro, as informações de PTL são úteis para propósito de negociação de sistema. Quando as informações de PTL não estão disponíveis no nível de transporte, a entidade de sistema (por exemplo, middlebox inteligente na parte intermediária do sistema de entrega) é forçada a pesquisar o nível codec (ou seja, a entidade de sistema deve utilizar e/ou gastar mais recursos para determinar as informações de PTL do nível codec do que aqueles recursos exigidos para determinar as informações de PTL do nível de transporte) que consiste em um fardo. Então, as informações de PTL podem ser necessárias por um modelo de armazenamento em buffer quando não há parâmetros de HRD presentes.

[0114] A seguir são descritos exemplos de acordo com a revelação. As técnicas exemplificadoras podem ser implementadas em conjunto ou separadamente. Em alguns exemplos, as técnicas exemplificadoras podem resolver os problemas descritos acima. Entretanto, resolver os problemas descritos acima não é necessário. Por exemplo, as técnicas descritas nesta revelação não devem ser consideradas limitadas a resolver os problemas descritos acima, ou fornecer necessariamente as vantagens descritas nesta revelação. Os problemas descritos acima e as potenciais vantagens são meramente apresentados para contexto e para ajudar a entender, e não devem ser considerados como uma exigência.

[0115] Um sumário de certos métodos desta revelação é fornecido abaixo, com uma implementação detalhada de algumas técnicas exemplificadoras fornecidas adicionalmente abaixo. Alguns desses conjuntos de procedimentos podem ser aplicados independentemente e, dentre os mesmos, alguns podem ser aplicados em combinação.

[0116] Em alguns exemplos, o descritor de extensão de HEVC existente e o descritor de ponto de operação de HEVC podem ser integrados em um descritor (ou seja, um único descritor) e esse único descritor pode reutilizar o nome “descritor de ponto de operação de HEVC”. Esse descritor de ponto de operação de HEVC pode ter os seguintes componentes: a. Uma lista de estruturas de PTL. As estruturas de PTL na lista devem ser referidas e associadas a camadas de ponto de operação por índices. b. Uma lista de pontos de operação. Cada ponto de operação inclui as seguintes informações: i. O conjunto de camadas de saída associado ii. O esquema de particionamento associado iii. A subcamada temporal mais alta iv. Lista de fluxos elementares (ou seja, subparticionamento) que constituem o ponto de operação v. O número de camadas de saída vi. Mapeamento de camada contida em cada fluxo elementar do ponto de operação com PTL vii. Informações de taxa de quadros

[0117] Quando a dependência entre fluxos elementares dentro de um programa ITU-T Rec. H.222.0 |ISO/IEC 13818-1 estiver disponível (por exemplo, sinalizada no descritor de hierarquia ou descritor de extensão de hierarquia), a lista de fluxos elementares (ou seja, subparticionamento) que constituem um ponto de operação pode incluir apenas o número mínimo de fluxos elementares. Utilizando-se as informações de dependência disponíveis, a lista de fluxos elementares que constituem o ponto de operação pode ser preenchida.

[0118] Quando a dependência entre fluxos elementares dentro de um programa ITU-T Rec. H.222.0 | ISO/IEC 13818-1 estiver disponível (por exemplo, sinalizada no descritor de hierarquia ou descritor de extensão de hierarquia), a lista de fluxos elementares (ou seja, subparticionamento) que constituem um ponto de operação pode ser exigida para incluir a lista completa de fluxos elementares que constituem o ponto de operação.

[0119] Em um exemplo, em vez de sinalizar o número de camadas de saída em um ponto de operação, para cada camada incluída no ponto de operação, um sinalizador é sinalizado para indicar se a camada é ou não uma camada de saída. Alternativamente, tanto o número de camadas de saída como a indicação de sinalizador (indicando se uma respectiva camada é uma camada de saída) para cada camada podem ser sinalizados.

[0120] Quando houver mais de um descritor de ponto de operação de HEVC presente para o programa ITU-T Rec. H.222.0 | ISO/IEC 13818-1, o seguinte pode ser aplicado. Primeiro, a lista de informações de PTL sinalizadas no (n + l)-ésimo descritor de ponto de operação de HEVC, em que n começa a partir de 1, pode ser a continuação da lista de informações de PTL sinalizadas no n-ésimo descritor de ponto de operação de HEVC. Então, a lista de pontos de operação sinalizados no (n + l)-ésimo descritor de ponto de operação de HEVC, em que n começa a partir de 1, pode ser a continuação da lista de pontos de operação sinalizados no n-ésimo descritor de ponto de operação de HEVC. Em outras palavras, as informações de dois ou mais descritores de ponto de operação de HEVC consecutivos como sinalizado podem ser concatenadas para formar um único descritor. Ou seja, informações similares podem ser sinalizadas em dois ou mais descritores de ponto de operação de HEVC distintos, e essas informações podem ser concatenadas como se todas as informações fossem sinalizadas em um único descritor.

[0121] O descritor de ponto de operação de HEVC descrito no presente documento pode ser um descritor de nível de programa (ou seja, sinalizado juntamente com outros descritores que vêm imediatamente após o campo de elemento de sintaxe program_info_length na tabela de mapa de programa). Alternativamente, o descritor de ponto de operação de HEVC pode ser um descritor de nível de fluxo elementar (ou seja, sinalizado juntamente com outros descritores que vêm após o campo de elemento de sintaxe ES_info_length na tabela de mapa de programa).

[0122] A presença do descritor de ponto de operação de HEVC pode ser obrigatória quando um programa tiver um ou mais fluxos elementares com stream_type igual a 0x27, 0x28, 0x29 ou 0x2A. De modo semelhante, a presença do descritor de vídeo de HEVC pode ser obrigatória para cada fluxo elementar com stream_type igual a 0x24 e 0x25.

[0123] Em alguns exemplos, o descritor de extensão de hierarquia pode ser modificado para sustentar a descrição de dependência / aperfeiçoamento temporal. Por esse motivo, um dos valores reservados na Tabela amd7-4 - Semântica de bits de dimensão de extensão no rascunho de L- HEVC TS é alocada para aperfeiçoamento temporal.

[0124] Em alguns exemplos, o descritor de hierarquia é modificado para sustentar o aperfeiçoamento de camada auxiliar. Para esse propósito, o seguinte pode se aplicar: a. Usar um dos sinalizadores reservados na tabela de sintaxe de descritor de hierarquia para indicar aperfeiçoamento auxiliar. b. Atribuir um dos valores reservados na Tabela 2-50 - valores de campos hierarchy_type para indicar o aperfeiçoamento auxiliar.

[0125] Em alguns exemplos, para evitar o uso sobreposto do descritor de hierarquia e do descritor de extensão de hierarquia, o seguinte pode ser utilizado: a. Para cada fluxo elementar que contém uma imagem codificada de HEVC, um descritor (e em alguns exemplos, exatamente um), tanto o descritor de hierarquia como o descritor de extensão de hierarquia, podem (e em alguns exemplos, devem) estar presentes e associados ao fluxo elementar. b. Para cada fluxo elementar que contém imagens com layerld igual a 0, um descritor de hierarquia pode (e em alguns exemplos, devem) estar presente e associado ao fluxo elementar. c. Para cada fluxo elementar que não contém imagens com layerld igual a 0 e que contém imagens com layerld não igual a 0, um descritor de extensão de hierarquia pode (e em alguns exemplos, deve (ou seja, precisa)) estar presente e associado ao fluxo elementar.

[0126] A Figura 1 é um diagrama de blocos que ilustra um sistema de criptação e decodificação de vídeo 10 exemplificador que pode utilizar técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo. Conforme mostrado na Figura 1, o sistema 10 inclui um dispositivo de fonte 12 que fornece dados de vídeo criptados a serem decodificados posteriormente por um dispositivo de destino 14. Em particular, o dispositivo de fonte 12 fornece os dados de vídeo para o dispositivo de destino 14 por meio de uma mídia legível por computador 16. O dispositivo de origem 12 e o dispositivo de destino 14 podem compreender qualquer um dentre uma ampla faixa de dispositivos, incluindo computadores de mesa, computadores do tipo notebook (isto é, do tipo laptop), computadores do tipo tablet, decodificadores de sinais, parelhos de telefone, tais como os então chamados telefones “inteligentes”, dispositivos tipo tablet, televisões, câmeras, dispositivos de exibição, reprodutores de mídias digital, consoles de jogos eletrônicos, dispositivo de transmissão contínua de vídeo ou semelhantes. Em alguns casos, o dispositivo de origem 12 e o dispositivo de destino 14 podem ser equipados para comunicação sem fio.

[0127] O dispositivo de destino 14 pode receber os dados de vídeo criptados a serem decodificados por meio de uma mídia legível por computador 16. A mídia legível por computador 16 pode compreender qualquer tipo de mídias ou dispositivos com capacidade para mover os dados de vídeo codificados do dispositivo de fonte 12 ao dispositivo de destino 14. Em um exemplo, a mídia legível por computador 16 pode compreender uma mídia de comunicação para possibilitar que um dispositivo de fonte 12 transmite os dados de vídeo codificados diretamente a um dispositivo de destino 14 em tempo real. Os dados de vídeo codificados podem ser modulados de acordo com um padrão de comunicação, tal como, um protocolo de comunicação sem fio e transmitidos a um dispositivo de destino 14. A mídia de comunicação pode compreender qualquer mídia de comunicação sem fio e cabeada, tal como, um espectro de radiofrequência (RF) ou uma ou mais linhas de transmissão física. A mídia de comunicação pode formar parte de uma rede com base em pacote, tal como, uma rede de área local, uma rede de longa distância ou uma rede global, tal como, a Internet. A mídia de comunicação pode incluir roteadores, comutadores, estações-base, ou qualquer outro equipamento que pode ser útil que para facilitar a comunicação do dispositivo de origem 12 com o dispositivo de destino 14.

[0128] Em alguns exemplos, dados criptados podem ser emitidos a partir da interface de saída 22 para um dispositivo de armazenamento. De modo similar, dados criptados podem ser acessados a partir do dispositivo de armazenamento pela interface de entrada. O dispositivo de armazenamento pode incluir qualquer um dentre uma variedade de meios de armazenamento de dados distribuídos ou acessados localmente como um disco rígido, discos Blu-ray, DVDs, CD-ROMs, memória flash, memória volátil ou não volátil ou quaisquer outros meios de armazenamento digital adequado para armazenar dados de vídeo codificados. Em um exemplo adicional, o dispositivo de armazenamento pode corresponder a um servidor de arquivo ou a outro dispositivo de armazenamento intermediário que pode armazenar o vídeo codificado gerado pelo dispositivo de fonte 12. O dispositivo de destino 14 pode acessar os dados de vídeo armazenados do dispositivo de armazenamento por meio de transmissão contínua ou transferência por download. O servidor de arquivo pode ser qualquer tipo de servidor com capacidade para armazenar dados de vídeo criptados e para transmitir esses dados de vídeo criptados para o dispositivo de destino 14. Os servidores de arquivo exemplificativos incluem um servidor da web (por exemplo, para um site da web), um servidor FTP, dispositivos de armazenamento anexado à rede (NAS) ou uma unidade de disco local. O dispositivo de destino 14 pode acessar os dados de vídeo criptados através de qualquer conexão de dados padrão, incluindo uma conexão de Internet. Isso pode incluir um canal sem fio (por exemplo, uma conexão Wi-Fi), uma conexão cabeada (por exemplo, DSL, modem a cabo, etc.), ou uma combinação dos dois que seja adequada para cessar os dados de vídeo criptados armazenados em um servidor de arquivos. A transmissão de dados de vídeo criptados a partir do dispositivo de armazenamento pode ser uma transmissão contínua, uma transmissão através de transferência por download ou uma combinação das mesmas.

[0129] As técnicas desta revelação não se limitam necessariamente às aplicações ou definições sem fio. As técnicas podem ser aplicadas à codificação de vídeo visando dar apoio a qualquer uma dentre uma variedade de aplicações de multimídia, tais como difusões de televisão aberta, transmissões de televisão a cabo, transmissões de televisão por satélite, transmissões contínuas de vídeo pela Internet, tais como transmissão contínua adaptativa dinâmica através de HTTP (DASH), vídeo digital que é criptado em uma mídia de armazenamento de dados, decodificação de vídeo digital armazenado em uma mídia de armazenamento de dados, ou outras aplicações. Em alguns exemplos, o sistema 10 pode ser configurado para suportar transmissão de vídeo unidirecional ou bidirecional a fim de suportar aplicações, tais como transmissão contínua de vídeo, reprodução de vídeo, difusão de vídeo e/ou videotelefonia.

[0130] No exemplo da Figura 1, o dispositivo de fonte 12 inclui uma fonte de vídeo 18, um criptador de vídeo 20, multiplexador 21 e uma interface de saída 22. O dispositivo de destino 14 inclui uma interface de entrada 28, demultiplexador 29, um decodificador de vídeo 30 e um dispositivo de exibição 32. De acordo com esta revelação, o multiplexador 21 de dispositivo de fonte 12 pode ser configurado para aplicar as técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo, enquanto o demultiplexador 29 pode receber tais dados para processar e encaminhar os dados de vídeo processados para, por exemplo, o decodificador de vídeo 30. Em outros exemplos, um dispositivo de fonte e um dispositivo de destino podem incluir outros componentes ou disposições. Por exemplo, o dispositivo de fonte 12 pode receber dados de vídeo a partir de uma fonte de vídeo externa 18, como uma câmera externa. De modo semelhante, o dispositivo de destino 14 pode fazer interface com um dispositivo de exibição externo, em vez de incluir um dispositivo de exibição integrado.

[0131] O sistema ilustrado 10 da Figura 1 é meramente um exemplo. As técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo podem ser realizadas por qualquer dispositivo de criptação e/ou decodificação de vídeo digital. Embora, em geral, as técnicas desta revelação sejam realizadas por um dispositivo de criptografia de vídeo, as técnicas também podem ser realizadas por um criptógrafo/decodificador de vídeo, tipicamente chamado de um “CODEC”. Além disso, as técnicas desta revelação também podem ser realizadas por um pré-processador de vídeo. O dispositivo de fonte 12 e o dispositivo de destino 14 são simplesmente exemplos de tais dispositivos de codificação nos quais o dispositivo de fonte 12 gera dados de vídeo codificados para transmissão para o dispositivo de destino 14. Em alguns exemplos, os dispositivos 12, 14 podem operar de maneira substancialmente simétrica de modo que cada um dos dispositivos 12, 14 inclua componentes de criptação e decodificação de vídeo. Por conseguinte, o sistema 10 pode suportar transmissão de vídeo unidirecional ou bidirecional entre dispositivos de vídeo 12, 14, por exemplo, para transmissão contínua de vídeo, reprodução de vídeo, radiodifusão de vídeo ou videotelefonia.

[0132] A fonte de vídeo 18 do dispositivo de fonte 12 pode incluir um dispositivo de captura de vídeo, tal como, uma câmera de vídeo, um arquivo de vídeo que contém um vídeo anteriormente capturado e/ou uma interface de alimentação de vídeo para receber vídeo de um fornecedor de conteúdo de vídeo. Como uma alternativa adicional, uma fonte de vídeo 18 pode gerar dados com base em computação gráfica como o vídeo-fonte ou uma combinação de vídeo ao vivo, vídeo arquivado e vídeo gerado por computador. Em alguns casos, caso a fonte de vídeo 18 seja uma câmera de vídeo, o dispositivo de fonte 12 e o dispositivo de destino 14 podem formar os assim chamados telefones de câmera ou videofones. No entanto, conforme mencionado acima, as técnicas descritas nesta revelação podem ser aplicáveis à codificação de vídeo em geral, e podem ser aplicadas a aplicações sem fio e/ou cabeadas. Em cada caso, o vídeo capturado, pré-capturado ou gerado por computador pode ser criptado por criptador de vídeo 20. As informações de vídeo criptadas podem, então, ser emitidas pela interface de saída 22 para uma mídia legível por computador 16.

[0133] O meio legível por computador 16 pode incluir meios transitórios, como uma transmissão por difusão sem fio ou por difusão com fio ou meios de armazenamento (ou seja, meios de armazenamento não transitórios), como um disco rígido, unidade flash, disco compacto, disco de vídeo digital, disco Blu-ray ou outros meios legíveis por computador. Em alguns exemplos, um servidor de rede (não mostrado) pode receber dados de vídeo criptados a partir do dispositivo de fonte 12 e fornecer os dados de vídeo criptados para o dispositivo de destino 14, por exemplo, por meio de transmissão por rede. De modo similar, um dispositivo de computação de uma instalação de produção de mídia, tal como uma instalação de rotulação de disco, pode receber dados de vídeo criptados a partir do dispositivo de fonte 12 e produzir um disco contendo os dados de vídeo criptados. Portanto, a mídia legível por computador 16 pode ser entendida como incluindo uma ou mais mídias legíveis por computador várias formas, em vários exemplos.

[0134] A interface de entrada 28 de dispositivo de destino 14 recebe informações a partir da mídia legível por computador 16. As informações do meio legível por computador 16 podem inclui informações de sintaxe definidas pelo criptador de vídeo 20, que também é usado pelo decodificador de vídeo 30, que inclui elementos de sintaxe que descrevem características e/ou o processamento de blocos e outras unidades codificadas, por exemplo, GOPs. O dispositivo de exibição 32 exibe os dados de vídeo decodificados para um usuário, e pode compreender qualquer um dentre uma variedade de dispositivos de visores como um tubo de raio de cátodo (CRT), um visor de cristal líquido (LCD), um visor de plasma, um visor de diodo emissor de luz orgânico (OLED) ou outro tipo de dispositivo de exibição.

[0135] O criptador de vídeo 20 e o decodificador de vídeo 30 podem operar de acordo com um padrão de codificação de vídeo, tal como, um padrão de Codificação de Vídeo de Alta Eficiência (HEVC), e pode se conformar ao Modelo de Teste HEVC (HM). Alternativamente, o criptador de vídeo 20 e o decodificador de vídeo 30 podem operar de acordo com outros padrões de proprietário ou indústria, tal como o padrão ITU-T H.264, alternativamente chamado de MPEG-4, Parte 10, Codificação de Vídeo Avançada (AVC), ou extensões de tais padrões. As técnicas dessa revelação, entretanto, não são limitadas a qualquer padrão de codificação específico. Outros exemplos padrões de codificação de vídeo incluem MPEG-2 e ITU-T H.263. Embora não seja mostrado na Figura 1, em alguns aspectos, o criptador de vídeo 20 e o decodificador de vídeo 30 podem ser, cada um, integrados a um criptador e decodificador de áudio, e podem incluir unidades MUX-DEMUX apropriadas, ou outro hardware e software, para lidar com a criptação tanto de áudio quanto de vídeo em uma corrente de dados comum ou correntes de dados separadas. Caso aplicável, as unidades MUX-DEMUX podem se conformar ao protocolo multiplexador ITU H.223, ou outros protocolos como protocolo de datagrama de usuário (UDP).

[0136] O padrão ITU-T H.264/MPEG-4 (AVC) foi formulado pelo Grupo de Especialistas em Codificação de Vídeo (VCEG) de ITU-T junto com o Grupo de Especialistas de Imagem em Movimento (MPEG) de ISO/IEC como o produto de uma parceria coletiva conhecida como a Equipe de Vídeo Conjunta (JVT). Em alguns aspectos, as técnicas descritas nesta revelação podem ser aplicadas aos dispositivos que geralmente se conformam ao padrão H.264. O padrão H.264 é descrito na recomendação de ITU-T H.264, Codificação de Vídeo Avançada para serviços audiovisuais genéricos, pelo Grupo de Estudo de ITU-T, e datado de março de 2005, que pode ser denominado no presente documento como o padrão H.264 ou especificação de H.264, ou o padrão ou especificação H.264/AVC. A Equipe de Vídeo Conjunta (JVT) continua a funcionar nas extensões para H.264/MPEG-4 AVC.

[0137] O criptador de vídeo 20 e o decodificador de vídeo 30, cada um, podem ser implantados como qualquer um dentre uma variedade de conjunto de circuitos de criptador adequado, como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), matrizes de porta programáveis por campo (FPGAs), lógica discreta, software, hardware, firmware ou quaisquer combinações dos mesmos. Quando os conjuntos de procedimentos são implantados parcialmente em software, um dispositivo pode armazenar instruções para o software em um meio legível por computador não transitório adequado e executar as instruções em hardware com o uso de um ou mais processadores para realizar os conjuntos de procedimentos dessa revelação. Cada um dentre o criptador de vídeo 20 e o decodificador de vídeo 30 pode estar incluído em um ou mais criptadores ou decodificadores, um dos quais pode ser integrado como parte de um criptador/decodificador (CODEC) combinado em um dispositivo respectivo.

[0138] O JCT-VC desenvolveu o padrão de HEVC, e continua a operar em extensões do padrão de HEVC. Os esforços de padronização HEVC têm base em um modelo de evolução de um dispositivo de codificação de vídeo referido como o Modelo de Teste HEVC (HM). O HM considera diversas capacidades adicionais para dispositivos de codificação de vídeo em relação a dispositivos existentes de acordo com, por exemplo, ITU-T H.264/AVC. Por exemplo, enquanto H.264 fornece nove modos de codificação intrapredição, o HM pode proporcionar trinta e três (e pode ser trinta e cinco) modos de codificação intrapredição.

[0139] Em geral, o modelo de trabalho do HM descreve que um quadro de vídeo ou imagem pode ser dividida em uma sequência de blocos-árvore ou as maiores unidades de codificação (LCUs) (também denominadas como “unidades de árvore de codificação”) que incluem ambas as amostras luma e croma. Os dados de sintaxe dentro de um fluxo de bits podem definir um tamanho para a LCU, que é uma unidade de codificação maior em termos da quantidade de pixels. Uma fatia inclui inúmeros blocos de árvore consecutivos em ordem de codificação. Um quadro ou figuração de vídeo pode ser particionado em uma ou mais fatias. Cada bloco de árvore pode ser dividido em unidades de codificação (CUs) de acordo com uma árvore quadrática. Em geral, uma estrutura de dados de árvore quadrática inclui um nó por CU, com um nó de raiz correspondente ao bloco em árvore. Se uma CU for dividida em quatro sub-CUs, o nó correspondente à CU inclui quatro nós de folha, cada um dos quais corresponde a uma das sub-CUs.

[0140] Cada nó da estrutura de dados de árvore quadrática pode fornecer dados de sintaxe para a CU correspondente. Por exemplo, um nó na árvore quadrática pode incluir um sinalizador dividido, que indica se a CU que corresponde ao nó está dividida em sub-CUs. Os elementos de sintaxe para uma CU podem ser definidos de modo recursivo e podem depender de se a CU está dividida em sub-CUs. Se uma CU não estiver mais dividida, a mesma é denominada como uma CU de folha. Nesta revelação, quatro sub-CUs de uma CU de folha também serão denominadas como CUs de folha mesmo se não houver divisão explícita da CU de folha original. Por exemplo, se uma CU de tamanho 16x16 não estiver mais dividida, as quatro sub-CUs 8x8 também serão denominadas como Cus de folha, embora a CU 16x16 nunca tenha sido dividida.

[0141] Uma CU tem um propósito similar a um macrobloco do padrão H.264, exceto que uma CU não tem uma distinção de tamanho. Por exemplo, um bloco de árvore pode ser dividido em quatro nós-filho (também denominados como sub-CUs), e cada nó-filho pode, por sua vez, ser um nó-pai e ser dividido em outros quatro nós-filhos. Um nó-filho final não dividido, denominado como um nó-filho da árvore quadrática, compreende um nó de codificação, também denominado como CU de folha. Os dados de sintaxe associados a um fluxo de bits codificado podem definir uma quantidade máxima de vezes que um bloco de árvore pode ser dividido, denominada como uma profundidade de CU máxima, e também podem definir um tamanho mínimo dos nós de codificação.Consequentemente, um fluxo de bits também pode definir uma unidade de codificação menor (SCU). Esta revelação usa o termo “bloco” para se referir a qualquer um dentre uma CU, uma PU ou uma TU, no contexto de HEVC, ou às estruturas de dados similares no contexto de outros padrões (por exemplo, macroblocos e sub-blocos dos mesmos em H.264/AVC).

[0142] Uma CU inclui um nó de codificação e unidades de previsão (PUs) e unidades de transformada (TUs) associadas ao nó de codificação. Um tamanho da CU corresponde a um tamanho do nó de codificação e deve ter formato quadrado. O tamanho da CU pode variar de 8x8 pixels até o tamanho do bloco de árvore com um máximo de 64x64 pixels ou maior. Cada CU pode conter uma ou mais PUs e uma ou mais TUs. Os dados de sintaxe associados a uma CU podem descrever, por exemplo, a partição da CU em uma ou mais PUs. Os modos de particionamento podem diferir entre se a CU é omitida ou codificada de modo direto, codificada de modo de intrapredição ou codificada de modo de interpredição. As PUs podem ser particionadas para terem formato não quadrado. Os dados de sintaxe associados a uma CU também podem descrever, por exemplo, a partição da CU em uma ou mais TUs de acordo com uma árvore quadrática. Uma TU pode ser quadrada ou não quadrada (por exemplo, retangular) em formato.

[0143] O padrão HEVC prevê transformações de acordo com TUs, que podem ser diferentes para diferentes CUs. As TUs são dimensionadas tipicamente com base no tamanho de PUs dentro de uma dada CU definida por uma LCU particionada, embora esse possa nem sempre ser o caso. As TUs têm tipicamente o mesmo tamanho ou são menores que as PUs. Em alguns exemplos, as amostras residuais correspondentes a uma CU podem ser subdivididas em unidades menores com o uso de uma estrutura de árvore quadrática conhecida como “árvore quadrática residual” (RQT). Os nós de folha da RQT podem ser chamados de unidades de transformada (TUs). Os valores de diferença de pixel associados às TUs podem ser transformados para produzir o coeficiente de transformada, que pode ser quantizado.

[0144] O criptador de vídeo 20 pode usar a partição de árvore quadrática para decompor os blocos residuais luma, de Cb e de Cr de uma CU em um ou mais blocos de transformada luma, de Cb e de Cr. Um bloco de transformada pode ser um bloco retangular de amostras no qual a mesma transformada é aplicada. Uma unidade de transformada (TU) de um CU pode ser um bloco de transformada de amostras luma, dois blocos de transformada correspondentes de amostras croma e estruturas de sintaxe usadas para transformar as amostras de bloco de transformada. Assim, cada TU de uma CU pode estar associada a um bloco de transformada de luma, um bloco de transformada de Cb e um bloco de transformada de Cr. O bloco de transformada de luma associado à TU pode ser um sub-bloco do bloco residual de luma da CU. O bloco de transformada de Cb pode ser um sub-bloco do bloco residual de Cb da CU. O bloco de transformada de Cr pode ser um sub- bloco do bloco residual de Cr da CU. Nas figurações de monocroma ou nas figurações que têm três planos de cor separados, uma TU pode compreender um único bloco de transformada e estruturas de sintaxe usadas para transformar as amostras do bloco de transformada.

[0145] Uma CU de folha pode incluir uma ou mais unidades de previsão (PUs). Em geral, uma PU representa uma área espacial que corresponde a toda ou a uma porção da CU correspondente, e pode incluir dados para recuperar uma amostra de referência para a PU. Além disso, uma PU inclui dados relacionados à previsão. Por exemplo, quando a PU é codificada em intramodo, os dados para a PU podem ser incluídos em uma árvore quadrática residual (RQT), que podem incluir dados que descrevem um modo de intrapredição para uma TU que corresponde à PU. Como outro exemplo, quando a PU for codificada em intermodo, a PU pode incluir dados que definem um ou mais vetores de movimento para a PU. Os dados que definem o vetor de movimento para um PU podem descrever, por exemplo, um componente horizontal do vetor de movimento, um componente vertical do vetor de movimento, uma resolução para o vetor de movimento (por exemplo, precisão de um quarto de pixel ou precisão de um oitavo de pixel), uma imagem de referência para a qual o vetor de movimento aponta e/ou uma lista de imagens de referência (por exemplo, a Lista 0, a Lista 1 ou a Lista C) para o vetor de movimento.

[0146] Uma CU de folha que tem uma ou mais PUs também pode incluir uma ou mais unidades de transformada (TUs). As unidades de transformada podem ser especificadas com o uso de uma RQT (também denominada como uma estrutura de árvore quadrática de TU), conforme discutido acima. Por exemplo, um sinalizador dividido pode indicar se uma CU de folha está dividida em quatro unidades de transformada. Então, cada unidade de transformada pode ser ainda mais dividida em quatro sub-TUs. Quando uma TU não estiver mais dividida, a mesma pode ser denominada como uma TU de folha. Em geral, para intracodificação, todas as TUs de folha que pertencem a uma CU de folha compartilham o mesmo modo de intrapredição. Ou seja, o mesmo modo de intrapredição é geralmente aplicado para calcular valores previstos para todas as TUs de uma CU de folha. Para a intracodificação, um encriptador de vídeo pode calcular um valor residual para cada TU de folha com o uso do modo de intrapredição, como uma diferença entre a porção da CU que corresponde à TU e ao bloco original. Uma TU não é necessariamente limitada ao tamanho de uma PU. Assim, as TUs podem ser maiores ou menores que uma PU. Para a intracodificação, uma PU pode ser colocada com uma TU de folha correspondentes para a mesma CU. Em alguns exemplos, o tamanho máximo de uma TU de folha pode corresponder ao tamanho da CU de folha correspondente.

[0147] Além do mais, as TUs de Cus de folha também podem estar associadas às respectivas estruturas de dados de árvore quadrática, denominadas como árvores quadráticas residuais (RQTs). Ou seja, uma CU de folha pode incluir uma árvore quadrática que indica como a CU de folha é particionada em TUs. O nó de raiz de uma árvore quadrática de TU corresponde geralmente a uma CU de folha, enquanto o nó de raiz de uma árvore quadrática de CU corresponde geralmente a um bloco de árvore (ou LCU). As TUs da RQT que não são divididas são denominadas como Tus de folha. Em geral, esta revelação usa os termos CU e TU para se referir à CU de folha e à TU de folha, respectivamente, a não ser que indicado de outra forma.

[0148] Uma sequência de vídeo inclui tipicamente uma série de quadros ou figurações de vídeo. Um grupo de figurações (GOP) geralmente compreende uma série de uma ou mais das figurações de vídeo. Um GOP pode incluir dados de sintaxe em um cabeçalho do GOP, um cabeçalho de uma ou mais das figurações ou, em outro lugar, que descreve uma certa quantidade de figurações incluídas no GOP. Cada fatia de uma figuração pode incluir uma fatia de dados de sintaxe que descreva um modo de criptação para a respectiva fatia. O criptador de vídeo 20 opera tipicamente em blocos de vídeo dentro de fatias de vídeo individuais a fim de criptar os dados de vídeo. Um bloco de vídeo pode corresponder a um nó de codificação dentro de uma CU. Os blocos de vídeo podem ter tamanhos fixos ou variados e podem diferir em tamanho de acordo com um padrão de codificação especificado.

[0149] Como exemplo, o HM sustenta uma previsão em vários tamanhos de PU. Presumindo-se que o tamanho de uma CU particular seja 2Nx2N, o HM sustenta intrapredição em tamanhos de PU de 2Nx2N ou xN e interpredição em tamanhos simétricos de PU de 2Nx2N, 2NxN, Nx2N ou NxN. O HM também sustenta um particionamento assimétrico para interpredição em tamanhos de PU de 2NxnU, 2NxnD, nLx2N e nRx2N. No particionamento assimétrico, uma direção de uma CU não é particionada, enquanto a outra direção é particionada em 25% e 75%. A porção da CU correspondente aos 25% de partição é indicada por um “n” seguida por uma indicação de “Cima”, “Baixo”, “Esquerda” ou “Direita”. Dessa forma, por exemplo, “2NxnU” se refere a uma CU de 2Nx2N que é particionada horizontalmente com uma PU de 2Nx0,5N no topo e uma PU de 2Nxl,5N no fundo.

[0150] Nesta revelação, “NxN” e “N por N” podem ser usados de modo intercambiável para se referir às dimensões de pixel de um bloco de vídeo em termos de 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). De modo semelhante, um bloco NxN geralmente tem N pixels em uma direção vertical e N pixels em uma direção horizontal, em que N representa um valor de número inteiro não negativo. Os pixels em um bloco podem ser representados em fileiras e colunas. Além disso, os blocos não têm necessariamente a mesma quantidade de pixels tanto na direção horizontal quanto na direção vertical. Por exemplo, os blocos podem compreender pixels de NxM, em que M não é necessariamente igual a N.

[0151] Após a codificação intrapreditiva ou interpreditiva com o uso das PUs de uma CU, o criptador de vídeo 20 pode calcular dados residuais para as TUs da CU. As PUs podem compreender dados de sintaxe que descrevem um método ou modo de geração de dados de pixel preditivos no domínio espacial (também referido como o domínio de pixels) e as TUs podem compreender coeficientes no domínio de transformada após a aplicação de uma transformada, por exemplo, uma transformada de cosseno discreta (DCT), uma transformada de número inteiro, uma transformada de ondaleta ou uma transformada conceitualmente similar de dados de vídeo residuais. Os dados residuais podem corresponder a diferenças de pixel entre pixels da gravura não codificada e valores de previsão correspondentes às PUs. O codificador de vídeo 20 podem formar as TUs incluindo os dados residuais para a CU, e, então, transformar as TUs para produzir o coeficiente de transformada para a CU.

[0152] Após quaisquer transformações para produzir o coeficiente de transformada, o codificador de vídeo 20 pode realizar a quantização do coeficiente de transformada. A quantização, em geral, se refere a um processo no qual os coeficientes de transformada são quantizados para reduzir possivelmente a quantidade de dados usados para representar os coeficientes, fornecendo compressão adicional. O processo de quantização pode reduzir a profundidade de bit associada a alguns ou todos os coeficientes. Por exemplo, um valor de n bits pode ser arredondado para baixo para um valor de m bits durante a quantização, em que n é maior que m.

[0153] Após a quantização, o encriptador de vídeo pode realizar a varredura dos coeficientes de transformada, o que produz um vetor unidimensional a partir da matriz bidimensional que inclui coeficientes de transformada quantizados. A varredura pode ser projetada para aplicar coeficientes de energia mais alta (e, portanto, de frequência mais baixa) na frente do arranjo e para aplicar coeficientes de energia mais baixa (e, portanto, frequência mais alta) no verso da matriz. Em alguns exemplos, o codificador de vídeo 20 pode utilizar uma ordem de varredura predefinida para varrer o coeficiente de transformada quantizado para produzir o vetor serializado que pode ser codificado por entropia. Em outros exemplos, o criptador de vídeo 20 pode realizar uma varredura adaptativa. Após varrer o coeficiente de transformada quantizado para formar um vetor monodimensional, o codificador de vídeo 20 pode codificar por entropia o vetor monodimensional, por exemplo, de acordo com a codificação de comprimento variável adaptativa a contexto (CAVLC), codificação aritmética binária adaptativa a contexto (CABAC), codificação aritmética binária adaptativa a contexto com base em sintaxe (SBAC), codificação por Entropia de Particionamento de Intervalo de Probabilidade (PIPE) ou outra metodologia de codificação de entropia. O criptógrafo de vídeo 20 também pode criptar por entropia elementos de sintaxe associados aos dados de vídeo codificados para uso pelo decodificador de vídeo 30 na decodificação dos dados de vídeo.

[0154] Para realizar a CABAC, o criptógrafo de vídeo 20 pode atribuir um contexto dentro de um modelo de contexto a um símbolo a ser transmitido. O contexto pode se relacionar a, por exemplo, se valores vizinhos do símbolo são diferentes de zero ou não. para realizar a CAVLC, o criptador de vídeo 20 pode selecionar um código de comprimento variável para um símbolo a ser transmitido. As palavras-código em VLC podem ser construídas de modo que os códigos relativamente mais curtos correspondam a mais símbolos prováveis, enquanto códigos mais longos correspondem a símbolos menos prováveis. Desse modo, o uso de VLC pode conseguir uma economia de bits sobre, por exemplo, o uso de palavras-código de comprimento igual para cada símbolo a ser transmitido. A determinação de probabilidade pode ter base em um contexto atribuído ao símbolo.

[0155] Esta revelação descreve técnicas para a condução de fluxos de bits de extensão de HEVC. Ou seja, de acordo com as técnicas desta revelação, o multiplexador 21 e/ou demultiplexador 29 podem ser configurados para transportar dados de vídeo (ou seja, enviar ou receber dados de vídeo) que são codificados de acordo com uma extensão de um padrão de codificação de vídeo, como HEVC, uma extensão do padrão de HEVC (por exemplo, SHVC ou MV- HEVC), ou outros padrões de codificação de vídeo ainda não desenvolvidos. Em geral, multiplexador 21 pode encapsular dados de vídeo criptados para formar um fluxo de bits, por exemplo, substancialmente de acordo com sistemas de MPEG-2 e as técnicas desta revelação, enquanto o demultiplexador 29 pode receber e descapsular dados encapsulados, por exemplo, dados de vídeo criptados de acordo com uma extensão de um padrão de codificação de vídeo, tal como HEVC.

[0156] Em alguns exemplos, o multiplexador 21 e o demultiplexador 29 podem ser configurados para codificar uma versão revisada do descritor de ponto de operação da Tabela Amd7-1, como discutido acima. A tabela abaixo, rotulada “Tabela Proposta Amd7-1— Descritor de Ponto de Operação de HEVC”, representa um exemplo de modificações para a Tabela atual Amd7-1. O descritor de ponto de operação de HEVC descrito a seguir pode ser usado para realizar certas técnicas nesta revelação. O texto em itálico na tabela abaixo enfatiza as adições relativas à Tabela Amd7-1 atual, conforme mostrado acima.TABELA AMD7-1 PROPOSTA - DESCRITOR DE PONTO DE OPERAÇÃO DE HEVC

[0157] Semânticas exemplificadoras para os elementos de sintaxe adicionados dessa tabela são descritas a seguir. Semânticas para os outros elementos de sintaxe podem permanecer iguais como em L-HEVC TS.

[0158] num_profile_tier_level - Um campo de 8 bits que especifica o número de estruturas de perfil, categoria e nível sinalizadas nesse descritor.

[0159] profile_space[ptlldx],tier_flag[ptlldx], profile_idc[ptlldx], profile_compatibility_indication[ptlldx], progressive_source_flag[ptlldx], interlaced_source_flag[ptlldx], non_packed_constraint_flag[ptlldx], frame_only_constraint_flag[ptlldx], reserved_zero_44bits[ptlldx], level_idc_[ptlldx] - Esses campos devem ser codificados de acordo com as semânticas definidas em Rec. ITU-T H.265 | ISO/IEC 23008-2 for general _profile_space, general jtier_flag, general _profile_idc, general _profile_compatibility_flag[i], general _progressive_source_flag, general _interlaced_source_flag, general _non _packed_constraint Jag, general _frame_only_constraint Jag, general _reserved_zero_44bits, level Jdc, respectivamente, para camadas de pontos de operação descritos dentro desse descritor.

[0160] O valor de ptlldx e opldx são ambos inicializados para iguais a 0 para o primeiro ponto de operação de HEVC de um programa.

[0161] num_operation_points - Esse campo de 8 bits indica o número de pontos de operação descritos nesse descritor.

[0162] target_ols[opldx] - Um campo de 8 bits que especifica o conjunto de camadas de saída associado ao opldx -ésimo ponto de operação definido nesse descritor.

[0163] target_partitioning_scheme[opIdx] – Um campo de 8 bits que especifica o esquema de particionamento do conjunto de camadas de saída associado ao opldx -ésimo ponto de operação definido nesse descritor.

[0164] max_temporal_id[opldx] - Um campo de 3 bits que especifica o TemporalId mais alto das unidades de NAL pertence ao opldx-ésimo ponto de operação definido nesse descritor.

[0165] es_count[opIdx] - Um campo de 8 bits que especifica o número de valores de es_reference incluídos no seguinte grupo de elemento de dados. A agregação de fluxos elementares, de acordo com a lista ordenada no seguinte grupo de elementos de dados, forma um ponto de operação de HEVC. O valor Oxff é reservado.

[0166] prepend_dependencies[opIdx] [j] - Um sinalizador de 1-bit que quando é ajustado para 1 indica que o fluxo elementar sinalizado pelo elemento de sintaxe hierarchy_embedded_layer_index no descritor de hierarquia e descritor de extensão de hierarquia com o valor de índice de camada de hierarquia especificado pelo seguinte elemento de sintaxe element_es_reference[opIdx][j] deve ser adicionado à lista de fluxos elementares para o ponto de operação alvo antes do fluxo elementar sinalizado pelo es_reference[opIdx][j]. Se o fluxo elementar sinalizado por hierarchy_embedded_layer_index tiver dependências adicionais sinalizadas por descritores de hierarquia, essas dependências devem ser adicionadas à lista ES de maneira recursiva. Quando não há descritor de hierarquia e descritores de extensão de hierarquia presentes para qualquer fluxo elementar referido pelo elemento de sintaxe ES_reference[opIdx][j], o valor de prepend_dependencies[opIdx][j] não deve ser igual a 1.

[0167] ES_reference[opIdx] [j] - Um campo de 6 bits que especifica o valor de índice de camada de hierarquia presente no descritor de hierarquia que identifica um fluxo elementar.

[0168] num_target_output_layers[opIdx] - Esse campo de 6 bits especifica o valor do número de camadas, destinado para saída para o optldx-ésimo ponto de operação definido nesse descritor.

[0169] num_layers[opIdx] - Um campo de 6 bits que especifica o número de camadas incluídas no optldx- ésimo ponto de operação definido nesse descritor.

[0170] output_layer_flag[opIdx] [j] - Um campo de 1 bit quando atribui-se um valor T indica que a j-ésima camada do opldx-ésimo ponto de operação definido nesse descritor é uma camada de saída. De outro modo, quando atribui-se um valor ‘O’, isso indica que a j-ésima camada do opldx-ésimo ponto de operação definido nesse descritor não é uma camada de saída.

[0171] ptl_ref_idx[opIdx] [j] - Um campo de 8 bits que especifica o índice para o perfil, categoria e nível que é atribuído à j-ésima camada do optldx-ésimo ponto de operação definido nesse descritor.

[0172] constant_frame_rate_info_idc[opIdx] -Um campo de 2 bits, em combinação com o indicador de taxa de quadros de elemento de sintaxe conforme especificado abaixo, que especifica como a taxa de quadros para o opldx- ésimo ponto de operação associado definido nesse descritor é determinada. O valor de 0 indica que a taxa de quadros não é especificada para o ponto de operação e que o indicador de taxa de quadros de elemento de sintaxe não está presente nesse descriptor para o ponto de operação.

[0173] frame_rate_indicator[opIdx] – Se constant_frame_rate_info_idc[opIdx] for igual a 1, esse campo de 12 bits indica um número constante de tiques, conforme especificado na temporização de HEVC e descritor de HRD, para a distância em tempo entre duas imagens no i- ésimo ponto de operação definido nesse descritor. Ainda se constant_frame_rate_info_idc[opIdx] for igual a 2, esse campo de 12 bits indica a taxa de quadros para o ponto de operação medido em quadros por segundo. Ainda se constant_frame_rate_info_idc[opIdx] for igual a 3, esse campo de 12 bits indica a taxa de quadros para o ponto de operação medido em quadros por 1,001 segundo.

[0174] Dessa forma, um descritor de acordo com a Tabela Proposta Amd7-1 representa um exemplo de um descritor que inclui um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de gPTL correspondentes. Ou seja, os elementos citados no loop “para ( i = 0; i < num_profile_tier_level; i++, ptlldx++ )” representam um exemplo de um conjunto de estruturas de perfil, categoria e nível (PTL), enquanto os elementos citados no loop “para ( j = 0; j < num_layers[opIdx]; j++ )” representam exemplos de dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de PTL correspondentes.

[0175] Um descritor de acordo com a Tabela Proposta Amd7-1 também representa um exemplo de um descritor que inclui valores para elementos de sintaxe de conjunto de camadas de saída alvo para cada um dos pontos de operação, em que os elementos de sintaxe de conjunto de camadas de saída alvo especificam os conjuntos de camadas de saída alvo associados aos pontos de operação correspondentes. Ou seja, os elementos de sintaxe target_ols[opIdx] representam exemplos de valores para elementos de sintaxe de conjunto de camadas de saída alvo para cada um dos pontos de operação, pois esses valores especificam os conjuntos de camadas de saída alvo associados aos pontos de operação correspondentes.

[0176] Consequentemente, o demultiplexador 29 pode extrair o descritor do fluxo de bits para determinar as estruturas de PTL para cada ponto de operação do fluxo de bits. Ou seja, o demultiplexador 29 pode extrair dados dentro de cada um dentre “para( i = 0; i < num_profile_tier_level; i++, ptlldx++ )”, como os elementos de sintaxe profile_idc[ptlIdx], tier_flag[ptlldx], e level_idc[ptlldx], para determinar vários conjuntos de informações de perfil, categoria e nível. Cada um desses conjuntos pode corresponder a uma única estrutura de dados de PTL, que o demultiplexador 29 pode instanciar, indexada em ordem. O demultiplexador 29 pode iterar adicionalmente através de cada camada de cada ponto de operação e determinar qual das estruturas de dados de PTL corresponde a cada camada de cada ponto de operação com base no elemento de sintaxe ptl_ref_idx[opIdx][j]. Ou seja, “opldx” representa um índice para um ponto de operação, e “j” representa um índice para uma camada do ponto de operação. Dessa forma, o valor do elemento de sintaxe ptl_ref_idx[opIdx][j] representa uma das estrutura de dados de PTL à qual a jésima camada do opldxésimo ponto de operação corresponde.

[0177] Além disso, o demultiplexador 29 pode determinar um conjunto de camadas de saída alvo para cada um dos pontos de operação. Ou seja, para cada um dos pontos de operação, o demultiplexador 29 pode recuperar um valor para target_ols[opIdx], que representa o conjunto de camadas de saída alvo para o ponto de operação representado por “opldx”.

[0178] Esta revelação também descreve exemplos em que um descritor de hierarquia e um descritor de extensão de hierarquia que podem ser usados para sinalizar dados para uma camada de HEVC (fluxo elementar), como descrever a dependência (possivelmente dependência de camadas). Por exemplo, o descritor de hierarquia e o descritor de extensão de hierarquia, desta revelação, podem ser diferentes de descritores de hierarquia existentes e descritores de extensão de hierarquia. Consequentemente, quando esta revelação usa o termo “descritor de extensão de hierarquia” ou “descritor de hierarquia”, a revelação está se referindo a versões atualizadas de tais descritores, a menos que esteja evidente a partir da descrição que a versão anterior de tais descritores está sendo referenciada. Em alguns exemplos, cada um ou tanto o descritor de extensão de hierarquia como o descritor de hierarquia podem ser integrados com o descritor de ponto de operação de HEVC da Tabela Proposta Amd7-1, conforme discutido acima.

[0179] Consequentemente, o demultiplexador 29 pode ser configurado para determinar dependências entre fluxos elementares que usam, por exemplo, o descritor de hierarquia e/ou o descritor de extensão de hierarquia, conforme discutido acima.

[0180] O multiplexador 21 pode ser configurado para formar o descritor de ponto de operação de HEVC, o descritor de hierarquia e/ou o descritor de extensão de hierarquia, enquanto o demultiplexador 29 pode usar o descritor de ponto de operação de HEVC, o descritor de hierarquia e/ou o descritor de extensão de hierarquia para processar dados de vídeo recebidos, por exemplo, para montar os dados de vídeo em uma forma que possa ser usada pelo decodificador de vídeo 30. Embora não seja mostrado no exemplo da Figura 1, um dispositivo intermediário também pode usar esses descritores, por exemplo, para realizar a extração de subfluxo de bits. Por exemplo, um elemento de rede com suporte de mídia (MANE) pode executar a extração de subfluxo de bits usando o descritor de ponto de operação de HEVC, o descritor de hierarquia, e/ou descritor de extensão de hierarquia.

[0181] O multiplexador 21, demultiplexador 29, criptador de vídeo 20 e o decodificador de vídeo 30, podem ser, cada um, implantados como qualquer um dentre uma variedade de conjunto de circuitos de criptador ou decodificador adequado, conforme aplicável, tal como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), matrizes de porta programáveis por campo (FPGAs), conjunto de circuitos lógico discreto, software, hardware, firmware ou quaisquer combinações dos mesmos. Cada um dentre o criptador de vídeo 20 e o decodificador de vídeo 30 pode estar incluído em um ou mais criptadores ou decodificadores, um dos quais pode ser integrado como parte de um criptador/decodificador (CODEC) de vídeo combinado. Um dispositivo que inclui o criptador de vídeo 20 e/ou o decodificador de vídeo 30 pode compreender um circuito integrado, um microprocessador e/ou um dispositivo de comunicação sem fio, como um telefone celular.

[0182] Dessa maneira, o demultiplexador 29 representa um exemplo de um dispositivo que inclui uma memória para armazenar dados extraídos do fluxo de bits e uma ou mais unidades de processamento configuradas para extrair um descritor do fluxo de bits, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separado do descritor, de modo que cada ponto de operação inclua uma ou mais camadas de dados de vídeo, e em que o descritor inclua um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de PTL correspondentes, extrair dados de vídeo para um dos pontos de operação do fluxo de bits com base pelo menos em parte nas estruturas de PTL às quais as camadas de um ou mais pontos de operação correspondem, e fornecer os dados de vídeo extraídos a um decodificador de vídeo.

[0183] A Figura 2 é um diagrama de blocos que ilustra um exemplo de criptador de vídeo 20 que pode implantar técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo. Os dados de vídeo podem incluir múltiplas (por exemplo, duas ou mais) camadas de aprimoramento a uma camada de base, em que as camadas de aprimoramento podem corresponder a diferentes dimensões de escalabilidade. O criptador de vídeo 20 pode realizar intra e intercodificação de blocos de vídeo dentro de fatias de vídeo. A intracodificação tem base na previsão espacial para reduzir ou remover a redundância espacial no vídeo dentro de um dado quadro ou figuração de vídeo. A intercodificação consiste em previsão temporal ou entre camadas para reduzir ou remover a redundância em vídeo dentro de quadros ou imagens de uma sequência de vídeo ou de uma camada de referência (por exemplo, uma vista de referência). O intramodo (modo I) pode se referir a qualquer um dentre vários modos de codificação com base em espaço. Os intermodos, como previsão monodirecional (modo P) ou biprevisão (modo B), podem se referir a qualquer um dentre vários modos de codificação com base em tempo.

[0184] Conforme mostrado na Figura 2, o codificador de vídeo 20 recebe um bloco de vídeo atual dentro de um quadro de vídeo a ser criptado. No exemplo da Figura 2, o codificador de vídeo 20 inclui a unidade de seleção de modo 40, a memória de imagem de referência 64, somador 50, a unidade de processamento de transformada 52, a unidade de quantização 54 e a unidade de codificação por entropia 56. A unidade de seleção de modo 40, por sua vez, inclui a unidade de compensação de modo 44, a unidade de estimativa de movimento 42, a unidade de intrapredição 46 e a unidade de partição 48. Para o bloco de vídeo reconstrução, o codificador de vídeo 20 também inclui a unidade de quantização inversa 58, a unidade de transformada inversa 60 e o somador 62. Um filtro de desbloqueio (não mostrado na Figura 2) também pode ser incluído para filtrar os limites do bloco para remover artefatos de característica de bloqueio de vídeo reconstruído. Caso desejado, o filtro de desbloqueio pode filtrar tipicamente o resultado do somador 62. Filtros adicionais (em circuito ou pós-circuito) também podem ser usados adicionalmente ao filtro de desbloqueio. Tais filtros não são mostrados para propósitos de brevidade, mas caso desejado, podem filtrar o resultado do somador 50 (como um filtro em circuito).

[0185] Durante o processo de codificação, o codificador de vídeo 20 recebe um quadro ou fatia de vídeo a ser codificado. O quadro ou fatia pode ser dividido em múltiplos blocos de vídeo. A unidade de estimativa de movimento 42 e a unidade de compensação de movimento 44 realizam codificação interpreditiva do bloco de vídeo recebido em relação a um ou mais blocos em um ou mais quadros de referência para fornecer previsão temporal. A unidade de intrapredição 46 pode realizar de modo alternativo a codificação intrapreditiva do bloco de vídeo recebido em relação a um ou mais blocos vizinhos no mesmo quadro ou fatia que o bloco a ser codificado para fornecer previsão espacial. O codificador de vídeo 20 pode realizar múltiplos passos de codificação, por exemplo, para selecionar um modo de codificação apropriado para cada bloco de dados de vídeo.

[0186] Além do mais, a unidade de partição 48 pode particionar blocos de dados de vídeo em sub-blocos, com base na avaliação de esquemas de particionamento anteriores em passos de codificação anteriores. Por exemplo, a unidade de partição 48 pode particionar inicialmente um quadro ou fatia em LCUs, e particionar cada uma das LCUs em sub-CUs com base na análise de distorção de taxa (por exemplo, otimização de distorção de taxa). A unidade de seleção de modo 40 pode produzir adicionalmente uma estrutura de dados de árvore quadrática que indica a partição de uma LCU em sub-CUs. As CUs de nó-folha da árvore quadrática podem incluir uma ou mais PUs e uma ou mais TUs.

[0187] A unidade de seleção de modo 40 pode selecionar um dos modos de codificação, intra ou inter, por exemplo, com base em resultados de erro e fornece o bloco intra ou interprevisto resultante para o somador 50 para gerar dados de bloco residuais e para o somador 62 para reconstruir o bloco criptado para uso em um quadro de referência. A unidade de seleção de modo 40 também fornece elementos de sintaxe, como vetores de movimento, indicadores de intramodo, informações de partição e outras tais informações de sintaxe, para a unidade de criptação por entropia 56.

[0188] A unidade de estimativa de movimento 42 e a unidade de compensação de movimento 44 podem ser altamente integradas, mas são ilustradas separadamente para propósitos conceituais. A estimativa de movimento, realizada pela unidade de estimativa de movimento 42, é o processo de geração de vetores de movimento, que estima o movimento para blocos de vídeo. Um vetor de movimento, por exemplo, pode indicar o deslocamento de uma PU de um bloco de vídeo dentro de um quadro ou imagem de vídeo atual em relação a um bloco preditivo dentro de um quadro de referência (ou outra unidade codificada) em relação ao bloco atual que está codificado dentro do quadro atual (ou outra unidade codificada). Um bloco preditivo é um bloco que se encontra em correspondência muito próxima ao bloco a ser codificado, em termos de diferença de pixels, que pode ser determinado pelo somatório da diferença absoluta (SAD), somatório da diferença quadrada (SSD) ou outras medidas de diferença. Em alguns exemplos, o criptador de vídeo pode calcular valores para posições de pixel subnúmero inteiro de imagens de referência armazenadas na memória de imagem de referência 64. Por exemplo, o criptador de vídeo 20 pode interpolar valores de posições de um quarto de pixel, posições de um oitavo de pixel ou outras posições fracionadas de pixel da imagem de referência. Portanto, a unidade de estimativa de movimento 42 pode realizar uma busca de movimento em relação a todas as posições de pixel e posições fracionadas de pixel e emitir um vetor de movimento com precisão fracionada de pixel.

[0189] A unidade de estimativa de movimento 42 calcula um vetor de movimento para uma PU de um bloco de vídeo em uma fatia intercodificada pela comparação da posição da PU em relação à posição de um bloco preditivo de uma imagem de referência. A imagem de referência pode ser selecionada a partir de uma primeira lista de imagem de referência (Lista 0) ou uma segunda lista de imagem de referência (Lista 1), cada uma das quais identifica uma ou mais imagens de referência armazenadas na memória de quadro de referência 64. A unidade de estimativa de movimento 42 envia o vetor de movimento calculado para a unidade de criptação por entropia 56 e a unidade de compensação de movimento 44.

[0190] A compensação de movimento, realizada pela unidade de compensação de movimento 44, pode envolver obter ou gerar o bloco preditivo com base no vetor de movimento determinado pela unidade de estimativa de movimento 42. Novamente, a unidade de estimativa de movimento 42 e a unidade de compensação de movimento 44 podem ser integradas de modo funcional, em alguns exemplos. Mediante o recebimento do vetor de movimento para a PU do bloco de vídeo atual, a unidade de compensação de modo 44 pode localizar o bloco preditivo para o qual o vetor de movimento aponta em uma das listas de imagens de referência. O somador 50 forma um bloco de vídeo residual subtraindo-se valores de pixel do bloco preditivo dos valores de pixel do bloco de vídeo atual que está codificado, o que forma a diferença de valores de pixels, conforme discutido abaixo. Em geral, a unidade de estimativa de movimento 42 realiza a estimativa de movimento em relação aos componentes de luma, e a unidade de compensação de movimento 44 usa vetores de movimento calculados com base nos componentes de luma tanto para os componentes de croma quanto para os componentes de luma. A unidade de seleção de modo 40 também pode gerar elementos de sintaxe associados aos blocos de vídeo e à fatia de vídeo para uso pelo decodificador de vídeo 30 na decodificação dos blocos de vídeo da fatia de vídeo.

[0191] Alternativamente, a unidade de estimativa de movimento 42 pode realizar previsão entre camadas (por exemplo, entrevista) para um bloco de uma imagem em uma camada dependente. Por exemplo, a unidade de estimativa de movimento 42 pode ser configurada para calcular um vetor de movimento de disparidade ao realizar previsão entre vistas de uma imagem em uma vista dependente. Em outros exemplos, a unidade de compensação de movimento 44 pode realizar previsão de vetor sem movimento de um bloco ao realizar previsão entre camadas, por exemplo, quando uma camada de aprimoramento corresponde a uma dimensão de escalabilidade para a qual os blocos na camada de aprimoramento são posicionados ao mesmo tempo ou substancialmente a mesma posição que os blocos na camada de base que é aprimorada. Tais dimensões de escalabilidade podem incluir, por exemplo, profundidade de bit de croma, formato de cor, gama de cores, PSNR ou similares.

[0192] A unidade de intrapredição 46 pode intraprever ou calcular um bloco atual, como uma alternativa à interpredição realizada pela unidade de estimativa de movimento 42 e a unidade de compensação de movimento 44, conforme descrito acima. Em particular, a unidade de intrapredição 46 pode determinar um modo de intrapredição para usar para criptar um bloco atual. Em alguns exemplos, a unidade de intrapredição 46 pode codificar um bloco atual com o uso de vários modos de intrapredição, por exemplo, durante passos de codificação separados, e a unidade de intrapredição 46 (ou unidade de seleção de modo 40, em alguns exemplos) pode selecionar um modo de intrapredição apropriado para usar a partir dos modos testados.

[0193] Por exemplo, a unidade de intrapredição 46 pode calcular valores de distorção de taxa com o uso de uma análise de distorção de taxa para os vários modos de intrapredição testados, e selecionar o modo de intrapredição que tem as melhores características de distorção de taxa entre os modos testados. A análise de distorção de taxa geralmente determina uma quantidade de distorção (ou erro) entre um bloco criptado e um bloco original não criptado que foi criptado para produzir o bloco criptado, bem como uma taxa de bits (isto é, vários bits) usados para produzir o bloco criptado. A unidade de intrapredição 46 pode calcular razões a partir de distorções e taxas para os vários blocos criptados para determinar qual modo de intrapredição exibe o melhor valor de distorção de taxa para o bloco.

[0194] Após selecionar um modo de intrapredição para um bloco, a unidade de intrapredição 46 pode fornecer informações que indicam o modo de intrapredição selecionado para o bloco em relação à unidade de codificação por entropia 56. A unidade de codificação por entropia 56 pode codificar as informações que indicam o modo de intrapredição selecionado. O criptador de vídeo 20 pode incluir nos dados de configuração de fluxo de bits transmitidos, que podem incluir uma pluralidade de tabelas de índices de modo de intrapredição e uma pluralidade de tabelas de índices de modo de intrapredição modificados (também chamadas de tabelas de mapeamento de palavras- código), as definições de criptação de contextos para vários blocos, e indicações de um modo de intrapredição mais provável, uma tabela de índices de modo de intrapredição e uma tabela de índices de modo de intrapredição modificados para usar para cada um dos contextos.

[0195] O criptador de vídeo 20 forma um bloco de vídeo residual subtraindo-se os dados de previsão da unidade de seleção de modo 41 a partir do bloco de vídeo original que está codificado. O somador 50 representa o componente ou os componentes que realizam essa operação de subtração. A unidade de processamento de transformada 52 aplica uma transformada, como uma transformada de cosseno discreta (DCT) ou uma transformada conceitualmente similar, ao bloco residual, o que produz um bloco de vídeo que compreende valores de coeficiente de transformada residuais. A unidade de processamento de transformada 52 pode realizar outras transformadas que sejam conceitualmente similares à DCT. As transformadas de ondaleta, transformadas de números inteiros, transformadas de subfaixa ou outros tipos de transformadas também podem ser usadas.

[0196] Em todo caso, a unidade de processamento de transformada 52 aplica a transformada ao bloco residual, produzindo um bloco de coeficiente de transformada residual. A transformada pode converter as informações residuais provenientes de um domínio de valor de pixel para um domínio de transformada, tal como um domínio de frequência. A unidade de processamento de transformada 52 pode enviar coeficientes de transformada resultantes para a unidade de quantização 54. A unidade de quantização 54 quantiza os coeficientes de transformada para reduzir ainda mais a taxa de bits. O processo de quantização pode reduzir a profundidade de bits associada a alguns ou todos os coeficientes. O processo de quantização também pode ser chamado de processo de “escalonamento”, e portanto, os coeficientes de transformada quantizados podem ser chamados de “coeficientes de transformada escalonados”. O grau de quantização (ou escalonamento) pode ser modificado ajustando-se um parâmetro de quantização. Em alguns exemplos, a unidade criptação de entropia 56, pode, então, realizar uma varredura da matriz, que inclui coeficientes de transformada quantizados.

[0197] Após a quantização, a unidade de criptação por entropia 56 codifica por entropia os coeficientes de transformada quantizados submetidos a varredura. Por exemplo, uma unidade de codificação por entropia 56 pode realizar codificação de comprimento variável adaptativa a contexto (CAVLC), codificação aritmética binária adaptativa a contexto (CABAC), codificação aritmética binária adaptativa a contexto com base em sintaxe (SBAC), codificação por Entropia de partição de Intervalo de Probabilidade (PIPE) ou outra metodologia de codificação por entropia. No caso de codificação por entropia com base em contexto, o contexto pode ter base em blocos vizinhos. Após a codificação por entropia pela unidade de codificação por entropia 56, o fluxo de bits codificado pode ser transmitido para outro dispositivo (por exemplo, o decodificador de vídeo 30) ou arquivado para transmissão ou recuperação posterior.

[0198] A unidade de quantização inversa 58 e a unidade de transformada inversa 60 aplicam quantização inversa e transformada inversa, respectivamente, para reconstruir o bloco residual no domínio de pixels, por exemplo, para uso posterior como um bloco de referência. A unidade de compensação de movimento 44 pode calcular um bloco de referência adicionando-se o bloco residual a um bloco de previsão de um dos quadros de memória de imagem de referência 64. A unidade de compensação de movimento 44 também pode aplicar um ou mais filtros de interpolação ao bloco residual reconstruído para calcular valores de pixel de subnúmeros inteiros para uso na estimativa de movimento. O somador 62 adiciona o bloco residual reconstruído ao bloco de previsão compensado de movimento produzido pela unidade de compensação de modo 44 para produzir um bloco de vídeo reconstruído para o armazenamento na memória de imagem de referência 64. O bloco de vídeo reconstruído pode ser usado pela unidade de estimativa de movimento 42 e pela unidade de compensação de movimento 44 como um bloco de referência para intercodificar um bloco em um quadro de vídeo subsequente.

[0199] A Figura 3 é um diagrama de blocos que ilustra um exemplo de decodificador de vídeo 30 que pode implantar técnicas para transportar dados de vídeo codificados de acordo com extensões de um padrão de codificação de vídeo. No exemplo da Figura 3, o decodificador de vídeo 30 inclui uma unidade de decodificação e entropia 70, uma unidade de compensação de modo 72, uma unidade de intrapredição 74, uma unidade de quantização inversa 76, uma unidade de transformada inversa 78, uma memória de imagem de referência 82 e um somador 80. O decodificador de vídeo 30 pode, em alguns exemplos, realizar um passo de decodificação geralmente recíproco ao passo de criptação descrito em relação ao criptador de vídeo 20 (Figura 2). A unidade de compensação de movimento 72 pode gerar dados de previsão com base em vetores de movimento recebidos a partir da unidade de decodificação e entropia 70, enquanto a unidade de intrapredição 74 pode gerar dados de previsão com base em indicadores de modo de intrapredição recebidos a partir da unidade de decodificação e entropia 70.

[0200] Durante o processo de decodificação, o decodificador de vídeo 30 recebe um fluxo de bits de vídeo codificado que representa blocos de vídeo de uma fatia de vídeo codificada e elementos de sintaxe associados provenientes do codificador de vídeo 20. A unidade de decodificação de entropia 70 do decodificador de vídeo 30 decodifica por entropia o fluxo de bits para gerar coeficientes quantizados, vetores de movimento ou indicadores de modo de intrapredição e outros elementos de sintaxe. A unidade de decodificação por entropia 70 encaminha os vetores de movimento e outros elementos de sintaxe para a unidade de compensação de movimento 72. O decodificador de vídeo 30 pode receber os elementos de sintaxe no nível de fatia de vídeo e/ou no nível de bloco de vídeo.

[0201] Quando a fatia de vídeo for codificada como uma fatia intracodificada (I), a unidade de intrapredição 74 pode gerar dados de previsão para um bloco de vídeo da fatia de vídeo atual com base em um modo de intrapredição sinalizado e dados provenientes de blocos decodificados anteriormente do quadro ou gravura atual. Quando o quadro de vídeo for codificado como uma fatia intercodificada (isto é, B ou P), a unidade de compensação de movimento 72 produz blocos preditivos para um bloco de vídeo da fatia de vídeo atual com base nos vetores de movimento e outros elementos de sintaxe recebidos a partir da unidade de decodificação por entropia 70. Os blocos preditivos podem ser produzidos a partir de uma das figurações de referência dentro de uma das listas de figurações de referência. O decodificador de vídeo 30 pode construir as listas de quadro de referência, a Lista 0 e a Lista 1, com o uso de técnicas de construção padrão com base em figurações de referência armazenadas na memória de figuração de referência 82.

[0202] A unidade de compensação de movimento 72 determina informações de previsão para um bloco de vídeo da fatia de vídeo atual analisando-se os vetores de movimento e outros elementos de sintaxe, e usa as informações de previsão para produzir os blocos preditivos para o bloco de vídeo atual em decodificação. Por exemplo, a unidade de compensação de modo 72 usa uma parte dos elementos de sintaxe recebidos para determinar um modo de previsão (por exemplo, intra ou interpredição) usado para codificar os blocos de vídeo da fatia de vídeo, um tipo de fatia de interpredição (por exemplo, fatia B ou fatia P), informações de construção para uma ou mais dentre as listas de figurações de referência para a fatia, vetores de movimento para cada bloco de vídeo intercriptado da fatia, situações de interpredição para cada bloco de vídeo intercriptado da fatia e outras informações para decodificar os blocos de vídeo na fatia de vídeo atual.

[0203] A unidade de compensação de movimento 72 também pode realizar interpolação com base em filtros de interpolação. A unidade de compensação de movimento 72 por usar filtros de interpolação conforme usado pelo criptador de vídeo 20 durante a criptação dos blocos de vídeo para calcular valores interpolados para pixels sub-inteiros de blocos de referência. Nesse caso, a unidade de compensação de modo 72 pode determinar os filtros de interpolação usados pelo codificador de vídeo a partir dos elementos de sintaxe recebidos e usar os filtros de interpolação para produzir blocos preditivos.

[0204] Em alguns exemplos, a unidade de compensação de movimento 72 pode realizar previsão de vetor sem movimento de um bloco ao realizar previsão entre camadas, por exemplo, quando uma camada de aprimoramento corresponde a uma dimensão de escalabilidade para a qual blocos na camada de aprimoramento são posicionados na mesma ou substancialmente na mesma posição como blocos na camada de base que é aprimorada Tais dimensões de escalabilidade podem incluir, por exemplo, profundidade de bit de croma, formato de cor, gama de cores, PSNR ou similares. Alternativamente, unidade de compensação de movimento 72 pode usar vetores de movimento de disparidade para prever blocos de uma vista dependente de uma ou mais vistas de referência (por exemplo, uma vista de base). Deve-se entender que uma vista é um exemplo de uma camada. Ou seja, quando uma camada de aprimoramento é uma vista, a dimensão de escalabilidade pode corresponder a uma dimensão de vista (por exemplo, para fornecer dados para produzir um efeito tridimensional para um visualizador).

[0205] A unidade de quantização inversa 76 quantiza inversamente, isto é, de-quantiza, os coeficientes de transformada quantizados fornecidos no fluxo de bits e decodificados pela unidade de decodificação por entropia 70. O processo de quantização inversa pode incluir o uso de um parâmetro de quantização QPY calculado pelo decodificador de vídeo 30 para cada bloco de vídeo na fatia de vídeo para determinar um grau de quantização e, de modo similar, um grau de quantização inversa que deve ser aplicado. A unidade de transformada inversa 78 aplica uma transformada inversa, por exemplo, uma DCT inversa, uma transformada de número inteiro inversa ou um processo de transformada inversa conceitualmente similar, ao coeficiente de transformada a fim de produzir blocos residuais no domínio de pixels.

[0206] Após a unidade de compensação de modo 72 gerar o bloco de previsão para o bloco de vídeo atual com base nos vetores de movimento e outros elementos de sintaxe, o decodificador de vídeo 30 forma um bloco de vídeo decodificado somando-se os blocos residuais provenientes da unidade de transformada inversa 78 com os blocos preditivos correspondentes gerados pela unidade de compensação de modo 72. O somador 80 representa o componente ou os componentes que realizam essa operação de soma. Caso desejado, um filtro de desbloqueio também pode ser aplicado para filtrar os blocos decodificados a fim de remover os artefatos de característica de bloqueio. Outros filtros de laço (tanto no laço de codificação quanto após o laço de codificação) também podem ser usados para suavizar as transições de pixel, ou, de outro modo, aprimorar a qualidade de vídeo. Os blocos de vídeo decodificados em um quadro ou gravura dados são, então, armazenados na memória de gravura de referência 82, que armazena gravuras de referência usadas para a composição de movimento subsequente. A memória de imagem de referência 82 também armazena o vídeo decodificado para apresentação posterior em um dispositivo de exibição, como o dispositivo de exibição 32 da Figura 1.

[0207] A Figura 4 é um diagrama de blocos que ilustra um sistema exemplificador 100 no qual o dispositivo de fonte de áudio/vídeo (A/V) 120 transporta dados de áudio e vídeo ao dispositivo de destino de A/V 140. O sistema 100 da Figura 4 pode corresponder a um vídeo sistema de teleconferência, um sistema de servidor/cliente, um sistema de transmissor contínuo/receptor, ou qualquer outro sistema no qual dados de vídeo são enviados de um dispositivo de fonte, tais como dispositivo de fonte de A/V 120, a um dispositivo de destino, tal como dispositivo de destino de A/V 140. Em alguns exemplos, dispositivo de fonte de A/V 120 e dispositivo de destino de A/V 140 pode realizar troca de informações bidirecionais. Ou seja, o dispositivo de fonte de A/V 120 e o dispositivo de destino de A/V 140 pode ter capacidade tanto de criptar quanto de codificar (e transmitir e receber) dados de áudio e vídeo. Em alguns exemplos, o criptador de áudio 126 pode compreender um criptador de voz, também denominado como vocoder.

[0208] O dispositivo de fonte de A/V 120, no exemplo da Figura 4, compreende fonte de áudio 122 e fonte de vídeo 124. A fonte de áudio 122 pode compreender, por exemplo, um microfone que produz sinais elétricos representativos de dados de áudio capturados a serem criptados pelo criptador de áudio 126. Alternativamente, a fonte de áudio 122 pode compreender um meio de armazenamento que armazena dados de áudio anteriormente registrados, um gerador de dados de áudio tais como um sintetizador computadorizado, ou qualquer outra fonte de dados de áudio. A fonte de vídeo 124 pode compreender uma câmera de vídeo que produz dados de vídeo a serem criptados pelo criptador de vídeo 128, um meio de armazenamento criptado com dados de vídeo anteriormente registrados, uma unidade de geração de dados de vídeo, ou qualquer outra fonte de dados de vídeo.

[0209] Dados de áudio e vídeo “brutos” (ou seja, dados capturados ou adquiridos que não foram codificados) podem compreender dados analógicos e digitais. Os dados análogos podem ser digitalizados antes de ser criptados pelo criptador de áudio 126 e/ou criptador de vídeo 128. A fonte de áudio 122 pode obter dados de áudio de um participante falante enquanto o participante falante está falando, e a fonte de vídeo 124 pode obter simultaneamente dados de vídeo do participante falante. Em outros exemplos, a fonte de áudio 122 pode compreender um meio de armazenamento legível por computador que compreende dados de áudio armazenados, e fonte de vídeo 124 pode compreender um meio de armazenamento legível por computador que compreende dados de vídeo armazenados. Dessa maneira, as técnicas descritas nesta revelação podem ser aplicadas a dados de áudio e vídeo ao vivo, streaming, em tempo real ou a dados de áudio e vídeo alcançados pré-registrados.

[0210] Quadros de áudio que correspondem a quadros de vídeo são geralmente quadros de áudio que contém dados de áudio que foram capturados pela fonte de áudio 122 simultaneamente com dados de vídeo capturados pela fonte de vídeo 124 que é contida dentro dos quadros de vídeo. Por exemplo, embora um participante falante geralmente produza dados de áudio falando, a fonte de áudio 122 captura os dados de áudio, e fonte de vídeo 124 captura dados de vídeo do participante falante ao mesmo tempo, ou seja, enquanto a fonte de áudio 122 captura os dados de áudio. Portanto, um quadro de áudio pode corresponder de modo temporal a um ou mais quadros de vídeo particulares. Consequentemente, um quadro de áudio que corresponde a um quadro de vídeo corresponde geralmente 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.

[0211] Em alguns exemplos, criptador de audio 126 pode criptar um carimbo temporal em cada quadro de áudio criptado que representa um tempo no qual os dados de áudio para o quadro de áudio criptado foram registrados e, de modo similar, criptador de vídeo 128 pode criptar um carimbo temporal em cada quadro de vídeo criptado que representa um tempo no qual os dados de vídeo para o quadro de vídeo criptado foram registrados. Em tais exemplos, um quadro de áudio que corresponde a um quadro de vídeo pode compreender um quadro de áudio que compreende um carimbo temporal e um quadro de vídeo que compreende o mesmo carimbo temporal. Dispositivo de fonte de A/V 120 pode incluir um relógio interno do qual o criptador de áudio 126 e/ou criptador de vídeo 128 pode gerar os carimbos temporais, ou essa fonte de áudio 122 e fonte de vídeo 124 podem usar para associar dados de áudio e vídeo, respectivamente, com um carimbo temporal.

[0212] Em alguns exemplos, a fonte de audio 122 pode enviar dados ao criptador de áudio 126 correspondentes a um tempo no qual dados de áudio foram registrados, e a fonte de vídeo 124 pode enviar dados ao criptador de vídeo 128 correspondente a um tempo no qual dados de vídeo foram registrados. Em alguns exemplos, o criptador de áudio 126 pode criptar um identificador de sequência em dados de áudio criptados para indicar uma ordenação temporal relativa de dados de áudio criptados, mas sem indicar necessariamente um tempo absoluto no qual os dados de áudio foram registrados, e de modo similar, o criptador de vídeo 128 também pode usar identificadores de sequência para indicar uma ordenação temporal relativa de dados de vídeo criptados. De modo similar, em alguns exemplos, um identificador de sequência pode ser mapeado ou de outro modo correlacionado a um carimbo temporal.

[0213] As técnicas desta revelação são geralmente direcionadas ao transporte de dados de multimídia criptada (por exemplo, áudio e vídeo), e recepção e interpretação subsequente e decodificação dos dados de multimídia transportados. As técnicas desta revelação são particularmente aplicáveis para transporte de dados de codificação de vídeo de múltiplas vistas (MVC), ou seja, dados de vídeo que compreendem uma pluralidade de vistas. Conforme mostrado no exemplo da Figura 4, a fonte de vídeo 124 pode fornecer uma pluralidade de vistas de um cenário ao criptador de vídeo 128. MVC pode ser útil para gerar dados de vídeo tridimensionais a serem usados por uma exibição tridimensional, tal como uma exibição tridimensional estereoscópica ou autostereoscópica.

[0214] O dispositivo de fonte de A/V 120 pode fornecer um “serviço” ao dispositivo de destino de AV 140. Um serviço corresponde geralmente a um subconjunto de vistas disponíveis de dados de MVC. Por exemplo, dados de MVC podem estar disponíveis para oito vistas, ordenadas de zero a sete. Um serviço pode corresponder a vídeo estéreo que tem duas vistas, enquanto 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 (ou seja, 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 modo que o dispositivo de fonte de A/V 120 possa fornecer adicionalmente um descritor de ponto de operação para cada serviço fornecido por dispositivo de fonte de A/V 120.

[0215] O dispositivo de fonte de A/V 120, de acordo com as técnicas desta revelação, tem capacidade de fornecer serviços que correspondem a um subconjunto de vistas. Em geral, uma vista é representada por um identificador de vista, também denominado como um “view_id”. Identificadores de vista geralmente compreendem elementos de sintaxe que podem ser usados para identificar uma vista. Um criptador de MVC fornece o id de vista de uma vista quando a vista é criptada. O id de vista pode ser usado por um decodificador de MVC para previsão entre vistas ou por outras unidades para outros propósitos, por exemplo, para renderização.

[0216] Previsão entre vistas é uma técnica para criptar dados de MVC de vídeo de um quadro em referência a um ou mais quadros em um local temporal comum como o quadro criptado de diferentes vistas. Em geral, um quadro criptado de dados de MVC de vídeo pode ser criptado de modo previsto espacialmente, temporalmente e/ou em referência a quadros de outras vistas em um local temporal comum. Consequentemente, vistas de referência, das quais outras vistas são previstas, geralmente são decodificadas antes das vistas para as quais as vistas de referência atuam como referência, de modo que essas vistas decodificadas podem ser usadas para referência ao decodificar vistas referenciais. A ordem de decodificação não corresponde necessariamente à ordem dos ids de vista. Portanto, a ordem de decodificação de vistas é descrita com o uso de índices de ordem de vista. Os índices de ordem de vista são índices que indicam a ordem de decodificação de componentes de vista correspondentes em uma unidade de acesso.

[0217] Cada fluxo individual de dados (seja áudio ou vídeo) é denominado como um fluxo elementar. Um fluxo elementar é um único componente digitalmente codificado (possivelmente comprimido) de um programa. Por exemplo, a parte de vídeo e áudio codificado do programa pode ser um fluxo elementar. Um fluxo elementar pode ser convertido em um fluxo elementar (PES) empacotado antes multiplexado em um fluxo de programa ou fluxo de transporte. Dentro do mesmo programa, um ID de fluxo é usado para distinguir os pacotes de PES que pertencem a um fluxo elementar a partir de outro. A unidade básica de dados de um fluxo elementar é um pacote de fluxo elementar (PES) empacotado. Desse modo, cada vista de dados de MVC de vídeo corresponde a respectivos fluxos elementares. De modo similar, dados de áudio correspondem a um ou mais respectivos fluxos elementares.

[0218] Uma sequência de vídeo codificada de MVC pode ser separada em vários subfluxos de bits, em que cada um dos quais é um fluxo elementar. Cada subfluxo de bits pode ser identificada com o uso de um subconjunto de view_id de MVC. Com base no conceito de cada subconjunto de view_id de MVC, um subfluxo de bits de vídeo de MVC é definido. Um subfluxo de bits de vídeo de MVC contém as unidades de NAL das vistas listadas no subconjunto de view_id de MVC. Um fluxo de programa geralmente contém somente as unidades de NAL que são daquelas dos fluxos elementares. É também projetado que quaisquer dois fluxos elementares não podem conter uma vista idêntica.

[0219] No exemplo da Figura 4, o multiplexador 130 recebe fluxos elementares que compreende dados de vídeo do criptador de vídeo 128 e fluxos elementares que compreendem dados de áudio do criptador de áudio 126. Em alguns exemplos, o criptador de vídeo 128 e o criptador de áudio 126 podem incluir, cada um, empacotadores para formar pacotes de PES de dados criptados. Em outros exemplos, criptador de vídeo 128 e criptador de áudio 126 podem, cada um, interagir com respectivos empacotadores para formar pacotes de PES a partir de dados criptados. Em ainda outros exemplos, o multiplexador 130 pode incluir empacotadores para formar pacotes de PES de dados de áudio e vídeo criptados.

[0220] Um “programa”, conforme usado 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 entregues por um serviço de dispositivo de fonte de A/V 120. Cada pacote de PES inclui um ID de fluxo que identifica o fluxo elementar ao qual o pacote de PES pertence. O multiplexador 130 é responsável por montar fluxos elementares em fluxos de programa constituintes ou fluxos de transporte. Um fluxo de programa e um fluxo de transporte são dois multiplexes alternativos voltados a diferentes aplicações.

[0221] Em geral, um fluxo de programa inclui dados para um programa, enquanto um fluxo de transporte pode incluir dados para um ou mais programas. O multiplexador 130 pode criptar tanto um fluxo de programa quanto/como um fluxo de transporte, com base em um serviço que é fornecido, um meio no qual o fluxo será passado, um número de programas a ser enviado, ou outras considerações. Por exemplo, quando os dados de vídeo tiverem de ser criptados em um meio de armazenamento, o multiplexador 130 pode ser mais propenso a formar um fluxo de programa, enquanto quando os dados de vídeo devem ser transmitidos por streaming over uma rede, transmissão contínua, ou enviado como parte de telefonia de vídeo, o multiplexador 130 pode ser mais propenso a usar um fluxo de transporte.

[0222] O multiplexador 130 pode ser desviado 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 é destinado para o uso em ambientes sem erro ou ambientes menos suscetíveis a encontrar erros, devido ao fato de que os fluxos de programa são preferencialmente suscetíveis a erros. Um fluxo de programa compreende simplesmente os fluxos elementares pertencentes ao mesmo e contém geralmente pacotes de comprimentos variáveis. Em um fluxo de programa, pacotes de PES que são derivados a partir de fluxos elementares de contribuição são organizados em “conjuntos”. Um conjunto compreende um leitor de conjunto, um cabeçalho de sistema opcional, e qualquer número de pacotes de PES tomados de qualquer um dos fluxos elementares de contribuição, 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 vídeo e áudio de contribuição, informações de temporização adicionais ou outras informações. Um decodificador pode usar as informações contidas em um cabeçalho de sistema para determinar se o decodificador tem capacidade ou não de decodificar o fluxo de programa.

[0223] O multiplexador 130 pode usar um fluxo de transporte para a entrega simultânea de uma pluralidade de programas através de canais potencialmente propensos a erros. Um fluxo de transporte é um multiplex elaborado para aplicações de múltiplos programas, tais como transmissão contínua, de modo que um único fluxo de transporte possa acomodar muitos programas independentes. Um fluxo de transporte pode compreender uma sucessão de pacotes de transporte, sendo que cada um dos pacotes de transporte tem 188 bytes de comprimento. O uso de pacotes de comprimento curto 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 dada proteção adicional contra erros processando- se o pacote através de um processo de proteção contra erros padrão, tal como criptação Reed-Solomon. A resiliência de erros aprimorada do fluxo de transporte significa que o mesmo tem uma chance melhor de sobreviver aos canais de erros a serem constatados em um ambiente de difusão, por exemplo.

[0224] Pode-se observar que o fluxo de transporte é melhor do que um fluxo de programa devido a sua resiliência a erros aumentada e capacidade de conduzir 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 que tem um valor de 0x47 (hexadecimal 47, binário “01000111”, decimal 71). Um único fluxo de transporte pode transportar muitos programas diferentes, sendo que cada programa compreende muitos fluxos elementares empacotados. O multiplexador 130 pode usar um campo de identificador de pacote (PID) de treze bits para distinguir pacotes de transporte que contêm os dados de um fluxo elementar a partir daqueles que conduzem os dados de outros fluxos elementares. O multiplexador tem a responsabilidade de garantir que cada fluxo elementar seja privilegiado em um valor de PID único. O último byte de um pacote de transporte pode ser o campo de contagem de continuidade. O multiplexador 130 incrementa o valor do campo de contagem de continuidade entre sucessivos pacotes de transporte que pertencem ao mesmo fluxo elementar. Isso permite que um decodificador ou outra unidade de um dispositivo de destino, tal como dispositivo de destino de A/V 140, para detectar a perda ou ganho de um pacote de transporte e esperançosamente ocultar os erros que podem, de outro modo, se resultar de tal evento.

[0225] O multiplexador 130 recebe pacotes de PES para fluxos elementares de um programa do criptador de áudio 126 e criptador de vídeo 128 e forma unidades de camada de abstração de rede (NAL) correspondentes dos pacotes de PES. No exemplo de H.264/AVC (Codificação de Vídeo Avançada), segmentos de vídeo codificados são organizados em unidades de NAL, que fornecem uma representação de vídeo “amigável para rede” voltadas a aplicações tais como telefonia de vídeo, armazenamento, transmissão contínua ou streaming. As unidades de NAL podem ser categorizadas para unidades de NAL de codificação de vídeo camada (VCL) e unidades diferentes de NAL VCL. As unidades de VCL contêm dados para o mecanismo de compressão de núcleo e pode compreender bloco, macrobloco e/ou níveis de fatia. Outras unidades de NAL são unidades diferentes de NAL VCL.

[0226] O multiplexador 130 pode formar unidades de NAL que compreendem um cabeçalho que identifica um programa ao qual a NAL pertence, assim como uma carga, por exemplo, dados de áudio, dados de vídeo, ou dados que descrevem o transporte ou fluxo de programa ao qual a unidade de NAL corresponde. Por exemplo, em H.264/AVC, uma unidade de NAL inclui um cabeçalho de 1 byte e uma carga de tamanho variado. 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_flag. Em MVC convencional, a unidade de NAL definida por H.264 é retida, exceto para unidades de prefixo NAL e unidades de NAL de fatia codificadas por MVC, que incluem um cabeçalho de unidade de NAL de MVC de 4 bytes e a carga de unidade de NAL.

[0227] O elemento priority_id de um cabeçalho de NAL pode ser usado para um simples processo de adaptação de fluxo de bits de uma trajetória. O elemento temporal_id pode ser usado para especificar o nível temporal da unidade de NAL correspondente, em que diferentes níveis temporais correspondem a diferentes taxas de quadro.

[0228] O elemento anchor_pic_flag pode indicar se uma imagem é uma imagem âncora ou imagem não âncora. As imagens âncora e todas as imagens que sucedem a mesmas na ordem de saída (ou seja, a ordem de exibição) podem ser corretamente decodificadas sem decodificação de imagens anteriores na ordem de decodificação (ou seja, a ordem de fluxo de bits), e desse modo, podem ser usadas como pontos de acesso aleatórios. Imagens âncora e imagens não âncora podem ter diferentes dependências, ambas as quais são sinalizadas no conjunto de parâmetro de sequência. Outros sinalizadores devem ser discutidos e usados nas seguintes seções neste capítulo. Tal imagem âncora também pode ser denominada como um ponto de acesso de GOP (grupo de imagens) aberto, enquanto um ponto de acesso de GOP fechado é também suportado quando o elemento non_idr_flag é igual a zero. O elemento non_idr_flag indica se uma imagem é um atualizador de decodificador instantâneo (IDR) ou imagem de IDR de vista (V-IDR). Em geral, uma imagem de IDR, e todas as imagens que sucedem a mesma na ordem de saída ou ordem de fluxo de bits, podem ser corretamente decodificadas sem a decodificação de imagens anteriores nem na ordem de decodificação nem na ordem de exibição.

[0229] O elemento view_id pode compreender informações de sintaxe que podem ser usadas para identificar uma vista, que pode ser usada para interatividade de dados dentro de um decodificador de MVC, por exemplo, para previsão entre vistas, e fora de um decodificador, por exemplo, para renderização. O elemento inter_view_flag pode especificar se a unidade de NAL correspondente é usada por outras vistas para previsão entre vistas. Para conduzir as informações de unidade de cabeçalho de NAL de 4 bytes para uma vista de base, que pode estar em conformidade com AVC, uma unidade de prefixo NAL é definida em MVC. No contexto de MVC, a unidade de acesso de vista de base inclui as unidades de NAL VCL da instância de tempo atual da vista assim como sua unidade de prefixo NAL, que contém somente o cabeçalho de unidade de NAL. Um decodificador de H.264/AVC pode ignorar a unidade de prefixo NAL.

[0230] Uma unidade de NAL que inclui dados de vídeo em sua carga pode compreender vários níveis granularidade de dados de vídeo. Por exemplo, uma unidade de NAL pode compreender um bloco de dados 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. O multiplexador 130 pode receber dados de vídeo criptados de criptador de vídeo 128 na forma de pacotes de PES de fluxos elementares. O multiplexador 130 pode associar cada fluxo elementar com um programa correspondente mapeando-se ids de fluxo aos 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).

[0231] O multiplexador 130 também pode montar unidades de acesso de uma pluralidade de unidades de NAL.Em geral, uma unidade de acesso pode compreender um ou mais unidades de NAL para representar um quadro de dados de vídeo, assim como dados de áudio correspondentes ao quadro quando tais dados de áudio estão disponíveis. Uma unidade de acesso geralmente inclui todas as unidades de NAL para uma instância de tempo de saída, por exemplo, todos os dados de áudio e vídeo por uma instância de tempo. Por exemplo, se cada vista tiver uma taxa de quadro de 120 quadros por segundo (fps), então cada instância de tempo pode corresponder a um intervalo de tempo de 0,05 segundo. Durante esse 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 apresentado 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 criptada de uma vista particular como um “componente de vista”. Ou seja, um componente de vista pode compreender uma imagem criptada (ou quadro) 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 precisam ser necessariamente as mesmas que a ordem de saída ou exibição.

[0232] O multiplexador 130 pode também embutir dados relacionados um programa em uma unidade de NAL. Por exemplo, multiplexador 130 pode criar uma unidade de NAL que compreende uma tabela de mapa de programa (PMT) ou um mapa de fluxo de programa (PSM). Em geral, um PMT é usado para descrever um fluxo de transporte, enquanto um PSM é usado para descrever um fluxo de programa. Conforme descrito em mais detalhes em relação ao exemplo da Figura 2 abaixo, multiplexador 130 pode compreender ou interagir com uma unidade de armazenamento de dados que associa os fluxos elementares recebidos do criptador de áudio 126 e do criptador de vídeo 128 com programas e consequentemente com os respectivos fluxos de transporte e/ou fluxos de programa.

[0233] Assim como a maioria dos padrões de codificação de vídeo, H.264/AVC e HEVC definem a sintaxe, semântica, e processo de decodificação para fluxos de bits sem erros, em que qualquer um dos quais se conformam a um determinado perfil ou nível. Esses padrões não especificam o criptador, mas o criptador é atarefado com a garantia de que os fluxos de bits gerados estão em conformidade de padrão para um decodificador. No contexto de 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 aos mesmos. Conforme definido pelo padrão H.264, por exemplo, um “perfil” é um subconjunto da sintaxe de fluxo de bits inteira que é especificada pelo padrão H.264. Um “nível” corresponde às limitações do consumo de recurso de decodificador, tais como, por exemplo, memória e decodificação e computação, que são relacionadas à resolução das imagens, taxa de bits e taxa de processamento de macrobloco (MB).

[0234] O padrão H.264, por exemplo, reconhece que, dentro das ligações impostas pela sintaxe de um dado perfil, ainda é possível exigir uma grande variação no desempenho de criptadores e decodificadores que dependem dos valores tomados pelos elementos de sintaxe no fluxo de bits tais como o tamanho especificado das imagens decodificadas. O padrão H.264 reconhece adicionalmente que, em muitas aplicações, não é prático nem econômico implantar um decodificador com capacidade de lidar com todos os usos hipotéticos da sintaxe dentro de um perfil particular. Consequentemente, o padrão H.264 define um “nível” como um conjunto especificado de restrições impostas em valores dos elementos de sintaxe no fluxo de bits. Essas restrições podem ser simples limites de valores. Alternativamente, essas restrições podem tomar a forma de restrições em combinações aritméticas de valores (por exemplo, largura de imagem multiplicadas por imagem altura multiplicadas por número de imagens decodificadas por segundo). O padrão H.264 determina adicionalmente que implantações individuais podem suportar um nível diferente para cada perfil suportado.

[0235] Um decodificador que se conforma a um perfil suporta normalmente todos os recursos definidos no perfil. Por exemplo, como um recurso de codificação, codificação de imagem B não é suportado no perfil de linha de base de H.264/AVC, mas é suportado em outros perfis de H.264/AVC. Um decodificador que se conforma a um nível deve ter capacidade de decodificar qualquer fluxo de bits que não exige recursos além das limitações definidas no nível. Definições de perfis e níveis podem ser úteis para interpretabilidade. Por exemplo, durante a transmissão de vídeo, um par de definições de perfil e nível pode ser negociado e estar de acordo para uma sessão de transmissão inteira. Mais especificamente, em H.264/AVC, um nível pode definir, por exemplo, limitações no número de macroblocos que precisam ser processados, tamanho de armazenamento temporário de imagem decodificada (DPB), tamanho de armazenamento temporário de imagem codificada (DPB), faixa de vetor de movimento vertical, número máximo de vetores de movimento por dois MBs consecutivos, e se um bloco B pode ter partições de submacrobloco menores do que 8x8 pixels. Dessa maneira, um decodificador pode determinar se o decodificador tem capacidade de decodificar apropriadamente o fluxo de bits.

[0236] Conjuntos de parâmetros contêm geralmente informações de cabeçalho de camada de sequência nos conjuntos de parâmetro de sequência (SPS) e as informações de cabeçalho de camada de imagens que mudam de modo infrequente nos conjuntos de parâmetros de imagem (PPS). Com conjuntos de parâmetros, essas informações que mudam de modo infrequente não precisam ser repetidas para cada sequência ou imagem; portanto, a eficiência de codificação pode ser aprimorada. Ademais, o uso de conjuntos de parâmetros pode permitir a transmissão fora de banda de informações de cabeçalho, evitando a necessidade de transmissões redundantes para alcançar resiliência de erro. Na transmissão fora de banda, unidades de NAL de conjunto de parâmetros são transmitidas em um canal diferente das outras unidades de NAL.

[0237] Os sistemas padrão de MPEG-2 permite as extensões do sistema por meio de “descritores”. Tanto PMTs quanto PSMs incluem ciclos de descritor nos quais um ou mais descritores podem ser inseridos. Em geral, um descritor pode compreender uma estrutura de dados que pode ser usada para estender a definição de programas e/ou elementos de programa. Esta revelação descreve descritores de ponto de operação para realizar as técnicas desta revelação. Em geral, o descritor de ponto de operação desta revelação aprimora o descritor de extensão de MVC convencional descrevendo-se uma capacidade de renderização, uma capacidade de decodificação e uma taxa de bits para um ponto de operação. Um dispositivo de destino, tal como dispositivo de destino de A/V 140, pode usar 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 a ser decodificado.

[0238] 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 fonte 120 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 de destino 140 (por exemplo, um dispositivo de cliente). De modo que o dispositivo de destino 140 renderize apropriadamente (por exemplo, exiba) dados de vídeo do ponto de operação, o dispositivo de destino 140 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 serem exibidas (por exemplo, um número de vistas almejadas para renderização) e/ou a taxa de quadro dos dados de vídeo para as vistas. Desse modo, dispositivo de destino 140 pode determinar que as capacidades de renderização são atendidas quando a saída de vídeo 144 de dispositivo de destino 140 tem capacidade de exibir o número de vistas do ponto de operação na taxa de quadro especificada pelo descritor de ponto de operação.

[0239] Depois que o multiplexador 30 montou uma unidade de NAL e/ou uma unidade de acesso dos dados recebidos, o multiplexador 30 passa a unidade à interface de saída 132 para saída. A interface de saída 132 pode compreender, por exemplo, um transmissor, um transceptor, um dispositivo para gravar dados em um meio legível por computador tal como, por exemplo, uma unidade óptica, uma unidade de mídia magnética (por exemplo, disquete), uma porta de barramento serial universal (USB), uma interface de rede, ou outra interface de saída. A interface de saída 132 emite a unidade de NAL ou unidade de acesso a um meio legível por computador 134, tal como, por exemplo, um sinal de transmissão, um meio magnético, um meio óptico, uma memória, uma unidade de flash, ou outro meio legível por computador.

[0240] Por fim, a interface de entrada 136 recupera os dados do meio legível por computador 134. A interface de entrada 136 pode compreender, por exemplo, uma unidade óptica, uma unidade de mídia magnética, uma porta USB, um receptor, um transceptor ou outra interface de meio legível por computador. A interface de entrada 136 pode fornecer a unidade de NAL ou unidade de acesso ao demultiplexador 138. O demultiplexador 138 pode demultiplexar um fluxo de transporte ou fluxo de programa em fluxos de PES constituinte, desempacotar os fluxos de PES para recuperar dados criptados, e enviar os dados criptados tanto ao decodificador de áudio 146 como decodificador de vídeo 148, dependendo da possibilidade de os dados criptados serem parte de um fluxo de áudio ou vídeo, por exemplo, conforme indicado pelos cabeçalhos de pacote de PES do fluxo. O decodificador de áudio 146 decodifica dados de áudio criptados e envia os dados de áudio decodificados à saída de áudio 142, enquanto o decodificador de vídeo 148 decodifica dados de vídeo criptados e envia os dados de vídeo decodificados, que podem incluir uma pluralidade de vistas de um fluxo à saída de vídeo 144. A saída de vídeo 144 pode compreender um visor que usa uma pluralidade de vistas de um cenário, por exemplo, uma exibição estereoscópica ou autostereoscópica que apresenta cada vista de um cenário simultaneamente.

[0241] Em particular, o demultiplexador 138 pode selecionar um ponto de operação de um fluxo de bits recebido. Por exemplo, o demultiplexador 138 pode comparar características de pontos de operação do fluxo de bits para selecionar um ponto de operação apropriado a ser usado pelo dispositivo de destino de A/V 140. Em geral, o demultiplexador 138 pode tentar selecionar um dos pontos de operação que fornecerão a maior experiência de visualização de qualidade para um usuário que pode ser decodificado pelo decodificador de vídeo 148. Por exemplo, o demultiplexador 138 pode comparar as capacidades de renderização e capacidades de decodificação do decodificador de vídeo 148 às capacidades sugeridas de renderização e decodificação sinalizadas pelos descritores de ponto de operação do fluxo de bits. Dos pontos de operação que o demultiplexador 138 determina poderiam ser apropriadamente decodificados pelo decodificador de vídeo 148, o demultiplexador 138 pode selecionar um ponto de operação que fornecerão a maior qualidade dados de vídeo, por exemplo, a maior taxa de quadro e/ou a taxa de bits. Em outros exemplos, o demultiplexador 138 pode selecionar um dos pontos de operação suportados com base em outras considerações, tais como, por exemplo, consumo de potência.

[0242] Em geral, o sistema 100 pode corresponder substancialmente ao sistema 10 da Figura 1. De modo similar, o multiplexador 130 pode corresponder substancialmente ao multiplexador 21 da Figura 1, o demultiplexador 138 pode corresponder substancialmente ao demultiplexador 29 da Figura 1, e outros componentes de sistema 100 nomeados de modo similar podem corresponder substancialmente aos componentes nomeados de modo similar da Figura 1. Desse modo, o multiplexador 130 e o demultiplexador 138 pode ser configurado para realizar qualquer uma das várias técnicas descritas nesta revelação, por si só ou em qualquer combinação.

[0243] A seguir são descritos alguns exemplos de casos de uso. O uso do descritor de hierarquia e do descritor de extensão de hierarquia pode ser ilustrado no exemplo a seguir. A Figura 5 é um diagrama conceitual que ilustra um exemplo ilustrando fluxos de bits de L-HEVC transportados em quatro fluxos elementares. Por exemplo, dado um programa que contém fluxos de bits de L-HEVC transportados em quatro fluxos elementares como representada na Figura 5, as informações de dependência para cada fluxo elementar são sinalizadas da seguinte forma: a. Um descritor de hierarquia deve estar presente para esA de modo a descrever que esA é um fluxo elementar de camada de base. b. Um descritor de hierarquia deve estar presente para esB de modo a descrever que esB tem dependência temporal para esA. c. Um descritor de extensão de hierarquia deve estar presente para esC de modo a descrever que esC tem dependência de camada para esA. d. Um descritor de extensão de hierarquia deve estar presente para esD de modo a descrever que: i. esD tem dependência de camada para esB. ii. esD tem dependência temporal para esC.

[0244] Alternativa ou adicionalmente, para evitar o uso sobreposto do descritor de hierarquia e do descritor de extensão de hierarquia, o seguinte é proposto: a. Para cada fluxo elementar que contém uma imagem codificada de HEVC, um descritor (por exemplo, exatamente um), tanto o descritor de hierarquia como o descritor de extensão de hierarquia, podem (em um exemplo, devem) estar presentes e associados ao fluxo elementar. b. Um descritor de hierarquia pode (em um exemplo, deve) estar presente e associado a um fluxo elementar se o fluxo elementar tiver dependência (por exemplo, temporal, espacial, multivista, etc) para exatamente um outro fluxo elementar de referência. Um fluxo elementar de referência de um fluxo elementar atual é um fluxo elementar que é diretamente dependente do fluxo elementar atual. c. Um descritor de hierarquia pode (em um exemplo, deve) estar presente e associado a um fluxo elementar se o fluxo elementar tiver dependência para mais de um fluxo elementar de referência.

[0245] A Figura 6 é outro exemplo de dependência entre fluxos elementares. Como a Figura 5, os fluxos de bits de L-HEVC transportados em quatro fluxos elementares são ilustrados. O uso do descritor de hierarquia e do descritor de extensão de hierarquia neste exemplo alternativo ou adicional para a estrutura de dependência conforme mostrado na Figura 5 são as seguintes: d. Um descritor de hierarquia deve estar presente para esA de modo a descrever que esA é um fluxo elementar de camada de base. e. Um descritor de hierarquia deve estar presente para esB de modo a descrever que esB tem dependência temporal para esA. f. Um descritor de hierarquia deve estar presente para esC para descrever que esC tem uma dependência de camada a esA. g. Um descritor de extensão de hierarquia deve estar presente para esD para descrever que: iii. esD tem uma dependência de camada a esB iv. esD tem uma dependência temporal a esC.

[0246] Para a dada estrutura de dependência na Figura 6, o uso do descritor de hierarquia e do descritor de extensão de hierarquia nessa alternativa ocorre da seguinte forma: a. Um descritor de hierarquia deve estar presente para esA de modo a descrever que esA é um fluxo elementar de camada de base. b. Um descritor de hierarquia deve estar presente para esB de modo a descrever que esB tem dependência temporal para esA. c. Um descritor de hierarquia deve estar presente para esC de modo a descrever que esC tem dependência de camada para esB: d. Um descritor de hierarquia deve estar presente para esD de modo a descrever que esD tem dependência de camada para esC. e. Um descritor de hierarquia deve estar presente para esE de modo a descrever que esE tem dependência temporal para esD.

[0247] A Figura 7 ilustra outro exemplo da estrutura de dependência. Para a dada estrutura de dependência na Figura 7 (possivelmente a Figura 6), o uso do descritor de hierarquia e do descritor de extensão de hierarquia nessa alternativa é da seguinte forma: a. Um descritor de hierarquia deve estar presente para esA de modo a descrever que esA é um fluxo elementar de camada de base. b. Um descritor de hierarquia deve estar presente para esB de modo a descrever que esB tem dependência temporal para esA. c. Um descritor de hierarquia deve estar presente para esC de modo a descrever que esC é um fluxo elementar independentemente codificado. d. Um descritor de hierarquia deve estar presente para esD de modo a descrever que esD tem dependência temporal para esC. e. Um descritor de extensão de hierarquia deve estar presente para esE de modo a descrever que: i. esE tem dependência de camada para esC. ii. esE tem dependência de camada para esA. f. Um descritor de extensão de hierarquia deve estar presente para esF de modo a descrever que: iii. esF tem dependência temporal para esE. iv. esE tem dependência de camada para esD. v. esF tem dependência de camada para esB.

[0248] No exemplo alternativo ou adicional,para evitar o uso sobreposto do descritor de hierarquia e do descritor de extensão de hierarquia, o seguinte é proposto: a. Um descritor de hierarquia deve estar presente e associado a um fluxo elementar se o fluxo elementar tiver dependência temporal. b. Um descritor de hierarquia deve estar presente e associado a um fluxo elementar se o fluxo elementar tiver dependência de camada (por exemplo, espacial, multivista, qualidade) para exatamente um outro fluxo elementar de referência. c. Um descritor de extensão de hierarquia deve estar presente e associado a um fluxo elementar se o fluxo elementar tiver dependência de camada a mais de um fluxo elementar de referência.

[0249] O uso do descritor de hierarquia e do descritor de extensão de hierarquia neste exemplo alternativo ou adicional para a estrutura de dependência conforme mostrado na Figura 5 (e possivelmente as Figuras 6 ou 7) são as seguintes: a. Um descritor de hierarquia deve estar presente para esA de modo a descrever que esA é um fluxo elementar de camada de base. b. Um descritor de hierarquia deve estar presente para esB de modo a descrever que esB tem dependência temporal para esA. c. Um descritor de hierarquia deve estar presente para esC de modo a descrever que esC tem dependência de camada a esA. d. Dois descritores de hierarquia devem estar presentes para esD de modo a descrever que esD tem dependência temporal a esC e esD tem dependência de camada a esB.

[0250] O uso do descritor de hierarquia e do descritor de extensão de hierarquia alternativamente para a estrutura de dependência conforme mostrado na Figura 7 (possivelmente as Figuras 5 ou 6) são as seguintes: a. Um descritor de hierarquia deve estar presente para esA de modo a descrever que esA é um fluxo elementar de camada de base. b. Um descritor de hierarquia deve estar presente para esB de modo a descrever que esB tem dependência temporal para esA. c. Um descritor de hierarquia deve estar presente para esC de modo a descrever que esC é um fluxo elementar independentemente codificado. d. Um descritor de hierarquia deve estar presente para esD de modo a descrever que esD tem dependência temporal para esC. e. Um descritor de extensão de hierarquia deve estar presente para esE de modo a descrever que: v. esE tem dependência de camada para esC. vi. esE tem dependência de camada para esA. f. Um descritor de hierarquia deve estar presente para esF de modo a descrever que esF tem dependência temporal para esE. g. Um descritor de extensão de hierarquia deve estar presente para esF de modo a descrever que: vii. esF tem dependência temporal para esD. viii. esF tem dependência de camada para esB.

[0251] No terceiro exemplo alternativo ou adicional para evitar o uso sobreposto do descritor de hierarquia e do descritor de extensão de hierarquia, propõe-se que apenas o descritor de hierarquia deve ser usado, e o descritor de extensão de hierarquia pode ser removido.

[0252] O uso do descritor de hierarquia nessa alternativa para a estrutura de dependência conforme mostrado na Figura 5 (possivelmente as Figuras 6 ou 7) são as seguintes: a. Um descritor de hierarquia deve estar presente para esA de modo a descrever que esA é um fluxo elementar de camada de base. b. Um descritor de hierarquia deve estar presente para esB de modo a descrever que esB tem dependência temporal para esA. c. Um descritor de hierarquia deve estar presente para esC de modo a descrever que esC tem dependência de camada a esA. d. Um descritor de hierarquia deve estar presente para esD de modo a descrever que esD tem dependência temporal para esC. e. Um descritor de hierarquia deve estar presente para esD de modo a descrever que esD tem dependência de camada para esB.

[0253] Na presença do descritor de hierarquia ou do descritor de extensão de hierarquia ou ambos, as duas seguintes opções são propostas: a. Opção 1: para cada fluxo elementar contendo imagens codificadas de HEVC, pelo menos um descritor contendo informações de dependência deve estar presente. b. Opção 2: i. A presença de descritor contendo informações de dependência é obrigatória apenas quando um programa contém mais de um fluxo elementar de imagens codificadas por HEVC com o mesmo tipo de fluxo. ii. Quando nenhum descritor contendo informações de dependência está presente em um programa, para cada fluxo elementar no programa que contém imagens codificadas por HEVC, o valor de índice de camada de hierarquia para cada fluxo elementar é derivado como exposto a seguir: ao primeiro fluxo elementar é dado o valor 0, ao segundo fluxo elementar é dado o valor 1, ao n-ésimo fluxo elementar é dado o valor n - 1.

[0254] O uso do descritor de hierarquia e do descritor de extensão de hierarquia neste exemplo do segundo exemplo alternativo ou adicional para a estrutura de dependência conforme mostrado na Figura 5 (possivelmente as Figuras 6 ou 7) não precisa nem do descritor de hierarquia nem do descritor de extensão de hierarquia. Conforme cada fluxo elementar de tipos diferentes, não há a necessidade de sinalizar o descritor para informações de dependência como pode ser inferido da seguinte forma: a. esA é um fluxo elementar de camada de base b. esB tem dependência temporal a esA c. esC tem dependência multivista a esA d. esD tem tanto dependência multivista a esC como dependência temporal a esB.

[0255] Além disso, a ordem daqueles fluxos elementares na tabela de mapa de programa é a seguinte: esA, esB, esC e esC.

[0256] Por fim, o valor de hierarchy_layer_index para cada fluxo elementar é derivado como exposto a seguir: hierarchy_layer_index de esA é igual a 0, hierarchy_layer_index de esB é igual a 1, hierarchy_layer_index de esC é igual a 2 e hierarchy_layer_index de esD é igual a 4

[0257] A seguir são exemplos de implementações de uma ou mais técnicas descritas acima. Os textos sugeridos para implementar as propostas acima são fornecidos.

[0258] Para o descritor de extensão de hierarquia aprimorado, a semântica de bits de dimensão de extensão é atualizada da seguinte forma. O texto em itálico representa atualizações no padrão de MPEG-2 TS:

[0259] extension_dimension_bits - Um campo de 16 bits que indica o possível aprimoramento do elemento de programa associado a partir da camada de base resultante do elemento de programa da camada com nuh_layer_id igual a 0.A alocação dos bits para dimensões de aperfeiçoamento é da seguinte forma na Tabela Amd7-4. TABELA AMD7-4 - SEMÂNTICA DE BITS DE DIMENSÃO DE EXTENSÃO

[0260] Nota-se que o valor de índice para bits atribuídos a aperfeiçoamento temporal pode ser qualquer um dos valores reservados (por exemplo, 5 a 15).

[0261] Para o descritor de hierarquia aprimorado, as seguintes mudanças são propostas para a implementação do exemplo para sustentar o aperfeiçoamento de camada auxiliar no descritor de hierarquia. Nota-se que a parte atualizada é destacada em cinza, com [[]] indicando deleção: CLÁUSULA 2.6.6 SUBSTITUIR A TABELA 2-49 POR: TABELA 2-49 - DESCRITOR DE HIERARQUIA CLÁUSULA 2.6.7 SUBSTITUIR temporal_scalability_flag - Um sinalizador de 1- bit, que quando definidas para “0” indica que o elemento de programa associado aprimora a taxa de quadro do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado. spatial_scalability_flag - Um sinalizador de 1- bit, que, quando ajustado para “0”, indica que o elemento de programa associado aprimora a resolução espacial do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado. quality_scalability_flag - Um sinalizador de 1- bit, que, quando ajustado para “0”, indica que o elemento de programa associado aprimora a qualidade de SNR ou fidelidade do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado. hierarchy_type - A relação hierárquica entre a camada hierárquica associada e sua camada embutida de hierarquia é definida na tabela 2-50. Se a escalabilidade se aplicar em mais do que uma dimensão, esse campo deve ser ajustado para o valor de “8” (“escalabilidade combinada”), e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados de acordo. Para subfluxos de vídeo de MVC, esse campo deve ser ajustado para o valor de '9'(“subfluxo de bits de vídeo de MVC”) e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados para T. Para subfluxos de bits de vista de base de MVC, esse campo deve ser ajustado para o valor de '15’ e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados para T. Para subfluxos de vídeo de MVCD, esse campo deve se ajustado para o valor de '9'(“subfluxo de vídeo de MVCD”) e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados para T. Para subfluxos de bits de vista de base de MVCD, esse campo deve ser ajustado para o valor de ‘15’ e os sinalizadores temporal_scalability_flag, spatial_scalability_flag e quality_scalability_flag devem ser ajustados para 1. por: no_view_scalability_flag - Um sinalizador de 1- bit, que, quando ajustado para “0”, indica que o elemento de programa associado aprimora a qualidade de SNR ou fidelidade do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” para esse sinalizador é reservado. no_temporal_scalability_flag - Um sinalizador de 1-bit, que quando definidas para “0” indica que o elemento de programa associado aprimora a taxa de quadro do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado. no_spatial_scalability_flag - Um sinalizador de 1-bit, que, quando ajustado para “0”, indica que o elemento de programa associado aprimora a resolução espacial do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado. no_quality_scalability_flag - Um sinalizador de 1-bit, que, quando ajustado para “0”, indica que o elemento de programa associado aprimora a qualidade de SNR ou fidelidade do fluxo de bits resultante do elemento de programa referenciado pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado. hierarchy_type - A relação hierárquica entre a camada hierárquica associada e sua camada embutida de hierarquia é definida na tabela 2-50. Se a escalabilidade se aplicar em mais de uma dimensão, esse campo deve ser ajustado para o valor de '8'(“Escalabilidade Combinada”), e os sinalizadores no_view_scalability_flag, no_temporal_scalability_flag, no_spatial_scalability_flag e no_quality_scalability_flag devem ser ajustados consequentemente. Para os subfluxos de vídeo de MVC, esse campo deve ser ajustado para o valor de '9'(“subfluxo de bits de vídeo de MVC”) e os sinalizadores no_view_scalability_flag, no_temporal_scalability_flag, no_spatial_scalability_flag e no_quality_scalability_flag devem ser ajustados para T. Para subfluxos de bits de vista de base de MVC, esse campo deve ser ajustado para o valor de '15’ e os sinalizadores no_view_scalability_flag, no_temporal_scalability_flag, no_spatial_scalability_flag, [[and]]no_quality_scalability_flag devem ser ajustados para T e no_auxiliary_flag deve ser ajustado para '1'. Para subfluxos de bits de vídeo de MVCD, esse campo deve ser ajustado para o valor de'9'(“subfluxo de bits de vídeo de MVCD”) e os sinalizadores no_view_scalability_flag, no_temporal_scalability_flag, no_spatial scalability_flag e no_quality_scalability_flag devem ser ajustados para T. Para subfluxos de bits de vista de base de MVCD, esse campo deve ser ajustado para o valor de '15’ e os sinalizadores no_view_scalability_flag, no_temporal_scalability_flag, no_spatial_scalability_flag,[[and]] no_quality_scalability_flag devem ser ajustados para T e no_auxiliary_flag deve ser ajustado para '1'. no_auxiliar_flag - Um sinalizador de 1 bit, que quando ajustado para '0’ indica que o elemento de programa associado fornece aperfeiçoamento auxiliar resultante do elemento de programa referido pelo hierarchy_embedded_layer_index. O valor de “1” “para esse sinalizador é reservado. Substituir na Tabela 2-50 a descrição pelo valor 15 da seguinte forma: TABELA 2-50 - VALORES DE CAMPO DE HIERARCHYTYPE

[0262] Para o uso proposto do descritor de hierarquia e do descritor de extensão de hierarquia, as seguintes alterações são propostas para a implementação de evitar o uso sobreposto de descritor de hierarquia e descritor de extensão de hierarquia.

[0263] Adicionar no final da lista com marcadores na seção 2.17.1 de rascunho de L-HEVC TS: a. Um descritor de hierarquia deve estar presente para cada fluxo elementar com stream_type igual a 0x24 e 0x25. b. Um descritor de extensão de hierarquia deve estar presente para cada fluxo elementar com stream_type igual a 0x27, 0x28, 0x29 e 0x2A.

[0264] As seguintes alterações são propostas para a implementação de evitar a sobreposição.

[0265] Adicionar no final da lista com marcadores na seção 2.17.1 de rascunho de L-HEVC TS: a. Um descritor de hierarquia deve estar presente para cada fluxo elementar com stream_type igual a 0x24 e 0x25. b. Para cada fluxo elementar com stream_type igual a 0x27, 0x28, 0x29 e 0x2 A, o seguinte se aplica: i. Se o fluxo elementar aprimorar exatamente um outro fluxo elementar, um descritor de hierarquia deve estar presente. ii. De outro modo, um descritor de extensão de hierarquia deve estar presente

[0266] O segundo exemplo alternativo ou adicional do uso proposto do descritor de hierarquia e do descritor de extensão de hierarquia é descrito agora. As seguintes alterações são propostas para a implementação de evitar a sobreposição.

[0267] Adicionar no final da lista com marcadores na seção 2.17.1 de rascunho de L-HEVC TS: a. Para fluxo elementar com stream_type igual a 0x24, um descritor de hierarquia com hierarchy_type igual a 15 deve estar presente. b. Para cada fluxo elementar com stream_type igual a 0x25, 0x28 e 0x29, um descritor de hierarquia com hierarchy_type igual a 3 deve estar presente. c. para cada fluxo elementar com stream_type igual a 0x27, 0x28, 0x29 e 0x2 A, o seguinte se aplica: i. Se o fluxo elementar aprimorar exatamente um outro fluxo elementar, um descritor de hierarquia com hierarchy_type não igual a 3 deve estar presente. ii. De outro modo, um descritor de extensão de hierarquia deve estar presente

[0268] A terceira alternativa ou adição do uso proposto do descritor de hierarquia e do descritor de extensão de hierarquia. As seguintes alterações são propostas para a implementação de evitar a sobreposição.

[0269] Adicionar no final da lista com marcadores na seção 2.17.1 de rascunho de L-HEVC TS: a. Para cada fluxo elementar com stream_type igual a 0x24 e 0x25, um descritor de hierarquia deve estar presente. b. Para cada fluxo elementar com stream_type igual a 0x27, 0x28, 0x29 ou 0x2A, um ou mais descritores de hierarquia devem estar presentes.

[0270] Adicional ou alternativamente, um descritor de vídeo de HEVC pode ser obrigatório para cada fluxo elementar com stream_type igual a 0x24 e 0x25. De modo semelhante, quando um programa ITU-T Rec. H.222.0 | ISO/IEC 13818-1 inclui um ou mais fluxos elementares com stream_type igual a 0x27, 0x28, 0x29 ou 0x2A, pelo menos um descritor de ponto de operação de HEVC pode ser obrigatório na tabela de mapa de programa associada ao programa.

[0271] A Figura 8 é um diagrama conceitual que ilustra um exemplo de múltiplas camadas de dados de vídeo. Um exemplo em que as informações de ponto de operação podem ser sinalizadas com um descritor de ponto de operação de HEVC, por exemplo, o descritor de ponto de operação de HEVC de Tabela Proposta Amd7-1 como discutido acima, é descrito em relação aos dados de vídeo da Figura 8. A Figura 8 representa um exemplo de um programa tendo cinco camadas de um fluxo de bits de HEVC em camadas, divididas em cinco fluxos elementares. A dependência de cada fluxo elementar é como mostrado na Figura 8 pelas setas entre as camadas. A dependência pode ser descrita por dados de um descritor de extensão de hierarquia, em alguns exemplos.

[0272] Devido ao número limitado de bytes que um descritor pode ter, a sinalização de pontos de operação pode ser dividida em descritores de dois pontos de operação de HEVC, conforme mostrado abaixo. O descritor de primeiro ponto de operação de HEVC, nesse exemplo, contém informações das três primeiras estruturas de PTL e dos dois primeiros pontos de operação, enquanto o descritor de segundo ponto de operação de HEVC contém informações das próximas duas estruturas de PTL e dos próximos dois pontos de operação. DESCRITOR DE PRIMEIRO PONTO DE OPERAÇÃO #PTL=3 PTL[0]=Perfil principal, categoria principal, nível 3.1 PTL[1]=MV Perfil principal, categoria principal, nível 3.1 PTL[2]=MV Perfil principal, categoria principal, nível 4.1 #OP = 2 es_count[0]=l prepand_dependencies[0]=l es_reference[0][0]=l #layers[0]=2 ptl_ref_idx[0][0]=0 ptl_ref_idx[0][l]=l es_count[l]=l prepand_dependencies[0]=l es_reference[ 1 ] [0]=2 #layers[l]=3 ptl_ref_idx[l][0]=0 ptl_ref_idx[l][l]=l ptl_ref_idx[l][2]=2 DESCRITOR DE SEGUNDO PONTO DE OPERAÇÃO #PTL=1 PTL[3]=MV Perfil principal, categoria principal, nível 5.0 #OP = 2 es_count[2]=l prepand_dependencies[2]=0 es_reference[2] [0]=3 #layers[2]=l ptl_ref_idx[2][0]=3 es_count[3]=2 prepand_dependencies[3]=l es_reference[3][0]=4 #layers[3]=5 ptl_ref_idx[3][0]=0 ptl_ref_idx[3][l]=l ptl_ref_idx[3][2]=2 ptl_ref_idx[3][3]=0 ptl_ref_idx[3][4]=l

[0273] Nota-se que para poupar bits, para alguns pontos de operação, o valor de prepand_dependencies[opIdx] é ajustado igual a 1 e a lista de fluxos elementares do ponto de operação pode ser derivada com base em informações de dependência sinalizadas no descritor de extensão de hierarquia.

[0274] A Figura 9 é um fluxograma que ilustra um método exemplificador de acordo com as técnicas desta revelação. Dessa maneira, o método da Figura 9 é explicado em relação ao demultiplexador 29 da Figura 1. Entretanto, deve-se compreender que outros dispositivos podem ser configurados para realizar o método da Figura 9, como o demultiplexador 138 da Figura 4, ou um elemento de rede com suporte de mídia (MANE) posicionado entre um dispositivo de origem e um dispositivo de destino. Além disso, um método recíproco pode ser realizado por um multiplexador, como multiplexador 21 da Figura 1 ou multiplexador 130 da Figura 4.

[0275] Inicialmente, nesse exemplo, o demultiplexador 29 extrai um descritor, como um descritor de ponto de operação de HEVC de acordo com a Tabela Proposta Amd7-1, a partir de um fluxo de bits (150). O demultiplexador 29, então, recupera uma ou mais estruturas de perfil, categoria e nível (PTL) do descritor (152). Por exemplo, as estruturas de PTL podem corresponder aos dados do loop “para( i = 0; i < num_profile_tier_level; i++, ptlldx++ )” da Tabela Proposta Amd7-1 discutida acima.

[0276] O demultiplexador 29 pode determinar as dependências entre fluxos elementares (ou seja, as camadas) (154). As dependências podem ser sinalizadas no descritor de ponto de operação de HEVC ou em um descritor separado. Por exemplo, o demultiplexador 29 pode extrair um descritor de hierarquia (por exemplo, de acordo com a Tabela 2-49) ou um descritor de extensão de hierarquia que inclui informações indicativas das dependências, conforme discutido acima.

[0277] O demultiplexador 29 também determina qual das estruturas de PTL corresponde a cada camada de cada um dentre uma pluralidade de pontos de operação (156). Por exemplo, o demultiplexador 29 pode determinar essa correspondência a partir do loop “para( j = 0; j < num_layers[opIdx]; j++ )” de Tabela Proposta Amd7-1 discutida acima.

[0278] Em alguns exemplos, o demultiplexador 29 pode iterar através das estruturas de PTL para determinar as informações de PTL de cada uma das estruturas de PTL, por exemplo, valores para profile_idc[ptlIdx], tier_flag[ptlldx], e level_idc[ptlldx]. O demultiplexador 29 pode formar estruturas de dados representativas de cada uma das estruturas de PTL sinalizadas no descritor (ou seja, cada uma das estruturas de PTL correspondente a um dos valores de ptlldx). O demultiplexador 29 pode, ainda, recuperar valores para índices de referência de PTL para cada uma das camadas de cada um dos pontos de operação que mapeiam uma das camadas correspondentes a uma das estruturas de PTL para determinar as informações de perfil, categoria e nível para uma das camadas correspondentes. Por exemplo, ptl_ref_idx[opIdx][j] da Tabela Proposta Amd7-1 representa um exemplo de um elemento de sintaxe tendo um valor que mapeia a camada “j” de ponto de operação “opldx” para uma das estruturas de PTL.

[0279] Além disso, o demultiplexador 29 pode determinar conjuntos de camadas de saída para cada um dos pontos de operação (158). Por exemplo, o demultiplexador 29 pode determinar qual das camadas está incluída em um conjunto de camadas de saída para cada um dos pontos de operação a partir dos elementos de sintaxe target_ols[opIdx] da Tabela Proposta Amd7-1 discutida acima. Em um exemplo, o demultiplexador 29 recupera os valores para o elemento de sintaxe target_ols [opldx] para cada um dos pontos de operação do descritor, que especificam os conjuntos de camadas de saída alvo que são associados aos pontos de operação correspondentes.

[0280] Com base nas informações do descritor, o demultiplexador 29 seleciona um ponto de operação (160). Por exemplo, o demultiplexador 29 pode determinar um dos pontos de operação que podem ser decodificados pelo decodificador de vídeo 30. Um ponto de operação pode ser decodificado por um decodificador de vídeo quando o decodificador de vídeo suporta os elementos de perfil, categoria e nível aos quais os dados de vídeo do ponto de operação correspondem. Dessa forma, se o decodificador de vídeo 30 suportar pelo menos o perfil, categoria e nível do ponto de operação como indicado pelas informações de PTL do descritor, o demultiplexador 29 pode selecionar o ponto de operação. O demultiplexador 29 pode basear adicionalmente a seleção em outras características, como várias camadas de saída alvo em um conjunto de camadas de saída, por exemplo, como indicado pelas informações de conjunto de camadas de saída do descritor para o ponto de operação. Em particular, o demultiplexador 29 pode determinar se o dispositivo de exibição 32 pode renderizar um número de visualizações igual ao número de camadas de saída alvo para o ponto de operação. Se houver múltiplos pontos de operação que podem ser decodificados e exibidos, o demultiplexador 29 pode selecionar um ponto de operação com o perfil, categoria e nível mais alto que também inclui o maior número de visualizações que podem ser exibidas. Adicional ou alternativamente, o demultiplexador 29 pode receber a entrada de um usuário indicativa de um ponto de operação que será selecionado.

[0281] Dessa forma, em um exemplo, o demultiplexador 29 pode determinar um ou mais perfis de um padrão de codificação de vídeo que o decodificador de vídeo suporta, uma ou mais categorias de padrão de codificação de vídeo que o decodificador de vídeo suporta, e um ou mais níveis dentro da uma ou mais categorias que o decodificador de vídeo suporta e, então, seleciona um dos pontos de operação de modo que cada camada do um ou mais pontos de operação tenha um dos perfis que o decodificador de vídeo suporta, cada uma das camadas que um dos pontos de operação tem uma das categorias que o decodificador de vídeo suporta, e cada uma das camadas de um dos pontos de operação tem um dos níveis que o decodificador de vídeo suporta, como indicado pelas estruturas de PTL às quais as camadas do um dos pontos de operação correspondem.

[0282] O demultiplexador 29 pode, então, extrair os fluxos elementares correspondentes ao ponto de operação selecionado (162). Os fluxos elementares que serão extraídos podem incluir fluxos elementares que incluem dados para cada um dos conjuntos de camadas de saída alvo, bem como fluxos elementares que incluem dados dos quais os conjuntos de camadas de saída alvo dependem (por exemplo, para previsão temporal e/ou intervisualização). O demultiplexador 29 pode, então, enviar os fluxos elementares extraídos para o decodificador de vídeo 30 (164).

[0283] Dessa maneira, um método da Figura 9 representa um exemplo de um método que inclui extrair um descritor do fluxo de bits, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separado do descritor, de modo que cada ponto de operação inclua uma ou mais camadas de dados de vídeo, e em que o descritor inclui um conjunto de estruturas de perfil, categoria e nível (PTL) e dados que se associam a cada uma das camadas de cada um dos pontos de operação com uma das estruturas de PTL correspondentes, extrair dados de vídeo para um dos pontos de operação do fluxo de bits com base pelo menos em parte nas estruturas de PTL às quais as camadas de um ou mais pontos de operação correspondem, e fornecer os dados de vídeo extraídos a um decodificador de vídeo.

[0284] Deve ser reconhecido que, dependendo do exemplo, certos atos ou eventos de quaisquer uma dentre as técnicas descritas no presente documento podem ser realizados em uma sequência diferente, podem ser adicionados, fundidos ou deixados de fora todos juntos (por exemplo, nem todos os atos e eventos descritos são necessários para a prática das técnicas). Além disso, em certos exemplos, os atos ou eventos podem ser realizados de modo concorrente, por exemplo, através de processamento de múltiplos encadeamentos, processamento interrupto ou em múltiplos processadores, em vez de sequencialmente.

[0285] Em um ou mais exemplos, as funções descritas podem ser implantadas em hardware, software, firmware ou qualquer combinação dos mesmos. Caso implantado em software, as funções podem ser armazenadas ou transmitidas como uma ou mais instruções ou código em um meio legível por computador e executado por uma unidade de processamento com base em hardware. As mídias legíveis por computador podem incluir mídias de armazenamento legíveis por computador, que correspondem a uma mídia tangível tal como mídias de armazenamento de dados ou meios de comunicação que incluem qualquer mídia que facilite a transferência de um programa de computador de um lugar para outro, por exemplo, de acordo com um protocolo de comunicação. Dessa maneira, as mídias legíveis por computador, em geral, podem corresponder a (1) mídias de armazenamento legíveis por computador tangíveis que são não transitórias ou (2) um meio de comunicação tal como um sinal ou onda de portadora. As mídias de armazenamento de dados podem ser quaisquer mídias disponíveis que possam ser acessadas por um ou mais computadores ou um ou mais processadores para recuperar instruções, estruturas de código e/ou dados para a implantação das técnicas descritas nesta revelação. Um produto de programa de computador pode incluir uma mídia legível por computador.

[0286] A título de exemplo, e não de limitação, tais mídias de armazenamento legíveis por computador podem compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento de disco óptico, armazenamento de disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outro meio que possa ser usado para armazenar o código de programa desejado na forma de instruções ou estruturas de dados e que possa ser acessado por um computador. Além disso, qualquer conexão é apropriadamente denominada uma média legível por computador. Por exemplo, se as instruções forem transmitidas a partir de um sítio da Web, servidor ou outra fonte remota com o uso de um cabo coaxial, cabo de fibra óptica, par trançado, linha de inscrição digital (DSL) ou tecnologias sem fio tais como infravermelho, rádio e microonda, 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-onda estão incluídos na definição de mídia. Entretanto, deve ser compreendido que as mídias de armazenamento legíveis por computador e as mídias de armazenamento de dados não incluem conexões, ondas portadoras, sinais ou outras mídias transitórias, mas são, em vez disso, voltadas para mídias de armazenamento tangíveis não transitórias. Disco magnético e disco óptico, conforme usado no presente documento, incluem disco compacto (CD), disco laser, disco ótico, disco versátil digital (DVD), disquete e disco blu-ray, em que os discos magnéticos normalmente reproduzem os dados de modo magnético, enquanto os discos ópticos reproduzem os dados de modo óptico com lasers. As combinações dos supracitados também devem ser abrangidas pelo escopo de mídias legíveis por computador.

[0287] As instruções podem ser executadas por um ou mais processadores, tais como um ou mais processadores de sinal digital (DSPs), microprocessadores de propósito geral, circuitos integrados de aplicação específica (ASICs), arranjos lógicos programáveis em campo (FPGAs) ou outro conjunto de circuitos lógico discreto ou integrado equivalente. Portanto, o termo “processador”, conforme usado no presente documento pode se referir a qualquer uma das estruturas supracitadas ou qualquer outra estrutura adequada para a implantação dos conjuntos de procedimentos descritas no presente documento.Adicionalmente, em alguns aspectos, a funcionalidade descrita no presente documento pode ser fornecida dentro de módulos dedicados de hardware e/ou software configurados para cifrar e decodificar ou incorporados em um codec combinado. Além disso, as técnicas podem ser totalmente implantadas em um ou mais circuitos ou elementos lógicos.

[0288] Os conjuntos de procedimentos desta revelação podem ser implantados em uma ampla variedade de dispositivos ou aparelhos, incluindo um monofone 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 os aspectos funcionais de dispositivos configurados para realizar as técnicas reveladas, mas não exigem, necessariamente, a realização por diferentes unidades de hardware. Em vez disso, conforme descrito acima, várias unidades podem ser combinadas em uma unidade de hardware de codec ou fornecidas por uma coleção de unidades de hardware interoperativas, incluindo um ou mais processadores, conforme descrito acima, em conjunto com software e/ou firmware adequados.

[0289] Vários exemplos foram descritos. Essas e outras implantações estão contidas no escopo das reivindicações a seguir.

Claims (18)

1. Método de processamento de um fluxo de bits incluindo dados de vídeo de Codificação de Vídeo de Alta Eficiência, HEVC, caracterizado pelo fato de que compreende: extrair um descritor a partir do fluxo de bits (150), em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separados do descritor, de modo que cada ponto de operação inclua uma ou mais das camadas de dados de vídeo, em que extrair o descritor inclui: extrair um conjunto de estruturas de perfil, categoria e nível (PTL); e extrair dados que associam cada uma das camadas de cada um dos pontos de operação a uma das estruturas PTL correspondentes, em que os dados que associam cada uma das camadas a uma das estruturas PTL correspondentes são separados das estruturas PTL no descritor; extrair dados de vídeo para um dos pontos de operação a partir do fluxo de bits (162) com base pelo menos em parte nas estruturas PTL às quais as camadas de um dos pontos de operação correspondem; e fornecer os dados de vídeo extraídos a um decodificador de vídeo (164).

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que extrair os dados de vídeo (162) compreende: determinar um ou mais perfis de um padrão de codificação de vídeo que o decodificador de vídeo suporta, uma ou mais categorias do padrão de codificação de vídeo que o decodificador de vídeo suporta, e um ou mais níveis dentro de uma ou mais categorias que o decodificador de vídeo suporta; e selecionar um dos pontos de operação (160) de modo que cada uma das camadas de um dos pontos de operação selecionados tem um dos perfis que o decodificador de vídeo suporta, cada uma das camadas de um dos pontos de operação selecionados tem uma das categorias que o decodificador de vídeo suporta, e cada uma das camadas de um dos pontos de operação selecionados tem um dos níveis que o decodificador de vídeo suporta, conforme indicado pelas estruturas PTL às quais as camadas do um dos pontos de operação correspondem.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: iterar através das estruturas PTL para determinar pelo menos informações de perfil, informações de categoria, e informações de nível para cada uma das estruturas PTL; e para cada uma das camadas de cada um dos pontos de operação, restaurar, a partir do descritor, valores para índices de referência de PTL que mapeiam uma camada correspondente das camadas a uma das estruturas PTL para determinar as informações de perfil, categoria e nível para uma camada correspondente das camadas; ou determinar se o descritor está incluído no fluxo de bits com base em tipos de fluxo para um ou mais fluxos elementares de um programa do fluxo de bits; ou determinar que o descritor está incluído no fluxo de bits quando um tipo de fluxo para pelo menos um fluxo elementar de um programa do fluxo de bits tiver um valor de 0x27, 0x28, 0x29, ou 0x2A.

4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que: cada uma das estruturas PTL inclui dados representativos de um valor general_profile_space, um valor general_tier_flag, uma pluralidade de valores general profile_idc, um valor general profile_compatibility_flag[ i] para o iésimo valor general profile_idc, um valor general progressive_source_flag, um valor general interlaced_source_flag, um valor general non_packed_constraint_flag, um valor general frame_only_constraint_flag, um valor general reserved_zero_44bits, e um valor level_ idc; ou o descritor inclui informações para uma lista de pontos de operação, sendo que as informações incluem um conjunto de camadas de saída associadas para o ponto de operação correspondente, um esquema de particionamento associado para o ponto de operação correspondente, uma subcamada temporal mais alta para o ponto de operação correspondente, uma lista de fluxos elementares que constituem o ponto de operação correspondente, o número de camadas de saída para o ponto de operação correspondente, um mapeamento de camadas contidas em cada fluxo elementar do ponto de operação para as estruturas PTL, e informações de taxa de quadro para o ponto de operação correspondente.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que extrair os dados de vídeo (162) compreende: determinar um conjunto de camadas de saída para um dos pontos de operação (158) com base nos dados do descritor; extrair cada camada do conjunto de camadas de saída a partir do fluxo de bits; e extrair camadas nas quais as camadas do conjunto de camadas de saída dependem do fluxo de bits.

6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que: determinar o conjunto de camadas de saída (158) compreende restaurar, a partir do descritor, valores para elementos de sintaxe de conjunto de camadas de saída alvo para cada um dos pontos de operação, em que os elementos de sintaxe de conjunto de camadas de saída alvo especificam os conjuntos de camadas de saída alvo associados aos pontos de operação correspondentes; ou determinar o conjunto de camadas de saída (158) compreende restaurar, a partir do descritor, valores para flags para cada uma das camadas, em que os flags indicam se a camada correspondente é uma camada de saída.

7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente extrair informações que indicam um ou mais fluxos elementares de referência para pelo menos um fluxo elementar a partir do fluxo de bits.

8. Método, de acordo com a reivindicação 7, caracterizado pelo fato de que os dados de vídeo do um ou mais fluxos elementares de referência compreende dados de vídeo em um primeiro conjunto de uma ou mais camadas temporais, e em que os dados de vídeo do pelo menos um fluxo elementar compreende dados de vídeo de uma camada temporal que é superior às camadas temporais do primeiro conjunto.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que compreende adicionalmente: processar valores para bits de um elemento de sintaxe de bits de dimensão de extensão, em que pelo menos um bit do elemento de sintaxe de bits de dimensão de extensão tem um valor indicando que os dados de vídeo do pelo menos um fluxo elementar representa um aprimoramento temporal; ou processar um valor para um elemento de sintaxe hierarchy_type do descritor, em que o valor indica que um tipo para aprimoramento entre os dados de vídeo do fluxo elementar atual e o um ou mais fluxos elementares de referência é um tipo auxiliar.

10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que extrair o descritor compreende: extrair uma pluralidade de descritores a partir do fluxo de bits, cada um dos descritores sendo consecutivo no fluxo de bits e incluindo conjuntos respectivos de estruturas PTL e dados que associam cada uma das camadas de cada um dos pontos de operação com uma estrutura PTL correspondente das estruturas PTL; ou extrair um grupo de descritores que segue imediatamente um campo program_info_length de uma tabela de mapa de programa do fluxo de bits; ou extrair um grupo de descritores que segue imediatamente um campo ES_info_length de uma tabela de mapa de programa do fluxo de bits.

11. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o descritor compreende um descritor de nível de programa; ou um descritor de nível de fluxo elementar.

12. Dispositivo (14, 140, 30, 148) para processamento de um fluxo de bits incluindo dados de vídeo de Codificação de Vídeo de Alta Eficiência, HEVC, caracterizado pelo fato de que compreende: uma memória para armazenar dados extraídos a partir do fluxo de bits; e uma ou mais unidades de processamento configuradas para: extrair um descritor a partir do fluxo de bits, em que o fluxo de bits inclui camadas de dados de vídeo para pontos de operação, separados do descritor, de modo que cada ponto de operação inclua uma ou mais das camadas de dados de vídeo, em que para extrair o descritor, um ou mais processadores são configurados para: extrair um conjunto de estruturas de perfil, categoria e nível (PTL); e extrair dados que associam cada uma das camadas de cada um dos pontos de operação a uma estrutura PTL correspondente das estruturas PTL, em que os dados que associam cada uma das camadas a uma estrutura PTL correspondente das estruturas PTL são separados das estruturas PTL no descritor; extrair dados de vídeo para um dos pontos de operação a partir do fluxo de bits com base pelo menos em parte nas estruturas PTL às quais as camadas de um dos pontos de operação correspondem, e fornecer os dados de vídeo extraídos a um decodificador de vídeo.

13. Dispositivo (14, 140, 30, 148), de acordo com a reivindicação 12, caracterizado pelo fato de que a uma ou mais unidades de processamento são configuradas adicionalmente para: determinar um ou mais perfis de um padrão de codificação de vídeo que o decodificador de vídeo suporta, uma ou mais categorias do padrão de codificação de vídeo que o decodificador de vídeo suporta, e um ou mais níveis dentro da uma ou mais categorias que o decodificador de vídeo suporta; e selecionar um dos pontos de operação de modo que cada uma das camadas de um dos pontos de operação tenha um dos perfis que o decodificador de vídeo suporta, cada uma das camadas de um dos pontos de operação tenha uma das categorias que o decodificador de vídeo suporta, e cada uma das camadas de um dos pontos de operação tenha um dos níveis que o decodificador de vídeo suporta, conforme indicado pelas estruturas PTL às quais as camadas de um dos pontos de operação correspondem.

14. Dispositivo (14, 140, 30, 148), de acordo com a reivindicação 12, caracterizado pelo fato de que: o uma ou mais unidades de processamento são configuradas adicionalmente para: iterar através das estruturas PTL para determinar pelo menos informações de perfil, informações de categoria, e informações de nível para cada uma das estruturas PTL; e para cada uma das camadas de cada um dos pontos de operação, restaurar, a partir do descritor, valores para índices de referência de PTL que mapeiam uma camada correspondente das camadas para uma das estruturas PTL para determinar as informações de perfil, categoria, e nível para a camada correspondente das camadas; ou o descritor inclui informações para uma lista de pontos de operação, as informações incluindo um conjunto de camadas de saída associadas para o ponto de operação correspondente, um esquema de particionamento associado para o ponto de operação correspondente, uma subcamada temporal superior para o ponto de operação correspondente, uma lista de fluxos elementares que constitui o ponto de operação correspondente, o número de camadas de saída para o ponto de operação correspondente, um mapeamento de camadas contidas em cada fluxo elementar do ponto de operação às estruturas PTL, e informações de taxa de quadro para o ponto de operação correspondente.

15. Dispositivo (14, 140, 30, 148), de acordo com a reivindicação 12, caracterizado pelo fato de que a uma ou mais unidades de processamento são configuradas adicionalmente para: determinar um conjunto de camadas de saída para um dos pontos de operação com base nos dados do descritor; extrair cada camada do conjunto de camadas de saída a partir do fluxo de bits; e extrair camadas nas quais as camadas do conjunto de camadas de saída dependem do fluxo de bits.

16. Dispositivo (14, 140, 30, 148), de acordo com a reivindicação 15, caracterizado pelo fato de que para determinar o conjunto de camadas de saídas, um ou mais processadores são configurados para restaurar, a partir do descritor: valores para elementos de sintaxe de conjunto de camadas de saída alvo para cada um dos pontos de operação, em que os elementos de sintaxe de conjunto de camadas de saída alvo especificam o conjunto de camadas de saída alvos associados aos pontos de operação correspondentes; ou valores para flags para cada uma das camadas, em que os flags indicam se a camada correspondente é uma camada de saída.

17. Dispositivo (14, 140, 30, 148), de acordo com a reivindicação 12, caracterizado pelo fato de que uma ou mais unidades de processamento são configuradas adicionalmente para: extrair informações que indicam um ou mais fluxos elementares de referência para pelo menos um fluxo elementar a partir do fluxo de bits; ou extrair uma pluralidade de descritores a partir do fluxo de bits, cada um dos descritores sendo consecutivo no fluxo de bits e incluindo conjuntos de estruturas PTL respectivos e dados que associam cada uma das camadas de cada um dos pontos de operação a uma estrutura PTL correspondente das estruturas PTL.

18. Memória legível por computador caracterizada pelo 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 11.