"AGREGAÇÃO COMPATÍVEL INVERSA DE IMAGENS EMCODIFICAÇÃO DE VÍDEO REDIMENSIONAVEL"
CAMPO DA INVENÇÃO
A presente invenção refere-se de modo geral a uma codificação de vídeo.
Mais particularmente, a presente invenção se refere à codificação, armazenamento etransporte de um vídeo redimensionável.
FUNDAMENTOS DA INVENÇÃO
A presente seção pretende oferecer um fundamento ou contexto à invençãoconforme apresentada nas reivindicações. A presente descrição pode incluir conceitos quepodem ser buscados, contudo não são necessariamente aqueles previamente concebidos ouperseguidos. Sendo assim, a menos que de outra forma indicado, o que se descreve nestaseção não constitui uma técnica anterior a presente descrição e reivindicações, matéria dopresente pedido de patente, bem como não se admite ser uma anterioridade por inclusãonesta seção.
A Codificação de Vídeo Redimensionável (SVC) provê fluxos de bits devídeo redimensionáveis. Um fluxo de bits de vídeo redimensionável contém uma camadabase não redimensionável e uma ou mais camadas de aperfeiçoamento. Uma camada deaperfeiçoamento pode aumentar a resolução temporal (isto é, a taxa de quadros), aresolução espacial, ou a qualidade do conteúdo de vídeo representado pela camada inferiorou parte da mesma. As camadas redimensionáveis podem ser agregadas em um únicofluxo de protocolo de transporte em tempo real (RTP) ou transportadas de. formaindependente.
O conceito de uma camada de codificação de vídeo (VCL) e de uma camadade abstração de rede (NAL) é herdado da codificação de vídeo avançada (AVC). Acamada VCL contém a funcionalidade de processamento de sinal do dispositivo codec;mecanismos, tais como transformação, quantização, predição temporal, filtro de Ioop,predição entre camadas. O vídeo codificado de uma camada base ou de aperfeiçoamentoconsiste de uma ou mais fatias. A camada NAL encapsula cada fatia gerada pela camadaVCL em uma ou mais unidades de camada NAL.
Cada camada de codificação SVC é formada pelas unidades de camadaNAL, representando os bits de vídeo codificados da camada. Um fluxo de protocolo RTPque transporta um fluxo de bits de vídeo redimensionável completo transportaria todas asunidades de camada NAL de uma camada base e de uma ou mais camadas deaperfeiçoamento. A codificação SVC especifica a ordem de decodificação destas unidadesde camada NAL.
O conceito de se redimensionar a qualidade de um conteúdo visual por meioda omissão do transporte e da decodificação de todas as camadas de aperfeiçoamento éindicado como um redimensionamento de granulidade grossa (CGS).
Em alguns casos, a taxa de bits de uma dada camada de aperfeiçoamentopode ser reduzida por meio de bits trancados de unidades de camada NAL individuais. Otruncamento resulta em uma degradação normal da qualidade de vídeo da camada deaperfeiçoamento reproduzida. Este conceito é conhecido como redimensionamento degranulidade fina (FGS).
De acordo com o padrão de codificação de vídeo H.264/AVC, uma unidadede acesso compreende uma imagem codificada primária. Em alguns sistemas, a detecçãode limites de unidade de acesso pode ser simplificada por meio da inserção de umaunidade de camada NAL delimitadora de unidade de acesso no fluxo de bits. Nacodificação SVC, uma unidade de acesso pode compreender múltiplas imagens codificadasprimárias, mas no máximo uma imagem em cada combinação única de dependencyid,temporal level, e quality_level.
A codificação de vídeo redimensionável envolve a codificação de uma"camada base" com uma determinada qualidade mínima, assim como a codificação deinformações de aperfeiçoamento que aumenta a qualidade a um nível máximo. A camadabase de fluxos de codificação SVC é normalmente compatível com uma codificação devídeo avançada (AVC). Em outras palavras, os decodificadores de codificação AVCpodem decodificar a camada base de um fluxo de codificação SVC e ignorar os dadosespecíficos à codificação SVC. Este recurso é realizado ao se especificar tipos de unidadesde camada NAL de fatia codificada, específicos à codificação SVC, caso reservados parauso futuro em uma codificação AVC, e deve ser pulado de acordo com a especificação deuma codificação AVC.A identificação de imagens e suas características de redimensionamentodentro de uma unidade de acesso de codificação SVC são importantes por pelo menos doispropósitos. Em primeiro lugar, esta identificação é importante no afinamento de fluxos dedomínio compactado em servidores ou em dispositivos portais. Devido à necessidade de setratar grandes quantidades de dados, estes elementos têm de identificar imagensremovíveis no menor espaço de tempo possível. Em segundo lugar, esta identificação éimportante para a reprodução de áudio e vídeo (playback) de um fluxo com qualidade ecomplexidade desejadas. Os receptores e tocadores (players) devem ser capazes deidentificar as imagens de um fluxo redimensionável incapazes de ou relutantes emdecodificar.
Uma função dos dispositivos portais cientes de mídia ou dos misturadoresde protocolo RTP (os quais podem ser unidades de controle de conferência demultipontos, dispositivos portal entre uma vídeo-telefonia comutada por pacotes oucomutada por circuitos, servidores de aperte-para-falar-pelo-celular (PoC), encapsuladoresde protocolo IP em sistemas portáteis de vídeo-difusão digitais (DVB-H), ou aparelhosdecodificadores que encaminham transmissões de difusão localmente para redesdomésticas sem fio, por exemplo) é controlar a taxa de bits do fluxo encaminhado deacordo com as condições de rede de enlace descendente prevalecente. É desejávelcontrolar a taxa de dados encaminhada sem um processamento extensivo dos dados deentrada, por exemplo, ao simplesmente deixar cair pacotes ou partes de pacotes facilmenteidentificados. Para uma codificação em camadas, os dispositivos portais deixam cairimagens inteiras ou seqüências de imagens que não afetam a decodificação do fluxoencaminhado. O modo de pacotização intercalado da especificação de carga útil de padrãoH. 264/AVC RTP permite o encapsulamento de praticamente todas as unidades de camadaNAL de quaisquer unidades de acesso para a mesma carga útil de protocolo RTP(referidas como um pacote de agregação). Em particular, não se faz necessário encapsularimagens codificadas inteiras em uma carga útil de protocolo RTP, podendo, emcontrapartida, as unidades de camada NAL de uma imagem codificada ser divididas emmúltiplos pacotes de protocolo RTP.
Embora seja bem-vinda esta liberdade de agregação de pacotes para muitasaplicações, esta, por outro lado, ocasiona diversas complicações em uma operação dedispositivo portal. Primeiramente, dado um pacote de agregação, não se sabe a quaisimagens pertencem as suas unidades de camada NAL antes de analisar o cabeçalho de cadaunidade de camada NAL contida no pacote de agregação. Sendo assim, quando um modode pacotização intercalada é aplicado para uma codificação SVC, as camadas às quaispertencem as unidades de camada NAL contidas não são conhecidas antes de se analisar ocabeçalho de cada unidade de camada NAL no pacote. Consequentemente, um dispositivoportal deverá analisar cada cabeçalho de unidade de camada NAL antes de decidir se uma,todas, ou algumas unidades de camada NAL do pacote foram encaminhadas. Em segundolugar, para algumas unidades de camada NAL, tais como as Informações deAperfeiçoamento Suplementares (SEI) e as unidades de camada NAL definidas porparâmetros, não é possível identificar a unidade de acesso a que pertencem antes de asunidades de camada NAL de camada de codificação de vídeo (VCL) da mesma unidade deacesso serem recebidas. Deste modo, o dispositivo portal precisará manter umarmazenador temporário e algumas informações de estado para solucionar o mapeamentode unidades de camada NAL de não camada VCL para suas imagens associadas.
Nos padrões convencionais de codificação de vídeo, um cabeçalho deimagem é usado para separar imagens codificadas. No entanto, no padrão H.264/AVC ena codificação SVC, nenhum cabeçalho de imagem é incluído na sintaxe. Além disso,embora os analisadores tenham a capacidade de analisar informações deredimensionamento para cada unidade de camada NAL em um fluxo, esta ação irárequerer uma quantidade maior de bits da força de processamento, e alguns analisadorespoderão não possuir esta capacidade.
Em adição ao acima apresentado, uma unidade de camada NAL agregadorafoi previamente sugerida no modelo 2 de verificação de formato de arquivo de codificaçãoSVC (documento MPEG M7586). Nesse sistema, a unidade de camada NAL agregadoravem a ser um recipiente que inclui as unidades de camada NAL associadas em sua cargaútil. A unidade de camada NAL agregadora tem um tipo não especificado nasespecificações de padrão H.264/AVC e SVC e deve ser ignorada nos decodificadores depadrão H.264/AVC e SVC. No entanto, quando uma imagem de camada base, de acordocom o padrão H.264/AVC, é encerrada dentro de uma unidade de camada NALagregadora, não mais a mesma poderá ser decodificada com um decodificador de padrãoH.264/AVC, nem poderá ser analisada com depayloadizer de padrão H.264/AVC RTP ouanalisador de formato de arquivo de codificação AVC.
SUMÁRIO DA INVENÇÃO
A presente invenção provê uma unidade de camada NAL agregadoraindireta para o formato de arquivo de codificação SVC e para o formato de carga útil deprotocolo RTP. A unidade de camada NAL agregadora indireta da presente invençãopermite uma fácil identificação de dependências de redimensionamento dentro de um fluxode bits, desta maneira possibilitando uma manipulação rápida e eficaz dos fluxos. Alémdisso, a unidade de camada NAL agregadora indireta da presente invenção garante que acamada base dos fluxos possa também ser processada com um decodificador de padrãoH.264/AVC, com um analisador de formato de arquivo de codificação AVC, ou com umanalisador de carga útil de padrão H.264/AVC RTP.
Estas e outras vantagens e aspectos da presente invenção, juntamente com asua organização e forma de operação, tornar-se-ão aparentes a partir da descriçãodetalhada a seguir, quando tomada em conjunto com os desenhos em anexo, nos quaiselementos similares possuem numerais similares em todos os diversos desenhos descritos aseguir.
BREVE DESCRIÇÃO DOS DESENHOS
A Figura 1 é uma representação esquemática do circuito incluído em umdispositivo eletrônico capaz de servir como codificador ou decodificador naimplementação da funcionalidade da presente invenção;
A Figura 2 mostra um sistema de comunicação de multimídia genérico parauso com a presente invenção; e
A Figura 3 mostra uma disposição de multidifusão de protocolo IP na qualcada roteador pode usar o fluxo de bits de acordo com as suas capacidades.
DESCRIÇÃO DETALHADA DAS MODALIDADES PREFERIDAS
A presente invenção provê uma unidade de camada NAL agregadoraindireta, mais genericamente, uma unidade de dados elementares de informação deredimensionamento, para uso em uma codificação de vídeo redimensionável. A unidade decamada NAL agregadora indireta não contém outras unidades de camada NAL. Emcontrapartida, a unidade de camada NAL agregadora indireta da presente invenção contémmecanismos para sua associação a outras unidades de camada NAL. Esses mecanismosincluem, mas não se limitam ao, número de bytes sucessivos, o número de unidades decamada NAL sucessivas, e o número de unidades de camada NAL remanescentes dentrode um enquadramento de nível superior. Por exemplo, as unidades de camada NALremanescentes dentro do enquadramento de nível superior ficam na mesma carga útil deprotocolo RTP na qual a unidade de camada NAL agregadora indireta também ocorre.
A estrutura para a unidade de camada NAL indireta da presente invençãocompreende ainda informações características ou de propriedade comuns a todas asunidades de camada NAL associadas. As informações características ou de propriedadecomuns incluem, porém não se limitam a, informações de redimensionamento e se asunidades de camada NAL associadas formam um ponto de comutação de camadaredimensionável, no qual uma diferente camada redimensionável poderá comutar para acamada corrente. As informações de redimensionamento podem incluir pelo menos ocabeçalho de unidade de camada NAL "estendido" na especificação de codificação SVC,incluindo os elementos de sintaxe simple_priority_id, discardableflag, dependency_id,temporal level, e quality_level.
A unidade de camada NAL agregadora indireta da presente invenção éselecionada a partir de tais tipos de unidade de camada NAL especificadas como tipos aserem ignorados pelas unidades de processamento para a camada base de padrãoH.264/AVC RTP somente. Em outras palavras, o decodificador de padrão H.264/AVCRTP, o analisador de formato de arquivo de codificação AVC, e o depayloadizer depadrão H.264/AVC RTP devem ignorar a unidade de camada NAL agregadora indireta dapresente invenção. Além disso, a unidade de camada NAL agregadora indireta pode serignorada pelo decodificador de codificação SVC, uma vez que a mesma não traz nenhumefeito normativo ao processo de decodificação. Uma sintaxe ou semântica exemplar daunidade de camada NAL agregadora indireta para o formato de arquivo de codificaçãoSVC, ou outro exemplo para o formato de carga útil de codificação SVC de protocoloRTP, será provido a seguir. Deve-se notar que a presente invenção não se limita a estesexemplos particulares de encapsulamento e formatos de codificação.
Em termos do formato de arquivo de codificação SVC, as unidades decamada NAL agregadoras permitem que as entradas de grupo de mapas de unidade NALUsejam usadas para agrupar unidades de camada NAL de codificação SVC pertencentes àmesma amostra e com as mesmas informações de redimensionamento. As unidades decamada NAL agregadoras usam o mesmo cabeçalho como unidades de camada NAL deextensão redimensionáveis (unidades de camada NAL de codificação SVC), porém umnovo tipo de unidade de camada NAL. Uma unidade de camada NAL agregadora podeconter unidades de camada NAL extratoras. Uma unidade de camada NAL extratora podefazer referência a unidades de camada NAL agregadoras.
Ao varrer o fluxo, caso a unidade NALU agregadora não seja necessária(isto é, quando a mesma pertence a uma camada indesejada), ela e seus conteúdos sãofacilmente descartados (usando o seu campo de comprimento). Caso a unidade NALUagregadora seja necessária, o seu cabeçalho é facilmente descartado e seu conteúdomantido.
Uma unidade de camada NAL agregadora encapsula duas ou mais unidadesde camada NAL de codificação SVC em uma nova unidade de camada NAL. A unidadede camada NAL agregadora usa um cabeçalho de unidade de camada NAL com a mesmasintaxe das unidades de camada NAL de codificação SVC (conforme especificado naespecificação de codificação SVC). Uma unidade de camada NAL agregadora éarmazenada dentro de uma amostra, assim como qualquer outra unidade de camada NAL.
Todas as unidades de camada NAL permanecem em ordem de decodificaçãodentro de uma unidade de camada NAL agregadora. Quando as unidades de camada NALsão agrupadas no mesmo parâmetro quality_level, a ordem das unidades de camada NALcom quality level > O poderá mudar. A sintaxe para a unidade de camada NAL agregadoraé como se segue.
class aligned(8) AggregatorNALUnit(AggregatorNALUnitSize){unsigned int I = 2;/*NALUnitHeader conforme especificada na SVC spec */bit(l) forbiddenzerobit;
bit(2) NAL_ref_idc;
bit(5) NAL_unit_type = AggregatorNALUnitType = const(30);
bit(6) simple_dependency_ID;
bit(l) discardable flag;
bit(l) extension_flag;
if (extension_flag) {
quality_level = simple_dependency_ID;bit (3) temporal level;bit (3) dependency_ID;bit (2) quality_ID;
i+ + ;}
/* end of NAL unit header*/do {
unsigned int((lengthSizeMinusOne +1)*8)NALUnitLength;
bit(NALUnitLength *8)SVCNALUnit;i += (lengthSizeMinusOne + 1)+NALUnitLength;
} while (i< AggregatorNALUnitSize);}
A semântica para a unidade de camada NAL agregadora é como se segue.NALUnitHeader: (8 ou 16 bits) conforme especificado na especificação decodificação SVC:
NAL_unit_type definido para o tipo de unidade de camada NAL agregadora(tipo 30).
A informação de redimensionamento (NALrefidc,simple dependency lD, discardable_flag, informação de redimensionamento estendida)terão os mesmos valores de dentro do cabeçalho de cada unidade de camada NALagregada.NALUnitLength: Especifica o tamanho da unidade de camada NALseguinte. O tamanho deste campo é especificado com a entrada IengthSizeMinusOne.
SVCNALUnit: unidade de camada NAL de codificação SVC conformeespecificada na especificação de codificação SVC, incluindo o cabeçalho da unidade decamada NAL codificação SVC. O tamanho da unidade de camada NAL de codificaçãoSVC é especificado pela NALUnitLength.
Presume-se que uma unidade de camada NAL agregadora colete as unidadesde camada NAL de codificação SVC da mesma camada de redimensionamento. Da mesmaforma, pode-se agrupar unidades de camada NAL de codificação SVC de diferentescamadas (por exemplo, o agrupamento de todos os níveis de qualidade (fragmentos deredimensionamento FGS), o agrupamento de todas as unidades de camada NAL com omesmo parâmetro de dependencylD). Neste caso, o cabeçalho de unidade de camadaNAL de agregação sinalizaria informações de redimensionamento de unidades de camadaNAL de codificação SVC com o menor parâmetro de dependency_ID e/ou temporallevel,qualitylD.
As unidades de camada NAL agregadoras podem ser usadas para agruparunidades de camada NAL de codificação SVC pertencentes a um nível deredimensionamento que pode não ser sinalizado pelo cabeçalho de unidade de camadaNAL (por exemplo, as unidades de camada NAL de codificação SVC pertencentes a umaregião de interesse). A descrição de tal unidade de camada NAL agregadora pode ser feitacom a descrição de camada e com os grupos de mapas de unidade de camada NAL. Nestecaso, mais de uma unidade de camada NAL agregadora com a mesma informação deredimensionamento poderá ocorrer em uma amostra.
As unidades de camada NAL agregadoras podem levar a um númeroconstante de unidades de camada NAL para cada camada em cada AU. A fim de garantirum padrão constante, o seguinte poderá ocorrer. As unidades NALU de camada base decodificação AVC podem ser agrupadas em uma unidade de camada NAL agregadora(quando usada em um fluxo de codificação SVC). Neste caso, os parâmetrostemporal level, dependency lD, e quality_ID são definidos todos em 0. As unidadesNALU de camada base de codificação AVC podem ser referenciadas por uma camadaNAL extratora. Se, por algum motivo, nenhuma unidade NALU de uma camada emparticular existe nesta AU, unidades de camada NAL agregadora vazias poderão existirnesta posição.
Em termos de um Formato de Carga Útil de protocolo RTP para um Vídeode codificação SVC, uma Unidade de camada NAL de Informação de Redimensionamentode Conteúdo de Carga útil será, de modo geral, como segue. Uma unidade de camadaNAL de codificação SVC inclui um cabeçalho de um, dois ou três bytes e a cadeia debytes de carga útil. O cabeçalho indica o tipo da unidade de camada NAL, a presençapotencial de erros de bit ou violações de sintaxe na carga útil de unidade de camada NAL,informações relacionadas à relativa importância da unidade de camada NAL para oprocesso de decodificação, e (opcionalmente, quando o cabeçalho é de três bytes) asinformações de dependência de decodificação de camada redimensionável.
O cabeçalho de unidade de camada NAL serve também como um cabeçalhode carga útil deste formato de carga útil de protocolo RTP. A carga útil de uma unidadede camada NAL segue imediatamente. A sintaxe e a semântica do cabeçalho de unidade decamada NAL são especificadas em [SVC], mas as propriedades essenciais do cabeçalho deunidade de camada NAL são resumidas como se segue.
O primeiro byte do cabeçalho de unidade de camada NAL tem o seguinteformato:
<formula>formula see original document page 11</formula>
forbidden_zero_bit (F): 1 bit. A especificação de padrão H.264 declara umvalor de 1 como uma violação de sintaxe.
nal ref idc (NRI): 2 bits. Um valor de 00 indica que o conteúdo da unidadede camada NAL não é usado para reconstruir as imagens de referência para uma prediçãoentre imagens. Estas unidades de camada NAL podem ser descartadas sem arriscar aintegridade das imagens de referência na mesma camada. Valores superiores a 00 indicamque a decodificação da unidade de camada NAL é necessária a fim de manter a integridadedas imagens de referência. Para uma fatia ou unidade de camada NAL de divisão de dadosde fatia, um valor de NRI de 11 indica que a unidade de camada NAL contém dados deuma imagem chave, conforme especificado em [SVC].
Nota informativa: O conceito de uma imagem chave é introduzido nacodificação SVC, e não se deve supor que nenhuma imagem nos fluxos de bits compatívelcom as versões 2003 e 2005 do padrão H.264 siga esta regra.nal unit type (Type): 5 bits. Este componente especifica o tipo de carga útilde unidade de camada NAL. Previamente, os tipos de unidade de camada NAL 20 e 21(entre outros) são reservados para extensões futuras. A codificação SVC usa estes doistipos de unidade de camada NAL. Os mesmos indicam a presença de um byte mais útil deum ponto de vista de transporte.
+---------------------------+
I 0 I 1 I 2 I 3 I 4 I 5 I 6 I 7 I+-+-+-+-+-+-+-+-+-+-+-+| PRID | D | E |+----------------------------+simple_priority_id (PRID): 6 bits. Este componente especifica umidentificador de prioridade para a unidade de camada NAL. Quando extension_flag é iguala 0, simple_priority_id é usado para inferir os valores de dependencyid, temporal level,e quality level. Quando simple_priority_id não se encontra presente, infere-se que omesmo é igual a 0.
discardableflag(D): 1 bit. Um valor de 1 indica que o conteúdo da unidadede camada NAL (dependency id = currDependencyld) não é usado no processo dedecodificação das unidades de camada NAL com dependency id > currDependencyld.Estas unidades de camada NAL podem ser descartadas sem arriscar a integridade dascamadas redimensionáveis superiores corpo valores maiores de dependency_id.discardable flag igual a 0 indica que a codificação da unidade de camada NAL énecessária a fim de manter a integridade de camadas redimensionáveis superiores comvalores maiores de dependency id.extension_flag (Ε): 1 bit. Um valor de 1 indica que o terceiro byte docabeçalho de unidade de camada NAL se encontra presente. Quando o Ε-bit do segundo
byte é 1, o cabeçalho de unidade de camada NAL estende-se para um terceiro byte:
<formula>formula see original document page 13</formula>
temporal_level (TL): 3 bits. Este componente é usado para indicar oredimensionamento temporal ou taxa de quadros. Uma camada consistida de imagens deum valor temporal level menor tem uma taxa de quadros menor.
dependencyid (DID): 3 bits. Este componente é usado para indicar ahierarquia de dependência de codificação entre camadas. Em qualquer local temporal, umaimagem de um valor dependency id menor pode ser usada para uma predição entrecamadas para a codificação de uma imagem com valor dependency id maior.
Quality level (QL): 2 bits. Este componente é usado para indicar umahierarquia de camada de redimensionamento FGS. Em qualquer local temporal e com umvalor dependency_id idêntico, uma imagem redimensionamento FGS com valorquality levei igual a QL usa a imagem de redimensionamento FGS ou imagem dequalidade base (a imagem de não redimensionamento FGS quando QL-I = 0) com umvalor quality level igual a QL-I para uma predição entre camadas. Quando QL é maiorque 0, a unidade de camada NAL contém uma fatia de redimensionamento FGS ou parteda mesma.
Na presente modalidade, um novo tipo de unidade de camada NAL,referida como uma unidade de camada NAL de informação de redimensionamento deconteúdo de carga útil, é especificado. A unidade de camada NAL de PACSI, quandopresente, deve ser a primeira unidade de camada NAL em pacotes de agregação, e nãodeve estar presente em outros tipos de pacotes. A unidade de camada NAL de PACSIindica as características de redimensionamento comuns a todas as unidades de camadaNAL restantes na carga útil, tornando-se, então, mais fácil para os MANES decidirementre encaminhar ou descartar o pacote. Os remetentes podem criar unidades de camadaNAL de PACSI, e os receptores podem ignorar as mesmas.
O tipo de unidade de camada NAL para a unidade de camada NAL PACSI éselecionada entre estes valores não especificados na especificação de padrão H.264/AVC eno padrão RFC 3984. Sendo assim, os fluxos de codificação SVC tendo uma camada basede padrão H.264/AVC e incluindo unidades de camada NAL PACSI podem serprocessados com receptores de padrão RFC 3984 e decodificadores de padrãoH. 264/A VC.
Quando a primeira unidade de agregação de um pacote de agregação contémuma unidade de camada NAL PACSI, poderá haver pelo menos uma unidade de agregaçãoadicional presente no mesmo pacote. Os campos de cabeçalho de protocolo RTP sãodefinidos de acordo com as demais unidades de camada NAL do pacote de agregação.
Quando uma unidade de camada NAL PACSI é incluída em um pacote deagregação de múltiplos tempos, o número de ordem de decodificação para a unidade decamada NAL PACSI deve ser definido no sentido de indicar que a unidade de camadaNAL PACSI é a primeira unidade de camada NAL em ordem de decodificação entre asunidades de camada NAL, ou que a unidade de camada NAL PACSI tem um número deordem de decodificação idêntico ao da primeira unidade de camada NAL em ordem dedecodificação entre as restantes unidades de camada NAL do pacote de agregação.
A estrutura da unidade de camada NAL PACSI é especificada como sesegue.
<formula>formula see original document page 14</formula>
Os valores dos campos na unidade de camada NAL ACSI devem serdefinidos como se segue.
- o bit F deve ser definido em 1 quando o bit F de qualquer unidade decamada NAL restante na carga útil é igual a 1. De outra forma, o bit F deve ser definidoem 0;
- o campo NRI deve ser definido com o valor mais alto entre as demaisunidades de camada NAL da carga útil;
- o campo Tipo deve ser definido em 30;
- o campo PRID deve ser definido com o menor valor do campo de PRIDentre as demais unidades de camada NAL na carga útil. Se o campo de PRID não estiverpresente em uma das unidades de camada NAL restantes na carga útil, o campo de PRIDna unidade de camada NAL PACSI deve ser definido em 0;
- o bit D deve ser definido em 0 quando o bit D de qualquer unidade decamada NAL restante na carga útil for igual a 0. De outra forma, o bit D deve serdefinido em 1;
- o bit E deve ser definido em 1;
- o campo TL deve ser definido no valor mais baixo do campo TL entre asdemais unidades de camada NAL na carga útil;
- o campo DID deve ser definido no valor mais baixo do campo DID entreas demais unidades de camada NAL na carga útil;
- o campo QL deve ser definido no valor mais baixo do campo QL entre asdemais unidades de camada NAL na carga útil.
A unidade de camada NAL agregadora indireta da presente invençãopermite uma fácil identificação de dependências de redimensionamento dentro do fluxo debits, possibilitando, assim, uma rápida e eficiente manipulação do fluxo. A unidade decamada NAL agregadora indireta garante que a camada base dos fluxos possa ainda serprocessada com um decodificador de padrão H.264/AVC, com um analisador de formatode arquivo de codificação AVC, ou com um analisador de carga útil de padrãoH.264/AVC RTP.
No caso da decodificação, deve-se notar que o fluxo de bits a ser codificadopode ser recebido de um dispositivo remoto dentro de virtualmente qualquer tipo de rede.Além disso, o fluxo de bits pode ser recebido de um hardware ou software local. Deve-setambém entender que, embora o texto e exemplos contidos no presente documento possamdescrever especificamente um processo de codificação, uma pessoa versada na técnicaprontamente entenderá que os mesmos conceitos e princípios se aplicam igualmente a umprocesso de decodificação correspondente ou vice versa.A Figura 1 mostra um dispositivo eletrônico representativo 12 dentro doqual a presente invenção pode ser implementada, tanto em termos de codificação como emtermos de decodificação. Deve-se notar, no entanto, que a presente invenção não pretendeficar limitar a um tipo particular de dispositivo eletrônico 12. o dispositivo eletrônico 12da Figura 1 inclui um vídeo 32, um teclado 34, um microfone 36, um fone de ouvido 38,uma porta infravermelha 42, uma antena 44, um cartão inteligente 46 na forma de umUICC de acordo com uma modalidade da presente invenção, uma leitora de cartão 48, umcircuito de interface de rádio 52, um circuito de codec 54, uma controladora 56 e umamemória 58. Os circuitos e elementos individuais são todos de um tipo bem conhecido natécnica, por exemplo, da faixa Nokia de telefones móveis.
A Figura 2 mostra um sistema de comunicação de multimídia genérico parauso com a presente invenção, uma fonte de dados 100 provê um sinal de fonte em umformato digital compactado, digital não compactado, ou analógico, ou qualquercombinação destes formatos. Um codificador 110 codifica o sinal de fonte em um fluxo debits de mídia codificado. O codificador 110 pode ser capaz de codificar mais de um tipode mídia, como, por exemplo, áudio ou vídeo, ou mais de um codificador 110 pode serrequerido para codificar diferentes tipos de mídia do sinal de fonte. O codificador 110pode também obter uma entrada produzida sinteticamente, como, por exemplo, gráficos etexto, ou pode ser capaz de produzir fluxos de bits de mídia sintética. A seguir, apenas oprocessamento de um fluxo de bits de mídia codificado de um tipo de mídia é consideradono sentido de simplificar a descrição. Deve-se notar, no entanto, que os serviços dedifusão tipicamente em tempo real compreendem diversos fluxos (tipicamente pelo menosum áudio, vídeo ou fluxo de subtítulo de texto). Deve-se notar ainda que o sistema podeincluir muitos codificadores, mas, a seguir, apenas um codificador 110 é considerado nosentido de simplificar a descrição sem prejuízo da generalidade.
O fluxo de bits de mídia codificado é transferido para um armazenador 120.O armazenador 120 pode compreender qualquer tipo de memória de massa a fim dearmazenar o fluxo de bits de mídia codificado. O formato do fluxo de bits de mídiacodificado no armazenador 120 pode ser um formato de fluxo de bits autocontidoelementar, ou um ou mais fluxos de bits de mídia codificado pode ser encapsulado em umarquivo recipiente. Alguns sistemas operam "ao vivo", isto é omitem o fluxo de bits demídia codificado de armazenamento e transferência do codificador 110 diretamente para oremetente 130. O fluxo de bits de mídia codificado é em seguida transferido para oremetente 130, também referido como o servidor, em uma base de necessidade. O formatousado na transmissão pode ser um formato de fluxo de bits autocontido elementar, umformato de fluxo de pacotes, ou um ou mais fluxos de bits de mídia codificado pode serencapsulado em um arquivo recipiente. O codificador 110, o armazenador 120, e oservidor 130 podem residir no mesmo dispositivo físico ou podem ser incluídos emdispositivos separados. O codificador 110 e o servidor 130 podem operar com umconteúdo em tempo real ao vivo, em cujo caso o fluxo de bits de mídia codificado serátipicamente não armazenado de forma permanente, mas sim armazenado temporariamentepor pequenos períodos de tempo no codificador de conteúdo 110 e/ou no servidor 130 demodo a suavizar as variações no atraso de processamento, no atraso de transferência, ouno fluxo de bits de mídia codificado.
O servidor 130 envia o fluxo de bits de mídia codificado usando uma pilhade protocolos de comunicação. A pilha pode incluir, sem ficar limitado a, um Protocolode Transporte em Tempo Real (RTP), Protocolo de Datagrama de Usuário (UDP), eProtocolo da Internet (IP). Quando a pilha de protocolos de comunicação é orientada porpacotes, o servidor 130 encapsula o fluxo de bits de mídia codificado em pacotes. Porexemplo, quando o protocolo RTP é usado, o servidor 130 encapsula o fluxo de bits demídia codificado em pacotes de protocolo RTP de acordo com um formato de carga útil deprotocolo RTP. Tipicamente, cada tipo de mídia tem um formato de carga útil deprotocolo RTP dedicado. Deve-se, mais uma vez, notar que o sistema pode conter mais deum servidor 130, contudo, para fins de simplicidade, a descrição a seguir consideraapenas um servidor 130.
O servidor 130 pode ou não ser conectado a um dispositivo portal 140através de uma rede de comunicação. O dispositivo portal 140 pode realizar diferentestipos de funções, tais como a tradução de um fluxo de bits de pacotes de acordo com umapilha de protocolos de comunicação para outra pilha de protocolos de comunicação,intercalação ou bifurcação de fluxos de dados, e manipulação de fluxo de dados de acordocom as capacidades de enlace descendente e/ou do receptor, como, por exemplo, controlara taxa de bits do fluxo encaminhado de acordo com as condições de rede de enlacedescendente prevalecentes. Exemplos de dispositivos portal 140 incluem as unidades decontrole de conferência de multipontos (MCU), dispositivos portal entre uma vídeo-telefonia comutada por circuitos ou por pacotes, servidores de Aperte-para-falar pelocelular (PoC), encapsuladores de protocolo IP em sistemas portáteis de vídeo-difusãodigitais (DVB-H), ou aparelhos decodificadores que encaminham transmissões de difusãolocalmente para redes domésticas sem fio. Quando o protocolo RTP é usado, o dispositivoportal 140 é denominado um misturador de protocolo RTP e atua como uma extremidadede uma conexão de protocolo RTP.
O sistema inclui um ou mais receptores 150, tipicamente capazes dereceber, demodular, e desencapsular o sinal transmitido para um fluxo de bits de mídiacodificado. O fluxo de bits de mídia de codec é tipicamente processado ainda por umdecodificador 160, cuja saída é um ou mais fluxos de mídia não compactados. Finalmente,um sintetizador 170 pode reproduzir os fluxos de mídia não compactados com um alto-falante ou vídeo, por exemplo. O receptor 150, o decodificador 160, e o sintetizador 170podem residir no mesmo dispositivo físico ou podem ser incluídos em dispositivosseparados.
O redimensionamento em termos de taxa de bits, complexidade dedecodificação, ou de tamanho de imagem é uma propriedade desejável em ambientesheterogêneos ou suscetíveis a erros. Esta propriedade é desejável a fim de fazer frente alimitações, tais como limitações na taxa de bits, na resolução de vídeo, na saída de rede, ena força computacional de um dispositivo receptor.
O redimensionamento pode ser usado para melhorar a resiliência ao erro deum sistema de transmissor no qual uma codificação em camadas é combinada a umapriorização de transporte. O termo "priorização de transporte" refere-se a váriosmecanismos para prover diferentes quantidades de serviço em transporte, incluindo aproteção desigual de erros, a fim de prover diferentes canais tendo diferentes taxas de erro/ perda. Dependendo de sua natureza, os dados são atribuídos diferentemente. Porexemplo, a camada base pode ser liberada através de um canal com alto grau de proteçãoao erro, e as camadas de aperfeiçoamento podem ser transmitidas através de mais canaissuscetíveis a erros.
Nas aplicações de multimídia de multiponto e de difusão, as limitações nasaída de rede podem não estar previstas no momento da codificação. Sendo assim, umfluxo de bits redimensionável deve ser usado. A Figura 3 mostra uma disposição demultidifusão de protocolo IP na qual cada roteador pode usar o fluxo de bits de acordocom as suas capacidades. A Figura 3 mostra um servidor S que provê um fluxo de bitspara diversos clientes Cl a C3. Os fluxos de bits são roteados para os clientes pelosroteadores Rl a R3. Neste exemplo, o servidor provê um clipe que pode serredimensionado para pelo menos três taxas de bit, 120 kbit/s, 60 kbit/s e 28 kbit/s.
Se o cliente e o servidor estiverem conectados via uma conexão deunidifusão normal, o servidor poderá tentar ajustar a taxa de bit do clipe de multimídiatransmitido de acordo com a saída de canal temporária. Uma solução é usar um fluxo debits em camadas e adaptar as mudanças de largura de banda variando o número decamadas de aperfeiçoamento transmitidas.
A presente invenção é descrita no contexto geral de etapas de método, quepodem ser implementadas em uma modalidade por um produto de programa que incluiinstruções executáveis em computador, tais como um código de programa executado emambientes de rede. De modo geral, os módulos de programa incluem rotinas, programas,objetos, componentes, estruturas de dados, etc., que realizam tarefas particulares ouimplementam tipos de dados abstratos particulares. As instruções executáveis emcomputador, estruturas de dados associadas, e módulos de programa representamexemplos de código de programa para a execução de etapas dos métodos apresentadosneste doe. A seqüência particular de tais instruções executáveis ou de estruturas de dadosassociadas representa exemplos de atos correspondentes para a implementação das funçõesdescritas em tais etapas.
As implementações de software e da web da presente invenção podem serobtidas com técnicas de programação padrão que norteiam a lógica baseada ou outralógica a fim de realizar as várias etapas de pesquisa de banco de dados, etapas decorrelação, etapas de comparação e etapas de decisão. Deve-se notar ainda que as palavras"componente" e "módulo", conforme aqui usadas e nas reivindicações, pretendemabranger implementações que usam uma ou mas linhas de código de software, e/ouimplementações de hardware, e/ou equipamento para o recebimento de entradas manuais.
A descrição acima de modalidades da presente invenção é apresentada parafins de ilustração e descrição. A mesma não pretende ser exaustiva ou limitar a presenteinvenção a precisa forma apresentada, sendo possíveis modificações e variações à luz dosensinamentos acima, ou sendo estas possíveis a partir da prática da presente invenção, asmodalidades foram escolhidas e descritas a fim de explicar os princípios da presenteinvenção e sua aplicação prática de modo a permitir que uma pessoa versada na técnicautilize a presente invenção em várias modalidades e com várias modificações conformeadequadas ao uso particular contemplado.