PT2868103T

PT2868103T - Conceito de fluxo de dados de vídeo

Info

Publication number: PT2868103T
Application number: PT137352415T
Authority: PT
Inventors: Schierl Thomas; George Valeri; Henkel Anastasia; Marpe Detlev; Grüneberg Karsten; Skupin Robert
Original assignee: Ge Video Compression Llc
Priority date: 2012-06-29
Filing date: 2013-07-01
Publication date: 2017-03-02
Also published as: JP2020065292A; IL305350B1; CN115442624A; TWI769904B; TW202201961A; WO2014001573A1; US20150208095A1; CN115442626A; EP3905697A1; US11025958B2; TWI584637B; IL299951A; IL277485A; RU2720534C2; KR101858200B1; MX2014016063A; JP2017118564A; JP7021167B2; CN115442623A; TW202007152A

Description

DESCRIÇÃO

CONCEITO DE FLUXO DE DADOS DE VÍDEO

Este pedido diz respeito a conceitos de fluxo de dados de video que são em especial vantajosos em conjugação com aplicações de pouco atraso. A HEVC [2] permite diferentes meios de sinalização de Sintaxe de Nivel Elevado ao nivel de aplicação. Tais meios são o cabeçalho da unidade NAL, Conjuntos de Parâmetros e Mensagens de Melhoria de Informação Suplementar (SEI). Estas últimas não são utilizadas no processo de descodificação. Outros meios de sinalização de Sintaxe de Nivel elevado são originados das respetivas especificações do protocolo de transporte tais como o Protocolo de Transporte MPEG2 [3] ou o Protocolo de Transporte em tempo Real [4], e as suas especificações de carga útil especificas, por exemplo as recomendações para H.264/AVC [5], codificação de video escalável (SVC) ou HEVC [7] . Esses protocolos de transporte podem introduzir um Nivel Elevado de sinalização que emprega estruturas e mecanismo semelhantes como a sinalização de Nivel Elevado do respetivo nivel de aplicação coded spec, por exemplo, HEVC [2]. Um exemplo de tal sinalização é a unidade de Informação de Escalabilidade de Conteúdo De carga útil (PACSI) NAL tal como descrito em [6] que proporciona informação suplementar para o nivel de transporte.

Para conjuntos de parâmetros, HEVC inclui o Conjunto de

Parâmetros de Video (VPS), que compila a maior parte das informações importantes de fluxo a ser utilizada pelo nivel de aplicação num local único e central. Em abordagens anteriores, esta informação precisaria ser recolhida a partir de vários Conjuntos de Parâmetros e cabeçalhos de unidades NAL.

Antes deste pedido, o estado da norma relativa às operações de Buffer da Imagem Codificada (CPB) do Descodificador de Referência Hipotético (HRD), e de toda a sintaxe associada existente no Conjunto de Sequência de Parâmetros (SPS)/Informação de Utilização de Video (VUI), Tempo da Imagem SEI, Período de Buffering SEI assim como a definição da unidade de descodificação, descrevendo uma subimagem e a sintaxe dos Segmentos Dependentes presentes no cabeçalho do segmento assim como o conjunto de Parâmetros da imagem (PPS), foi o seguinte.

De modo a permitir a operação CPB de baixo atraso no nivel da subimagem, as operações CPB subimagem foram propostas e integradas no projeto da norma HEVC 7 JCTVC-I1003 [2] . Aqui em especial, a unidade de descodificação foi definida na secção 3 de [2] da seguinte forma:

Unidade de descodificação: Uma unidade de acesso ou um subconjunto de uma unidade de acesso. Se SubPicCpbFlag é igual a 0, uma unidade de descodificação é uma unidade de acesso. Caso contrário, uma unidade de descodificação é composta por uma ou mais unidades VCL NAL numa unidade de acesso e as unidades NAL não-VCL associadas. Para a primeira unidade NAL VCL numa unidade de acesso, as unidades NAL não-VCL associadas e as unidades NAL

dos dados de preenchimento, caso existam, são imediatamente seguidas pela primeira unidade NAL VCL e todas as unidades NAL não-VCL na unidade de acesso que precede a primeira unidade NAL

VCL. Para uma unidade NAL VCL que não é a primeira unidade NAL VCL numa unidade de acesso, as unidades NAL não-VCL associadas são a unidade NAL de preenchimento de dados, caso exista, imediatamente seguida pela unidade NAL VCL.

Na norma definida até essa altura, o "Tempo de descodificação da remoção da unidade e a descodificação da unidade descodificada" foi descrito e adicionado ao Anexo C " Descodificador de

Referência hipotética em descodificador". De modo a sinalizar o tempo de subimagem, a mensagem do período de buffering SEI e a mensagem do tempo da imagem SEI, assim como os parâmetros HRD no VUI foram alargadas a fim de prestar suporte às unidades de descodificação, como unidades de subimagem. A sintaxe de mensagens do período de buffering SEI de [2] encontra-se ilustrada na Fig. 1.

Quando NalHrdBpPresentFlag ou VelHrdBpPresentFlag são iguais a 1, uma mensagem SEI do período de buffering pode ser associada a qualquer unidade de acesso no fluxo de bits, e uma mensagem SEI do período de buffering deverá ser associada a cada unidade de acesso RAP, e com cada unidade de acesso associada a uma mensagem SEI do ponto de pesquisa.

Para algumas aplicações, a presença frequente de uma mensagem SEI de um período de buffering pode ser desejável.

Um período de buffering foi especificado como o conjunto de unidades de acesso entre duas instâncias da mensagem SEI do período de buffering na sequência de descodificação. A semântica foi a seguinte: seq_parameter set id especifica o conjunto de sequência de parâmetros que contém os atributos de sequência HRD. 0 valor de seq parameter set_id deverá ser igual ao valor de seq parameter set id no conjunto de parâmetros de imagem através da primeira imagem codificada com a mensagem SEI do período de buffering. 0 valor de seq_parameter_set_id deverá estar na ordem dos 0 a 31, inclusive. rap_cpb_j?aramsj?resent_flag igual a 1 especifica a presença dos elementos de sintaxe initial_alt_cpb_removal_delay[ SchedSelldx ] e initial_alt_cpb_removal_delay_offset[

SchedSelIdx ] . Quando não se encontram presentes, o valor de rap cpb params_present_flag é considerado como igual a 0. Quando a imagem associada não é uma imagem CRA nem uma imagem BLA, o valor de rap_cpb_params_present_flag deverá ser igual a 0. initial_cpb_removal_delay[ SchedSelldx ] e initial_alt_cpb_removal_delay[ SchedSelldx ] especificam os atrasos de remoção CPB iniciais para o CPB SchedSelIdx-th. Os elementos de sintaxe são dotados de um comprimento em bits dado por initial_cpb_removal_length_minusl + 1, e encontram-se em unidades de um relógio de 90 kHz. Os valores dos elementos de sintaxe não deverão ser iguais a 0 e não deverão ultrapassar 90000 * / CpbSize[ SchedSelldx ] -r- BitRate [ SchedSelldx ] ), o equivalente a tempo da dimensão CPB em unidades de relógio de 90 kHz . initial_cpb_removal_delay_offset[ SchedSelldx ] e initial_alt__cpb_removal_delay_offset [ SchedSelldx ] são utilizados para CPB SchedSelldx-th para especificar o tempo de entrega inicial das unidades de dados codificadas para o CPB. Os elementos de sintaxe são dotados de um comprimento em bits dados por initial_cpb_removal_delay_length_minusl + 1 e são em unidades de um relógio de 90 kHz. Estes elementos de sintaxe não são utilizados por descodificadores e podem ser precisos apenas para o programador de entrega (HSS).

Por toda a sequência de vídeo codificada, a soma de initial_cpb_removal_delay [ SchedSelldx ] e initial_cpb_removal_delay_offset[ SchedSelldx ] deverá ser constante para cada valor de SchedSelldx, e a soma de initial cpb_removal_delay [ SchedSelldx ] e initial cpb removal_delay offset [ SchedSelldx ] deverá ser constante para cada valor de SchedSelldx. A sintaxe da mensagem SEI da instância da imagem de [2] encontra-se ilustrada na Fig. 2. A sintaxe da mensagem SEI do tempo da imagem estava dependente do conteúdo do conjunto de sequência de parâmetros que se encontrava ativo para a imagem codificada associada à mensagem SEI do tempo da imagem. Contudo, a menos que a mensagem SEI do tempo da imagem de uma unidade de acesso IDR ou BLA seja precedida por uma mensagem SEI do período de buffering na mesma unidade de acesso, a ativação do conjunto de sequência de parâmetros associado (e, para imagens IDR ou BLA que não são a primeira imagem no fluxo de bits, a determinação de que a imagem codificada é uma imagem IDR ou uma imagem BLA) não ocorre até à descodificação da primeira unidade NAL do segmento codificado da imagem codificada. Visto que a unidade NAL do segmento codificado da imagem codificada segue a mensagem SEI da instância da imagem na sequência de unidade NAL, poderão existir casos em que é necessário que um descodificador guarde a RBSP contendo a mensagem SEI da instância da imagem até determinar os parâmetros do parâmetro de sequência que estará ativo para a imagem codificada, e depois executar a análise da mensagem SEI da instância da imagem. A presença da mensagem SEI da instância da imagem no fluxo de bits foi especificada como segue: - Se CpbDpbDelaysPresentFlag é igual a 1, uma mensagem SEI da instância da imagem deverá estar presente em todas as unidades de acesso da sequência de vídeo codificada. - Caso contrário (CpbDpbDelaysPresentFlag é igual a 0) , nenhuma mensagem SEI da instância da imagem deverá estar presente em todas as unidades de acesso da sequência de vídeo codificada. A semântica foi definida do seguinte modo: cpb_removal_delay especifica quantos tiques do relógio de espera após remoção do CPB da unidade de acesso associada à mais recente mensagem SEI da instância da imagem com a mensagem SEI do período de utilização da memória mais recente numa unidade de acesso anterior antes da remoção do registo dos dados da unidade de acesso associados à mensagem SEI da instância da imagem. Este valor é também utilizado para calcular um tempo de chegada mais cedo possível dos dados da unidade de acesso no CPB para o HSS. 0 elemento de sintaxe é um código de comprimento fixo cujo comprimento em bits é dado por cpb_removal_delay_minusl + 1. 0 cpb removal_delay é o restante de um contador de módulo 2 (cpb_removal_delay_minusl + 1) 0 valor de cpb_removal_delay_minusl que determina o comprimento (em bits) do elemento de sintaxe cpb_removal_delay é o valor de cpb removal_delay_minusl codificado no conjunto de sequência de parâmetros que se encontra ativo para a primeira imagem codificada associada à mensagem SEI da instância da imagem, apesar de o cpb_removal_delay especificar um número de tiques de relógio relativos ao tempo de remoção da unidade de acesso anterior contendo uma mensagem SEI da instância da imagem, que pode ser uma unidade de acesso de uma diferente sequência de vídeo codificada. dpb_output-delay é utilizado para calcular o tempo de saída DPB da imagem. Especifica quantos tiques de relógio de espera após remoção da última unidade de descodificação numa unidade de acesso do CPB antes da imagem descodificada ter saído do DPB.

Uma imagem não é removida do DPB no seu tempo de saída quando ainda se encontra marcada como "utilizada para referência a curto prazo" ou "utilizada para referência a longo prazo".

Apenas dpb_output_delay é especificada para uma imagem descodificada. 0 comprimento do elemento de sintaxe dpb_output_delay é dado em bits por dpb_output_delay_length_minusl + 1. Quando sps_max dec_pic_buffering[ max_temporal_layers_minusl] é igual a 0, dpb output_delay deverá ser igual a 0. O tempo de saida derivado de dpb_output_delay de qualquer imagem saida de um descodificador conforme da instância de saida deverá preceder o tempo de saida derivado de dpb-output_delay de todas as imagens em qualquer sequência de video codificado posteriormente em sequência de descodificação. A ordem de saida da imagem estabelecida pelos valores deste elemento de sintaxe deverá ser a mesma ordem estabelecida pelos valores de PicOrderCntVal.

Para imagens que não saem pelo processo "bumping" pois precedem, em sequência de descodificação, uma imagem IDR ou BLA com no output of prior pics flag igual a 1 ou considerado como ser igual a 1, os tempos de saída derivados de dpb_output_delay deverão ser aumentados com valor crescente de PicOrderCntVal relativos a todas as imagens na mesma sequência de vídeo codificada. num_decoding_units_minusl mais 1 especifica o número de unidades de descodificação na unidade de acesso à qual a mensagem SEI do tempo de imagem está associada. O valor de num_decoding_units_minusl deverá ser da ordem de 0 a PicWidthlnCtbs * PicHeightInCtbs - 1, inclusive. num_nalus_in_du_niinusl [i] mais 1 especifica o número de unidades NAL na unidade de descodificação i-ésima da unidade de acesso à qual a mensagem SEI do tempo de imagem está associada. 0 valor de num_nalus_in_du_minusl[i] deverá ser da ordem de 0 a PicWidthlnCtbs * PicHeightInCtbs - 1, inclusive. A primeira unidade de descodificação da unidade de acesso é constituída pelas primeiras unidades NAL consecutivas num_nalus_in_du_minusl[0] + 1 na sequência de descodificação na unidade de acesso. A unidade de descodificação i-ésima (com i superior a 0) da unidade de acesso é constituída pelas unidades NAL consecutivas num_nalus_in_du_minusl[i] + 1 imediatamente seguidas pela última unidade NAL na unidade de descodificação anterior da unidade de acesso, na sequência de descodificação. Deverá existir pelo menos uma unidade NAL VCL em cada unidade de descodificação. Todas as unidades NAL não-VCL associadas a uma unidade NAL VCL deverão ser incluídas na mesma unidade de descodificação. du_cpb_removal_delay[ i ] especifica quantos tiques de relógio de subimagem se deverá esperar após a remoção do CPB da primeira unidade de descodificação associada à mais recente mensagem SEI do período de buffering numa unidade de acesso anterior antes da remoção do CPB da unidade de descodificação i-ésima na unidade de acesso associada à mensagem SEI da instância de imagem. Este valor é também utilizado para calcular o mais cedo possível um tempo de chegada dos dados da unidade de descodificação no CPB para o HSS. O elemento de sintaxe é um código de comprimento fixo cujo comprimento em bits é dado por cpb_removal_delay_length_minusl +1.0 du_cpb_removal_delay[ i ] é O restante de um contador do módulo 2 <cPb_removal_delay_length_minusl + 1) 0 valor de cpb_removal_delay_length_minusl + 1 que determina o comprimento (em bits) do elemento de sintaxe du_cpb_removal_delay[ i ] é o valor do cpb removal_delay_length_minusl codificado no conjunto de sequência de parâmetros que se encontra ativo para a imagem codificada associada à mensagem SEI da instância de imagem, apesar de du_cpb_removal_delay[ i ] especificar um número de tiques de relógio subimagem relativos ao tempo de remoção da primeira unidade de descodificação na unidade de acesso anterior contendo uma mensagem SEI do período de buffering, que pode ser uma unidade de acesso de uma diferente sequência de vídeo codificada.

Alguma informação estava contida na sintaxe VUI de [2]. A sintaxe de parâmetros VUI de [2] encontra-se ilustrada na Fig. 3. A sintaxe de parâmetros HRD de [2] encontra-se ilustrada na Fig. 4. A semântica foi definida do seguinte modo: sub_pic epb__params_present_flag igual a 1 especifica que os parâmetros de atraso da remoção do nível subimagem CPB encontram-se presentes e o CPB pode funcionar ao nível da unidade de acesso ou nível subimagem. sub_pic_epb_params_present_flag igual a 0 especifica que os parâmetros de atraso da remoção do nível subimagem CPB não se encontram presentes e o CPB funciona ao nível da unidade de acesso. Quando sub_pic_epb_params_present_flag não se encontra presente, o seu valor é inferido como sendo igual a 0. num_units_in_sub_tick é o número de unidades de tempo de funcionamento de um relógio na escala de tempo de frequência Hz que corresponde a um incremento (designado um tique de um relógio subimagem) de um contador de tiques de relógio da subimagem. num_units_in_sub_tick deverá ser superior a 0. Um tique de relógio de subimagem é o intervalo mínimo de tempo que pode ser representado nos dados codificados quando sub_pic_cpb_params_present_flag é igual a 1. tiles_fixed_structure_flag igual a 1 indica que cada conjunto de parâmetros de imagem que se encontram ativos na sequência de vídeo codificada tem o mesmo valor dos elementos de sintaxe num_tile_columns_minusl, num_tile_rows_minusl, uniform_spacing_flag, column_width[ i ], row_height [ i ] e loop across_tiles_enabled_flag, quando presente, tiles fixed_structure_flag igual a 0 indica que os elementos de sintaxe dos mosaicos em diferentes conjuntos de parâmetros de imagens podem ter ou não o mesmo valor. Quando o elemento de sintaxe tiles_fixed_structure_flag não se encontra presente, é inferido como sendo igual a 0. A sinalização de tiles_fixed_structure_flag igual a 1 é uma garantia para um descodificador de que cada imagem na sequência de vídeo codificada tem o mesmo número de mosaicos distribuídos da mesma maneira que poderão ser úteis para atribuição de carga de trabalho no caso de descodificação multi-threaded.

Dados de preenchimento de [2] foi assinalado utilizando sintaxe de dados de preenchimento RBSP ilustrada na Fig. 5. 0 descodificador hipotético de referência de [2] utilizado para verificar o fluxo de bits e a conformidade do descodificador foi definido do seguinte modo:

Dois tipos de fluxo de bits são sujeitos a verificação de conformidade HRD para esta Recomendação |Norma Internacional. 0 primeiro tipo de fluxo de bits, designado fluxo de dados do Tipo I, é um fluxo da unidade NAL contendo apenas as unidades NAL VCL e unidades NAL dos dados de preenchimento para todas as unidades de acesso no fluxo de bits. 0 segundo tipo de fluxo de bits, designado fluxo de bits Tipo II, contém, para além das unidades NAL VCL e unidades NAL dos dados de preenchimento para todas as unidades de acesso no fluxo de bits, pelo menos uma das seguintes: unidades NAL não-VCL que não unidades NAL de dados de preenchimento, - todos os elementos de sintaxe leading_zero_8bits, zero_byte, start_code_prefix_one_3bytes, e trailing_zero_8bits que formam um fluxo de bits proveniente do fluxo da unidade NAL. A Fig. 6 ilustra os tipos pontos de conformidade do fluxo de bits verificado pelo HRD de [2].

São utilizados dois tipos de conjuntos de parâmetros HRD (parâmetros HRD NAL e parâmetros HRD VCL) . Os conjuntos de parâmetros HRD são assinalados através da informação de utilização, que é parte da estrutura de sintaxe do conjunto de sequência de parâmetros.

Todos os conjuntos de parâmetros de sequência e todos os conjuntos de parâmetros de imagens referidos nas unidades NAL VCL, e respetivos períodos de buffering e mensagens SEI da instância da imagem deverão ser transportado para o HRD, de modo temporal, seja no fluxo de bits ou por outro meio. A especificação para "presença" de unidades NAL não-VCL é também satisfeita quando as unidades NAL (ou apenas algumas delas) são transportadas para os descodificadores (ou para o HRD) através de outros meios não especifiçados por esta Recomendação | Norma Internacional. Com o objetivo da contagem de bits, apenas os bits apropriados que estão efetivamente presentes no fluxo de bits são contados.

Como um exemplo, a sincronização de uma unidade NAL não-VCL, transportada por outros meios que não a presença no fluxo de bits, com as unidades NAL que se encontram presentes no fluxo de bits, pode ser obtida através da indicação de dois pontos no fluxo de bits, entre os quais a unidade NAL não-VCL estaria presente no fluxo de bits, caso tivesse o codificador decidido transportá-la no fluxo de bits.

Quando o conteúdo de uma unidade NAL não-VCL é transportado para a aplicação através de alguns meios que não a presença no fluxo de bits, não é necessário que a representação do conteúdo da unidade NAL não-VCL utilize a mesma sintaxe que a especificada neste anexo.

De salientar que quando a informação HRD está contida no fluxo de bits, é possível verificar a conformidade de um fluxo de bits para os requisitos desta subcláusula com base apenas na informação contida no fluxo de bits. Quando a informação HRD não se encontra presente no fluxo de bits, tal como é o caso para todos os fluxos de bits "autónomo" do Tipo I, a conformidade pode ser apenas verificada quando os dados HRD são fornecidos por quaisquer outros meios que não os especificados nesta Recomendação | Norma Internacional. 0 HRD contém um buffer de Imagens Codificadas (CPB), um processo de descodificação instantânea, um buffer de imagens descodificadas (DPB) e recortes de saida tal como ilustrado na Fig. 7.

As dimensões CPB (número de bits) é CpbSize[ SchedSelIdx ]. As dimensões de DPB (número de registo de armazenamento de imagens) para o nivel temporal X são sps_dec_pic_buffering[ X ] para cada X na ordem de 0 a sps max temporal layers minusl, inclusive. A variável SubPicCpbPreferredFlag é especificada por meios externos, ou quando não especificada por meios externos fixada em 0. A variável SubPicCpbPreferredFlag deriva do seguinte modo: SubPicCpbFlag=SubPicCpbPreferredFlag&&sub_pic_cpb_params_present _f lag

Se SubPicCpbFlag for igual a 0, o CPB funciona ao nivel da unidade de acesso e cada unidade de descodificação é uma unidade de acesso. Caso contrário, o CPB funciona ao nivel da subimagem e cada unidade de descodificação é um subconjunto de uma unidade de acesso. 0 HRD funciona do seguinte modo. Os dados associados às unidades de descodificação que fluem para o CPB de acordo com um programa de chegada especificado são entregues pelo HSS. Os dados associados a cada unidade de descodificação são removidos e descodificados instantaneamente pelo processo de descodificação instantânea nos tempos de remoção CPB. Cada imagem descodificada é colocada no DPB. Uma imagem descodificada no máximo é removida do DPB no tempo de saída DPB ou alternativamente no tempo em que já não seja necessária para referência inter-predição. 0 HRD é inicializado tal como especificado pelo período de buffering SEI. 0 tempo de remoção das unidades de descodificação do CPB e tempo de saída de imagens descodificadas provenientes do DPB são especificados na mensagem SEI da instância de imagens. Toda a informação da instância relativa a uma unidade de descodificação específica deverá chegar antes do tempo de remoção CPB da unidade de descodificação. 0 HRD é utilizado para verificar a conformidade dos fluxos de bits e descodificadores.

Enquanto a conformidade é garantida sob o pressuposto de todas as taxas de frames e relógios utilizados para originar uma correspondência exata de fluxos de bits aos valores assinalados no fluxo de bits, num sistema real cada um destes pode variar do valor assinalado ou especificado.

Toda a aritmética é feita com valores reais, de modo a que nenhum erro de arredondamento se possa propagar. Por exemplo, o número de bits num CPB mesmo antes de ou após a remoção de uma unidade de descodificação não é necessariamente um número inteiro. A variável tc deriva do seguinte modo e é designada um tique de relógio: tc = num_units_in_tick a time_scale A variável tc deriva do seguinte modo e é designada um tique de relógio subimagem: tc sub = num_units_in_sub_tick a time_scale 0 seguinte é especificado para expressar os constrangimentos: - Deixar a unidade de acesso n ser a unidade de acesso n-ésima na sequência de descodificação com a primeira unidade de acesso a ser a unidade de acesso 0.

Deixar a imagem n ser a imagem codificada ou a imagem descodificada da unidade de acesso n.

Deixar a unidade de descodificação m ser a unidade de descodificação m-ésima na sequência de descodificação com a primeira unidade de descodificação a ser a unidade de descodificação 0.

Em [2], a sintaxe do cabeçalho de segmento permitiu os designados segmentos dependentes. A Fig. 8 ilustra a sintaxe do cabeçalho do segmento de [2]. A semântica do cabeçalho do segmento foi definida do seguinte modo: dependent_slice_flag igual a 1 especifica que o valor de cada elemento de sintaxe do cabeçalho do segmento não presente é considerado como sendo igual ao valor do elemento de sintaxe do cabeçalho do segmento correspondente no segmento anterior contendo o bloco de árvore de codificação para o qual o endereço bloco de árvore de codificação é SliceCtbAddrRS - 1. Quando não estiver presente, o valor de dependent_slice_flag é considerado como sendo igual a 0. 0 valor de dependent_slice_flag deverá ser igual a 0 quando SliceCtbAddrRS é igual a 0. slice_address especifica o endereço na resolução de granularidade do segmento no qual o segmento tem inicio. O comprimento do elemento de sintaxe slice_address é ( Ceil ( Log2 ( PicWidthlnCtbs * PicHeightlnCtbs ) ) + SliceGranularity ) bits. A variável SliceCtbAddrRS, especificando o bloco de árvore de codificação no qual o segmento tem inicio na análise por varrimento do bloco de árvore de codificação, deriva do seguinte modo:

SliceCtbAddrRS = ( slice_address >> SliceGranularity ) A variável SliceCbAddrZS, que especifica o endereço do primeiro bloco de codificação no segmento na granularidade minima do bloco de codificação na sequência z-scan, deriva do seguinte modo:

SliceCbAddrZS = slice_address « ( ( log2_diff_max_min_coding_block_size - SliceGranularity ) «1 ) A descodificação do segmento inicia com a maior unidade de codificação possível na coordenada de início do segmento. first_slice_in_pic_flag indica se o segmento é o primeiro segmento da imagem. Se first_slice_in_pic_flag for igual a 1, as variáveis SliceCbAddrZS e SliceCtbAddrRS são ambas fixadas em 0 e a descodificação tem inicio com o primeiro bloco de árvore de codificação na imagem. pic_parameter_set_id especifica o conjunto de parâmetros de imagem em utilização. 0 valor do pic_parameter_set_id deverá ser da ordem dos 0 a 255, inclusive. num_entry_point_offsets especifica o número de elementos de sintaxe entry point offset[i] no cabeçalho do segmento. Quando tiles or entropy coding sync_idc é igual a 1, o valor de num_entry_point_offsets deverá ser da ordem de 0 a ( num_tile_columns_minusl + 1 ) * ( num_tile_rows_minusl + 1) - 1, inclusive. Quando tiles_or_entropy_coding_sync_idc é igual a 2, o valor de num_entry_point_offsets deverá ser da ordem de 0 a PicHeightInCtbs - 1, inclusive. Quando não se encontra presente, o valor de num entry point_offsets é considerado como sendo igual a 0 . offset_len_minusl especifica o comprimento, em bits, dos elementos de sintaxe entry_point_offset[ i ]. entry_point_offset[ i ] especifica o i-ésimo ponto de entrada do valor, em bytes, e deverá ser representado por offset_len_minusl mais 1 bits. Os dados do segmento codificados após o cabeçalho do segmento consistem em subconjuntos num_entry_point_offsets + 1, com valores de índice do subconjunto desde 0 a num_entry_point_offsets, inclusive. 0 subconjunto 0 consiste em 0 bytes a entry_point_offset[0] - 1, inclusive, dos dados do segmento codificados, subconjunto k, com k na ordem de 1 a num entry_point_pffsets - 1, inclusive, consiste em bytes entry_point_offset[ k - 1 ] a entry_point_offset[ k ] + entrey_point_offset [ k - 1 ] - 1, inclusive, dos dados do segmento codificados, e o último subconjunto (com o índice do subconjunto igual a num_entry_point_offsets) consiste dos restantes bytes dos dados do segmento codificado.

Quando tiles_or_entropy_coding_sync_idc é igual ale num entry point_offsets é superior a 0, cada subconjunto deverá conter todos os bits codificados para exatamente um mosaico, e o número de subconjuntos (isto é, o valor de num_entry_point_offsets + 1) deverá ser igual a ou inferior ao número de mosaicos no segmento.

Quando tiles_or_entropy_coding_sunc_idc é igual a 1, cada segmento deverá incluir um subconjunto de um mosaico (sendo que neste caso a sinalização de pontos de entrada é desnecessária) ou um número inteiro de mosaicos completos.

Quando tiles_or_entropy_coding_sunc_idc é igual a 2 e num entry point_offsets é superior a 0, cada subconjunto k com k na ordem dos 0 a num_entry_point_offsets - 1, inclusive, deverá conter todos os bits codificados de exatamente uma linha de blocos de árvore de codificação, o último subconjunto (com índice de subconjunto igual a num_entry_point_offsets) deverá conter todos os bits codificados dos restantes blocos de codificação incluídos no segmento, em que os restantes blocos de codificação consistem em exatamente uma linha de blocos de árvore de codificação ou um subconjunto de uma linha de blocos de árvore de codificação, e o número de subconjuntos (isto é, o valor de num_entry_point_offsets +1 ) deverá ser igual ao número de linhas de blocos de árvore de codificação no segmento, em gue um subconjunto de uma linha de blocos de árvore de codificação no segmento é também contado.

Quando tiles_or_entropy_coding_sunc_idc é igual a 2, um segmento pode incluir um número de linhas de blocos de árvore de codificação e um subconjunto de uma linha de blocos de árvore de codificação. Por exemplo, se um segmento inclui duas linhas e meia de blocos de árvores de codificação, o número de subconjuntos (isto é, o valor de num_entry_point_offsets +1) deverá ser igual a 3. A Fig. 9 ilustra a sintaxe do conjunto de parâmetros de imagem RBSP de [2], em que a semântica RBSP do conjunto de parâmetros de imagem de [2] é definida como: dependent_slice_enabled_flag igual a 1 especifica a presença do elemento de sintaxe dependent_slice_flag no cabeçalho do segmento para imagens de codificação referentes ao conjunto de parâmetros da imagem. dependent_slice_enabled_flag igual a 0 especifica a ausência do elemento de sintaxe dependent_slice_flag no cabeçalho do segmento para imagens codificadas referentes ao conjunto de parâmetros da imagem. Quando tiles_or_entropy_coding_sync_idc é igual a 3, o valor de dependent_slice_enabled_flag deverá ser igual a 1. tiles_or_entropy_coding_sync_idc igual a 0 especifica que deverá existir apenas um mosaico em cada imagem em referência ao conjunto de parâmetros da imagem, que não deverá existir processo de sincronização especifica para variáveis de contexto antes da descodificação do primeiro bloco de árvore de descodificação de uma linha de blocos de árvore de codificação em cada imagem em referência ao conjunto de parâmetros de imagem, e que os valores de cabac_independent_flag e dependent_slice_flag para imagens codificadas referentes ao conjunto de parâmetros de imagem não deverão ser ambos iguais a 1.

Quando cabac_independent_flag e dependent_slice_flag são ambos iguais a 1 para um segmento, o segmento é uma entropy slice. tiles or_entropy_coding_sync_idc igual a 1 especifica que poderão existir mais do que um mosaico em cada imagem referente ao conjunto de parâmetros de imagem, que poderá não existir processo de sincronização especifica para variáveis de contexto invocados antes da descodificação do primeiro bloco de árvore de codificação de uma linha de blocos de árvores de codificação em cada imagem referente ao conjunto de parâmetros de imagem, e que os valores do cabac_independent_flag e dependent_slice_flag para imagens codificadas referentes ao conjunto de parâmetros de imagem não deverão ser ambos iguais a 1. tiles or entropy_coding_sync_idc igual a 2 especifica que poderá existir apenas um mosaico em cada imagem referente ao conjunto de parâmetros de imagem, que um processo de sincronização especifica para variáveis de contexto deverá ser invocado antes da descodificação do primeiro bloco de árvore de codificação de uma linha de bloco de árvore de codificação em cada imagem referente ao conjunto de parâmetros de imagem e que um processo de memorização especifico para variáveis de contexto deverá ser invocado após descodificação de dois blocos de árvore de uma linha de blocos de árvore de codificação em cada imagem referente ao conjunto de parâmetros de imagem, e os valores de cabac_independent_flag e dependent_slice_flag para imagens codificadas referentes ao conjunto de parâmetros de imagem não deverão ser ambos iguais a 1. tiles_or_entropy_coding sync ide igual a 3 especifica que poderá existir apenas um mosaico em cada imagem referente ao conjunto de parâmetros de imagem, que não deverá existir processo de sincronização especifica para variáveis de contexto invocadas antes da descodificação do primeiro bloco de árvore de codificação de uma linha dos blocos de árvore de codificação em cada imagem referente ao conjunto de parâmetros de imagem, e que os valores de cabac_independent_flag e dependent_slice_flag para imagens codificadas referentes ao conjunto de parâmetros de imagem podem ambos ser iguais a 1.

Quando dependent_slice_enabled_flag deverá ser igual a 0, tiles_or_entropy_coding_sync_idc não deverá ser igual a 3. Trata-se de um requisito de conformidade de fluxo de bits que o valor tiles_or_entropy_coding_sync_idc deverá ser o mesmo para todos os conjuntos de parâmetros de imagens ativados numa sequência de video codificada.

Para cada segmento referente ao conjunto de parâmetros de imagem, quando tiles_or_entropy_coding_sync_idc é igual a 2 e quando o primeiro bloco de codificação no segmento não é o primeiro bloco de codificação no primeiro bloco de árvore de codificação de uma linha de blocos de árvore de codificação, o último bloco de codificação no segmento deverá pertencer à mesma linha do bloco de árvore de codificação como o primeiro bloco de codificação no segmento. num_tile_coluirms_ininusl mais 1 especifica o número de colunas de mosaicos que dividem a imagem. num_tile_rows_minusl mais 1 especifica o número de linhas de mosaicos que dividem a imagem. Quando num_tile_columns_minusl é igual a 0, num_tile_rows_minusl não deverá ser igual a 0. uniform_spacing_flag igual a 1 especifica que as delimitações de coluna e do mesmo modo as delimitações de linha são distribuídas uniformemente pela imagem. uniform_spacing_flag igual a 0 especifica que as delimitações da coluna e do mesmo modo as delimitações de linha não são distribuídas uniformemente pela imagem mas explicitamente assinaladas utilizando os elementos de sintaxe column_width[ i ] e row_height[ i ]. column_width[ i ] especifica a largura da i-ésima coluna do mosaico em unidades de blocos de árvore de codificação. row_height[ i ] especifica a altura da i-ésima linha do mosaico em unidades de blocos de árvore de codificação. O vetor colwidth[ i ] especifica a largura da i-ésima coluna do mosaico em unidades de CTBs com a coluna i desde 0 a num_tile_columns_minusl, inclusive. 0 vetor CtbAddrRStoTS [ ctbAddrRS ] especifica a conversação proveniente de um endereço CTB em análise por varrimento para um endereço CTB em análise por mosaico com o índice ctbAddrRS desde 0 a (picHeightlnCtbs * picWidthlnCtbs) - 1, inclusive. 0 vetor CtbAddrRStoTS[ ctbAddrRS ] especifica a conversação proveniente de um endereço CTB em análise por mosaico para um endereço CTB em análise por varrimento com o índice ctbAddrTS desde 0 a (picHeightlnCtbs * picWidthlnCtbs) - 1, inclusive. 0 vetor Tileld[ ctbAddrTS ] especifica a conversação proveniente de um endereço CTB em análise por mosaico para uma identificação de mosaico com ctbSddrTS desde 0 a (picHeightlnCtbs * picWidthlnCtbs) - 1, inclusive.

Os valores de colWidth, CtbAddrRStoTS, CtbAddrTStoRS e Tileld são derivados invocando o processo de conversação de mosaico e varrimento tal como especificado na subcláusula 6.5.1 com PicHeightlnCtbs e PicWidthlnCtbs como entradas sendo a saída é atribuída a colWidth, CtbAddrRStoTS e Tileld.

Os valores de ColumnWidthLumaSamples[ i ], especificando a largura do i-ésima coluna de mosaico em unidades de luma samples, são fixados iguais a colWidth[ i ] << Log2CtbSize. A série MinCbAddrZS[ X ] [ y ], especificando a conversação proveniente de uma localização ( x, y ) em unidades de mínimo CBs para um mínimo endereço CB em z-scan com x desde 0 a picWidthMinCbs - 1, inclusive, e y desde 0 a picHeightInMinCbs -1, inclusive, deriva através da invocação de um processo de inicialização da pluralidade de varrimento em Z como especificado na subcláusula 6.5.2 com Log2MinCbSize, Log2CtbSize, PicHeightlnCtbs, PicWidthlnCtbs, e o vetor CtbAddrRStoTS como entradas sendo a saída é atribuída a MinCbAddrZS. loop_filter_across_tiles_enabled_flag igual a 1 especifica que as operações de filtragem de retorno são executadas pelas delimitações de mosaico. loop_filter_across_tiles_enabled_flag igual a 0 especifica que as operações de filtragem de retorno não são executadas pelas delimitações do mosaico. As operações de filtragem de retorno incluem o filtro de desbloqueamento, deslocamento adaptável da amostra e operações de filtragem circular adaptável. Quando não presente, o valor do loop_filter_across_tiles_enabled_flag é considerado como sendo igual a 1. cabac_independent_flag igual a 1 especifica que a descodificação CABAC dos blocos de codificação num segmento está dependente de qualquer estado do segmento anteriormente descodificado. cabac_independent_flag igual a 0 especifica que a descodificação CABAC dos blocos de codificação num segmento está dependente dos estados do segmento anteriormente descodificado. Quando não presentes, o valor de cabac_independent_flag é considerado como sendo igual a 0.

Um processo de derivação para a disponibilidade de um bloco de codificação com um endereço do bloco de codificação mínima foi descrito do seguinte modo:

Entradas a este processo são: - um endereço do bloco de codificação mínima minCbAddrZS na ordem z-scan o endereço do bloco de codificação mínima atual currMinCBAddrZS na ordem z-scan A saída deste processo é a disponibilidade do bloco de codificação com endereço de bloco de codificação mínima cbAddrZS na ordem z-Scan cbAvailable.

De salientar que o significado de disponibilidade é determinado quando este processo é invocado.

De salientar que qualquer bloco de codificação, independentemente das suas dimensões, está associado ao endereço do bloco de codificação mínima, sendo o endereço do bloco de codificação com as dimensões do bloco de codificação mínima na ordem z-scan.

Se uma ou mais das condições seguintes forem verídicas, cbAvailable é fixada em FALSO. - minCbAddrZS é inferior a 0

- minCbAddrZS é superior a currMinCBAddrZS o bloco de codificação com endereço do bloco de codificação mínima minCbAddrZS pertence a um segmento diferente do bloco de codificação com o endereço do bloco de codificação mínima atual currMinCBAddrZS e o dependent_slice_flag do segmente contendo o bloco de codificação com o endereço do bloco de codificação mínima atual currMinCBAddrZS é igual a 0. - o bloco de codificação com o endereço do bloco de codificação mínima MinCbAddrZS consta num mosaico diferente do bloco de codificação com o endereço do bloco de codificação mínima atual currMinCBAddrZS. - De outro modo, cbAvailable é fixada em VERDADE. 0 processo de análise sintática CABAC para dados do segmento de [2] foi o seguinte:

Este processo é invocado aquando de elementos de sintaxe de análise sintática com descritor ae(v).

Entradas a este processo são um pedido para um valor de um elemento de sintaxe e valores de elementos de sintaxe analisados sintaticamente. A saída deste processo é o valor do elemento de sintaxe.

Quando se inicia a análise sintática dos dados de segmento de um segmento, o processo de inicialização do processo de análise sintática CABAC é invocado. 0 endereço do bloco de codificação mínima do bloco de árvore codificado contendo o bloco espacial vizinha T (Fig. 10a), ctbMinCbAddrT, é derivado utilizando a localização (xO, yO) da luma sample superior esquerda do bloco de árvore de codificação atual do seguinte modo.

ctbMinCbAddrT = MinCbAddrZS[ x >> Log2MinCbSize ] [ y >>

Log2MinCbSize ] A variável availableFlagT é obtida pela invocação do processo de derivação de disponibilidade do bloco de codificação com CtbMinCbAddrT como entrada.

Quando do início da análise sintática de uma árvore de codificação, aplicam-se as seguintes etapas ordenadas. 1.0 motor de descodificação de aritmética é inicializado do seguinte modo. - Se CtbAddrRS for igual a slice_address, dependent_slice_flag é igual ale entropy_coding_reset_flag é igual a 0, aplica-se o seguinte. - 0 processo de sincronização do processo de análise sintática CABAC é invocado com TableStateldxDS e TableMPSValDS como entrada. - 0 processo de descodificação para decisões binárias antes da conclusão é invocado, seguido pelo processo de inicialização para a descodificação aritmética. - Por outro lado, se tiles_or_entropy_coding_sync_idc for igual a 2, e CtbAddrRS % PicWidthlnctbs for igual a 0, aplica-se o seguinte.

Quando availableFlagT é igual a 1, o processo de sincronização do processo de análise sintática CABAC é invocado com TableStateldxWPP e TableMPSValWPP como entrada. - 0 processo de descodificação para decisões binárias antes da conclusão é invocado, seguido do processo de inicialização para o motor de descodificação de aritmética. 2.Quando cabac_independent_flag é igual a 0 e dependent_slice_flag é igual a 1, ou quando tiles_or_entropy_coding_sync_idc é igual a 2, o processo de memorização é aplicado do seguinte modo:

Quando tiles_or_entropy_coding_sync_idc é igual a 2 e CtbAddrRS % PicWidthlnCtbs é igual a 2, o processo de memorização do processo de análise sintática CABAC é invocado com TableStateldxWPP e TableMPSValWPP como saída.

Quando cabac_independent_flag é igual a 0, dependent_slice_flag é igual a 1, e end_of_slice flag é igual a 1, o processo de memorização do processo de análise sintática CABAC é invocado com TableStateldxDS e TableMPSValDS do seguinte modo. A análise sintática dos elementos de sintaxe prossegue do seguinte modo:

Para cada valor de um elemento de sintaxe solicitado uma apresentação de dados na forma binária é derivada. A apresentação de dados na forma binária para o elemento de sintaxe e a sequência dos bins analisados sintaticamente determina o fluxo do processo de descodificação.

Para cada bin da apresentação de dados na forma binária do elemento de sintaxe, que se encontra indexado pelo binldx variável, um índice de contexto ctxldx é derivado.

Para cada ctxldx o processo de descodificação aritmética é invocado. A sequência resultante (bo.. bbinidx) dos bins analisados sintaticamente é comparada com a fixação das cadeias de bins dados pelo processo de apresentação de dados em forma binária após a descodificação de cada bin. Quando a sequência corresponde a uma cadeia de bins no dado conjunto, o valor correspondente é atribuído ao elemento de sintaxe.

Caso o pedido para um valor de um elemento de sintaxe é processado para o elemento de sintaxe pcm_flag e o valor descodificado de pcm_flag for igual a 1, o motor de descodificação é inicializado após a descodificação de qualquer pcm alignment_zero_bit, num_subsequent_pcm, e todos os dados pcm_sample_luma e pcm_sample_chroma.

Dentro dos parâmetros de conceção até agora descrito ocorreu o seguinte problema. 0 momento das unidades de descodificação precisa ser conhecido antes da codificação e envio dos dados num cenário de baixo atraso, em que as unidades NAL terão já sido enviadas pelo codificador, enquanto o codificador ainda está a codificar partes da imagem, isto é, outras unidades de descodificação de subimagem. Isto é, devido à sequência da unidade NAL numa unidade de acesso permite apenas que mensagens SEI antecedam as VCL (unidades NAL de Codificação de Vídeo) numa unidade de acesso, mas nesse cenário de baixo atraso, as unidades NAL não-VCL precisam de estar já na ligação, ou seja, enviadas, se o codificador iniciar a codificação das unidades de descodificação. A Fig. 10b ilustra a estrutura de uma unidade de acesso como definido em [2] . [2] ainda não especificou o fim da sequência ou fluxo, pelo que a sua presença na unidade de acesso seria provisória.

Para além disso, o número de unidades NAL associadas a uma subimagem precisa também de ser conhecido com antecedência num cenário de baixo atraso, visto que a mensagem SEI da instância da imagem contém esta informação e tem de ser compilada e enviada antes de o codificador iniciar a codificação da imagem atual. Um autor de aplicações relutante em inserir dados de preenchimento nas unidades NAL, com potencialmente nenhuns dados para cumprir com o número da unidade NAL, tal como assinalado por unidade de descodificação na SEI da instância de imagens, precisa de meios para sinalizar esta informação num nível de subimagem. 0 mesmo sucede para a instância de subimagem, atualmente fixada na existência de uma unidade de acesso pelos parâmetros dados na mensagem SEI da instância.

Outras incapacidades da especificação projetada [2] incluem várias sinalizações do nível subimagem, necessárias para aplicações específicas, tais como sinalização ROI ou sinalização de dimensões do mosaico.

Os problemas anteriormente descritos não são específicos da norma HEVC. Pelo contrário, este problema ocorre também em relação a outros codecs de vídeo. A Fig. 11 ilustra, mais genericamente, um cenário de transmissão de vídeo em que um par de codificador 10 e descodificador 12 são ligados através de uma rede 14 de modo a transmitir um vídeo 16 proveniente do codificador 10 para o descodificador 12 num curto atraso de extremo a extremo. O problema já anteriormente sinalizado é o seguinte. O codificador 10 codifica a sequência de frames 18 do vídeo 16 de acordo com uma certa sequência de descodificação que significativamente, mas não necessariamente, segue a sequência de reprodução 2 0 dos frames 18, e dentro de cada frame 18 viaja através da área de frames dos frames 18 de alguma maneira definida, tal como por exemplo de análise por varrimento com ou sem segmentação por mosaico dos frames 18. A sequência de descodificação controla a disponibilidade de informação para técnicas de codificação utilizadas pelo codificador 10 tais como, por exemplo, codificação de predição e/ou de entropia, isto é, a disponibilidade de informação em relação a partes de video 16 espaciais e/ou temporais vizinhas disponíveis para servir como uma base para predição ou seleção de contexto. Apesar de o codificador 10 poder ser capaz de utilizar processamento em paralelo de modo a codificar os frames 18 do vídeo 16, o codificador 10 precisa necessariamente de algum tempo para codificar um determinado frame 18, tal como o frame atual. A Fig. 11, por exemplo, ilustra um instante no tempo em que o codificador 10 já concluiu a parte de codificação 18a de um frame atual 18, enquanto outra parte 18b do frame atual 18 ainda não foi codificada. Como o codificador 10 ainda não codificou a parte 18b, o codificador 10 pode não prever o modo como o débito binário para codificar o frame atual 18 deverá ser espacialmente distribuído sobre o frame atual 18 de modo a obter uma otimização no que diz respeito a, por exemplo, sentido de débito/distorção. Por conseguinte, o codificador 10 possui apenas duas escolhas: ou o codificador 10 estima uma distribuição quase ótima do débito binário disponível para frame atual 18 nos segmentos nos quais o frame atual 18 se encontra espacialmente subdividido antecipadamente, nesse sentido aceitando que a estimativa possa estar errada, ou o codificador 10 finaliza a codificação do frame atual 18 antes de transmitir os pacotes com os segmentos do codificador 10 para o descodif icador 12. De qualquer maneira, de modo a poder aproveitar de qualquer transmissão de pacotes de segmentos do atual frame codificado 18 antes de finalizar a sua codificação, a rede 14 deverá ser informada dos débitos binários associados a cada um desses pacotes de segmentos sob a forma de tempos de remoção do buffer de imagens codificadas. Contudo, tal como indicado anteriormente, apesar de o codificador 10, de acordo com a versão atual de HEVC, poder variar o débito binário distribuído sobre os frames 18 através da utilização de definição do descodificador dos tempos de remoção do registo de imagens para áreas individuais de subimagem, o codificador 10 precisa de transmitir ou enviar essa informação através da rede 14 para o descodif icador 12 no início de cada unidade de acesso que recolhe todos os dados relativos ao frame atual 18, desse modo limitando o codificador 10 a escolher uma de entre as duas alternativas descritas, uma que conduz ao baixo atraso mas pior débito/distorção, a outra que conduz a um débito/distorção ótimos, contudo a um atraso de extremo a extremo aumentado.

Assim, até agora não existe um codec de vídeo que permita a obtenção desse baixo atraso em que o codificador poderia iniciar a transmissão de pacotes relativos a partes 18a do frame atual antes de codificar a restante parte 18b do frame atual, em que o descodificador poderia explorar esta transmissão intermediária de pacotes relativos a partes preliminares 18a através da rede 16, que obedece à descodificação do momento de recuperação do registo transportado no fluxo de dados de video enviado do codificador 12 para o descodificador 14. Aplicações que iriam, por exemplo, aproveitar esse exemplo de baixo atraso abrangem aplicações industriais tais como, por exemplo, peças de trabalho ou vigilância de fábrica para fins de automação ou de inspeção ou outro idêntico. Até agora, também não existe uma solução para informar o lado de descodificação da associação de pacotes a mosaicos nos quais um frame atual se encontra estruturado, e áreas de interessantes (área de interesse) de um frame atual de modo que as entidades de rede intermediárias na rede 16 consigam juntar tal informação do fluxo de dados sem terem de inspecionar aprofundadamente o interior dos pacotes, isto é, a sintaxe de segmentos.

Por conseguinte, é objetivo desta invenção proporcionar um conceito de codificação de fluxo de dados de video que seja mais eficaz ao permitir baixo atraso de extremo a extremo e/ou proporcione a identificação de partes do fluxo de dados a uma região de interesse ou a certos mosaicos com maior facilidade. Este propósito é alcançado através do tema das reivindicações independentes em anexo.

Uma ideia na qual este pedido é baseado é a de que a informação do tempo de pesquisa, informação ROI e a informação de identificação do mosaico deverão ser transportadas num fluxo de dados de vídeo a um nível que permita um acesso fácil pelas entidades de rede tais como MANEs ou descodificadores e que, de modo a atingir esse nível, a informação desses tipos deveria ser transportada num fluxo de dados de vídeo através de pacotes intercalados em pacotes de unidades de acesso de um fluxo de dados de vídeo. De acordo com uma forma de realização, os pacotes intercalados são de um tipo de pacote removível, isto é, a recuperação destes pacotes intercalados mantém a capacidade do descodificador em recuperar totalmente o conteúdo de vídeo transportado através do fluxo de dados de vídeo.

De acordo com um aspeto deste pedido, a obtenção do baixo atraso de extremo a extremo é tornada mais eficaz através da utilização de pacotes intercalados de modo a transportar informação sobre os tempos de pesquisa do registo do descodificador formado por pacotes de carga útil que se seguem ao respetivo pacote de controlo do momento no fluxo de dados de vídeo numa unidade de acesso atual. Através desta medida, o codificador é autorizado a determinar os tempos de pesquisa do registo do descodificador na hora durante a codificação do frame atual, permitindo assim, enquanto ocorre a codificação de um frame atual, determinar continuamente o débito binário verdadeiramente utilizado para a porção do frame atual que já foi codificada em pacotes de carga útil e transmitida, ou enviada, prefixada com pacotes de controlo de tempo, por um lado, e por conseguinte adaptar a distribuição do restante débito binário disponível para o frame atual sobre a restante porção do frame atual ainda não codificado. Através desta medida, o débito binário disponível é eficazmente explorado sendo o atraso apesar de tudo encurtado visto que o codificador não precisa de esperar para terminar a codificação do frame atual na sua totalidade.

De acordo com um aspeto adicional deste pedido, os pacotes intercalados num pacote de carga útil de uma unidade de acesso são rentabilizados para transportar informação numa região de interesse, permitindo assim, tal como anteriormente descrito, um acesso fácil desta informação pelas entidades de rede visto não terem que inspecionar os pacotes de carga útil intermediários. Além disso, o codificador permanece ainda livre para determinar os pacotes pertencentes à ROI durante a codificação de um frame atual durante o processo sem ter de determinar com antecedência a subdivisão do frame atual em subpartes e respetivos pacotes de carga útil. Acresce que, de acordo com a forma de realização com a qual os pacotes intercalados são do tipo pacotes removíveis, a informação ROI pode não ser considerada por destinatários do fluxo de dados de vídeo não interessados na informação ROI, ou que não consigam processar a mesma.

Ideias semelhantes são exploradas neste pedido de acordo com outro aspeto com o qual os pacotes intercalados transportam informação referente a que mosaicos pertencem certos pacotes numa unidade de acesso.

Implementações vantajosas desta invenção são objeto das reivindicações dependentes. Formas de realização deste pedido são descritas com maior detalhe em baixo em relação às figuras, de entre as quais:

Figs. 1 a 10b ilustram um estado atual da HEVC com a Fig. 1 a ilustrar uma sintaxe de mensagem SEI do período de buffering, a Fig. 2 ilustra uma sintaxe de mensagem SEI da instância de imagem, a Fig. 3 ilustra uma sintaxe de parâmetros VUI, a Fig. 4 ilustra uma sintaxe de parâmetros HRD, a Fig. 5 ilustra uma sintaxe RBSP de dados de preenchimento, a Fig. 6 ilustra uma estrutura dos fluxos de bytes e fluxos da unidade NAL para verificações de conformidade HRD, a Fig. 7 ilustra um modelo de registo HRD, a Fig. 8 ilustra uma sintaxe do cabeçalho de segmentos, a Fig. 9 ilustra uma sintaxe RBSP de fixação de parâmetro de imagens, a Fig. 10a ilustra uma apresentação esquemática de um bloco de árvores espacialmente conexo T possivelmente utilizado para invocar o processo de derivação de disponibilidade do bloco de árvores de codificação relativo ao bloco de árvores de codificação atual, e a Fig. 10b ilustra uma definição de uma estrutura de uma unidade de acesso; Fig. 11 ilustra esquematicamente um par de codificador e descodificador ligado através de uma rede para a ilustração de problemas que ocorrem na transmissão do fluxo de dados de vídeo;

Fig. 12 ilustra um diagrama de blocos esquemático de um codificador de acordo com uma forma de realização utilizando pacotes de controlo de tempo;

Fig. 13 ilustra um fluxograma que representa um modo de operação do codificador da Fig. 12 de acordo com uma forma de realização; Fig. 14 ilustra um diagrama de blocos de uma forma de realização de um codificador de modo a esclarecer a sua funcionalidade relativamente ao fluxo de dados de video gerados por um codificador de acordo com a Fig. 12;

Fig. 15 ilustra um diagrama de blocos esquemático que representa um codificador, uma entidade de rede e fluxo de dados de video de acordo com uma forma de realização adicional utilizando pacotes ROI;

Fig. 16 ilustra um diagrama de blocos que representa um codificador, entidade de rede e fluxo de dados de video de acordo com uma forma de realização adicional utilizando pacotes de identificação de mosaicos;

Fig. 17 ilustra uma estrutura de uma unidade de acesso de acordo com uma forma de realização. A linha a tracejado reflete o caso de uma unidade NAL de prefixo de segmentos não obrigatória;

Fig. 18 ilustra a utilização de mosaicos na sinalização da região de interesse;

Fig. 19 ilustra a primeira sintaxe/versão 1 simples;

Fig. 20 ilustra a sintaxe/versão 2 alargada, incluindo tile id signaling, identificador de inicio de unidade de descodificação, ID do prefixo de segmentos e dados do cabeçalho do segmento para além do conceito de mensagem SEI;

Fig. 21 ilustra o código do tipo de unidade NAL e classes do tipo de unidade NAL;

Fig. 22 ilustra uma possível sintaxe para um possível cabeçalho do segmento, em que certos elementos de sintaxe presentes no cabeçalho do segmento de acordo com uma versão atual são deslocados para um elemento de sintaxe de baixa hierarquia, referido como slice_header_data();

Fig. 23 ilustra uma tabela em que todos os elementos de sintaxe removidos do cabeçalho do segmento são assinalados através dos dados do cabeçalho do segmento do elemento de sintaxe;

Fig. 24 ilustra uma sintaxe da mensagem suplementar de melhoria de informação;

Fig. 25 ilustra uma sintaxe de carga útil SEI adaptada de modo a introduzir novos tipos de mensagens SEI de segmento ou subimagem;

Fig. 26 ilustra um exemplo para uma mensagem SEI de buffering subimagem;

Fig. 27 ilustra um exemplo para uma mensagem SEI da instância da subimagem;

Fig. 2 8 ilustra como poderá ser o aspeto de uma mensagem SEI de informação do segmento subimagem;

Fig. 2 9 ilustra um exemplo para uma mensagem SEI de informação do mosaico subimagem;

Fig. 30 ilustra um exemplo de sintaxe para uma mensagem SEI de informação das dimensões do mosaico subimagem;

Fig. 31 ilustra uma primeira variante de um exemplo de sintaxe para uma mensagem SEI da região de interesse em que cada ROI é assinalada numa mensagem SEI individual;

Fig. 32 ilustra uma segunda variante de um exemplo de sintaxe para uma mensagem SEI da região de interesse em que todas as ROIs são assinaladas numa única mensagem SEI;

Fig. 33 ilustra uma possível sintaxe para um pacote de controlo de tempo de acordo com uma forma de realização adicional;

Fig. 34 ilustra uma possível sintaxe para um pacote de identificação de mosaicos de acordo com uma forma de realização; Figs. 35 a 38 ilustram possíveis subdivisões de uma imagem de acordo com diferentes definições de acordo com uma forma de realização; e

Fig. 39 ilustra um exemplo de uma parte extraída de um fluxo de dados de vídeo de acordo com uma forma de realização utilizando pacotes de controlo de tempo interpolados entre os pacotes de carga útil de uma unidade de acesso.

No que diz respeito à Fig. 12, esta descreve um codificador 10 de acordo com uma forma de realização deste pedido e o seu modo de funcionamento. 0 codificador 10 está configurado para codificar conteúdo de vídeo 16 num fluxo de dados de vídeo 22. O codificador está configurado para executar esta última em unidades de subpartes dos frames/imagens 18 do conteúdo de vídeo 16, em que as subpartes podem, por exemplo, ser segmentos 24 nos quais imagens 18 são divididas, ou alguns outros segmentos espaciais tais como, por exemplo, mosaicos 26 ou subfluxos WPP 28, todos ilustrados na Fig. 12 apenas para fins ilustrativos e não querendo sugerir que o codificador necessita de suportar processamento ao mosaico ou em paralelo WPP, por exemplo, ou que as subpartes precisam ser segmentos.

Ao codificar o conteúdo de vídeo 16 em unidades de subpartes 24, o codificador 10 pode obedecer a uma sequência de descodificação, ou sequência de codificação, definido entre as subpartes 24, que por exemplo atravessa as imagens 18 de video 16 de acordo com uma sequência de descodificação de imagem que, por exemplo, não coincide necessariamente com a sequência de reprodução 20 definido entre as imagens 18, e atravessa cada imagem 18 blocos nos quais imagens 18 se encontram divididas, de acordo com uma sequência de análise por varrimento, com as subpartes 24 em que representam execuções continuas desses blocos ao longo da sequência de descodificação. Em especial, o codificador 10 pode ser configurado para obedecer a esta sequência de descodificação na determinação da disponibilidade de partes espacial e/ou temporalmente conexas de partes atualmente a ser codificadas de modo a utilizar atributos descrevendo tais partes conexas na predição de codificação e/ou codificação de entropia tais como, por exemplo, para determinar a predição e/ou um contexto de entropia: Partes meramente visitadas anteriormente (codificadas/descodifiçadas) do video encontram-se disponíveis. Caso contrário, os atributos agora mencionados são fixados em valores por defeito ou algumas outras medidas substitutas são tomadas.

Por outro lado, o codificador 10 não precisa codificar em série subpartes 24 juntamente com a sequência de descodificação. Pelo contrário, o codificador 10 pode utilizar processamento em paralelo para acelerar o processo de codificação, ou poder executar uma codificação mais complexa em tempo real. Do mesmo modo, o codificador 10 pode ou não ser configurado para transmitir ou enviar os dados codificando subpartes juntamente com a sequência de descodificação. Por exemplo, o codificador 10 pode fazer sair/transmitir os dados codificados em alguma outra sequência de modo que, por exemplo, de acordo com a sequência na qual a codificação das subpartes é finalizada pelo codificador 10 que pode, devido ao processamento em paralelo, por exemplo, desviar da sequência de descodificação agora mencionado.

De modo a tornar as versões codificadas de subpartes 24 adequadas para transmissão numa rede, o codificador 10 codifica cada subparte 2 4 num ou mais pacotes de carga útil de uma sequência de pacotes de fluxo de dados de vídeo 22. No caso das subpartes 24 serem segmentos, o codificador 10 pode, por exemplo, ser configurado para colocar cada dado do segmento, isto é, cada segmento codificado, num pacote de carga útil, tal como uma unidade NAL. Este empacotamento pode servir para tornar o fluxo de dados de vídeo 22 adequado para transmissão através de uma rede. Por conseguinte, os pacotes podem representar as unidades mais pequenas nas quais o fluxo de dados de video 22 pode ocorrer, isto é, as unidades mais pequenas que podem ser individualmente enviadas pelo codificador 10 para transmissão através de uma rede para um destinatário.

Para além dos pacotes de carga útil e dos pacotes de controlo de tempo interpolados entre si e aqui discutidos, outros pacotes, isto é, pacotes de outro tipo podem também existir, tais como pacotes de preenchimento de dados, pacotes de conjuntos de parâmetros de imagem ou de sequência para transmitir elementos de sintaxe de alteração infrequentemente ou pacotes EOF (fim de ficheiro) ou AUE (fim de unidade de acesso) ou outros idênticos. 0 codificador executa a codificação nos pacotes de carga útil de modo que a sequência de pacotes é dividida numa sequência de unidades de acesso 30 e cada unidade de acesso recolhe os pacotes de carga útil 32 relativamente a uma imagem 18 do conteúdo de video 16. Ou seja, a sequência 34 de pacotes que formam o fluxo de dados de video 22 é subdividida em partes não-sobrepostas, designadas unidades de acesso 30, cada uma associada a cada uma das respetivas imagens 18. A sequência de unidades de acesso 30 pode seguir a sequência de descodificação das imagens 18 às quais as unidades de acesso 30 dizem respeito. A Fig. 12 ilustra, por exemplo, que a unidade de acesso 30 existente no meio da parte do fluxo de dados 22, ilustrados, compreende um pacote de carga útil 32 por subparte 24 na qual a imagem 18 é subdividida. Ou seja, cada pacote de carga útil 32 transporta uma subparte correspondente 24. O codificador 10 é configurado para intercalar na sequência 34 de pacotes, pacotes de controlo de tempo 36 de modo que os pacotes de controlo de tempo subdividem as unidades de acesso 30 nas unidades de descodificação 38 de modo que pelo menos algumas unidades de acesso 30, tais como a do meio ilustrada na Fig. 12, sejam subdivididas em duas ou mais unidades de descodificação 38, cada pacote de controlo de tempo assinalando um tempo de pesquisa do registo do descodificador para uma unidade de descodificação 38, os pacotes de carga útil 32 os quais seguem o respetivo pacote de controlo de tempo na sequência 34 de pacotes. Por outras palavras, o codificador 10 prefixa subsequências da sequência de pacotes de carga útil 32 numa unidade de acesso 30 com um pacote de controlo de tempo 36 respetivo assinalando a respetiva subsequência de pacotes de carga útil prefixados pelo pacote de controlo de tempo 36 respetivo e formando uma unidade de descodificação 38, um tempo de pesquisa do registo do descodificador. A Fig. 12, por exemplo, ilustra o caso em que todos os segundos pacotes 32 representam o primeiro pacote de carga útil de uma unidade de descodificação 38 da unidade de acesso 30. Tal como ilustrado na Fig. 12, a quantidade de dados ou débito binário despendidos para cada unidade de descodificação 38 varia e os tempos de pesquisa do registo do descodificador podem correlacionar-se com esta variação de débito binário entre as unidades de descodificação 38 na medida em que o tempo de pesquisa do registo do descodif icador de uma unidade de descodificação 38 acompanha o tempo de pesquisa do registo do descodificador sinalizada pelo pacote de controlo do tempo 36 da unidade de descodificação 38 imediatamente anterior mais o tempo de intervalo correspondente ao débito binário despendido para esta unidade de descodificação 38 imediatamente anterior.

Isto é, o codificador 10 pode funcionar tal como ilustrado na Fig. 13. Em especial, tal como anteriormente mencionado o codificador 19 pode, na etapa 40, sujeitar uma subparte atual 24 de uma imagem atual 18 a uma codificação. Tal como já mencionado, o codificador 10 pode sequencialmente manobrar as subpartes 24 na sequência de descodificação anteriormente mencionada tal como ilustrado pela seta 42, ou o codificador por utilizar algum processamento em paralelo tal como WPP e/ou processamento de mosaicos de modo a codificar simultaneamente várias "subpartes atuais" 24. Independentemente da utilização ou não do processamento em paralelo, o codificador 10 forma uma unidade de descodificação de uma ou várias subpartes recentemente codificadas na etapa 40 e prossegue com a etapa 44, em que o codificador 10 fixa um tempo de pesquisa de registo do descodificador para esta unidade de descodificação e transmite esta unidade de descodificação prefixada com um pacote de controlo de tempo sinalizando o tempo de pesquisa de registo do descodificador para esta unidade de descodificação. Por exemplo, o codificador 10 pode determinar o tempo de pesquisa de registo do descodificador na etapa 44 com base no débito binário despendido para a codificação das subpartes que foram codificadas nos pacotes de carga útil formando a unidade de descodificação atual incluindo, por exemplo, todos os pacotes intermediários adicionais nesta unidade de descodificação, caso existam, isto é, os "pacotes prefixados".

Consequentemente, na etapa 46, o codificador 10 pode adaptar o débito binário disponível com base no débito binário despendido para a unidade de descodificação já transmitida na etapa 44. Se, por exemplo, o conteúdo da imagem na unidade de descodificação já transmitida na etapa 44 era bastante complexo em termos de taxa de compressão, então o codificador 10 pode reduzir o débito binário disponível para a próxima unidade de descodificação de modo a obedecer a algum conjunto externo de débito binário alvo determinado, por exemplo, com base numa situação de banda larga atual relativa à rede que transmite o fluxo de dados de vídeo 22. As etapas 40 a 56 são então repetidas. Através desta medida, as imagens 18 são codificadas e transmitidas, isto é, enviadas, em unidades de unidades de descodificação, cada uma prefixada por um pacote de controlo de tempo correspondente.

Por outras palavras, o codificador 10, durante a codificação de uma imagem atual 18 do conteúdo de vídeo 16, codifica 40 uma subparte atual 24 da imagem atual 18 num pacote de carga útil atual 32 de uma unidade de descodificação atual 38, transmite 44, no fluxo de dados, a unidade de descodificação atual 38 prefixada com um pacote de controlo de tempo atual 36 com a definição de um tempo de pesquisa de registo do descodificador assinalado pelo pacote de controlo do tempo atual (36), num primeiro instante, e codifica 44, regressando da etapa 46 à 40, uma subparte adicional 24 da imagem atual 18 num segundo momento- segunda visita à etapa 40, posteriormente ao primeiro instante- primeira visita à etapa 44.

Como o codificador consegue enviar uma unidade de descodificação antes da codificação de um restante da imagem atual à qual esta unidade de descodificação pertence, o codificador 10 consegue baixar o atraso de extremo a extremo. Por outro lado, o codificador 10 não precisa de desperdiçar tempo disponível, visto que o codificador 10 consegue reagir à natureza especifica do conteúdo da imagem atual e da sua distribuição de complexidade espacial.

Por outro lado, as entidades de rede intermediárias, responsáveis pela transmissão de fluxo de dados de video 22 adicional do codificador para o descodificador, conseguem utilizar os pacotes de controlo do tempo 36 de modo a garantir que qualquer descodificador que tenha recebido o fluxo de dados de video 22 receba as unidades de descodificação a tempo de modo a poder ganhar vantagem sobre a aproximação da unidade de descodificação codificação e transmissão pelo codificador 10. Ver, por exemplo, a Fig. 14 que ilustra um exemplo para um descodificador para descodificar o fluxo de dados de vídeo 22. O descodif icador 12 recebe o fluxo de dados de vídeo 22 num segundo buffer de imagens codificadas CPB 48 através de uma rede por via da qual o codificador 10 transmitiu o fluxo de dados de vídeo 22 ao descodif icador 12. Particularmente, dado que a rede 14 se presume como podendo suportar a aplicação de baixo atraso, a rede 10 inspeciona os tempos de pesquisa de registo do descodificador de modo a encaminhar a sequência 34 de pacotes de fluxo de dados de vídeo 22 ao buffer de imagens codificadas 48 do descodif icador 12 de modo que cada unidade de descodificação esteja presente no buffer de imagens codificadas 48 antes do tempo de pesquisa do registo de imagens assinalado pelo pacote de controlo de tempo associando a respetiva unidade de descodificação. Através desta medida, o descodificador pode, sem parar, isto é, sem ficar sem pacotes de carga útil disponíveis no buffer de imagens codificadas 48, utilizar os tempos de pesquisa do registo de imagens nos pacotes de controlo de tempo de modo a esvaziar o buffer de imagens codificadas 48 do descodificador em unidades das unidades de descodificação em vez de unidades de acesso completo. A Fig. 14, por exemplo, ilustra para fins ilustrativos, uma unidade de processamento 50 como estando ligada a uma saída de buffer de imagens codificadas 48, cuja entrada recebe o fluxo de dados de vídeo 22. Do mesmo modo do codificador 10, o descodificador 12 pode executar processamento em paralelo tal como, por exemplo, utilizando processamento em paralelo/descodificação de mosaicos e/ou processamento em paralelo/descodificação de WPP.

Tal como descrito com maior detalhe em baixo, os tempos de pesquisa do registo de imagens do descodificador mencionados até agora não pertencem necessariamente a tempos de pesquisa relativos ao buffer de imagens codificadas 48 do descodificador 12. Em vez disso, os pacotes de controlo de tempo podem adicionalmente, ou alternativamente, comandar a remoção de dados de imagens já descodificados de um buffer de imagens descodificadas correspondentes de um descodificador 12. A Fig. 14 ilustra, por exemplo, o descodificador 12 como compreendendo um buffer de imagens do descodificador no qual a versão descodificada do conteúdo de vídeo, obtida pela unidade de processamento 50 pela descodificação do fluxo de dados de vídeo 22, é registrada, isto é, armazenada e enviada, em unidades de versões descodificadas de unidades de descodificação. 0 buffer de imagens descodificadas do descodificador 22 pode assim estar ligado entre a saída do descodificador 12 e a saída da unidade de processamento 50. Tendo a capacidade de fixar os tempos de pesquisa para a saída de versões descodificadas de unidades de descodificação do buffer de imagens descodificadas 52, ao codificador 10 é dada a oportunidade de, a cada dado instante, isto é, durante a codificação de uma imagem atual, controlar a reprodução, ou extremo-a-extremo, atraso da reprodução do conteúdo de vídeo no lado de descodificação mesmo a uma granularidade mais pequena do que o débito de imagem ou débito de frame. Obviamente, a sobre segmentação de cada imagem 18 numa grande quantidade de subpartes 24 no lado de codificação iria afetar de modo negativo o débito binário para transmitir o fluxo de dados de vídeo 22, apesar de, por outro lado, o atraso extremo-a-extremo poder ser minimizado visto que o tempo necessário para codificar e transmitir e descodificar e fazer sair tal unidade de descodificação seria minimizado. Por outro lado, aumentando as dimensões das subpartes 24 aumenta o atraso extremo-a-extremo. Por conseguinte, terá de se encontrar um compromisso. A utilização dos tempos de pesquisa do buffer de imagens do descodificador de modo a comandar o tempo de saída das versões descodifiçadas das subpartes 24 em unidades de unidades de descodificação permite que o codificador 10 ou alguma outra unidade no lado de descodificação se adapte a este compromisso espacialmente sobre o conteúdo da imagem atual.

Através desta medida, seria possível controlar o atraso extremo-a-extremo de tal modo que o mesmo varia espacialmente pelo conteúdo de imagens atual.

Na implementação das formas de realização acima descritas é possível utilizar, como os pacotes de controlo de tempo, pacotes de um tipo de pacote removível. Pacotes de um tipo de pacote removível não estão necessariamente em ordem para recuperarem o conteúdo de vídeo no lado de descodificação. No seguimento, tais pacotes são designados pacotes SEI. Outros pacotes de um tipo de pacote removível podem também existir, ou seja, pacotes removíveis de outro tipo tal como, se transmitidos no fluxo, pacotes de redundância. Como outra alternativa, os pacotes de controlo do tempo podem ser pacotes de um certo tipo de pacote removível, transportando adicionalmente, contudo, um certo campo do tipo de pacote SEI. Por exemplo, os pacotes de controlo de tempo podem ser pacotes SEI com cada pacote SEI transportando uma ou mais mensagens SEI, e apenas esses pacotes SEI que compreendem uma mensagem SEI de um certo tipo formam os pacotes de controlo de tempo anteriormente mencionados.

Assim, a forma de realização descrita até agora em relação às Figs. 12 a 14 é, de acordo com uma forma de realização adicional, aplicado à norma HEVC, formando assim um possível conceito para tornar a HEVC mais eficaz na obtenção de baixo atraso extremo-a-extremo. Ao fazê-lo, os pacotes anteriormente mencionados são formados por unidades NAL e os pacotes de carga útil anteriormente mencionados são unidades NAL VCL de um fluxo de unidade NAL com segmentos que formam as subpartes mencionadas acima.

Antes de tal descrição de uma forma de realização mais detalhada, contudo, formas de realização adicionais são descritas, que coincidem com formas de realização descritas anteriormente nesses pacotes intercalados são utilizados por ordem para transportarem, de modo eficaz, informação que descreva o fluxo de dados de vídeo, mas o tipo de informação difere das formas de realização anteriores em que os pacotes de controlo de tempo transportados transportaram informação relativa ao tempo de pesquisa de registo do descodificador. Nas formas de realização descritos mais abaixo, o tipo de informação transferida através de pacotes intercalados, intercalados nos pacotes de carga útil pertencentes a uma unidade de acesso, dizem respeito a uma informação sobre a região de interesse (ROI) e/ou informação de identificação do mosaico. Nas formas de realização descritos mais abaixo podem ou não ser combinadas com as formas de realização descritas no que diz respeito às Figs. 12 a 14. A Fig. 15 ilustra um codificador 10 que funciona do mesmo modo que o esclarecido acima em relação à Fig. 12, exceto para o intercalado dos pacotes de controlo de tempo e a funcionalidade descrita acima em relação à Fig. 13, sendo opcional para o codificador 10 da Fig. 15. Contudo, o codificador 10 da Fig. 15 é configurado para codificar conteúdo de video 16 num fluxo de dados de video 22 em unidades de subpartes 24 das imagens 18 do conteúdo de vídeo 16 tal como explicado acima em relação à Fig. 11. Na codificação do conteúdo de vídeo 16, o codificador 10 está interessado em transportar, juntamente com o fluxo de dados de vídeo 22, informação sobre uma região de interesse ROI 60 ao lado de descodificação. A ROI 60 é uma subárea espacial de uma imagem atual 18, que o descodificador deve, por exemplo, prestar uma atenção especial. A posição espacial da ROI 60 pode entrar no codificador 10 a partir do exterior, tal como ilustrado por uma linha tracejada 62, tal como pela entrada de utilizador, ou pode ser determinada automaticamente pelo codificador 10 ou por alguma outra entidade, na hora durante a codificação da imagem atual 18. Em qualquer dos casos, o codificador 10 enfrenta o seguinte problema: a indicação da localização da ROI 60 não é, em princípio, problema para o codificador 10. Para tal, o codificador 10 pode facilmente indicar a localização da ROI 60 no fluxo de dados 22. Contudo, para tornar esta informação de fácil acesso, o codificador 10 da Fig. 15 utiliza a intercalação de pacotes ROI entre pacotes de carga útil das unidades de acesso de modo que o codificador 10 está livre para, numa base online, escolher a segmentação da imagem atual 18 em subpartes 24 e/ou o número de pacotes de carga útil nos quais as subpartes 24 são "embaladas", espacialmente no exterior e espacialmente no interior da ROI 60. Utilizando os pacotes ROI intercalados, qualquer entidade de rede pode facilmente identificar pacotes de carga útil pertencentes à ROI. Por outro lado, no caso de utilização do tipo de pacote removível para estes pacotes ROI, o mesmo pode ser facilmente desrespeitado por qualquer entidade de rede. A Fig. 15 ilustra um exemplo para a intercalação de pacotes ROI 64 entre os pacotes de carga útil 32 de uma unidade de acesso 30. O pacote ROI 64 indica onde numa sequência 34 de pacotes do fluxo de dados de video 22 codificou os dados relativos a, isto é codifica, a ROI 60. O modo como o pacote ROI 64 indica a localização de ROI 60 pode ser implementado de várias maneiras. Por exemplo, a pura existência/ocorrência de um pacote ROI 64 pode indicar a incorporação de dados codificados relativos à ROI 64 num ou mais dos seguintes pacotes de carga útil 32, seguidos na ordem sequencial de sequência 34, ou seja, pertencentes aos pacotes de carga útil prefixados. Em alternativa, um elemento de sintaxe no interior do pacote ROI 64 pode indicar se um ou mais dos seguintes pacotes de carga útil 32 pertence a, por exemplo, pelo menos parcialmente codificar, a ROI 60 ou não. O número elevado de variância desdobra-se também a partir das possíveis variações relativas ao "âmbito" do respetivo pacote ROI 64, isto é, o número de pacotes de carga útil prefixados, prefixados por um pacote ROI 64. Por exemplo, a indicação de incorporação ou não incorporação de quaisquer dados codificados à ROI 60 num pacote ROI, pode dizer respeito a todos os pacotes de carga útil 32 seguidos na ordem sequencial da sequência 34 até à ocorrência do próximo pacote ROI 64, ou pode apenas dizer respeito ao pacote de carga útil 32 imediatamente a seguir, ou seja, o pacote de carga útil 32 imediatamente a seguir ao respetivo pacote ROI 64 na ordem sequencial da sequência 34. Na Fig. 15, um gráfico 66 ilustra como exemplo um caso em que os pacotes ROI 64 indicam uma relevância ROI, ou seja, a incorporação de quaisquer dados codificados à ROI 60, ou a não relevância da ROI, ou seja, a ausência de quaisquer dados codificados à ROI 60, relativos a todos os pacotes de carga útil 32 que ocorrem a jusante do respetivo pacote ROI 64 até à ocorrência do próximo pacote ROI 64 ou o final da unidade de acesso atual 30, aquela que ocorrer em primeiro lugar juntamente com a sequência 34 de pacotes. Em especial, a Fig. 15 ilustra o caso em que um pacote ROI 64 é dotado de um elemento de sintaxe no interior, indicando se os pacotes de carga útil 32 seguintes na ordem sequencial de sequência de pacotes 34 têm ou não dados codificados relativos à ROI 60 no interior. Tal forma de realização é também descrito adiante. Contudo, outra possibilidade é, tal como mencionado, que cada pacote ROI 64 indica apenas pela sua presença na sequência de pacotes 34 que o pacote (s) de carga útil 32 pertencente ao "âmbito" do pacote ROI 64 respetivo, é dotado de dados relativos à ROI 60 no interior, ou seja, dados relativos à ROI 60. De acordo com uma forma de realização adiante descrita com maior detalhe, o pacote ROI 64 indica mesmo a localização da parte da ROI 60 codificada no pacote (s) de carga útil 32 pertencente ao seu "âmbito".

Qualquer entidade de rede 68 que recebe o fluxo de dados de video 22 pode explorar a indicação de relevância ROI tal como apercebida pela utilização dos pacotes ROI 64 de modo a tratar, por exemplo, partes de ROI relevantes da sequência 34 de pacotes com prioridade mais elevada do que outras partes da sequência de pacotes 34, por exemplo, em alternativa, a entidade de rede 68 pode utilizar a informação de relevância ROI de modo a executar outras tarefas relativas, por exemplo, à transmissão do fluxo de dados de video 22. A entidade de rede 68 pode ser, por exemplo, um MANE ou um descodificador para descodificar a reprodução do conteúdo de vídeo 60 tal como transportado através do fluxo de dados de vídeo 22, 28. Por outras palavras, a entidade de rede 68 pode utilizar um resultado da identificação de pacotes ROI de modo a decidir sobre as tarefas de transmissão pertencentes ao fluxo de dados de vídeo. As tarefas de transmissão podem compreender pedidos de retransmissão relativa a pacotes com deficiências. A entidade de rede 68 pode ser configurada para manusear a região de interesse 70 com prioridade aumentada e atribuir uma prioridade mais elevada aos pacotes ROI 72 e aos seus respetivos pacotes de carga útil, ou seja, aqueles que foram por ele prefixados, e que se encontram assinalados como se sobrepondo à região de interesse, do que comparados a pacotes ROI e seus respetivos pacotes de carga útil, que se encontram assinalados como não sobrepostos à ROI. A entidade de rede 68 pode em primeiro lugar solicitar uma retransmissão de pacotes de carga útil com prioridade mais elevada, antes de solicitar igualmente qualquer retransmissão de pacotes de carga útil com prioridade mais baixa. A forma de realização da Fig. 15 pode facilmente ser combinada com a forma de realização descrita anteriormente em relação às Figs. 12 a 14. Por exemplo, os pacotes ROI 64 mencionados anteriormente podem também ser pacotes SEI dotados de um certo tipo de mensagem SEI ali contida, nomeadamente uma mensagem SEI ROI. Ou seja, um pacote SEI pode, por exemplo, ser um pacote de controlo de tempo e simultaneamente um pacote ROI, em especial se o pacote SEI compreende simultaneamente informação de controlo de tempo assim como informação de indicação ROI. Em alternativa, um pacote SEI pode ser um de um pacote de controlo de tempo e um pacote ROI, em vez de o outro, ou não ser nem um pacote ROI nem um pacote de controlo de tempo.

De acordo com a forma de realização ilustrada na Fig. 16, a intercalação de pacotes entre os pacotes de carga útil das unidades de acesso é utilizada para indicar, de uma maneira facilmente acessível às entidades de rede 68, o manuseamento do fluxo de dados de vídeo 22, cujo mosaico ou mosaicos são da imagem atual 18, a gue unidade de acesso atual 30 diz respeito, se encontra sobreposto por qualquer subparte codificada em quaisquer pacotes de carga útil 32 para cujos respetivos pacotes serve como um prefixo. Na Fig. 16, por exemplo, a imagem atual 18 é ilustrada para ser subdividida em quatro mosaicos 70, aqui formados como exemplo pelos quatro quadrantes da imagem atual 18. A subdivisão da imagem atual 18 em mosaicos 70 pode, por exemplo, ser assinalada no fluxo de dados de vídeo em unidades compreendendo sequências de imagens tais como, por exemplo, em pacotes VPS ou SPS também intercalados na sequência 34 de pacotes. Tal como será descrito com maior detalhe em baixo, uma subdivisão de mosaicos da imagem atual 18 pode ser uma subdivisão regular da imagem 18 em colunas e linhas de mosaicos. 0 número de colunas e o número de linhas assim como a largura das colunas e a altura das linhas de mosaicos pode ser variado. Em especial, a largura e altura das colunas/linhas de mosaicos pode ser diferente para diferentes linhas e diferentes colunas, respetivamente. A Fig. 16 ilustra adicionalmente o exemplo em que as subpartes 24 são segmentos da imagem 18. Os segmentos 24 subdividem a imagem 18. Tal como descrito com maior detalhe em baixo, a subdivisão da imagem 18 em segmentos 24 pode ser sujeita a constrangimentos de acordo com os quais cada segmento 24 pode estar completamente contido num único mosaico 70, ou completamente cobrir dois ou mais mosaicos 70. A Fig. 16 ilustra um caso em que a imagem 18 é subdividida em cinco segmentos 24. Os primeiros quatro desses segmentos 24 na sequência de descodificação anteriormente descrita cobrem os primeiros dois mosaicos 70, enquanto o quinto mosaico cobre completamente o terceiro e o quarto mosaico 70. Ainda, a Fig. 16 ilustra o caso em que cada segmento 24 é individualmente codificado num respetivo pacote de carga útil 32. Ainda, a Fig. 16 ilustra como exemplo o caso em que cada pacote de carga útil 32 é prefixada por um pacote de identificação de mosaicos 72 anterior. Cada pacote de identificação de mosaicos 72, por um lado, indica o seu pacote de carga útil 32 imediatamente seguinte relativo a qual dos mosaicos 70 a subparte 24 codificada neste pacote de carga útil 32 se sobrepõe. Por conseguinte, enquanto os primeiros dois pacotes de identificação de mosaicos 72 na unidade de acesso 30 relativa à imagem atual 18 indica o primeiro mosaico, o terceiro e quarto pacote de identificação de mosaicos 72 indica o segundo mosaico 70 da imagem 18, e o quinto pacote de identificação de mosaicos 72 indica o terceiro e o quarto mosaico 70. Em relação à forma de realização da Fig. 16, as mesmas variações são viáveis tal como descrito em baixo em relação à Fig. 15, por exemplo. Ou seja, o "âmbito" dos pacotes de identificação do mosaico 72 pode, por exemplo, abranger apenas o primeiro pacote de carga útil 32 imediatamente seguinte ou os pacotes de carga útil 32 imediatamente seguintes até à ocorrência do próximo pacote de identificação de mosaicos.

No que diz respeito aos mosaicos, o codificador 10 pode ser configurado para codificar cada mosaico 70 de modo que, através das delimitações dos mosaicos, não ocorra nenhuma predição espacial ou nenhuma seleção de contexto. O codificador 10 pode, por exemplo, codificar o mosaico 70 em paralelo. Do mesmo modo, qualquer descodif icador tal como a entidade de rede 68 pode descodificar os mosaicos 70 em paralelo. A entidade de rede 68 pode ser um MANE ou um descodif icador ou algum outro dispositivo intermédio do codificador 10 e descodificador, e pode ser configurado para utilizar a informação transportada pelos pacotes de identificação de mosaicos 72 para decidir sobre certas tarefas de transmissão. Por exemplo, a entidade de rede 68 pode manusear um certo mosaico da imagem atual 18 de video 16 com prioridade mais elevada, ou seja, pode encaminhar os respetivos pacotes de carga útil indicados como sendo relativos a esse mosaico anteriormente ou utilizando proteção FEC mais segura ou outro idêntico. Por outras palavras, a entidade de rede 68 pode utilizar um resultado da identificação de modo a decidir sobre tarefas de transmissão pertencentes ao fluxo de dados de video. As tarefas de transmissão podem compreender pedidos de retransmissão relativos a pacotes recebidos num estado defeituoso, isto é, excedendo qualquer proteção FEC do fluxo de dados de video, caso exista. A entidade de rede pode manusear, por exemplo, diferentes mosaicos 70 com diferentes prioridades. Com esta finalidade, a entidade de rede pode atribuir uma prioridade mais elevada aos pacotes de identificação de mosaicos 72 e seus pacotes de carga útil, ou seja, aqueles por ele prefixados, pertencentes a mosaicos de prioridade mais elevada, do que comparados com pacotes de identificação de mosaicos 72 e seus pacotes de carga útil pertencentes a mosaicos de prioridade baixa. A entidade de rede 68 pode, por exemplo, em primeiro lugar solicitar uma retransmissão de pacotes de carga útil com prioridade mais elevada, antes de solicitar qualquer retransmissão de pacotes de carga útil com prioridade mais baixa.

As formas de realização descritas até ao momento podem ser construídas pelo enquadramento HEVC tal como descrito na parte introdutória da especificação deste pedido tal como descrito em seguida .

Em especial, mensagens SEI podem ser atribuídas a segmentos de unidades de descodificação no caso da subimagem CPB/HRD. Ou seja, o período de buffering e as mensagens SEI de tempo podem ser atribuídos às unidades NAL contendo os segmentos de uma unidade de descodificação. Tal pode ser obtido através de um novo tipo de unidade NAL, uma unidade NAL não-VCL que pode preceder diretamente uma ou mais unidades de segmento/NAL VCL de uma unidade de descodificação. Esta nova unidade NAL pode ser designada unidade NAL de prefixo de segmento. A Fig. 17 ilustra a estrutura de uma unidade de acesso que omite quaisquer unidades NAL provisórias para fim de sequência e de fluxo.

De acordo com a Fig. 17, uma unidade de acesso 30 é construída do seguinte modo: na ordem sequencial de pacotes da sequência 34 de pacotes, a unidade de acesso 30 pode iniciar com a ocorrência de um tipo especial de pacote, em especial um delimitador da unidade de acesso 80. Depois, um ou mais pacotes SEI 82 de um tipo de pacote SEI relativo a toda a unidade de acesso pode seguir-se na unidade de acesso 30. Ambos os tipos de pacotes 80 e 82 são opcionais. Ou seja, nenhum pacote deste tipo pode ocorrer numa unidade de acesso 30. Depois, segue-se a sequência das unidades de descodificação 3. Cada unidade de descodificação 38 inicia opcionalmente com um prefixo de segmento da unidade NAL 84, incluindo nisso por exemplo informação de controlo de tempo ou de acordo com a forma de realização da Fig. 15 ou 16, uma informação ROI ou informação de mosaico ou, mesmo mais geralmente, uma mensagem SEI subimagem respetiva 86. Depois, seguem-se os dados de segmento atual 88 nos respetivos pacotes de carga útil ou unidades NAL VCL como indicado em 88. Assim, cada unidade de descodificação 38 compreende uma seguência de um prefixo de segmento da unidade NAL 84 seguida por respetivos dados de segmento da unidade (s) NAL 88. A seta desviada 90 na Fig. 17, contornando o prefixo de segmento da unidade NAL, deverá indicar que no caso de não existir subdivisão de unidade de descodificação da unidade de acesso atual 30 poderá não existir prefixo de segmento da unidade NAL 84.

Tal como já observado acima, toda a informação assinalada no prefixo de segmento e respetivas mensagens SEI subimagem pode ser válida para todas as unidades NAL VCL na unidade de acesso ou até a ocorrência de uma segunda unidade de prefixo NAL ou para a unidade VCL-NAL seguinte na sequência de descodificação, dependendo de uma sinalização ou bandeira atribuída na unidade NAL do prefixo de segmento. A unidade do prefixo de segmento NAL, para a qual a informação assinalada no prefixo de segmento é válida, é referida seguidamente como segmentos prefixados. Segmentos prefixados associados ao único segmento prefixado não constituem necessariamente uma unidade de descodificação completa mas podem fazer parte dela. Contudo, um único prefixo de segmento não pode ser válido para múltiplas unidades de descodificação (subimagens) e o início de uma unidade de descodificação é assinalado no prefixo de segmento. Se meios de sinalização não forem dados através da sintaxe de prefixo do segmento (como na "sintaxe simples"/versão 1 indicado em baixo), a ocorrência de uma unidade de prefixo de segmento NAL assinala o inicio de uma unidade de descodificação. Apenas certas mensagens SEI (identificadas através do Tipo de carga útil na descrição de sintaxe em baixo) podem ser enviadas exclusivamente ao nivel da subimagem no prefixo de segmento da unidade NAL, enquanto algumas mensagens SEI podem ser enviadas no prefixo de segmento da unidade NAL no nivel da subimagem ou como uma mensagem SEI regular no nível da unidade de acesso.

Tal como discutido anteriormente em relação à fig. 16, adicionalmente ou alternativamente, uma mensagem SEI de ID do mosaico/sinalização ID do mosaico pode ser executada na sintaxe de alto nivel. Em conceções anteriores de uma HEVC, o cabeçalho de segmento/os dados de segmento continham um identificador para o mosaico contido no respetivo segmento. Por exemplo, a semântica dos dados de segmento têm a seguinte leitura: tile_idx_minus_l especifica o TilelD na sequência de análise por varrimento. 0 primeiro mosaico na imagem deverá ter um TilelD de 0. O valor do tile_idx_minus_l deverá ser da ordem de 0 a ( num_tile_columns_minusl + 1 ) * ( num_tile_rows_minusl + 1 ) - 1.

Este parâmetro contudo não é considerado útil visto que esta ID pode ser facilmente derivada do endereço de segmento e as dimensões do segmento como assinalado no conjunto de parâmetros de imagem, se tiles_or_entropy_coding_sync_idc for igual a 1.

Apesar de a ID do segmento poder ser implicitamente derivada no processo de descodificação, o conhecimento deste parâmetro no nivel de aplicação é também importante para casos de diferente utilização tais como, por exemplo, num cenário de videoconferência em que diferentes mosaicos podem ter diferente prioridade para a reprodução (aqueles mosaicos tipicamente formam a região de interesse que contém o locutor num caso de utilização de conversação) pode ter uma prioridade mais elevada do que outros mosaicos. No caso de perda de pacotes de rede na transmissão de múltiplos mosaicos, os pacotes de rede que contêm mosaicos que representam a região de interesse podem ser retransmitidos com prioridade mais elevada de modo a manter a qualidade da experiência no terminal recetor superior do que no caso da retransmissão de mosaicos sem qualquer ordem de prioridade. Outro caso de utilização pode ser atribuir mosaicos, se as dimensões e a sua posição forem conhecidas, para diferentes ecrãs, por exemplo num cenário de videoconferência.

De modo a permitir que tal aplicação manuseie mosaicos com uma determinada prioridade em cenários de transmissão, o tile_id_ pode ser fornecido como uma subimagem ou mensagem SEI de subimagem ou numa unidade NAL especial em frente a uma ou mais unidades NAL do mosaico ou numa secção do cabeçalho especial da unidade NAL pertencente ao mosaico.

Tal como descrito anteriormente em relação à Fig. 15, mensagens SEI da região de interesse podem também ser adicionalmente ou alternativamente fornecidas. Essa mensagem SEI poderia permitir a sinalização da região de interesse (ROI), em especial a sinalização de uma ROI à qual um certo tile_id/tile pertença. A mensagem poderia permitir dar à região de interesse Ids mais uma prioridade de uma região de interesse. A Fig. 18 ilustra a utilização de mosaicos na sinalização da região de interesse.

Para além do que tem sido descrito acima, a sinalização do cabeçalho de segmento poderá ser implementada. 0 prefixo de segmento da unidade NAL pode também conter o cabeçalho de segmento para os seguintes segmentos dependentes, ou seja, os segmentos prefixados pelo respetivo prefixo de segmento. Se o cabeçalho de segmento for apenas fornecido no prefixo de segmento da unidade NAL, o tipo de segmento atual precisa ser derivado pelo tipo de unidade NAL da unidade NAL contendo o respetivo segmento dependente ou através de uma bandeira na sinalização de prefixo de segmento se os seguintes dados de segmento pertencem a um tipo de segmento que serve como um ponto de acesso aleatório.

Além disso, o prefixo de segmento da unidade NAL pode transportar mensagens SEI especificas do segmento ou da imagem para transportar informação não obrigatória tal como instância da subimagem ou um identificador de mosaico. Mensagens especificas da subimagem não obrigatórias não são suportadas na especificação HEVC descrita na parte introdutória da especificação desta aplicação, mas é crucial para certas aplicações.

No que se segue, far-se-á a descrição da possível sintaxe para implementação do conceito da prefixação de segmentos anteriormente referido. Em especial, é descrito que alterações poderiam ser suficientes num nível de segmento aquando da utilização do estado HEVC tal como descrito na parte introdutória da especificação deste pedido como uma base.

Em especial, segue-se a apresentação de duas versões de uma possível sintaxe do prefixo de segmento, uma com uma funcionalidade da mensagem SEI apenas, e uma com a funcionalidade alargada de sinalização de uma parte do cabeçalho do segmento para os segmentos seguintes. A primeira sintaxe simples/versão 1 é ilustrada na Fig. 19.

Como uma nota preliminar, a Fig. 19 ilustra assim uma possível implementação para implementar quaisquer das forma de realização anteriormente descritas em relação às Figs. 11 a 16. Os pacotes intercalados aqui ilustrados podem ser construídos tal como ilustrados na Fig. 19, e de seguida tal é descrito com maior detalhe com exemplos específicos de implementação. A sintaxe alargada/versão 2, incluindo sinalização tile_id, identificador do início da unidade de descodificação, ID do prefixo de segmento e dados do cabeçalho de segmento para além do conceito de mensagem SEI, é dada na tabela da Fig. 20. A semântica poderá ser definida do seguinte modo: rap_flag com um valor de 1 indica que a unidade de acesso que contém o prefixo de segmento é uma imagem RAP. rap_flag com um valor de 0 indica que a unidade de acesso que contém o prefixo do segmento não é uma imagem RAP. decoding_unit_start_flag indica o inicio de uma unidade de descodificação numa unidade de acesso, assim que os segmentos seguintes até ao fim da unidade de acesso ou o inicio de outra unidade de descodificação pertencem à mesma unidade de descodificação. single_slice_flag com um valor de 0 indica que a informação fornecida no segmento de prefixo da unidade NAL e as respetivas mensagens SEI subimagem é válida para todas as unidades VCL-NAL seguintes até o início da próxima unidade de acesso, a ocorrência de outro prefixo de segmento ou de outro cabeçalho de segmento completo. single_slice_flag com um valor de 1 indica que toda a informação prevista no prefixo de segmento da unidade NAL e respetivas mensagens SEI subimagem é válida apenas para a próxima unidade VCL-NAL na sequência de descodificação. tile_idc indica a quantidade de mosaicos a estarem presentes no segmento seguinte. tile_idc igual a 0 indica que não são utilizados mosaicos no segmento seguinte. tile_idc igual a 1 indica que um único mosaico é utilizado no segmento seguinte e o seu identificador de segmento é assinalado conformemente. tile ide com um valor de 2 indica que múltiplos mosaicos são utilizados no seguinte segmento e o número de mosaicos e o primeiro identificador de mosaicos são assinalados conformemente. prefix_slice_header_data_present_flag indica que os dados do cabeçalho do segmento correspondentes aos segmentos seguintes na sequência de descodificação são assinalados no prefixo de segmento dado. slice_header_data() é mais tarde definido no texto. Contém informação do cabeçalho de segmento relevante, não abrangida pelo cabeçalho do segmento, se dependent_slice_flag for fixado igual a 1.

De salientar que a desassociação do cabeçalho de segmento e dados de segmento atual permite esquemas de transmissão mais flexíveis do cabeçalho e dos dados de segmento. num_tiles_in_prefixed_slices_minusl indica o número de mosaicos utilizados na seguinte unidade de descodificação menos 1. first_tile_id_in_prefixed_slices indica o identificador de mosaicos do primeiro mosaico na seguinte unidade de descodificação.

Para a sintaxe simples/versão 1 do prefixo de segmento, os elementos de sintaxe seguintes podem ser fixados para valores por defeito do seguinte modo, caso não se encontrem presentes: - decoding_unit_start igual a 1, ou seja, o prefixo de segmento indica sempre um início de uma unidade de descodificação. - single_slice_flag igual a 0, ou seja, o prefixo de segmento é válido para todos os segmentos na unidade de descodificação. O prefixo de segmento da unidade NAL é proposto ter um tipo de unidade NAL de 24 e a tabela de síntese do tipo de unidade NAL a ser alargado de acordo com a Fig. 21.

Ou seja, resumindo sucintamente as Figs. 19 a 21, os detalhes de síntese aqui ilustrados revelam que um certo tipo de pacote pode ser atribuído aos pacotes intercalados identificados acima, aqui o exemplo da unidade NAL do tipo 24. Além disso, em especial o exemplo de sintaxe da Fig. 20 torna claro que as alternativas descritas acima relativas ao "âmbito" dos pacotes intercalados, um mecanismo de comutação controlado por um respetivo elemento de sintaxe nestes próprios pacotes intercalados, aqui como exemplo single_slice_flag, podem ser utilizadas de modo a controlarem este âmbito, ou seja, a trocá-los entre diferentes alternativas para a definição deste âmbito, respetivamente. Além disso, foi tornado claro que as formas de realização descritas acima das Figs. 1 a 16 podem estender-se na medida em que os pacotes intercalados também compreendem dados de cabeçalho de segmento comuns para segmentos 24 contidos nos pacotes pertencentes ao "âmbito" dos respetivos pacotes intercalados. Ou seja, poderá existir um mecanismo controlado por uma bandeira de sinalização respetiva nestes pacotes intercalados, que indica se os dados de cabeçalho de segmento comuns constam do respetivo pacote intercalado ou não. É claro que o conceito agora apresentado de acordo com o qual parte dos dados do cabeçalho do segmento é deslocada para o prefixo do cabeçalho do segmento, exige alterações aos cabeçalhos do segmento tal como especificado na versão HEVC atual. A tabela na Fig. 22 ilustra uma possível sintaxe para esse tipo de cabeçalho do segmento, em que certos elementos de sintaxe no cabeçalho do segmento de acordo com a versão atual, são deslocados para um elemento de sintaxe hierarquicamente inferior, referido como slice_header_data () . Esta sintaxe do cabeçalho do segmento e os dados do cabeçalho do segmento aplica-se apenas à opção de acordo com a qual o prefixo do cabeçalho do segmento alargado do conceito de unidade NAL é utilizado.

Na Fig. 22, slice_header_data_present_flag indica que dados do cabeçalho do segmento para este segmento deverão ser previstos dos valores assinalados no último prefixo de segmento da unidade NAL na unidade de acesso, isto é, o prefixo do segmento da unidade NAL ocorrido mais recentemente.

Todos os elementos de sintaxe removidos do cabeçalho do segmento são assinalados através dos dados do cabeçalho do segmento do elemento de sintaxe tal como dado na tabela da Fig. 23.

Ou seja, transferir o conceito da Fig. 22 e Fig. 23 nas formas de realização das Figs. 12 a 16, os pacotes intercalados aqui descritos podem ser abrangidos pelo conceito de incorporação nestes pacotes intercalados, uma parte da sintaxe do cabeçalho do segmento dos segmentos (subpartes) 24 codificados em pacotes de carga útil, ou seja, unidades VCL NAL. A incorporação pode ser opcional. Ou seja, um respetivo elemento de sintaxe no pacote intercalado pode indicar se tal sintaxe do cabeçalho de segmento está contida no respetivo pacote intercalado ou não. Se estiver incorporada, os respetivos dados do cabeçalho do segmento incorporados no respetivo pacote intercalado podem aplicar-se a todos os segmentos contidos no pacote pertencentes ao "âmbito" do respetivo pacote intercalado. Se os dados do cabeçalho do segmento contidos num pacote intercalado forem adotados por um segmento codificado em quaisquer dos pacotes de carga útil pertencentes ao âmbito deste pacote intercalado, podem ser assinalados por uma bandeira respetiva, tal como slice header_data_present_flag da Fig. 22. Através desta medida, os cabeçalhos do segmento dos segmentos codificados nos pacotes pertencentes ao "âmbito" de um respetivo pacote intercalado podem ser tornados mais pequenos conformemente utilizando a bandeira agora mencionada nos segmentos do cabeçalho do segmento e qualquer descodificador que recebe o fluxo de dados de video, tal como as entidades de rede ilustradas nas Figs. 12 a 16 acima, seriam recetivos à bandeira agora mencionada nos segmentos do cabeçalho do segmento de modo a copiar os dados do cabeçalho do segmento incorporados num pacote intercalado no cabeçalho do segmento de um segmento codificado num pacote de carga útil pertencente ao âmbito deste pacote intercalado no caso da respetiva bandeira dentro desse segmento assinalar o deslocamento dos dados do cabeçalho do segmento para o prefixo do segmento, ou seja, o respetivo pacote intercalado.

Avançando ainda com o exemplo de sintaxe para implementação das formas de realização das Figs. 12 a 16, a sintaxe da mensagem SEI pode ser como ilustrada na Fig. 24. De modo a introduzir tipos de mensagens SEI de segmento ou subimagem, a sintaxe de carga útil SEI pode ser adaptada tal como apresentada na tabela da Fig. 25. Apenas a mensagem SEI com "payloadType" na ordem dos 180 a 184 pode ser enviada exclusivamente ao nivel da subimagem na unidade de prefixo de segmento NAL. Além disso, as mensagens SEI da região de interesse com "payloadType" igual a 140 podem ser enviadas na unidade do prefixo de segmento NAL ao nivel da subimagem, ou a mensagem SEI regular no nivel da unidade de acesso.

Ou seja, na transferência dos detalhes ilustrados nas Figs. 25 e 24 nas formas de realização descritas acima em relação às Figs. 12 a 16, os pacotes intercalados ilustrados nestas formas de realização das Figs. 12 a 16 podem ser executados através das unidades do prefixo de segmento NAL com um certo tipo de unidade NAL, por exemplo 24, compreendendo um certo tipo de mensagem SEI assinalado por "payloadType" no inicio de cada mensagem SEI na unidade do prefixo de segmento NAL, por exemplo. Na forma de realização de sintaxe especifica agora descrita, "payloadType" = 180 e "payloadType" = 181 resulta num pacote de controlo do tempo de acordo com as formas de realização das Figs. 11 a 14, enquanto "payloadType" = 140 resulta num pacote ROI de acordo com a forma de realização da Fig. 15, e "payloadType" = 182 resulta num pacote de identificação do mosaico de acordo com a forma de realização da Fig. 16. O exemplo de sintaxe especifico aqui descrito pode compreender apenas um ou um subconjunto das opções "payloadType" agora mencionadas. Para além disso, a Fig. 25 revela que qualquer uma das forma de realização das Figs. 11 a 16 descritas acima pode ser combinado um com o outro. Mais ainda, a Fig. 25 revela que qualquer uma das forma de realização anteriores das Figs. 12 a 16, ou qualquer uma das suas combinações, pode ser alargado por um pacote intercalado adicional, posteriormente explicado com "payloadType" = 184. Tal como já descrito acima, um alargamento descrito em baixo relativo ao "payloadType" = 183 termina na possibilidade de que quaisquer pacotes intercalados podem ter incorporados dados do cabeçalho de segmento comuns para cabeçalhos de segmento de segmentos codificados em qualquer pacote de carga útil pertencente ao seu âmbito.

As tabelas nas figuras que se seguem definem mensagens SEI que podem ser utilizadas ao nivel do segmento ou da subimagem. Uma mensagem SEI da região de interesse é também apresentada podendo ser utilizada na subimagem e ao nível da unidade de acesso. A Fig. 26, por exemplo, ilustra um exemplo para uma mensagem SEI da instância da subimagem que ocorre sempre que uma unidade NAL do prefixo de segmento da unidade NAL do tipo 24 possui uma mensagem SEI do tipo 180 aqui contida, formando assim um pacote de controlo do tempo. A semântica deverá ser definida do seguinte modo: seçL_parameter_set_id especifica o conjunto de parâmetros de sequência que contém os atributos da sequência HRD. O valor de seq_parameter_set_id deverá ser igual ao valor de seq_parameter_set_id no conjunto de parâmetros da imagem referenciado pela primeira imagem codificada com a mensagem SEI do período de buffering. O valor de seq_parameter_set_id deverá ser da ordem de 0 a 31, inclusive. initial_cpb_removal_delay [ SchedSelIdx ] e initial_alt_cpb_removal_delay[ SchedSellDx ] especificam os atrasos de remoção CPB iniciais para o SchedSelldx-th CPB da unidade de descodificação (a subimagem). Os elementos de sintaxe são dotados de um comprimento em bits dado por initial_cpb_removal_delay_length_minusl + 1, e encontram-se em unidades de um relógio de 90 kHz. Os valores dos elementos de sintaxe não deverão ser iguais a 0 e não deverão exceder 90000 * ( CpbSize[ SchedSelIdx ] + BitRate[ SchedSelIdx ] ), o equivalente a tempo das dimensões CPB em unidades de relógio de 90 kHz.

Em toda a sequência de video codificada, a soma de initial_cpb_removal_delay[ SchedSelIdx ] e initial_cpb_removal_delay_offset[ SchedSelIdx ] por unidade de descodificação (subimagem) deverá ser constante para cada valor de SchedSelIdx, e a soma de initial_alt_cpb_removal_delay[ SchedSelIdx ] e initial_cpb_removal_delay_offset[ SchedSelIdx ] deverá ser constante para cada valor de SchedSelIdx. A Fig. 27 ilustra da mesma forma um exemplo para uma mensagem SEI do tempo de subimagem, em que a semântica pode ser descrita do seguinte modo: du_cpb_removal_delay especifica quantos tiques de relógio se deve esperar após a remoção do CPB da unidade de descodificação (subimagem) associada à mensagem SEI do período de registo de subimagem numa unidade de acesso anterior na mesma unidade de descodificação (subimagem), caso exista, de outro modo associada à mensagem SEI do período de buffering mais recente numa unidade de acesso anterior, antes da remoção do registo dos dados (subimagem) da unidade de descodificação associados à mensagem SEI do registo de imagem. Este valor é também utilizado para calcular um tempo de chegada mais cedo possível de dados da unidade de descodificação (subimagem) para o CPB para o HSS (Programador de Fluxo Hipotético [2]0) . 0 elemento de sintaxe é um código de comprimento fixo cujo comprimento em bits é dado por cpb_removal_delay_length_minusl +1. 0 cpb_removal_delay é o restante de um contador módulo 2 (opb-removal-delay-length-minusl + 1} . du_cpb_removal_delay é utilizado para calcular o tempo de saída DPB da unidade de descodificação (subimagem). Especifica quantos tiques de relógio se deve esperar após a remoção da unidade de descodificação descodificada (subimagem) do CPB antes de a unidade de descodificação (subimagem) da imagem sair do DPB.

De salientar que tal permite atualizações de subimagens. Num cenário destes, as unidades de descodificação não atualizadas podem manter-se inalteradas da última imagem descodificada, ou seja, elas mantêm-se visíveis.

Resumindo as Figs. 26 e 27, e transferindo os detalhes específicos aí contidos na forma de realização das Figs. 12 a 14, poder-se-á dizer que o tempo de pesquisa do registo do descodificador para uma unidade de descodificação pode ser assinalado no respetivo pacote de controlo do tempo de maneira codificada diferencial, nomeadamente incrementalmente relativo a outro tempo de pesquisa do registo descodifiçado. Ou seja, de modo a obter o tempo de pesquisa do registo do descodificador para uma certa unidade de descodificação, um descodificador que recebe o fluxo de dados de video adiciona ao descodificador tempo de pesquisa obtido do pacote de controlo do tempo que prefixa a certa unidade de descodificação, para o tempo de pesquisa do descodificador da unidade de descodificação imediatamente anterior, ou seja, a uma certa unidade de descodificação anterior, e prosseguindo deste modo com as unidades de descodificação seguintes. Nos inícios das sequências de vídeo codificadas de várias imagens cada ou de partes destas, um pacote de controlo do tempo pode adicionalmente ou alternativamente compreender um valor do tempo de pesquisa do registo do descodificador absolutamente codificado em vez de diferencialmente relativo a qualquer tempo de pesquisa do registo da unidade de descodificação. A Fig. 28 ilustra que aparência poderá ter a mensagem SEI de informação de segmento de subimagem. A semântica pode ser definida do seguinte modo: slice_header_data_flag com um valor de 1 indica que os dados do cabeçalho do segmento encontram-se presentes na mensagem SEI. Os dados do cabeçalho do segmento fornecidos na SEI são válidos para todos os segmentos que se seguem na sequência de descodificação até ao fim da unidade de acesso, a ocorrência dos dados do segmento noutra mensagem SEI, unidade de segmento NAL ou unidade de prefixo de segmento NAL. A Fig. 29 ilustra um exemplo para uma mensagem SEI de informação do mosaico subimagem, em que a semântica poderá ser definida do seguinte modo: tile_priority indica a prioridade de todos os mosaicos nos segmentos prefixados seguidos na sequência de descodificação. 0 valor do tile_priority deverá ser na ordem de 0 a 7 inclusivamente, sendo que 7 indica a prioridade mais elevada. multiple_tiles_in_prefixed_slices_flag com um valor de 1 indica que existem mais do que um mosaico nos segmentos prefixados para seguirem na sequência de descodificação. multiple_tiles_in_prefixed_slices_flag com um valor de 0 indica que os segmentos prefixados seguintes contêm apenas um mosaico. num_tiles_in_prefixed_slices_minusl indica o número de mosaicos nos segmentos prefixados que seguem na sequência de descodificação. first tile_id_in_prefixed_slices indica o tile_id do primeiro mosaico nos segmentos prefixados que seguem na sequência de descodificação.

Ou seja, a forma de realização da Fig. 16 poderá ser implementada utilizando a sintaxe da Fig. 29 para execução dos pacotes de identificação de mosaicos mencionados na Fig. 16. Tal como aqui ilustrado, uma certa bandeira, aqui multiple_tiles_in_prefixed_slices_flag, pode ser utilizada para assinalar no pacote de identificação de mosaico intercalado se apenas um mosaico ou mais de um mosaico é abrangido por qualquer subparte da imagem atual 18 codificada em qualquer um dos pacotes de carga útil pertencentes ao âmbito do respetivo pacote de identificação de mosaico intercalado. Se a bandeira assinalar a sobreposição de mais de um mosaico, um elemento de sintaxe adicional é contido no respetivo pacote intercalado, aqui como exemplo num_tiles_in_prefixed_slices_minusl indicando o número de mosaicos sobrepostos por qualquer subparte de qualquer pacote de carga útil pertencente ao âmbito do respeito pacote de identificação de mosaico intercalado. Finalmente, um elemento de sintaxe adicional, aqui exemplificativamente first_tile_id in_prefixed_slices, indica a ID do mosaico entre um número de mosaicos indicados pelo pacote de identificação de mosaicos intercalados, o primeiro de acordo com na sequência de descodificação. Ao transferir a sintaxe da Fig. 29 para a forma de realização da Fig. 16, o pacote de identificação de mosaicos 72 que prefixa o quinto pacote de carga útil 32 poderia, por exemplo, ter todos os três elementos de sintaxe agora discutidos com multiple_tiles_in_prefixed_slices_flag fixados em 1, num tiles in prefixed_slices_minusl fixado em 1, indicando assim que os dois mosaicos pertencem ao âmbito atual, e first_tile_id_in_prefixed_slices fixado em 3, indicando que a execução de mosaicos na sequência de descodificação pertencente ao âmbito do pacote de identificação de mosaicos atual 72 inicia-se no terceiro mosaico (com tile_id = 2). A Fig. 29 revela também que um pacote de identificação de mosaicos 72 pode possivelmente indicar também um tile_priority, ou seja, uma prioridade dos mosaicos pertencentes ao seu âmbito.

Do mesmo modo que no aspeto ROI, a entidade de rede 68 pode utilizar essa informação de prioridade para controlar tarefas de transmissão tais como o pedido para retransmissões de certos pacotes de carga útil. A Fig. 30 ilustra um exemplo de sintaxe para uma mensagem SEI de informação de dimensão do mosaico subimagem, sendo que a semântica poderia ser definida como: multiple_tiles_in_prefixed_slices_flag com um valor de 1 indica que existem mais do que um mosaico nos mosaicos prefixados para seguirem na sequência de descodificação. multiple_tiles_in_prefixed_slices_flag com um valor de 0 indica que os segmentos prefixados seguintes contêm apenas um mosaico. num_tiles_in_j?refixed_slices_minusl indica o número de mosaicos nos segmentos prefixados que seguem na sequência de descodificação. tile_horz_start[ i ] indica o início na direção horizontal do i-ésimo mosaico em pixéis na imagem. tile_width[ i ] indica a largura do i-ésimo mosaico em pixéis na imagem. tile_vert_start[ i ] indica o início na direção horizontal do i-ésimo mosaico em pixéis na imagem. tile_height[ i ] indica a altura do i-ésimo mosaico em pixéis na imagem.

De salientar que a mensagem SEI de dimensões do mosaico pode ser utilizada em operações de apresentação, por exemplo, para atribuição de um mosaico a um ecrã em cenários de apresentação em múltiplos ecrãs. A Fig. 30 revela assim que o exemplo de sintaxe de implementação da Fig. 29 relativos aos pacotes de identificação de mosaicos da Fig. 16 pode variar na medida em que os mosaicos pertencentes ao âmbito do respetivo pacote de identificação de mosaicos são indicados pela sua localização na imagem atual 18 e não pela sua ID de mosaico. Ou seja, em vez de sinalização a ID do mosaico do primeiro mosaico na sequência de descodificação abrangido pelas respetivas subpartes codificadas em qualquer pacote de carga útil pertencente ao âmbito do respetivo pacote de identificação do mosaico intercalado, para cada mosaico pertencente ao pacote de identificação de mosaicos atual, a sua posição poderá ser assinalada pela sinalização, por exemplo, da posição do canto superior esquerdo de cada mosaico i, aqui exemplificativamente tile horz start e tile_vert_start, e a largura e altura do mosaico i, aqui exemplificativamente pelo tile_width e tile_height.

Um exemplo de sintaxe para uma mensagem SEI da região de interesse encontra-se ilustrado na Fig. 31. Para se ser ainda mais preciso, a Fig. 32 ilustra uma primeira variante. Em especial, a mensagem SEI da região de interesse pode, por exemplo, ser utilizada ao nível da unidade de acesso ou ao nivel da subimagem para assinalar uma ou mais regiões de interesse. De acordo com a primeira variante da Fig. 32, uma ROI individual é assinalada uma vez por cada mensagem SEI ROI, em vez de sinalizar todas as ROIs do respetivo âmbito do pacote ROI numa mensagem SEI ROI se múltiplas ROIs se encontrarem no âmbito atual.

De acordo com a Fig. 31, a mensagem SEI da região de interesse assinala cada ROI individualmente. A semântica poderia ser definida do seguinte modo: roi_id indica o identificador da região de interesse. roi_priority indica a prioridade de todos os mosaicos gue pertencem à região de interesse nos segmentos prefixados ou todos os segmentos que seguem na sequência de descodificação dependendo se a mensagem SEI é enviada ao nivel subimagem ou ao nível da unidade de acesso. 0 valor de roi_priority deverá ser da ordem de 0 a 7 inclusivamente, sendo que 7 indica a prioridade mais elevada. Se ambas, roi_priority na mensagem SEI de informação roi e tile_priority nas mensagens SEI de informação mosaico de subimagem forem dadas, o valor mais elevado de ambas é válido para a prioridade dos mosaicos individuais. num_tiles_in_roi_minusl indica o número de mosaicos nos segmentos prefixados que seguem na sequência de descodificação que pertence à região de interesse. roi tile id[ i ] indica o tile_id do i-ésimo mosaico que pertence à região de interesse nos segmentos prefixados que seguem na sequência de descodificação.

Ou seja, a Fig. 31 ilustra que um pacote ROI tal como ilustrado na fig. 15 poderia assinalar ai uma ID da região de interesse à qual se referem o respetivo pacote ROI e o pacote de carga útil pertencente ao seu âmbito. Opcionalmente, um índice de prioridade ROI pode ser assinalado juntamente com a ID ROI. Contudo, ambos os elementos de sintaxe são opcionais. Depois, um elemento de sintaxe num_tiles_in_roi_minusl pode indicar o número de mosaicos no âmbito do respetivo pacote ROI pertencente à respetiva ROI 60. Depois, roi_tile_id indica a ID do mosaico dos i-ésimos mosaicos pertencentes à ROI 60. Imagine-se, por exemplo, que a imagem 18 seria subdividida em mosaicos 70 do modo ilustrado na Fig. 16, e que a ROI 60 da Fig. 15 iria corresponder à metade do verso da imagem 18, seria formada pelo primeiro e pelo terceiro e pelo terceiro mosaicos em sequência de descodificação. Depois, um pacote ROI poderia ser colocado em frente do primeiro pacote de carga útil 32 da unidade de acesso na fig. 16, seguida por um pacote ROI adicional entre o quarto e o quinto pacote de carga útil 32 desta unidade de acesso 30. Depois, o primeiro pacote ROI teria num_tile_in_roi_minusl fixado em 0 com roi_tile_id[0] sendo 0 (referindo-se pois ao primeiro mosaico na sequência de descodificação), em que o segundo pacote ROI em frente do quinto pacote de carga útil 32 teria num tils in_roi_minusl fixado em 0 com roi_tile_id[0] fixado em 2 (denotando assim o terceiro mosaico na sequência de descodificação na quarta parte inferior esquerda da imagem 18).

De acordo com a segunda variante, a sintaxe de uma mensagem SEI da região de interesse poderia ser a ilustrada na fig. 32. Aqui, todas as ROIs numa única mensagem SEI são assinaladas. Em especial, a mesma sintaxe tal como discutido anteriormente em relação à Fig. 31 seria utilizada, mas multiplicando os elementos de sintaxe para cada ROIs de um número de ROIs à qual a respetiva mensagem SEI ROI ou pacote ROI se refere, com um número assinalado por um elemento de sintaxe, aqui exemplificativamente num_rois_minusl. Opcionalmente, um elemento de sintaxe adicional, aqui exemplificativamente roi_presentation_on_separate_screen, poderia sinalizar para cada ROI caso a respetiva ROI seja adequada para ser apresentada num ecrã em separado. A semântica poderia ser a seguinte: num_rois_minusl indica o número de ROIs nos segmentos prefixados ou segmentos regulares que seguem na sequência de descodificação. roi_id[ i ] indica o identificador do i-ésima região de interesse. roi_priority[ i ] indica a prioridade de todos os mosaicos que pertencem à i-ésima região de interesse nos segmentos prefixados ou todos os segmentos que seguem na sequência de descodificação dependendo se a mensagem SEI é enviada ao nivel de subimagem ou ao nivel da unidade de acesso. 0 valor de roi_priority deverá ser da ordem dos 0 a 7 inclusivamente, sendo que 7 indica a prioridade mais elevada. Se ambas, roi_priority na mensagem SEI roi_info e tile_priority nas mensagens SEI de informação do mosaico de subimagem forem dadas, o valor mais elevado de ambas é válido para a prioridade dos mosaicos individuais. num_tiles_in_roi_ininusl [ i ] indica o número de mosaicos nos segmentos prefixados que seguem na sequência de descodificação que pertencem à i-ésima região de interesse. roi_tile_id[ i ][ n ] indica o tile_id do n mosaico que pertence à i-ésima região de interesse nos segmentos prefixados que seguem na sequência de descodificação. roi_presentation_on_sperate_screen [ i ] indica que a região de interesse, associada ao i-ésimo roi_id é adequada para apresentação num ecrã em separado.

Assim, resumindo rapidamente as várias formas de realização descritas até ao momento, uma estratégia de sinalização de sintaxe de alto nível adicional tem sido apresentada que permite aplicar mensagens SEI assim como itens de sintaxe de alto nível adicionais para além daqueles incluídos no cabeçalho da unidade NAL a um nível por segmento. Desse modo, descrevemos a unidade de prefixo de segmento NAL. A sintaxe e a semântica do prefixo de segmento e das mensagens SEI slice_level/subimagem têm sido descritas juntamente com casos de utilização para operações de baixo atraso/subimagem CPB, sinalização de mosaicos e sinalização de ROI. Uma sintaxe alargada tem sido apresentada para sinalizar parte do cabeçalho de segmento dos seguintes segmentos adicionalmente no prefixo de segmento.

Para se ser exaustivo, a fig. 33 ilustra um exemplo adicional para uma sintaxe que pode ser utilizada para um pacote de controlo do tempo de acordo com a forma de realização das Figs. 12 a 14. A semântica poderia ser a seguinte: du spt cpb removal delay_increment especifica a duração, em unidades de subtiques de relógio, entre os tempos CPB nominais da última unidade de descodificação na sequência de descodificação na unidade de acesso atual e a unidade de descodificação associada à mensagem SEI de informação da unidade de descodificação. Este valor é também utilizado para calcular o tempo mais cedo possível de chegada de dados da unidade de descodificação no CPB para o HSS, tal como especificado no Anexo C. 0 elemento de sintaxe é representado por um código de comprimento fixo cujo comprimento em bits é dado por du_cpb_removal_delay_increment_length_minusl + 1. Quando a unidade de descodificação associada à mensagem SEI de informação da unidade de descodificação é a última unidade de descodificação na unidade de acesso atual, o valor de du_spt_cpb_removal_delay_increment deverá ser igual a 0. dpb_output_d.u_delay_present_flag igual a 1 especifica a presença do elemento de sintaxe pic_spt_dpb_output_du_delay na mensagem SEI de informação da unidade de descodificação. dpb_output_du_delay_present_flag igual a 0 especifica a ausência do elemento de sintaxe pic_spt_dpb_output_du_delay na mensagem SEI de informação da unidade de descodificação.

pic_spt_dpb_output_du_delay é utilizado para calcular o tempo de saída DPB da imagem quando SubPicHrdFlag é igual a 1. Especifica quantos subtiques de relógio deve aguardar após remoção da última unidade de descodificação numa unidade de acesso do CPB antes da imagem descodificada sair do DPB. Quando não se encontra presente, o valor de pic_spt_dpb_output_du_delay é considerado como sendo igual a pic_dpb_output_du_delay. 0 comprimento do elemento de sintaxe pic_spt_dpb_output_du_delay é dado em bits por dpb_output_delay_du_length minusl + 1. É um reguisito de conformidade do fluxo de bits que todas as mensagens SEI de informação da unidade de descodificação, à qual se encontram associadas com a mesma unidade de acesso, se aplicam ao mesmo ponto de operação, e têm dpb_output_du_delay_present_flag igual a 1 devem ter o mesmo valor de pic_spt_dpb_output_du_delay. 0 tempo de saida derivado do pic_spt_dpb_output_du_delay de qualquer imagem que sai do descodificador de conformidade do tempo de saida deverá preceder ao tempo de saida derivado de pic_spt_dpb_output_du_delay de todas as imagens em quaisquer CVS posteriores na sequência de descodificação. A sequência de saida da imagem estabelecida pelos valores deste elemento de sintaxe deve ser a mesma sequência estabelecida pelos valores de PicOrderCntVal.

Para imagens que não saem pelo processo "bumping" porque precedem, na sequência de descodificação, uma imagem IRAP com NoRaslOutputFlag igual a 1 tem um no_output_of_prior_pics_flag igual a 1 ou considerado como sendo igual a 1, os tempos de saida derivados de pic_spt_dpb_output_du_delay devem ser progressivos com valor crescente de PicOrderCntVal em relação a todas as imagens no mesmo CVS. Para quaisquer duas imagens no CVS, a diferença entre os tempos de saida das duas imagens quando SubPicHrdFlag é igual a 1 deverá ser idêntica à mesma diferença quando SubPicHrdFlag é igual a 0.

Ainda, a Fig. 34 ilustra um exemplo adicional para sinalizar uma região ROI utilizando pacotes ROI. De acordo com a Fig. 34, a sintaxe de um pacote ROI compreende apenas uma bandeira indicando se todas as subpartes da imagem 18 codificadas em qualquer pacote de carga útil 32 pertencentes ao seu âmbito pertencem à ROI ou não. O "âmbito" estende-se até à ocorrência do pacote ROI ou mensagem regio_refresh_info. Se a bandeira for 1, a região é indicada como sendo codificada no respetivo pacote (s) de carga útil posterior, e se for 0 o oposto aplica-se, ou seja, as respetivas subpartes da imagem 18 não pertencem à ROI 60.

Antes de se discutir novamente algumas das formas de realização acima por outras palavras com explicação adicional de alguns termos utilizados acima tais como mosaico, segmento e subdivisão de subfluxos WPP, deverá denotar-se que a sinalização de Alto Nivel das formas de realização acima podem alternativamente ser definidos em especificações de transporte tais como [3-7]. Por outras palavras, os pacotes mencionados acima e que formam a sequência 34 podem ser pacotes de transporte alguns dos quais possuem as subpartes do nivel de aplicação tais como segmentos, incorporados, tais como "embalados" na totalidade ou fragmentados, neles próprios, alguns intercalados entre o último da maneira, e com o objetivo, discutido anteriormente. Por outras palavras, os pacotes intercalados mencionados acima não estão limitados a ser definidos como mensagens SEI ou outros tipos de unidades NAL, definidos no codec de video do nivel de aplicação, mas podem alternativamente ser pacote de transporte extra definido nos protocolos de transporte.

Por outras palavras, de acordo com um aspeto da presente especificação, as formas de realização anteriores revelaram um fluxo de dados de video dotado nelas próprias de um conteúdo de video codificado em unidades de subpartes (ver blocos de árvores codificadas ou segmentos) de imagens do conteúdo de video, cada subparte respetivamente codificada num ou mais pacotes de carga útil (ver unidades VCL NAL) de uma sequência de pacotes (unidades NAL) do fluxo de dados de video, a sequência de pacotes sendo dividida numa sequência de unidades de acesso de modo que cada unidade de acesso recolhe os pacotes de carga útil relativos a uma respetiva imagem do conteúdo de video, em que a sequência de pacotes é dotada nela de pacotes de controlo do tempo (prefixo de segmento) de modo que os pacotes de controlo do tempo subdividem as unidades de acesso em unidades de descodificação de modo que pelo menos algumas unidades de acesso sejam subdivididas em duas ou mais unidades de descodificação, com cada pacote de controlo do tempo sinalizando um tempo de pesquisa do registo do descodificador para uma unidade de descodificação, os pacotes de carga útil dos quais seguem o respetivo pacote de controlo do tempo na sequência de pacotes.

Tal como descrito acima, o domínio relativo ao qual o conteúdo de vídeo é codificado no fluxo de dados em unidades de subpartes de imagens, pode abranger os elementos de sintaxe relativos à codificação preditiva tal como modos de codificação (tais como intra-modo, inter-modo, informação de subdivisão e outro idêntico), parâmetros de predição (tais como vetores de movimento, direções de extrapolação ou outro idêntico) e/ou dados residuais (tais como níveis de coeficiente de transformação, com estes elementos de sintaxe associados às partes locais da imagem tais como blocos de árvore de codificação, blocos de predição e blocos residuais (tais como de transformação), respetivamente.

Tal como descrito acima, os pacotes de carga útil podem, cada um, abranger um ou mais segmentos (na totalidade, respetivamente). Os segmentos podem ser independentemente descodificáveis ou podem demonstrar inter-relações que colocam em causa uma sua descodificação independente. Por exemplo, segmentos de entropia podem ser independentemente descodificáveis de entropia, mas a predição para além dos limites do segmento pode não ser permitida. Segmentos dependentes podem permitir o processamento WPP, ou seja, codificação/descodificação utilizando codificação de entropia e de predição para além dos limites do segmento com a capacidade de paralelamente codificar/descodificar os segmentos dependentes com sobreposição no tempo com, apesar disso, um início inconstante do procedimento de codificação/descodificação dos segmentos dependentes individuais e o segmento/segmentos referidos pelos segmentos dependentes. A ordem sequencial na qual os pacotes de carga útil de uma unidade de acesso se encontram dispostos na respetiva unidade de acesso pode ser conhecida pelo descodificador com antecedência. Por exemplo, uma sequência de codificação/descodificação pode ser definida entre as subpartes das imagens tais como a ordem de digitalização entre os blocos de árvores de codificação nos exemplos anteriores.

Ver, por exemplo, a figura em baixo. Uma imagem codificada/descodifiçada atual 100 pode ser dividida em mosaicos que, nas Figs. 35 e 36, por exemplo, correspondem exemplificativamente aos quatro quadrantes da imagem 110 e são indicados com sinais de referência 112a-112d. Ou seja, toda a imagem 110 pode formar um mosaico tal como no caso da Fig. 37 ou pode ser segmentada em mais do que um mosaico. A segmentação de mosaicos pode ser restrita a mosaicos regulares nos quais os mosaicos se encontram dispostos em colunas e linhas apenas. Diferentes exemplos são apresentados em baixo.

Tal como se pode observar, a imagem 110 é ainda subdividida em blocos (de árvores) de codificação (pequenas caixas na figura e designadas CTB acima) 114 entre os quais um sequência de codificação 116 é definida (aqui, sequência de análise por varrimento, mas pode também ser diferente) . A subdivisão da imagem em mosaicos 112a-d pode ser restrita de modo que os mosaicos são conjuntos não contíguos de blocos 114. Adicionalmente, os blocos 114 e os mosaicos 112a-d podem ambos ser restritos a um arranjo regular em colunas e linhas.

Se os mosaicos (isto é, mais do que um) estiverem presentes, então a análise da sequência de (des)codificação 116 por varrimento verifica um primeiro mosaico completo primeiro após o qual transitando, também numa sequência de análise por varrimento de mosaico, ao próximo mosaico na sequência do mosaico.

Como os mosaicos são codificáveis/descodifiçáveis independentemente um do outro devido ao não-cruzamento dos limites do mosaico por predições espaciais e seleções de contexto consideradas de proximidade espacial, o codificador 10 e o descodificador 12 podem codificar/descodificar uma imagem subdividida em mosaicos 112 (anteriormente indicados por 70), em paralelo, independentes um do outro, exceto, por exemplo, um retorno ou pós-filtragem que pode ser permitida para atravessar limites de mosaicos. A imagem 110 pode ainda ser subdividida em mosaicos 118a-d, 180, anteriormente indicados utilizando o sinal de referência 24. Um segmento pode conter apenas uma parte de um mosaico, um mosaico completo ou mais do que um mosaico completo. Desse modo, a divisão em segmentos pode também subdividir mosaicos tal como no caso da Fig. 35. Cada mosaico compreende pelo menos um bloco de codificação 114 em completo e é constituído por consecutivos blocos de codificação 114 na sequência de codificação 116 de modo que uma sequência seja definida entre os segmentos 118a-d a seguir aos quais os índices na figura foram atribuídos. A divisão de segmentos nas Figs. 35 a 37 foi selecionada para fins ilustrativos apenas. Os limites do mosaico podem estar sinalizados no fluxo de dados. A imagem 110 pode formar um único mosaico tal como descrito na Fig. 37. O codificador 10 e o descodificador 12 podem ser configurados para obedecer aos limites dos mosaicos na medida em que a predição espacial não é aplicada pelos limites do mosaico. A adaptação do contexto, isto é, as adaptações de probabilidade dos vários contextos de entropia (aritmética) pode continuar sobre segmentos completos. Contudo, sempre que um segmento atravessa, ao longo de uma sequência de codificação 116, um limite do mosaico (se presente no interior de um segmento) tal como na Fig. 36 relativo aos segmentos 118a,b, então o segmento é, por sua vez, subdividido em subsecções (subfluxos ou mosaicos) com o segmento compreendendo ponteiros (c.p. entry point offset) apontando para os inícios de cada subsecção. No laço de descodificador podem ser permitidos filtros para atravessar limites de mosaicos. Tais filtros podem envolver um ou mais de um filtro de desbloqueio, um filtro de Amostra Adaptável de Compensação (SAO) e um filtro de laço adaptável (ALF). Este último pode ser aplicado sobre os limites do mosaico/segmento de ativado.

Cada segunda e seguintes subsecções opcionais podem ter o seu início colocado de forma a estar alinhado em bytes no segmento com o ponteiro indicando o desvio do início de uma subsecção para o início da próxima subsecção. As subsecções encontram-se dispostas em segmentos na sequência de verificação 116. A Fig. 38 ilustra um exemplo de um segmento 180c da Fig. 37 exemplificativamente subdividido em subsecções 119ι.

Em relação a estas figuras poder observar-se que os segmentos que formam subpartes de mosaicos não têm de terminar com a fila no mosaico 112a. Ver, por exemplo, o segmento 118a nas Figs. 37 e 38. A Figura abaixo ilustra uma parte exemplificativa de um fluxo de dados relativo a uma unidade de acesso associada à imagem 110 da imagem da Fig. 38 acima. Aqui, cada pacote de carga útil 112a-d, anteriormente indicado pelo sinal de referência 32, aloja exemplificativamente apenas um segmento 118a. Dois pacotes de controlo do tempo 124a,b, anteriormente indicados pelo sinal de referência 36, são ilustrados como sendo intercalados na unidade de acesso 120 para fins ilustrativos: 124a precede o pacote 122a na sequência do pacote 126 (correspondendo à constante de tempo de de/codificação) e 124b precede o pacote 122c. Por conseguinte, a unidade de acesso 120 é dividida em duas unidades de descodificação 128a,b, anteriormente indicadas pelo sinal de referência 38-, o primeiro dos quais compreende os pacotes 122a,b (juntamente com pacotes de dados de preenchimento opcionais (sucedendo aos primeiros e segundos pacotes 122a,b, respetivamente) e unidade de acesso opcional conduzindo aos pacotes SEI (precedendo o primeiro pacote 122a)) e o segundo dos quais compreende os pacotes 118c,d (juntamente com pacotes de dados de preenchimento opcional (sucedendo aos pacotes 122c,d, respetivamente)).

Tal como descrito anteriormente, cada pacote da sequência de pacotes pode ser atribuído a exatamente um tipo de pacote de uma pluralidade de tipos de pacotes (nal_unit_type). Pacotes de carga útil e pacotes de controlo do tempo (e dados de preenchimento opcional e pacotes SEI) são, por exemplo, diferentes tipos de pacote. A instanciação de pacotes de um certo tipo de pacote na sequência de pacotes pode ser sujeita a certas limitações. Estas limitações podem definir uma ordem entre os tipos de pacotes (ver Fig. 17) que deverá ser obedecida pelos pacotes dentro de cada unidade de acesso de modo que as delimitações da unidade de acesso 130a,b sejam detetáveis, e se mantenham na mesma posição na sequência de pacotes, mesmo se os pacotes de qualquer tipo de pacote removível forem removidos do fluxo de dados de vídeo. Por exemplo, pacotes de carga útil são do tipo de pacote não removível. Contudo, pacotes de controlo do tempo, pacotes de dados de preenchimento e pacotes SEI podem, tal como discutido acima, ser do tipo de pacote removível, isto é, podem ser unidades não VCL NAL.

No exemplo anterior, os pacotes de controlo do tempo foram explicitamente exemplificados acima pela sintaxe de slice_prefix_rbsp().

Utilizando tal intercalação de pacotes de controlo do tempo, um codificador consegue regular o programador de registo no lado do descodificador durante o decorrer da codificação das imagens individuais do conteúdo de vídeo. Por exemplo, o codificador consegue otimizar o programador do registo de modo a minimizar o atraso de extremo-a-extremo. A este respeito, o codificador consegue ter em consideração a distribuição individual de codificação de complexidade pela área de imagem do conteúdo de vídeo para imagens individuais do conteúdo de vídeo. Em especial, o codificador pode continuadamente fazer sair a sequência de pacotes 122, 122a-d, 122a-di_3 numa base de pacote a pacote (isto é, assim que um pacote atual tenha finalizado é dada a sua saída). Com o uso dos pacotes de controlo do tempo, o codificador consegue regular a programação do registo no lado do descodificador em instâncias em que algumas das subpartes da imagem atual já tenham sido codificadas em pacotes de carga útil respetivos com as restantes subpartes, contudo, ainda não tendo sido codificadas.

Por conseguinte, um codificador para codificar num fluxo de dados de vídeo conteúdo de vídeo em unidades de subpartes (ver codificação de blocos de árvores, mosaicos ou segmentos) de imagens do conteúdo de vídeo, respetivamente codificando cada subparte num ou mais pacotes de carga útil (ver unidades VCL NAL) de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo de modo que a sequência de pacotes é dividida numa sequência de unidades de acesso e cada unidade de acesso recolhe os pacotes de carga útil relativamente à imagem do conteúdo de vídeo, pode ser configurado para intercalar na sequência de pacotes de controlo do tempo (prefixo do segmento) de modo que os pacotes de controlo do tempo subdividam as unidades de acesso em unidades de codificação de modo que pelo menos algumas unidades de acesso sejam subdividias em duas ou mais unidades de descodificação, com cada pacote de controlo do tempo sinalizando um tempo de pesquisa do registo do descodificador para uma unidade de descodificação, os pacotes de carga útil os quais seguem o respetivo pacote de controlo do tempo na sequência de pacotes.

Qualquer descodificador que receba o fluxo de dados de video agora descrito é livre para explorar a informação de programação contida no pacote de controlo do tempo, ou não. Contudo, enquanto o descodificador é livre para explorar a informação, um descodificador em conformidade com o nível codec deverá poder descodificar os dados seguindo os tempos indicados. Se a exploração ocorrer, o descodificador alimenta o seu registo do descodificador e esvazia o seu registo do descodificador em unidades de unidades de descodificação. 0 "registo do descodificador" pode, tal como descrito acima, envolver o buffer da imagem descodificada e/ou o buffer da imagem codificada.

Por conseguinte, um descodificador para descodificar um fluxo de dados de video dotado de conteúdo de vídeo aqui codificado em unidades de subpartes (ver codificação de blocos de árvores, mosaicos ou segmentos) de imagens do conteúdo de vídeo, cada subparte respetivamente codificada num ou mais pacotes de carga útil (ver unidades VCL NAL) de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo, a sequência de pacotes dividida numa sequência de unidades de acesso de modo que cada unidade de acesso recolhe os pacotes de carga útil relativos a uma imagem respetiva do conteúdo de vídeo, pode ser configurado para pesquisar pacotes de controlo do tempo intercalados na sequência de pacotes, subdividir as unidades de acesso em unidades de descodificação nos pacotes de controlo do tempo de modo que pelo menos algumas unidades de acesso sejam subdivididas em duas ou mais unidades de descodificação, derivar de cada pacote de controlo do tempo um tempo de pesquisa do registo do descodificador para uma unidade de descodificação, os pacotes de carga útil os quais seguem o respetivo pacote de controlo do tempo na sequência de pacotes, e recuperar as unidades de descodificação de um registo do descodificador programado em tempos definidos pelos tempos de pesquisa do registo do descodificador para as unidades de descodificação. A pesquisa pelo pacote de controlo do tempo pode envolver o descodificador a inspecionar o cabeçalho da unidade NAL e o elemento de sintaxe por ela compreendido, nomeadamente nal_unit_type. Se o valor da última bandeira for igual a algum valor, isto é, de acordo com os exemplos anteriores, 124, então o pacote atualmente inspecionado é um pacote de controlo do tempo. Ou seja, o pacote de controlo do tempo iria compreender ou transportar a informação explicada acima relativa ao pseudo código subpic_buffering assim como subpic_timing. Ou seja, os pacotes de controlo do tempo podem transportar ou especificar atrasos de remoção CPB iniciais para o descodificador ou especificar quantos tiques do relógio deve esperar após a remoção do CPB de uma unidade de descodificação respetiva.

De modo a permitir uma transmissão repetitiva dos pacotes de controlo do tempo sem acidentalmente dividir ainda mais a unidade de acesso em unidades de descodificação adicionais, uma bandeira nos pacotes de controlo do tempo pode explicitamente sinalizar se o pacote de controlo do tempo atual participa na subdivisão da unidade de acesso em unidades de codificação ou não (comparar decoding_unit_start_flag = 1 indicando o início de uma unidade de descodificação, e decoding_unit_start_flag = 0 sinalizando a circunstância oposta). 0 aspeto da utilização da informação de identificação do mosaico relacionado com a unidade de descodificação intercalada difere do aspeto da utilização dos pacotes de controlo do tempo relacionado com a unidade de descodificação intercalada na medida em que os pacotes de identificação dos mosaicos são intercalados no fluxo de dados. Os pacotes de controlo do tempo acima mencionados podem adicionalmente ser intercalados no fluxo de dados ou os tempos de pesquisa do registo do descodificador podem ser transportados juntamente com a informação de identificação do mosaico explicado em baixo no mesmo pacote em comum. Por conseguinte, os detalhes adiantados na secção acima podem ser utilizados por forma a clarificar assuntos relativos à descrição abaixo.

Um outro aspeto desta especificação derivado das formas de realização descritas acima revela um fluxo de dados de video dotado de conteúdo de vídeo nele codificado, utilizando codificação preditiva e de entropia, em unidades de segmentos nas quais imagens do conteúdo de vídeo são espacialmente subdivididas, utilizando uma sequência de codificação entre os segmentos, com predições restritivas da codificação preditiva e/ou codificação de entropia para o interior dos mosaicos nos quais as imagens do conteúdo de video são espacialmente subdivididas, em que a sequência dos segmentos em sequência de codificação são "embalados" em pacotes de carga útil de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo na sequência de codificação, sendo a sequência de pacotes dividida numa sequência de unidades de acesso de modo que cada unidade de acesso recolha os pacotes de carga útil dotados de segmentos neles "embalados" relativo a uma imagem respetiva do conteúdo de vídeo, em que a sequência de pacotes possui pacotes de identificação de mosaicos nela intercalados identificando mosaicos (potencialmente apenas um) que se encontram sobrepostos por segmentos (potencialmente apenas um) "embalados" num ou mais pacotes de carga útil imediatamente seguintes ao respetivo pacote de identificação de mosaicos na sequência de pacotes. Observe-se, por exemplo, a figura imediatamente anterior ilustrando um fluxo de dados. Os pacotes 124a e 124b devem agora representar pacotes de identificação de mosaicos. Seja por sinalização explicita (comparar single_slice_flag = 1) ou por convenção, o pacote de identificação de mosaicos pode simplesmente identificar mosaicos que se encontram sobrepostos por segmentos "embalados" no pacote de carga útil 122a imediatamente seguinte. Em alternativa, através de sinalização explícita ou por convenção, o pacote de identificação 124a pode identificar mosaicos que se encontram sobrepostos por segmentos "embalados" num ou mais pacotes de carga útil imediatamente a seguir ao respetivo pacote de identificação de mosaicos 124a na sequência de pacotes até imediatamente anterior ao final 130b da unidade de acesso atual 120, e o inicio de uma próxima unidade de descodificação 128b, respetivamente. Ver, por exemplo, a Fig. 35: se cada segmento 118a-di-3 foi "embalado" em separado num pacote 122a-di_3 respetivo, com a subdivisão em unidades de descodificação tais que os pacotes sejam agrupados em três unidades de descodificação a {122ai_3}, {122bi_3} e {122ci_3, 122di_ 3}, então os segmentos {II8C1-3, 118di_3} "embalados" em pacotes {122ci-3, 122di-3} da terceira unidade de descodificação iria, por exemplo, sobrepor-se aos mosaicos 112c e 112d, e o prefixo de segmento correspondente iria, por exemplo, quando se refere a toda a unidade de descodificação, indicar "c" e "d", isto é, estes mosaicos 112c e 112d.

Assim, a entidade de rede mencionado mais abaixo pode utilizar esta sinalização explicita ou convenção de modo a corretamente associar cada pacote de identificação de mosaicos com um ou mais pacotes de carga útil imediatamente a seguir ao pacote de identificação na sequência dos pacotes. O modo de identificação pode ser sinalizado como exemplificativamente descrito acima através do pseudo código subpic_tile_info. Os pacotes de carga útil associados foram mencionados acima como "segmentos prefixados". Naturalmente, o exemplo pode ser modificado. Por exemplo, as entidades de sintaxe "tile_priority" podem ser ignoradas. Para além disso, a ordem entre os elementos de sintaxe pode ser trocada e o descritor relativo a possíveis comprimentos de bits e de codificação de princípios dos elementos de sintaxe é meramente ilustrativo.

Uma entidade de rede que recebe o fluxo de dados de vídeo (isto é, um fluxo de dados de vídeo dotado de conteúdo de vídeo, utilizando codificação preditiva e de entropia, em unidades de segmentos nos quais imagens do conteúdo de vídeo são espacialmente subdivididas, utilizando uma sequência de codificação entre os segmentos, com predições restritivas da codificação preditiva e/ou codificação de entropia ao interior dos mosaicos nos quais as imagens do conteúdo de vídeo se encontram espacialmente subdivididas, em que a sequência dos segmentos em sequência de codificação são "embalados" em pacotes de carga útil de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo na sequência de codificação, a sequência de pacotes divididos numa sequência de unidades de acesso de modo que cada unidade de acesso recolhe os pacotes de carga útil tendo segmentos nela "embalados" relativos a uma imagem respetiva do conteúdo de vídeo, em que a sequência de pacotes possui pacotes de identificação de mosaicos nela intercalados) pode ser configurado para identificar, com base nos pacotes de identificação de mosaicos, mosaicos que se encontram sobrepostos por segmentos "embalados" num ou mais pacotes de carga útil imediatamente seguintes ao respetivo pacote de identificação de mosaicos na sequência de pacotes. A entidade de rede pode utilizar o resultado da identificação de modo a poder decidir sobre as tarefas de transmissão. Por exemplo, a entidade de rede pode manusear os diferentes mosaicos com diferente prioridade para reprodução. Por exemplo, no caso de perda de pacotes esses pacotes de carga útil relativos a mosaicos de prioridade elevada podem ser preferidos para uma retransmissão sobre pacotes de carga útil relativos a mosaicos de prioridade baixa. Ou seja, a entidade de rede pode primeiro solicitar a retransmissão de pacotes de carga útil perdidos para mosaicos de prioridade elevada. Apenas em caso de existir tempo (dependendo da velocidade de transmissão) a entidade de rede procede com o pedido de retransmissão dos pacotes de carga útil perdidos relativos aos mosaicos de prioridade mais baixa. A entidade de rede pode, contudo, ser também uma unidade de reprodução capaz de atribuir a diferentes ecrãs mosaicos ou pacotes de carga útil relativos a certos mosaicos.

No que diz respeito ao aspeto de utilização da informação da região de interesse intercalada, dever-se-á ter em atenção que os pacotes ROI mencionados abaixo podem coexistir com os pacotes de controlo do tempo mencionado acima e/ou pacotes de identificação de mosaicos, seja através da combinação de conteúdo de informação em pacotes comuns tal como descrito acima relativos aos prefixos de segmento, ou sob a forma de pacotes separados. 0 aspeto da utilização da informação da região de interesse intercalada tal como descrita acima revela, por outras palavras, um fluxo de dados de vídeo com conteúdo de vídeo nele codificado, utilizando codificação e entropia preditiva, em unidades de segmentos nas quais imagens do conteúdo de vídeo se encontram espacialmente subdivididas, utilizando uma sequência de codificação entre os segmentos, com predições restritivas e/ou codificação de entropia da codificação preditiva para o interior dos mosaicos nos quais as imagens do conteúdo de vídeo são dividas, em que a sequência dos segmentos em sequência de codificação são "embalados" em pacotes de carga útil de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo na sequência de codificação, sendo a sequência de pacotes dividida numa sequência de unidades de acesso de modo que cada unidade de acesso recolha os pacotes de carga útil dotados de segmentos aí "embalados" para uma imagem respetiva do conteúdo de vídeo, em que a sequência de pacotes possui pacotes ROI nela intercalados identificando mosaicos das imagens que pertencem a uma ROI das imagens, respetivamente.

Em relação aos pacotes ROI, comentários idênticos são válidos como aqueles fornecidos antes no que diz respeito aos pacotes de identificação de mosaicos: os pacotes ROI podem identificar mosaicos das imagens que pertencem a uma ROI da imagem apenas entre os mosaicos que se encontram sobrepostos por segmentos contidos num ou mais pacotes de carga útil a que o respetivo pacote ROI se refere através do seu um ou mais pacotes de carga útil imediatamente anteriores tal como descrito acima relativamente aos "segmentos prefixados".

Pacotes ROI podem permitir a identificação de mais de uma ROI por segmentos prefixados com a identificação de mosaicos associados para cada uma destas ROIs (c.p. num_rois_minusl). Depois, para cada ROI, pode ser transmitida uma prioridade permitindo hierarquizar as ROIs em termos de prioridade (c.p. roi priority[ i ]). De modo a permitir o "seguimento" das ROIs ao longo do tempo durante uma sequência de imagem do video, cada ROI pode ser indexada a um indice ROI de modo que as ROIs indicadas nos pacotes ROI possam ser associadas umas às outras para além/através das delimitações da imagem, isto é, ao longo do tempo (c.p. roi_id[ i ]).

Uma entidade de rede que recebe o fluxo de dados de video (isto é, um fluxo de dados de video com conteúdo de vídeo aqui codificado, utilizando codificação preditiva e de entropia, em unidades de segmentos nas quais imagens do conteúdo de vídeo são espacialmente subdivididas, utilizando uma sequência de codificação entre os segmentos, com predições restritivas da codificação preditiva para o interior dos mosaicos nos quais as imagens do conteúdo de vídeo se encontram divididas, enquanto a continuação da probabilidade de adaptação da codificação de entropia sobre todos os segmentos, em que a sequência dos segmentos na sequência de codificação são "embalados" em pacotes de carga útil de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo na sequência de codificação, a sequência de pacotes divididos numa sequência de unidades de acesso de modo que cada unidade de acesso recolha os pacotes de carga útil com segmentos nela "embalados" relativos a uma imagem respetiva do conteúdo de video) pode ser configurado para identificar, com base nos pacotes de identificação de mosaicos, pacotes que "embalam" segmentos que se sobrepõem aos mosaicos que pertencem à ROI das imagens. A entidade de rede pode explorar a informação transportada pelo pacote ROI de modo idêntico tal como explicado acima na secção imediatamente anterior relativamente aos pacotes de identificação de mosaicos.

No que diz respeito à secção atual assim como a secção anterior, dever-se-á ter em atenção que qualquer entidade de rede, tal como um MANE ou descodificador, é capaz de averiguar qual mosaico ou mosaicos são sobrepostos pelo segmento ou segmentos de um pacote de carga útil atualmente inspecionado, simplesmente verificando a ordem de cada segmento dos segmentos das imagens e verificando o progresso da parte da imagem atual que estes segmentos abrangem, relativamente à posição dos mosaicos na imagem, que pode ser explicitamente sinalizada no fluxo de dados tal como explicado acima ou pode ser conhecido pelo codificador e descodificador através de convenção. Em alternativa, cada segmento (exceto o primeiro de uma imagem em varrimento) pode ser dotado de uma indicação/indice (slice_address medido em unidades de blocos de árvores de codificação) do primeiro bloco de codificação (por exemplo, CTB) o mesmo referindo-se a (mesmo códigos) de modo que o descodificador possa colocar cada segmento (a sua reconstrução) na imagem proveniente deste bloco de codificação na direção da sequência do segmento. Por conseguinte, pode ser suficiente se os pacotes de informação de mosaicos anteriormente mencionados compreenderem apenas o índice do primeiro mosaico (first_tile_id_in_prefixed_slices) sobreposto por qualquer segmento dos respetivos um ou mais pacotes de carga útil imediatamente seguintes ao respetivo pacote de identificação de mosaicos visto que está claro para a entidade de rede após encontrar o próximo pacote de identificação de mosaicos em linha que se o índice transportado pelo último pacote de identificação de mosaicos diferir do anterior um ou mais do que um, então os pacotes de carga útil entre aqueles dois pacotes de identificação de mosaicos cobrem os mosaicos com o índice de mosaico entre eles. Tal é verdade se, tal como mencionado antes, ambas a subdivisão e a subdivisão do bloco de codificação terem, por exemplo, como base uma subdivisão em linha/coluna com uma sequência de varrimento definida entre eles tal que, para ambos os mosaicos e blocos de codificação, em linha, por exemplo, isto é, o índice de mosaico aumenta neste sequência de varrimento assim como os segmentos seguem-se um ao outro de acordo com a sequência do segmento ao longo desta sequência de varrimento entre os blocos de codificação. 0 aspeto da sinalização do cabeçalho de segmento "embalado" e intercalado descrito derivável das formas de realização acima é também combinável com qualquer um dos aspetos anteriormente mencionados ou quaisquer suas combinações. Os prefixos de segmento explicitamente descritos anteriormente, por exemplo, de acordo com a versão 2 unificaram todos estes aspetos. Uma vantagem deste aspeto é a possibilidade de tornar os dados do cabeçalho do segmento mais facilmente disponíveis para as entidades de rede pois são transportados em pacotes autónomos externos para segmentos prefixados/pacotes de carga útil, e uma transmissão repetitiva dos dados do cabeçalho do segmento é possibilitada.

Por conseguinte, um outro aspeto da presente especificação é o aspeto de "embalamento" e intercalação da sinalização do cabeçalho do segmento e pode ser, por outras palavras, visto como revelando um fluxo de dados de vídeo com conteúdo de vídeo codificado aqui em unidades de subpartes (ver blocos de árvores ou segmentos de codificação) de imagens do conteúdo de vídeo, cada subparte respetivamente codificada num ou mais pacotes de carga útil (ver unidades VCL NAL) de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo, a sequência de pacotes dividida numa sequência de unidades de acesso de modo que cada unidade de acesso recolhe os pacotes de carga útil relativos a uma imagem respetiva do conteúdo de vídeo, em que a sequência de pacotes tem nela intercalados pacotes de cabeçalho de segmento (prefixo de segmento) que transportam dados do cabeçalho de segmento para, e na falta de, um ou mais pacotes de carga útil que seguem o respetivo pacote do cabeçalho de segmento na sequência de pacotes.

Uma entidade de rede que recebe um fluxo de dados de vídeo (isto é, um fluxo de dados de vídeo dotado de conteúdo de vídeo codificado aqui em unidades de subpartes (ver blocos de árvore ou segmentos de codificação) de imagens do conteúdo de vídeo, cada subparte respetivamente codificada num ou mais pacotes de carga útil (ver unidades VCL NAL) de uma sequência de pacotes (unidades NAL) do fluxo de dados de vídeo, a sequência de pacotes dividida numa sequência de unidades de acesso de modo que cada unidade de acesso recolhe os pacotes de carga útil relativos a uma imagem respetiva do conteúdo de vídeo, em que a sequência de pacotes tem nela intercalados pacotes do cabeçalho do segmento) pode ser configurado para cabeçalho de segmento de leitura juntamente com dados de carga útil para os segmentos dos pacotes com, contudo, derivando dos dados do cabeçalho do segmento dos pacotes do cabeçalho de segmento e saltando a leitura do cabeçalho do segmento para um ou mais pacotes de carga útil que seguem o respetivo pacote do cabeçalho do segmento de pacotes, mas adotando em vez disso o cabeçalho do segmento derivado do pacote do cabeçalho do segmento que o um ou mais pacotes de carga útil seguem.

Tal como verdadeiro para os aspetos mencionados acima, é possível que os pacotes, aqui os pacotes do cabeçalho de segmento, possam também ter a funcionalidade de indicarem a qualquer entidade de rede tal como um MANE ou descodificador, o início de uma unidade de descodificação ou um início de execuções do um ou mais pacotes de carga útil prefixados pelo respetivo pacote. Por conseguinte, a entidade de rede de acordo com o presente aspeto pode identificar os pacotes de carga útil para os quais a leitura do cabeçalho do segmento teve de ser ultrapassada com base nos elementos de sintaxe anteriormente mencionados neste pacote, nomeadamente single_slice_flag, juntamente com, por exemplo, decoding_unit_start_flag, entre os quais a última bandeira permite, tal como discutido anteriormente, uma retransmissão de cópias de certos pacotes do cabeçalho de segmento nas unidades de descodificação. Isto é útil, por exemplo, porque o cabeçalho de segmento dos segmentos numa unidade de descodificação pode alterar-se ao longo da sequência de segmentos, e por conseguinte, enquanto os pacotes do cabeçalho do segmento no inicio das unidades de descodificação podem ter o conjunto decoding_unit_start_flag (igual a um) , pacotes do cabeçalho de segmento posicionados entre estes podem ter esta bandeira não estabelecida, de modo a evitar que qualquer entidade de rede interprete falsamente a ocorrência desta pacote do cabeçalho de segmento como um início de uma nova unidade de descodificação.

Apesar de alguns aspetos terem sido descritos no contexto de um aparelho, está claro que estes aspetos representam também uma descrição do método correspondente, em que um bloco ou dispositivo corresponde a uma etapa do método ou uma característica de uma etapa do método. Do mesmo modo, aspetos descritos no contexto de uma etapa do método representam também uma descrição de um bloco correspondente ou item ou caracteristica de um aparelho correspondente. Algumas ou todas as etapas do método podem ser executadas por (ou utilizando) um aparelho de hardware, como por exemplo, um microprocessador, um computador programável ou um circuito eletrónico. Nalgumas formas de realização, alguma ou mais das mais importantes etapas do método podem ser executadas por um aparelho desses. 0 fluxo de dados de video inovador pode ser armazenado num meio de armazenamento digital ou pode ser transmitido num meio de transmissão tal como um meio de transmissão sem fios ou um meio de transmissão com fios como a Internet.

Dependendo de certos requisitos de implementação, formas de realização da invenção podem ser implementadas em hardware ou em software. A implementação pode ser executada utilizando um meio de armazenamento digital, por exemplo uma disquete, um DVD, um Blu-Ray, um CD, uma ROM, uma PROM, uma EPROM, uma EEPROM ou uma memória FLASH, com sinais de controlo lidos eletronicamente ai armazenados, que cooperam (ou são capazes de cooperar) com um sistema de computador programável de modo que o respetivo método seja executado. Assim, o meio de armazenamento digital pode ser um lido por um computador.

Algumas formas de realização de acordo com a invenção compreendem um suporte de dados com sinais de controlo lidos eletronicamente, capazes de cooperarem com um sistema de computador programável, de modo que um dos métodos aqui descritos seja executado.

Regra geral, formas de realização desta invenção podem ser implementadas como um produto de programa de computador com um código de programa, em que o código de programa é operacional para executar um dos métodos quando o produto do programa de computador é executado num computador. 0 código de programa pode por exemplo ser armazenado num suporte de leitura mecânica.

Outras formas de realização compreendem o programa de computador para executar um dos métodos aqui descritos, armazenados num suporte de leitura mecânica.

Por outras palavras, uma forma de realização do método inovador é, desse modo, um programa de computador com um código de programa para executar um dos métodos aqui descritos, quando o programa de computador é executado num computador.

Uma forma de realização adicional dos métodos inovadores é, por isso, um suporte de dados (ou um meio de armazenamento digital, ou um meio lido por computador) compreendendo, ali registados, o programa de computador para executar um dos métodos aqui descritos. 0 suporte de dados, o meio de armazenamento digital ou o meio registado são tipicamente tangíveis e/ou não transitório.

Uma forma de realização adicional do método inovador é, por isso, um fluxo de dados ou uma sequência dos sinais representando o programa de computador para executar um dos métodos aqui descritos. 0 fluxo de dados ou a sequência de sinais pode por exemplo ser configurado para ser transferido através de uma ligação de comunicação de dados, por exemplo através da Internet.

Uma forma de realização adicional compreende um meio de processamento, por exemplo um computador, ou um dispositivo de lógica programável, configurado para ou adaptado para executar um dos métodos aqui descritos.

Uma forma de realização adicional compreende um computador tendo instalado nele o programa de computador para executar um dos métodos aqui descritos.

Uma forma de realização adicional de acordo com a invenção compreende um aparelho ou um sistema configurado para transferir (por exemplo, eletronicamente ou oticamente) um programa de computador para executar um dos métodos aqui descritos para um recetor. 0 recetor pode, por exemplo, ser um computador, um dispositivo móvel, um dispositivo de memória ou outro idêntico. 0 aparelho ou sistema pode, por exemplo, compreender um servidor de ficheiros para transferir o programa de computador para o recetor.

Nalgumas formas de realização, um dispositivo de lógica programável (por exemplo uma rede de portas lógicas programáveis) pode ser utilizado para executar algumas ou todas as funcionalidades dos métodos aqui descritos. Nalgumas formas de realização, uma rede de portas lógicas programáveis pode cooperar com um microprocessador de modo a executar um dos métodos aqui descritos. Regra geral, os métodos são de preferência executados por qualquer aparelho de hardware.

As formas de realização descritas acima são meramente ilustrativas para os princípios da presente invenção. É entendido que modificações e variações das disposições e dos detalhes descritos no presente documento serão evidentes para outros elementos especialistas na técnica. É intenção portanto serem limitadas apenas pelo âmbito das reivindicações iminentes da patente e não pelos detalhes específicos apresentados por meio de descrição e explicação das formas de realização do presente documento.

Referências [1] Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, Ajay Luthra, "Overview of the H.264/AVC Video Coding Standard", IEEE Trans. Circuits Syst. Video Technol., vol. 13, N7, July 2003.

[2] JCT-VC, "High-Efficiency Video Coding (HEVC) text specification Working Draft 7", JCTVC-I1003, Maio 2012.

[3] ISO/IEC 13818-1: MPEG-2 Systems specification.

[4] IETF RFC 3550 - Real-time Transport Protocol.

[5] Y.-K. Wang et al., "RTP Payload Format for H.264 Video", IETF RFC 6184, hftp: //1οo.1 s . ietf. org/htm 1 /

Referências citadas na descrição: A lista de referências citada pelo proponente é somente para conveniência do leitor. Não é parte do documento europeu de patente. Apesar de todo o cuidado que foi tido na compilação das referências, erros ou omissões não podem ser excluídas e o EPO recusa quaisquer responsabilidades nesse sentido.

Literatura, que não patentes, citada na descrição,

Thomas Wiegand, Gary J. Sullivan, Gisle Bjontegaard, Ajay

Luthra, "Overview of the H.264/AVC Video Coding Standard", IEEE Trans. Circuits Syst. Video Technol., vol. 13, N7, Julho 2003. High-Efficiency Video Coding (HEVC) text specification Working Draft 7. JCTVC-I1003, Maio 2012 Y.-K. Wang et al., "RTP Payload Format for H.264 Video", IETF RFC 6184, http ://tools .ietf.org/html/ S. Wenger et al., "RTP Payload format for Scalable Video Coding", IETF RFC 6190, http://tools.ietf.org/html/rfc6190 T. Schierl et al., "RTP Payload Format for High Efficiency Video

Coding", IETF internet draft, nttp: / /da tatracker. ietf. orq/doc/draf t-schi e r 1 - p ay 1 od.-rtp-n2 65/

Claims

REIVINDICAÇÕES

1. Fluxo de dados de vídeo com conteúdo de vídeo (16) codificado aqui em unidades de subpartes (24) de imagens (18) do conteúdo de vídeo (16), cada subparte (24) estando respetivamente codificada num ou mais pacotes de carga útil (32) de uma sequência (34) de pacotes do fluxo de dados de vídeo (22), a sequência (34) de pacotes estando dividida numa sequência de unidades de acesso (30) de modo que cada unidade de acesso (30) recolhe os pacotes de carga útil (32) relativos a uma respetiva imagem (18) do conteúdo de vídeo (16), caracterizado por a sequência (34) de pacotes ter intercalado nela pacotes de controlo do tempo (36) de modo que os pacotes de controlo do tempo (36) subdividam as unidades de acesso (30) em unidades de descodificação (38) de modo que pelo menos algumas unidades de acesso (30) sejam subdivididas em duas ou mais unidades de descodificação (38), com cada pacote de controlo do tempo (38) sinalizando um tempo de pesquisa do registo do descodificador para uma unidade de descodificação (38), os pacotes de carga útil (32) dos quais seguem o respetivo pacote de controlo do tempo (38) na sequência (34) de pacotes.
2. Fluxo de dados de vídeo de acordo com a reivindicação 1, caracterizado por as subpartes (24) serem segmentos, e cada pacote de carga útil (32) abranger um ou mais segmentos.
3. Fluxo de dados de vídeo de acordo com a reivindicação 2, caracterizado por os segmentos compreenderem segmentos independentemente descodificáveis e segmentos dependentes permitindo, para o processamento WPP, descodificação utilizando descodificação de entropia e preditiva para além dos limites dos segmentos.
4. Fluxo de dados de video de acordo com qualquer uma das reivindicações 1 a 3, caracterizado por cada pacote da sequência (34) de pacotes poder ser atribuído a exatamente um tipo de pacote de uma pluralidade de tipos de pacotes com pacotes de carga útil (32) e pacotes de controlo do tempo (36) de diferentes tipos de pacotes, em que as ocorrências de pacotes da pluralidade de tipos de pacotes na sequência (34) dos pacotes estão sujeitas a certas limitações que definem uma sequência entre os tipos de pacotes para obedecer pelos pacotes em cada unidade de acesso (30) de modo que as limitações da unidade de acesso sejam detetáveis utilizando as limitações através da deteção de instâncias em que as limitações são objeto de, e mantêm-se na mesma posição na sequência de pacotes, mesmo que pacotes de qualquer tipo de pacote removível sejam removidos do fluxo de dados de vídeo, em que pacotes de carga útil (32) são do tipo de pacote não removível, e pacotes de controlo do tempo (36) são do tipo de pacote removível.
5. Fluxo de dados de video de acordo com qualquer uma das reivindicações 1 a 4, caracterizado por cada pacote compreender um tipo de pacote indicando uma parte do elemento de sintaxe.
6. Fluxo de dados de video de acordo com a reivindicação 5, caracterizado por o tipo de pacote indicando parte da entidade de sintaxe compreender um campo do tipo de pacote num cabeçalho do pacote do respetivo pacote, cujo conteúdo difere entre pacotes de carga útil e pacotes de controlo do tempo, e, para pacotes de controlo do tempo, um campo do tipo de pacote SEI diferenciando entre os pacotes de controlo do tempo por um lado e pacotes SEI de tipo diferente por outro.
7. Codificador para codificar num fluxo de dados de video (22) conteúdo de vídeo (16) em unidades de subpartes (24) de imagens (18) do conteúdo de vídeo (16), codificando respetivamente cada subparte (24) num ou mais pacotes de carga útil (32) de uma sequência (34) de pacotes do fluxo de dados de vídeo (22) de modo que a sequência (34) de pacotes seja dividida numa sequência de unidades de acesso (30) e cada unidade de acesso (30) recolhe os pacotes de carga útil (32) relativos a uma respetiva imagem (18) do conteúdo de vídeo (16), o codificador caracterizado por estar configurado para se intercalar na sequência (34) de pacotes dos pacotes de controlo do tempo (36) de modo que os pacotes de controlo do tempo (36) subdividam as unidades de acesso (30) em unidades de descodificação (38) de modo que pelo menos algumas unidades de acesso (30) sejam subdivididas em duas ou mais unidades de descodificação (38) , com cada pacote de controlo do tempo (36) sinalizando um tempo de pesquisa do registo do descodificador para uma unidade de descodificação (38), cujos pacotes de carga útil (32) seguem o respetivo pacote de controlo do tempo (36) na sequência (34) de pacotes.
8. Codificador de acordo com a reivindicação 7, caracterizado por o codificador estar configurado para, durante a codificação de uma imagem atual do conteúdo de video codificar uma subparte atual (24) de uma imagem atual (18) num pacote de carga útil atual (32) de uma unidade de descodificação atual (38), transmitir, no fluxo de dados, a unidade de descodificação atual (38) prefixada com um pacote de controlo do tempo atual (36) com o definir de um tempo de pesquisa do registo do descodificador sinalizado pelo pacote de controlo do tempo atual (36), num primeiro instante de tempo, e codificar uma subparte adicional da imagem atual num segundo instante de tempo, mais tardio que o primeiro instante.
9. Método para codificação num fluxo de dados de vídeo (22) com conteúdo de vídeo (16) em unidades de subpartes (24) de imagens (18) do conteúdo de vídeo (16), codificando respetivamente cada subparte (24) num ou mais pacotes de carga útil (32) de uma sequência (34) de pacotes do fluxo de dados de vídeo (22) de modo que a sequência (34) de pacotes seja dividida numa sequência de unidades de acesso (30) e cada unidade de acesso (30) recolher os pacotes de carga útil (32) relativos a uma imagem respetiva (18) do conteúdo de vídeo (16), o método caracterizado por compreender intercalar-se na sequência (34) de pacotes de pacotes de controlo do tempo (36) de modo que os pacotes de controlo do tempo (36) subdividam as unidades de acesso (30) em unidades de descodificação (38) de modo que pelo menos algumas unidades de acesso (30) sejam subdivididas em duas ou mais unidades de descodificação (38), com cada pacote de controlo do tempo (36) sinalizando um tempo de pesquisa do registo do descodificador para uma unidade de descodificação (38), cujos pacotes de carga útil (32) seguem o respetivo pacote de controlo do tempo (36) na sequência (34) de pacotes.
10. Descodificador para descodificar o fluxo de dados de video (22) com conteúdo de video (16) aqui codificado em unidades de subpartes (24) de imagens (18) do conteúdo de video (16), cada subparte estando respetivamente codificada num ou mais pacotes de carga útil (32) de uma sequência (34) de pacotes do fluxo de dados de video (22), a sequência (34) de pacotes estando dividida numa sequência de unidades de acesso (30) de modo que cada unidade de acesso (30) recolha os pacotes de carga útil (32) relativos a uma respetiva imagem (18) do conteúdo de video (16), o descodificador sendo caracterizado por compreender um registo para registar o fluxo de dados de video ou uma reconstrução do conteúdo de vídeo daí obtido pela descodificação do fluxo de dados de vídeo e configurado para procurar pacotes de controlo do tempo (36) intercalados na sequência de pacotes, subdividir as unidades de acesso (30) em unidades de descodificação (38) nos pacotes de controlo do tempo (36) de modo que pelo menos algumas unidades de acesso sejam subdivididas em duas ou mais unidades de descodificação, e esvaziam o registo em unidades das unidades de descodificação.
11. Descodificador de acordo com a reivindicação 10, caracterizado por o descodificador ser configurado para, ao procurar os pacotes de controlo do tempo (36), inspecionar, em cada pacote, um tipo de pacote indicando uma parte da entidade de sintaxe com, se um valor do tipo de pacote indicando a parte da entidade de sintaxe igualar um valor pré-determinado, reconhecer o respetivo pacote como um pacote de controlo do tempo (36).
12. Método para descodificação de um fluxo de dados de video (22) com conteúdo de video (16) aqui codificado em unidades de subpartes (24) de imagens (18) do conteúdo de video (16), cada subparte estando respetivamente codificada num ou mais pacotes de carga útil (32) de uma sequência (34) de pacotes do fluxo de dados de video (22), a sequência (34) de pacotes estando dividida numa sequência de unidades de acesso (30) de modo que cada unidade de acesso (30) recolha os pacotes de carga útil (32) relativos a uma respetiva imagem (18) do conteúdo de vídeo (16), o método sendo caracterizado por utilizar um registo para registrar o fluxo de dados de vídeo ou uma reconstrução do conteúdo de vídeo aí obtido pela descodificação do fluxo de dados de vídeo e compreendendo a pesquisa de pacotes de controlo do tempo (36) intercalados na sequência de pacotes, subdividindo as unidades de acesso (30) em unidades de descodificação (38) nos pacotes de controlo do tempo (36) de modo que pelo menos algumas unidades de acesso sejam subdivididas em duas ou mais unidades de descodificação, e esvaziando o registo em unidades das unidades de descodificação.
13. Entidade de rede para transmissão de um fluxo de dados de video (22) dotado de conteúdo de vídeo (16) aí codificado em unidades de subpartes (24) de imagens (18) do conteúdo de vídeo (16), cada subparte estando respetivamente codificada num ou mais pacotes de carga útil (32) de uma sequência (34) de pacotes do fluxo de dados de vídeo (22), a sequência (34) de pacotes estando dividida numa sequência de unidades de acesso (30) de modo que cada unidade de acesso (30) recolha os pacotes de carga útil (32) relativos a uma respetiva imagem (18) do conteúdo de vídeo (16), caracterizada por o descodificador estar configurado para procurar pacotes de controlo de tempo (36) intercalados na sequência de pacotes, subdividir as unidades de acesso em unidades de descodificação nos pacotes de controlo de tempo (36) de modo que pelo menos algumas unidades de acesso (30) sejam subdivididas em duas ou mais unidades de descodificação (38), derivar de cada pacote de controlo do tempo (36) um tempo de pesquisa de registo do descodificador para uma unidade de descodificação (38), os pacotes de carga útil (32) os quais seguem o respetivo pacote de controlo do tempo (36) na sequência (34) de pacotes, e executar a transmissão do fluxo de dados de vídeo dependente dos tempos de pesquisa de registo do descodificador para as unidades de descodificação (38).
14. Método para transmissão de um fluxo de dados de vídeo (22) dotado de conteúdo de vídeo (16) aí codificado em unidades de subpartes (24) de imagens (18) do conteúdo de vídeo (16), cada subparte estando respetivamente codificada num ou mais pacotes de carga útil (32) de uma sequência (34) de pacotes do fluxo de dados de video (22), a sequência (34) de pacotes estando dividida numa sequência de unidades de acesso (30) de modo que cada unidade de acesso (30) recolha os pacotes de carga útil (32) relativos a uma respetiva imagem (18) do conteúdo de video (16), o método caracterizado por compreender a procura de pacotes de controlo do tempo (36) intercalados na sequência de pacotes, subdividir as unidades de acesso em unidades de descodificação nos pacotes de controlo do tempo (36) de modo que pelo menos algumas unidades de acesso (30) sejam subdivididas em duas ou mais unidades de descodificação (38), derivando de cada pacote de controlo do tempo (36) um tempo de pesquisa de registo do descodificador para uma unidade de descodificação (38), os pacotes de carga útil (32) dos quais seguem o respetivo pacote de controlo do tempo (36) na sequência (34) de pacotes, e executar a transmissão do fluxo de dados de video dependente dos tempos de pesquisa de registo do descodificador para as unidades de descodificação (38).
15. Programa de computador caracterizado por conter um código de programa para executar, quando correndo num computador, um método tal como definido em qualquer uma das reivindicações 9, 12, 14.