BR112014010418B1

BR112014010418B1 - Acesso aleatório com gerenciamento de buffer de imagem decodificada avançada (dpb) na codificação de vídeo

Info

Publication number: BR112014010418B1
Application number: BR112014010418-2A
Authority: BR
Inventors: Ye-Kui Wang; Ying Chen; Jianle Chen
Original assignee: Qualcomm Incorporated
Priority date: 2011-10-31
Filing date: 2012-10-31
Publication date: 2022-05-24
Also published as: AU2016201877A1; JP2014535219A; EP2774365A1; ZA201403984B; JP5837216B2; WO2013067033A1; CA2852959A1; SI2774365T1; IL232069A; BR112014010418A2; MY167629A; HUE039675T2; RU2584491C2; IN2014CN03181A; AU2016201877B2; KR101597927B1; AU2012332567A1; US20160165237A1; PL2774365T3; EP2774365B1

Abstract

ACESSO ALEATÓRIO COM GERENCIAMENTO DE BUFFER DE FIGURA DECODIFICADA AVANÇADA (DPB) NA CODIFICAÇÃO DE VÍDEO. Como um exemplo, técnicas para decodificar dados de vídeo incluem receber um fluxo de bits que inclui uma ou mais imagens de uma sequência de vídeo codificada (CVS), decodificar uma primeira imagem de acordo com uma ordem de decodificação, em que a primeira imagem é a imagem de ponto de acesso aleatório (RAP) que não é uma imagem de atualização de decodificação instantânea (IDR), e decodificar pelo menos outra imagem seguinte a primeira imagem de acordo com a ordem de decodificação com base na primeira imagem decodificada. Como outro exemplo, técnicas para codificar dados de vídeo incluem gerar um fluxo de bits que inclui uma ou mais imagens de uma CVS, em que a primeira imagem de acordo com a ordem de decodificação é uma imagem de RAP que não é uma imagem de IDR, e evitar incluir pelo menos outra imagem, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem, no fluxo de bits.

Description

[0001] Este pedido reivindica o benefício do Pedido Provisório US N°. 61/553.802, depositado em 31 de outubro de 2011, e Pedido Provisório U.S. N°. 61/595.605, depositado em 6 de fevereiro de 2012, o conteúdo total dos quais são incorporados aqui por referência.

CAMPO TÉCNICO

[0002] Est a divulgação refere-se à codificação de vídeo, e, mais particularmente, aos quadros de codificação dos dados de vídeo gerados pelos processos de codificação de vídeo.

FUNDAMENTO

[0003] Capacidades de vídeo digitais podem ser incorporadas em uma ampla gama de dispositivos, incluindo televisores digitais, sistemas de radiodifusão digital direta, sistemas de transmissão sem fio, assistentes digitais pessoais (PDAs), computadores portáteis ou de mesa, computadores tablet, e-books, câmeras digitais, dispositivos de gravação digital, reprodutores de mídia digital, dispositivos de jogos de vídeo, videogames, telefones celulares ou de rádio por satélite, os chamados "smartphones", dispositivos de vídeo de teleconferência, dispositivos de streaming de vídeo, e assim por diante. Dispositivos de vídeo digitais implementam técnicas de compressão de vídeo, tais como aquelas descritas nos padrões definidos pelo MPEG-2, MPEG-4, ITU-T H.263, ITU-T H.264/MPEG-4, Parte 10, Codificação de Vídeo Avançada ("AVC"), o padrão de Codificação de Vídeo de Alta Eficiência (HEVC) atualmente em desenvolvimento, e extensões de tais padrões. Os dispositivos de vídeo podem transmitir, receber, codificar, decodificar, e/ou armazenar informações de vídeo digital de forma mais eficiente através da implementação de tais técnicas de compressão de vídeo.

[0004] As técnicas de compressão de vídeo executam a predição espacial (intra imagem) e/ou predição temporal (inter imagem) para reduzir ou remover a redundância inerente nas sequências de vídeo. Para a codificação de vídeo baseada em bloco, uma fatia de vídeo (isto é, um quadro de vídeo ou uma porção de um quadro de vídeo) pode ser dividida em blocos de vídeo, os quais também podem ser referidos como treeblocks, unidades de codificação (UC) e/ou nós de codificação. Blocos de vídeo em uma fatia intra-codificada (I) de uma imagem são codificados usando a predição espacial em relação às amostras de referência em blocos vizinhos na mesma imagem. Blocos de vídeo em uma fatia inter-codificada (P ou B) de uma imagem pode usar a predição espacial em relação às amostras de referência em blocos vizinhos da mesma imagem ou predição temporal com relação às amostras de referência em outras imagens de referência. As imagens podem ser referidas como quadros, e imagens de referência podem ser referidos para um quadro de referência.

[0005] A predição espacial ou temporal resulta em um bloco de predição para um bloco a ser codificado. Dados residuais representam diferenças de pixels entre o bloco original a ser codificado e o bloco de predição. Um bloco inter-codificado é codificado de acordo com um vetor de movimento que aponta para um bloco de amostras de referência que formam o bloco de predição, e os dados residuais, indicando a diferença entre o bloco codificado e o bloco de predição. O bloco intra-codificado é codificado de acordo com um modo de intra-codificação e os dados residuais. Para a compressão adicional, os dados residuais podem ser transformados a partir do domínio de pixel para um domínio de transformada, resultando em coeficientes de transformada residuais, que então podem ser quantificados. Os coeficientes de transformada quantificados, inicialmente dispostos em uma matriz bidimensional, podem ser verificados, a fim de produzir um vetor unidimensional de coeficientes de transformada. A codificação por entropia pode então ser aplicada para conseguir ainda mais compressão.

SUMÁRIO

[0006] Est a divulgação descreve técnicas para acesso aleatório na codificação de vídeo. Em particular, a divulgação descreve várias técnicas para codificação de sequências de vídeo que incluem um ou mais quadros, ou “imagens,” sendo que a primeira imagem codificada de uma sequência de vídeo codificada particular (CVS) em um fluxo de bits de conformação pode ser uma imagem de ponto de acesso aleatório (RAP) que não é uma imagem de atualização de decodificação instantânea (IDR). Por exemplo, de acordo com as técnicas, a primeira imagem codificada pode ser uma imagem de acesso aleatório limpa (CRA).

[0007] Como um exemplo, as técnicas desta divulgação podem permitir que um decodificador de vídeo de conformação às técnicas decodifique com sucesso um fluxo de bits começando a partir de tal imagem RAP não-IDR de uma maneira previsível e definida, ou “padrão”. Por exemplo, as técnicas divulgadas podem permitir que o decodificador de vídeo de conformação manipule várias saídas e propriedades de referência das chamadas “imagens principais” associadas com a primeira imagem codificada que também são incluídas no fluxo de bits. Como um resultado, as técnicas podem permitir acesso aleatório relativamente melhorado do fluxo de bits pelo decodificador de vídeo, em comparação com outras técnicas. Por exemplo, as técnicas podem facilitar o acesso aleatório “mais fino” ou mais granular, do fluxo de bits possibilitando que o decodificador de vídeo decodifique o fluxo de bits em relativamente mais pontos de partida, ou imagens de acesso (i.e., imagem de não-IDR) do fluxo de bits, em comparação com outras técnicas (ex., técnicas que permitem o acesso aleatório de um fluxo de bits somente a partir das imagens de IDR). Adicionalmente, as técnicas podem permitir que o decodificador de vídeo de conformação melhore a qualidade visual de uma ou mais das outras imagens também incluídas no fluxo de bits, ex., evitando produzir e/ou usar como imagens de referência as imagens principais associadas com a primeira imagem.

[0008] Alternativamente, como outro exemplo, as técnicas divulgadas podem permitir que um codificador de vídeo de conformação às técnicas gere um fluxo de bits que exclui as imagens principais associadas com a primeira imagem codificada do fluxo de bits que é a imagem RAP não- IDR. Como um resultado, um decodificador de vídeo também conforme às técnicas divulgadas pode decodificar com sucesso o fluxo de bits de uma maneira previsível e definida.

[0009] Dessa forma, usar as técnicas desta divulgação pode melhorar a interoperabilidade de codificação e decodificação de vídeo de sistemas e dispositivos, experiência do usuário, geralmente, por acesso aleatório de fluxo de bits, que pode ocorrer com frequência em várias aplicações de vídeo.

[0010] Em um exemplo da divulgação, um método de decodificação de dados de vídeo inclui receber um fluxo de bits compreendendo uma ou mais imagens de uma CVS, decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS, sendo que a primeira imagem é uma imagem de RAP que não é uma imagem de IDR, e decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0011] Em outro exemplo da divulgação, um método de codificar dados de vídeo inclui gerar um fluxo de bits compreendendo uma ou mais imagens de uma CVS, sendo que a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS é uma imagem de RAP que não é uma imagem de IDR, sendo que gerar um fluxo de bits compreende evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem, no fluxo de bits, sendo que a imagem principal compreende uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS, e sendo que a primeira imagem é decodificável, e sendo que pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, é decodificável com base na primeira imagem.

[0012] Em outro exemplo da divulgação, um equipamento configurado para decodificar dados de vídeo inclui um decodificador de vídeo configurado para receber um fluxo de bits compreendendo uma ou mais imagens de uma CVS, decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS, sendo que a primeira imagem é uma imagem de RAP que não é uma imagem de IDR, e decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0013] Em outro exemplo da divulgação, um equipamento configurado para codificar dados de vídeo inclui um codificador de vídeo configurado para gerar um fluxo de bits compreendendo uma ou mais imagens de uma CVS, sendo que a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS é uma imagem de RAP que não é uma imagem de IDR, sendo que para gerar um fluxo de bits, o codificador de vídeo é configurado para evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem, no fluxo de bits, sendo que a imagem principal compreende uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS, e sendo que a primeira imagem é decodificável, e sendo que pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, é decodificável com base na primeira imagem.

[0014] Em outro exemplo da divulgação, um dispositivo para decodificar dados de vídeo inclui meios para receber um fluxo de bits compreendendo uma ou mais imagens de uma CVS, meios para decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com uma CVS, sendo que a primeira imagem é uma imagem de RAP que não é uma imagem de IDR, e meios para decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0015] Em outro exemplo da divulgação, um dispositivo para codificar dados de vídeo inclui meios para gerar um fluxo de bits compreendendo uma ou mais imagens de uma CVS, sendo que a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS é uma imagem de RAP que não é uma imagem de IDR, sendo que a meios para gerar um fluxo de bits compreende meios para evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem, no fluxo de bits, sendo que a imagem principal compreende uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS, e sendo que a primeira imagem é decodificável, e sendo que pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, é decodificável com base na primeira imagem.

[0016] As técnicas descritas nesta divulgação podem ser implementadas em hardware, software, firmware, ou combinações dos mesmos. Se implementadas em hardware, um equipamento pode ser realizado como um circuito integrado, um processador, lógica discreta, ou qualquer combinação dos mesmos. Se implementadas em software, o software pode ser executado em um ou mais processadores, como um microprocessador, circuito integrado de aplicação específica (ASIC), arranjo de porta programável em campo (FPGA), ou processador de sinal digital (DSP). O software que executa as técnicas pode ser inicialmente armazenado em uma mídia legível por computador tangível e carregado e executado no processador.

[0017] Des sa forma, em outro exemplo, essa divulgação contempla uma mídia de armazenamento legível por computador armazenando instruções que, quando executadas, fazem com que um ou mais processadores recebam um fluxo de bits compreendendo uma ou mais imagens de uma CVS, decodifiquem uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS, sendo que a primeira imagem é uma imagem de RAP que não é uma imagem de IDR, e decodifiquem pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0018] Em outro exemplo, essa divulgação contempla uma mídia de armazenamento legível por computador armazenando instruções que, quando executadas, fazem com que um ou mais processadores gerem um fluxo de bits compreendendo uma ou mais imagens de uma CVS, sendo que a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS é uma imagem de RAP que não é uma imagem de IDR, sendo que a instruções que fazem com que um ou mais processadores gerem um fluxo de bits compreendem instruções que fazem com que um ou mais processadores evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem, no fluxo de bits, sendo que a imagem principal compreende uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS, e sendo que a primeira imagem é decodificável, e sendo que pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, é decodificável com base na primeira imagem.

[0019] Os detalhes de um ou mais exemplos são apresentados nos desenhos anexos, e descrição abaixo. Outras características, objetos e vantagens serão evidentes a partir da descrição e desenhos, e a partir das reivindicações.

BREVE DESCRIÇÃO DOS DESENHOS

[0020] FIG. 1 é um diagrama em bloco que ilustra um exemplo de um sistema de codificação e decodificação de vídeo que pode realizar técnicas para acesso aleatório com gestão de tampão de imagem de decodificador avançado (DPB), de acordo com as técnicas desta divulgação.

[0021] FIG. 2 é um diagrama em bloco que ilustra um exemplo de um codificador de vídeo que pode realizar as técnicas para acesso aleatório com gestão de DPB avançada, de acordo com as técnicas desta divulgação.

[0022] FIG. 3 é um diagrama em bloco que ilustra um exemplo de um decodificador de vídeo que pode realizar as técnicas para acesso aleatório com gestão de DPB avançada, de acordo com as técnicas desta divulgação.

[0023] FIG. 4 é um diagrama conceitual que ilustra um exemplo de hierarquias de referência dentre as imagens dos grupos de imagens (GOPs) de dados de vídeo, de acordo com as técnicas desta divulgação.

[0024] FIG. 5 é um fluxograma que ilustra um método exemplar de realização de acesso aleatório de um fluxo de bits que inclui uma ou mais imagens de dados de vídeo por um decodificador de vídeo, de acordo com as técnicas desta divulgação.

[0025] FIG. 6 é um fluxograma que ilustra um método exemplar de gerar um fluxo de bits que inclui uma ou mais imagens de dados de vídeo por um codificador de vídeo, de acordo com as técnicas desta divulgação.

DESCRIÇÃO DETALHADA

[0026] Est a divulgação descreve técnicas para acesso aleatório na codificação de vídeo. Em particular, a divulgação descreve várias técnicas para codificação de sequências de vídeo que incluem um ou mais quadros, ou “imagens,” sendo que a primeira imagem codificada de uma sequência de vídeo codificada particular (CVS) em um fluxo de bits de conformação pode ser uma imagem de ponto de acesso aleatório (RAP) que não é uma imagem de atualização de decodificação instantânea (IDR). Por exemplo, de acordo com as técnicas, a primeira imagem codificada pode ser uma imagem de acesso aleatório limpa (CRA).

[0027] Como um exemplo, as técnicas desta divulgação podem permitir que um decodificador de vídeo de acordo com as técnicas decodifique com sucesso um fluxo de bits começando a partir de tal imagem RAP não-IDR de uma maneira previsível e definida, ou “padrão”. Por exemplo, as técnicas divulgadas podem permitir que o decodificador de vídeo de conformação manipule várias saídas e propriedades de referência das chamadas “imagens principais” associadas com a primeira imagem codificada que também são incluídas no fluxo de bits. Como um resultado, as técnicas podem permitir acesso aleatório relativamente melhorado do fluxo de bits pelo decodificador de vídeo, em comparação com outras técnicas. Por exemplo, as técnicas podem facilitar o acesso aleatório “mais fino” ou mais granular, do fluxo de bits permitindo que o decodificador de vídeo decodifique o fluxo de bits em relativamente mais pontos de partida, ou imagens de acesso (i.e., imagem de não-IDR) do fluxo de bits, em comparação com outras técnicas (ex., técnicas que permitem acesso aleatório de um fluxo de bits somente a partir das imagens de IDR). Adicionalmente, as técnicas podem permitir que o decodificador de vídeo de conformação melhore a qualidade visual de uma ou mais das outras imagens também incluídas no fluxo de bits, ex., evitando produzir e/ou usar como imagens de referência as imagens principais associada com a primeira imagem.

[0028] Alternativamente, como outro exemplo, as técnicas divulgadas podem permitir que um codificador de vídeo de acordo com as técnicas gere um fluxo de bits que exclui imagens principais associadas com a primeira imagem codificada do fluxo de bits que é a imagem RAP não-IDR. Como um resultado, um decodificador de vídeo também conforme às técnicas divulgadas pode decodificar com sucesso o fluxo de bits de uma maneira previsível e definida.

[0029] Dessa forma, usar as técnicas desta divulgação pode melhorar a interoperabilidade de sistemas e dispositivos de codificação e decodificação, e experiência de usuário, geralmente, para acesso aleatório do fluxo de bits, que pode ocorrer com frequência em várias aplicações de vídeo.

[0030] Especificamente, as técnicas descritas aqui podem incluir pelo menos um ou mais dos novos aspectos a seguir, em comparação com outras técnicas: (1) detectar uma ocorrência de acesso aleatório a partir da imagem RAP não-IDR (ex., uma imagem de CRA); 2) identificar e decodificar uma ou mais imagens que seguem a imagem RAP não-IDR em uma ordem de decodificação, mas precede a imagem RAP não-IDR em uma ordem de saída (i.e., uma ou mais “imagens principais” da imagem RAP não-IDR); e (3) especificar que cada de uma ou mais imagens principais da imagem RAP não-IDR não é produzida mesmo no caso de um elemento de sintaxe sinalizado correspondente output_flag é igual a verdade, ou “1” (i.e., a output_flag identifica que a respectiva imagem deve ser produzida), e que a respectiva imagem não é usada como uma imagem de referência para quaisquer outras imagens que seguem a imagem RAP não-IDR na ordem de decodificação e a ordem de saída.

[0031] Desta maneira, um fluxo de bits que inclui uma ou mais imagens de dados de vídeo e começa com uma imagem RAP não-IDR pode ser decodificado de uma maneira previsível e definida por um decodificador de vídeo de acordo com as técnicas desta divulgação. Alternativamente, um codificador de vídeo de acordo com as técnicas divulgadas pode gerar um fluxo de bits que inclui uma ou mais imagens de dados de vídeo e começa com uma imagem RAP não-IDR, tal que o fluxo de bits pode ser decodificado de uma maneira previsível e definida por um decodificador de vídeo também de acordo com as técnicas. Como um resultado, pode haver uma melhoria relativa na experiência do usuário ao realizar o acesso aleatório de um fluxo de bits que inclui uma ou mais imagens de dados de vídeo, ao usar as técnicas desta divulgação. Em particular, pode haver uma melhoria relativa na granularidade do acesso aleatório, assim como na qualidade visual de uma ou mais imagens do fluxo de bits, e/ou de uma CVS que inclui as uma ou mais imagens como um todo, ao usar as técnicas divulgadas.

[0032] FIG. 1 é um diagrama em bloco que ilustra um exemplo de um sistema de codificação e decodificação de vídeo que pode realizar técnicas para acesso aleatório com gestão de tampão de imagem de decodificador avançado (DPB), de acordo com as técnicas desta divulgação. Como mostrado na FIG. 1, o sistema 10 inclui um dispositivo de origem 12 que gera dados de vídeo codificados a serem decodificados em um momento posterior por um dispositivo de destino 14. O dispositivo de origem 12 e dispositivo de destino 14 podem incluir qualquer de uma ampla gama de dispositivos, incluindo computadores de mesa, computadores notebook (laptop), computadores tablet, decodificadores, aparelhos de telefone chamados "smartphones", televisores, câmeras, dispositivos de exibição, reprodutores de mídia digital, consoles de videogame, dispositivos de streaming de vídeo, ou similares. Em alguns casos, o dispositivo de origem 12 e dispositivo de destino 14 podem ser equipados para comunicação remota.

[0033] Dispositivo de destino 14 pode receber os dados de vídeo codificados a serem decodificados através de um link 16. O link 16 pode compreender qualquer tipo de mídia ou dispositivo capaz de mover os dados de vídeo codificados a partir do dispositivo de origem 12 para o dispositivo de destino 14. Em um exemplo, o link 16 pode compreender uma mídia de comunicação para permitir que o dispositivo de origem 12 transmita dados de vídeo codificados diretamente para o 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, como um protocolo de comunicação sem fio, e transmitidos para o dispositivo de destino 14. O meio de comunicação pode compreender qualquer meio de comunicação sem fio ou com fio, como um espectro de frequência de rádio (RF) ou uma ou mais linhas de transmissão física. O meio de comunicação pode fazer parte de uma rede a base de pacote, como uma rede de área local, rede de área ampla, ou uma rede global, tal como a Internet. O meio de comunicação pode incluir roteadores, switches, estações base, ou qualquer outro equipamento que pode ser útil para facilitar a comunicação a partir do dispositivo de origem 12 para o dispositivo de destino 14.

[0034] Alternativamente, dados codificados podem ser produzidos a partir da interface de saída 22 para um dispositivo de armazenamento 24. Similarmente, dados codificados podem ser acessados a partir do dispositivo de armazenamento 24 pela interface de entrada 26. Dispositivo de armazenamento 24 pode incluir qualquer de uma variedade de mídia de armazenamento de dados distribuída ou acessada 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 qualquer mídia de armazenamento digital adequado para armazenar dados de vídeo codificados. Em um exemplo adicional, dispositivo de armazenamento 24 pode corresponder a um servidor de arquivo ou outro dispositivo de armazenamento intermediário que pode manter o vídeo codificado gerado pelo dispositivo de origem 12. Dispositivo de destino 14 pode acessar dados de vídeo armazenados a partir do dispositivo de armazenamento 24 através de streaming ou download. O servidor de arquivo pode ser qualquer tipo de servidor capaz de armazenar dados de vídeo codificados e transmitir aqueles dados de vídeo codificados para o dispositivo de destino 14. Servidores de arquivo exemplares incluem um servidor da web (ex., para um website), um servidor de FTP, dispositivos de armazenamento anexos à rede (NAS), ou uma unidade de disco local. O dispositivo de destino 14 pode acessar os dados de vídeo codificados através de qualquer conexão de dados padrão, incluindo uma conexão da Internet. Isto pode incluir um canal sem fio (ex., uma conexão Wi-Fi), uma conexão com fio (ex., DSL, modem a cabo, etc.), ou uma combinação de ambas que é adequada para acessar dados de vídeo codificados armazenados em um servidor de arquivo. A transmissão de dados de vídeo codificados a partir dos dispositivos de armazenamento 24 pode ser uma transmissão de streaming, uma transmissão por download, ou uma combinação de ambas.

[0035] As técnicas desta divulgação não são necessariamente limitadas às aplicações ou ajustes sem fio. As técnicas podem ser aplicadas à codificação de vídeo em apoio de qualquer uma de uma variedade de aplicações de multimídia, como transmissões de TV através do ar, transmissões de televisão a cabo, transmissões de televisão via satélite, transmissões de streaming de vídeo, ex., através da Internet, codificação de vídeo digital para armazenamento em um meio de armazenamento de dados, decodificação de vídeo digital armazenado em um meio de armazenamento de dados ou outras aplicações. Em alguns exemplos, o sistema 10 pode ser configurado para suportar a transmissão de vídeo de uma via ou de duas vias para suportar aplicações como streaming de vídeo, reprodução de vídeo, transmissão de vídeo, e/ou telefonia por vídeo.

[0036] No exemplo da FIG. 1, o dispositivo de origem 12 inclui uma fonte de vídeo 18, codificador de vídeo 20 e uma interface de saída 22. Em alguns casos, a interface de saída 22 pode incluir um modulador/demodulador (modem) e/ou um transmissor. No dispositivo de origem 12, a fonte de vídeo 18 pode incluir uma fonte como um dispositivo de captura de vídeo, ex., uma câmera de vídeo, um arquivo de vídeo contendo o vídeo capturado anteriormente, uma interface de alimentação de vídeo para receber vídeo de um provedor de conteúdo de vídeo, e/ou um sistema de gráficos de computador para gerar dados de gráficos de computador como o vídeo fonte, ou uma combinação de tais fontes. Como um exemplo, se a fonte de vídeo 18 é uma câmera de vídeo, dispositivo de origem 12 e dispositivo de destino 14 podem formar os chamados telefones de câmera ou telefones de vídeo. No entanto, as técnicas descritas nesta divulgação podem ser aplicáveis à codificação de vídeo em geral, e podem ser aplicadas às aplicações remotas e/ou com fio.

[0037] O vídeo capturado, pré-capturado ou gerado por computador pode ser codificado pelo codificador de vídeo 20. Os dados de vídeo codificados podem ser transmitidos diretamente para o dispositivo de destino 14 através da interface de saída 22 do dispositivo de origem 12. Os dados de vídeo codificados também podem (ou alternativamente) ser armazenados sobre o dispositivo de armazenamento 24 para acesso posterior pelo dispositivo de destino 14 ou outros dispositivos, para decodificação e/ou reprodução.

[0038] Dispositivo de destino 14 inclui uma interface de entrada 26, um decodificador de vídeo 30, e um dispositivo de exibição 28. Em alguns casos, a interface de entrada 26 pode incluir um receptor e/ou um modem. A interface de entrada 26 do dispositivo de destino 14 recebe os dados de vídeo codificados através do link 16 ou a partir do dispositivo de armazenamento 24. Os dados de vídeo codificados comunicados através do link 16, ou fornecidos no dispositivo de armazenamento 24, podem incluir uma variedade de elementos de sintaxe gerados pelo codificador de vídeo 20 para uso por um decodificador de vídeo, como decodificador de vídeo 30, na decodificação dos dados de vídeo. Tais elementos de sintaxe podem ser incluídos com os dados de vídeo codificados transmitidos sobre um meio de comunicação, armazenados em uma mídia de armazenamento, ou armazenados em um servidor de arquivo.

[0039] Dispositivo de exibição 28 pode ser integrado com, ou ser externo ao, dispositivo de destino 14. Em alguns exemplos, dispositivo de destino 14 pode incluir um dispositivo de exibição integrado e também ser configurado para interface com um dispositivo de exibição externo. Em outros exemplos, o dispositivo de destino 14 pode ser um dispositivo de exibição. Em geral, o dispositivo de exibição 28 exibe os dados de vídeo decodificados para um usuário, e pode compreender qualquer de uma variedade de dispositivos de exibição como um monitor de cristal líquido (LCD), um monitor de plasma, um monitor de diodo emissor de luz orgânica (OLED), ou outro tipo de dispositivo de exibição.

[0040] Codificador de vídeo 20 e decodificador de vídeo 30 podem funcionar de acordo com um padrão de compressão de vídeo, como o Padrão de Codificação de Vídeo de Alta Eficiência (HEVC) atualmente em desenvolvimento pela Equipe Colaborativa Conjunta sobre Codificação de vídeo (JCT-VC) do Grupo de Especialistas de Codificação de Vídeo ITU-T (VCEG) e Grupo de Especialistas da Imagem em Movimento ISO/IEC (MPEG), e pode estar em conformidade ao Modelo de Teste de HEVC (HM). Alternativamente, o codificador de vídeo 20 e decodificador de vídeo 30 podem funcionar de acordo com outros padrões proprietários ou da indústria, como o padrão ITU-T H.264, alternativamente referido como MPEG-4, Parte 10, AVC, ou extensão de tais padrões. As técnicas desta divulgação, no entanto, não são limitadas a qualquer padrão de codificação particular. Outros exemplos de padrão de compressão de vídeos incluem MPEG-2 e ITU-T H.263. Um esboço recente do padrão de HEVC, referido como “Esboço de Trabalho de HEVC 8” ou “WD8,” é descrito no documento JCTVC-J1003_d7, Bross et al., “esboço da especificação de texto da codificação de vídeo de alta eficiência 8 (HEVC)”, Equipe Colaborativa Conjunta sobre Codificação de vídeo (JCT-VC) de ITU-T SG16 WP3 e ISO/IEC JTC1/SC29/WG11, 10° Encontro: Estocolmo, SE, 11-20 de Julho de 2012, o qual, como o de 17 de outubro de 2012, pode ser baixado na http://phenix.int- evry.fr/jct/doc_end_user/documents/10_Stockholm/wg11/JCTVC- J1003-v8.zip.

[0041] Outro esboço do padrão HEVC, referido nesta divulgação como “Esboço de Trabalho de HEVC 4” ou “WD4,” é descrito no documento JCTVC-F803, Bross et al., “WD4: Esboço de Trabalho 4 da Codificação de Vídeo de Alta Eficiência,” Equipe Colaborativa Conjunta sobre Codificação de vídeo (JCT-VC) de ITU-T SG16 WP3 e ISO/IEC JTC1/SC29/WG11, 6° Encontro: Torino, IT, 14-22 de Julho de 2011, os quais, como os de 11 de outubro de 2012, podem ser baixados na http://phenix.int-evry.fr/jct/doc_end_user/documents/6_Torino/wg11/JCTVC- F803-v8.zip.

[0042] Ainda outro esboço do padrão HEVC, referido nesta divulgação como “Esboço de Trabalho de HEVC 5” ou “WD5,” é descrito no documento JCTVC-G1103, Bross et al., “WD5: Esboço de Trabalho 5 da Codificação de Vídeo de Alta Eficiência,” Equipe Colaborativa Conjunta sobre Codificação de vídeo (JCT-VC) de ITU-T SG16 WP3 e ISO/IEC JTC1/SC29/WG11, 7° Encontro: Geneva, CH, 21-30 de novembro de 2011, os quais, com os de 17 de outubro de 2012, podem ser baixados na http://phenix.int-evry.fr/jct/doc_end_user/documents/7_Geneva/wg11/JCTVC- G1103-v12.zip.

[0043] Embora não mostrado na FIG. 1, em alguns aspectos, o codificador de vídeo 20 e decodificador de vídeo 30 podem cada ser integrados com um codificador e decodificador de áudio, e podem incluir unidades de MUX- DEMUX adequadas, ou outro hardware e software, para manejar a codificação tanto de áudio quanto de vídeo em um fluxo de dados comum ou fluxos de dados separados. Se aplicável, em alguns exemplos, unidades de MUX-DEMUX podem estar em conformidade com o protocolo multiplexador ITU H.223, ou outros protocolos como o protocolo de datagrama de usuário (UDP).

[0044] Codificador de vídeo 20 e decodificador de vídeo 30 cada pode ser implementado como qualquer de uma variedade de circuitos de codificador ou decodificador adequado, como um ou mais microprocessadores, processadores de sinal digital (DSPs), circuitos integrados de aplicação específica (ASICs), arranjos de porta programáveis em campo (FPGAs), lógica discreta, software, hardware, firmware ou qualquer combinação dos mesmos. quando as técnicas são implementadas parcialmente em software, um dispositivo pode armazenar instruções para o software em uma mídia legível por computador não transitória adequada e executar as instruções em hardware usando um ou mais processadores para realizar as técnicas desta divulgação. Cada um do codificador de vídeo 20 e decodificador de vídeo 30 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um codificador/decodificador combinado ("CODEC") em um respectivo dispositivo.

[0045] Os esforços de padronização de HEVC são baseados em um modelo em evolução de um dispositivo de codificação de vídeo referido como o Modelo de Teste de HEVC (HM). O HM presume algumas capacidades adicionais dos dispositivos de codificação de vídeo em relação aos dispositivos existentes de acordo com, ex., ITU-T H.264/AVC. Por exemplo, enquanto que H.264 fornece nove modos de codificação intra-predição, o HM pode fornecer até trinta e cinco modos de codificação intra-predição.

[0046] Em geral, o modelo de trabalho do HM descreve que um quadro de vídeo ou imagem pode ser dividido em uma sequência de treeblocks ou unidades de codificação maiores (LCU) que incluem ambas amostras luma e croma. Um treeblock tem uma finalidade similar como um macrobloco do padrão H.264. Uma fatia inclui um número de treeblocks consecutivos na ordem de codificação. Um quadro de vídeo ou imagem pode ser dividido em uma ou mais fatias. Cada treeblock pode ser dividido em unidades de codificação (CUs) de acordo com um quadtree. Por exemplo, um treeblock, como um nó raiz do quadtree, pode ser dividido em quatro nós crianças, e cada nó criança pode por sua vez ser um nó pai e ser dividido em outros quatro nós crianças. Um nó criança final, não dividido, como um nó folha do quadtree, compreende um nó de codificação, i.e., um bloco de vídeo codificado. Dados de sintaxe associados com um fluxo de bits codificado podem definir um número máximo de vezes que um treeblock pode ser dividido, e pode também definir um tamanho mínimo dos nós de codificação.

[0047] Uma CU inclui um nó de codificação e unidades de predição (PUs) e unidades de transformada (TUs) associadas com um nó de codificação. Um tamanho da CU corresponde a um tamanho do nó de codificação e deve ser quadrado na forma. O tamanho da CU pode variar de 8x8 pixels até o tamanho do treeblock com um máximo de 64x64 pixels ou maior. Cada CU pode conter uma ou mais PUs e uma ou mais TUs. Dados de sintaxe associados com uma CU podem descrever, por exemplo, divisão do CU em uma ou mais PUs. Modos de divisão podem diferir entre quando a CU é pulada ou codificada de modo direto, codificada por modo de intra- predição, ou codificada por modo de inter-predição. As PUs podem ser divididas para serem não quadradas na forma. Dados de sintaxe associados com uma CU podem também descrever, por exemplo, a divisão da CU em uma ou mais TUs de acordo com um quadtree. Uma TU pode ser quadrada ou não quadradas na forma.

[0048] O padrão HEVC permite as transformações de acordo com as TUs, que podem ser diferentes para CUs diferentes. As TUs são tipicamente dimensionadas com base no tamanho das PUs dentro de uma dada CU definida para a LCU dividida, embora este possa não ser o caso sempre. As TUs são tipicamente do mesmo tamanho ou menores do que as PUs. Em alguns exemplos, amostras residuais correspondente a uma CU podem ser subdivididas em unidades menores usando uma estrutura de quadtree conhecida como "quad tree residual" (RQT). Os nós folhas do RQT podem ser referidos como TUs. Valores de diferença de pixel associados com as TUs podem ser transformados para produzir coeficientes de transformada, que podem ser quantizados.

[0049] Em geral, uma PU inclui dados relacionados ao processo de predição. Por exemplo, quando a PU é codificada intra-modo, a PU pode incluir dados que descrevem um modo de intra-predição para a PU. Como outro exemplo, quando a PU é codificada inter-modo, a PU pode incluir dados que definem um vetor de movimento para a PU. Os dados que definem o vetor de movimento para uma 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 (ex., 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/or uma lista de imagem de referência (ex., Lista 0, Lista 1, ou Lista C) para o vetor de movimento.

[0050] Em geral, uma TU é usada para os processos de transformada e quantização. Uma dada CU tendo uma ou mais PUs pode também incluir uma ou mais TUs. Seguindo a predição, o codificador de vídeo 20 pode calcular valores residuais correspondentes à PU. Os valores residuais compreendem valores de diferença de pixel que podem ser transformados em coeficientes de transformada, quantizados, e escaneados usando as TUs para produzir coeficientes de transformada em série para codificação da entropia. esta especificação tipicamente usa o termo “bloco de vídeo,” ou simplesmente “bloco,” para se referir a um nó de codificação de uma CU. Em alguns casos específicos, esta divulgação pode também usar o termo “bloco de vídeo” para se referir a um treeblock, i.e., LCU, ou uma CU, que inclui um nó de codificação e PUs e TUs.

[0051] Uma sequência de vídeo tipicamente inclui uma série de quadros de vídeo ou imagens. Um grupo de imagens (GOP) geralmente compreende uma série de uma ou mais das imagens de vídeo. Um GOP pode incluir dados de sintaxe em um cabeçalho do GOP, um cabeçalho de uma ou mais das imagens, ou em outro lugar, que descreve um número de imagens incluídas no GOP. Cada fatia de uma imagem pode incluir dados de sintaxe de fatia que descrevem um modo de codificação para a respectiva fatia. O codificador de vídeo 20 tipicamente opera nos blocos de vídeo dentro de fatias de vídeo individuais a fim de codificar os dados de vídeo. Um bloco de vídeo pode corresponder 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.

[0052] Como um exemplo, o HM suporta a predição em vários tamanhos de PU. Assumindo que o tamanho de uma particular CU é 2Nx2N, o HM suporta a intra-predição nos tamanhos de PU de 2Nx2N ou NxN, e inter-predição nos tamanhos simétricos de PU de 2Nx2N, 2NxN, Nx2N, ou NxN. O HM também suporta a divisão assimétrica para a inter- predição nos tamanhos de PU de 2NxnU, 2NxnD, nLx2N, e nRx2N. Na divisão assimétrica, uma direção de uma CU não é dividida, enquanto a outra direção é dividida em 25% e 75%. A porção da CU correspondente à 25% de divisão é indicada por um “n” seguida por uma indicação de “Cima”, “Baixo,” “Esquerda,” ou “Direita.” Então, por exemplo, “2NxnU” refere-se a uma 2Nx2N CU que é dividida horizontalmente com uma 2Nx0.5N PU no topo e uma 2Nx1.5N PU no fundo.

[0053] Nesta divulgação, “NxN” e “N por N” podem ser usados indistintamente para se referir às dimensões de pixel de um bloco de vídeo em termos de dimensões vertical e horizontal, ex., 16x16 pixels ou 16 por 16 pixels. Em geral, um bloco de 16x16 terá 16 pixels em uma direção vertical (y = 16) e 16 pixels em uma direção horizontal (x = 16). Da mesma forma, um bloco NxN geralmente tem N pixels em uma direção vertical e N pixels em uma direção horizontal, onde N representa um valor inteiro não negativo. Os pixels em um bloco podem ser arranjados em fileiras e colunas. Além disso, os blocos não precisam necessariamente ter o mesmo número de pixels na direção horizontal como na direção vertical. Por exemplo, blocos podem compreendem NxM pixels, onde M não é necessariamente igual a N.

[0054] Seguindo a codificação intra-predita ou inter-predita usando as PUs de uma CU, codificador de vídeo 20 pode calcular dados residuais para as TUs da CU. As PUs podem compreendem dados de pixel no domínio espacial (também referido como o domínio de pixel) e as TUs podem compreender coeficientes no domínio de transformada após a aplicação de uma transformada, ex., uma transformada de cosseno discreta (DCT), uma transformada de inteiro, uma transformada wavelet, ou uma transformada conceitualmente similar para dados de vídeo residuais. Os dados residuais podem corresponder às diferenças de pixel entre pixels da imagem não codificada e valores de predição correspondente às PUs. Codificador de vídeo 20 pode formar as TUs incluindo os dados residuais para a CU, e então transformar as TUs para produzir coeficientes de transformada para a CU.

[0055] Depois de quaisquer transformadas para produzir coeficientes de transformada, codificador de vídeo 20 pode realizar a quantização dos coeficientes de transformada. A quantização geralmente refere-se a um processo no qual os coeficientes de transformada são quantizados para possivelmente reduzir a quantidade de dados usada para representar os coeficientes, fornecendo compressão adicional. O processo de quantização pode reduzir a profundidade de bit associada com alguns ou todos dos coeficientes. Por exemplo, um valor de n-bit pode ser arredondado para baixo para um valor de m-bit durante a quantização, onde n é maior do que m.

[0056] Em alguns exemplos, codificador de vídeo 20 pode utilizar uma varredura predefinida, ou ordem de “varredura” para varrer os coeficientes de transformada quantizados para produzir um vetor serializado que pode ser codificado por entropia. Em outros exemplos, o codificador de vídeo 20 pode realizar uma varredura adaptativa. Após a varredura dos coeficientes de transformada quantizados para formar um vetor unidirecional, o codificador de vídeo 20 pode codificar por entropia o vetor unidirecional, ex., de acordo com codificação de comprimento variável adaptativa ao contexto (CAVLC), codificação aritmética binária adaptativa ao contexto (CABAC), codificação aritmética binária adaptativa ao contexto com base na sintaxe (SBAC), A codificação de Entropia de Divisão de Intervalo de Probabilidade (PIPE), ou outra metodologia de codificação por entropia. Codificador de vídeo 20 pode também codificar por entropia elementos de sintaxe associados com os dados de vídeo codificados para uso pelo decodificador de vídeo 30 na decodificação dos dados de vídeo.

[0057] Para realizar CABAC, o codificador 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 referir a, por exemplo, quando ou não valores vizinhos do símbolo são zero. Para realizar CAVLC, o codificador de vídeo 20 pode selecionar um código de comprimento variável para um símbolo a ser transmitido. Palavras código no VLC podem ser construídos de tal forma que os códigos relativamente curtos correspondem a símbolos mais prováveis, enquanto os códigos relativamente mais longos correspondem aos símbolos menos prováveis. Desta maneira, o uso do VLC pode atingir uma economia de bit durante, por exemplo, o uso de palavras código de comprimentos iguais para cada símbolo a ser transmitido. A determinação da probabilidade pode ser com base em um contexto atribuído ao símbolo.

[0058] Em alguns exemplos, as técnicas desta divulgação são direcionadas para o acesso aleatório na codificação de vídeo. Em particular, esta divulgação descreve várias técnicas para codificação de sequências de vídeo que incluem um ou mais quadros, ou imagens, sendo que a primeira imagem codificada de uma CVS particular em um fluxo de bits de conformação pode ser uma imagem de RAP que não é uma imagem de IDR. Por exemplo, de acordo com as técnicas divulgadas, a primeira imagem codificada pode ser uma imagem de CRA.

[0059] Em outras palavras, um fluxo de bits que inclui uma ou mais imagens de uma CVS, sendo que a primeira imagem codificada do fluxo de bits é uma imagem RAP não-IDR, pode ser considerada um fluxo de bits “conformação” de acordo com as técnicas desta divulgação. Dito de outra forma, um decodificador de vídeo que de acordo com as técnicas divulgadas pode decodificar tal fluxo de bits com sucesso e de uma maneira previsível e definida. Especificamente, as técnicas desta divulgação incluem métodos de manuseio, pelo decodificador de vídeo, a decodificação, assim como a saída e propriedades de referência, das imagens principais associada com a primeira imagem codificada. Alternativamente, as técnicas também incluem gerar, por um codificador de vídeo, um fluxo de bits de conformação que exclui imagens principais associadas com a primeira imagem codificada do fluxo de bits que é uma imagem RAP não-IDR a partir do fluxo de bits, tal que o fluxo de bits pode ser decodificado com sucesso por um decodificador de vídeo de uma maneira previsível e definida.

[0060] Nesta divulgação, uma imagem de IDR de uma CVS pode geralmente se referir a uma imagem incluída dentro da CVS que é codificada usando a codificação intra- predita, i.e., uma imagem “I” codificada sem se referir a qualquer outra imagem dentro ou for a da CVS. Adicionalmente, a imagem de IDR pode se referir a uma imagem para a qual todas as outras imagens incluídas dentro da CVS seguindo uma imagem de IDR de acordo com uma ordem de decodificação associada com a CVS são decodificadas sem referência a quaisquer imagens que precedem uma imagem de IDR de acordo com a ordem de decodificação. Por exemplo, de acordo com algumas técnicas (ex., H.264/MPEG-4 Parte 10/AVC; doravante “H.264/AVC”), uma CVS pode incluir uma imagem de IDR como a primeira imagem da CVS de acordo com uma ordem de decodificação associada com a CVS, assim como uma ou mais imagens de IDR adicionais. Como um exemplo, a CVS pode incluir uma ou mais GOPs, sendo que cada GOP começa com uma imagem de IDR, seguida por uma ou mais outras, imagens de não-IDR (ex., chamadas imagens “P” e “B” que são codificadas usando a codificação intre-predita com base na predição direta e bidirecional a partir de outras imagens de referência).

[0061] De acordo com as técnicas descritas acima (ex., H.264/AVC), o acesso aleatório de uma CVS pode ser realizado primeiro pela decodificação de uma imagem de IDR da CVS, ex., uma imagem de IDR de uma GOP particular incluída dentro da CVS. Porque as imagens de IDR podem ser decodificadas sem referência a qualquer outra imagem, como descrito acima, de acordo com estas técnicas, o acesso aleatório da CVS pode ser realizado em uma base de GOP primeiro pela decodificação de uma imagem de IDR localizada no começo de cada GOP. Em outras palavras, de acordo com algumas técnicas (ex., H.264/AVC), o acesso aleatório de uma CVS pode ser realizado somente a partir de uma imagem de IDR incluída dentro da CVS. Como tal, nestas técnicas, para uma primeira imagem codificada de uma CVS particular em um fluxo de bits de conformação para ser uma imagem de RAP, a imagem deve ser uma imagem de IDR.

[0062] Em contraste com as técnicas acima descritas, de acordo com as técnicas desta divulgação, o acesso aleatório de um fluxo de bits que começa a partir de uma imagem não-IDR (ex., uma imagem de CRA) pode ser realizada em um modo predito e definido, ou “padrão,” pelos decodificadores de vídeo de conformação. Como um resultado, as técnicas divulgadas podem melhorar significativamente a interoperabilidade dos sistemas e dispositivos de codificador de vídeo e decodificador de vídeo, assim como a experiência do usuário, geralmente, para acesso aleatório de fluxo de bits que pode ocorrer frequentemente em várias aplicações de vídeo. Por exemplo, as técnicas descritas aqui podem incluir pelo menos um ou mais dos novos aspectos a seguir, em comparação com outras técnicas: (1) detectar uma ocorrência de acesso aleatório a partir de uma imagem RAP não-IDR (ex., uma imagem de CRA); (2) identificar e decodificar uma ou mais imagens que seguem a imagem RAP não-IDR em uma ordem de decodificação, mas precedem a imagem RAP não-IDR em uma ordem de saída (i.e., uma ou mais “imagens principais” da imagem RAP não-IDR); e (3) especificar que cada de uma ou mais imagens principais da imagem RAP não-IDR não é produzida mesmo no caso de uma output_flag sinalizada correspondente ser igual a verdade, ou “1” (i.e., a output_flag identifica que a respectiva imagem deve ser produzida), e que a respectiva imagem não é usada como uma imagem de referência para quaisquer outras imagens que seguem a imagem RAP não-IDR na ordem de decodificação e a ordem de saída.

[0063] Como descrito acima, de acordo com algumas técnicas (ex., H.264/AVC), uma imagem de IDR pode servir como um ponto de acesso convencional (ex., um ponto de acesso aleatório, ou imagem “RAP”) para uma CVS. Por exemplo, uma imagem de IDR pode ser incluída no começo de uma porção independentemente decodificável da CVS, às vezes referida como uma GOP. Esta implementação do acesso aleatório de uma CVS é às vezes referida como uma implementação de “GOP fechada”, sendo que nenhuma imagem dentro de uma GOP particular refere-se a quaisquer imagens que ocorrem antes de uma imagem de IDR da GOP, ex., imagens incluídas dentro de uma GOP anterior da CVS, ou uma GOP de outra, CVS anterior, de acordo com uma ordem de decodificação associada com a CVS. Como já explicado acima, neste contexto, uma GOP pode ser definida como uma imagem de IDR seguida por uma ou mais imagens “P” e/ou “B”.

[0064] Em uma chamada implementação de “GOP aberta”, uma imagem de CRA serve para uma finalidade similar como a imagem de IDR descrita acima com referência à implementação de GOP fechada. Por exemplo, neste contexto, uma GOP pode ser definida como uma imagem de CRA seguida por uma ou mais imagens “P” e/ou “B”. No entanto, em contraste à implementação de GOP fechada, na implementação de GOP aberta, as imagens incluídas dentro de uma GOP particular pode se referir às imagens que ocorrem antes de uma imagem de CRA da GOP, ex., imagens incluídas dentro de uma GOP anterior da CVS, ou uma GOP de outra, CVS anterior, de acordo com uma ordem de decodificação associada com a CVS. Por exemplo, de acordo com a implementação de GOP aberta, uma imagem “B” que segue uma imagem de CRA (a qual, como uma imagem de IDR, é uma intra- predita, ou imagem “I”) de uma GOP de uma CVS de acordo com uma ordem de decodificação associada com a CVS pode se referir a uma imagem (ex., uma imagem “P” ou “B”) incluída dentro de uma GOP anterior da CVS.

[0065] De acordo com algumas técnicas, uma imagem “B” de uma CVS é convencionalmente prevista pela referência a uma imagem que precede uma imagem “B” e uma imagem que segue uma imagem “B” em uma ordem de saída associada com a CVS. Por exemplo, a imagem “B” deste exemplo pode se referir a (i.e., uso como uma imagem de referência) a imagem incluída dentro da GOP anterior, a qual pode preceder a imagem “B” em uma ordem de saída associada com a CVS, e também se referir a (i.e., uso como uma imagem de referência) a imagem de CRA, a qual pode seguir a imagem “B” em uma ordem de saída. Em outras palavras, neste exemplo, a imagem “B” segue a imagem de CRA na ordem de decodificação, mas precede uma imagem de CRA em uma ordem de saída. Como tal, a imagem “B” pode ser considerada uma “imagem principal” da imagem de CRA. Em outros exemplos, no entanto, a imagem “B” pode ser qualquer outro tipo de uma imagem que também é uma imagem principal de uma imagem de CRA, como definido acima.

[0066] O exemplo acima descrito ilustra pelo menos um problema associado com uma implementação de GOP aberta descrita acima. Especificamente, em casos onde acesso aleatório de uma CVS é realizado a partir de uma imagem de CRA incluída dentro da CVS, as imagens principais de uma imagem de CRA não podem ser decodificadas corretamente. Isto é devido ao fato de que, em casos onde a imagem de CRA é a primeira imagem codificada da CVS, quaisquer imagens que precedem uma imagem de CRA em uma ordem de decodificação associada com a CVS não são decodificadas, e, portanto, não estão disponíveis como imagem de referência das imagens principais. Dessa forma, na implementação de GOP aberta descrita acima, as imagens principais não podem ser decodificadas corretamente, e assim podem prejudicar a experiência do usuário se exibidas. Por exemplo, se decodificadas, as imagens principais podem incluir dados de vídeo errôneos, e, se exibidas, podem degradar a qualidade visual das próprias imagens, assim como da CVS em geral. Para as mesmas razões, na implementação de GOP aberta, outras imagens da CVS que seguem a imagem de CRA em ambas ordem de decodificação e ordem de saída (ex., imagens “P”) pode não se referir às imagens principais (ex., já que estas imagens principais, se decodificadas, podem incluir dados de vídeo errôneos), ou a qualquer outra imagem que precede uma imagem de CRA na ordem de decodificação e ordem de saída (ex., já que estas imagens não são decodificadas, e são portanto indisponíveis como imagens de referência).

[0067] De modo geral, qualquer das técnicas descritas acima (i.e., a implementação de GOP fechada usando as imagens de IDR e a implementação de GOP aberta usando imagens de CRA) podem permitir que o acesso aleatório de uma CVS de dados de vídeo. No entanto, de acordo com alguns padrões de codificação, como, ex., H.264/AVC, um fluxo de bits que começa com uma imagem de CRA é considerado um fluxo de bits de “não-conformação”. Por exemplo, como descrito acima, de acordo com algumas técnicas, como, ex., H.264/AVC, um fluxo de bits deve começar com uma imagem de IDR. Em outras palavras, de acordo com estas técnicas, somente a implementação de acesso aleatório de GOP fechada descrita acima pode ser suportada. As técnicas desta divulgação podem permitir que um decodificador de vídeo manipule tal fluxo de bits não- conformação (i.e., um fluxo de bits que começa com uma imagem de CRA e se conforma a uma implementação de GOP aberta). Dito de outra forma, as técnicas descritas aqui visam definir tal fluxo de bits como um fluxo de bits de “conformação”. Em alguns exemplos, um fluxo de bits de conformação de acordo com as técnicas desta divulgação inclui fluxo de bits que começam com imagens CRA e se conformam a uma implementação de GOP aberta, assim como fluxo de bits que começam com imagens de IDR e conforme à implementação de GOP fechada.

[0068] Como já explicado acima, um problema que é identificado com relação ao acesso aleatório que ocorre em uma imagem de CRA refere-se ao fato de que imagens principais de uma imagem de CRA podem não ser corretamente decodificadas, e, portanto, podem prejudicar a experiência do usuário se exibidas. As técnicas desta divulgação podem resolver esse problema possibilitando o acesso aleatório de uma CVS a partir de uma imagem de CRA pela realização da decodificação, assim como manipulação da saída e propriedades de referência, das imagens principais associadas com uma imagem de CRA de um modo particular. Especificamente, as técnicas podem incluir algumas ou todas das etapas a seguir:Etapa 1: Identificar uma ou mais imagens de uma CVS como imagens principais de uma imagem de CRA da CVS quando um valor de contagem de ordem da imagem (POC) de cada de uma ou mais imagens é menor do que um valor POC de uma imagem de CRA (i.e., a respectiva imagem precede uma imagem de CRA em uma ordem de saída associada com a CVS), e quando a respectiva imagem segue a imagem de CRA em uma ordem de decodificação associada com a CVS. Etapa 2: Determinar, para cada de uma ou mais imagens principais, quando a respectiva imagem principal faz referência à imagem que não está disponível para decodificação. Etapa 3: Gerar, para cada de uma ou mais imagens principais que é determinada para fazer referência à imagem que não está disponível para decodificar uma imagem de referência virtual (ex., gerar uma imagem “média” luma (ou croma) que tem valores de luma (ou croma) que correspondem a um meio de uma faixa de valor de luma (ou croma) associada com a CVS, ex., uma imagem “cinza”). Etapa 4: Decodificar cada de uma ou mais imagens principais para as quais a imagem de referência virtual é gerada usando a imagem de referência virtual correspondente gerada, assim como decodificação de quaisquer imagens principais restantes. (a decodificação de uma ou mais imagens principais é realizada a fim de manter os parâmetros de temporização de CVS originais no decodificador de vídeo, ex., dentro de um DPB do decodificador de vídeo, embora, como mostrado abaixo, as imagens principais decodificadas podem não ser produzidas ou usadas como imagens de referência para outras imagens da CVS). Etapa 5: Definir uma output_flag associada com cada de uma ou mais imagens principais decodificadas para falso, ou “0,” de modo a não produzir a respectiva imagem principal , mesmo quando uma output_flag atual é igual a verdade, ou “1.” (Alternativamente, as técnicas podem incluir simplesmente ignorar, ou “mascarar” a output_flag atual que é igual a verdade, ou “1,” de modo a não produzir a respectiva imagem principal ). Etapa 6: Impedir que cada de uma ou mais imagens principais decodificadas de serem usadas como uma imagem de predição (i.e., uma referência) para quaisquer outras imagens da CVS que seguem a imagem de CRA em ambas ordem de decodificação e a ordem de saída.

[0069] Adicionalmente, as técnicas descritas aqui podem ser aplicáveis a um dispositivo de codificação (ex., codificador de vídeo 20), ao invés de um de decodificação (ex., decodificador de vídeo 30). Por exemplo, em casos onde a primeira imagem codificada de uma CVS compreende uma imagem de CRA, um codificador de vídeo inteligente que de acordo com as técnicas desta divulgação pode ser configurado para evitar enviar quaisquer imagens principais da imagem de CRA para um decodificador de vídeo. Como um exemplo, o codificador de vídeo pode ser configurado para enviar somente imagens “P” que seguem a imagem de CRA de acordo com uma ordem de decodificação associada com a CVS. Para conseguir isso, o codificador de vídeo pode ser configurado para gerar um chamado “subconjunto” de fluxo de bits deixando cair todas as "unidades de acesso" ou conjuntos comparáveis de dados que contêm imagens principais associada com uma imagem de CRA, em alguns exemplos. Dessa forma, no exemplo alternativo ilustrado acima, um codificador de vídeo, ao invés de um decodificador de vídeo, pode ser configurado para manejar (i.e., remover) as imagens principais de uma CRA de uma CVS como parte de gerar um fluxo de bits que inclui a CVS, de modo a melhorar a interoperabilidade e experiência do usuário para acesso aleatório do fluxo de bits no decodificador de vídeo.

[0070] Como tal, de acordo com as técnicas descritas aqui, a primeira imagem codificada de uma CVS de acordo com uma ordem de decodificação associada com a CVS em um fluxo de bits de conformação pode ser uma imagem de IDR ou uma imagem de CRA. Em outras palavras, as técnicas desta divulgação podem permitir que acesso aleatório que ocorre em uma imagem de CRA de uma CVS pela definição de um fluxo de bits sendo que a primeira imagem codificada de uma CVS de acordo com uma ordem de decodificação associada com a CVS é uma imagem de CRA como um fluxo de bits de conformação. Por exemplo, as técnicas desta divulgação podem ser aplicáveis a um padrão de codificação particular (ex., H.265/HEVC), ou uma extensão de um padrão de codificação (ex., H.264/AVC). em qualquer caso, de acordo com as técnicas divulgadas, tal fluxo de bits pode ser um fluxo de bits de conformação. Em outras palavras, tal fluxo de bits pode ser decodificado com sucesso por um decodificador de vídeo de acordo com as técnicas desta divulgação de uma maneira definida e previsível.

[0071] A descrição a seguir fornece informação adicional e exemplos com relação às técnicas desta divulgação descritas acima, assim como informação e técnicas adicionais.

[0072] Especificamente, as técnicas descritas aqui podem incluir um ou mais dos novos aspectos a seguir, em comparação com outras técnicas: (1) detectar uma ocorrência de acesso aleatório a partir de uma imagem não- IDR; (2) especificar que uma imagem não é produzida, mesmo quando uma output_flag sinalizada correspondente para a imagem é igual a verdade, ou “1;” e (3) sinalizar os parâmetros de tempo de remoção para “buffer de imagem codificada” atualizados para imagens seguindo uma imagem RAP não-IDR em uma ordem de decodificação, quando a imagem RAP não-IDR é a primeira imagem codificada de um fluxo de bits, e quando as imagens principais associadas com a primeira imagem codificada não estão presentes. Em alguns exemplos de acordo com as técnicas divulgadas, os parâmetros de tempo de remoção de CPB atualizados podem ser indicados por um deslocamento que se aplica a todas as imagens seguindo a imagem RAP não-IDR na ordem de decodificação após realizar o acesso aleatório a partir da imagem RAP não-IDR.

[0073] As técnicas descritas aqui podem ser aplicáveis à vários padrões de codificação de vídeo, incluindo 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 conhecido como ISO/IEC MPEG-4 AVC), incluindo suas extensões de Codificação de Vídeo Escalável (SVC) e Codificação de vídeo de Multivista (MVC). Além disso, as técnicas divulgadas podem ser aplicáveis ao padrão HEVC atualmente sendo desenvolvido pelo JCT-VC do ITU-T Grupo de Especialistas em Codificação de vídeo (VCEG) e Grupo de Especialistas em Imagem em Movimento ISO/IEC (MPEG). Como explicado acima, uma versão particular do HEVC referida à nesta divulgação é WD4 descrita no documento JCTVC-F803.

[0074] Algumas técnicas de gerenciamento de DPB não serão descritas. De acordo com algumas técnicas de codificação de vídeo, vários métodos de gerenciamento de DPB podem ser implementados. Como um exemplo, imagens decodificadas usadas para prever as imagens codificadas subsequentes, e para futura saída, podem ser armazenadas em buffer em um DPB. Para eficientemente usar a memória de um DPB, processos de gerenciamento de DPB, incluindo um processo de armazenamento de imagens decodificadas no DPB, um processo de marcação das imagens de referência, e processos de produção e remoção das imagens decodificadas a partir do DPB, podem ser especificados. O gerenciamento de DPB pode incluir pelo menos os aspectos a seguir: (1) identificação da imagem e identificação da imagem de referência; (2) construção da lista da imagem de referência; (3) marcação da imagem de referência; (4) produção da imagem a partir do DPB; (5) inserção da imagem no DPB; e (6) remoção da imagem a partir do DPB. Alguma introdução para a marcação da imagem de referência e construção da lista da imagem de referência é fornecida abaixo.

[0075] Como um exemplo, as técnicas de marcação da lista da imagem de referência serão agora descritas. De acordo com algumas técnicas de codificação de vídeo, vários métodos de marcação da imagem de referência podem ser implementados. Como um exemplo, a marcação da imagem de referência no H.264/AVC pode ser resumida como segue. Um número máximo, que pode ser referido como “M” (ex., correspondendo ao elemento de sintaxe num_ref_frames), das imagens de referência usadas para inter-predição pode ser indicado em um conjunto de parâmetro de sequência ativo (SPS). Quando a imagem de referência é decodificada, ela pode ser marcada como “usada para referência.” Se a decodificação da imagem de referência faz com que mais de “M” imagens sejam marcadas como “usadas para referência,” pelo menos uma imagem pode ser marcada como “não usada para referência.” Subsequentemente, o processo de remoção de DPB pode remover imagens marcadas como “não usadas para referência” a partir do DPB, se as imagens também não são necessárias para produção.

[0076] Quando uma imagem é decodificada, ela pode ser ou uma imagem de não-referência, ou uma imagem de referência. A imagem de referência pode ser uma imagem de referência de longo prazo, ou uma imagem de referência de curto prazo, e, quando marcada como “não usada para referência,” a imagem pode se tornar uma imagem de não- referência.

[0077] H.264/AVC inclui as operações de marcação da imagem de referência que mudam o status das imagens de referência. Por exemplo, em H.264/AVC, há dois tipos de operações para a marcação da imagem de referência, ou seja, a janela deslizante e o controle de memória adaptativo. O modo de operação para a marcação da imagem de referência é selecionado em uma base por imagem. Como um exemplo, as funções da marcação da imagem de referência da janela deslizante como uma fila primeiro a entrar primeiro a sair (FIFO) com um número fixo de imagens de referência de curto prazo. Em outras palavras, uma imagem de referência de curto prazo com um tempo de decodificação mais antigo é a primeira a ser removida (i.e., marcada como a imagem “não usada para referência”), de uma forma implícita. Como outro exemplo, a marcação da imagem de referência do controle de memória adaptativo remove imagens de curto prazo ou longo prazo explicitamente. Também permite a comutação do status das imagens de curto prazo e longo prazo.

[0078] Como outro exemplo, as técnicas de construção da lista da imagem de referência não serão descritas. De acordo com algumas técnicas de codificação de vídeo, vários métodos de construção da lista da imagem de referência podem ser implementados. Como um exemplo, tipicamente, a construção da lista da imagem de referência para uma primeira ou uma segunda lista da imagem de referência de uma imagem “B” pode incluir duas etapas: (1) inicialização da lista da imagem de referência, e (2) reordenação da lista da imagem de referência (que pode ser referida como “modificação”). A inicialização da lista da imagem de referência pode ser um mecanismo explícito que põe as imagens de referência em uma memória da imagem de referência (também conhecida como um DPB) em uma lista com base em uma ordem de POC (que, como explicado acima, é uma “Contagem de Ordem de Imagem,” e é alinhada com valores de uma ordem de saída, ou uma ordem de exibição, de uma imagem).

[0079] O mecanismo de reordenação da lista da imagem de referência pode modificar a posição de uma imagem que foi colocada na lista durante a inicialização da lista da imagem de referência para qualquer nova posição, ou colocar qualquer imagem de referência na memória da imagem de referência em qualquer posição, mesmo se uma imagem não pertence à lista inicializada. Algumas imagens, após a reordenação da lista da imagem de referência (ou modificação), podem ser colocadas em posições muito “distantes” na lista. No entanto, se a posição de uma imagem excede um número de imagens de referência ativa da lista, a imagem pode não ser considerada como uma entrada da lista da imagem de referência final. O número de imagens de referência ativas pode ser sinalizado em um cabeçalho de fatia para cada lista.

[0080] Alternativamente, uma abordagem diferente para o gerenciamento de DPB foi descrito no documento “JCTVC-F493: Absolute Signaling of Reference Pictures,” por Sjoberg et al., 6° Encontro, Torino, 2011 (referido como JCTVC-F493 doravante), todo o conteúdo do qual está aqui incorporado por referência.

[0081] Algumas técnicas de ajuste de imagem de referência (RPS) não serão descritas. Por exemplo, o Pedido de Patente US N°. 13/622,972, depositado em 19 de setembro de 2012, o conteúdo inteiro do qual é também incorporado por referência aqui, descreve um RPS, que inclui, para cada imagem, um número de imagens de referência que pode ser usado por uma imagem atual, ou atualmente codificada e uma imagem seguindo a imagem atualmente codificada em uma ordem de decodificação. Uma definição detalhada de um RPS pode ser fornecida como segue: um conjunto de imagens de referência associadas com uma imagem, consistindo em todas as imagens de referência, excluindo a própria imagem associada, que pode ser usada para inter-predição da imagem associada ou qualquer imagem seguindo a imagem associada em uma ordem de decodificação, e que tem o elemento de sintaxe temporal_id menor que ou igual àquele da imagem associada.

[0082] Exemplos de uma RAP e um RPS correspondente não serão descritos. Como explicado anteriormente, nesta divulgação, “acesso aleatório” refere- se a uma decodificação de uma CVS, que começa a partir da imagem codificada que não é a primeira imagem codificada tradicional, i.e., uma imagem de IDR, na CVS. A imagem RAP não-IDR, que pode ser referida como “picR,” pode ser definida como a imagem codificada para as quais todas das condições a seguir são verdadeiras: (1) picR não é uma imagem de IDR; (2) deixa o POC da picR ser “rPoc,” e deixa “picA” se uma imagem na mesma CVS e seguindo picR em ambas ordem de decodificação e ordem de saída, e deixa o POC da picA ser “aPoc.” Quando o acesso aleatório é realizado na picR, todas as imagens que estão na mesma CVS e seguem a picA em uma ordem de saída podem ser decodificadas corretamente.

[0083] Neste exemplo, para uma imagem RAP não- IDR picR, se uma condição a seguir é verdadeira, a imagem pode ser referida como uma imagem de CRA: quando o acesso aleatório é realizado na picR, todas as imagens que estão na mesma CVS e seguem picR em uma ordem de saída podem ser decodificadas corretamente. Se a condição acima não for verdade para a imagem RAP não-IDR picR, a imagem pode ser referida como uma imagem de atualização de decodificação gradual (GDR). Adicionalmente, para uma imagem de CRA, uma RPS correspondente pode não conter qualquer imagem de referência para uma imagem de CRA, mas pode tipicamente conter pelo menos uma imagem para as imagens seguindo uma imagem de CRA na ordem de decodificação.

[0084] FIG. 4 é um diagrama conceitual que ilustra um exemplo de hierarquias de referência dentre as imagens de GOPs de dados de vídeo, de acordo com as técnicas desta divulgação. Em particular, a FIG. 4 ilustra a codificação da imagem “B” hierárquica com quatro níveis temporais e um tamanho de GOP de “8.” Como mostrado na FIG. 4, quando a imagem com um valor de POC igual a “8” é codificada como intra- (i.e., uma imagem “I”), a imagem pode ser uma imagem de CRA. Com base na definição do RPS, o RPS contém uma imagem com um valor POC igual a “0” para as imagens que seguem esta imagem na ordem de decodificação.

[0085] As imagens principais e RPSs correspondentes não serão descritas. Como explicado anteriormente, as imagens que seguem uma imagem de RAP em uma ordem de decodificação, mas que precedem a imagem RAP em uma ordem de exibição, podem ser referidas como “imagens principais” correspondentes da imagem RAP. No exemplo da FIG. 4, as RPS’s das imagens principais correspondentes de uma imagem de CRA (i.e., a imagem com um valor POC de “8”) são como mostradas na Tabela I abaixo. Tabela I

[0086] As técnicas de saída de imagem não serão descritas. Em HEVC WD4, a cada imagem pode ser atribuída uma output_flag. Quando esta bandeira é igual a falso, ou “0,” a respectiva imagem não é usada para saída, e assim não será exibida.

[0087] Um exemplo de um CPB não será descrito. Um CPB pode ser necessário por um decodificador de vídeo para recepção e armazenamento em buffer da unidade de acessos, cada contendo uma imagem codificada e unidades de camada de abstração de rede associada (NAL), antes de elas serem decodificadas. Em HEVC WD4, por exemplo, as operações de CPB estão faltando, mas as operações de CPB como especificado em H.264/AVC podem, contudo, ser aplicadas. Como um exemplo, de acordo com H.264/AVC, para um fluxo de bits de conformação, uma lista de condições como especificado na sub-cláusula C.3 em H.264/AVC pode ser satisfeita em sua totalidade. Duas das condições de conformidade de fluxo de bits são como seguem: (1) Um sobrefluxo de CPB é especificado como uma condição na qual um número total de bits em um CPB é maior do que o tamanho do CPB. O CPB pode nunca ter sobrefluxo; (2) Um subfluxo de CPB é especificado como uma condição na qual tr,n(n) é menor do que “taf(n).” Quando low_delay_hrd_flag é igual a “0,” o CPB pode nunca ter subfluxo.

[0088] Alguns problemas potenciais com as técnicas acima descritas serão agora discutidos. As várias abordagens descritas acima, referem-se ao acesso aleatório que ocorre em uma imagem de CRA, tem algumas desvantagens. Como um exemplo, no caso da imagem principal não estar presente, um decodificador de conformação pode não saber se a imagem principal está perdida devido às perdas de transmissão, ou devido a quedas de imagem intencionais (ex., por um servidor de streaming, intencionalmente para a operação de acesso aleatório). Como outro exemplo, as imagens principais podem não ser corretamente decodificadas, e, portanto, podem prejudicar a experiência do usuário se exibidas. Ainda como outro exemplo, no caso de algumas imagens codificadas serem puladas intencionalmente, o fluxo de bits resultante que começa a partir de uma imagem de CRA pode conflitar com uma ou mais condições de conformidade de fluxo de bits, e, portanto, comportamento de decodificação imprevisível e resultados de decodificação incontroláveis podem ocorrer. Por exemplo, quando todas as imagens principais são descartadas, uma próxima imagem depois da imagem de CRA em uma ordem de decodificação se torna a imagem codificada após a última imagem principal na ordem de decodificação. Em comparação ao caso onde as imagens principais estão presentes, esta próxima imagem flui para dentro de um CPB mais cedo, e, consequentemente, seu tempo de chegada final de CPB taf(n) se torna mais cedo. O tempo de remoção do CPB derivado a partir do elemento de sintaxe cpb_removal_delay na mensagem de informação de melhoria suplementar (SEI) de temporização da imagem associada pode não mudar. Assim, o subfluxo do CPB não ocorrerá. No entanto, se um número de bits desta imagem e as imagens seguintes na ordem de decodificação é significativamente maior do que aquele das imagens principais descartadas, o sobrefluxo do CPB pode ocorrer.

[0089] Est a divulgação descreve várias técnicas que podem, em alguns casos, reduzir ou eliminar algumas das desvantagens descritas acima. Em particular, as técnicas desta divulgação podem resolver os problemas descritos acima, relacionados ao acesso aleatório a partir das imagens de CRA, pelo emprego de vários métodos para garantir que um fluxo de bits para o qual a primeira imagem codificada é uma imagem de CRA é conformada, independente de se as imagens principais associadas com uma imagem de CRA estão presentes. As técnicas divulgadas incluem pelo menos os aspectos a seguir que podem ser usados para implementar as características descritas acima.

[0090] Como um exemplo, um processo para a detecção de uma ocorrência de acesso aleatório pode ser opcionalmente adicionado. A detecção da ocorrência do acesso aleatório para cada imagem e para cada imagem principal, se ela é direcionada para a decodificação e/ou saída, pode ser realizada pela construção de um conjunto de imagem de desaparecimento (VPS) que contém imagens que pode não ser corretamente recebidas e decodificadas devido ao acesso aleatório, mas serão corretamente recebidas e decodificadas em um caso normal. Desde que o VPS não é vazio, a detecção pode ser necessária.

[0091] Como outro exemplo, a manipulação de uma propriedade de saída das imagens principais pode ser realizada, tal que, as imagens principais podem não ser usadas para saída quando o acesso aleatório, que começa a partir de uma imagem de CRA associada, ocorre.

[0092] Como outro exemplo, processos de decodificação para uma imagem principal podem ser modificados, tal que, se a imagem principal é recebida, apenas analisando a sintaxe de alto nível e invocação dos processos de decodificação associados, ex., derivação de um conjunto de imagem de referência (RPS), pode ser realizada, e a decodificação de tal imagem pode ser pulada.

[0093] Como outro exemplo, uma restrição de fluxo de bits pode ser adicionada, tal que, mesmo quando um decodificador começa a decodificar uma imagem de CRA, e não há imagens principais seguindo uma imagem de CRA, a informação relacionada à conformidade de CPB, incluindo parâmetros de decodificador de referência hipotética (HDR), as mensagens de SEI de período de armazenamento em buffer da imagem, e mensagens de SEI de temporização da imagem, podem ser usados para satisfazer as restrições de CPB, e, portanto, nenhum sobrefluxo ou subfluxo de buffer pode ocorrer.

[0094] Como outro exemplo, uma mensagem SEI associada com uma imagem de CRA pode ser sinalizada para incluir um conjunto adicional de parâmetros de retardo inicial de CPB, tal que, quando imagens principais não estão presentes, as restrições de conformidade de CPB podem ser satisfeitas ao aplicar o conjunto adicional de parâmetros de retardo inicial de CPB. Mais especificamente, na mensagem de SEI de período de armazenamento em buffer da imagem, dois conjuntos de parâmetros de retardo inicial de CPB podem ser sinalizados se a imagem atual é uma imagem de CRA.

[0095] Os exemplos a seguir demostram as características acima descritas das técnicas desta divulgação. Para fins de descrever os exemplos a seguir, os termos a seguir são definidos:imagem principal: A imagem, associada com uma imagem de CRA, que sucede a imagem de CRA em uma ordem de decodificação e precede uma imagem de CRA na saída, ou ordem de exibição.VPS: um conjunto de imagens de referência, associadas com uma imagem de CRA, que tem uma ordem de exibição mais adiantada do que aquela da imagem de CRA.

[0096] Exemplos de sintaxe, e, em particular, exemplos de sintaxe de mensagem de SEI de período de armazenamento em buffer, serão agora descritos.TABELA II

[0097] Adicionalmente, exemplos de semânticas da mensagem de SEI de período de armazenamento em buffer são descritos abaixo:

[0098] Como um exemplo, cra_para_present_flag igual a verdade, ou “1,” pode indicar que outro conjunto de retardos iniciais de CPB é sinalizado quando a imagem associada atual é uma imagem de CRA. Esta bandeira igual a falso, ou “0,” pode indicar que nenhum conjunto adicional de retardos iniciais de CPB é sinalizado. Esta bandeira pode ser igual a “0” quando a imagem associada não é uma imagem de CRA.

[0099] Como outro exemplo, update_initial_cpb_removal_delay[SchedSelIdx] pode especificar um retardo para o SchedSelIdx-th CPB entre o tempo de chegada no CPB do primeiro bit dos dados codificados associados com a unidade de acesso associada com a mensagem de SEI de período de armazenamento em buffer, e o tempo de remoção a partir do CPB do dados codificados associados com a mesma unidade de acesso, para um primeiro período de armazenamento em buffer após a inicialização de HRD. O elemento de sintaxe pode ter um comprimento em bits dado por initial_cpb_removal_delay_length_minus1 + 1. Pode ser em unidades de um relógio de 90 kHz. Além disso, update_initial_cpb_removal_delay[SchedSelIdx] pode não ser igual a “0” e não pode ser excedido 90000 * (CpbSize[SchedSelIdx] BitRate[SchedSelIdx] ), o equivalente ao tempo do tamanho de CPB nas unidades de relógio de 90 kHz.

[0100] Como outro exemplo, update_initial_cpb_removal_delay_offset[SchedSelIdx] pode ser usado para o SchedSelIdx-th CPB em combinação com o cpb_removal_delay para especificar o tempo de entrega inicial das unidades de acesso codificadas para o CPB. Por exemplo, update_initial_cpb_removal_delay_offset[SchedSelIdx] pode ser em unidades de um relógio de 90 kHz. O elemento de sintaxe update_initial_cpb_removal_delay_offset[SchedSelIdx] pode ser um código de comprimento fixo cujo comprimento em bits é dado por initial_cpb_removal_delay_length_minus1 + 1. Este elemento de sintaxe pode não ser usado pelos decodificadores, e pode ser necessário somente para o programador de entrega (HSS) especificado no Anexo C do HEVC WD4.

[0101] Exemplos dos processos de decodificação serão agora descritos. De acordo com as técnicas desta divulgação, os processos de decodificação a seguir podem ser adicionados e/ou modificados em relação aos processos de decodificação descritos no Pedido de Patente US N° . 13/622.972, depositado em 19 de setembro de 2012, o conteúdo inteiro do qual é incorporado aqui por referência.

[0102] Como um exemplo, técnicas de criação de VPS serão agora descritas. Em alguns exemplos, a criação de VPS pode ocorrer logo após a invocação de um processo de derivação para um RPS quando a imagem atual é uma imagem de CRA. Por exemplo, em casos onde a imagem atual é uma imagem de CRA, se qualquer imagem no RPS não está em um DPB, o VPS pode ser definido como o RPS atual. Caso contrário, o VPS pode ser definido para estar vazio.

[0103] Como outro exemplo, as técnicas de identificação da imagem principal serão agora descritas. Em alguns exemplos, se o VPS não está vazio, e a imagem tem um RPS que se sobrepõe ao VPS, a imagem pode ser identificada como uma imagem principal.

[0104] Como outro exemplo, técnicas de decodificação da imagem principal serão agora descritas. Em alguns exemplos, a decodificação da imagem principal pode ser descartada por um decodificador de conformação.

[0105] Como outro exemplo, técnicas de saída da imagem principal serão agora descritas. Em alguns exemplos, para cada imagem principal, o output_flag pode ser definido para “falso,” independente de se o valor de output_flag no cabeçalho da fatia é igual a “0” ou “1.”

[0106] Um HRD, e, em particular, a operação de um CPB, será agora descrita. Por exemplo, as especificações nesta porção da divulgação podem se aplicar independentemente a cada conjunto de parâmetros de CPB que está presente, e a ambas conformidades Tipo I e Tipo II.

[0100] Como um exemplo, a temporização da chegada do fluxo de bits será agora descrita. A HRD pode ser inicializada para qualquer uma da mensagens de SEI de período de armazenamento em buffer. Antes da inicialização, o CPB pode estar vazio. Neste exemplo, após a inicialização, a HRD pode não ser inicializada novamente pelas mensagens de SEI de período de armazenamento em buffers subsequentes. Também neste exemplo, se a primeira unidade de acesso é uma unidade de acesso de CRA, e as imagens principais não estão presentes e a cra_para_present_flag é igual a “1,” useUpdatePara pode ser definido para “1.” Caso contrário, useUpdatePara pode ser definido para “0.”

[0101] Por exemplo, se useUpdatePara é igual a “0,” InitialCpbRemovalDelay[SchedSelIdx] pode ser definido para initial_cpb_removal_delay[SchedSelIdx] e InitialCpbRemovalDelayOffset[SchedSelIdx] pode ser definido para initial_cpb_removal_delay_offset[SchedSelIdx]. Caso contrário, InitialCpbRemovalDelay[SchedSelIdx] pode ser definido para update_initial_cpb_removal_delay[SchedSelIdx] e InitialCpbRemovalDelayOffset[SchedSelIdx] pode ser definido para update_initial_cpb_removal_delay_offset[SchedSelIdx], sendo que initial_cpb_removal_delay[SchedSelIdx], initial_cpb_removal_delay_offset[SchedSelIdx], update_initial_cpb_removal_delay[SchedSelIdx], e update_initial_cpb_removal_offset[SchedSelIdx] pode ser especificado na mensagem de SEI de período de armazenamento em buffer associada com uma unidade de acesso de CRA.

[0102] Além disso, a unidade de acesso que é associada com a mensagem de SEI de período de armazenamento em buffer que inicializa o CPB pode ser referida como unidade de acesso “0.” Todas as outras unidades de acesso são referidas como unidade de acesso “n” que “n” sendo incrementado por 1 para a próxima unidade de acesso na ordem de decodificação. Neste exemplo, o tempo no qual o primeiro bit de unidade de acesso n começa a entrar no CPB pode ser referido como um tempo de chegada inicial tai(n).

[0103] Em um exemplo, o tempo de chegada inicial das unidades de acesso pode ser derivado como segue: (1) se a unidade de acesso é unidade de acesso 0, tai(0) = 0; (2) caso contrário (a unidade de acesso é unidade de acesso n com > 0), o seguinte pode ser aplicado: (a) se cbr_flag[SchedSelIdx] é igual a “1,” o tempo de chegada inicial para unidade de acesso n pode ser igual a um tempo de chegada final (que é derivado abaixo) da unidade de acesso n - 1, i.e., tai (n) = taf(n — 1) EQ. 1 (b) caso contrário, se cbr_flag[SchedSelIdx] é igual a “0,” e unidade de acesso n não é a primeira unidade de acesso de um período de armazenamento em buffer subsequente, o tempo de chegada inicial para unidade de acesso n pode ser derivado por: tai(n) = Max(taf(n — 1), tai, mais cedo(n) ) EQ. 2 onde tai, mais cedo(n) é dado como segue: tai, mais cedo (n) = tr,n (n) — (InitialCpbRemovalDelay[SchedSelIdx] + InitialCpbRemovalDelayOffset[SchedSelIdx] ) a 90000 EQ. 3 com tr,n(n) sendo o tempo de remoção nominal da unidade de acesso n a partir do CPB como especificado na sub-cláusula C.1.2 de HEVC WD4, em alguns exemplos; (c) caso contrário (se cbr_flag[SchedSelIdx] é igual a “0,” e a unidade de acesso subsequente n é a primeira unidade de acesso de um período de armazenamento em buffer subsequente), o tempo de chegada inicial para a unidade de acesso n pode ser derivado por: tai(n) = tr,n(n) - (InitialCpbRemovalDelay[SchedSelIdx] a 90000) EQ. 4 com InitialCpbRemovalDelay[SchedSelIdx] sendo especificado na mensagem de SEI de período de armazenamento em buffer associada com unidade de acesso n, em alguns exemplos.

[0104] Neste exemplo, o tempo de chegada final para a unidade de acesso n pode ser derivado por: taf(n) = tai(n) + b(n) a BitRate[SchedSelIdx] EQ. 5 onde b(n) pode ser o tamanho em bits da unidade de acesso n, contagem de bits do fluxo de bits Tipo I para conformidade Tipo I, ou os bits do fluxo de bits Tipo II para conformidade Tipo II.

[0105] Em alguns exemplos, os valores de SchedSelIdx, BitRate[SchedSelIdx], e CpbSize[SchedSelIdx] podem ser limitados como a seguir: (1) se a unidade de acesso n e unidade de acesso n - 1 são parte de diferentes CVSs, e o conteúdo das SPSs ativas de duas CVS diferem, a HSS pode selecionar um valor SchedSelIdx1 de SchedSelIdx a partir dos valores de SchedSelIdx provided para a CVS contendo a unidade de acesso n que resulta em uma BitRate[SchedSelIdx1] ou CpbSize[SchedSelIdx1] para a segunda das duas CVSs (que contém a unidade de acesso n - 1) que difere do valor de BitRate[SchedSelIdx0] ou CpbSize[SchedSelIdx0] para o valor SchedSelIdx0 de SchedSelIdx que estava em uso para a CVS contendo a unidade de acesso n - 1; (2) caso contrário, a HSS pode continuar a funcionar com os valores anteriores de SchedSelIdx, BitRate[SchedSelIdx], e CpbSize[SchedSelIdx].

[0106] Em outros exemplos, quando a HSS seleciona valores de BitRate[SchedSelIdx] ou CpbSize[SchedSelIdx] que diferem daqueles das unidade de acesso anteriores, o seguinte pode ser aplicado: (1) a variável BitRate[SchedSelIdx] pode entrar em vigor no momento tai(n); (2) a variável CpbSize[SchedSelIdx] pode entrar em vigor como segue: (a) se um novo valor de CpbSize[SchedSelIdx] excede o tamanho de CPB antigo, ele pode entrar em vigor no momento tai(n); (b) caso contrário, o novo valor de CpbSize[SchedSelIdx] pode entrar em vigor no momento tr(n).

[0107] Como outro exemplo, a temporização da remoção da imagem codificada será agora descrita. Por exemplo, para a unidade de acesso 0, o tempo de remoção nominal da unidade de acesso a partir do CPB pode ser especificado por: tr,n(0) = InitialCpbRemovalDelay[SchedSelIdx] ^ 90000 EQ. 6

[0108] Além disso, para a primeira unidade de acesso de um período de armazenamento em buffer que não inicializa a HRD, o tempo de remoção nominal da unidade de acesso a partir do CPB pode ser especificado por: tr,n(n) = tr,n (nb) + tc * cpb_removal_delay(n) EQ. 7 onde tr,n(nb) pode ser o tempo de remoção nominal da primeira imagem do período de armazenamento em buffer anterior, e cpb_removal_delay(n) pode ser especificado na mensagem de SEI de temporização da imagem associada com a unidade de acesso n.

[0109] Adicionalmente, quando uma unidade de acesso n é a primeira unidade de acesso de um período de armazenamento em buffer, nb pode ser definido igual a n no tempo de remoção da unidade de acesso n.

[0110] Também, o tempo de remoção nominal tr,n(n) de uma unidade de acesso n que não é a primeira unidade de acesso de um período de armazenamento em buffer pode ser dado por: tr,n(n) = tr,n(nb) + tc * cpb_removal_delay(n) EQ. 8

[0111] Adi cionalmente, o tempo de remoção da unidade de acesso n pode ser especificado como segue: (1) se low_delay_hrd_flag é igual a “0” ou tr,n(n) >= taf(n), o tempo de remoção da unidade de acesso n pode ser especificado por: tr(n) = tr,n(n) EQ. 9 (2) caso contrário (se low_delay_hrd_flag é igual a 1 e tr,n(n) < taf(n)), o tempo de remoção da unidade de acesso n pode ser especificado por: tr(n) = tr,n(n) + tc * Ceil( ( taf(n) - tr,n(n) ) + tc ) EQ. 10

[0112] Neste exemplo, o último caso, indica que o tamanho da unidade de acesso n, b(n), é tão grande que ele impede a remoção no tempo de remoção nominal.

[0113] Como outro exemplo, a conformidade de fluxo de bits será agora descrita. A divulgação da sub- cláusula C.3 do H.264/AVC pode se aplicar às técnicas descritas abaixo, com as mudanças a seguir incluídas: a primeira imagem codificada, em uma ordem de decodificação, de um fluxo de bits de conformação pode ser uma imagem de IDR ou uma imagem de CRA. Para um fluxo de bits de conformação que começa com uma imagem de CRA, um subconjunto de fluxo de bits gerado pela queda das unidades de acesso que contém todas as imagens principais associadas com a que começa na imagem CRA pode ainda ser um fluxo de bits de conformação.

[0114] A descrição a seguir inclui exemplos alternativos das técnicas desta divulgação descritas acima. Por exemplo, várias implementações alternativas de certos aspectos desta divulgação são possíveis, e algumas são descritas como segue. As seguintes implementações alternativas são descritas com referência a diversos aspectos das técnicas da divulgação. No entanto, qualquer combinação das implementações para os diferentes aspectos pode também formar as implementações de acordo com as técnicas desta divulgação.

[0115] Os seguintes exemplos alternativos referem-se às modificação de um VPS.

[0116] Como um exemplo, uma definição de VPS é fornecida como segue: um conjunto de imagens de referência associado com a imagem, consistindo em todas as imagens de referência, que estão em um RPS atual e podem não ser corretamente decodificadas quando acesso aleatório a partir de uma imagem de CRA mais próxima, que precede a imagem em uma ordem de decodificação, ocorrer.

[0117] O seguinte é um exemplo alternativo da modificação de VPS. Neste exemplo, no caso da um VPS não ser vazio, o seguinte pode ser aplicado: (1) antes da imagem atual ser decodificada, cada imagem no VPS pode ser verificada; (a) se a imagem está no RPS, pode ser mantida no VPS; (b) caso contrário, pode ser removida a partir do VPS; (2) no caso do VPS da imagem atual e o RPS da imagem atual terem se sobreposto, a imagem atual pode ser inserida no VPS, se é a imagem de referência, após a imagem atual ser decodificada.

[0118] Em alguns exemplos, se a imagem não é uma imagem de CRA, e o VPS não está vazio, cada imagem em um RPS atual pode estar ou no VPS ou no DPB.

[0119] O seguinte é outro exemplo alternativo da modificação de VPS. Neste exemplo, no caso de um VPS não estar vazio, o seguinte pode ser aplicado: (1) antes da imagem ser decodificada, cada imagem no VPS pode ser verificada; (a) se a imagem está no RPS e pertence a um dos subconjuntos RefPicSetStCurr0, RefPicSetStCurr1 e RefPicSetLtCurr, pode ser mantida no VPS; (b) caso contrário, pode ser removida a partir do VPS; (2) no caso do VPS da imagem atual e o RPS da imagem atual se sobreporem, a imagem atual pode ser inserida no VPS, se esta é a imagem de referência, após a imagem atual ser decodificada.

[0120] O seguinte é outro exemplo alternativo da modificação de VPS. Neste exemplo, no caso da uma imagem ter uma ordem de exibição maior do que uma imagem de CRA, e um VPS não estar vazio, o seguinte pode ser aplicado: (1) no caso da pelo menos uma imagem em um RPS pertencer ao VPS, o VPS pode ser mantido não modificado; (2) no caso de nenhuma imagem no RPS pertencer ao VPS, o VPS pode ser definido como vazio.

[0121] Neste exemplo, o VPS pode somente mudar duas vezes durante cada acesso aleatório. Na primeira vez, ele pode ser preenchido com imagens das quais as imagens principais podem depender. A segunda vez, pode ser definido como vazio.

[0122] No exemplo da FIG. 4, se a imagem “8” é usada para acesso aleatório, o VPS pode ser {8}. Neste exemplo, somente após um RPS da imagem “16” ser criado, o VPS pode ser definido como vazio. Neste exemplo, as imagens com uma ordem de exibição menor do que aquela da imagem de CRA pode ser pulada para a decodificação e saída, desde que o VPS não esteja vazio. Isto pode ser descrito como uma abordagem diferente, ou alternativa para a “Identificação da Imagem Principal”.

[0123] Um exemplo alternativo da criação de uma imagem desaparecida será agora descrito. Neste exemplo, no caso de uma imagem ser detectada como a imagem desaparecida, pode ser criada como uma cópia de uma imagem em um DPB que tem a ordem de exibição mais próxima (distância POC) à imagem desaparecida. Se duas imagens tem a mesma distância POC, aquela com um POC menor pode ser usada.

[0124] Um exemplo alternativo da decodificação da imagem principal será agora descrito. Como um exemplo, a imagem principal pode ser decodificada, se nenhuma das imagens em RefPicSetStCurr0, RefPicSetStCurr1 ou RefPicSetLtCurr pertence ao VPS. Como outro exemplo, a imagem principal pode sempre ser decodificada, especialmente quando cada imagem desaparecida está disponível no DPB, embora com desvio.

[0125] Um exemplo alternativo da saída da imagem principal será agora descrito. Como um exemplo, no caso de uma imagem principal ser corretamente decodificada, output_flag pode ser definido para “1”. Caso contrário, o output_flag pode ser definido para “0.” Como outro exemplo, somente as imagens principais contínuas imediatamente antes da imagem de CRA em uma ordem de saída, se elas são todas corretamente decodificadas, pode ter valores de output_flag definidos para “1,” e outras imagens principais podem ter valores de output_flag definidos para “0.”

[0126] Um exemplo alternativo do deslocamento do tempo de remoção, e em particular, a sintaxe da mensagem de SEI de período de armazenamento em buffer, será agora descrita.TABELA III

[0127] Alternativamente, em outros exemplos, o deslocamento pode ser sinalizado em uma mensagem de SEI diferente que é somente associada com a imagem de CRA (ou acesso aleatório não-IDR), para a qual a sintaxe é fornecida abaixo.

[0128] Um exemplo de sintaxe de mensagem de SEI de deslocamento de retardo de remoção de CPB será agora descrita.Tabela IV

[0129] Adi cionalmente, as semânticas da mensagem de SEI de período de armazenamento em buffer são descritas abaixo.

[0130] Como um exemplo, cra_para_present_flag igual a “1” pode indicar a presença do elemento de sintaxe random_access_removal_delay_offset[SchedSelIdx]. Esta bandeira igual a “0” pode indicar a ausência do elemento de sintaxe random_access_removal_delay_offset[SchedSelIdx].

[0131] Como outro exemplo, random_access_removal_delay_offset[SchedSelIdx] pode especificar um deslocamento de tempo de remoção de CPB para o SchedSelIdx-th CPB. Por exemplo, pode estar em unidades de um relógio de 90 kHz. Adicionalmente, random_access_removal_delay_offset[SchedSelIdx] pode não exceder initial_cpb_removal_delay[SchedSelIdx] + initial_cpb_removal_delay_offset[SchedSelIdx]. Em alguns exemplos, quando não presente, o valor pode ser inferido por ser igual a “0.”

[0132] Um exemplo de semânticas da mensagem de SEI de deslocamente de retardo de remoção de CPB será agora descrito. Em alguns exemplos, tal mensagem SEI pode somente estar presente para uma imagem de CRA, e pode somente ter efeito quando a CRA é usada para acesso aleatório e suas imagens principais correspondentes não estão presentes no fluxo de bits. Como um exemplo, random_access_removal_delay_offset[SchedSelIdx] pode especificar um deslocamento de tempo de remoção de CPB para o SchedSelIdx-th CPB. Por exemplo, pode estar em unidades de um relógio de 90 kHz. Adicionalmente, random_access_removal_delay_offset[SchedSelIdx] não pode ser excedido pelo initial_cpb_removal_delay[ SchedSelIdx ] + initial_cpb_removal_delay_offset[SchedSelIdx]. Em alguns exemplos, quando não presente, o valor pode ser inferido por ser igual a “0.”

[0133] Um exemplo de operação de um CPB será agora descrito. As especificações nesta porção da divulgação podem aplicar independentemente a cada conjunto de parâmetros de CPB que está presente, e a ambas as conformidades de Tipo I e Tipo II.

[0134] Como um exemplo, a temporização da chegada do fluxo de bits será agora descrita. Por exemplo, o HRD pode ser inicializado a qualquer uma das mensagens de SEI de período de armazenamento em buffer. Antes da inicialização, o CPB pode estar vazio. Neste exemplo, após a inicialização, o HRD pode não ser inicializado novamente pelas mensagens de SEI do período de armazenamento em buffer subsequente. Também neste exemplo, a unidade de acesso que é associada com a mensagem de SEI do período de armazenamento em buffer que inicializa o CPB pode ser referida como unidade de acesso 0. Todas as outras unidades de acesso são referidas como unidade de acesso n, com n sendo incrementado por 1 para a próxima unidade de acesso na ordem de decodificação.

[0135] Neste exemplo, se a primeira unidade de acesso é uma unidade de acesso de CRA, e as imagens principais não estão presentes e a cra_para_present_flag é igual a “1,” useUpdatePara pode ser definido para “1.” Caso contrário, useUpdatePara pode ser definido para “0.” além disso, se useUpdatePara é igual a “1,” random_access_removal_delay_offset[SchedSelIdx]. Caso contrário, DelayOffset[SchedSelIdx] pode ser definido para “0.” Adicionalmente, o tempo no qual o primeiro bit da unidade de acesso n começa a entrar no CPB pode ser referido como o tempo de chegada inicial tai(n). Em alguns exemplos, o tempo de chegada inicial das unidades de acesso pode ser derivado como segue: (1) se a unidade de acesso é unidade de acesso 0, tai(0) = 0. (2) Caso contrário (se a unidade de acesso é unidade de acesso n com n > 0), o seguinte pode ser aplicado: (a) Se cbr_flag[ SchedSelIdx] é igual a “1,” o tempo de chegada inicial para unidade de acesso n pode ser igual ao tempo de chegada final (que é derivado abaixo) da unidade de acesso n - 1, i.e., tai (n) = taf(n — 1) EQ. 11 (b) Caso contrário, se cbr_flag[SchedSelIdx] é igual a “0,” e unidade de acesso n não é a primeira unidade de acesso de um período de armazenamento em buffer subsequente, o tempo de chegada inicial para unidade de acesso n pode ser derivado por: tai(n) = Max(taf(n — 1), tai, mais cedo(n)) EQ. 12 onde tai, mais cedo(n) pode ser dado como segue: tai, mais cedo (n) = tr,n (n) - (initial_cpb_removal_delay[SchedSelIdx] + initial_cpb_removal_delay_offset[SchedSelIdx]) 90000 EQ. 13 com tr,n(n) sendo o tempo de remoção nominal da unidade de acesso n a partir do CPB como especificado na sub-cláusula C.1.2 do HEVC WD4, e initial_cpb_removal_delay[SchedSelIdx] e initial_cpb_removal_delay_offset[SchedSelIdx] sendo especificados na mensagem de SEI de período de armazenamento em buffer anterior. (c) Caso contrário (se cbr_flag[SchedSelIdx] é igual a “0,” e a unidade de acesso subsequente n é a primeira unidade de acesso de um período de armazenamento em buffer subsequente), o tempo de chegada inicial para a unidade de acesso n pode ser derivado por: tai(n) = tr,n(n) — (initial_cpb_removal_delay[SchedSelIdx] 90000) EQ. 14 com initial_cpb_removal_delay[SchedSelIdx] sendo especificado na mensagem de SEI de período de armazenamento em buffer associada com unidade de acesso n. Neste exemplo, o tempo de chegada final para a unidade de acesso n pode ser derivado por: taf(n) = tai(n) + b(n) BitRate[SchedSelIdx] EQ. 15 onde b(n) pode ser o tamanho em bits da unidade de acesso n, contagem de bits do fluxo de bits Tipo I para conformidade Tipo I, ou os bits do fluxo de bits Tipo II para conformidade Tipo II.

[0136] Além disso, os valores de SchedSelIdx, BitRate[SchedSelIdx], e CpbSize[SchedSelIdx] podem ser limitados como a seguir: (1) Se a unidade de acesso n e unidade de acesso “n - 1” são parte de diferentes CVSs, e o conteúdo das SPSs ativas de duas CVS diferem, a HSS pode selecionar um valor SchedSelIdx1 de SchedSelIdx a partir dos valores de SchedSelIdx fornecidos para a CVS contendo unidade de acesso n que resulta em um BitRate[SchedSelIdx1] ou CpbSize[SchedSelIdx1] para a segunda das duas CVSs (que contém a unidade de acesso n - 1) que difere do valor de BitRate[SchedSelIdx0] ou “CpbSize[SchedSelIdx0]” para o valor SchedSelIdx0 de SchedSelIdx que estava em uso para a CVS contendo unidade de acesso n - 1. (2) Caso contrário, a HSS pode continuar a funcionar com os valores anteriores de SchedSelIdx, BitRate[SchedSelIdx] e CpbSize[SchedSelIdx].

[0137] Adi cionalmente, quando a HSS seleciona valores de BitRate[SchedSelIdx] ou CpbSize[SchedSelIdx] que diferem daqueles das unidade de acesso anteriores, o seguinte pode ser aplicado: (1) a variável BitRate[SchedSelIdx] pode entrar em vigor no momento tai(n); e (2) a variável CpbSize[SchedSelIdx] pode entrar em vigor como segue: (a) Se o novo valor de CpbSize[SchedSelIdx] excede o tamanho de CPB antigo, ele pode entrar em vigor no momento tai(n), (b) Caso contrário, o novo valor de CpbSize[SchedSelIdx] pode entrar em vigor no momento tr(n).

[0138] Como outro exemplo, a temporização da remoção da imagem codificada será agora descrita. Em alguns exemplos, pode ser assumido que o tempo de remoção de CPB nominal e o tempo de remoção de CPB de uma imagem codificada são imediatamente calculados após a imagem codificada anterior ser removida a partir do CPB, ou, para a unidade de acesso 0, quando o HRD é inicializado.

[0139] Por exemplo, para a unidade de acesso 0, o tempo de remoção nominal da unidade de acesso a partir do CPB pode ser especificado por: tr,n(0) = initial_cpb_removal_delay[SchedSelIdx] ^ EQ. 16

[0140] No tempo de remoção da unidade de acesso 0, a variável nb pode ser definida igual a “0.” imediatamente após a remoção da unidade de acesso 0 a partir do CPB, tr,n (0) pode ser definido para igual a tr,n(0) — (DelayOffset[SchedSelIdx] - 90000).

[0141] Neste exemplo, o tempo de remoção de CPB efetivo da unidade de acesso 0 pode não ser deslocado, mas para todas as imagens após a unidade de acesso 0 em uma ordem de decodificação, o tempo de remoção de CPB efetivo pode ser deslocado mais cedo pelo (DelayOffset[SchedSelIdx] - 90000).

[0142] Além disso, para a primeira unidade de acesso de um período de armazenamento em buffer que não inicializa a HRD, o tempo de remoção nominal da unidade de acesso a partir do CPB pode ser especificado por: tr,n(n) = tr,n (nb) + tc * cpb_removal_delay(n) EQ. 17 onde tr,n(nb) pode ser o tempo de remoção nominal da primeira imagem do período de armazenamento em buffer anterior, e cpb_removal_delay(n) pode ser especificado na mensagem de SEI de temporização da imagem associada com unidade de acesso n.

[0143] Adicionalmente, quando uma unidade de acesso n é a primeira unidade de acesso de um período de armazenamento em buffer que não inicializa a HRD, nb pode ser definido igual a “n” no tempo de remoção da unidade de acesso n. Além disso, o tempo de remoção nominal tr,n(n) de uma unidade de acesso n que não é a primeira unidade de acesso de um período de armazenamento em buffer pode ser dado por: tr,n(n) = tr,n(nb) + tc * cpb_removal_delay(n) EQ. 18

[0144] Po r exemplo, o tempo de remoção da unidade de acesso n pode ser especificado como segue: (1) Se low_delay_hrd_flag é igual a “0,” ou tr,n(n) >= taf(n), o tempo de remoção da unidade de acesso n pode ser especificado por: tr(n) = tr,n(n) EQ. 19 (2) Caso contrário (se low_delay_hrd_flag é igual a “1,” e tr,n(n) < taf(n)), o tempo de remoção da unidade de acesso n pode ser especificado por: tr( n ) = tr,n( n ) + tc * Ceil( ( taf( n ) - tr,n( n ) ) + tc ) EQ. 20

[0145] Neste exemplo, o último caso indica que o tamanho da unidade de acesso n, b(n), é tão grande que ele impede a remoção no tempo de remoção nominal.

[0146] Out ro exemplo das técnicas desta divulgação especifica processos de decodificação para as imagens principais que perderam as imagens de referência. Neste exemplo, somente um fluxo de bits que começa com uma imagem de CRA para as quais as imagens principais estão presentes no fluxo de bits é especificada como um fluxo de bits de conformação. Em particular, este exemplo corresponde a algumas das técnicas descritas em HEVC WD5, e inclui as seguintes mudanças para estas técnicas de HEVC WD5, como descrito em detalhe abaixo.

[0147] Neste exemplo, a primeira imagem codificada em um fluxo de bits pode ser uma imagem de IDR ou uma imagem de CRA. Como explicado anteriormente, o termo “imagem principal,” como usado nesta divulgação, pode ser definido como segue: A imagem codificada associada com uma imagem de CRA que segue uma imagem de CRA em uma ordem de decodificação, e precede uma imagem de CRA em uma ordem de saída. Por exemplo, se a primeira imagem codificada no bitream é uma imagem de CRA, e a imagem atual, ou atualmente codificada é a imagem principal da primeira imagem codificada no fluxo de bits, a output_flag da imagem atualmente codificada pode ser definido para ser igual a falso, ou “0” (ex., independente do valor do output_flag no cabeçalho da unidade de NAL das unidades NAL da camada de codificação de vídeo (VCL) da imagem codificada). Neste exemplo, o processo de decodificação para gerar imagens de referência faltantes (como mostrado abaixo) pode ser invocado (ex., este processo pode somente ser necessário para ser invocado para uma fatia de uma imagem).

[0148] Além disso, pode haver uma ou mais imagens de referência que estão incluídas no RPS, mas que não estão presentes no DPB. Entradas em RefPicSetStFoll ou RefPicSetLtFoll iguais a “nenhuma imagem de referência” podem ser ignoradas se a primeira imagem codificada no fluxo de bits é uma imagem de IDR, ou se a primeira imagem codificada no fluxo de bits é uma imagem de CRA e a imagem atualmente codificada não é a imagem principal da primeira imagem codificada no fluxo de bits. Por exemplo, uma perda de imagem não intencional pode ser inferida para cada entrada em RefPicSetStCurr0, RefPicSetStCurr1, e RefPicSetLtCurr igual a “nenhuma imagem de referência.”

[0149] Adicionalmente, se a primeira imagem codificada no fluxo de bits é uma imagem de IDR, ou se a primeira imagem codificada no fluxo de bits é uma imagem de CRA e a imagem atualmente codificada não é a imagem principal da primeira imagem codificada no fluxo de bits, pode não haver entrada em RefPicSetStCurr0, RefPicSetStCurr1, ou RefPicSetLtCurr igual a “nenhuma imagem de referência.

[0150] O processo de decodificação para gerar imagens de referência faltantes pode ser especificado como segue. Este processo pode ser invocado uma vez por imagem codificada, após a invocação do processo de decodificação para o RPS (como especificado na sub-cláusula 8.2.2 em HEVC WD5, no documento “JCTVC-G1103”, por exemplo, na versão “d9” do documento). Quando a primeira imagem codificada no fluxo de bits é uma imagem de CRA, e a imagem atualmente codificada é a imagem principal da primeira imagem codificada no fluxo de bits, o seguinte pode ser aplicado: 1) Para cada RefPicSetStCurr0[i], com “i” estando na faixa de “0” a NumPocStCurrO - 1, inclusive, que é igual a “nenhuma imagem de referência,” a imagem de referência pode ser gerada pela invocação do processo de decodificação para gerar uma imagem de referência faltante, como especificado abaixo. Adicionalmente, o seguinte pode ser aplicado: A) O valor de PicOrderCntVal para a imagem de referência gerada pode ser definido para PocStCurr0[i]. B) O valor de output_flag para a imagem de referência gerada pode ser definido para “0.” C) A imagem de referência gerada pode ser marcada como “usado para referência de curto prazo.” D) RefPicSetStCurr0[i] pode ser definido para ser a imagem de referência gerada. 2) Para cada RefPicSetStCurr1[i], com “i” estando na faixa de “0” a NumPocStCurr1 - 1, inclusive, que é igual a “nenhuma imagem de referência,” a imagem de referência pode ser gerada pela invocação do processo de decodificação para gerar uma imagem de referência faltante, como especificado abaixo. Adicionalmente, o seguinte pode ser aplicado: A) O valor de PicOrderCntVal para a imagem de referência gerada pode ser definido para PocStCurr1[i]. B) O valor de output_flag para a imagem de referência gerada pode ser definido para “0.” C) A imagem de referência gerada pode ser marcada como “usada para referência de curto prazo.” D) RefPicSetStCurr1[i] pode ser definido para ser a imagem de referência gerada. 3) Para cada RefPicSetLtCurr[i], com “i” estando na faixa de “0” a NumPocLtCurr - 1, inclusive, que é igual a “nenhuma imagem de referência,” a imagem de referência pode ser gerada pela invocação do processo de decodificação para gerar uma imagem de referência faltante, como especificado abaixo. Adicionalmente, o seguinte pode ser aplicado: A) O valor de pic_order_cnt_lsb para a imagem de referência gerada pode ser definido para PocLtCurr[i]. B) O valor de output_flag para a imagem de referência gerada pode ser definido para “0.” C) A imagem de referência gerada pode ser marcada como “usada para referência a longo prazo.” D) RefPicSetLtCurr[i] pode ser definido para ser a imagem de referência gerada.

[0151] Em alguns exemplos, o processo de decodificação para gerar uma imagem de referência faltante pode ser especificado como segue: 1) O valor de cada elemento na matriz de amostra SL pode ser definido para 1<< (BitDepthY - 1). 2) O valor de cada elemento na matriz de amostras SCb e SCr pode ser definido para 1<< (BitDepthC - 1). 3) O modo de precisão PredMode para cada CU mínima pode ser definido para MODE_INTRA.

[0152] Alternativamente, cada LCU pode ser dividida em uma CU mínima, e a CU mínima pode ser definida para MODE_INTRA.

[0153] Alternativamente, cada LCU pode ser definido para ser MODE_INTRA.

[0154] Des sa forma, em alguns exemplos de acordo com as técnicas desta divulgação, codificador de vídeo 20 do dispositivo de origem 12 pode ser configurado para codificar uma ou mais imagens de dados de vídeo. Nestes exemplos, o decodificador de vídeo 30 do dispositivo de destino 14 pode ser configurado para receber as uma ou mais imagens codificadas a partir do codificador de vídeo 20, ex., como parte de um fluxo de bits codificado gerado pelo codificador de vídeo 20 e recebido pelo decodificador de vídeo 30, e decodificar as uma ou mais imagens.

[0155] Como um exemplo, decodificador de vídeo 30 pode ser configurado para receber um fluxo de bits que inclui uma ou mais imagens de uma CVS. O decodificador de vídeo 30 pode ser ainda configurado para decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS. Neste exemplo, a primeira imagem pode ser uma imagem de RAP que não é uma imagem de IDR. O decodificador de vídeo 30 também pode ser configurado para decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0156] Como outro exemplo, o codificador de vídeo 20 pode ser configurado para gerar um fluxo de bits que inclui uma ou mais imagens de uma CVS. Neste exemplo, a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS pode ser uma imagem de RAP que não é uma imagem de IDR. também neste exemplo, para gerar um fluxo de bits, o codificador de vídeo 20 pode ser configurado para evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem, no fluxo de bits. Por exemplo, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com uma ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Neste exemplo, a primeira imagem pode ser decodificável, i.e., capaz de ser decodificada, por exemplo, pelo decodificador de vídeo 30. Também neste exemplo, pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, também pode ser decodificável, com base na primeira imagem decodificada. Por exemplo, a pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação pode ser decodificável usando uma versão decodificada da primeira imagem como uma imagem de referência.

[0157] De sta maneira, o decodificador de vídeo 30 pode decodificar um fluxo de bits, ex., gerado pelos codificador de vídeo 20, que inclui uma ou mais imagens de dados de vídeo e começa com uma imagem RAP não-IDR, de uma maneira previsível e definida, como especificado pelas técnicas desta divulgação. Como um resultado, pode haver uma melhoria relativa na experiência do usuário ao realizar o acesso aleatório de um fluxo de bits que inclui uma ou mais imagens de dados de vídeo, ao usar as técnicas divulgadas. Em particular, o decodificador de vídeo 30 pode ser capaz de decodificar o fluxo de bits com granularidade relativamente maior. Em outras palavras, o decodificador de vídeo 30 pode ser capaz de acessar aleatoriamente o fluxo de bits em relativamente mais pontos, ou imagens (i.e., imagem de não-IDR) do fluxo de bits, em comparação com outras técnicas (ex., técnicas que permitem acesso aleatório de um fluxo de bits somente a partir das imagens de IDR. Adicionalmente, pode haver uma melhoria relativa na qualidade visual de uma ou mais imagens de uma CVS incluída no fluxo de bits, e/ou da CVS como um todo, ao usar as técnicas desta divulgação.

[0158] Codificador de vídeo 20 e decodificador de vídeo 30 cada podem ser implementados como qualquer de uma variedade de circuitos de codificador ou decodificador adequados, como aplicável, como um ou mais microprocessadores, DSPs, ASICs, FPGAs, circuitos de lógica discreta, software, hardware, firmware, ou qualquer combinação dos mesmos. Cada um dentre codificador de vídeo 20 e decodificador de vídeo 30 pode ser incluído em um ou mais codificadores ou decodificadores, qualquer um dos quais pode ser integrado como parte de um codificador/decodificador de vídeo combinado (CODEC). Um equipamento incluindo o codificador de vídeo 20 e/ou decodificador de vídeo 30 pode compreender um circuito integrado (IC), um microprocessador, e/ou um dispositivo de comunicação sem fio, como um telefone celular.

[0159] FIG. 2 é um diagrama em bloco que ilustra um exemplo de um codificador de vídeo que pode realizar as técnicas para acesso aleatório com gestão de DPB avançada, de acordo com as técnicas desta divulgação. O codificador de vídeo 20 pode realizar a intra- e inter- codificação dos blocos de vídeo dentro das fatias de vídeo. Intra-codificação depende da predição espacial para reduzir ou remover a redundância espacial no vídeo dentro de um dado quadro de vídeo ou imagem. A inter-codificação depende da predição temporal para reduzir ou remover a redundância temporal no vídeo dentro de quadros ou imagens adjacentes de uma sequência de vídeo. O intra-modo (modo I) pode se referir a qualquer um dos vários modos de compressão baseados no espaço. Inter-modos, como a predição uni- direcional (modo P) ou bi-predição (modo B), pode se referir a qualquer um dos vários modos de compressão baseados no tempo.

[0160] No exemplo da FIG. 2, o codificador de vídeo 20 inclui a unidade de seleção de modo 40, unidade de estimativa de movimento 42, unidade de compensação de movimento 44, unidade de processamento de intra-predição 46, memória da imagem de referência 66, somador 50, unidade de processamento de transformada 52, unidade de quantização 54, e unidade de codificação por entropia 56. Para a reconstrução do bloco de vídeo, o codificador de vídeo 20 também inclui a unidade de quantização inversa 58, unidade de processamento de transformada inversa 60, e somador 62. Um filtro de desbloqueio 64 é também incluído para filtrar os limites do bloco para remover artefatos de blocagem a partir do bloco reconstruído.

[0161] Como mostrado na FIG. 2, o codificador de vídeo 20 recebe um bloco de vídeo atual dentro de uma fatia de vídeo a ser codificada. A fatia pode ser dividida em vários blocos de vídeo. A unidade de seleção de modo 40 pode selecionar um dos modos de codificação, intra- ou inter-, para um bloco de vídeo atual com base em resultados de erro. Se os modos intra- ou inter- são selecionados, a unidade de seleção de modo 40 fornece o bloco intra- ou inter-codificado resultante para o somador 50 para gerar dados do bloco residual e para o somador 62 reconstruir o bloco codificado para uso como a imagem de referência. A unidade de processamento de intra-predição 46 realiza a codificação intra-predita do bloco de vídeo atual em relação a um ou mais blocos vizinhos no mesmo quadro ou fatia como o bloco atual a ser codificado para fornecer a compressão espacial. A unidade de estimativa de movimento 42 e unidade de compensação de movimento 44 realizam a codificação intre-predita do bloco de vídeo atual em relação a um ou mais blocos preditivos em uma ou mais imagens de referência para fornecer a compressão temporal.

[0162] No caso da inter-codificação, a unidade de estimativa de movimento 42 pode ser configurada para determinar o modo de inter-predição para uma fatia de vídeo de acordo com um padrão predeterminado para uma sequência de vídeo. O padrão predeterminado pode designar fatias de vídeo na sequência como fatias P, fatias B ou fatias GPB. A unidade de estimativa de movimento 42 e unidade de compensação de movimento 44 podem ser altamente integradas, mas são ilustradas separadamente para fins conceituais. A estimativa de movimento, realizada pela unidade de estimativa de movimento 42, é o processo de geração dos vetores de movimento, que estima o movimento para os 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 de vídeo ou imagem atuais em relação a um bloco preditivo dentro da imagem de referência.

[0163] Um bloco preditivo é um bloco que é encontrado por corresponder muito de perto à PU do bloco de vídeo a ser codificado em termos de diferença de pixel, que pode ser determinado pela soma da diferença absoluta (SAD), soma da diferença ao quadrado (SSD), ou outras métricas diferentes. Em alguns exemplos, o codificador de vídeo 20 pode calcular valores para posições de pixel de sub-inteiro das imagens de referência armazenadas na memória da imagem de referência 66. Por exemplo, o codificador de vídeo 20 pode calcular valores de posições de um quarto de pixel, posições de um oitavo de pixel, ou outras posições de pixel fracionário da imagem de referência. Portanto, a unidade de estimativa de movimento 42 pode realizar uma pesquisa de movimento em relação às posições de pixel cheias e posições de pixel fracionárias e produzir um vetor de movimento com predição de pixel fracionária.

[0164] Unidade de estimativa de movimento 42 calcula um vetor de movimento para uma PU de um bloco de vídeo em uma fatia inter-codificada pela comparação da posição da PU à posição de um bloco preditivo da 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 da imagem de referência 66. A unidade de estimativa de movimento 42 envia o vetor de movimento calculado para a unidade de codificação por entropia 56 e unidade de compensação de movimento 44.

[0165] A compensação do movimento, realizada pela unidade de compensação de movimento 44, pode envolver buscar ou gerar um bloco preditivo com base no vetor de movimento determinado pela estimativa de movimento. Mediante recebimento do vetor de movimento para a PU do bloco de vídeo atual, a unidade de compensação de movimento 44 pode localizar o bloco preditivo para o qual o vetor de movimento aponta em uma das listas de imagem de referência. O codificador de vídeo 20 forma um bloco de vídeo residual pela subtração de valores de pixel do bloco preditivo a partir dos valores de pixel do bloco de vídeo atual sendo codificado, formando valores de diferença de pixel. Os valores de diferença de pixel a partir dos dados residuais para um bloco, e podem incluir ambos componentes de diferença luma e croma. O somador 50 representa o componente ou componentes que realizam esta operação de subtração. A unidade de compensação de movimento 44 pode também gerar elementos de sintaxe associados com um bloco de vídeo e a 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.

[0166] Após a unidade de compensação de movimento 44 gerar o bloco preditivo para um bloco de vídeo atual, o codificador de vídeo 20 forma um bloco de vídeo residual pela subtração do bloco preditivo a partir do bloco de vídeo atual. Os dados de vídeo residuais no bloco residual podem ser incluídos em uma ou mais TUs e aplicados à unidade de processamento de transformada 52. A unidade de processamento de transformada 52 transforma os dados de vídeo residuais em coeficientes de transformada residuais usando uma transformada, como uma transformada de cosseno discreta (DCT) ou uma transformada conceitualmente similar. A unidade de processamento de transformada 52 pode converter os dados de vídeo residuais a partir de um domínio de pixel para um domínio de transformada, como um domínio de frequência.

[0167] A unidade de processamento de transformada 52 pode enviar os coeficientes de transformada resultantes para a unidade de quantização 54. A unidade de quantização 54 quantifica os coeficientes de transformada para ainda reduzir a taxa de bit. O processo de quantização pode reduzir a profundidade de bit associada com alguns ou todos dos coeficientes. O grau de quantização pode ser modificado pelo ajuste de um parâmetro de quantização (QP). Em alguns exemplos, a unidade de quantização 54 pode então realizar uma varredura da matriz incluindo os coeficientes de transformada quantizados. Alternativamente, a unidade de codificação por entropia 56 pode realizar a varredura.

[0168] Após a quantização, a unidade de codificação por entropia 56 codifica por entropia os coeficientes de transformada quantizados. Por exemplo, unidade de codificação por entropia 56 pode realizar CAVLC, CABAC, ou outra técnica de codificação por entropia. Seguindo a codificação por entropia pela unidade de codificação por entropia 56, o fluxo de bits codificado pode ser transmitido para decodificador de vídeo 30, ou arquivado para posterior transmissão ou recuperação pelo decodificador de vídeo 30. A unidade de codificação por entropia 56 pode também codificar por entropia o vetor de movimentos e os outros elementos de sintaxe para uma fatia de vídeo atual sendo codificada.

[0169] A unidade de quantização inversa 58 e unidade de processamento de transformada inversa 60 aplicam a quantização inversa e transformação inversa, respectivamente, para reconstruir o bloco residual no domínio de pixel para uso posterior como um bloco de referência de uma imagem de referência. A unidade de compensação de movimento 44 pode calcular um bloco de referência pela adição do bloco residual a um bloco preditivo de uma das imagens de referência dentro de uma das listas de imagem de referência. A unidade de compensação de movimento 44 pode também aplicar um ou mais filtros de interpolação ao bloco residual reconstruído para calcular valores de pixel sub-inteiros para uso na estimativa de movimento. O somador 62 adiciona o bloco residual reconstruído para o bloco de predição de movimento compensado produzido pela unidade de compensação de movimento 44 para produzir um bloco de referência para armazenamento na memória da imagem de referência 66. O bloco de referência pode ser usado pela unidade de estimativa de movimento 42 e unidade de compensação de movimento 44 como um bloco de referência para inter-prever um bloco em um quadro de vídeo ou imagem subsequente.

[0170] Como um exemplo, o codificador de vídeo 20 pode ser configurado para codificar uma ou mais imagens de dados de vídeo durante um processo de codificação de vídeo. Por exemplo, codificador de vídeo 20 pode ser configurado para gerar um fluxo de bits que inclui uma ou mais imagens de uma CVS, sendo que a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS é uma imagem de RAP que não é uma imagem de IDR. Neste exemplo, para gerar um fluxo de bits, o codificador de vídeo 20 pode ser configurado para evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem no fluxo de bits. Por exemplo, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Também neste exemplo, como um resultado do codificador de vídeo 20 gerar um fluxo de bits da maneira descrita acima, a primeira imagem pode ser decodificada com sucesso (ex., pelo decodificador de vídeo 30), i.e., ser decodificável. Adicionalmente, pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, também pode ser decodificada com sucesso (ex., pelo decodificador de vídeo 30), ou ser decodificável, com base na primeira imagem (ex., usando a primeira imagem como uma imagem de referência, após a primeira imagem ter o lado decodificado como descrito acima).

[0171] Des sa forma, como explicado acima, as técnicas desta divulgação podem permitir que o codificador de vídeo 20 gere um fluxo de bits que pode ser decodificado por um decodificador de vídeo, ex., decodificador de vídeo 30, de uma maneira previsível e definida, como especificado pelas técnicas desta divulgação. Em particular, o fluxo de bits pode incluir uma ou mais imagens de uma CVS dos dados de vídeo. O fluxo de bits pode ser recebido pelo decodificador de vídeo tal que o fluxo de bits começa com uma imagem RAP não-IDR. Usando as técnicas desta divulgação, o decodificador de vídeo pode decodificar com sucesso o fluxo de bits. Como tal, pode haver uma melhoria relativa na experiência do usuário ao realizar o acesso aleatório do fluxo de bits, ao usar as técnicas divulgadas. Como um exemplo, as técnicas podem permitir que o decodificador de vídeo decodifique o fluxo de bits com granularidade relativamente maior. Em outras palavras, as técnicas podem permitir que o decodificador de vídeo acesse aleatoriamente o fluxo de bits em relativamente mais pontos, ou imagens (i.e., imagem de não-IDR) do fluxo de bits, em comparação com outras técnicas (ex., técnicas que permitem acesso aleatório de um fluxo de bits somente a partir das imagens de IDR). Como outro exemplo, pode haver uma melhoria relativa na qualidade visual de uma ou mais imagens da CVS incluída no fluxo de bits, e/ou da CVS como um todo (ex., pelo codificador de vídeo 20 omitindo as imagens principais associada com a primeira imagem a partir do fluxo de bits), ao usar as técnicas divulgadas.

[0172] De sta maneira, codificador de vídeo 20 representa um exemplo de um codificador de vídeo configurado para gerar um fluxo de bits que inclui uma ou mais imagens de uma CVS, sendo que a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS é uma imagem de RAP que não é uma Imagem de IDR, sendo que para gerar um fluxo de bits, o codificador de vídeo é configurado para evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem no fluxo de bits, sendo que a imagem principal é a imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS, e sendo que a primeira imagem é decodificável, e sendo que pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, é decodificável com base na primeira imagem.

[0173] FIG. 3 é um diagrama em bloco que ilustra um exemplo de um decodificador de vídeo que pode realizar as técnicas para acesso aleatório com gestão de DPB avançada, de acordo com as técnicas desta divulgação. No exemplo da FIG. 3, o decodificador de vídeo 30 inclui uma unidade de decodificação por entropia 80, uma unidade de processamento de predição 82, uma unidade de quantização inversa 88, uma unidade de processamento de transformada inversa 90, um somador 92, um filtro de desbloqueio 94, e uma memória da imagem de referência 96. A unidade de processamento de predição 82 inclui a unidade de compensação de movimento 84 e a unidade de processamento de intra-predição 86. O decodificador de vídeo 30 pode, em alguns exemplos, realizar uma passada decodificação geralmente recíproca à passada de codificação descrita com relação ao codificador de vídeo 20 a partir da FIG. 2.

[0174] Durante o processo de decodificação, o decodificador de vídeo 30 recebe um fluxo de bits de vídeo codificado que representa os blocos de vídeo de uma fatia de vídeo codificada e elementos de sintaxe associados a partir do codificador de vídeo 20. Quando os blocos de vídeo representados no fluxo de bits incluem dados de vídeo comprimidos, a unidade de decodificação por entropia 80 do decodificador de vídeo 30 decodifica por entropia o fluxo de bits para gerar coeficientes quantizados, vetores de movimento, e outros elementos de sintaxe. A unidade de decodificação por entropia 80 encaminha os vetores de movimento e outros elementos de sintaxe para a unidade de processamento de predição 82. O decodificador de vídeo 30 pode receber os elementos de sintaxe em um nível de fatia de vídeo e/ou o nível de bloco de vídeo.

[0175] Quando uma fatia de vídeo é codificada como uma fatia intra-codificada (I), a unidade de processamento de intra-predição 86 da unidade de processamento de predição 82 pode gerar dados de predição para um bloco de vídeo da fatia de vídeo atual com base em um modo de intra-predição sinalizado e dados a partir dos blocos decodificados anteriormente do quadro ou imagem atual. Quando o quadro de vídeo é codificado como uma fatia inter-codificada (i.e., B, P ou GPB), a unidade de compensação de movimento 84 da unidade de processamento de predição 82 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 80. Os blocos preditivos podem ser produzidos a partir de uma das imagens de referência dentro de uma das listas de imagem de referência. O decodificador de vídeo 30 pode construir as listas de quadro de referência, Lista 0 e Lista 1, usando técnicas de construção padrão com base nas imagens de referência armazenadas na memória da imagem de referência 96.

[0176] A unidade de compensação de movimento 84 determina a informação de predição para um bloco de vídeo da fatia de vídeo atual ao analisar os vetores de movimento e outros elementos de sintaxe, e usa a informação de predição para produzir os blocos preditivos para um bloco de vídeo atual sendo decodificado. Por exemplo, a unidade de compensação de movimento 84 usa alguns dos elementos de sintaxe recebidos para determinar um modo de predição (ex., intra- ou inter-predição) usado para codificar os blocos de vídeo da fatia de vídeo, um tipo de fatia de inter-predição (ex., fatia B, fatia P, ou fatia GPB), informação de construção para uma ou mais das listas de imagem de referência para uma fatia, vetores de movimento para cada bloco de vídeo inter-codificado da fatia, status de inter-predição para cada bloco de vídeo inter-codificado da fatia, e outras informações para decodificar os blocos de vídeo na fatia de vídeo atual.

[0177] A unidade de compensação de movimento 84 pode também realizar a interpolação com base nos filtros de interpolação. A unidade de compensação de movimento 84 pode usar filtros de interpolação como usados pelo codificador de vídeo 20 durante a codificação dos blocos de vídeo para calcular valores interpolados para pixels sub- inteiros dos blocos de referência. A unidade de compensação de movimento 84 pode determinar os filtros de interpolação usados pelo codificador de vídeo 20 a partir dos elementos de sintaxe recebidos e usar os filtros de interpolação para produzir blocos preditivos.

[0178] A unidade de quantização inversa 88 quantifica inversamente, i.e., de-quantiza, os coeficientes de transformada quantizados fornecidos no fluxo de bits e decodificados pela unidade de decodificação por entropia 80. O processo de quantização inverso pode incluir uso de um parâmetro de quantização (QP) calculado pelo codificador de vídeo 20 para cada bloco de vídeo em uma fatia de vídeo para determinar um grau de quantização e, do mesmo modo, um grau de quantização inversa que deveria ser aplicado. A unidade de processamento de transformada inversa 90 aplica uma transformada inversa, ex., uma DCT inversa, uma transformada inteira inversa, ou um processo de transformada inversa conceitualmente similar, aos coeficientes de transformada para produzir blocos residuais no domínio de pixel.

[0179] Após a unidade de compensação de movimento 84 gerar o bloco preditivo para um 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 pela soma dos blocos residuais a partir da unidade de processamento de transformada inversa 90 com os blocos preditivos correspondentes gerados pela unidade de compensação de movimento 84. O somador 92 representa o componente ou componentes que realizam esta operação de soma. Um filtro de desbloqueio 94 é aplicado para filtrar os blocos decodificados para remover artefatos de blocagem. Os blocos de vídeo decodificados em um dado quadro ou imagem são então armazenados na memória da imagem de referência 96, que armazena as imagens de referência usadas para uma compensação do movimento subsequente. A memória da imagem de referência 96 também armazena vídeo decodificado para apresentação posterior em um dispositivo de exibição, como dispositivo de exibição 28 da FIG. 1.

[0180] Como um exemplo, o decodificador de vídeo 30 pode ser configurado para decodificar uma ou mais imagens de dados de vídeo durante um processo de decodificação de vídeo. Por exemplo, o decodificador de vídeo 30 pode ser configurado para receber um fluxo de bits, ex., gerado pelo codificador de vídeo 20, que inclui uma ou mais imagens de uma CVS. O decodificador de vídeo 30 pode ser ainda configurado para decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS. Neste exemplo, a primeira imagem pode ser uma imagem de RAP que não é uma imagem de IDR. O decodificador de vídeo 30 também pode ser configurado para decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0181] Em alguns exemplos, o decodificador de vídeo 30 pode ser ainda configurado para determinar (ou identificar) pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem. Em outras palavras, o decodificador de vídeo 30 pode ser configurado para identificar pelo menos uma imagem principal que é associada com a primeira imagem dentre as uma ou mais imagens. Nestes exemplos, a imagem principal pode mais uma vez ser a imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Por exemplo, o decodificador de vídeo 30 pode ser configurado para decodificar as pelo menos uma de uma ou mais imagens. Para decodificar cada de pelo menos uma de uma ou mais imagens, o decodificador de vídeo 30 pode ser configurado para determinar, ou identificar, uma ou mais imagens de referência usadas para codificar a respectiva imagem, determinar quando quaisquer das uma ou mais imagens de referência determinadas ou identificadas está disponível para ser decodificada, para cada de uma ou mais imagens de referência determinadas ou identificadas que é determinada por estar indisponível para ser decodificada, gerar uma imagem de referência virtual, e decodificar a respectiva imagem com base na uma ou mais imagens de referência virtuais correspondentes geradas.

[0182] Nos exemplos descritos acima, para gerar a imagem de referência virtual, o decodificador de vídeo 30 pode ser configurado para gerar uma imagem que inclui um ou mais valores de pixel que correspondem cada a um meio de uma faixa de valores de pixel associada com a CVS. Por exemplo, o decodificador de vídeo 30 pode ser configurado para gerar a imagem tal que a imagem inclui um ou mais valores de pixel cada um tendo valores de “luma” ou “croma” de “127.” Neste exemplo, cada um desses valores de pixel pode corresponder a um meio de uma faixa de valores de intensidade de pixel luma ou croma definidos a partir de um valor de intensidade de pixel de “0” para um valor de intensidade de pixel de “255.” Por exemplo, cada um dos valores de intensidade de pixel luma ou croma podem ser representados usando 7 bits de dados, resultando na faixa de valores descrita acima. Em outros exemplos, no entanto, a faixa de intensidade de pixel luma ou croma, e os valores médios correspondentes, da faixa, podem ser definidos de uma maneira diferente.

[0183] Em alguns exemplos, decodificador de vídeo 30 pode ser ainda configurado para determinar, ou identificar, pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem. Nestes exemplos, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Também nestes exemplos, o decodificador de vídeo 30 pode ser configurado para não produzir, ou evitar produzir, uma ou mais de pelo menos uma de uma ou mais imagens (i.e., uma ou mais das imagens principais anteriormente determinadas, ou identificadas, associadas com a primeira imagem) para as quais uma bandeira de saída (ex., elemento de sintaxe output_flag descrito acima) identifica que a respectiva imagem deve ser produzida.

[0184] Em outros exemplos, decodificador de vídeo 30 pode ser ainda configurado para determinar, ou identificar, pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem. Nestes exemplos, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Também nestes exemplos, o decodificador de vídeo 30 pode ser configurado para não usar, ou evitar usar, uma ou mais de pelo menos uma de uma ou mais imagens (i.e., uma ou mais das imagens principais anteriormente determinadas, ou identificadas, associadas com a primeira imagem) como uma imagem de referência para decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, que segue a primeira imagem de acordo com a ordem de decodificação e de acordo com uma ordem de exibição associada com a CVS.

[0185] Em alguns exemplos, a primeira imagem pode ser uma imagem de CRA. Nestes exemplos, a imagem de CRA pode ser uma imagem que é codificada usando codificação de intra-predição e é capaz de ser decodificada, i.e., é decodificável, sem referência a qualquer outra imagem. Nestes exemplos, para uma imagem de CRA, uma ou mais imagens incluídas dentro de uma CVS junto com a imagem de CRA que segue a imagem de CRA de acordo com uma ordem de decodificação associada com a CVS pode ser decodificada com referência a uma ou mais imagens que precedem a imagem de CRA de acordo com a ordem de decodificação. Por exemplo, a imagem de CRA pode ser referida como uma imagem intra- codificada de “GOP aberta”, como descrito acima com referência à FIG. 1. como também descrito acima, a imagem de CRA pode servir como uma finalidade similar como uma imagem de IDR em uma configuração de “GOP fechada”, particularmente com relação a permitir o acesso aleatório de um fluxo de bits que inclui uma ou mais imagens de uma ou mais GOPs de dados de vídeo.

[0186] Em outros exemplos, a imagem de IDR pode ser uma imagem que é codificada usando codificação de intra-predição e é capaz de ser decodificada, i.e., é decodificável, sem referência a qualquer outra imagem. Nestes exemplos, para a imagem de IDR, todas as outras imagens incluídas dentro de uma CVS junto com a imagem de IDR que segue a imagem de IDR de acordo com uma ordem de decodificação associada com a CVS pode ser decodificada sem referência a quaisquer imagens que precedem uma imagem de IDR de acordo com a ordem de decodificação.

[0187] Ainda em outros exemplos, ex., em casos onde o fluxo de bits recebido pelo decodificador de vídeo 30 não inclui quaisquer imagens principais associadas com a primeira imagem (por exemplo, nos casos onde codificador de vídeo 20 gerou o fluxo de bits pela exclusão das imagens principais da primeira imagem a partir do fluxo de bits), decodificador de vídeo 30 pode ser configurado para decodificar como fluxo de bits em um modo particular, como ilustrado pelos exemplos abaixo.

[0188] Como um exemplo, decodificador de vídeo 30 pode ser ainda configurado para decodificar um primeiro conjunto de parâmetros de retardo inicial do buffer da imagem codificada (CPB), e, quando a uma ou mais imagens não incluem pelo menos uma imagem principal associada com a primeira imagem, decodificar um de um segundo conjunto de parâmetros de retardo inicial de CPB, sendo que um segundo conjunto é diferente do primeiro conjunto, e um conjunto de parâmetros de deslocamento de retardo de CPB. Neste exemplo, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS.

[0189] No exemplo acima descrito, um ou mais dos primeiro e segundo conjuntos de parâmetros de retardo inicial de CPB e os conjuntos de parâmetros de deslocamento de retardo de CPB podem ser incluídos em uma de uma mensagem de informação de melhoria suplementar (SEI), uma mensagem de SEI de período de armazenamento em buffer da imagem, e um cabeçalho de fatia, associada com a primeira imagem.

[0190] Também no exemplo descrito acima, um tempo de remoção de CPB de cada imagem seguindo a primeira imagem na ordem de decodificação pode ser deslocada mais cedo como indicado por um ou mais dos primeiro e segundo conjuntos de parâmetros de retardo inicial de CPB e os conjuntos de parâmetros de deslocamento de retardo de CPB.

[0191] Des sa forma, como explicado acima, as técnicas desta divulgação podem permitir que o decodificador de vídeo 30 decodifique um fluxo de bits, ex., codificado pelo codificador de vídeo 20, de uma maneira previsível e definida, como especificado pelas técnicas desta divulgação. Em particular, o fluxo de bits pode incluir uma ou mais imagens de uma CVS de dados de vídeo. O fluxo de bits pode ser recebido pelo decodificador de vídeo 30 tal que o fluxo de bits começa com uma imagem RAP não-IDR. Usando as técnicas desta divulgação, decodificador de vídeo 30 pode decodificar com sucesso o fluxo de bits. Como tal, pode haver uma melhoria relativa na experiência do usuário ao realizar acesso aleatório do fluxo de bits, ao usar as técnicas divulgadas. Como um exemplo, as técnicas podem permitir que decodificador de vídeo 30 decodifique o fluxo de bits com granularidade relativamente maior. Dito de outra forma, as técnicas podem permitir que decodificador de vídeo 30 acesse aleatoriamente o fluxo de bits em relativamente mais pontos, ou imagens (i.e., imagem de não-IDR) do fluxo de bits, em comparação com outras técnicas (ex., técnicas que permitem acesso aleatório de um fluxo de bits somente a partir das imagens de IDR). Como outro exemplo, pode haver uma melhoria relativa na qualidade visual de uma ou mais imagens da CVS incluída no fluxo de bits, e/ou da CVS como um todo (ex., pelo decodificador de vídeo 30 evitando produzir e usar as imagens de referência as imagens principais associadas com a primeira imagem), ao usar as técnicas divulgadas.

[0192] De sta maneira, decodificador de vídeo 30 representa um exemplo de um decodificador de vídeo configurado para receber um fluxo de bits compreendendo uma ou mais imagens de uma CVS, decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS, sendo que a primeira imagem é uma imagem de RAP que não é uma Imagem de IDR, e decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0200] FIGS. 5 e 6 são fluxogramas que ilustram métodos exemplares de realizar as técnicas para acesso aleatório com gestão de DPB avançada, de acordo com as técnicas desta divulgação. Em particular, o método exemplar da FIG. 5 ilustra a realização como técnicas a partir do ponto de vista de um decodificador de vídeo, ex., decodificador de vídeo 30 das FIGS. 1 e 3. Adicionalmente, o método exemplar da FIG. 6 ilustra a realização como técnicas a partir do ponto de vista de um codificador de vídeo, ex., codificador de vídeo 20 das FIGS. 1 e 2.

[0201] As técnicas das FIGS. 5 e 6 podem geralmente ser realizadas por qualquer unidade de processamento ou processador, se aplicadas em hardware, software, firmware, ou uma combinação dos mesmos, e quando implementada em software ou firmware, hardware correspondentes pode ser fornecida para executar instruções para o software ou firmware. Para fins de exemplo, as técnicas das FIGS. 5 e 6 são descritas com relação aos vários componentes do codificador de vídeo 20 (FIG. 2) e/ou decodificador de vídeo 30 (FIG. 3), embora deva ser compreendido que outros dispositivos podem ser configurados para realizar técnicas similares. Além disso, as etapas ilustradas nas FIGS. 5 e 6 podem ser realizadas em uma ordem diferente ou em paralelo, e etapas adicionais podem ser adicionadas e certas etapas omitidas, sem partir das técnicas desta divulgação. Adicionalmente, de acordo com as técnicas desta divulgação, as técnicas dos métodos exemplares das FIGS. 5 e 6 podem ser realizadas individualmente ou em combinação com outra.

[0202] FIG. 5 é um fluxograma que ilustra um método exemplar de realizar o acesso aleatório de um fluxo de bits que inclui uma ou mais imagens de dados de vídeo por um decodificador de vídeo, ex., o decodificador de vídeo 30 das FIGS. 1 e 3, de acordo com as técnicas desta divulgação. Em particular, as técnicas do método exemplar da FIG. 5 incluem realizar o acesso aleatório do fluxo de bits em casos onde a primeira imagem do fluxo de bits é a imagem RAP não-IDR de uma maneira específica, como descrito abaixo.

[0203] Como um exemplo, decodificador de vídeo 30 pode receber um fluxo de bits que inclui uma ou mais imagens de uma CVS (500). Decodificador de vídeo 30 pode ainda decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS, sendo que a primeira imagem é uma imagem de RAP que não é uma imagem de IDR (502). Decodificador de vídeo 30 pode também decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada (504).

[0204] Em alguns exemplos, decodificador de vídeo 30 pode ainda determinar, ou identificar, pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem. Nestes exemplos, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Decodificador de vídeo 30 pode ainda decodificar as pelo menos uma de uma ou mais imagens. Nestes exemplos, para decodificar cada das pelo menos uma de uma ou mais imagens, decodificador de vídeo 30 pode realizar as etapas a seguir: (1) determinar, ou identificar, uma ou mais imagens de referência usadas para codificar a respectiva imagem; (2) determinar quando qualquer uma ou mais imagens de referência determinadas ou identificadas está disponível para ser decodificada; (3) para cada de uma ou mais imagens de referência determinadas ou identificadas que é determinada para estar indisponível de ser decodificada, gerar uma imagem de referência virtual; e (4) decodificar a respectiva imagem com base na uma ou mais imagens de referência virtuais correspondentes geradas.

[0205] No exemplo acima descrito, para gerar a imagem de referência virtual, decodificador de vídeo 30 pode gerar uma imagem que inclui um ou mais valores de pixel que correspondem cada a um meio de uma faixa de valores de pixel associada com a CVS (ex., um ou mais valores de pixel luma ou croma de “127” dentro de uma faixa de “0” a “255”), como descrito acima com referência à FIG. 3.

[0206] Em alguns exemplos, decodificador de vídeo 30 pode ainda determinar, ou identificar, pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem. Nestes exemplos, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Também nestes exemplos, decodificador de vídeo 30 pode ainda evitar produzir uma ou mais de pelo menos uma de uma ou mais imagens (i.e., uma ou mais das imagens principais anteriormente determinadas, ou identificadas, associadas com a primeira imagem) para as quais uma bandeira de saída (ex., elemento de sintaxe output_flag) identifica que a respectiva imagem deve ser produzida.

[0207] Em outros exemplos, decodificador de vídeo 30 pode ainda determinar, ou identificar, pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem. Nestes exemplos, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS. Também nestes exemplos, decodificador de vídeo 30 pode ainda evitar usar uma ou mais de pelo menos uma de uma ou mais imagens (i.e., uma ou mais das imagens principais anteriormente determinadas, ou identificadas, associadas com a primeira imagem) como uma imagem de referência para decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, que segue a primeira imagem de acordo com a ordem de decodificação e de acordo com uma ordem de exibição associada com a CVS.

[0208] No exemplo acima descrito, a primeira imagem pode ser uma imagem de CRA. Nestes exemplos, a imagem de CRA pode ser uma imagem que é codificada usando codificação de intra-predição e é capaz de ser decodificada, i.e., é decodificável, sem referência a qualquer outra imagem. Nestes exemplos, para uma imagem de CRA, uma ou mais imagens incluídas dentro de um CVS junto com a imagem de CRA que segue a imagem de CRA de acordo com uma ordem de decodificação associada com a CVS pode ser decodificada com referência a uma ou mais imagens que precedem a imagem de CRA de acordo com a ordem de decodificação. Por exemplo, como descrito acima, a imagem de CRA pode ser referida como uma imagem intra-codificada de “GOP aberta”, como descrito acima com referência à FIG. 1. Como também descrito acima, a imagem de CRA pode servir como uma finalidade similar como uma imagem de IDR em uma configuração de “GOP fechada”, particularmente com relação a permitir acesso aleatório de um fluxo de bits que inclui uma ou mais imagens de uma ou mais GOPs dos dados de vídeo.

[0209] Também nos exemplos descritos acima, a imagem de IDR pode ser uma imagem que é codificada usando codificação de intra-predição e é capaz de ser decodificada, i.e., é decodificável, sem referência a qualquer outra imagem. Além disso, a imagem de IDR pode ser uma imagem para a qual todas as outras imagens incluídas dentro de uma CVS junto com a imagem de IDR que segue a imagem de IDR de acordo com uma ordem de decodificação associada com a CVS são decodificadas sem referência a qualquer das imagens que precedem a imagem de IDR de acordo com a ordem de decodificação.

[0210] Ainda em outros exemplos, ex., em casos onde o fluxo de bits recebido pelo decodificador de vídeo 30 não inclui quaisquer imagens principais associadas com a primeira imagem (por exemplo, em casos onde codificador de vídeo 20 gerou o fluxo de bits pela exclusão das imagens principais da primeira imagem a partir do fluxo de bits), decodificador de vídeo 30 pode decodificar o fluxo de bits em um modo particular, como ilustrado pelos exemplos abaixo.

[0211] Como um exemplo, decodificador de vídeo 30 pode ser ainda decodificar um primeiro conjunto de parâmetros de retardo inicial de CPB, e, quando a uma ou mais imagens não inclui pelo menos uma imagem principal associada com a primeira imagem, decodificar um de um segundo conjunto de parâmetros de retardo inicial de CPB, sendo que um segundo conjunto é diferente do primeiro conjunto, e um conjunto de parâmetros de deslocamento de retardo de CPB. Neste exemplo, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS.

[0212] No exemplo acima descrito, um ou mais dos primeiro e segundo conjuntos de parâmetros de retardo inicial de CPB e os conjuntos de parâmetros de deslocamento de retardo de CPB podem ser incluídos em uma de uma mensagem SEI, uma mensagem de SEI de período de armazenamento em buffer da imagem, e um cabeçalho de fatia, associada com a primeira imagem.

[0213] Também no exemplo descrito acima, um tempo de remoção de CPB de cada imagem seguindo a primeira imagem na ordem de decodificação pode ser deslocada mais cedo como indicado por um ou mais dos primeiro e segundo conjuntos de parâmetros de retardo inicial de CPB e os conjuntos de parâmetros de deslocamento de retardo de CPB.

[0214] Desta maneira, o método da FIG. 5 representa um exemplo de um método de receber um fluxo de bits compreendendo uma ou mais imagens de uma CVS, decodificar uma primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS, sendo que a primeira imagem é uma imagem de RAP que não é uma imagem de IDR, e decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem decodificada.

[0215] FIG. 6 é um fluxograma que ilustra um método exemplar de gerar um fluxo de bits que inclui uma ou mais imagens de dados de vídeo por um codificador de vídeo, ex., codificador de vídeo 20 das FIGS. 1 e 2, de acordo com as técnicas desta divulgação. Em particular, as técnicas do método exemplar da FIG. 6 incluem gerar um fluxo de bits, tal que um decodificador de vídeo, ex., decodificador de vídeo 30, pode decodificar com sucesso o fluxo de bits de uma maneira específica. Por exemplo, o decodificador de vídeo pode decodificar os fluxos de bits em casos onde a primeira imagem do fluxo de bits é a imagem RAP não-IDR, como descrito abaixo.

[0216] Como um exemplo, codificador de vídeo 20 pode gerar um fluxo de bits que inclui uma ou mais imagens de uma CVS. Neste exemplo, a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS pode ser uma imagem de RAP que não é uma imagem de IDR (600). Codificador de vídeo 20 pode ainda evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem no fluxo de bits. Neste exemplo, mais uma vez, a imagem principal pode ser uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS (602).

[0217] Neste exemplo, subsequentemente, um decodificador de vídeo, ex., decodificador de vídeo 30, pode receber os fluxo de bits gerados pelo codificador de vídeo 20, e decodificar o fluxo de bits. Por exemplo, o decodificador de vídeo pode decodificar a primeira imagem. O decodificador de vídeo pode ainda decodificar pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, com base na primeira imagem (ex., com base em uma versão decodificada da primeira imagem).

[0218] Desta maneira, o método da FIG. 6 representa um exemplo de um método de gerar um fluxo de bits compreendendo uma ou mais imagens de uma CVS, sendo que a primeira imagem de uma ou mais imagens de acordo com uma ordem de decodificação associada com a CVS é uma imagem de RAP que não é uma imagem de IDR, sendo que gerar a fluxo de bits compreende evitar incluir pelo menos uma de uma ou mais imagens, que não a primeira imagem, que corresponde a uma imagem principal associada com a primeira imagem no fluxo de bits, sendo que a imagem principal compreende uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada com a CVS, e sendo que a primeira imagem é decodificável, e sendo que pelo menos uma de uma ou mais imagens, que não a primeira imagem, seguindo a primeira imagem de acordo com a ordem de decodificação, é decodificável com base na primeira imagem.

[0219] Em um ou mais exemplos, as funções descritas aqui podem ser implementadas em hardware, software, firmware, ou qualquer combinação dos mesmos. Se implementadas em software, as funções podem ser armazenadas em ou transmitidas através, de uma ou mais instruções ou código, uma mídia legível por computador e executadas por uma unidade de processamento baseada em hardware. Mídia legível por computador pode incluir mídia de armazenamento legível por computador, que pode corresponder à mídia tangível ou não transitória, como mídia de armazenamento de dados, ou mídia de comunicação incluindo qualquer mídia que facilita a transferência de um programa de computador a partir de um lugar para outro, ex., de acordo com um protocolo de comunicação. Desta maneira, a mídia legível por computador geralmente pode corresponder à (1) mídia de armazenamento legível por computador tangível, que é não- transitória ou (2) uma mídia de comunicação, como um sinal ou onda de transportador. A mídia de armazenamento de dados pode ser qualquer mídia disponível que pode ser acessada por um ou mais computadores ou um ou mais processadores para recuperar as instruções, código e/ou estruturas de dados para a implementação das técnicas descritas nesta divulgação. Um produto de programa de computador pode incluir uma mídia legível por computador.

[0220] A título de exemplo, e não como limitação, tal mídia de armazenamento legível por computador pode compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco ótico, armazenamento em disco magnético, ou outros dispositivos de armazenamento magnéticos, memória flash, ou qualquer outra mídia que pode ser usada para armazenar o código de programa desejado, sob a forma de instruções ou estruturas de dados e que pode ser acessada por um computador. Também, qualquer conexão é corretamente chamada de mídia legível por computador. Por exemplo, se as instruções são transmitidas a partir de um website, servidor, ou outra fonte remota usando um cabo coaxial, cabo de fibra ótica, par trançado, linha de assinante digital (DSL), ou tecnologias sem fio como infravermelho, rádio e micro-ondas, então, o cabo coaxial, cabo de fibra ótica, par trançado, DSL, ou tecnologias sem fio como infravermelho, rádio, e micro-onda são incluídas na definição de mídia. Deve-se compreender, no entanto, que a mídia de armazenamento legível por computador e mídia de armazenamento de dados não incluem conexões, ondas portadoras, sinais, ou outra mídia transitória, mas ao invés são direcionadas para mídia não transiente ou não transitória, mídia de armazenamento tangível. Disquete e disco, como aqui utilizado, inclui disco compacto (CD), disco laser, disco ótico, disco digital versátil (DVD), disquete e disco Blu-ray, onde disquetes costumam reproduzir dados magneticamente, enquanto que os discos reproduzem dados oticamente com lasers. As combinações do acima também devem ser incluídas dentro do escopo da mídia legível por computador.

[0221] As instruções podem ser executadas por um ou mais processadores, como um ou mais microprocessadores de finalidade geral, DSPs, ASICs, FPGAs, ou outro circuito integrado ou de lógica discreta equivalente. Dessa forma, o termo “processador,” como usado aqui, pode se referir a qualquer estrutura anterior ou qualquer outra estrutura adequada para a implementação das técnicas descritas nesta divulgação. Além disso, em alguns aspectos, a funcionalidade descrita aqui pode ser fornecida dentro de módulos de hardware e/ou software dedicados configurados para codificação e decodificação, ou incorporados em um codec combinado. Também, as técnicas poderiam ser plenamente implementadas em um ou mais circuitos ou elementos lógicos.

[0222] As técnicas desta divulgação podem ser implementadas em uma ampla variedade de dispositivos ou aparelhos, incluindo um telefone sem fio, um IC ou um conjunto de ICs (ex., um conjunto de chips). Vários componentes, módulos ou unidades são descritos nesta divulgação para enfatizar aspectos funcionais de dispositivos configurados para executar como técnicas divulgadas, mas não necessariamente exigem a realização por diferentes componentes de hardware, módulos ou unidades. Em vez disso, como descrito acima, várias unidades podem ser combinadas em uma unidade de hardware codec ou fornecidas por um conjunto de unidades de hardware interoperativas, incluindo um ou mais processadores como descrito acima, em conjunto com o software e/ou firmware adequado.

[0223] Vários exemplos foram descritos. Estes e outros exemplos estão dentro do escopo das reivindicações a seguir.

Claims

1. Método para decodificar dados de vídeo, caracterizado pelo fato de que compreende: receber (500) um fluxo de bits compreendendo uma ou mais sequências de vídeo codificadas, CVS, cada CVS compreendendo uma ou mais imagens, em que uma primeira imagem na ordem de decodificação em uma primeira CVS é uma imagem de ponto de acesso aleatório, RAP, que não é uma imagem de atualização de decodificação instantânea, IDR; decodificar um primeiro conjunto de parâmetros de retardo inicial de BUFFER de imagem codificada, CPB; decodificar, quando a uma ou mais imagens de uma CVS não incluírem pelo menos uma imagem principal associada à primeira imagem, um segundo conjunto de parâmetros de retardo inicial de CPB, em que o segundo conjunto de parâmetros de retardo inicial de CPB é diferente do primeiro conjunto de parâmetros de retardo inicial de CPB; e selecionar um dentre os dois parâmetros de retardo inicial de CPB para uma derivação de parâmetros de temporização de CPB, em que, quando a uma ou mais imagens da CVS não incluem pelo menos uma imagem principal associada à primeira imagem, os parâmetros de temporização de CPB são derivados com base no segundo conjunto de parâmetros de retardo inicial de CPB e um tempo de remoção de CPB de cada imagem seguindo a primeira imagem na ordem de decodificação é deslocado mais cedo como indicado pelo segundo conjunto de parâmetros de retardo inicial de CPB, em que a imagem principal compreende uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada à CVS.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o primeiro e segundo conjuntos de parâmetros de retardo inicial de CPB são incluídos em uma dentre uma mensagem de informação de aperfeiçoamento suplementar, SEI, uma mensagem SEI de período de armazenamento em BUFFER de imagem, e um cabeçalho de fatia, associado com a primeira imagem.

3. Método, de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que a primeira imagem compreende uma imagem de acesso aleatório limpa, CRA, em que a imagem de CRA compreende uma imagem que é codificada usando codificação de intra-predição e é decodificável sem referência a qualquer outra imagem, e para a qual uma ou mais imagens incluídas dentro de uma CVS junto com a imagem de CRA que segue a imagem de CRA de acordo com uma ordem de decodificação associada com a CVS pode ser decodificada com referência à uma ou mais imagens que precedem a imagem de CRA de acordo com a ordem de decodificação.

4. Método, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de que a imagem de IDR compreende uma imagem que é codificada usando codificação de intra-predição e é decodificável sem referência a quaisquer outras imagens, e para a qual todas as outras imagens incluídas dentro de uma CVS junto com a imagem de IDR que segue a imagem de IDR de acordo com uma ordem de decodificação associada com a CVS são decodificadas sem referência a quaisquer imagens que precedem a imagem de IDR de acordo com a ordem de decodificação.

5. Dispositivo (14) para decodificar dados de vídeo, caracterizado pelo fato de que compreende: meios para receber um fluxo de bits compreendendo uma ou mais sequências de vídeo codificadas, CVS, cada CVS compreendendo uma ou mais imagens, em que uma primeira imagem na ordem de decodificação em uma primeira CVS é uma imagem de ponto de acesso aleatório, RAP, que não é uma imagem de atualização de decodificação instantânea, IDR; e meios para decodificar um primeiro conjunto de parâmetros de retardo inicial de BUFFER de imagem codificada, CPB; meios para decodificar, quando a uma ou mais imagens de uma CVS não incluem pelo menos uma imagem principal associada à primeira imagem, um segundo conjunto de parâmetros de retardo inicial de CPB, em que o segundo conjunto de parâmetros de retardo inicial de CPB é diferente do primeiro conjunto de parâmetros de retardo inicial de CPB; e meios para selecionar um dentre os dois parâmetros de retardo inicial de CPB para uma derivação de parâmetros de temporização de CPB, em que, quando a uma ou mais imagens da CVS não incluem pelo menos uma imagem principal associada à primeira imagem, os parâmetros de temporização de CPB são derivados com base no segundo conjunto de parâmetros de retardo inicial de CPB e um tempo de remoção de CPB de cada imagem seguindo a primeira imagem na ordem de decodificação é deslocado mais cedo como indicado pelo segundo conjunto de parâmetros de retardo inicial de CPB, em que a imagem principal compreende uma imagem que segue a primeira imagem de acordo com a ordem de decodificação e precede a primeira imagem de acordo com uma ordem de exibição associada à CVS.

6. Dispositivo, de acordo com a reivindicação 5, caracterizado pelo fato de que o primeiro e segundo conjuntos de parâmetros de retardo inicial de CPB são incluídos em uma dentre uma mensagem de informação de aperfeiçoamento suplementar, SEI, uma mensagem SEI de período de armazenamento em BUFFER de imagem, e um cabeçalho de fatia, associado com a primeira imagem.

7. Dispositivo, de acordo com a reivindicação 5 ou 6, caracterizado pelo fato de que a primeira imagem compreende uma imagem de acesso aleatório limpa, CRA, em que a imagem de CRA compreende uma imagem que é codificada usando codificação de intra-predição e é decodificável sem referência a qualquer outra imagem, e para a qual uma ou mais imagens incluídas dentro de uma CVS junto com a imagem de CRA que segue a imagem de CRA de acordo com uma ordem de decodificação associada com a CVS pode ser decodificada com referência à uma ou mais imagens que precedem a imagem de CRA de acordo com a ordem de decodificação.

8. Dispositivo, de acordo com qualquer uma das reivindicações 5 a 7, caracterizado pelo fato de que a imagem de IDR compreende uma imagem que é codificada usando codificação de intra-predição e é decodificável sem referência a quaisquer outras imagens, e para a qual todas as outras imagens incluídas dentro de uma CVS junto com a imagem de IDR que segue a imagem de IDR de acordo com uma ordem de decodificação associada com a CVS são decodificadas sem referência a quaisquer imagens que precedem a imagem de IDR de acordo com a ordem de decodificação.

9. Memória 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 4.