BR112012006371B1 - streaming de solicitação de bloco aprimorado utilizando gabaritos de url e regras de construção - Google Patents

Abstract

STREAMING DE SOLICITAÇÃO DE BLOCO APRIMORADO UTILIZANDO GABARITOS DE URL E REGRAS DE CONSTRUÇÃO. Um sistema de fluxo contínuo de solicitação de bloco provê aperfeiçoamentos na experiência de usuário e eficiência de largura de banda de tais sistemas, tipicamente usando um sistema de ingestão que gera dados em uma forma a ser servidos por um servidor de arquivo convencional (HTTP, FTP, ou similar), em que o sistema de ingestão emite conteúdo e os prepara como elementos de arquivos e dados para serem servidos pelo servidor de arquivo, que pode incluir um cahe. Um dispositivo cliente pode ser adaptado para tirar vantagem do processo de ingestão vem como aperfeiçoamentos que fazem uma melhor apresentação independente do processo de ingestão. Os dispositivos clientes e sistema de ingestão podem ser coordenados para ter um mapeamento predefinido e modelo para fazer solicitações de bloco para nomes de arquivos HTTP que um servidor de arquivo convencional pode aceitar através do uso de regras de construção de URL. Tamanho de segmento pode ser especificado de uma maneira aproximada para organização mais eficiente.

Description

Referência a Pedidos Correlacionados

Este pedido é Pedido de Patente Não Provisório que reivindica o beneficio aos seguintes pedidos provisórios, cada um nomeado a Michael G. Luby, et al. e cada um intitulado "ENHANCED BLOCK-REQUEST STREAMING SYSTEM":

Este pedido também reivindica o beneficio da solicitação de Patente Provisório U.S. n° 61/372,399, depositado em 10 de agosto de 2010, nomeado a Ying Chen, et al. e intitulado "HTTP STREAMING EXTENSIONS".

Cada pedido provisório citado acima é aqui incorporado por referência para todos os fins. A presente divulgação também incorpora por referência, como se estabelecida na totalidade no presente documento, para todos os fins, as seguintes patentes / pedidos comumente atribuidas: Patente U.S. n° 6.307.487 para Luby (doravante denominada "Luby I"); Patente U.S. n° 7.068.729 para Shokrollahi, et al. (Doravante denominada "Shokrollahi I") ; Pedido de Patente U.S. n° 11/423,391 depositado em 0 9 de junho de 2006 e intitulado "FORWARD ERRORCORRECTING (FEC) CODING AND STREAMING" nomeado a Luby, et al. (doravante denominado "Luby IF); Pedido de Patente U.S. n° 12/103,605 depositado em 15 de abril de 2008, intitulado "DINAMIC STREAM INTERLEAVING AND SUB-STREAM BASED DELIVERY" nomeado a Luby, et al. (doravante "Luby III"); Pedido de Patente U.S. n° 12/705,202 depositado em 12 de fevereiro de 2010, intitulado "BLOCK PARTITIONING FOR A DATA STREAM" nomeado a Pakzad, et al. (doravante "Pakzad"), e Pedido de Patente U.S. n° 12/859,161 depositado em 18 de agosto de 2010, intitulado "METHODS AND APPARATUS EMPLOYING FEC CODES WITH PERMANENT INATIVATION OF SYMBOLS FOR ENCODING AND DECODING PROCESSES" nomeado a Luby, et al. (doravante denominado "Luby IV").

Campo da Invenção

A pres-ente invenção refere-se a métodos e sistemas de fluxo continuo (streaming) de midia, mais particularmente a sistemas e métodos que são adaptáveis às condições da rede e armazenador (buffer), a fim de otimizar uma apresentação de mídia transmitida em fluxo contínuo e permite a entrega eficiente simultânea ou temporalmente distribuída, de dados de mídia transmitida em fluxo contínuo.

Descrição da Técnica Anterior

Entrega de mídia em fluxo contínuo pode tornar-se cada vez mais importante conforme torna-se mais comum para áudio e vídeo de alta qualidade a ser entregue através de redes baseadas em pacotes, tal como a Internet, redes celulares e sem fio, redes de energia elétrica e outros tipos de redes. A qualidade com a qual mídia em fluxo contínuo entregue pode ser apresentada pode depender de um número de fatores, incluindo a resolução (ou outros atributos) do conteúdo original, a qualidade de codificação do conteúdo original, as capacidades dos dispositivos de recepção de decodificar e apresentar a mídia, pontualidade e qualidade do sinal recebido nos receptores, etc. Para criar uma experiência de mídia em fluxo contínuo bom percebida, o transporte e a pontualidade do sinal recebido no receptor pode ser especialmente importante. Bom transporte pode prover boa fidelidade do fluxo recebido no receptor em relação a qual um remetente envia, enquanto pontualidade pode representar quão rapidamente um receptor pode começar a jogar fora o conteúdo depois de uma solicitação inicial para aquele conteúdo.

Um sistema de entrega de mídia pode ser caracterizado como um sistema que tem fontes de mídia, destinos de mídia, e canais (em tempo e/ou espaço) que separam as fontes e os destinos. Tipicamente, uma fonte inclui um transmissor com à mídia de forma administrável, e um receptor com capacidade de controlar eletronicamente a recepção da mídia (ou uma aproximação da mesma) e provê-la a um consumidor de mídia (por exemplo, um usuário tendo um dispositivo de exibição acoplado de alguma forma ao receptor, um dispositivo de armazenamento ou elemento, um outro canal, etc.).

Enquanto muitas variações são possíveis, em um exemplo comum, um sistema de entrega de mídia tem um ou mais servidores que têm acesso a conteúdo de mídia em formato eletrônico, e um ou mais sistemas ou dispositivos clientes que fazem solicitações de mídia para os servidores, e os servidores transportam a mídia usando um transmissor, como parte do servidor, transmitindo a um receptor no cliente de modo que a mídia recebida possa ser consumida pelo cliente de alguma forma. Em um exemplo simples, existe um servidor e um cliente, para uma dada solicitação e resposta, mas que não precisa ser o caso.

Tradicionalmente, os sistemas de entrega de midia podem ser caracterizados que em um modelo de "download" ou modelo de "fluxo continuo". O modelo de "download" pode ser caracterizado pela independência de tempo entre a entrega dos dados de midia e a reprodução de midia para o usuário ou dispositivo receptor.

Como um exemplo, a midia é baixada (download) o suficiente de modo que quando ela for requerida ou quando for utilizada, tanto quanto é necessário já esteja disponível no receptor. Entrega no contexto de download é muitas vezes realizada usando um protocolo de transporte de arquivos, tais como HTTP, FTP ou Entrega de Arquivo através de Transporte Unidirecional (FLUTE) e a taxa de entrega pode ser determinada por um fluxo subjacente e/ou protocolo de controle de congestionamento, tal como TCP/IP. A operação do fluxo ou protocolo de controle de congestionamento pode ser independente da reprodução da midia para o usuário ou o dispositivo de destino, que pode ocorrer simultaneamente com o download ou em algum outro momento.

O modo "fluxo continuo" pode ser caracterizado por um forte acoplamento entre o momento da entrega dos dados de midia e a reprodução (reprodução) da midia para o usuário ou dispositivo receptor. Entrega neste contexto é frequentemente realizada usando um protocolo de fluxo continuo, tal como o Protocolo de Fluxo Continuo em Tempo Real (RTSP) para controle e o Protocolo de Transporte em tempo Real (RTP) para os dados de midia. A taxa de entrega pode ser determinada por um servidor de fluxo continuo, muitas vezes correspondente a taxa de reprodução dos dados.

Algumas desvantagens do modelo de "download" pode ser que, devido à independência de tempo da entrega e reprodução, quer os dados de midia podem não estar disponíveis quando forem requeridos para a reprodução (por exemplo, devido à largura de banda disponível ser inferior à taxa de dados de midia) , fazendo com que a reprodução pare momentaneamente ("protelar"), o que resulta em uma má experiência de usuário, ou os dados de midia podem ser requeridos para download muito mais adiantados do que a reprodução (por exemplo, devido à largura de banda disponível ser maior que a taxa de dados de midia), consumindo recursos de armazenamento no dispositivo de recepção, que podem ser escassos, e consumindo valiosos recursos de rede para a entrega que podem ser desperdiçados se o conteúdo não for, eventualmente, reproduzido ou usado.

Uma vantagem do modelo de "download" pode ser que a tecnologia necessária para realizar esses downloads, por exemplo, HTTP, é muito madura, muito utilizada e aplicável em uma ampla gama de.. aplicações. Baixar servidores e soluções de escalabilidade massiva de tais downloads de arquivos (por exemplo, servidores de Web HTTP e Redes de Entrega de Conteúdo) pode estar facilmente disponível, tornado a implantação de serviços baseados nesta tecnologia simples e de baixo custo.

Algumas desvantagens do modelo de "fluxo continuo" pode ser que em geral a taxa de entrega de dados de midia não está adaptada à largura de banda disponível na conexão proveniente do servidor para o cliente e os servidores especializados de fluxo continuo ou arquitetura de rede mais complexa que proveem garantias de largura de banda e retardo sejam exigidos. Embora os sistemas de fluxo continuo existam os quais suportam variação da taxa de disponível (por exemplo, Fluxo Continuo Adaptativo Adobe Flash), estes geralmente não são tão eficientes como download de protocolos de controle de fluxo de transporte, tais como TCP em utilizar toda a largura de banda disponível.

Recentemente, novos sistemas de entrega de mídia baseados em uma combinação dos Modelos de "fluxo contínuo" e "download" foram desenvolvidos e implantados. Um exemplo de tal modelo é agui referido como um modelo de "fluxo contínuo de solicitação de bloco", em que um cliente solicita blocos de dados de mídia de mídia a partir de infraestrutura de serviço usando um protocolo de download, tal como o HTTP. Uma preocupação em tais sistemas pode ser a capacidade de começar a reproduzir um fluxo, por exemplo, decodificação e renderização de fluxos de áudio e vídeo recebidos usando um computador pessoal e exibindo o vídeo na tela do computador e reproduzindo o áudio através de altofalantes embutidos, ou como outro exemplo de decodificação e renderização de fluxos de áudio e vídeo recebidos usando ua caixa set-top e exibindo o vídeo em um dispositivo de exibição de televisão e reproduzindo o áudio através de um sistema estéreo.

Outras preocupações, tal como ser capaz de decodificar os blocos fonte com rapidez suficiente para acompanhar a taxa fonte de fluxo contínuo, para minimizar a latência de decodificação e para reduzir o uso de recursos de CPU disponíveis são questões. Outra preocupação é a de prover uma solução de entrega de fluxo contínuo robusta e escalável que permita que os componentes do sistema falhem sem afetar adversamente a qualidade dos fluxos entregues aos receptores. Outros problemas podem ocorrer com base em rapidamente mudar informações sobre uma apresentação, como se ela estivesse sendo distribuída. Assim, é desejável ter processos e aparelhos melhorados.

Sumário da Invenção

Um sistema de fluxo continuo de solicitação de bloco prevê melhorias na experiência de usuário e na eficiência de largura de banda de tais sistemas, geralmente usando um sistema de ingestão que gera dados em uma forma para ser servido por um servidor de arquivos convencional (HTTP, FTP, ou similar), em que a sistema de ingestão entra 10 com de conteúdo e prepara como arquivos ou elementos de dados a serem atendidos pelo servidor de arquivos, que pode ou não incluir uma cache. Um dispositivo de cliente pode ser adaptado para tirar vantagem do processo de ingestão, bem como incluir as melhorias que contribuem para uma 15 melhor apresentação independente do processo de ingestão.

Em um aspecto, os dispositivos de cliente e o sistema de ingestão são coordenados em que não há um mapeamento prereprodução e modelo para fazer solicitações de bloco para nomes de arquivos HTTP que um servidor de arquivos 20 convencional pode aceitar através do uso de regras de construção de URL. Em algumas modalidades, novas melhorias aos métodos para a especificação de tamanho do segmento de uma forma aproximada para organização mais eficiente são providas.

A seguinte descrição detalhada em conjunto com os desenhos anexos irá prover uma melhor compreensão da natureza e das vantagens da presente invenção.

Breve Descrição dos Desenhos A figura 1 ilustra os elementos de um sistema de 30 fluxo contínuo de solicitação de bloco de acordo com modalidades da presente invenção. A figura 2 ilustra o sistema de fluxo contínuo de solicitação de bloco da figura 1, mostrando maiores detalhes nos elementos de um sistema cliente que está acoplado a uma infraestrutura de serviço de bloco ("BSI") para receber os dados que são processados por um sistema de ingestão de conteúdo. A figura 3 ilustra uma implementação de hardware / software de um sistema de ingestão. A figura 4 ilustra uma implementação de hardware / software de um sistema cliente. A figura 5 ilustra possiveis estruturas de armazenamento de conteúdo mostrado na figura 1, incluindo os segmentos e arquivos de descritor apresentação de de midia ("MPD"), bem como uma quebra de segmentos, temporizações e outras estruturas dentro de um arquivo MPD. A figura 6 ilustra os detalhes de um segmento fonte tipico, como pode ser armazenado no armazenamento de conteúdo ilustrado nas figuras 1 e 5. As figuras 7a e 7b mostram indexação simples e hierárquica dentro de arquivos. A figura 8 (a) ilustra dimensionamento de bloco variável com pontos de busca alinhados sobre uma pluralidade de versões de um fluxo de midia. A figura 8 (b) ilustra dimensionamento de bloco variável com os pontos de busca não-alinhados sobre uma pluralidade de versões de um fluxo de midia. A figura 9(a) ilustra uma Tabela de Metadados. A figura 9 (b) ilustra a transmissão de blocos e Tabela de Metadados e do servidor para o cliente. A figura 10 ilustra os blocos que são independentes de fronteiras de RAP. A figura 11 ilustra temporização continua e descontinua em todos os segmentos. A figura 12 é uma figura que mostra um aspecto de blocos graduáveis. A figura 13 mostra uma representação gráfica da evolução de certas variáveis dentro de um sistema de fluxo continuo de solicitação de bloco ao longo do tempo. A figura 14 mostra uma outra representação gráfica da evolução de certas variáveis dentro de um sistema de fluxo continuo de solicitação de bloco ao longo do tempo. A figura 15 mostra uma grade de célula de estados como uma função de valores limites. A figura 16 é um fluxograma de um processo que pode ser realizado em um receptor que pode solicitar blocos individuais e blocos múltiplos por solicitação. A figura 17 é um fluxograma de um processo de encadeamento flexivel. A figura 18 ilustra um exemplo de um conjunto de candidato de solicitações, suas prioridades, e quais conexões podem ser emitidas com, em um determinado momento. A figura 19 ilustra um exemplo de um conjunto candidato de solicitações, suas prioridades, e quais conexões podem ser emitidas em, que evoluiu de uma hora para outra. A figura 20 é um fluxograma de seleção proxy de servidor em cache consistente com base em um identificador de arquivo. A figura 21 mostra uma definição de sintaxe para um idioma de expressão adequado. A figura 22 ilustra um exemplo de uma função hash apropriada. A figura 23 ilustra exemplos de regras de construção de identificadores de arquivos. As figuras 24 (a) - (e) ilustram as flutuações de largura de banda de conexões TCP. A figura 25 ilustra múltiplas solicitações HTTP para dados fonte e de reparação. A figura 26 ilustra tempo zapping de canal exemplar com e sem FEC. A figura 27 ilustra os detalhes de um gerador de segmento de reparação que, como parte do sistema de ingestão mostrado na figura 1, gera segmentos de reparação de segmentos fonte e os parâmetros de controle. A figura 28 ilustra as relações entre os blocos fonte e blocos de reparação. A figura 29 ilustra um procedimento para serviços ao vivo em momentos diferentes no cliente.

Nas figuras, itens similares são referenciados com números similares e subindices são providos em parêntesis para indicar múltiplas instâncias de itens similares ou idênticos. Salvo indicação em contrário, o subindice final (por exemplo, "N" ou "M") não se destina a ser um fator limitante para qualquer valor particular e o número de ocorrências de um item pode diferir do número de ocorrências de outro item, mesmo quando o mesmo número é ilustradas e o subindice é reutilizado.

Descrição Detalhada da Invenção

Como aqui descrito, o objetivo de um sistema de fluxo continuo é mover midia de seu local de armazenamento (ou o local onde está sendo gerada) para um local onde ela está sendo consumida, isto é, apresentada a um usuário ou outra forma, "usada" por um consumidor humano ou eletrônico. Idealmente, o sistema de fluxo continuo pode prover uma reprodução ininterrupta (ou, mais geralmente, "consumo" ininterrupto) a uma extremidade de recepção e pode começar a reproduzir um fluxo ou uma coleção de fluxos logo depois que um usuário tiver solicitado o fluxo ou fluxos. Por razões de eficiência, é também desejável que cada fluxo seja interrompido uma vez que o usuário indica que o fluxo não é mais necessário, tal como quando o usuário está comutando de um fluxo para outro ou que obedece a apresentação de um fluxo, por exemplo, o fluxo "subtítulo". Se o componente de midia, tal como o video, continua a ser apresentado, mas um fluxo diferente é selecionado para apresentar este componente de midia, prefere-se frequentemente ocupar a largura de banda limitada com o novo fluxo e parar o fluxo antigo.

Um sistema de fluxo continuo de solicitação de bloco de acordo com modalidades descritas aqui provê muitos benefícios. Deve ser entendido que um sistema viável necessita de não incluir todas as características aqui descritas, assim como algumas aplicações podem prover uma experiência adequada satisfatória com menos que a totalidade das características aqui descritas.

Fluxo Contínuo HTTP Fluxo contínuo HTTP é um tipo específico de fluxo contínuo. Com Fluxo contínuo HTTP, as fontes podem ser servidores web padrão e redes de distribuição de conteúdo (CDN) e podem usar HTTP padrão. Esta técnica pode envolver a segmentação de fluxo e a utilização de múltiplos fluxos, tudo dentro do contexto de solicitações HTTP padronizadas. A mídia, tal como vídeo, pode ao ser codificada em múltiplas taxas de bits formar versões diferentes, ou representações. Os termos "versão" e "representação" são usados como sinônimos neste documento. Cada versão ou representação pode ser quebrada em pedaços menores, talvez na ordem de poucos segundos cada, para formar segmentos. Cada segmento pode então ser armazenado em um servidor web ou CDN como um arquivo separado.

No lado do cliente, as solicitações podem ser feitas, utilizando HTTP, para os segmentos individuais que são facilmente emendados pelo cliente. 0 cliente pode mudar para diferentes taxas de dados com base na largura de banda disponivel. 0 cliente também pode solicitar múltiplas representações, cada um apresentando um componente de midia 5 diferente, e pode apresentar a midia nessas representações conjuntamente e de forma sincrona. Acionadores para comutação podem incluir ocupação de armazenador e as medições de rede, por exemplo. Quando estiver operando em estado estacionário, o cliente pode passar solicitações ao 10 servidor para manter uma ocupação do armazenador alvo.

Vantagens de fluxo continuo de HTTP podem incluir adaptação de taxa de bits, inicialização rápida, e busca, e entrega desnecessária minima. Estas vantagens vêm de controlar a entrega de ser somente em um tempo curto à 15 frente da reprodução, fazendo uso máximo da largura de banda disponivel (através dos meios de taxa de bit variável), e otimizar segmentação de fluxo e procedimentos do cliente inteligentes.

Uma descrição de apresentação de midia pode ser 20 provida a um cliente de fluxo continuo HTTP de tal forma que o cliente possa usar uma coleção de’ arquivos (por exemplo, em formatos especificados pelo 3GPP, aqui chamado de segmentos 3gp) para prover um serviço de fluxo continuo para o usuário. Uma descrição de apresentação de midia e, 25 possivelmente as atualizações desta descrição de apresentação de midia, descrevem uma apresentação de midia que é uma coleção estruturada de segmentos, cada um contendo componentes de midia de tal forma que o cliente possa apresentar a midia incluida de forma sincronizada e 30 pode prover recursos avançados, como busca, bitrates de comutação e apresentação conjunta de componentes de midia em diferentes representações. O cliente pode usar informações de descrição de apresentação de midia de diferentes maneiras para o provimento do serviço. Em particular, a partir da descrição de apresentação de midia, o cliente de fluxo continuo HTTP pode determinar quais segmentos da coleção podem ser acessados de forma que os dados são úteis para a capacidade do cliente e do usuário no serviço de fluxo continuo.

Em algumas modalidades, a descrição de apresentação de midia pode ser estática, embora os segmentos possam ser criados de forma dinâmica. A descrição de apresentação de midia pode ser a mais compacta possível para minimizar o acesso e baixar o tempo para o serviço. Conectividade de outro servidor dedicado pode ser minimizada, por exemplo, sincronização de tempo regular ou frequente entre cliente e servidor.

A apresentação de mídia pode ser construída para permitir o acesso por terminais com capacidades diferentes, tais como o acesso a diferentes tipos de rede de acesso, diferentes condições atuais de rede, tamanhos de exibição, bitrates de acesso e suporte codec. O cliente pode então extrair a informação adequada para prover o serviço de fluxo contínuo para o usuário. A descrição de apresentação de mídia também pode permitir a flexibilidade de implantação e compactação de acordo com os requisitos.

Em um caso mais simples, cada Representação Alternativa pode ser armazenada em um único arquivo 3GP, isto é, um arquivo conforme reprodução no 3GPP TS26.244, ou qualquer outro arquivo que esteja de acordo com o formato de arquivo de mídia da ISO, tal como reprodução no padrão ISO / IEC 14496-12 ou especificações derivadas (tais como o formato de arquivo 3GP descrito na Especificação Técnica 3GPP 26.244). No restante do presente documento, quando se refere a um arquivo 3GP, deve ser entendido que o padrão ISO / IEC 14496-12 e especificações derivadas pode mapear todas as funções descritas para o formato de arquivo de midia da ISO geral, tal como reprodução no padrão ISO / IEC 14496 - 12 ou quaisquer especificações derivadas. 0 cliente 5 pode então solicitar uma porção inicial do arquivo para aprender os metadados de midia (que normalmente são armazenados na caixa de cabeçalho de Filme, também referido como caixa "moov"), juntamente com os tempos De fragmentação de filem e desvios de bytes. 0 cliente pode 10 então emitir HTTP parcial solicitando a obtenção de fragmentos de filme, conforme necessário.

Em algumas modalidades, pode ser desejável dividir cada representação em vários segmentos, onde os segmentos, no caso em que o formato do segmento baseia-se 15 no formato de arquivo 3GP, então os segmentos contêm fatias de tempo não sobrepostas dos fragmentos de filme, chamados de "divisão de tempo-a-tempo". Cada um desses segmentos pode conter múltiplos fragmentos de filme e cada um pode ser um arquivo 3GP válido por direito próprio. Em uma outra 20 modalidade, a representação é dividida em um segmento inicial contendo os metadados (tipicamente a caixa "moov" de Cabeçalho de filme) e um conjunto de segmentos de midia, cada um contendo dados de midia e a concatenação do segmento inicial e qualquer segmento de midia forma um 25 arquivo 3GP válido, bem como a concatenação do segmento inicial e todos os segmentos de midia de uma representação forma um arquivo 3GP válido. Toda a apresentação pode ser formada ao reproduzir cada segmento por sua vez, mapeando marcas de tempo locais dentro do arquivo para o tempo de 30 apresentação global de acordo com o tempo de partida de cada representação.

Deve ser notado que ao longo desta descrição, referência a um "segmento" deve ser entendida para incluir qualquer objeto de dados que é total ou parcialmente construído ou lido a partir de um meio de armazenamento ou de outro modo obtido como um resultado de uma solicitação de protocolo de download de arquivo, incluindo, por 5 exemplo, uma solicitação HTTP. Por exemplo, no caso de HTTP, os objetos de dados podem ser armazenados em arquivos reais que residem em um disco ou outro meio de armazenamento ligado a ou formando parte de um servidor HTTP, ou os objetos de dados podem ser construídos por um 10 script CGI, ou outro programa executado dinamicamente, que é executado em resposta à solicitação HTTP. Os termos "arquivo" e "segmento" são usados sinonimamente no presente documento, a menos que especificado em contrário. No caso de HTTP, o segmento pode ser considerado como o corpo da 15 entidade de uma resposta à solicitação HTTP.

Os termos "apresentação" e "item de conteúdo" são usados como sinônimos neste documento. Em muitos exemplos, a apresentação é um áudio, vídeo ou outra apresentação de midia que tem um tempo reprodução de "reprodução", mas 20 outras variações são possíveis.

Os termos "bloco" e "fragmento" são usados como sinônimos neste documento, a menos que especificado de outra forma e, geralmente, referem-se a menor agregação de dados que são indexados. Com base na indexação disponível, 25 um cliente pode solicitar diferentes partes de um fragmento em diferentes solicitações de HTTP, ou pode solicitar um ou mais fragmentos consecutivos ou porções de fragmentos em uma solicitação de HTTP. No caso onde segmento baseados em formato de arquivo de mídia da ISO ou segmentos baseados em 30 formato de arquivo 3GP são usados, um fragmento tipicamente refere-se a um fragmento de filme definido como a combinação de uma caixa de cabeçalho de fragmento de filme ("moof") e uma caixa de dados de mídia ('mdat').

Aqui, uma rede portando dados é assumida como sendo baseada em pacotes, a fim de simplificar as descrições aqui, com o reconhecimento de que, após a leitura desta descrição, um versado na técnica pode aplicar 5 modalidades da presente invenção aqui descritas a outros tipos de redes de transmissão, tal como redes de fluxo de bits continuo.

Aqui, códigos FEC são assumidos para prover proteção contra os tempos de entrega de dados longos e 10 variável, a fim de simplificar as descrições aqui, com o reconhecimento de que, após a leitura desta descrição, um versado na técnica pode aplicar modalidades da presente invenção a outros tipos de questões de transmissão de dados, tal corrupção de uma inversão de bit (bit-flip) de 15 dados. Por exemplo, sem FEC, se a última porção de um fragmento solicitado chega muito mais tarde ou tem alta variância em seu tempo de chegada do que porções anteriores do fragmento, então, o tempo zapping de conteúdo pode ser grande e variável, enquantoo uso FEC e solicitações 20 paralelas, apenas a maioria dos dados solicitados por um fragmento precisam de chegar antes que possa ser recuperado, reduzindo assim o tempo zapping de conteúdo e a variabilidade no tempo zapping de conteúdo. Nesta descrição, pode ser assumido que os dados a serem 25 codificados (isto é, dados de origem) foram divididos em comprimento igual "simbolos", o que podem ser de qualquer comprimento (abaixo de um único bit), mas os simbolos podem ser de diferentes comprimentos para diferentes partes dos dados, por exemplo, tamanhos diferentes de simbolo podem 30 ser usados para diferentes blocos de dados.

Nesta descrição, a fim de simplificar as descrições aqui, supõe-se que a FEC é aplicada a um "bloco" ou "fragmento" de dados de cada vez, ou seja, um "bloco" é um "bloco fonte" para finalidades de codificação e decodificação de FEC. Um dispositivo de cliente pode usar o indexação de segmento descrito aqui para ajudar a determinar a estrutura de bloco fonte de um segmento. Um 5 versado na técnica pode aplicar modalidades da presente invenção a outro tipo de estrutura de bloco fonte, por exemplo, um bloco fonte pode ser uma porção de um fragmento, ou englobar um ou vários fragmentos ou porções de fragmentos.

Os códigos FEC considerados para uso com o fluxo continuo de solicitação de bloco são códigos FEC tipicamente sistemáticos, isto é, os simbolos fonte do bloco fonte podem ser incluidos como parte da codificação do bloco fonte e, assim, os simbolos fonte são 15 transmitidos. Como um versado na técnica irá reconhecer, as modalidades aqui descritas se aplicam igualmente bem aos códigos de FEC que não são sistemáticos. Um codificador FEC sistemático gera, a partir de um bloco fonte de simbolos fonte, um certo -número de simbolos dereparação ea 20 combinação de pelo menos alguns dos simbolos fonte e de reparação são os simbolos codificados que são enviados através do canal que representa o bloco fonte. Alguns códigos FEC podem ser úteis para gerar eficientemente tantos simbolos de reparação quantos forem necessários, 25 tais como "códigos de adição de informação" ou "códigos fonte" e exemplos destes códigos incluem "códigos de reação em cadeia" e "códigos de reação em cadeia multi-estágio". Outros códigos de FEC tal como códigos Reed-Solomon podem praticamente gerar apenas um número limitado de simbolos de reparação para cada bloco fonte.

Supõe-se em muitos destes exemplos que um cliente está acoplado a um servidor de midia ou uma pluralidade de servidores de midia e o cliente solicita midia de fluxo contínuo através de um canal ou uma pluralidade de canais a partir do servidor de mídia ou a pluralidade de servidores de mídia. No entanto, os arranjos mais envolvidos também são possíveis.

Exemplos de Benefícios

Com o fluxo contínuo de solicitação de bloco, a mídia cliente mantém um acoplamento entre o tempo dessas das solicitações desse bloco e o tempo da reprodução de mídia para o usuário. Este modelo pode manter as vantagens do modelo de "download" acima descrito, evitando algumas das desvantagens que decorrem do padrão de dissociação da reprodução de mídia a partir da entrega dos dados. O modelo de fluxo contínuo de solicitação de bloco faz uso da taxa e mecanismos de congestionamento de controle disponíveis em protocolos de transporte, tais como TCP, para assegurar que a largura de banda máxima disponível seja utilizada para dados de mídia. Além disso, a divisão da apresentação de mídia em blocos permite que cada bloco de dados de mídia codificada seja selecionado a partir de um conjunto de várias codificações disponíveis.

Esta seleção pode ser baseada em qualquer número de critérios, incluindo combinação da taxa de dada de mídia para a largura de banda disponível, mesmo quando a largura de banda disponível muda com o tempo, combinar a resolução de mídia ou a complexidade da decodificação para capacidades de cliente ou configuração, ou combinar para as preferências do usuário, como idiomas. A seleção também pode incluir o download e apresentação dos componentes auxiliares, tais como componentes de acessibilidade, closed caption, subtítulos, vídeo em linguagem de sinais, etc. Exemplos de sistemas existentes, utilizando o modelo de solicitação de bloco de fluxo contínuo incluem Move Networks™, Fluxo Continuo Suave da Microsoft e o Protocolo de Fluxo Continuo para iPhone™ da Apple.

Geralmente, cada bloco de dados de midia pode ser armazenado em um servidor como um arquivo individual e, 5 então um protocolo, tal como HTTP, é usado, em conjunto com software de servidor HTTP executado no servidor, para solicitar o arquivo como uma unidade. Tipicamente, o cliente é provido com os arquivos de metadados, que pode ser, por exemplo em formato de Linguagem de Marcação 10 Extensivel (XML) ou na formato de texto de playlist ou em formato binário, que descrevem as características da apresentação de midia, tais como as codificações disponíveis (por exemplo, largura de banda necessária, resoluções, parâmetros de codificação, tipo de midia, 15 linguagem), normalmente referida como "representações" neste documento, bem como a maneira pela qual as codificações foram divididas em blocos. Por exemplo, os metadados podem incluir um Localizador de Recursos Uniformes (URL) para cada bloco. Os URLs em si podem prover 20 um esquema de como ser prefixado com a sequência "http://" para indicar que o protocolo que deve ser usado para acessar o recurso documentado é HTTP. Outro exemplo é "ftp://" para indicar que o protocolo que deve ser utilizado é FTP.

Em outros sistemas, por exemplo, os blocos de midia podem ser construídos "on-the-fly" pelo servidor em resposta a uma solicitação do cliente que indica a parte da apresentação de midia, com o tempo, que é solicitada. Por exemplo, em caso de HTTP com o esquema de "http://", a 30 execução da solicitação deste URL provê uma resposta da solicitação que contém alguns dados específicos no corpo da entidade desta resposta da solicitação. A implementação na rede sobre como gerar essa resposta de solicitação pode ser bastante diferente, dependendo da implementação do serviço de servidor de tais solicitações.

Geralmente, cada bloco pode ser independente decodificável. Por exemplo, no caso de midia de video, cada 5 bloco pode começar com um "ponto de busca". Em alguns esquemas de codificação, um ponto de busca é referido como "pontos de acesso aleatório" ou "RAPs", embora nem todos os RAPs podem ser designados como um ponto de busca. Da mesma forma, em outros esquemas de codificação, um ponto de busca 10 começa com um quadro de "Renovação de Dados Independente", ou "IDR", no caso de codificação de video H.264, embora nem todas as IDRs possam ser designadas como um ponto de busca. Um ponto de busca é uma posição em midia de video (ou outra) em que um decodificador pode começar a decodificação 15 sem a necessidade de quaisquer dados sobre quadros anteriores ou dados ou amostras, como pode ser o caso em que um quadro ou amostra que está sendo decodificado foi codificado não de uma forma independente, mas como, por exemplo, .. a diferença entre o quadro atual e o quadro 20 prévio.

Uma preocupação nesses sistemas pode ser a capacidade de começar a reproduzir um fluxo, por exemplo, decodificação e renderização de fluxos de áudio e video recebidos usando um computador pessoal e exibindo o video 25 na tela do computador e reproduzindo o áudio através de altofalantes embutidos, ou como um outro exemplo de decodificação e renderização de fluxos de áudio e video recebidos usando uma caixa set-top e exibindo o video em um dispositivo de exibição de televisão e reproduzindo o áudio 30 através de um sistema estéreo. A principal preocupação pode ser a de minimizar o retardo entre quando um usuário decide assistir a um novo conteúdo entregue como um fluxo e toma uma ação que expressa a decisão, por exemplo, o usuário clica em um link dentro de uma janela do navegador ou no botão de play de um dispositivo de controle remoto, e quando o conteúdo começa a ser exibido na tela do usuário, denominado "tempo zapping de conteúdo". Cada um destes 5 problemas pode ser tratado por elementos do sistema aperfeiçoado aqui descrito.

Um exemplo de zapping de conteúdo é quando um usuário está assistindo a um primeiro conteúdo entregue através de um primeiro fluxo e, então o usuário decide 10 assistir a um segundo conteúdo entregue através de um segundo fluxo e inicia uma ação para começar a assistir o segundo conteúdo. O segundo fluxo pode ser enviado a partir do mesmo conjunto ou de um conjunto diferente de servidores como o primeiro fluxo. Outro exemplo de zapping de conteúdo 15 é quando um usuário visita um site e decide começar a assistir um primeiro conteúdo entregue através de um primeiro fluxo, clicando em um link dentro da janela do navegador. De um modo semelhante, um usuário pode decidir começar a reproduzir o conteúdo não a partir do inicio, mas 20 a partir de algum tempo dentro do fluxo. 0 usuário indica para o seu dispositivo cliente para procurar uma posição de tempo e o usuário pode esperar que o tempo selecionado seja processado instantaneamente. Minimizar o tempo de zapping conteúdo é importante para assistir a um video para 25 permitir que os usuários tenham um uma experiência de navegação de conteúdo de rápido e de alta qualidade ao buscar e ter uma amostra de uma variedade de conteúdos disponíveis.

Recentemente, tornou-se comum a prática de 30 considerar o uso de códigos de Correção de Erro Direta (EEC) para proteção de transmitir em fluxo continuo a midia durante a transmissão. Quando enviados por uma rede de pacote, os exemplos dos quais incluem a Internet e redes sem fios, como aqueles padronizados por grupos tais como 3 GPP, 3GPP2 e DVB, o fluxo fonte é colocado em pacotes, como se ele fosse gerado ou tivesse disponibilizado, e, assim, os pacotes podem ser usados para portar o fluxo fone ou de 5 conteúdo na ordem em que é gerado ou disponibilizado para os receptores.

Em uma aplicação tipica de códigos de FEC para estes tipos de cenários, um codificador pode usar código FEC na criação de pacotes de reparação, que são então 10 enviados em adição aos pacotes fonte originais contendo o fluxo fonte. Os pacotes de reparação têm uma propriedade que, quando ocorre perda de pacote fonte, os pacotes de reparação recebidos podem ser usados para recuperar os dados contidos nos pacotes fonte perdidos. Pacotes de 15 reparação podem ser utilizados para recuperar o conteúdo de pacotes fonte perdidos que são perdidos completamente, mas podem também ser utilizados para recuperar quando perda de pacote parcial ocorre, quer pacotes de reparação integralmente recebidos ou mesmo pacotes de reparação 20 parcialmente recebidos. Assim, pacotes de reparação total ou parcialmente recebidos podem ser usados para recuperar pacotes fonte total ou parcialmente perdidos.

Em ainda outros exemplos, outros tipos de corrupção podem ocorrer com os dados enviados, por exemplo, 25 os valores de bits podem ser invertidos, e, assim, os pacotes de reparação podem ser utilizados para corrigir a corrupção e prover recuperação tão precisa quanto possivel dos pacotes fonte. Em outros exemplos, o fluxo fonte não é necessariamente enviado em pacotes discretos, mas em vez 30 disso pode ser enviado, por exemplo, como um fluxo de bits continuo. Existem muitos exemplos de códigos de FEC que podem ser usados para prover proteção de um fluxo fonte.

Códigos Reed-Solomon são bem conhecidos correcção de erros e apagamento em sistemas de comunicação. Para a correção de apagamento sobre, por exemplo, redes de dados de pacotes, uma implementação bem conhecida eficiente de códigos Reed- Solomon utiliza matrizes de Cauchy ou Vandermonde como descrito em L. Rizzo, "Effective Erasure codes for reliable computer communication protocols", Computer Communication Review, 27(2):24-3β (Abril de 1997) (doravante "Rizzo") e Bloemer, et al, "Na XOR-Based Erasure-Resilient Coding Scheme", Relatório Técnico TR-95-48, International Computer Science Institute, Berkeley , Califórnia (1995) (doravante "XOR-Reed-Solomon") ou em outro lugar.

Outros exemplos de códigos de FEC incluem códigos LDPC, códigos de reação de cadeia, tais como os descritos em Luby I e códigos de reação de cadeia multi-estágio tal em Shokrollahi I.

Exemplos do processo de decodificação de FEC para variantes de Reed-Solomon são descritos em Rizzo e XOR- Reed-Solomon. Em tais exemplos, decodificação pode ser aplicada após pacotes de dados de reparação e fonte suficientes terem sido recebidos. O processo de decodificação pode ser computacionalmente intensivo e, dependendo dos recursos da CPU disponíveis, isto pode levar um tempo considerável para completar, em relação ao periodo de tempo gerado pela midia no bloco. 0 receptor pode levar em consideração este periodo de tempo necessário para decodificar ao calcular o retardo necessário entre o inicio do recebimento do fluxo de midia e reprodução da midia. Este retardo devido à decodificação é percebido pelo usuário como um retardo entre sua solicitação por um fluxo de midia particular e no inicio da reprodução. É, portanto, desejável minimizar este retardo.

Em muitas aplicações, os pacotes podem ser adicionalmente subdivididos em simbolos nos quais o processo de EEC é aplicado. Um pacote pode conter um ou mais simbolo (ou menos do que um simbolo, mas geralmente simbolos que não são divididos em grupos de pacotes a menos que as condições de erro entre grupos de pacotes seja conhecida por ser altamente correlacionada). Um simbolo pode ter qualquer tamanho, mas muitas vezes o tamanho de um simbolo é no máximo igual ao tamanho do pacote. Simbolos fonte são aqueles simbolos que codificam os dados que devem ser transmitidos. Simbolos de reparação são simbolos gerados a partir de simbolos fonte, direta ou indiretamente, que são em adição aos simbolos fonte (isto é, os dados a serem transmitidos podem ser inteiramente recuperados se todos os simbolos fonte estiverem disponíveis e nenhum dos simbolos de reparação estiver disponíveis.

Alguns códigos de EEC podem ser baseados em bloco, em que as operações de codificação dependem do simbolo (s) que estão em um bloco e podem ser independentes dos simbolos não naquele bloco. Com codificação baseada em blocos, um codificador EEC pode gerar simbolos de reparação para um bloco de simbolos fonte naquele bloco, então mover para o próximo bloco e não precisa se referir aos simbolos fonte que não sejam aqueles do bloco atual a ser codificado. Em uma transmissão, um bloco fonte compreendendo simbolos fonte pode ser representado por um bloco codificado compreendendo simbolos codificados (que pode ser alguns simbolos fonte, alguns simbolos de reparação, ou ambos). Com a presença de simbolos de reparação, nem todos os simbolos fonte são necessários em cada bloco codificado.

Para alguns códigos de FEC, nomeadamente Reed- Solomon, tempo de codificação e decodificação pode crescer de modo impraticável conforme o número de simbolos codificados por bloco fonte cresce. Assim, na prática, há muitas vezes um limite prático superior (255 é um limite aproximado prático para algumas aplicações) sobre o número total de simbolos codificados que podem ser gerados por bloco fonte, especialmente em um caso tipico em que a codificação de Reed-Solomon ou processo de decodificação é feita por hardware personalizado, por exemplo, os processos de MPE-FEC que usam códigos Reed-Solomon incluidos como parte do padrão DVB-H para a proteção de fluxo contra a perda de pacotes são implementados em hardware especializado dentro de um telefone celular que é limitado a 255 simbolos codificados Reed-Solomon total por bloco fonte. Uma vez que os simbolos são muitas vezes necessários para ser colocados em cargas úteis de pacote separadas, este coloca um limite superior prático ligado no comprimento máximo do bloco fonte a ser codificado. Por exemplo, se uma carga útil do pacote está limitada a 1024 bytes ou menos e cada pacote porta um simbolo codificado, então um bloco fonte codificado pode ser, no máximo, de 255 kilobytes, e este é também, naturalmente, um limite superior para o tamanho do próprio bloco fonte.

Outras preocupações, tal como ser capaz de decodificar os blocos de código com rapidez suficiente para acompanhar a taxa de fluxo continuo fonte, para minimizar a latência introduzida pela decodificação FEC, e usar apenas uma pequena fração da CPU disponíveis no dispositivo de recepção em qualquer ponto no tempo durante a decodificação FEC são dirigidas por elementos aqui descritos, bem como lidar com

A necessidade é de prover uma solução de entrega de fluxo continuo robusta e escalável que permita que os componentes do sistema falhem sem afetar adversamente a qualidade dos fluxos entregues a receptores.

Um sistema de fluxo continuo de solicitação de bloco precisa suportar alterações na estrutura ou metadados da apresentação, por exemplo, alterações no número de codificações de midia disponíveis ou mudanças nos parâmetros das codificações de midia, tais como taxa de bits, resolução, relação de aspecto, codecs de áudio ou video ou parâmetros de codec de mudanças em outros metadados tais como URLs associados com os arquivos de conteúdo. Tais alterações podem ser requeridas para um número de razões, incluindo editar juntamente o conteúdo a partir de fontes diferentes, tais como publicidade ou diferentes segmentos de uma maior apresentação, a modificação de URLs ou outros parâmetros que se tornam necessárias, como resultado de alterações na infraestrutura de serviço, por exemplo, devido a alterações de configuração, falhas de equipamento ou recuperação de falhas de equipamentos ou outros motivos. Métodos existem em que uma apresentação pode ser controlada por um arquivo de playlist continuamente atualizado. Uma vez que este arquivo é continuamente atualizado, então pelo menos algumas das alterações descritas acima podem ser feitas dentro dessas atualizações. Uma desvantagem do método convencional é que os dispositivos clientes devem continuamente recuperar, também conhecido como "checagem" (poll), o arquivo de playlist, colocar carga na infraestrutura de serviço e que este arquivo não pode ser armazenado por mais tempo do que o intervalo de atualização, tornando a tarefa para a infraestrutura de serviço muito mais dificil. Esta questão é abordada por elementos aqui contidos para que as atualizações do tipo descrito acima sejam providas sem a necessidade de checagem continua por clientes para o arquivo de metadados. 5 Outro problema, especialmente nos serviços ao vivo, normalmente conhecido de distribuição de broadcast, é a falta de capacidade de o usuário visualizar o conteúdo que foi transmitido antes do tempo quando o usuário aderiu ao programa. Normalmente, a gravação pessoal local consome 10 armazenamento local desnecessário ou não é possivel quando o cliente não está sintonizado com o programa ou é proibido pelas regras de proteção de conteúdo. Gravação de rede e visualização de desvio de tempo é preferido, mas requer conexões individuais do usuário para o servidor e um 15 protocolo de entrega separado e infraestrutura do que os serviços ao vivo, resultando em infraestrutura duplicada e os custos do servidor significativos. Este é também abordado por elementos aqui descritos. Visão Geral do Sistema

Uma modalidade da invenção é descrita com referência à figura 1, que mostra um diagrama simplificado de um sistema de fluxo continuo de solicitação de bloco, incorporando a invenção. Na figura. 1, um sistema de fluxo continuo de 25 bloco 100 é ilustrado, o qual inclui infraestrutura de serviço de bloco ("BSI") 101, por sua vez compreende um sistema de ingestão 103 para ingerir o conteúdo 102, que prepara conteúdo e embala para o serviço por um servidor de fluxo continuo HTTP 104, armazenando em um armazenamento de 30 conteúdo 110 que é acessivel tanto pelo sistema de ingestão 103 quanto pelo servidor de fluxo continuo HTTP 104. Como mostrado, o sistema 100 pode também incluir um cache de HTTP 106. Na operação, um cliente 108, como um cliente de fluxo continuo HTTP, envia solicitações 112 para o servidor de fluxo continuo HTTP 104 e recebe respostas 114 do servidor de fluxo continuo HTTP 104 ou cache HTTP 106. Em cada caso, os elementos mostrados na figura 1 podem ser implementados, pelo menos em parte, no software, nela compreendendo código de programa que é executado em um processador ou outros eletrônicos.

O conteúdo pode incluir filmes, áudio e video plano 2D, video 3D, outros tipos de video, imagens, textos cronometrados, metadados cronometrados ou similares. Alguns conteúdos podem envolver dados que devem ser apresentados ou consumidos de uma forma cronometrada, tal como dados para apresentação de informação auxiliar (identificação da estação, publicidade, cotações de ações, sequências Flash™, etc.), juntamente com outras midias que estão sendo reproduzidas. Outras apresentações hibridas também podem ser usadas que combinam outra midia e/ou vão além de meramente áudio e video.

Tal como ilustrado na figura 2, blocos de midia podem ser armazenados dentro de uma infraestrutura de serviço de bloco 101(1), que poderia ser, por exemplo, um servidor HTTP, um dispositivo Rede de Entrega de Conteúdo, um proxy HTTP, proxy FTP ou servidor, ou algum outro servidor de midia ou sistema. Infraestrutura de serviço de bloco 101(1) está ligada a uma rede 122, que pode ser, por exemplo, uma rede de Protocolo de Internet ("IP"), tal como a Internet. Um sistema cliente de fluxo continuo de solicitação de bloco é mostrado com seis componentes funcionais, ou seja, um seletor de bloco 123, provido com os metadados descritos acima e realizando uma função de seleção de blocos ou blocos parciais a ser solicitados dentre a pluralidade de blocos disponíveis indicados pelos metadados, um solicitante de bloco 124, que recebe instruções de solicitação provenientes do seletor de bloco 123 e executa as operações necessárias para enviar uma solicitação para o bloco especificado, porções de um bloco, ou múltiplos blocos, que bloquear a infraestrutura de serviço 101(1) na rede 122 e para receber os dados que compreendem o bloco em troca, bem como um armazenador de bloco 125, um monitor de armazenador 126, um decodificador de midia e um ou mais transdutores de midia 128 que facilita consumo de midia.

Dados de bloco recebidos pelo solicitante de bloco 124 são passados para o armazenamento temporário para armazenador de bloco 125, que armazena os dados de midia. Alternativamente, os dados de bloco recebidos podem ser armazenados diretamente no armazenador de bloco 125, como ilustrado na figura 1. Decodificador de midia 127 é provido com os dados de midia pelo armazenador de bloco 125 e executa tais transformações sobre estes dados como são necessárias para prover a entrada adequada para transdutores de midia 128, que renderizam a midia em uma forma apropriada para o usuário ou outro consumo. Exemplos de transdutores de midia incluem dispositivos de visualização, como os encontrados em telefones celulares, sistemas de computadores ou televisores, e também podem incluir dispositivos de processamento de áudio, como alto- falantes ou fones de ouvido.

Um exemplo de um decodificador de midia seria uma função que transforma os dados no formato descrito no padrão de codificação de video H.264 em representações analógicas ou digitais de quadros de video, tais como um mapa de pixel em formato YUV com marcas de tempo de apresentação associadas a cada quadro ou amostra.

Monitor de armazenador 126 recebe a informação relativa ao conteúdo de armazenador de bloco 125 e, com base nesta informação e, possivelmente, em outras informações, provê a entrada para o seletor de bloco 123, que é usado para determinar a seleção de blocos para solicitar, tal como é aqui descrito.

Na terminologia usada aqui, cada bloco tem um "tempo de reprodução" ou "duração" que representa a quantidade de tempo que levaria para o receptor reproduzir a midia incluida nesse bloco em velocidade normal. Em alguns casos, a reprodução da midia dentro de um bloco pode 10 depender de ter dados já recebidos a partir de blocos anteriores. Em casos raros, a reprodução de alguma midia em um bloco pode depender de um bloco subsequente, caso em que o tempo de reprodução para o bloco é definido com respeito à midia que pode ser reproduzida dentro do bloco sem 15 referência ao bloco subsequente, e o tempo de reprodução para o bloco seguinte é aumentado pelo tempo de reprodução da midia dentro deste bloco que só pode reproduzir depois de ter recebido o bloco seguinte. Uma vez que incluir a midia em. um bloco que depende de blocos subsequentes é um 20 caso raro, no restante desta descrição assume-se que midia em um bloco não depende de blocos seguintes, mas nota-se que os versados na técnica reconhecerão que esta variante pode ser facilmente adicionada às modalidades descritas a seguir.

O receptor pode ter controles como "pausa", "direta rápida", "reversa", etc., que pode resultar no bloco que está sendo consumido por reprodução em um ritmo diferente, mas se o receptor pode obter e decodificar cada sequência de blocos consecutiva de um tempo total igual ou 30 inferior a seu tempo de reprodução agregado excluindo o último bloco na sequência, então o receptor pode apresentar a midia para o usuário sem parar. Em algumas descrições aqui contidas, uma posição particular no fluxo de midia é referida como um "tempo" particular na midia, que corresponde ao tempo que teria decorrido entre o inicio da reprodução da midia e o momento em que a posição particular no fluxo de video é alcançada. 0 tempo ou a posição em um 5 fluxo de midia é um conceito convencional. Por exemplo, onde o fluxo de video é composto por 24 quadros por segundo, poderia se dizer que o primeiro quadro tem uma posição ou tempo de t = 0,0 segundos e poderia se dizer que 241° quadro tem uma posição ou tempo de t = 10,0 segundos.

Naturalmente, em um fluxo de video baseado em quadro, posição ou tempo não precisa de ser continuo, como cada um dos bits no fluxo a partir do primeiro bit do 241° quadro até um pouco antes do primeiro bit do 242° do quadro pode ter todos o mesmo valor de tempo.

Adotando a terminologia acima, um sistema de fluxo continuo de solicitação de bloco (BRSS) compreende um ou mais clientes que fazem solicitações a um ou mais servidores de conteúdo (por exemplo, servidores HTTP, servidores FTP, etc.). Um sistema de ingestão compreende um 20 ou mais processadores de ingestão, em que um processador de ingestão recebe o conteúdo (em tempo real ou não), processa o conteúdo para uso pelos BRSS e armazena em memória acessivel aos servidores de conteúdo, possivelmente também, juntamente com metadados gerados pelo processador de 25 ingestão.

Os BRSS também podem conter caches de conteúdo que coordenam com os servidores de conteúdo. Os servidores de conteúdo e caches de conteúdo podem ser servidores convencionais HTTP e caches HTTP que recebem as 30 solicitações de arquivos ou segmentos em forma de solicitações HTTP que incluem um URL, e podem também incluir um intervalo de byte, de modo a solicitar menos do que todo o arquivo ou segmento indicado pelo URL. Os clientes podem incluir um cliente HTTP convencional, que faz solicitações de servidores HTTP e lida com as respostas a essas solicitações, onde o cliente HTTP é impulsionado por um novo sistema cliente que formula solicitações, passa para o cliente HTTP, obtém respostas do cliente HTTP e processa as respostas (ou armazenar, transformar, etc.), a fim de prover-lhes a um reprodutor de apresentação para reprodução por um dispositivo de cliente. Normalmente, o sistema cliente não sabe com antecedência qual midia será necessária (assim como as necessidades podem depender da entrada do usuário, mudanças na entrada do usuário, etc.), por isso é dito ser um sistema de "fluxo continuo" em que a midia é "consumida" assim que for recebida, ou pouco depois. Como resultado, os retardos de resposta e as restrições de largura de banda podem causar retardos em uma apresentação, tal como causar uma pausa em uma apresentação como o fluxo de capturas até onde o usuário está em consumir a apresentação.

A fim de prover uma apresentação que é percebida como sendo de boa qualidade, um número de pormenores pode ser implementado no BRSS, quer no final do cliente, no final da ingestão ou ambos. Em alguns casos, os pormenores que são implementados são feitos em consideração de, e para tratar, a interface de cliente-servidor na rede. Em algumas modalidades, tanto o sistema cliente quanto o sistema de ingestão estão cientes da melhora enquanto que em outras modalidades, apenas um lado está ciente da melhora. Nesses casos, os benefícios do sistema inteiro do aprimoramento embora um dos lados não esteja ciente dele, enquanto em outros, o beneficio só acumula se ambos os lados estão cientes disso, mas quando um lado não tem conhecimento, ele ainda opera sem falhar.

Tal como ilustrado na figura 3, o sistema de ingestão pode ser implementado como uma combinação de hardware e software, de acordo com várias modalidades. 0 sistema de ingestão pode compreender um conjunto de 5 instruções que podem ser executadas para fazer com que o sistema execute qualquer uma ou mais das metodologias aqui discutidas. 0 sistema pode ser realizado como uma máquina especifica na forma de um computador. 0 sistema pode ser um computador de servidor, um computador pessoal (PC), ou 10 qualquer outro sistema capaz de executar um conjunto de instruções (sequencial ou de outra forma) que especificam as ações a serem tomadas por esse sistema. Além disso, embora apenas um único sistema seja ilustrado, o termo "sistema" deve também ser interpretado como incluindo 15 qualquer coleção de sistemas que, individual ou conjuntamente executam um conjunto (ou vários conjuntos) de instruções para realizar qualquer uma ou mais das metodologias aqui discutidas. - O sistema de ingestão pode incluir o processador 20 de ingestão 302 (por exemplo, uma unidade de processamento central (CPU)), uma memória 304, que pode armazenar o código de programa durante a execução, e armazenamento em disco 306, todos os quais se comunicam uns com os outros através de um barramento 300. O sistema pode também incluir 25 uma unidade de exibição de video 308 (por exemplo, um display de cristal liquido (LCD) ou tubo de raios catódicos (CRT)). 0 sistema também pode incluir um dispositivo de entrada alfanumérico 310 (por exemplo, um teclado), e um dispositivo de interface de rede 312 para a recepção de 30 fonte de conteúdo e entrega de armazenamento de conteúdo.

A unidade de armazenamento em disco 306 pode incluir um meio legível por máquina no qual pode ser armazenado um ou mais conjuntos de instruções (por exemplo, o software) que incorporam qualquer um ou mais dos métodos ou funções aqui descritos. As instruções podem também residir, completamente ou pelo menos parcialmente, no interior da memória 304 e/ou no interior do processador de ingestão 302 durante a execução do mesmo pelo sistema, com a memória 304 e o processador de ingestão 302 constituindo também midia legivel por máquina.

Tal como ilustrado na figura 4, o sistema cliente pode ser implementado como uma combinação de hardware e software, de acordo com várias modalidades. O sistema cliente pode compreender um conjunto de instruções que podem ser executadas para fazer com que o sistema execute qualquer uma ou mais das metodologias aqui discutidas. O sistema pode ser executado como uma máquina especifica na forma de um computador. O sistema pode ser um computador de servidor, um computador pessoal (PC), ou qualquer outro sistema capaz de executar um conjunto de instruções (sequencial ou de outra forma) que especificam as ações a serem tomadas por esse sistema. Além disso,. embora apenas um único sistema seja ilustrado, o termo "sistema" deve também ser interpretado como incluindo qualquer coleção de sistemas que, individual ou conjuntamente executam um conjunto (ou vários conjuntos) de instruções para realizar qualquer uma ou mais das metodologias aqui discutidas.

O sistema cliente pode incluir o processador de cliente 402 (por exemplo, uma unidade de processamento central (CPU)), uma memória 404, que pode armazenar o código de programa durante a execução, e armazenamento em disco 406, todos os quais se comunicam uns com os outros através de um barramento 400. O sistema pode também incluir uma unidade de exibição de video 408 (por exemplo, um display de cristal liquido (LCD) ou tubo de raios catódicos (CRT)). O sistema também pode incluir um dispositivo de entrada alfanumérico 410 (por exemplo, um teclado), e um dispositivo de interface de rede 412 para enviar solicitações e receber respostas.

A unidade de armazenamento em disco 406 pode incluir um meio legivel por máquina no qual pode ser armazenado um ou mais conjuntos de instruções (por exemplo, software) que incorporam qualquer um ou mais dos métodos ou funções aqui descritos. As instruções podem também residir, completamente ou pelo menos parcialmente, no interior da memória 404 e/ou no interior do processador de cliente 402 durante a execução do mesmo pelo sistema, com a memória 404 e o processador de cliente 402 também constituindo midia legivel por máquina.

Uso de Formato de Arquivo 3GPP O formato de arquivo 3GPP ou qualquer outro arquivo baseado no formato de arquivo de midia baseado em ISO, como o formato de arquivo MP4 ou formato de arquivo 3GPP2, pode ser utilizado como recipiente para o formato de fluxo continuo HTTP com as seguintes características. Um indice de segmento pode ser incluído em cada segmento para sinalizar desvios de tempo e intervalos de byte, de modo que o cliente pode baixar as partes apropriadas de arquivos ou segmentos de midia, conforme necessário. Tempo de apresentação global da apresentação de mídia inteira e tempo local dentro de cada arquivo 3GP ou segmento de mídia pode ser precisamente alinhado. Faixas dentro de um arquivo 3GP ou segmento de mídia podem ser precisamente alinhadas. Faixas em toda representações também podem ser alinhadas através da atribuição de cada uma delas com o cronograma global, tal que a mudança através de representação pode ser perfeita e apresentação conjunta de componentes de mídia em diferentes representações pode ser síncrona.

O formato de arquivo pode conter um perfil para Fluxo Continuo Adaptativo com as seguintes propriedades. Todos os dados do filme podem ser contidos em fragmentos de filmes - a caixa "moov" não pode conter qualquer informação de amostra. Dados de amostra de áudio e video podem ser intercalados, com requisitos semelhantes como para o perfil de download progressivo, conforme especificado em TS26.244. A caixa "moov" pode ser colocada no inicio do processo, seguida por dados de desvio de fragmento, também referidos como um indice de segmento, que contém informações de desvio no tempo e intervalos de bytes para cada fragmento ou pelo menos um subconjunto de fragmentos no segmento contendo.

Também pode ser possivel para a Descrição de Apresentação de Midia para arquivos de referência que seguem o perfil existente de Download Progressivo. Neste caso, o cliente pode usar a descrição de apresentação de midia simplesmente selecionando a versão alternativa adequada dentre várias versões disponíveis. Os clientes também podem usar solicitações HTTP parciais com arquivos compatíveis com o perfil de download progressivo para solicitar subconjuntos de cada versão alternativa e, assim, implementar uma forma menos eficiente de fluxo contínuo adaptativo. Neste caso, as diferentes representações contendo a mídia no perfil de download progressivo podem ainda aderir a um cronograma comum global para habilitar a troca perfeita em representações.

Visão Geral de Métodos Avançados Nas seções seguintes, os métodos para melhoria de sistemas de fluxo contínuo de solicitação de bloco são descritos. Deve ser entendido que alguns destes melhoramentos podem ser utilizados com ou sem outros destes melhoramentos, dependendo das necessidades da aplicação. Na operação geral, um receptor faz solicitações de um servidor ou outro transmissor para blocos específicos ou porções de blocos de dados. Arquivos, também chamados de segmentos, podem conter vários blocos e estão associados com uma 5 representação de uma apresentação de midia.

Preferivelmente, informação de indexação, também chamada de "indexação de segmento" ou "mapa de segmento", é gerada a qual provê um mapeamento a partir de tempos de reprodução ou decodificação para desvios de bytes de blocos 10 correspondentes ou fragmentos dentro de um segmento. Este indexação de segmento pode ser incluído dentro do segmento, tipicamente, no inicio do segmento (pelo menos algum do mapa de segmento está no inicio) e é muitas vezes pequeno. O Índice de segmento pode também ser provido em um indice 15 de segmento separado ou arquivo. Especialmente nos casos em que o índice de segmento está contido no segmento, o receptor pode baixar alguns ou a totalidade deste mapa de segmento de forma rápida e subsequentemente utilizar este para determinar o mapeamento entre desvios de tempo e as 20 correspondentes posições de byte de fragmentos associados a esses desvios de tempo dentro do arquivo.

Um receptor pode usar o desvio de byte para solicitar dados a partir dos fragmentos associados com desvio de tempo particulares, sem ter de baixar todos os 25 dados associados com outros fragmentos não associados com os desvios de tempo de interesse. Desta forma, o mapa de segmento ou indexação de segmento pode melhorar significativamente a capacidade de um receptor para acessar diretamente as porções do segmento que são relevantes para 30 os desvio de tempo atuais de interesse, com benefícios, incluindo melhor tempos de zapping de conteúdo, a capacidade de mudar rapidamente de uma representação para outra conforme as condições da rede variam, e desperdício reduzido de recursos de rede de download de midia que não é reproduzido em um receptor.

No caso, comutar de uma representação (aqui referida como a representação "comutada de") para uma outra 5 representação (aqui referida como representação "comutada para") é considerada, o índice de segmento pode também ser usado para identificar o tempo de partida de um ponto de acesso aleatório na representação comutada-para para identificar a quantidade de dados a ser solicitada na representação comutada-de de comutação para assegurar que comutação é habilitada no sentido de que mídia na representação comutada-de é baixada até um tempo de apresentação de tal modo que a reprodução de representação comutada-para pode perfeitamente iniciar a partir do ponto 15 de acesso aleatório.

Os blocos representam segmentos da mídia de vídeo ou outra mídia que o receptor solicitante necessita para gerar a saída para o usuário do receptor. O receptor da mídia pode ser um dispositivo de cliente, tal como quando o 20 receptor recebe o conteúdo de um servidor que transmite o conteúdo. Exemplos incluem caixas set-top, computadores, consoles de jogos, especialmente televisores equipados, aparelhos portáteis, especialmente equipados com telefones celulares, ou outros receptores clientes.

Muitos métodos de gerenciamento de armazenador avançados são aqui descritos. Por exemplo, um método de gerenciamento de armazenador permite aos clientes solicitar blocos da mais alta qualidade de mídia que podem ser recebidos em tempo para ser reproduzidos com continuidade.

Uma característica de tamanho variável de bloco melhora a eficiência de compressão. A capacidade de ter várias conexões para a transmissão de blocos para o dispositivo solicitante enquanto limita a frequência das solicitações proporciona um desempenho melhorado de transmissão. Blocos de dados parcialmente recebidos podem ser usados para continuar a apresentação de midia. A conexão pode ser reutilizada para vários blocos sem ter de confirmar a conexão 5 no inicio para um determinado conjunto de blocos.

Consistência na seleção de servidores, dentre vários possiveis servidores de vários clientes é melhorada, o que reduz a frequência de conteúdo duplicado em servidores próximos e aumenta a probabilidade de que um servidor 10 contém um arquivo inteiro. Os clientes podem solicitar blocos de midia com base em metadados (como codificações de midia disponíveis) que são incorporados nos URLs para os arquivos contendo os blocos de midia. Um sistema pode prover para o cálculo e minimização da quantidade de tempo 15 de armazenador necessária antes de reprodução do conteúdo pode começar sem incorrer pausas subsequentes na reprodução da midia. Largura de banda disponível pode ser compartilhada entre vários blocos de midia, ajustadas como o tempo de reprodução de cada abordagem de bloco., de modo 20 que, se necessário, uma parte maior da largura de banda disponível possa ser alocada para o bloco com o tempo mais próximo de reprodução.

Fluxo continuo HTTP pode empregar metadados. Metadados de nivel de apresentação incluem, por exemplo, a 25 duração do fluxo, codificações disponíveis (bitrates, codecs, resoluções espaciais, taxas de quadros, linguagem, tipos de midia), ponteiros para metadados de fluxo para cada codificação e proteção de conteúdo (informação de gerenciamento de direitos digitais (DRM)). Metadados de 30 fluxo podem ser URLs para os arquivos de segmento.

Metadados de segmento podem incluir intervalo de bytes versus informações de tempo para as solicitações dentro de um segmento e identificação de pontos de acesso aleatório (RAPs) ou outros pontos de busca, em que algumas ou todas essas informações podem ser parte de um indexação de segmento ou mapa de segmento.

Fluxos podem incluir múltiplas codificações do mesmo conteúdo. Cada codificação pode então ser dividida em segmentos em que cada segmento corresponde a uma unidade de armazenamento ou arquivo. No caso de HTTP, um segmento normalmente é um recurso que pode ser referenciado por um URL e a solicitação de tal URL resulta no retorno do 10 segmento como o corpo da entidade da mensagem de resposta de solicitação. Segmentos podem compreender vários grupos de imagens (GOP). Cada GOP pode ainda compreender vários fragmentos onde a indexação de segmento provê informação de desvio byte / tempo para cada fragmento, ou seja, a unidade 15 de indexação é um fragmento.

Fragmentos ou porções de fragmentos podem ser solicitados através de conexões TCP paralelas para aumentar a capacidade de transmissão. Isso pode atenuar os problemas que surgem quando se compartilha conexões em um link 20 gargalo ou quando conexões são perdidas devido ao congestionamento, aumentando assim a velocidade global e confiabilidade de entrega, que pode melhorar substancialmente a velocidade e a confiabilidade do tempo zapping de conteúdo. Largura de banda pode ser trocada por 25 latência por excesso de solicitação, mas cuidados devem ser tomados para evitar fazer solicitações em demasia distante no futuro que podem aumentar o risco de esgotamento.

Várias solicitações para os segmentos no mesmo servidor podem ser encadeadas (fazendo a solicitação 30 seguinte, antes da solicitação atual estar completa) para evitar retardos de inicialização de TCP repetitivos. As solicitações de fragmentos consecutivos podem ser agregadas em uma única solicitação.

Alguns CDNs preferem arquivos grandes e podem acionar busca de fundo de um arquivo inteiro a partir de um servidor de origem quando primeiro ver uma solicitação de faixa. A maioria dos CDNs, no entanto, atendem às 5 solicitações de faixa de cache, se os dados estiverem disponíveis. Por conseguinte, pode ser vantajoso ter alguma porção das solicitações de cliente sendo para um arquivo de segmento completo. Estas solicitações podem mais tarde ser canceladas, se necessário.

Pontos de comutação válidos podem ser pontos de busca, especificamente RAPs, por exemplo, no fluxo alvo. Implementações diferentes são possíveis, tais como estruturas fixas de GOP ou alinhamento de RAPs pelos fluxos (com base no inicio da midia ou com base nas GOPs).

Em uma modalidade, os segmentos e GOPs podem ser alinhadas através de fluxos de taxa diferentes. Nesta modalidade, GOPs podem ser de tamanho variável e podem conter vários fragmentos, mas fragmentos não estão alinhados entre os diferentes fluxos de taxa.

Em algumas modalidades, a redundância de arquivo pode ser empregue com vantagem. Nestas modalidades, um código de apagamento é aplicado a cada fragmento.para gerar versões redundantes dos dados. De preferência, a formatação de origem não é alterada devido ao uso de FEC, e os segmentos de reparação adicionais, por exemplo, como representação dependente da representação original, que contem dados de reparação de FEC são geradas e disponibilizadas como uma etapa adicional no sistema de ingestão. O cliente, que é capaz de reconstruir um 30 fragmento usando dados de origem apenas para esse fragmento, só pode solicitar dados de origem para o fragmento dentro do segmento proveniente dos servidores. Se os servidores não estão disponíveis ou a conexão para os servidores são lentas, o que pode ser determinado antes ou depois da solicitação de dados de origem, os dados de reparação adicionais podem ser requeridos para o fragmento a partir do segmento de reparação, o que diminui o tempo 5 fiável para entregar o suficiente de dados para recuperar o fragmento, possivelmente através de decodificação de FEC para usar uma combinação de fonte recebida de dados de reparação para recuperar os dados fonte do fragmento. Além disso, os dados de reparação adicionais podem ser 10 solicitados para permitir a recuperação do fragmento se um fragmento torna-se urgente, ou seja, o seu tempo de reprodução torna-se iminente, o que aumenta a percentagem de dados para aquele fragmento em uma conexão, mas é mais eficiente do que fechar outras conexões sobre o link para liberar largura de banda. Isto também pode reduzir o risco de esgotamento a partir da utilização de conexões paralelas.

O formato de fragmento pode ser de um fluxo armazenado em tempo real de pacotes de Protocolo de 20 Transporte (RTP) com sincronização de áudio / video alcançadas através de protocolo de controle de transporte RTCP em tempo real.

O formato do segmento pode também ser um fluxo armazenado de pacotes MPEG-2 TS com sincronização de áudio 25 / video alcançando temporização interna MPEG-2 TS.

Uso de Sinalização e/ou Criação de Bloco para Tornar Fluxo Continuo mais Eficiente Uma série de recursos podem ser usados ou não, em um sistema de fluxo continuo de solicitação de bloco, para 30 prover um melhor desempenho. O desempenho pode estar relacionado com a capacidade de reprodução de uma apresentação sem parar, obtenção de dados de midia dentro das restrições de largura de banda, e/ou fazê-lo dentro dos recursos limitados de processadores em um sistema cliente, de servidor e/ou de ingestão. Algumas destas características serão agora descritas.

Indexação em Segmentos Para formular solicitações GET parciais de fragmentos de filmes, o cliente pode ser informado sobre o desvio de byte e tempo de partida na decodificação ou tempo de apresentação de todos os componentes de midia contidos nos fragmentos dentro do arquivo ou segmento e também 10 fragmentos que começam ou contêm Pontos de Acesso Aleatório (e assim são adequados para serem utilizados como pontos de comutação entre representações alternativas), em que esta informação é muitas vezes referida como a indexação de segmento ou mapa de segmento. o tempo de partida em 15 decodificação ou tempo de apresentação pode ser expressa diretamente ou pode ser expressa como deltas em relação a um tempo de referência.

Estas informações de indexação de desvio de tempo e byte pode exigir pelo menos 8 bytes de dados por 20 fragmento de filme. Como um exemplo, para um filme de duas horas contido dentro de um único arquivo, com fragmentos de filme 500ms, este seria um total de cerca de 112 kilobytes de dados. Download de todos esses dados quando se inicia uma apresentação pode resultar em um retardo de inicialização adicional significativo. No entanto, os dados de desvio de byte e tempo podem ser codificados hierarquicamente, de modo que o cliente pode encontrar rapidamente um pequeno pedaço de tempo e dados de desvio relevantes para o ponto da apresentação em que ele deseja 30 iniciar. A informação pode também ser distribuída dentro de um segmento de tal modo que algum refinamento do indice de segmento pode ser localizado intercalado com os dados de midia.

Note-se que se a representação é segmentada em tempos em múltiplos segmentos, a utilização da presente codificação hierárquica pode não ser necessária, conforme os dados de desvio e tempo para cada segmento pode já ser 5 bastante pequeno. Por exemplo, se os segmentos são um minuto em vez de duas horas no exemplo acima, a informação de indexação de desvio tempo-byte é de cerca de 1 kilobyte de dados, que pode tipicamente caber dentro de um pacote de TCP / IP único.

Diferentes opções são possíveis para aumentar dados de desvio de byte e tempo de fragmento a um arquivo de 3GPP: Primeiro, a caixa de Acesso aleatório de fragmento de filme ("MFRA") pode ser usada para esta 15 finalidade. A MFRA provê uma tabela, que pode ajudar os leitores a encontrar pontos de acesso aleatório em um arquivo usando fragmentos do filme. Em apoio a esta função, a MFRA incidentalmente contém os desvios de bytes de caixas MFRA contendo pontos de acesso aleatório. A MFRA pode ser 20 colocada em ou perto da extremidade do arquivo, mas isso não é necessariamente o caso. Ao digitalizar a partir do final do arquivo para uma Caixa de Desvio de Acesso Aleatório de Fragmento de Filme e usar as informações de tamanho na mesma, pode ser capaz de localizar o inicio de 25 um Caixa de Acesso Aleatório de Fragmento de Filme. No entanto, a colocação da MFRA no final para fluxo contínuo de HTTP requer tipicamente pelo menos 3-4 solicitações HTTP para acessar aos dados desejados: pelo menos um para solicitar a MFRA a partir da extremidade do arquivo, um 30 para obter a MFRA e, finalmente, um para obter o fragmento desejado no arquivo. Portanto, colocar no início pode ser desejável, como então a mfra pode ser baixada junto com os primeiros dados de mídia em uma única solicitação. Além disso, usar a MERA para fluxo contínuo HTTP pode ser ineficiente, uma vez que nenhuma das informações na "MERA" é necessária além do tempo e desvio de Moof e especificar desvios em vez de comprimentos pode exigir mais bits.

Em segundo lugar, a caixa de Localização de Item ("iLOC") pode ser usada. A "iLOC" provê um diretório de recursos de metadados neste arquivo ou outro, localizando seu arquivo contendo, seu desvio dentro desse arquivo e sua extensão. Por exemplo, um sistema pode integrar todos os recursos de metadados referenciados externamente em um arquivo, re-ajuste de desvios de arquivos e referências de arquivos também. No entanto, a "iLOC" destina-se a dar a localização de metadados por isso pode ser difícil para isso coexistir com metadados reais. Por último, e talvez o mais adequado, é a especificação de uma nova caixa, referida como Caixa de índice de Tempo ("TIDX"), especificamente dedicada ao propósito de prover tempos de fragmentos exatos ou durações e desvio de byte de uma maneira eficiente. Isto está descrito em mais detalhe na seção seguinte. Uma caixa alternativa com as mesmas funcionalidades pode ser a Caixa de índice de segmento ("SIDX"). Aqui, salvo indicação em contrário, essas duas podem ser intercambiáveis, assim como as duas caixas proveem a capacidade de prover tempos de fragmentos exatos ou durações e desvio de byte de uma maneira eficiente. A diferença entre a TIDX e o SIDX é provida abaixo. Deve estar claro como trocar as caixas TIDX e caixas SIDX, assim como as duas caixas implementam um índice de segmento.

Indexação de Segmento Um segmento tem um tempo de partida identificado e um número de bytes identificado. Múltiplos fragmentos podem ser concatenados em um único segmento e os clientes podem emitir solicitações que identificam o intervalo de byte especifico dentro do segmento que corresponde ao fragmento desejado ou um subconjunto do fragmento. Por exemplo, quando HTTP é utilizado como o protocolo de 5 solicitação, então o cabeçalho de intervalo HTTP pode ser utilizado para esta finalidade. Esta abordagem requer que o cliente tenha acesso a um "indice de segmento" do segmento que especifica a posição dentro do segmento dos diferentes fragmentos. Este "indice de segmento" pode ser provido como 10 parte dos metadados. Esta abordagem tem o resultado de que muito menos os arquivos precisam ser criados e gerenciados em comparação com a abordagem onde cada bloco é mantida em um arquivo separado. Gerenciamento da criação, transferência e armazenamento de um número muito grande de 15 arquivos (que poderia estender para muitos milhares de uma apresentação de 1 hora, digamos) pode ser complexa e sujeita a erros e assim redução do número de arquivos representa uma vantagem.

Se o cliente apenas sabe o tempo de partida 20 desejado de uma porção menor de um segmento, ele pode solicitar o arquivo inteiro, então ler o arquivo por meio de determinar a localização de inicio de reprodução apropriada. Para melhorar a utilização da largura de banda, os segmentos podem incluir um indice de arquivo como 25 metadados, onde o de indice de arquivo mapeia os intervalos de bytes de blocos individuais com os intervalos de tempo que os blocos correspondem, chamados indexação de segmento ou mapa de segmento. Esses metadados podem ser formatados como dados XML ou podem ser binários, por exemplo, após a 30 estrutura do átomo e caixa do formato de arquivo 3GPP. A indexação pode ser simples, em que os intervalos de tempo e byte de cada bloco são absolutos em relação ao inicio do processo, ou eles podem ser hierárquicos, em que alguns blocos são agrupados em blocos pai (e aqueles em blocos avós, etc.) e o intervalo de tempo e byte para um dado bloco é expresso em relação ao intervalo de tempo e/ou bytes do bloco pai do bloco.

Exemplo de Estrutura de Mapa de Indexação Em uma modalidade, os dados fonte para uma representação de um fluxo de midia podem ser contidos em um ou mais arquivos de midia aqui chamado de "segmento de midia", onde cada segmento de midia contém os dados de 10 midia utilizados para a reprodução de um segmento de tempo continuo da midia, por exemplo, 5 minutos da reprodução de midia. A figura 6 mostra uma estrutura global exemplar de um segmento de midia. Dentro de cada segmento, quer no 15 inicio ou na propagação ao longo do segmento fonte, pode haver também informação de indexação, que compreende um mapa de segmento de desvio de tempo / byte. O mapa de segmento de desvio de tempo / byte em uma modalidade pode ser uma lista pares de desvio de tempo./ byte (T(0), B(0)), 20 (T(l), B(D), (T(i), B(i)), ..., (T(n), B(n)), em que T (i- 1) representa uma tempo de partida dentro do segmento para a reprodução i-ésimo fragmento de midia em relação ao tempo de partida inicial da midia entre todos os segmentos de midia, T(i) representa um tempo final para o i-ésimo 25 fragmento (e, assim, o tempo de partida para o próximo fragmento), e o desvio de byte B(i-l) é o indice de byte correspondente do inicio dos dados dentro deste segmento fonte onde o i-ésimo fragmento de midia começa em relação ao inicio do segmento fonte, e B(i) é o indice de byte de 30 extremidade correspondente do i-ésimo fragmento (e assim, o indice do primeiro byte do próximo fragmento). Se o segmento contém vários componentes de midia , então T(i) e B(i) pode ser provido para cada componente no segmento de uma maneira absoluta ou pode ser expresso em relação a outro componente de midia que serve um componente de midia de referência. Nesta modalidade, o número de fragmentos no 5 segmento fonte é n, onde n pode variar de segmento para segmento.

Em uma outra modalidade, o desvio de tempo no indice de segmento para cada fragmento pode ser determinado com o tempo de partida absoluto do primeiro fragmento e as 10 durações de cada fragmento. Neste caso, o índice de segmento pode documentar o tempo de partida do primeiro fragmento e a duração de todos os fragmentos que estão incluídos no segmento. O índice de segmento pode também apenas documentar um subconjunto dos fragmentos. Nesse 15 caso, o índice de segmento documenta a duração de um subsegmento que é reprodução como um ou mais fragmentos consecutivos, terminando quer no final do segmento contendo, ou no início do próximo subsegmento.

Para cada fragmento, pode haver também um valor 20 que indica se o fragmento começa ou não no ou contém um ponto de busca, isto é, em um ponto em que nenhuma mídia após esse ponto depende de quaisquer mídias anteriores a esse ponto, e assim a mídia daquele o fragmento avançado pode ser reproduzida de forma independente de fragmentos 25 anteriores. Pontos de busca são, em geral, os pontos na mídia em que reprodução pode começar independentemente de todos as mídias anteriores. A figura 6 também mostra um exemplo simples de indexação de segmento possível para um segmento fonte. Nesse exemplo, o valor de desvio de tempo é 30 em unidades de milissegundos, e, assim, o primeiro fragmento deste segmento fonte começa 20 segundos a partir do início da mídia, e o primeiro fragmento tem um tempo de reprodução de 485 milissegundos. O desvio de byte do início do primeiro fragmento é 0, e o desvio de byte do final do primeiro fragmento / inicio do segundo fragmento é 50.245, e, assim, o primeiro fragmento é de tamanho 50,245 bytes. Se o fragmento ou o subsegmento não começa com um ponto de acesso aleatório, mas o ponto de acesso aleatório está contido no fragmento ou subsegmento, então o tempo de decodificação ou diferença de tempo de apresentação entre o momento de inicio e o tempo de RAP real pode ser dado. Isto permite que em caso de mudança para este segmento de midia, o cliente pode saber o tempo com precisão até que a comutação a partir da representação necessite ser apresentada. Em adição a, ou em vez de indexação simples ou hierárquica, indexação daisy-chain e/ou indexação híbrida poderia ser usada.

Porque o exemplo de durações exemplares para diferentes faixas não pode ser o mesmo (por exemplo, amostras de vídeo podem ser exibidas por 33 ms, enquanto que uma amostra de áudio pode durar 80- ms), as diferentes faixas de um fragmento de filme não podem começar e terminar precisamente ao mesmo, ou seja, o áudio pode começar ligeiramente antes ou um pouco depois do vídeo, com o oposto sendo verdadeiro do fragmento anterior, para compensar. Para evitar ambiguidade, as marcas de tempo especificadas nos dados de desvio de tempo e byte podem ser especificadas em relação a uma faixa em particular e esta pode ser a mesma faixa para cada representação. Geralmente, esta será a faixa de vídeo. Isso permite que o cliente identifique exatamente o próximo quadro de vídeo, quando ele está comutando representações.

Cuidados podem ser tomados durante a apresentação para manter uma estreita relação entre graduação de tempo e tempo de apresentação, para garantir a reprodução suave e manutenção de sincronização de áudio / video apesar da questão acima. A figura 7 ilustra alguns exemplos, tais como um indice de simples 700 e um indice hierárquico 702.

Dois exemplos especifico de uma caixa que contém um mapa de segmento são providos abaixo, um referido como caixa de indice de tempo ('TIDX') e uma referido como ('SIDX'). A definição segue a estrutura de caixa de acordo com o formato de arquivo midia da ISO. Outros desenhos para caixas deste tipo para definir uma sintaxe semelhante e com a mesma semântica e funcionalidade devem ser evidentes para o leitor. Caixa de índice de Tempo Definição Tipo de Caixa: 'tidx' Recipiente: Arquivo Mandatório: Não Quantidade: Qualquer número zero ou um

A Caixa de índice de Tempo pode prover um conjunto de indices de desvios de tempo e bytes que associa determinadas regiões do arquivo com determinados intervalos de tempo da apresentação. A caixa de indice de tempo pode incluir um campo targettype, que indica o tipo dos dados referenciados. Por exemplo, uma caixa de índice de Tempo com targettype "moof" provê um índice para os Fragmentos de mídia contidos no arquivo em termos de tempo e desvios de bytes. A Caixa de índice de tempo com targettype da Caixa de índice de tempo pode ser usada para construir um índice de tempo hierárquico, permitindo que os usuários do arquivo naveguem rapidamente para a parte necessária do índice. 0 índice de segmento pode, por exemplo, conter a seguinte sintaxe: aligned (8) class TimelndexBox extends FullBox ('f rai') { unsigned int (32) targettype; unsigned int (32) time_reference_track_ID; unsigned int (32) number_of_elements; unsigned int (64) first_element_offset; unsigned int (64) first_element_time; for (i = 1; i < = number of elements; i ++) { bit (1) ramdom_access_flag; unsigned int (31) lenght; unsigned int (32) deltaT; } } Semântica targettype: é o tipo dos dados da caixa referenciados por esta caixa de indice de tempo. Isso pode ser Cabeçalho de Fragmento de Filme ("moof") ou Caixa de índice de Tempo ("tidx"). time_ref erence_track_id:- indica- a faixa - em... relação a qual os desvio de tempo neste indice são especificados. number_of_elements: o número de elementos indexados por esta caixa de indice de tempo. first_element_offset: O desvio de byte do início do arquivo do primeiro elemento indexado. first_element_time: O tempo de partida do primeiro elemento indexado, utilizando a escala de tempo especificada na caixa de Cabeçalho de Mídia da faixa identificada por time_reference_track_ID. ramdom_access_flag: Um se o tempo de partida do elemento é um ponto de acesso aleatório. Caso contrário zero. lenght: O comprimento do elemento indexado em bytes deltaT: A diferença em termos da escala de tempo especificada na caixa de Cabeçalho de Midia da faixa identificada pelo Time_reference_track_id entre o tempo de partida deste elemento e o tempo de partida do próximo elemento. Caixa de índice de Segmento A Caixa de índice de segmento ( 'sidx') provê um índice compacto dos fragmentos de filme e outras caixas de índice de segmento em um segmento. Existem duas estruturas de loop na caixa de índice de Segmento. O primeiro loop documenta a primeira amostra do subsegmento, isto é, a amostra no primeiro fragmento de filme referenciado pelo segundo loop. O segundo loop provê um índice do subsegmento. 0 recipiente para a caixa 'sidx' é o arquivo ou segmento diretamente. Sintaxe aligned (8) class SegmentIndexBox extends FullBox sidx', versão 0) { unsigned int (32) Reference_track_ID; unsigned int (16) track_count; unsigned int (16) reference_count; for (i = r 1; i <= track_count; i ++) t unsigned int (32) track_ID; if (versão == 0) unsigned int (32) decoding_time; } else t unsigned int (64) 1 decoding time; for (i = 1; i <= reference_count; i + +) { bit (1) reference_type; unsigned int (31) reference_offset; unsigned int (32) subsegment_duration; bit (1) contains_RAP; unsigned int (31) RAP_delta_time; } Semântica: reference_track_ID provê o track_ID para a faixa de referência. track_count: o número de faixas indexados no loop seguinte (1 ou superior); reference_count: o número de elementos indexados pelo segundo loop (1 ou superior); track_ID: o ID de uma faixa para na qual um fragmento de faixa está incluido noprimeiro fragmentode filme identificado por este indice; exatamente um track_ID um neste loop é igual a reference_track_ID; decoding_time: o tempo de decodificação para a primeira amostra na faixa identificada por track_ID no fragmento de filme referenciado pelo primeiro item no segundo loop, expresso na escala de tempo da faixa (conforme documentado no campo escala de tempo da Caixa de cabeçalho de Midia da faixa); reference_type: quando ajustado para 0, indica que a referência é a uma caixa de fragmento de filme ('Moof'), quando ajustado para 1, indica que a referência é uma caixa de indice de segmento ('sidx'); reference_offset: a distância em bytes do primeiro byte seguinte à caixa de índice de Segmento contendo, para o primeiro byte da caixa referenciada; subsegment_duration: quando a referência é à Caixa de índice de segmento, este campo porta a soma dos campos subsegment_duration no segundo loop da referida caixa e, quando a referência é a um fragmento de filme, este campo porta a soma das durações de amostra das amostras na faixa de referência, no fragmento de filme indicado e fragmentos de filme subsequentes até o primeiro fragmento de filme documentado pela próxima entrada no loop, ou o fim do subsegmento, o que ocorrer primeiro, a duração é expressa na escala de tempo da faixa (como documentado no campo de escala de tempo da Caixa de cabeçalho de mídia da faixa); contians_RAP: quando a referência é a um fragmento de filme, então este bit pode ser 1 se o fragmento de faixa dentro desse fragmento de filme para a faixa com track_ID igual a reference_track_ID contiver pelo menos um ponto de acesso aleatório, do contrário este bit é ajustado para 0, quando a referência é um índice de segmento, então este bit é ajustado para 1, se qualquer uma das referências em que o índice de segmento têm este bit ajustado 1, e 0 caso contrário; RAP_delta_time: se contains_RAP é 1, provê tempo de apresentação (composição) de um ponto de acesso aleatório (RAP); reservado com o valor 0 se cotains_RAP é 0. O tempo é expresso como a diferença entre o tempo de decodificação da primeira amostra do subsegmento documentado por esta entrada e o tempo de apresentação (composição) do ponto de acesso aleatório, na faixa com o track ID igual a reference track ID. Diferenças entre TIDX e SIDX 0 SIDX e o SIDX proveem a mesma funcionalidade no que diz respeito à indexação. 0 primeiro ciclo do SIDX provê em sincronismo de adição global para o primeiro 5 fragmento de filme, mas a altura global pode também ser contida no fragmento de filme em si, absoluta ou relativa para a faixa de referência. 0 segundo loop do SIDX implementa a funcionalidade do TIDX. Especificamente, o SIDX permite ter 10 uma mistura de alvos para a referência para cada indice referido pelo reference_type, enquanto que o TIDX apenas referencia ou apenas TIDX ou apenas MOOf. O number_of_elements em TIDX corresponde à reference_count no SIDX, o time_reference_track_ID em TIDX corresponde à 15 reference_track_ID em SIDX, o tFirst_element_offset em TIDX corresponde ao reference_offset na primeira entrada do segundo loop, o first_element_time em TIDX corresponde ao decoding_time do reference_track no primeiro loop, o ramdom_access_flag em TIDX corresponde ao contaisn_RAP no 20 SIDX com a liberdade adicional que, no SIDX o RAP pode não necessariamente ser colocado no inicio do fragmento e, portanto, exigindo o RAP_delta_time, o length em TIDX corresponde ao reference_offset em SIDX e finalmente o deltaT em TIDX corresponde a subsegment_duration em SIDX. 25 Por conseguinte, as funcionalidades das duas caixas são equivalentes.

Tamanho de Bloco Variável e Blocos SubGoP Para uma midia de video, a relação entre a estrutura de codificação de video e a estrutura de blocos 30 para solicitações pode ser importante. Por exemplo, se cada bloco começa com um ponto de busca, como um ponto de acesso aleatório ("RAP"), e cada bloco representa um periodo de tempo de video igual, então o posicionamento de pelo menos alguns pontos de busca na mídia de video é fixado e pontos de busca irão ocorrer em intervalos regulares dentro da codificação de vídeo. Como é bem conhecido dos versados na técnica da codificação de vídeo, a eficiência de compressão 5 pode ser melhorada se pontos de busca são colocados de acordo com as relações entre os quadros de vídeo, e em particular, se eles são colocados em quadros que têm pouco em comum com quadros anteriores. Esta exigência de que os blocos representam quantidades iguais de tempo, portanto, 10 coloca uma restrição à codificação de vídeo, tal como compressão pode ser subideal. É desejável permitir que a posição de pontos de busca dentro de uma apresentação de vídeo seja escolhida pelo sistema de codificação de vídeo, em vez de exigir 15 pontos de busca em posições fixas. Permitir que o sistema de codificação de vídeo escolha os pontos de busca resulta em compressão de vídeo melhorada e, assim, uma maior qualidade de mídia de vídeo pode ser provida com uma determinada largura de banda disponível, resultando em uma 20 experiência de usuário aprimorada. sistemas de fluxo contínuo de solicitação de bloco atuais podem exigir que todos os blocos tenham a mesma duração (em tempo de vídeo), e que cada bloco tenha que começar com um ponto de busca e isto é, assim, uma desvantagem dos sistemas existentes. 25 Um novo sistema de fluxo contínuo de solicitação de bloco que provê vantagens sobre o acima é agora descrito. Em uma modalidade, o processo de codificação de vídeo de uma primeira versão do componente de vídeo pode ser configurado para selecionar as posições de pontos de 30 busca, a fim de otimizar a eficiência de compressão, mas com um requisito de que existe um máximo sobre a duração entre pontos de busca. Este último requisito faz restringir a escolha de pontos de busca pelo processo de codificação e, assim, reduz a eficiência de compressão. No entanto, a redução na eficiência de compressão é pequena comparada com a incorrida se posições fixas regulares forem necessárias para os pontos de busca, desde que o máximo sobre a duração 5 entre pontos de busca não seja muito pequeno (por exemplo, maior do que cerca de um segundo). Além disso, se o máximo da duração entre pontos de busca for de alguns segundos, então a redução na eficiência de compressão em relação ao posicionamento completamente livre de pontos de busca é 10 geralmente muito pequena.

Em muitas modalidades, incluindo esta modalidade, pode ser que alguns RAPs não sejam pontos de busca, isto é, pode haver um quadro que é um RAP que se encontra entre dois pontos de busca consecutivos que não é escolhido para 15 ser um ponto de busca e, por exemplo, porque o RAP é demasiado próximo em tempo dos pontos de busca vizinhos, ou porque a quantidade de dados de midia entre o ponto de busca antes ou depois do RAP e o RAP é muito pequeno.

A posição de pontos de busca dentro de todas as 20 outras versões da apresentação de midia pode ser restringida a ser a mesma que a dos pontos de busca em uma primeira versão (por exemplo, taxa de dados de midia mais elevada). Isto faz reduzir a eficiência da compressão para esta outra versão em comparação com permitir a escolha 25 livre do codificador de pontos de busca.

A utilização de pontos de busca tipicamente requer um quadro para ser independente decodificável, o que geralmente resulta em uma eficiência de compressão baixa para aquele quadro. Quadros que não são requeridos para ser 30 independentemente decodificáveis podem ser codificados com referência a dados em outros quadros, que geralmente aumenta a eficiência de compressão para aquele quadro por uma quantidade que é dependente da quantidade de homogeneidade entre o quadro a ser codificado e os quadros de referência. Escolha eficiente de busca de ponto de posicionamento preferencialmente escolhe como um quadro de ponto de busca um quadro que tem baixa uniformização com 5 quadros anteriores e assim minimiza a penalidade de eficiência de compressão efetuada codificando o quadro de uma forma que é independentemente decodificável.

No entanto, o nivel de homogeneidade entre um quadro e quadros de referência potenciais é altamente 10 correlacionado através de diferentes representações do conteúdo, uma vez que o conteúdo original é o mesmo. Como resultado, a restrição de pontos de busca em outras variantes de ser as mesmas posições que os pontos de busca na primeira variante não faz uma diferença grande na 15 eficiência de compressão.

A estrutura de ponto de busca de preferência é utilizada para determinar a estrutura de bloco. De preferência, cada ponto de busca determinou o inicio de um bloco, e pode haver um ou mais blocos que englobam os dados 20 entre dois pontos de busca consecutivos. Uma vez que a duração entre pontos de busca não é fixa para codificação com boa compressão, nem todos os blocos são necessários para ter a mesma duração de reprodução. Em algumas modalidades, os blocos estão alinhados entre as versões do 25 conteúdo - isto é, se houver um bloco abrangendo um grupo especifico de quadros em uma versão do conteúdo, então há um bloco que mede o mesmo grupo de quadros em uma outra versão do conteúdo. Os blocos de uma determinada versão do conteúdo não se sobrepõem e cada quadro do conteúdo está 30 contido dentro de exatamente um bloco de cada versão.

Uma característica de habilitação que permite a utilização eficiente da duração variável entre pontos de busca, e, assim, GOPs de duração variável, é a indexação de segmento ou mapa de segmento que pode ser incluída em um segmento ou provida por outra mídia para um cliente, ou seja, isto é metadados associados com este segmento nesta representação que podem ser providos compreendendo o tempo de partida e duração de cada bloco da apresentação. O cliente pode usar esses dados de indexação de segmento na determinação do bloco em que para iniciar a apresentação quando o usuário solicitou que o início da apresentação em um determinado ponto que está dentro de um segmento. Se tais metadados não são providos, então apresentação somente pode começar no início do conteúdo, ou em um ponto aleatório ou aproximado perto do ponto desejado (por exemplo, escolhendo o bloco de partida, dividindo o ponto de partida requerido (em tempo) pela duração de bloco média para dar o índice do bloco de partida).

Em uma modalidade, cada bloco pode ser provido como um arquivo separado. Em outra modalidade, vários blocos consecutivos podem ser agregados em um único arquivo para formar um segmento. Nesta segunda modalidade, metadados para cada versão podem ser providos compreendendo o tempo de partida e duração de cada bloco e o desvio de byte dentro do arquivo em que o bloco começa. Estes metadados podem ser providos em resposta a uma solicitação de protocolo inicial, isto é, disponíveis separadamente a partir do segmento ou arquivo, ou podem ser contidos dentro do mesmo arquivo ou segmento como os próprios blocos, por exemplo, no início do arquivo. Como será claro para aqueles que são versados na técnica, este metadados podem ser codificados em uma forma comprimida, tais como codificação gzip ou delta ou na forma binária, a fim de reduzir os recursos de rede necessários para transportar os metadados para o cliente. A figura 6 mostra um exemplo de indexação de segmento onde os blocos são de tamanho variável, e em que o escopo de blocos é um GoP parcial, ou seja, uma quantidade parcial dos dados de midia entre um RAP e o próximo RAP.

Neste exemplo, os pontos de busca estão indicados pelo indicador de RAP, em que um valor indicador de RAP de 1 indica que o bloco começa com ou contém um RAP, ou ponto de busca, e em que um indicador de RAP de 0 indica que o bloco não contém RAP ou ponto de busca. Neste exemplo, os 10 primeiros três blocos, isto é, os bytes de 0 a 157.033, compreendem o primeiro GOP, que tem uma duração de apresentação de 1.623 segundos, com um tempo de apresentação em execução a partir de 20 segundos para o conteúdo a 21.623 segundos. Neste exemplo, o primeiro dos 15 três primeiros blocos compreende .485 segundos de tempo de apresentação, e compreende os primeiros 50,245 bytes dos dados de midia no segmento. Neste exemplo, os blocos 4, 5 e 6 compreendem o segundo GoP, os blocos 7 e 8 compreendem o terceiro GoP, e blocos 9, 10 e 11 compreendem o quarto GoP.

Note-se que pode haver outros RAPs nos dados de midia que não são designados como pontos de busca, e são, portanto, não assinalados como RAPs no mapa de segmento.

Referindo novamente à figura 6, se o cliente ou receptor quer acessar o conteúdo de partida no desvio de 25 tempo de aproximadamente 22 segundos para a apresentação de midia, então o cliente pode primeiro recorrer a outras informações, como a MPD descrita em mais detalhe mais tarde, para primeiro determinar que os dados de midia relevante estão dentro deste segmento. O cliente pode 30 baixar a primeira porção do segmento para obter a indexação de segmento, que neste caso é apenas alguns bytes, por exemplo utilizando uma solicitação de intervalo de byte HTTP. Usando a indexação de segmento, o cliente pode determinar que o primeiro bloco que deve baixar é o primeiro bloco com um desvio de tempo que é no máximo de 22 segundos e que começa com um RAP, isto é, é um ponto de busca. Neste exemplo, embora o bloqueio 5 tenha um desvio 5 de tempo que é menor do que 22 segundos, isto é, o seu desvio de tempo é 21.965 segundos, a indexação de segmento indica que o bloco 5 não começa com uma RAP, e, assim, em vez disso, com base no indexação de segmento, o cliente seleciona baixar bloco 4, já que seu tempo de partida é no 10 máximo 22 segundos, ou seja, o seu desvio de tempo é 21.623 segundos, e ele começa com uma RAP. Assim, com base na indexação de segmento, o cliente irá fazer uma solicitação de intervalo HTTP a partir de desvio de byte 157.034.

Se a indexação de segmento não estava disponível, 15 então o cliente pode ter que baixar todos os 157,034 bytes anteriores de dados antes de baixar esses dados, levando a muito mais tempo de inicialização, ou tempo de zapping de canal, e download desperdiçado de dados que não são úteis. Alternativamente, se a indexação de segmento não estava 20 disponível, o cliente pode aproximar onde os dados desejados começam dentro do segmento, mas a aproximação pode ser pobre e ele pode perder o momento adequado e, então requer a ir para trás o que aumenta o retardo inicial.

Geralmente, cada bloco inclui uma porção dos dados de midia que, em conjunto com os blocos anteriores, podem ser reproduzidos por um leitor de midia. Assim, a estrutura de bloqueio e a sinalização da estrutura de indexação de segmento de bloqueio para o cliente, ou 30 contido dentro do segmento ou provido ao cliente através de outros meios, pode melhorar significativamente a capacidade do cliente de prover zapping de canal rápido, e reprodução fácil na face das variações de rede e interrupções. O suporte de blocos de duração variável, e os blocos que englobam apenas partes de um GoP, como habilitado pela indexação de segmento, podem melhorar significativamente a experiência de fluxo continuo. Por exemplo, referindo-se novamente à figura 6 e ao exemplo descrito acima, onde o cliente quer começar a reprodução em aproximadamente 22 segundos de apresentação, o cliente pode solicitar, através de uma ou mais solicitações, os dados dentro do bloco 4, e, então alimentar este reprodutor de midia assim que é disponivel para iniciar a reprodução. Assim, neste exemplo, a reprodução começa logo que os 42,011 bytes do bloco 4 são recebidos no cliente, permitindo assim um tempo de zapping de canal rápido. Se em vez do cliente necessitar solicitar o GoP inteiro antes da reprodução começar, o tempo de zapping de canal seria maior, pois este é 144,211 bytes de dados.

Em outras modalidades, RAPs ou pontos de busca também podem ocorrer no meio de um bloco, e pode haver dados na indexação de segmento que indica onde aquele RAP ou ponto de busca está dentro do bloco ou fragmento. Em outras modalidades, o desvio de tempo pode ser o tempo de decodificação do primeiro quadro dentro do bloco, em vez de o tempo de apresentação do primeiro quadro dentro do bloco. As figuras 8 (a) e (b) ilustram um exemplo de bloco variável dimensionado uma estrutura de ponto de busca alinhada através de uma pluralidade de versões ou representações; a figura 8(a) ilustra bloco variável dimensionando com pontos de busca alinhados ao longo de uma pluralidade de versões de um fluxo de midia, enquanto que a figura. 8(b) ilustra bloco variável dimensionando com os pontos de busca não-alinhados sobre uma pluralidade de versões de um fluxo de midia.

Tempo é mostrado na parte superior, em segundos, e os blocos e pontos de busca dos dois segmentos para as duas representações são mostrados da esquerda para a direita em termos da sua temporização com respeito a esta 5 linha de tempo, e assim o comprimento de cada bloco mostrado é proporcional ao seu tempo de reprodução e não proporcional ao número de bytes no bloco. Neste exemplo, a indexação de segmento para ambos os segmentos das duas representações teria os mesmos desvio de tempo como para os 10 pontos de busca, mas uma quantidade potencialmente diferente de blocos ou fragmentos entre pontos de busca, e diferentes desvios de bytes para blocos devido às quantidades diferentes de dados de midia em cada bloco.

Neste exemplo, se o cliente deseja mudar da representação 1 15 para a representação 2 no tempo de apresentação de aproximadamente 23 segundos, então o cliente pode solicitar até através do bloco 1,2 no segmento pela representação 1, e começar a solicitar o segmento para a representação 2, começando r.o bloco 2,2 e, assim-, a comutação ocorreria na 20 apresentação coincidindo com ponto de busca 1,2 na representação 1, que é ao mesmo tempo o ponto de busca 2,2 na representação 2.

Como deve estar claro a partir do exposto, o sistema de fluxo continuo de solicitação de bloco descrito 25 não restringe a codificação de video para colocar pontos de busca em posições especificas dentro do conteúdo e isso atenua um dos problemas dos sistemas existentes.

Nas modalidades descritas acima, ele é organizado de modo que os pontos de busca para as várias 30 representações da mesma apresentação de conteúdo estão alinhados. No entanto, em muitos casos, é preferivel relaxar este requisito de alinhamento. Por exemplo, é por vezes o caso de que as ferramentas de codificação têm sido usadas para gerar as representações que não têm as capacidades para gerar representações de ponto de busca alinhadas. Como outro exemplo, a apresentação de conteúdo pode ser codificada em diferentes representações de forma 5 independente, sem nenhum ponto de busca de alinhamento entre as diferentes representações. Como outro exemplo, uma representação pode conter mais pontos de busca, pois tem taxas mais baixas e mais comumente, precisa ser trocada ou que contém pontos de busca para suportar modos de artificio 10 como avançar ou retroceder rapidamente ou busca rápida.

Assim, é desejável prover métodos que tornam um sistema de fluxo continuo de solicitação de bloco capaz de lidar de forma eficiente e sem problemas com os pontos de busca não- alinhados através das diversas representações para uma 15 apresentação de conteúdo.

Nesta modalidade, as posições dos pontos de busca através de representações não podem alinhar. Os blocos são construídos de tal modo que um novo bloco começa em cada ponto de busca e, portanto, pode não haver alinhamento 20 entre os blocos de diferentes versões da apresentação. Um tal exemplo de estrutura de ponto de busca não alinhado entre representações diferentes é mostrado na figura 8 (b) . Tempo é mostrado na parte superior, em segundos, e os blocos e pontos de busca dos dois segmentos para as duas 25 representações são mostrados da esquerda para a direita em termos da sua temporização no que diz respeito a esta linha de tempo, e, portanto, o comprimento de cada bloco mostrado é proporcional ao seu tempo de reprodução e não proporcional ao número de bytes no bloco. Neste exemplo, a 30 indexação de segmento para ambos os segmentos das duas representações teria desvio de tempo potencialmente diferente para os pontos de busca, e também números de blocos potencialmente diferentes ou fragmentos entre pontos de busca, e os diferentes desvios do byte para blocos, devido às diferentes quantidades de dados de midia em cada bloco. Neste exemplo, se o cliente deseja mudar de representação 1 para a representação 2 no tempo de 5 apresentação de cerca de 25 segundos, então o cliente pode solicitar através do bloco 1,3 no segmento de representação 1, e começar a solicitar o segmento para a representação 2, começando no bloco 2,3 e, assim, a comutação ocorreria na apresentação coincidindo com ponto de busca 2,3 na 10 representação 2, que está no meio da reprodução do bloco de 1,3 na representação 1, e, assim, alguma midia para o bloco 1,2 não seria reproduzida (embora os dados de midia para os quadros de bloco 1,3 que não são reproduzidos podem ter de ser carregados no armazenador de receptor para decodificar 15 os quadros de outros blocos 1,3 que são reproduzidos).

Nesta modalidade, a operação do seletor de bloco 123 pode ser modificada de tal modo que sempre que for necessário selecionar um bloco a partir de uma representação que é diferente da versão previamente 20 selecionada, o último bloco cujo primeiro quadro não é o último do que o quadro subsequente ao último quadro do último bloco selecionado é escolhido.

Esta última modalidade descrita pode eliminar a necessidade de restringir as posições de pontos de busca 25 dentro de outras versões diferentes da primeira versão e, assim, aumenta a eficiência de compressão para essas versões, resultando em uma apresentação de qualidade superior para uma determinada largura de banda disponível e esta uma experiência de usuário aprimorada. Uma outra 30 consideração é que as ferramentas de codificação de video, que desempenham a função de alinhamento de ponto de busca através de múltiplas codificações (versões) do conteúdo não pode ser amplamente disponível e, portanto, uma vantagem desta última modalidade descrita é que as ferramentas de codificação de video atualmente disponíveis podem ser utilizadas. Outra vantagem é que codificação de diferentes versões de conteúdo podem ocorrer em paralelo, sem qualquer 5 necessidade de coordenação entre os processos de codificação para as diferentes versões. Outra vantagem é que as versões adicionais do conteúdo podem ser codificadas e adicionadas à apresentação em um momento posterior, sem ter de prover as ferramentas de codificação com as listas 10 de posições especificas de posições de ponto de busca.

Em geral, onde as imagens são codificadas como grupos de imagens (GoPs), a primeira imagem na sequência pode ser um ponto de busca, mas que não precisa ser sempre o caso.

Particionamento de Bloco Ideal Uma questão de preocupação em um sistema de sistema de fluxo continuo de solicitação de bloco é a interação entre a estrutura da midia codificada, por exemplo, mídia de vídeo, e a estrutura de bloco usada para 20 solicitações de bloco. Como será conhecido dos versados na técnica da codificação de vídeo, é muitas vezes o caso em que o número de bits necessários para a representação codificada de cada quadro de vídeo varia, por vezes, substancialmente, de quadro para quadro. Como resultado, a 25 relação entre a quantidade de dados recebidos e a duração da mídia codificada por que os dados não podem ser simples. Além disso, a divisão de dados de mídia em bloco dentro de um sistema de fluxo contínuo de solicitação de bloco adiciona uma nova dimensão de complexidade. Em particular, 30 em alguns sistemas, os dados de mídia de um bloco não podem ser reproduzidos até que todo o bloco tenha sido recebido, por exemplo, o arranjo da dados de mídia dentro de um bloco ou dependências entre as amostras de mídia dentro de um bloco do uso de códigos de apagamento pode resultar nessa propriedade. Como resultado dessas interações complexas entre o tamanho do bloco e a duração do bloco e a eventual necessidade de receber um bloco inteiro antes de começar 5 reprodução é comum que os sistemas clientes adotem uma abordagem conservadora em que dados de midia são armazenados em buffer antes da reprodução começar. Tal armazenamento em buffer resulta em um longo tempo de zapping de canal e, assim, uma má experiência de usuário.

Pakzad descreve "métodos de particionamento de de bloco", que são métodos novos e eficientes para determinar como particionar um fluxo de dados em blocos contiguos com base na estrutura subjacente do fluxo de dados e descreve ainda várias vantagens destes métodos no contexto de um 15 sistema de fluxo continuo. Uma modalidade adicional da invenção para aplicar os métodos de particionamento de bloco de Pakzad a um sistema de fluxo continuo de solicitação de bloco é agora descrito. Este método pode compreender arranjar os dados de. midia a ser apresentados 20 na ordem de tempo de apresentação aproximada, de tal modo que o tempo de reprodução de qualquer dado elemento de dados de midia (por exemplo, um quadro de video ou a amostra de áudio) difira e daquela de qualquer elemento de dados de midia adjacente em menos do que um limite provido.

Os dados de midia de modo ordenado podem ser considerados um fluxo de dados na linguagem da Pakzad e qualquer um dos métodos de Pakzad aplicados a este fluxo de dados identifica fronteiras de bloco com o fluxo de dados. Os dados entre qualquer par de fronteiras de blocos adjacentes 30 é considerado um "bloco" na linguagem desta divulgação e os métodos desta divulgação são aplicados para prover a apresentação dos dados de midia dentro de um sistema de fluxo continuo de solicitação de bloco. Como será claro para aqueles que são versados na técnica a leitura desta descrição das várias vantagens sobre os métodos divulgados na Pakzad pode então ser realizada no contexto de um sistema de fluxo continuo de solicitação de bloco.

Tal como descrito em Pakzad, a determinação da estrutura do bloco de um segmento, incluindo os blocos que englobam GoPs parciais ou porções de mais do que em GoP, pode ter impacto na capacidade do cliente, para permitir tempos de zapping de canal rápido. Em Pakzad, os métodos 10 que foram providos, dado um tempo alvo de inicialização, proveriam uma estrutura de bloco e uma taxa de download de destino que iria garantir que se o cliente começou a baixar a representação em qualquer ponto de busca e começou a reprodução após o tempo de inicialização de destino ter 15 decorrido, então a reprodução continuaria perfeitamente enquanto em cada ponto no tempo a quantidade de dados que o cliente tenha baixado é, pelo menos, os tempos de taxa de download de destino o tempo decorrido desde o inicio do download. É vantajoso para o cliente ter acesso ao tempo de 20 inicialização alvo e a taxa de download de destino, como isso provê ao cliente um meio para determinar quando começar a reproduzir a representação no primeiro ponto no tempo, e permite que o cliente continue a reproduzir a representação enquanto o download satisfaça a condição 25 acima descrita. Assim, o método descrito mais tarde provê um meio para incluir o tempo de inicialização alvo e a taxa de download alvo dentro da descrição de apresentação de midia, de modo que ele pode ser usado para os fins descritos acima.

Modelo de Dados de Apresentação de Midia A figura 5 ilustra possiveis estruturas de armazenamento de conteúdo mostrado na figura 1, incluindo segmentos de midia e arquivos de descrição de apresentação ("MPD"), e uma repartição dos segmentos, tempo e outras estruturas dentro de um arquivo MPD. Detalhes de implementações possíveis de estruturas MPD ou arquivos serão agora descritos. Em muitos exemplos, a MPD é descrita 5 como um arquivo, mas estruturas sem arquivos podem ser utilizadas também.

Como ilustrado aqui, armazenamento de conteúdo 110 mantém uma pluralidade de segmentos fontes 510, MPDs 500 e segmentos de reparação 512. Uma MPD pode compreender 10 registros de periodo 501, que por sua vez podem compreender registros de representação 502, que contêm informação de segmento 503, tais como referências a segmentos de inicialização 504 e segmentos de midia 505. A figura 9(a) ilustra uma tabela de metadados 15 exemplares 900, enquanto a figura 9(b) ilustra um exemplo de como um cliente de fluxo continuo HTTP 902 obtém tabela de metadados 900 e blocos de midia 904 através de uma conexão a um servidor de fluxo continuo HTTP 906.

Nos métodos descritos neste documento, uma 20 "descrição de apresentação de midia" é provida que compreende informações sobre as representações da apresentação de midia disponivel para o cliente. Representações podem ser alternativas em um sentido em que o cliente seleciona uma alternativa diferente, ou pode ser 25 elas podem ser complementares no sentido de que o cliente seleciona várias das representações, cada uma, possivelmente, também a partir de um conjunto de alternativas, e as apresenta conjuntamente. As representações podem vantajosamente ser atribuídas a 30 grupos, com o cliente programado ou configurado para compreender que, para as representações em um grupo, elas são, cada uma alternativa para a outra, enquanto as representações de diferentes grupos são tais que mais do que uma representação deve ser apresentada conjuntamente. Em outras palavras, se houver mais do que uma representação de um grupo, o cliente escolhe uma representação desse grupo, uma representação de entre o grupo seguinte, etc., para formar uma apresentação.

Informações descrevendo representações podem vantajosamente incluir detalhes dos codecs de midia aplicada, incluindo perfis e niveis daqueles codecs que são necessários para decodificar a representação, as taxas de quadro de video, resolução de video e taxas de dados. O cliente que recebe a descrição de apresentação de midia pode usar essas informações para determinar de antemão se uma representação é adequada para decodificação ou apresentação. Isto representa uma vantagem, porque se a informação de diferenciação somente estiver contida nos dados binários da representação seria necessário solicitar os dados binários de todas as representações e analisar e extrair as informações relevantes, a fim de descobrir informações sobre a sua adequação. Estas solicitações múltiplas e a extração de anexo de análise dos dados podem levar algum tempo o que resultaria em um longo tempo de inicialização e, portanto, uma má experiência de usuário.

Além disso, a descrição de apresentação de midia pode incluir informações que restringem as solicitações de clientes com base no tempo do dia. Por exemplo, para um serviço direto ao cliente pode ser limitado a solicitar a apresentação de partes que estão perto do "tempo de broadcast atual". Isto representa uma vantagem uma vez que para broadcast ao vivo, pode ser desejável purgar dados da infraestrutura de serviço para o conteúdo que foi transmitido mais do que um limite provido antes do tempo de broadcast atual. Isto pode ser desejável para a reutilização de recursos de armazenamento no interior da infraestrutura de serviço. Isto também pode ser desejável, dependendo do tipo de serviço oferecido, por exemplo, em alguns casos uma apresentação pode ser disponibilizada apenas ao vivo devido a um modelo de assinatura determinado de receber dispositivos de cliente, enquanto que outras apresentações de midia poderão ser disponibilizadas ao vivo e on-demand, e outras apresentações podem ser disponibilizadas apenas ao vivo para uma primeira classe de dispositivos de cliente, apenas on-demand para uma segunda classe de dispositivos de cliente, e uma combinação de ao vivo ou on-demand para uma terceira classe de dispositivos de cliente. Os métodos descritos no Modelo de Dados de Apresentação de Midia (abaixo) permitem que o cliente seja informado de tais politicas para que o cliente possa evitar fazer solicitações e ajustar as ofertas para o usuário, para dados que podem não estar disponíveis na infraestrutura de serviço. Como uma alternativa, por exemplo, o cliente pode apresentar uma notificação para o usuário de que estes dados não estão disponíveis.

Em uma modalidade adicional da invenção, os segmentos de transmissão poderão ser compatíveis com o formato de arquivo de midia baseado em ISO descritos no padrão ISO / IEC 14496-12 ou especificações derivadas (tais como o formato de arquivo 3GP descrito em na Especificação Técnica 3GPP 26,244). O uso da seção de formato de arquivo 3GPP (acima) descreve aprimoramentos novos no formato de arquivo de midia baseado em ISO que permite o uso eficiente das estruturas de dados do formato de arquivo dentro de um sistema de fluxo continuo de solicitação de bloco. Conforme descrito nesta referência, as informações podem ser providas dentro do arquivo que permite mapeamento rápido e eficiente entre os segmentos de tempo da apresentação de midia e intervalos de bytes dentro do arquivo. Os dados de mídia em si podem ser estruturados de acordo com a construção de Fragmento de Filme em ISO/IEC14496-12. Esta informação que provê desvio de tempo e byte pode ser estruturada hierarquicamente, ou como um único bloco de informações. Esta informação pode ser provida no início do arquivo. 0 provimento desta informação usando uma codificação eficiente, conforme descrito no Uso de seção de formato de arquivos 3GPP resulta no cliente sendo capaz de recuperar essas informações rapidamente, usando por exemplo solicitações HTTP GET parciais, no caso em que o protocolo de download de arquivo usado pelo sistema de fluxo contínuo de solicitação de bloco é HTTP, o que resulta em uma curta inicialização, busca ou tempo de troca de fluxo e, portanto, uma experiência de usuário aprimorada.

As representações em uma apresentação de mídia são sincronizadas em um cronograma global para garantir comutação perfeita em representações, sendo tipicamente alternativas, e para garantir uma apresentação sincronizada de duas ou mais representações. Portanto, tempo de amostra de mídia contida nas representações dentro de uma apresentação de mídia de fluxo contínuo de HTTP adaptativo pode estar relacionada a uma linha de tempo contínua global em vários segmentos.

Um bloco de mídia codificada contendo mídia de vários tipos, por exemplo, áudio e vídeo, pode ter tempos diferentes de apresentação para os diferentes tipos de mídia. Em um sistema de fluxo contínuo de solicitação de bloco, tais blocos de transmissão poderão ser reproduzidos consecutivamente, de tal maneira que cada tipo de mídia é reproduzida continuamente e, portanto, as amostras de mídia de um tipo a partir de um bloco podem ser reproduzidas antes das amostras de mídia de outro tipo de bloco anterior, que ê aqui referido—eomo iLemenda de bloco continuo". Como uma alternativa, tais blocos de midia podem ser reproduzidos de modo tal que a primeira amostra de qualquer tipo de bloco é reproduzida depois da última amostra de qualquer tipo de bloco anterior, que é aqui referido como "emenda bloco descontinuo". Emenda de bloco continuo pode ser apropriada quando ambos os blocos contêm midia do mesmo item de conteúdo e uma mesma representação, codificada em sequência, ou em outros casos. Tipicamente, dentro de uma representação emenda de bloco continuo pode ser aplicada ao emendar dois blocos. Isto é vantajoso, assim como codificação existente pode ser aplicada e segmentação pode ser feita sem a necessidade de alinhar as faixas de midias nas fronteiras de bloco. Isto é ilustrado na figura 10, onde fluxo de video 1000 compreende bloco 1202 e outros blocos, com RAPs tais como RAP 1204.

Descrição de Apresentação de Midia

Uma apresentação de midia pode ser vista como uma coleção estruturada de arquivos em um servidor de fluxo continuo HTTP. O cliente de fluxo continuo HTTP pode baixar informações suficientes para apresentar o serviço de fluxo continuo para o usuário. Representações alternativas podem ser compostas de um ou mais arquivos 3GP ou partes de arquivos 3GP de acordo com o formato de arquivo 3GPP ou pelo menos um conjunto bem definido de estruturas de dados que podem ser facilmente convertidos de ou para um arquivo 3GP.

Uma apresentação de midia pode ser descrita por uma descrição de apresentação de midia. A descrição de apresentação de midia (MPD) pode conter metadados que o cliente pode usar para construir solicitações de arquivos apropriados, por exemplo, solicitações HTTP GET, para acessar os dados em tempo oportuno e para prover o serviço de fluxo continuo para o usuário < A descrição de apresentação de midia pode prover informações suficientes para o cliente de fluxo continuo HTTP para selecionar os arquivos apropriados 3GPP e partes de arquivos. As unidades que são sinalizadas para o cliente como sendo acessivel são referidas como segmentos. Entre outros, uma descrição de apresentação de midia pode conter elementos e atributos, como segue.

Elemento MediaPresentationDescription Um elemento que encapsula metadados usados pelo cliente de fluxo continuo HTTP para prover o serviço de fluxo continuo para o usuário final. O elemento MediaPresentationDescription pode conter um ou mais dos seguintes atributos e elementos. Version: Número da versão para o protocolo para garantir a extensibilidade.

Presentationidentifier: Informações de tal forma que a apresentação pode ser identificada exclusivamente entre outras apresentações. Também pode conter campos privados ou nomes.

UpdateFrequency: Frequência de atualização da descrição de apresentação de midia, ou seja, quantas vezes o cliente pode recarregar a descrição de apresentação de midia real. Se não estiver presente, a apresentação de midia pode ser estática. Atualizar a apresentação de midia pode significar que a apresentação de midia não pode ser armazenada em cache.

MediaPresentationDescriptionURI: URI para datar a descrição de apresentação de midia. Stream: Descreve o tipo do fluxo ou apresentação de midia: video, áudio ou texto. Um tipo de fluxo de video pode conter áudio e pode conter texto. Service: Descreve o tipo de serviço com atributos a d i c i o n ais . Tipos dê serviços—podom—ser—ao vivo e on- demand. Isso pode ser usado para informar o cliente que busca e acessa além de algum tempo atual não ser permitido.

MaximumClientPreArmazenadorTime: Uma quantidade máxima de tempo que o cliente pode pré-armazenar em buffer o fluxo de midia. Este tempo pode diferenciar fluxo continuo de download progressivo, se o cliente é restrito a baixar além deste tempo pré-armazenador máximo. O valor pode não estar presente, indicando que não há restrições em termos de pré-armazenador pode ser aplicada.

SafetyGuardlntervalLiveService: Informações sobre o máximo de tempo de rotação de um serviço ao vivo no servidor. Provê uma indicação para o cliente de qual informação já acessivel no momento atual. Esta informação pode ser necessária se o cliente e o servidor são esperados para operar em tempo UTC e nenhuma sincronização de tempo apertado é provida.

TimeShiftArmazenadorDepth: Informações sobre o quão distante o cliente pode se mover em uma relação ao serviço ao vivo para o tempo atual. Pela extensão desta profundidade, visualização de deslocamento de tempo e de serviços de catch-up pode ser permitida sem alterações especificas no provisionamento de serviços.

LocalCachingPermitted: Esse flag indica se o cliente HTTP pode armazenar em cache os dados baixados localmente após terem sido reproduzidos.

LivePresentationlnterval: Contém intervalos de tempo durante o qual a apresentação pode estar disponível especificando StartTimes e Endtimes. O StartTime indica o tempo de partida dos serviços e o EndTime indica o tempo do fim do serviço. Se o EndTime não for especificado, então o tempo final é desconhecido no momento atual e o

UpdateFrequency pode garantir que os clientes tenham acesso ao fim do tempo antes do fim do tempo real do serviço. OnDemandAvailabilitylnterval: O intervalo de apresentação indica a disponibilidade do serviço na rede. Intervalos de apresentações múltiplos podem ser providos. O cliente HTTP pode não ser capaz de acessar o serviço fora de qualquer janela de tempo especificada. Pelo provisionamento do OnDemandlnterval, visualização de deslocamento de tempo adicional pode ser especificada. Este atributo pode também estar presente para um serviço ao vivo. No caso de estar presente para um serviço ao vivo, o servidor pode garantir que o cliente possa acessar o serviço como serviço OnDemand durante todos os intervalos de disponibilidade prestados. Portanto, o LivePresentationlnterval não pode sobrepor-se com qualquer OnDemandAvailabilitylnterval. MPDFilelnfoDynamic: Descreve a construção dinâmica padrão de arquivos na apresentação de midia. Mais detalhes são providos abaixo. A especificação padrão no nivel MPD pode salvar uma repetição desnecessária se as mesmas regras para várias ou todas as representações alternativas são utilizadas. MPDCodecDescription: Descreve os codecs padrão principais na apresentação de midia. Mais detalhes são providos abaixo. A especificação padrão no nivel MPD pode salvar uma repetição desnecessária se os mesmos codecs de várias ou todas representações são usados. MPDMoveBoxHeaderSizeDoesNotChange: Um flag para indicar se as mudanças de MoveBox Header em tamanho entre os arquivos individuais dentro da apresentação de midia inteira. Este flag pode ser utilizado para otimizar a descarga e só pode estar presente em caso de formatos de segmento especifico, especialmente aqueles para os quais os segmentos contêm o cabeçalho moov. FileURIPattern: Um padrão utilizado pelo cliente para gerar mensagens de solicitação de arquivos dentro da apresentação de midia. Os diferentes atributos permitem geração de URIs únicos para cada um dos arquivos dentro da apresentação de midia. O URI base pode ser um URI HTTP. Representação Alternativa: Descreve uma lista de representações.

AlternativeRepresentation Element: Um elemento XML que encapsula todos os metadados para uma representação. O AlternativeRepresentation Element pode conter os seguintes atributos e elementos. RepresentationlD: Um ID exclusivo para esta Representação Alternativa Especifica dentro da apresentação de midia.

FileslnfStatic: Provê uma lista explicita dos tempos de partida e da URI de todos os arquivos de uma apresentação alternativa. O provimento estático da lista de arquivos pode prover a vantagem de uma descrição de tempo exato da apresentação de midia, mas pode não ser tão compacto, especialmente se a representação alternativa contiver muitos arquivos. Além disso, os nomes dos arquivos podem ter nomes arbitrários.

FileslnfoDynamic: Provê uma maneira implicita para construir a lista dos tempos de partida e da URI de uma apresentação alternativa. O provisionamento dinâmico da lista de arquivos pode prover a vantagem de uma representação mais compacta. Se apenas a sequência de tempos de partida é provida, então as vantagens temporais também mantêm-se aqui, mas os nomes dos arquivos devem ser construídos dinamicamente com base no FilePatternURI. Se apenas a duraçã o dê cada segmenLo—é—p-rmnda, então a representação é compacta e pode ser adaptada para uso dentro de serviços ao vivo, mas a geração dos arquivos pode ser regulada por temporização global.

APMoveBoxHeaderSizeDoesNotChange: Um flag que indica se MoveBox Header muda em tamanho entre os arquivos individuais dentro da Descrição Alternativa. Este flag pode ser utilizado para otimizar a descarga e só pode estar presente em caso de formatos de segmento especifico, especialmente aqueles para os quais os segmentos contêm o cabeçalho moov. APCodecDescription: Descreve os codecs principais de arquivos na apresentação alternativa.

Media Description Element MediaDescription: Um elemento que pode encapsular todos os metadados de midia que estão contidos na representação. Especificamente, pode conter informações sobre as faixas nesta apresentação alternativa, bem como agrupamento recomendado de faixas, se aplicável. O atributo MediaDescription contém os seguintes atributos:

TrackDescription: Um atributo XML que encapsula todos os metadados para a midia que está contida na representação. O atributo TrackDescription contém os seguintes atributos: TracklD: Um ID exclusivo para a faixa dentro da representação alternativa. Isto pode ser usado no caso da faixa ser parte de uma descrição de agrupamento. Bitrate: A taxa de bits da faixa. TrackCodecDescription: Um atributo XML que contém todos os atributos sobre o codec utilizado nesta faixa. O atributo TrackCodecDescription contém os seguintes atributos: MediaName: Um atributo que define o tipo de midia. Os tipos de midia incluem "áudio", "video", "texto", "aplicativo" e "mensagem". Codec: CodecType incluindo perfil e nivel. LanguageTag: LanguageTag se aplicável. Max Width, MaxHeight: Para video, Altura e Largura de video contidos em pixel. SamplingRate: Para áudio, taxa de amostra GroupDescription: Um atributo que provê a recomendação para o cliente para agrupamento adequado com base em parâmetros diferentes. groupType: Um tipo com base no qual o cliente pode decidir como agrupar faixas.

A informação em uma descrição de apresentação de midia é vantajosamente usada por um cliente de fluxo continuo HTTP para realizar solicitações de arquivos e segmentos ou partes destes, em momentos apropriados, selecionar os segmentos a partir de representações adequadas que correspondem com as suas capacidades, por exemplo, em termos de largura de banda de acesso, capacidades de exibição, capacidades de codec, e assim por diante, bem como as preferências do usuário, como idioma, e assim por diante. Além disso, como a descrição de apresentação de midia descreve as representações que são alinhadas em tempo e mapeadas para uma linha de tempo global, o cliente também pode usar a informação na MPD durante uma apresentação de midia continua para iniciar ações apropriadas para alternar entre representações, para apresentar representações em conjunto ou buscar na apresentação de midia. Sinalização de tempos de partida de segmento

Uma representação pode ser dividida, tempo a tempo, em vários segmentos . Um—problema—de—temporização inter-faixa existe entre o último fragmento de um segmento e o próximo fragmento do próximo segmento. Além disso, um outro problema de temporização existe no caso de que os segmentos de duração constante são utilizados.

Usar a mesma duração para cada segmento pode ter a vantagem de que a MPD é compacta e estática. No entanto, cada segmento pode ainda começar com um Ponto de Acesso Aleatório. Assim, nem a codificação de video pode ser restringida para prover pontos de acesso aleatório nestes pontos específicos, nem as durações de segmento reais podem não ser precisamente como especificadas na MPD. Pode ser desejável que o sistema de transmissão não coloque restrições desnecessárias no processo de codificação de video e assim a segunda opção pode ser preferida.

Especificamente, se a duração do arquivo é especificada na MPD como d segundos, então o n-ésimo arquivo pode começar com o Ponto de Acesso Aleatório no tempo ou imediatamente a seguir (nl)d.

Nesta abordagem, cada arquivo pode incluir informação quanto ao tempo de partida exato do segmento em termos de tempo de apresentação global. Três maneiras possíveis para sinalizar isso incluem: (1) Em primeiro lugar, restringir o tempo de partida de cada segmento para o momento exato, conforme especificado na MPD. Mas em seguida o codificador de midia não pode ter qualquer flexibilidade na colocação dos quadros IDR e pode exigir codificação especial para fluxo continuo de arquivos. (2) Segundo, adicionar o tempo de partida exato para a MPD para cada segmento. Para o caso on-demand, a compacidade da MPD pode ser reduzida. Para o caso ao vivo, este pode exigir uma atualização regular da MPD, que pode reduzir a escalabilidade. ’ (3) Em terceiro lugar, adicionar o tempo global ou o tempo de partida exato em relação ao tempo de partida anunciado da representação ou o tempo de partida anunciado do segmento na MPD para o segmento no sentido de que o segmento contém esta informação. Isto pode ser adicionado a uma nova caixa dedicada a fluxo continuo adaptativo. Esta caixa também pode incluir a informação provida pela caixa "TIDX" ou "SIDX". Uma consequência desta terceira abordagem é a de que quando se pretende uma posição particular perto do inicio de um dos segmentos o cliente pode, com base na MPD, escolher o segmento posterior a um contendo o ponto de busca desejado. Uma resposta simples neste caso pode ser mover o ponto de busca diretamente para o inicio do segmento recuperado (isto é, para o próximo ponto de acesso aleatório após o ponto de busca). Normalmente, os pontos de acesso aleatório são providos, pelo menos a cada poucos segundos (e muitas vezes há pouco ganho de codificação de torná-los menos frequente) e assim, no pior caso, o ponto de busca pode ser movido para ser alguns segundos mais tarde do que o especificado. Alternativamente, o cliente pode determinar em recuperar as informações do cabeçalho para o segmento que o ponto de busca solicitado está na verdade, no segmento anterior e em vez disso solicitar aquele segmento. Isto pode resultar em um aumento ocasional no tempo necessário para executar a operação de busca. Lista de Segmentos Acessíveis

A apresentação de mídia compreende um conjunto de representações cada uma provendo alguma versão diferente da codificação do conteúdo da mídia original. As próprias representações vantajosamente contêm informações sobre os parâmetros de diferenciação da representação em relação a outros parâmetros. Elas também contêm, explícita ou implicit ame n t e, uma lista de segmenLus acessíveis.

Segmentos podem ser diferenciadas em segmentos de menos tempo que contêm apenas os metadados e os segmentos de midia que basicamente contêm dados de midia. A descrição de apresentação de Midia ("MPD") vantajosamente identifica e atribui atributos diferentes para cada um dos segmentos, implícita ou explicitamente. Atributos vantajosamente atribuídos a cada segmento compreendem o periodo durante o qual um segmento é acessível, os recursos e protocolos através dos quais os segmentos são acessíveis. Além disso, os segmentos de midia são vantajosamente atribuídos atributos como o tempo de partida do segmento na apresentação de midia, e a duração do segmento na apresentação de midia. Onde a apresentação de midia é do tipo "on- demand", como vantagem, indicada por um atributo na descrição de apresentação de midia, como o OnDemandAvailabilitylnterval, então a de scrição de apresentação de midia tipicamente descreve < DS segmentos inteiros e também provê uma indicação de quando os segmentos são acessíveis e, quando os segmentos não são acessíveis. Os tempos de partida de segmentos são vantajosamente expressos em relação ao inicio da apresentação de midia de tal modo que dois clientes iniciando a reprodução das mesmas apresentações de midia, mas em momentos diferentes, podem usar a mesma descrição de apresentação de midia, bem como os mesmos segmentos de midia. Esta vantagem, melhora a capacidade de armazenar em cache os segmentos.

Onde a apresentação de midia é do tipo "ao vivo", como vantagem, indicada por um atributo na descrição de apresentação de midia, como o atributo Service, então os segmentos que compõem a apresentação de midia além do tempo real do dia geralmente nâõ SHO—gerados—ou não são pelo menos acessíveis apesar dos segmentos serem completamente descritos na MPD. No entanto, com a indicação de que o serviço de apresentação de mídia é do tipo "ao vivo", o cliente pode produzir uma lista de segmentos acessíveis juntamente com os atributos de temporização para um tempo de cliente interno NOW em tempo de relógio de parede com base nas informações contidas na MPD e tempo de download da MPD. O servidor vantajosamente opera em um sentido que torna recurso acessível de tal forma que um cliente de referência operando com a instância da MPD no tempo de relógio de parede NOW pode acessar os recursos.

Especificamente, o cliente de referência produz uma lista de segmentos acessíveis juntamente com os atributos de tempo para um tempo de cliente interno NOW na tempo de relógio de parede com base nas informações contidas na MPD e o tempo de download da MPD. Com o tempo avançando, o cliente usa a mesma MPD e irá criar uma nova lista de segmento acessível que pode ser usada para continuamente reproduzir a apresentação de mídia. Portanto, o servidor pode anunciar segmentos em uma MPD antes que esses segmentos sejam realmente acessíveis. Isto é vantajoso, pois reduz a atualização frequente e faz download da MPD.

Suponha que uma lista de segmentos, cada uma com tempo de partida, tS, é descrita explicitamente por uma lista de reprodução de elementos como FilelnfoStatic ou implicitamente usando um elemento, como Filelnf©Dynamic. Um método vantajoso para gerar uma lista de segmento utilizando FilelnfoDynamic é descrito abaixo. Com base nesta regra de construção, o cliente tem acesso a uma lista de URIs para cada representação, r, aqui referida como FileURI (r, i), e uma tempo de partida tS (r, i) para cada segmento com índice i. _

A utilização de informação na MPD para criar a janela de tempo acessível de segmentos pode ser realizada utilizando as seguintes regras.

Para um serviço do tipo "on-demand", como vantagem, indicado por um atributo tal como Service, se o tempo de relógio de parede atual no cliente agora está dentro de qualquer faixa da disponibilidade, vantajosamente expressa por um elemento MPD tal como OnDemandAvailabilitylnterval, então todos os segmentos descritos desta apresentação On-Demand são acessíveis. Se o tempo de relógio de parede atual com o cliente NOW está fora de qualquer faixa da disponibilidade, então nenhum dos segmentos descritos desta apresentação On-Demand é acessivel.

Para um serviço do tipo "ao vivo", como vantagem, indicado por um atributo como Service, o tempo de partida tS (r, i) vantajosamente expressa o tempo de disponibilidade no tempo de relógio de parede. 0 tempo de partida, de disponibilidade pode ser obtido como uma combinação do tempo de serviço ao vivo do evento e algum tempo de rotação no servidor para a captura, codificação, e edição. O tempo para este processo pode, por exemplo, ser especificado na MPD, por exemplo, utilizando um intervalo de guarda de segurança tG especificado por exemplo especificado como SafetyGuardlntervalLiveService na MPD. Isso proveria a diferença minima entre o tempo UTC e a disponibilidade dos dados no servidor de fluxo continuo HTTP. Em uma outra modalidade, a MPD explicitamente especifica o tempo de disponibilidade do segmento na MPD sem prover o tempo de rotação como uma diferença entre o tempo de evento ao vivo e o tempo de rotação. Nas seguintes descrições, presume-se que quaisquer tempos globais são especificados corno tempos de disponibilidade-—Um yprsado na técnica broadcast de midia ao vivo pode obter esta informação a partir de informação adequada na descrição de apresentação de midia depois de ler esta descrição.

Se o tempo de relógio de parede atual no cliente NOW está fora de qualquer faixa do intervalo de apresentação ao vivo, vantajosamente expresso por um elemento MPD como LivePresentationlnterval, então nenhum dos segmentos descritos desta apresentação ao vivo são acessiveis. Se o tempo de relógio de parede atual com o cliente NOW está dentro do intervalo de apresentação ao vivo, então pelo menos certos segmentos dos segmentos descritos desta apresentação ao vivo podem ser acessiveis. A restrição dos segmentos acessiveis rege-se pelos seguintes valores:

O tempo do relógio de parede NOW (como disponivel para o cliente). A profundidade de armazenador em tempo permitida tTSB, por exemplo, especificada como TimeShiftArmazenadorDepth na descrição de apresentação de midia.

Um cliente no tempo do evento relativo tl só pode ser autorizado a solicitar segmentos com tempo de partida tS (r, i) no intervalo de (NOW - tTSB) e NOW ou em um intervalo tal que o tempo final do segmento com duração d também está incluido, resultando em um intervalo de (NOW - tTSB-d) e NOW. Atualizando a MPD

Em algumas modalidades, o servidor não sabe de antemão o localizador de arquivo ou segmento e os tempos de partida dos segmentos, como por exemplo a localização do servidor irá mudar, ou a apresentação de midia inclui alguma anúncio de um servidor diferente, ou a duração da apresentação de midia é desconhecida, ou o servidor quer ofuscar o localizador para os segmentos seguintes.

Em tais modalidades, o servidor só poderia descrever segmentos que já são acessíveis ou obter acesso logo após esta instância da MPD ser publicada. Além disso, em algumas modalidades, o cliente vantajosamente consome midia perto da midia descrita na MPD tal que o usuário experimenta o programa de midia contida tão próximo quanto possivel para a geração do conteúdo de midia. Assim que o cliente antecipa, que ele chega ao fim dos segmentos de midia descritos na MPD, que vantajosamente solicita uma nova instância da MPD para continuar reprodução continua na expectativa de que o servidor publicou uma nova MPD descrevendo novos segmentos de midia. O servidor vantajosamente gera novas instâncias da MPD e atualiza a MPD tal que os clientes podem contar com os procedimentos para atualizações continuas. O servidor pode adaptar os seus procedimentos de atualização da MPD, juntamente com a geração de segmento e publicação para os procedimentos de um cliente de referência que atua como um cliente comum pode atuar.

Se uma nova instância da MPD apenas descreve um avanço curto de tempo, então os clientes precisam frequentemente solicitar novas instâncias de MPD. Isso pode resultar em problemas de escalabilidade e tráfego de uplink e downlink desnecessário devido a solicitações frequentes desnecessárias.

Portanto, é relevante, por um lado descrever os segmentos, tanto quanto possivel para o futuro sem necessariamente torná-los acessíveis, no entanto, e por outro lado, permitir atualizações imprevistas na MPD para expressar novos locais de servidor, permite a inserção de novos conteúdos, tal como anúncios ou para prover alterações nos parâmetros de codec.

Além disso, em algumas modalidades, a duração dos segmentos de mídia pode ser pequena, tal como na faixa de vários segundos. A duração de segmentos de midia é vantajosamente flexível para ajustar a tamanhos de segmento adequados que podem ser otimizados para entrega ou propriedades de cache, para compensar o retardo ponta a ponta em serviços ao vivos ou outros aspectos que lidam com a armazenamento ou a entrega de segmentos, ou por outras razões. Especialmente nos casos em que os segmentos são pequenos em comparação com a duração de apresentação de mídia, então uma quantidade significativa de recursos do segmento de mídia e tempos de partida precisam ser descritos na descrição de apresentação de mídia. Como um resultado, o tamanho da descrição de apresentação de mídia pode ser grande, o que pode afetar negativamente o tempo de download da descrição de apresentação de mídia e, por conseguinte, afeta o retardo de inicialização da apresentação de mídia e também o uso de largura de banda sobre o link de acesso. Portanto, é vantajoso não só permitir a descrição de uma lista de segmentos de mídia que utiliza playlists, mas também permitir a descrição usando modelos ou regras de construção de URL. Modelos e regras de construção de URL são usados como sinônimos nesta descrição.

Além disso, os modelos podem ser vantajosamente usados para descrever localizadores de segmento em casos ao vivo além do tempo atual. Em tais casos, as atualizações da MPD são per se desnecessárias, visto que os localizadores, bem como a lista de segmentos são descritos pelos modelos. No entanto, imprevistos podem ainda acontecer os quais requerem mudanças nã descrição dãs representações—ou dos segmentos. Alterações em uma descrição de apresentação de midia de fluxo continuo de HTTP adaptativo podem ser necessárias quando o conteúdo a partir de múltiplas fontes diferentes é emendado, por exemplo, quando o anúncio foi inserido. O conteúdo de diferentes fontes pode diferir em uma variedade de maneiras. Outra razão, durante as apresentações ao vivo, é que pode ser necessário alterar os URLs usados para os arquivos de conteúdo para prover fail- over a partir de um servidor de origem ao vivo para o outro.

Em algumas modalidades, é vantajoso que, se a MPD é atualizada, então as atualizações para a MPD são realizadas de tal modo que a MPD atualizada é compativel com a MPD anterior, no seguinte sentido de que o cliente de referência e, portanto, qualquer cliente implementado gera uma lista idêntica funcionalmente de segmentos acessiveis a partir da MPD atualizada por qualquer tempo até o tempo de validade da MPD anterior como teria feito a partir da instância anterior da MPD. Este requisito garante que (a) os clientes podem começar imediatamente a usar a MPD nova sem a sincronização com a MPD antiga, uma vez que é compativel com a MPD antiga antes do tempo de atualização, e (b) o tempo de atualização não necessita de ser sincronizado com o tempo no qual a alteração real para a MPD ocorre. Ou seja, as atualizações para a MPD podem ser anunciadas com antecedência e o servidor pode substituir a instância antiga da MPD uma vez que novas informações estão disponíveis sem a necessidade de manter versões diferentes da MPD.

Duas possibilidades podem existir para o sincronismo de midia através de uma atualização de MPD para um conjunto de representações ou todas as representações. Quer (a) a linha de tempo global existente continua através da atualização de MPD (aqui referida como uma "atualização de MPD continua"), ou (b) as extremidades de linha de tempo atuais e uma nova linha de tempo começa com o seguinte segmento da alteração (aqui referido como uma "atualização de MPD descontinua").

A diferença entre estas opções podem ser evidentes quando se considera que as faixas de um fragmento de midia e, portanto, de um segmento, geralmente não começam e terminam ao mesmo tempo por causa da granularidade de amostra de difereciação entre as faixas. Durante a apresentação normal, amostras de uma faixa de um fragmento podem ser processadas antes de algumas amostras de outra faixa do fragmento anterior, ou seja, existe algum tipo de sobreposição entre os fragmentos, embora não possa haver sobreposição em uma única faixa.

A diferença entre (a) e (b) é se tal sobreposição pode ser ativada através de uma atualização de MPD. Quando a atualização de MPD é por causa de emenda do conteúdo completamente separado, sobreposição deste tipo é normalmente dificil de conseguir que o conteúdo de novo precisa de codificação nova para ser unido com o conteúdo anterior. Por isso, é vantajoso prover a capacidade para descontinuamente atualizar a apresentação de midia reiniciando o cronograma para determinados segmentos e, possivelmente, também definir um novo conjunto de representações, após a atualização. Além disso, se o conteúdo foi codificado de forma independente e segmentada, então ele também é evitado para ajustar data e hora para caber dentro do cronograma global da obra anterior do conteúdo.

Quando a atualização é por razões menores, como apenas adicionar novos segmentos de midia à lista de segmentos de midia descrita, õü sê õ local—de—URLs—é- alterado, então sobreposição e atualizações continuas podem ser permitidas.

No caso de uma atualização de MDP descontinua, a linha de tempo do último segmento da representação anterior 5 termina no último tempo de apresentação final de qualquer amostra no segmento. A linha de tempo da representação seguinte (ou, mais precisamente, o primeiro tempo de apresentação do primeiro segmento de midia da nova parte da apresentação de midia, também referido como o novo periodo) 10 e, vantajosamente, tipicamente começa neste mesmo instante que o fim da apresentação do último periodo tal que reprodução uniforme e continua é assegurada. Os dois casos são ilustrados na figura 11.

É preferido e vantajoso restringir atualizações 15 de MPD para fronteiras de segmento. A lógica para restringir tais alterações ou atualizações para fronteiras de segmento é como se segue. Primeiro, as alterações para os metadados binários para cada representação, normalmente cabeçalho do filme, pode ocorrer, pelo menos nos fronteiras 20 de segmento. Em segundo lugar, a Descrição de Apresentação de Midia pode conter os ponteiros (URLs) para os segmentos. Em certo sentido, a MPD é a estrutura de dados "guarda- chuva" que reúne todos os arquivos associados do segmento com a apresentação de midia. Para manter esta relação de 25 contenção, cada segmento pode ser referenciado por uma única MPD e quando a MPD é atualizada, ela só vantajosamente atualizada em uma fronteira de segmento.

Fronteiras de segmento não são geralmente necessárias para ser alinhadas, no entanto, para o caso de 30 o conteúdo emendado a partir de fontes diferentes, e para atualizações de MPD descontínuos geralmente, isto faz sentido alinhar as fronteiras de segmento (especificamente, que o último segmento de cada representação pode terminar no mesmo quadro de video e não pode conter amostras de áudio com um tempo de partida de apresentação posterior do que o tempo de apresentação desse quadro). Uma atualização descontinua pode então iniciar um novo conjunto de representações em um instante de tempo comum, referido como periodo. 0 tempo de partida da validade deste novo conjunto de representações é provido, por exemplo, por um periodo de tempo de partida. 0 tempo de partida relativo de cada representação é reajustado para zero e o tempo de partida do periodo coloca o conjunto de representações neste novo periodo na linha de tempo global de apresentação de midia.

Para atualizações de MPD continuas, as fronteiras de segmento não são obrigadas a estar alinhadas. Cada segmento de cada representação alternativa pode ser regido por uma única Descrição de Apresentação de Midia e assim as solicitações de atualização para novas instâncias da descrição de apresentação de midia, geralmente desencadeadas pela expectativa de que nenhum segmento de midia adicional está descrito na operação de MPD, podem ocorrer em momentos diferentes, dependendo do conjunto de representações consumidas, incluindo o conjunto de representações que estão previstas para ser consumidas.

Para suportar atualizações em elementos de MPD e atributos em um caso mais geral, qualquer elementos que não apenas representações ou conjunto de representações podem ser associados com um tempo de validade. Assim, se certos elementos da MDP precisam de ser atualizados, por exemplo, onde o número de representações é alterado ou as regras de construção de URL são alteradas, então estes elementos podem, cada um individualmente ser atualizados em tempos especificados, por provimento de múltiplas cópias do elemento com tempos de validade disjuntos.

A validade é vantajosamente associada com o tempo de midia global, de tal modo que o elemento descrito associado com um tempo de validade é válido em um periodo de linha do tempo global de apresentação de midia.

Como discutido acima, em uma modalidade, os tempos de validade só são adicionados a um conjunto completo de representações. Cada conjunto completo, então forma um periodo. O tempo de validade então forma o tempo de partida do periodo. Em outras palavras, em um caso especifico da utilização do elemento de validade, um conjunto completo de representações pode ser válido para um periodo de tempo, indicado por um tempo de validade global para um conjunto de representações. O tempo de validade de um conjunto de representações é referido como um periodo. No inicio de um novo periodo, a validade da representação ajustada anteriormente expirou e o novo conjunto de representações é válido. Observe novamente que os tempos de periodos de validade são preferencialmente disjuntos.

Como notado acima, as alterações da Descrição de Apresentação de Midia ocorre em fronteiras de segmento, e assim para cada representação, a mudança de um elemento ocorre realmente na próxima fronteira de segmento. O cliente pode então formar uma MPD válida incluindo uma lista de segmentos para cada instante de tempo, dentro do tempo de apresentação de midia.

Emendar o bloco descontinuo pode ser adequado em casos onde os blocos contêm dados de midia a partir de diferentes representações, ou de conteúdo diferente, por exemplo, de um segmento de conteúdo e um anúncio, ou em outros casos. Ele pode ser solicitado em um sistema de fluxo continuo de solicitação de bloco que as alterações para metadados de apresentação ocorrerão somente nas fronteira de bloco. Isto pode ser vantajoso por motivos cte aplicação porque atualizar os parâmetros de decodificador de midia dentro de um bloco pode ser mais complexo do que atualizá-los apenas entre os blocos. Neste caso, pode vantajosamente ser especificado que os intervalos de validade, como descrito acima podem ser interpretados como aproximados, de tal modo que um elemento é considerado válido a partir da primeira fronteira de bloco não antes do inicio do intervalo de validade especificado para a primeira fronteira de bloco não antes da extremidade do intervalo de validade especificado.

Uma modalidade exemplar do acima descreve melhorias inovadoras para um sistema de fluxo continuo de solicitação de bloco é descrita na seção mais tarde apresentada intitulada Mudanças para Apresentações de Midia. Sinalização de Duração de Segmento

Atualizações descontinuas eficazmente dividem a apresentação em uma série de intervalos disjuntos, referidos como periodo. Cada periodo tem o seu próprio cronograma para a temporização de amostra de midia. A temporização de midia de representação dentro de um periodo pode ser vantajosamente indicada, especificando uma lista separada compacta de duração do segmento de cada periodo ou de cada representação em um periodo.

Um atributo, por exemplo referido como tempo de partida do periodo, associado a elementos dentro da MPD pode especificar o tempo de validade de certos elementos dentro do tempo de apresentação de midia. Este atributo pode ser adicionado a quaisquer elementos (atributos que podem atribuir um prazo de validade podem ser alterados para elementos) da MPD.

Para atualizações de MPD descontinuas os segmentos de todas as representações podem terminar rra- descontinuidade. Isto geralmente implica pelo menos que o último segmento antes da descontinuidade tem uma duração diferente dos anteriores. Sinalização de duração de segmento pode envolver indicar que todos os segmentos têm a mesma duração ou indicar uma duração separada para cada segmento. Pode ser desejável ter uma representação compacta para uma lista de durações de segmento que é eficaz no caso de que muitos deles têm a mesma duração.

Durações de cada segmento em uma representação ou um conjunto de representações podem vantajosamente ser efetuadas com uma única sequência de caracteres que especifica todas as durações de segmento para um único intervalo desde o inicio da atualização descontinua, isto é, o inicio do periodo até o último segmento de midia descrito na MPD. Em uma modalidade, o formato deste elemento é uma sequência de texto de acordo com uma produção que contém uma lista de entradas de duração do segmento em que cada entrada contém um atributo de duração dur e um multiplicador opcional mult do atributo indicando que esta representação contém <mult> dos primeiros segmentos de entrada de duração <dur> da primeira entrada, então <mult> do segundo segmento de entrada de duração <dur> da segunda entrada e assim por diante.

Cada entrada de duração especifica a duração de um ou mais segmentos. Se o valor <dur> é seguido pelo caracter e um número, então este número especifica o número de segmentos consecutivos com a sua duração, em segundos. Se o sinal multiplicador está ausente, o número de segmentos é um. Se o está presente sem nenhum número seguinte, então todos os segmentos subsequentes têm a duração especificada e pode não haver mais entradas na lista. Por exemplo, a sequência "30*" significa que todos os segmentos têm a duração de 3Õ segundos. A sequência * 12 10.5" indica 12 segmentos de duração de 30 segundos, seguidos de um com a duração de 10,5 segundos.

Se durações de segmento são especificadas separadamente para cada representação alternativa, então a soma das durações de segmento dentro de cada intervalo pode ser a mesma para cada representação. No caso de faixas de video, o intervalo pode terminar no mesmo quadro, em cada representação alternativa.

Os versados na técnica, após a leitura desta descrição, podem encontrar formas semelhantes e equivalentes para expressar durações de segmento de uma maneira compacta.

Em outra modalidade, a duração de um segmento é sinalizada para ser constante para todos os segmentos com a representação exceto para o último por um atributo de sinal de duração <duration>. A duração do último segmento antes de uma atualização descontinua pode ser mais curta, enquanto o ponto de inicio da próxima atualização descontinua ou o inicio de um novo periodo é provido, o que implica então na duração do último segmento alcançando o inicio do próximo periodo. Mudanças e Atualizações de Metadados de Representação

Indicar mudanças de metadados de representação de codec binária, tal como mudanças no cabeçalho de filme "moov" podem ser realizadas de diferentes maneiras: (a) pode haver uma caixa moov para toda a representação em um arquivo separado referenciado na MPD, (b) pode haver uma caixa moov para cada representação alternativa em um arquivo separado referenciado em cada Representação Alternativa, (c) cada segmento pode conter uma caixa moov e é, portanto, auto-contido, (d) pode haver uma caixa moov para toda a representação em um arquivo 3GP juntamente com MPD.

Note-se que no caso de (a) e (b) , o único 'moov' pode ser vantajosamente combinado com o conceito de 5 validade a partir do acima no sentido de que mais caixas 'moov' podem ser referenciadas em uma MPD desde que a sua validade seja separada. Por exemplo, com a definição de um limite de periodo, a validade do 'moov' no periodo antigo pode expirar com o inicio do novo periodo.

No caso de opção (a) , a referência à caixa moov única pode ser atribuida um elemento de validade. Cabeçalhos de apresentação múltiplos podem ser permitidos, mas apenas um pode ser válido em um tempo . Em uma outra modalidade, o tempo de validade de todo o conjunto de 15 representações em um periodo ou a totalidade do periodo, tal como reprodução acima pode ser usado como um tempo de validade para este metadados de representação, tipicamente provido como o cabeçalho moov. No. caso de opção (b) , a referência à caixa moov 20 de cada representação pode ser atribuida a um elemento de validade. Cabeçalhos de representação múltiplos podem ser permitidos, mas apenas um pode ser válido em um tempo. Em uma outra modalidade, o tempo de validade da representação inteira ou a totalidade do periodo, tal como reprodução 25 acima pode ser usado como um tempo de validade para estes metadados de representação, tipicamente providos como o cabeçalho moov. No caso de opções (c), nenhuma sinalização na MPD pode ser adicionada, mas sinalização adicional no fluxo de 30 midia pode ser adicionada para indicar se a caixa moov mudará para qualquer um dos segmentos próximos. Isto é explicado no abaixo no contexto de "Atualizações de sinalização dentro de Metadados de Segmento". Atualizações de Sinalização dentro de Metadados de Segmento

Para evitar atualizações frequentes da descrição de apresentação de midia para obter conhecimento sobre as 5 atualizações possíveis, é vantajoso sinalizar essas atualizações, juntamente com os segmentos de midia. Pode ser provido um elemento adicional ou elementos dentro dos próprios segmentos de midia que podem indicar que metadados atualizados tais como a descrição de apresentação de midia 10 estão disponíveis e têm de ser acessados para dentro de um determinado periodo de tempo para continuar a criação de forma bem sucedida de listas de segmento acessíveis. Além disso, tais elementos podem prover um identificador de arquivo, como um URL, ou informações que podem ser 15 utilizadas para construir um identificador de arquivo, para o arquivo de metadados atualizado. O arquivo de metadados atualizado pode incluir metadados iguais aos providos no arquivo de metadados original para a apresentação modificada para indicar intervalos de validade, juntamente 20 com metadados adicionais também acompanhados por intervalos de validade. Uma tal indicação pode ser provida em segmentos de midia de todas as representações disponíveis para uma apresentação de midia. Um cliente acessando um sistema de fluxo continuo de solicitação de bloco, na 25 detecção de uma indicação desse tipo dentro de um bloco de midia, pode usar o protocolo de download de arquivos ou outros meios para recuperar o arquivo de metadados atualizado. O cliente é, assim, provido com informações sobre mudanças na descrição de apresentação de midia e o 30 tempo em que elas irão ocorrer ou ocorreram.

Vantajosamente, cada cliente solicita a descrição de apresentação de midia atualizada apenas uma vez quando tal mudança ocorrer, em vez de "sondagem" e que recebe o arquivo muitas vezes para possiveis atualizações ou mudanças.

Exemplos de mudanças incluem a adição ou remoção de representações, a mudança de uma ou mais representação, tais como alteração na taxa de bits, relação de aspecto, resolução, faixas incluidas ou parâmetros de codec, e mudanças nas regras de construção de URL, por exemplo, um servidor de origem diferente para um anúncio. Algumas alterações podem afetar apenas o segmento de inicialização, como o cabeçalho de filme ("moov") associado a um átomo de representação, ao passo que outras mudanças podem afetar a descrição de apresentação de midia (MPD).

No caso de conteúdo sob demanda, essas mudanças e sua temporização podem ser conhecidas com antecedência e poderiam ser sinalizadas na descrição de apresentação de Midia.

Para conteúdo ao vivo, as alterações não podem ser conhecidas até o ponto em que elas ocorrem. Uma solução é permitir a Descrição de Apresentação de Midia disponivel em um URL especifico para ser dinamicamente atualizada e exigir que os clientes regularmente solicitem esta MPD, a fim de detectar alterações. Esta solução tem a desvantagem em termos de escalabilidade (carga de origem do servidor e a eficiência do cache). Em um cenário com um grande número de espectadores, caches podem receber muitas solicitações para a MPD após a versão anterior expirar do cache e antes da nova versão ser recebida e tudo isso pode ser enviado para o servidor de origem. O servidor de origem pode precisar constantemente de processar solicitações de caches para cada versão atualizada da MPD. Além disso, as atualizações não podem ser facilmente alinhadas com tempo de mudanças na apresentação de midia.

Uma vez que uma das vantagens de fluxo contínuo HTTP é a capacidade de utilizar infraestrutura da web padrão e serviços para a escalabilidade, uma solução preferida pode envolver apenas arquivos "estáticos" (ou seja passíveis de cache) e não confiar nos arquivos de "sondagem" de clientes para ver se eles mudaram.

As soluções são discutidas e propostas para resolver a atualização de metadados, incluindo a descrição de apresentação de mídia e metadados de representação binários como átomos "moov" em uma apresentação de mídia de fluxo contínuo HTTP adaptativo.

Para o caso de conteúdo ao vivo, os pontos em que a MPD ou "moov" podem mudar não podem ser conhecidos quando a MPD é construída. Como "sondagem" frequente da MPD para verificar as atualizações deve ser evitada, por razões de largura de banda e escalabilidade, atualizações para a MPD podem ser indicadas "em banda" nos arquivos de segmento em si, ou seja, cada segmento de mídia pode ter a opção de indicar atualizações. Dependendo dos formatos de segmento (a) a (c) a partir do acima, a atualização diferente pode ser sinalizada.

Geralmente, a seguinte indicação pode vantajosamente ser provida em um sinal dentro do segmento: um indicador de que a MPD pode ser atualizada antes de solicitar o próximo segmento dentro desta representação ou qualquer segmento seguinte, que tem tempo de partida maior do que o tempo de partida do segmento atual. A atualização pode ser anunciada com antecedência, indicando que a atualização só precisa acontecer em qualquer segmento até o próximo. Esta atualização de MPD pode também ser utilizada para atualizar metadados de representação binária como cabeçalhos de filme no caso do localizador do segmento de comunicação estar alterado. Outro sinal pode indicar que com a conclusão deste segmento, nenhum segmento que avançou no tempo deve ser solicitado.

No caso de segmentos serem formatados de acordo com o formato do segmento (c) , isto é, cada segmento de 5 midia pode conter metadados de autoinicialização tais como o cabeçalho de filme, então ainda um outro sinal pode ser adicionado, indicando que o segmento posterior contém um Cabeçalho de filme atualizado (moov). Esta vantagem permite que o cabeçalho do filme seja incluido no segmento, mas o 10 cabeçalho de filme só precisa ser solicitado pelo cliente, se o segmento anterior indicar uma atualização do cabeçalho de filme ou no caso de busca ou acesso aleatório ao alternar representações. Em outros casos, o cliente pode emitir uma solicitação de intervalo de bytes para o 15 segmento, que exclui o cabeçalho de filme do download, portanto, vantajosamente poupa largura de banda.

Em ainda outra modalidade, se a indicação de atualização de MPD é sinalizada, então o sinal pode também conter um localizador tal como URL para a descrição de 20 Apresentação de Midia atualizada. A MPD atualizada pode descrever a apresentação, tanto antes quanto após a atualização, usando os atributos de validade, tais como um novo e antigo periodo e no caso de atualizações descontinuas. Isto pode ser vantajosamente utilizado para 25 permitir visualizações de deslocamento de tempo, tal como descrito mais abaixo, mas também permite vantajosamente que a atualização de MPD seja sinalizada em qualquer momento antes das alterações que ela contém entrar em vigor. O cliente pode imediatamente baixar a MPD e aplicá-la à 30 apresentação continua.

Em uma realização especifica, a sinalização de quaisquer mudanças para a descrição de apresentação de midia, os cabeçalhos moov ou o fim da apresentação podem estar contidos em uma caixa de transmissão de informações que está formatada seguindo as regras do formato de segmento utilizando a estrutura de caixa do formato de arquivo de midia baseado em ISO. Esta caixa pode prover um sinal especifico para qualquer das atualizações diferentes.

Caixa de Informação de Fluxo Continuo Definição Tipo de Caixa: 'sinf Recipiente: Nenhum Mandatório: Não Quantidade: zero ou um. A Caixa de Informação de Fluxo Continuo contém informações sobre a apresentação de fluxo continuo da qual o arquivo faz parte. Sintaxe aligned (8) class StreaminglnformationBox extends FullBox ('sinf) { unsigned int (32) streaming_information_flags;

A seguir, são campos opcionais string mpd_location } Semântica streaming_information_flags contém a lógica OU de zero ou mais dos seguintes: 0x00000001 atualização de Cabeçalho de Filme seguinte 0x00000002 atualização de Descrição de Apresentação 0x00000004 Fim-de-apresentação mpd_location está presente se e somente se flags de atualização de Descrição de Apresentação for apresentado e prover um Localizador de Recurso Uniforme para a nova descrição de apresentação de Midia.

Caso de Uso Exemplar para Atualizações de MPD para Servços ao Vivo Suponha que um provedor de serviços quer oferecer um evento de futebol ao vivo usando o fluxo continuo de 5 solicitação de bloco melhorado aqui descrito. Talvez milhões de usuários possam querer acessar a apresentação do evento. O evento ao vivo é esporadicamente interrompido por pausas, quando um tempo limite é chamado, ou outros na ação, durante o qual anúncios podem ser adicionados. 10 Normalmente, há um aviso prévio de pouco ou nenhum tempo exato das quebras.

O provedor de serviços pode precisar de prover infraestrutura redundante (por exemplo, codificadores e servidores) para permitir uma perfeita transição no caso de 15 qualquer um dos componentes falhar durante o evento ao vivo.

Suponha que um usuário, Anna, acesse o serviço em um ônibus com o seu dispositivo móvel, e o serviço está disponivel imediatamente. Próximo a ela se senta outro 20 usuário, Paulo, que assiste ao evento em seu laptop. Um gol é marcado e ambos comemoram este evento, ao mesmo tempo. Paulo diz a Anna que o primeiro gol do jogo foi ainda mais emocionante e Anna usa o serviço para que ela possa ver o evento 30 minutos atrás no tempo. Depois de ter visto o 25 gol, ela volta para o evento ao vivo.

Para resolver esse caso de uso, o provedor de serviços deve ser capaz de atualizar a MPD, o sinal para os clientes que uma MPD atualizada está disponivel, e permitir que os clientes acessem o serviço de fluxo continuo de tal 30 forma que ele possa apresentar os dados próximos a tempo real.

Atualização da MPD é viável, de forma assíncrona para a entrega de segmentos, como explicado aqui em outro lugar. O servidor pode prover garantias para o receptor que uma MPD não é atualizada durante algum tempo. O servidor pode contar com a MPD atual. No entanto, nenhuma sinalização explicita é necessária quando a MPD é 5 atualizada antes de algum periodo de atualização minimo.

Reprodução completamente sincrona é dificilmente alcançada conforme o cliente pode operar em diferentes instâncias de atualização da MPD e, portanto, os clientes podem ter drift. Usar as atualizações da MPD, o servidor 10 pode transmitir alterações e os clientes podem ser alertados para as mudanças, mesmo durante uma apresentação. Sinalização em banda sobre uma base por segmento pode ser usada para indicar a atualização da MPD, de modo que atualizações podem ser limitadas a fronteiras de segmento, 15 mas que devem ser aceitáveis na maioria das aplicações.

Um elemento de MPD pode ser acrescentado o qual provê o tempo de publicação no tempo de relógio de parede da MPD, bem como uma caixa de atualização opcional da MPD — que é adicionado no inicio de segmentos para sinalizar, que uma atualização de MPD é necessária. As atualizações podem ser feitas de forma hierárquica, como com as MPDs.

O "tempo de publicação" de MPD provê um identificador exclusivo para a MPD e quando a MPD foi emitida. Ele também provê uma âncora para os procedimentos 25 de atualização.

A caixa de atualização de MPD pode ser encontrada na MPD após a caixa "styp", e definida por um tipo de caixa = "mupe", não necessitando de nenhum recipiente, não sendo mandatória, e tendo uma quantidade de zero ou um. A caixa 30 de atualização de MPD contém informações sobre a apresentação de midia da qual o segmento faz parte. Sintaxe exemplar é como se segue: aligned (8) class MPDUpdateBox extends FullBox ('Mupe') { unsigned int (3) mdp information flags; unsigned int (1) new-location flag; unsigned int (28: ) latest_mpd_update time;

A seguir, são campos opcionais string mpd_location } A semântica dos vários objetos da classe MPDUpdateBox poderia ser a seguinte: mdp_information_flags: lógica OU de zero ou mais dos seguintes: 0x00 Descrição de Apresentação de Midia atualiza agora 0x01 Descrição de Apresentação de Midia atualiza a frente 0x02 Fim-de-apresentação 0x03-0x07 Reservado new_location_flag: se ajustado para 1, então a Descrição de Apresentação de Midia nova está disponivel em urn novo local especificado no local mpd. latest_mpd_update time: especifica o tempo (em ms) por quando a atualização de MPD é necessária relativa ao tempo em questão da MPD da última MPD. O cliente pode optar por atualizar a MPD a qualquer momento entre agora. MP_location: está presente se e somente se o new_location_flag é ajustado e, nesse caso, mpd_location prover um Localizador de Recurso Uniforme para a nova descrição de apresentação de midia. Se a largura de banda utilizada por atualizações é um problema, o servidor pode oferecer MPDs para certas capacidades do dispositivo tal que somente estas partes são atualizadas. Visualização de deslocamento de tempo e PVR de Rede

Quando a visualização de deslocamento de tempo é suportada, pode acontecer que para o tempo de vida da 5 sessão de duas ou mais MPDs ou cabeçalhos de filme são válidas. Neste caso, atualizar a MPD quando necessária, mas adicionar o mecanismo de validade ou o conceito de periodo, uma MPD válida pode existir para toda a janela de tempo. Isso significa que o servidor pode garantir que qualquer 10 MPD e cabeçalho de filme sejam anunciados por qualquer periodo de tempo que está dentro da janela de tempo válida para visualização de deslocamento de tempo. Cabe ao cliente garantir que a sua MPD disponivel e metadados para o seu tempo de apresentação atual sejam válidos. Migração de uma 15 sessão ao vivo para uma sessão PVR de rede usando apenas pequenas atualizações de MPD também podem ser suportadas. Segmentos de Midia Especiais

Uma questão quando o formato de arquivo de ISO / IEC 14496-12 é utilizado dentro de um sistema de fluxo 20 continuo de solicitação de bloco é que, tal como descrito no que precede, pode ser vantajoso armazenar os dados de midia em uma única versão da apresentação nos vários arquivos, dispostos em segmentos de tempo consecutivos. Além disso, pode ser vantajoso fazer com que cada arquivo 25 comece com um ponto de acesso aleatório. Além disso, pode ser vantajoso escolher as posições dos pontos de busca durante o processo de codificação de video e para o segmento de apresentação em vários arquivos cada um começando com um ponto de busca com base na escolha de 30 pontos de busca que foi efetuada durante o processo de codificação, em que cada ponto de acesso aleatório pode ou não pode ser colocado no inicio de um arquivo, mas em que cada arquivo começa com um ponto de acesso aleatório. Em uma modalidade com as propriedades descritas acima, os metadados de apresentação, ou descrição de apresentação de midia, pode conter a duração exata de cada arquivo, onde a duração é tomada por exemplo para significar a diferença 5 entre o tempo de partida da midia de video de um arquivo e o tempo de partida da midia de video do próximo arquivo. Com base nessas informações nos metadados de apresentação o cliente é capaz de construir um mapeamento entre a linha do tempo global para a apresentação de midia e a linha do 10 tempo local para a midia dentro de cada arquivo.

Em uma outra modalidade, o tamanho dos metadados de apresentação pode ser vantajosamente reduzido especificando em vez de cada arquivo ou segmento ter a mesma duração. No entanto, neste caso, e onde os arquivos 15 de midia são construídos de acordo com o método acima a duração de cada arquivo pode não ser exatamente igual à duração especificada na descrição de apresentação de midia porque um ponto de acesso aleatório pode não existir no ponto que é exatamente a duração especificada do inicio do 20 processo.

Uma modalidade adicional da invenção para prover um funcionamento correto do sistema de fluxo continuo de solicitação de bloco, apesar da discrepância mencionada acima é agora descrita. Neste método, pode ser provido um 25 elemento de dentro de cada arquivo que especifica o mapeamento da linha do tempo local da midia dentro do arquivo (pelo qual se entende a linha de tempo iniciando a partir de zero timestamp contra o qual a decodificação e composição de timestamps das amostras de midia no arquivo 30 são especificadas de acordo com a ISO / IEC 14496-12) com o cronograma de apresentação global. Esta informação de mapeamento pode compreender um único timestamp em tempo de apresentação global que corresponde à data e hora zero no cronograma de arquivo local. A informação de mapeamento pode alternativamente compreender um valor de desvio que especifica a diferença entre o tempo de apresentação global correspondente ao timestamp zero no cronograma de arquivo local e o tempo de apresentação global correspondente ao inicio do arquivo de acordo com a informação provida nos metadados de apresentação.

Exemplo de tais caixas pode ser, por exemplo, a caixa de tempo de decodif icação de fragmento de faixa ('tfdt') ou a caixa de ajuste de fragmento de faixa ('tfad' ) , juntamente com a caixa de ajuste de fragmento de midia ('TFMA').

Cliente Exemplar incluindo Geração de Lista de Segmento Um cliente exemplar será agora descrito. Pode ser usado como um cliente de referência para o servidor para assegurar a correta geração e atualizações da MPD.

Um cliente de fluxo continuo HTTP é guiado pelas informações providas na . MPD. Supõe-se que o cliente tem acesso à MPD que recebeu no tempo T, ou seja, o tempo que foi capaz de receber uma MPD. Determinar a recepção bem sucedida pode incluir o cliente obtendo uma MPD atualizada ou o cliente verificando que a MPD não foi atualizada desde a recepção anterior bem sucedida.

Um exemplo do comportamento do cliente é introduzido. Para prover um serviço de fluxo continuo para o usuário, o primeiro cliente analisa a MPD e cria uma lista de segmentos acessiveis para cada representação para a hora local do cliente em uma hora atual do sistema, tendo em conta procedimentos de geração de lista de segmento, conforme detalhado abaixo, possivelmente usando playlists ou usando as regras de construção de URL. Então, o cliente seleciona uma ou múltiplas representações com base nas informações dos atributos de representação e outras informações, por exemplo, largura de banda disponivel e capacidades do cliente. Dependendo do agrupamento as representações podem ser apresentadas individual ou 5 conjuntamente com outras representações.

Para cada representação, o cliente adquire os metadados binários, como o cabeçalho "moov" para a representação, se houver, e os segmentos de midia das representações selecionadas. O cliente acessa o conteúdo de 10 midia, solicitando segmentos ou intervalos de bytes de segmentos, possivelmente utilizando a lista de segmentos. O cliente pode, inicialmente, armazenar em buffer a midia antes de iniciar a apresentação e, uma vez que a apresentação começou, o cliente continua a consumir o 15 conteúdo de midia continuamente solicitando segmentos ou partes de segmentos tendo em conta os procedimentos de atualização da MPD.

O cliente pode comutar representações tendo em conta as informações de MPD atualizadas e/ou informações 20 atualizadas do seu ambiente, por exemplo, mudança de largura de banda disponivel. Com qualquer solicitação para um segmento de midia que contém um ponto de acesso aleatório, o cliente pode mudar para uma representação diferente. Quando se desloca para a frente, isto é, o 25 avanço de tempo de sistema atual (referido como "tempo NOW" para representar o tempo relativo à apresentação), o cliente consome os segmentos acessiveis. Com cada avanço no tempo, o cliente possivelmente expande a lista de segmentos acessiveis para cada representação de acordo com os 30 procedimentos a seguir especificados.

Se o fim da apresentação de midia ainda não foi atingido e se o tempo de reprodução ainda está dentro de um limite para o qual o cliente antecipa para executar a midia da midia descrita na MPD para qualquer consumo ou representação consumida, então o cliente pode solicitar uma atualização da MPD, com um novo tempo de busca de recepção tempo T. Uma vez recebido, o cliente leva em conta a MPD 5 possivelmente atualizada e o novo tempo T na geração das listas do segmento acessiveis. A Figura 29 ilustra um procedimento para serviços ao vivo em tempos diferentes no cliente.

Geração de Lista de Segmento acessivel Suponha que o cliente de fluxo continuo HTTP tem acesso a uma MPD e pode querer gerar uma lista de segmentos acessivel para um tempo do relógio NOW. O cliente está sincronizado a uma referência de tempo global com certa precisão, mas vantajosamente nenhuma sincronização direta 15 com o servidor de fluxo continuo HTTP é necessária.

A lista segmento acessivel para cada representação é de preferência definida como um par de lista de um tempo de partida de segmento e localizador de segmento onde o tempo de partida de segmento pode ser 20 definido como sendo em relação ao inicio da representação sem perda de generalidade. O inicio da representação pode ser alinhado com o inicio de um periodo ou se este conceito é aplicado. Caso contrário, o inicio de representação pode estar no inicio da apresentação de midia.

O cliente usa regras de construção de URL e temporização como, por exemplo, definida adicionalmente aqui. Uma vez que uma lista de. segmentos descritos é obtida, esta lista é ainda mais restrita aos acessiveis, o que pode ser um subconjunto dos segmentos da apresentação 30 de midia completa. A construção é governada pelo valor atual do relógio no tempo NOW do cliente. Geralmente, os segmentos só estão disponíveis para qualquer momento dentro de um conjunto de tempos de disponibilidade. Por vezes NOW fora desta janela, nenhum segmento está disponivel. Além disso, para serviços ao vivo, assumir algum checktime e tempo provê informações sobre o quão longe no futuro, a midia é descrita. O checktime é reprodução no eixo do tempo 5 de midia documentada por MPD; quando a reprodução do tempo de reprodução do cliente atinge checktime, ele vantajosamente solicita uma MPD nova. ; quando o tempo de reprodução do cliente atinge checktime, ele vantajosamente solicita uma nova MPD.

Então a lista de segmento é ainda restrita pelo checktime juntamente com o atributo de MDP TimeShiftArmazenadorDepth tal que apenas segmentos de midia disponíveis são aqueles para os quais a soma do tempo de partida do segmento de midia e o tempo de partida de 15 representação cai no intervalo entre NOW menos timeShiftArmazenadorDepth menos a duração do último segmento descrito e o menor valor de qualquer checktime ou NOW. Blocos Escaláveis

Às vezes a largura de banda disponivel cai tão abaixo que o bloco ou blocos a ser recebidos em um receptor tornam-se pouco prováveis que seja completamente recebidos a tempo de ser reproduzidos sem interromper a apresentação. 0 receptor pode detectar estas situações com antecedência.

Por exemplo, o receptor pode determinar que ele está recebendo blocos que codificam 5 unidades de midia a cada 6 unidades de tempo, e tem um armazenador de 4 unidades de midia, de modo que o receptor pode esperar ter de parar, pausar, apresentar, cerca de 24 unidades de tempo 30 posteriores. Com antecedência suficiente, o receptor pode reagir a uma tal situação, por exemplo, abandonando o fluxo atual de blocos e começando a solicitar um bloco ou blocos de uma representação diferente do conteúdo, tal como um que usa menos largura de banda por unidade de tempo de reprodução. Por exemplo, se o receptor ligado a uma representação onde os blocos codificados para o tempo de video, pelo menos, 20% mais para os blocos do mesmo 5 tamanho, o receptor pode ser capaz de eliminar a necessidade de parar até que a situação de largura de banda melhore.

No entanto, pode ser um desperdício ter o receptor inteiramente descartando os dados já recebidos a 10 partir da representação abandonada. Em uma modalidade de um bloco de fluxo do sistema aqui descrito, os dados dentro de cada bloco podem ser codificados e dispostos de tal maneira que certos prefixos dos dados dentro do bloco podem ser usados para continuar a apresentação sem o restante do 15 bloco ter sido recebido. Por exemplo, as técnicas bem conhecidas da codificação de video escalável podem ser usadas. Exemplos de tais métodos de codificação de video incluem Codificação de Video H.264 Escalável (SVC) ou a escalabilidade temporal de Codificação de Video avançada 20 H.264 (AVC). Vantajosamente, este método permite que a apresentação continue com base na porção de um bloco que foi recebido, mesmo quando a recepção de um bloco ou blocos pode ser abandonada, por exemplo, devido a alterações na largura de banda disponivel. Outra vantagem é que um único 25 arquivo de dados pode ser utilizado como fonte para múltiplas representações diferentes de conteúdo. Isto é possivel, por exemplo, fazendo uso de solicitações GET HTTP parcial que selecionam o subconjunto de um bloco correspondente à representação requerida.

Uma melhoria detalhada aqui é um segmento aperfeiçoado, um mapa de segmento escalável. 0 mapa de segmento escalável contém os locais das diferentes camadas no segmento de tal modo que o cliente pode ter acesso às partes dos segmentos acordo e extrair as camadas. Em outra modalidade, os dados de midia no segmento são ordenados de tal modo que a qualidade do segmento aumenta durante o download dos dados gradualmente a partir do inicio do segmento. Em uma outra modalidade, o aumento gradual da qualidade é aplicado para cada bloco ou fragmento contido no segmento, de tal modo que as solicitações de fragmento pode ser feitas para resolver a abordagem escalável. A figura 12 é uma figura que mostra um aspecto de blocos expansíveis. Nesta figura, um transmissor 1200 emite metadados 1202, camada expansível 1 (1204), camada expansível 2 (1206), e camada escalável 3 (1208), sendo a última mais atrasada. Um receptor 1210 pode então usar metadados 1202, camada escalável 1 (1204), e camada escalável 2 (1206) para apresentar a apresentação de midia 1212. Camadas de Escalabilidade Independentes

Como acima explicado, é indesejável para um sistema de fluxo continuo de solicitação de bloco ter de parar quando o receptor é incapaz de receber os blocos solicitados de uma representação especifica dos dados de midia em tempo para a sua reprodução, tal como muitas vezes cria uma má experiência de usuário. Paradas podem ser evitadas, reduzidas ou atenuadas através da restrição de uma taxa de dados das representações escolhidas para ser muito menor do que a largura de banda disponível, de modo que se torna muito improvável que qualquer dada porção da apresentação não seria recebida no tempo, mas esta estratégia tem a desvantagem de que a qualidade de midia é necessariamente muito menor do que poderia, em principio, ser suportado pela largura de banda disponível. Uma apresentação de qualidade inferior da que é possivel também pode ser interpretada como uma má experiência de usuário.

Assim, o designer de um sistema de fluxo continuo de solicitação de bloco é confrontado com uma escolha no desenho dos procedimentos do cliente, programar o cliente ou configuração de hardware, seja para solicitar uma versão 5 de conteúdo que tem uma taxa de dados muito menor que a largura de banda disponivel, caso em que o usuário pode sofrer fraca qualidade de midia, ou para solicitar uma versão de conteúdo que tem uma taxa de dados perto da largura de banda disponivel, caso em que o usuário pode 10 sofrer uma alta probabilidade de pausas durante a apresentação como as alterações de largura de banda disponivel.

Para lidar com tais situações, os sistemas de fluxo continuo de bloco aqui descritos podem ser 15 configurados para lidar com múltiplas camadas de escalabilidade de forma independente, de modo que um receptor pode fazer solicitações em camadas e um transmissor pode responder a solicitações em camadas.

Em tais modalidades, os dados de midia codificada 20 para cada bloco podem ser divididos em múltiplas partes separadas, aqui referidas como "camadas", tal que a combinação de camadas compreende a totalidade dos dados de midia para um bloco e tal que um cliente que recebeu determinados subconjuntos das camadas pode realizar 25 decodificação e apresentação de uma representação do conteúdo. Nesta abordagem, a ordenação dos dados no fluxo é tal que intervalos contiguos estão aumentando na qualidade e os metadados refletem isto.

Um exemplo de uma técnica que pode ser usada para 30 gerar camadas com a propriedade acima é a técnica de codificação de video escalável por exemplo, como descrito em Padrões ITU-T H.264/SVC. Outro exemplo de uma técnica que pode ser usada para gerar camadas com a propriedade acima é a técnica de camadas de escalabilidade temporal, tal como previsto no padrão ITU-T H.264/AVC.

Nestas modalidades, metadados podem ser providos na MPD ou no próprio segmento que permite a construção de 5 solicitações de camadas individuais de qualquer bloco de dados e/ou combinações de camadas e/ou uma dada camada de blocos múltiplos e/ou uma combinação de camadas de blocos múltiplos. Por exemplo, as camadas que compreendem um bloco podem ser armazenadas dentro de um único arquivo e 10 metadados podem ser providos especificando os intervalos de bytes dentro do arquivo correspondente para as camadas individuais.

Um protocolo de download de arquivo capaz de especificar intervalos de bytes, por exemplo, HTTP 1,1, 15 pode ser usado para solicitar camadas individuais ou múltiplas camadas. Além disso, como será claro para um versado na técnica na revisão desta descrição, as técnicas descritas acima referentes à construção, solicitação, e download de blocos de tamanho variável e combinações 20 variáveis de blocos podem ser aplicadas neste contexto também. Combinações

Várias modalidades são agora descritas que podem ser vantajosamente empregues por um cliente de fluxo 25 continuo de solicitação de bloco, a fim de alcançar uma melhoria na experiência de usuário e/ou uma redução nos requisitos de capacidade de infraestrutura de serviço em relação às técnicas existentes através da utilização de dados de midia particionados em camadas, tal como descrito 30 acima.

Em uma primeira modalidade, as técnicas conhecidas de um sistema de fluxo continuo de solicitação de bloco podem ser aplicadas com a modificação de que diferentes versões do conteúdo são, em alguns casos substituídas por diferentes combinações das camadas. Isto quer dizer que, quando um sistema existente pode prover duas representações distintas o conteúdo do sistema 5 aperfeiçoado aqui descrito pode prover duas camadas, onde uma representação do conteúdo no sistema existente é semelhante em taxa de bits, qualidade e, possivelmente, outras métricas à primeira camada no sistema aperfeiçoado e a segunda representação do conteúdo no sistema existente é 10 semelhante em taxa de bits, qualidade e, possivelmente, outras métricas à combinação das duas camadas no sistema avançado. Como resultado, a capacidade de armazenamento requerida dentro do sistema aperfeiçoado é reduzida comparada com a necessária no sistema existente. Além 15 disso, enquanto os clientes do sistema existente podem emitir solicitações de blocos de uma representação ou outra representação, os clientes do sistema aperfeiçoado podem emitir solicitações da primeira ou das duas camadas de um bloco. Como resultado, a experiência de usuário nos dois 20 sistemas é semelhante. Além disso, o cache melhorado é provido como até mesmo segmentos comuns de diferentes qualidades são usados os quais são armazenadas em cache com maior probabilidade.

Em uma segunda modalidade, um cliente em um 25 sistema de fluxo contínuo de solicitação de bloco aperfeiçoado empregando o método de camadas agora descrito pode manter um armazenador de dados separado para cada uma das várias camadas de codificação de mídia. Como será claro para aqueles que são versados na técnica de gerenciamento 30 de dados dentro de dispositivos de cliente, estes armazenadores "separado" podem ser implementados por atribuição de regiões de memória separadas físicas ou lógicas aos armazenadores separados ou por outras técnicas em que os dados são armazenados em buffer em simples ou múltiplas regiões de memória, e a separação dos dados a partir de diferentes camadas é conseguida logicamente através da utilização de estruturas de dados que contêm as referências aos locais de armazenamento de dados das camadas separadas e assim no seguinte termo "armazenadores separados" deve ser entendido incluir qualquer método em que os dados das camadas distintas podem ser identificados separadamente. O cliente emite solicitações para as camadas individuais de cada bloco com base na ocupação de cada armazenador, por exemplo, as camadas podem ser ordenadas em uma ordem de prioridade de tal modo que uma solicitação de dados de uma camada não pode ser emitida se a ocupação de qualquer armazenador para uma camada inferior na ordem de prioridade está abaixo de um limite para aquela camada inferior. Neste método, é dada prioridade para receber dados das camadas inferiores da ordem de prioridade de tal modo que se a largura de banda disponivel cai abaixo do necessário para receber também as camadas superiores, na ordem de prioridade, então apenas as camadas inferiores são solicitadas. Além disso, os limites associados com as diferentes camadas podem ser diferentes, de tal modo que, por exemplo, as camadas inferiores têm limites elevados. No caso em que mudanças de largura de banda disponíveis tal que os dados para uma camada superior não podem ser recebidos antes do tempo de reprodução do bloco, então os dados para as camadas inferiores serão necessariamente já recebidos e assim a apresentação pode continuar com as camadas inferiores sozinhas. Limites para ocupação de armazenador podem ser definidos em termos de bytes de dados, duração de reprodução dos dados contidos no armazenador, número de blocos ou qualquer outra medida apropriada.

Em uma terceira modalidade, os métodos das primeira e segunda modalidades podem ser combinados de tal forma que são providas múltiplas representações de midia cada uma compreendendo um subconjunto das camadas (como na 5 primeira modalidade) e tal que a segunda modalidade é aplicada a um subconjunto das camadas dentro de uma representação.

Em uma quarta modalidade dos métodos das primeira, segunda e/ou terceira modalidades podem ser 10 combinados com a modalidade em que múltiplas representações independentes do conteúdo de tal são providas tal que, por exemplo, pelo menos uma das representações independentes compreende múltiplas camadas as quais as técnicas das primeira, segunda e/ou terceira modalidades são aplicadas. 15 Gerenciador de Armazenador Avançado

Em combinação com monitor de armazenador 126 (ver figura 2), um gerenciador de armazenador avançado pode ser usado para otimizar um armazenador do lado do cliente. Sistemas de fluxo continuo de solicitação de bloco querem 20 garantir que reprodução de midia pode começar rapidamente e continuar sem problemas, oferecendo, simultaneamente, a qualidade da midia máxima para o usuário ou o dispositivo de destino. Isso pode exigir que o cliente solicite blocos que têm maior qualidade de midia, mas que também podem ser 25 iniciados rapidamente e recebidos em tempo posterior a ser reproduzido sem forçar uma pausa na apresentação.

Em modalidades que utilizam o gerenciador de armazenador avançado, o gerenciador determina quais blocos de dados de midia solicitar e quando fazer essas 30 solicitações. Um gerenciador de armazenador avançado poderia, por exemplo, dispor de um conjunto de metadados para o conteúdo a ser apresentado, estes metadados, incluindo uma lista de representações disponíveis para o conteúdo e metadados para cada representação. Metadados para uma representação podem incluir informações sobre a taxa de dados da representação e outros parâmetros, tais como video, áudio ou outros codecs e parâmetros de codec, 5 resolução de video, complexidade de decodificação de áudio, linguagem e quaisquer outros parâmetros que podem afetar a escolha da representação no cliente.

Metadados para uma representação pode também compreender identificadores para os blocos nos quais a 10 representação foi segmentada, estes identificadores provendo as informações necessárias para o cliente solicitar um bloco. Por exemplo, onde o protocolo de solicitação é HTTP, o identificador pode ser um URL de HTTP eventualmente em conjunto com a informação adicional 15 identificando um intervalo de bytes ou intervalo de tempo dentro do arquivo identificado pelo URL, este intervalo de bytes ou periodo de tempo que identifica o bloco especifico dentro do arquivo identificado pela URL.

Em uma implementação especifica, o gerenciador de 20 armazenador avançado determina quando um receptor faz uma solicitação de novos blocos e pode ele próprio gerenciar o envio das solicitações. Em um aspecto novo, o gerenciador de armazenador avançado faz solicitações de novos blocos de acordo com o valor de uma relação de uma razão de 25 equilíbrio que equilibra entre usar muita largura de banda e executar a mídia durante um reprodução de fluxo contínuo.

As informações recebidas pelo monitor de armazenador 126 a partir do bloco de armazenador 125 podem incluir indicações de cada caso quando os dados de mídia 30 são recebidos, quanto foi recebido, quando reprodução de dados de mídia foi iniciada ou interrompida, e a velocidade de reprodução de mídia. Com base nesta informação, o monitor de armazenador 126 pode calcular uma variável que representa um tamanho do armazenador atual, BatUai« Nestes exemplos, Batuai representa a quantidade de material contido em um cliente ou outro armazenador ou armazenadores de dispositivo e pode ser medido em unidades de tempo de modo que Batuai representa a quantidade de tempo que levaria para reprodução de toda a midia representada pelos blocos ou blocos parciais armazenados no armazenador ou armazenadores se nenhum bloco adicional ou blocos parciais foram recebidos. Assim, Batuai representa a "duração de reprodução", a uma velocidade de reprodução normal, dos dados de midia disponíveis no cliente, mas ainda não reproduzidos.

Conforme o tempo passa, o valor de BatUai irá diminuir conforme a midia é reproduzida e pode aumentar a cada vez que novos dados de um bloco são recebidos. Note-se que, para os fins desta explicação, é assumido que um bloco é recebido quando a totalidade dos dados daquele bloco está disponivel no solicitador de bloco 124, mas outras medidas podem ser usadas .em vez disso, por exemplo, ter em conta a recepção de blocos parciais. Na prática, a recepção de um bloco pode ocorrer ao longo de um periodo de tempo. A figura 13 ilustra uma variação do valor de Batuai ao longo do tempo, conforme midia é reproduzida e blocos são recebidos. Como mostrado na figura 13, o valor de Batuai é zero para tempos menores do que t0, indicando que não há dados recebidos. Em t0, o primeiro bloco é recebido e o valor de Batuai aumenta para igualar a duração de reprodução do bloco recebido. Neste momento, reprodução ainda não começou e assim o valor de BatUai permanece constante, até o tempo tl, em que um segundo bloco chega e aumenta Batuai por o tamanho deste segundo bloco. Neste momento, reprodução começa e o valor de Batuai começa a diminuir de forma linear, até ao tempo t2, momento em que um terceiro bloco chega.

A progressão da BatUai continua nesta maneira "dente de serra", aumentando gradualmente cada vez que um bloco é recebido (às vezes t2, t3, t4, T5 e T6) e diminuindo suavemente conforme os dados são reproduzidos no meio. Note-se que, neste exemplo, a reprodução prossegue à taxa de reprodução normal para o conteúdo e assim, o declive da curva entre a recepção do bloco é exatamente -1, significando que um segundo da dados de midia é reproduzido para cada um segundo de tempo real que passa. Com reprodução de midia baseada em quadro em um determinado número de quadros por segundo, por exemplo, 24 quadros por segundo, o declive de -1 irá ser aproximado por funções pequenas de etapa que indicam a reprodução de cada quadro individual de dados, por exemplo, etapas de -1/24 de um segundo quando cada quadro é reproduzido. A figura 14 mostra outro exemplo da evolução de Batuai ao longo- do tempo. Nesse exemplo, o primeiro bloco chega a t0 e reprodução começa imediatamente. O bloco chega e a reprodução continua até o tempo t3, em que o valor de Batuai chega a zero. Quando isso acontece, não há dados de midia adicionais disponíveis para reprodução, forçando uma pausa na apresentação de midia. No tempo t4, um quarto bloco é recebido e pode retomar a reprodução. Este exemplo indica, portanto, um caso em que a recepção do quarto bloco foi mais tarde do que desejado, resultando em uma pausa na reprodução e, assim, uma experiência de usuário ruim. Assim, um objetivo do gerenciador de armazenador avançado e outras características é reduzir a probabilidade deste evento e, simultaneamente, manter a qualidade de midia alta.

Monitor de armazenador 126 também pode calcular outra métrica, Brazâo(t), que é a razão entre a midia recebida em um determinado periodo de tempo para a duração do periodo de tempo. Mais especificamente, Brazão(t) é igual a Trecebido (Tagora - 1), onde TreCebido é a quantidade de midia (medida por seu tempo de reprodução) recebida no periodo de tempo a partir de t, algum tempo antes do tempo atual até o tempo atual, TagOra- Brazão(t) pode ser usado para medir a taxa de variação de BatUai- • BraZão(t) = 0 é o caso em que nenhum dado foi recebido desde o tempo t; Batuai irá ser reduzida por {Tagora - t) desde aquela tempo, assumindo que midia está reproduzindo. Brazâo(t) = 1 é o caso em que a midia é recebida na mesma quantidade que está sendo reproduzida, para o tempo (Tagora - 1) ; Batuai terá o mesmo valor em tempo Tagora como no tempo t. Brazao(t)> 1 é o caso em que mais dados foram recebidos do que o necessário para reproduzir para o tempo (Tagora- 1); Batuai irá ter aumentado de tempo t para tempo Tagora.

O monitor de armazenador 126 adicionalmente calcula valor State, cujo valor pode assumir um número discreto de valores. O monitor de armazenador 126 está ainda equipado com uma função, NewState (Batuai, Brazâo) , que, dado o valor atual de Batuai e valores de Brazao para t < Tagora, provê um novo valor State como saida. Sempre que Batuai θ Brazão fizerem esta função retornar a um valor diferente do valor atual de State, o novo valor é atribuido ao Statee este valor novo State indicado para o seletor de bloco 123.

Uma função NewState pode ser avaliada com referência ao espaço de todos os valores possiveis do par (Batuai, Brazã0 {Tagora - Tx) ) onde Tx poderá ser um valor fixo (configurado) , ou pode ser derivado de Batuai, por exemplo por uma tabela de configuração que mapeia a partir de valores de Batuai para valores de Tx, ou pode depender do valor anterior do State. Monitor de armazenador 126 é provido com uma ou mais divisões deste espaço, onde cada partição compreende conjuntos de regiões disjuntas, cada região sendo anotada com um valor do State. Avaliação da função NewState, então compreende a operação de identificação de uma separação e determinação da região em que o par (Batuai, Brazâo (Tagora - Tx) ) cai. O valor de retorno é, então, a anotação associada com essa região. Em um caso simples, apenas um particionamento é provido. Em um processo mais complexo, o particionamento pode depender do par (Batuai, Brazao {Tagora - Tx) ) no momento anterior de avaliação da função NewState ou de outros fatores.

Em uma modalidade especifica, o particionamento descrito acima, pode ser com base em uma tabela de configuração contendo um número de valores limites para Batuai e um número de valores limites para Brazão. Especificamente, deixar os valores limites para BatUai serem Biimit (0) = 0, Biimit(nl), Biimit (nl+1) = 00 é o número de valores limites diferentes de zero para BatUai- Deixar os valores limites para Brazâo serem Br_limit(0) = 0, Br_iimite(1) , Br-limite (N2) , Br-iirnite (N2 + 1) = °°, onde n2 é o número de valores limites para Brazao. Esses valores limites definem um particionamento compreendendo uma grade de células (n+1) por (n2 + 1), onde a i-ésima célula da j-ésima linha corresponde à região em que Biimite (i ~ 1) <= Batuai <Bnmit(i) e Br-iimit (j ~ Brazão <Br-iimit (j ) • Cada célula da grade descrita acima é anotada com um valor de State, tal como por estar associada a determinados valores armazenados na memória, e a função NewState retorna o valor de estado associado à célula indicada pelos valores BatUai e Brazao (Tagora ~ Tx) .

Em uma outra modalidade, um valor de histerese pode estar associado a cada valor limite. Neste método melhorado, a avaliação da função NewState pode ser baseada em um compartilhamento temporário construído usando um conjunto de valores limites temporariamente modificados, como se segue. Para cada valor limite BatUai que é menor que o intervalo Batual correspondente à célula escolhida sobre a última avaliação de NewState, o valor limite é reduzido pela subtração do valor de histerese associado com esse limite. Para cada valor limite BatUai que é maior do que o intervalo BatUai correspondente à célula escolhida sobre a última avaliação de NewState, o valor limite é aumentado pela adição do valor da histerese associado com esse limite. Para cada valor limite Brazâo que é menor que o intervalo Brazão correspondente à célula escolhida sobre a última avaliação de NewState, o valor limite é reduzido pela subtração do valor de histerese associado com esse limite. Para cada valor limite Brazã0 que é maior do que o intervalo Brazão correspondente à célula escolhida na última avaliação de NewState, o valor limite é aumentado pela adição do valor da histerese associado com esse limite. Os valores limites modificados são utilizados para avaliar o valor de NewState e, então os valores limites são retornados para os valores originais.

Outras formas de definir particionamento do espaço será óbvia para aqueles que são versados na técnica após a leitura desta descrição. Por exemplo, um particionamento pode ser definido pela utilização de desigualdades com base em combinações lineares de Brazâo θ Batuai, PQr exemplo, limites lineares de desigualdade da forma al • Braza0 + «2 • BatUai «0 para otOde valor real otl, e α2, para definir meios-espaços dentro do espaço total e definindo cada reprodução disjunta como a intersecção de um número de tais meios espaços.

A descrição acima é ilustrativa do processo 5 básico. Como será claro para os versados na técnica da programação de tempo real após a leitura desta descrição, implementações eficientes são possiveis. Por exemplo, cada vez que nova informação é provida para monitor de armazenador 126, é possivel calcular o tempo futuro em que 10 NewState irá transitar para um novo valor se, por exemplo nenhum dados adicional para os blocos é recebido. Um temporizador é então ajustado para este tempo e na ausência de outras entradas de validade este temporizador irá fazer com que o novo valor de State seja enviado para o seletor 15 de bloco 123. Como resultado, os cálculos só necessitam de serem realizados quando a nova informação é provida para o monitor de armazenador 126 ou quando um temporizador expira, em vez de continuamente.

Os valores adequados de State- poderiamser 20 "Baixo", "estável" e "Cheio". Um exemplo de um conjunto adequado de valores limites e na grade de célula resultante é mostrado na figura 15. Na figura 15, os limites de BatUai são mostrados no eixo horizontal em milissegundos, com valores de 25 histerese mostrados abaixo como "+ /-valor". Limites Brazão são mostrados no eixo vertical em permille (isto é, multiplicado por 1000) com valores de histerese mostrados abaixo como "+ /-valor". Valores de State são anotados nas células da grade como "L", "S" e "F" para "Baixo", "Estável" e "Cheio", respectivamente.

Seletor de bloco 123 recebe notificações do solicitador de bloco 124 sempre que houver uma oportunidade de solicitar um novo bloco. Como descrito acima, o seletor de bloco 123 é provido com os dados assim como a pluralidade de blocos disponíveis e metadados para esses blocos, incluindo por exemplo, informações sobre a taxa de dados de midia de cada bloco.

Informação sobre a taxa de dados de midia de um bloco pode compreender a real taxa de dados de midia do bloco especifico (isto é, o tamanho do bloco em bytes dividido pelo tempo de reprodução em segundos), a média taxa de dados de midia da representação à qual o bloco 10 pertence ou uma medida da largura de banda disponível necessária, em uma base sustentável, para reproduzir a representação a qual o bloco pertence sem pausas, ou uma combinação dos anteriores. Seletor de bloco 123 seleciona blocos com base no último valor State indicado pelo monitor de seletor 126. Quando este valor de State é "estável", o seletor de bloco 123 seleciona um bloco da mesma representação que o bloco anterior selecionado. O bloco selecionado é o primeiro bloco (em ordem de reprodução) contendo dados de midia por 20 um periodo de tempo na apresentação para a qual nenhum dado de midia foi previamente requerido.

Quando o valor de State é "Baixo", seletor de bloco 123 seleciona um bloco a partir de uma representação com uma menor taxa de dados de midia do que o bloco 25 selecionado anteriormente. Uma série de fatores pode influenciar a escolha exata da representação no presente caso. Por exemplo, o seletor de bloco 123 pode ser provido com uma indicação da taxa total de dados de entrada e pode escolher uma representação com uma taxa de dados de midia 30 que é inferior a esse valor.

Quando o valor de State é "Cheio", o seletor de bloco 123 seleciona um bloco a partir de uma representação com uma maior taxa de dados de midia do que o bloco selecionado anteriormente. Uma série de fatores pode influenciar a escolha exata da representação no presente caso. Por exemplo, o seletor de bloco 123 pode ser provido com uma indicação da taxa total de dados de entrada e pode 5 escolher uma representação com uma taxa de dados de midia que não é maior do que aquele valor.

Uma série de fatores adicionais podem ainda influenciar o funcionamento do seletor de bloco 123. Em particular, a frequência com que a taxa de dados de midia 10 do bloco selecionado é aumentada pode ser limitada, mesmo se monitor de armazenador 126 continuar a indicar o estado "Cheio". Além disso, é possivel que o seletor de bloco 123 receba uma indicação de estado "Cheio", mas não existem blocos de maior taxa de dados de midia disponíveis (por 15 exemplo, devido ao fato de o último bloco selecionado já estar disponível para a mais alta taxa de dados de midia). Neste caso, o seletor de bloco 123 pode atrasar a seleção do bloco seguinte por um tempo escolhido de tal modo que a quantidade total de dados de midia armazenados em buffer no 20 armazenador de bloco 125 é delimitada acima.

Outros fatores podem influenciar o conjunto de blocos que são considerados durante o processo de seleção. Por exemplo, os blocos disponíveis podem ser limitados àqueles a partir de representações cuja resolução de 25 codificação cai dentro de uma faixa especifica provida para o seletor de bloco 123.

O seletor de bloco 123 também pode receber contribuições de outros componentes que monitoram os outros aspectos do sistema, tais como a disponibilidade de 30 recursos computacionais para a decodificação de midia. Se tais recursos se tornam escassos, seletor de bloco 123 pode escolher blocos cuja decodificação é indicada para ser de menor complexidade computacional dentro de metadados (por exemplo, as representações com menor resolução ou taxa de quadros são geralmente de menor complexidade de decodificação).

A modalidade acima descrita traz uma vantagem 5 substancial em que a utilização do valor Brazâo na avaliação da função NewState dentro do monitor de armazenador 126 permite um aumento mais rápido na qualidade no inicio da apresentação em comparação com um método que considera só Batuai- Sem considerar Brazao, uma grande quantidade de dados 10 em armazenador pode ser acumulada antes que o sistema seja capaz de selecionar blocos com maior taxa de dados de midia e, consequentemente, uma maior qualidade. No entanto, quando o valor Brazã0 é grande, isto indica que a largura de banda disponivel é muito mais elevada do que a taxa de 15 dados de midia dos blocos recebida previamente e que, mesmo com relativamente poucos dados armazenados (isto é, baixo valor para BatUai) r ele continua a ser seguro para solicitar blocos de taxa de dados de midia mais elevada e, portanto, a qualidade mais elevada. Igualmente, se o valor Brazâ0 é 20 baixo (<1, por exemplo), isso indica que a largura de banda disponivel caiu abaixo da taxa de dados de midia dos blocos previamente solicitados e, assim, mesmo se Batuai é elevado, o sistema irá mudar para uma taxa de dados de midia mais baixa e, consequentemente, uma menor qualidade, por exemplo, para evitar atingir o ponto onde Batuai = 0 e a reprodução das pausas de midia. Esse comportamento melhorado pode ser especialmente importante em ambientes onde as condições da rede e, assim, velocidades de entrega podem variar de forma rápida e dinâmica, por exemplo, 30 usuários de fluxo continuo para dispositivos móveis.

Outra vantagem é conferida pelo uso de dados de configuração para especificar o particionamento do espaço de valores de (Batuai, Brazâ0) . Tais dados de configuração podem ser providos para o monitor de armazenador 126 como parte dos metadados de apresentação ou por outros meios dinâmicos. Uma vez que, em implementações práticas, o comportamento de conexões de rede do usuário pode ser 5 altamente variável entre os usuários e ao longo do tempo para um único usuário, pode ser dificil prever particionamentos que irão funcionar bem para todos os usuários. A possibilidade de prover informações de configuração permite aos usuários de forma dinâmica 10 configurações boas a serem desenvolvidas ao longo do tempo de acordo com a experiência acumulada.

Dimensionamento de Solicitação Variável A alta frequência de solicitações pode ser necessária se cada solicitação é para um único bloco e se 15 cada bloco codifica para um segmento de midia curto. Se os blocos de midia são curtos, a reprodução de video está se movendo de bloco em bloco rapidamente, o que provê oportunidades mais frequentes para o receptor de ajustar ou alterar sua taxa de dados selecionada, alterando a 20 representação, melhorando a probabilidade daquela reprodução pode continuar sem parar. No entanto, uma desvantagem para uma alta frequência de solicitações é que elas podem não ser sustentáveis em determinadas redes em que a largura de banda disponivel é limitada no cliente 25 para servidor de rede, por exemplo, em redes sem fio WAN, tais como WANs sem fio 3G e 4G, onde a capacidade da conexão de dados do cliente para a rede é limitada ou pode tornar-se limitada por periodos longos ou curtos de tempo devido a alterações nas condições de rádio.

Uma frequência elevada de solicitações também implica uma elevada carga sobre a infraestrutura de serviço, o que traz custos associados em termos de requisitos de capacidade. Assim, seria desejável ter alguns dos benefícios de uma frequência elevada de solicitações sem todas as desvantagens.

Em algumas modalidades de um sistema de fluxo contínuo de bloco, a flexibilidade da elevada frequência e solicitação é combinada com as solicitações menos frequentes. Nesta modalidade, os blocos podem ser construídos como descrito acima e agregados em segmentos que contêm blocos múltiplos, também como descrito acima. No início da apresentação, os processos descritos acima no qual cada solicitação faz referência a um único bloco ou múltiplas solicitações simultâneas são feitas para solicitar partes de um bloco são aplicadas para assegurar um tempo de zapping de canal rápido e, por conseguinte, uma boa experiência de usuário no início da apresentação. Posteriormente, quando uma determinada condição, a ser descrita abaixo, for atendida, o cliente pode emitir solicitações, que abrangem vários blocos em uma única solicitação. Isto é possível porque os blocos foram agregados em arquivos maiores ou segmentos e podem ser solicitados usando intervalos de bytes ou de tempo. Intervalos consecutivos de bytes ou tempo podem ser agregados em um único intervalo de bytes ou tempo maior, resultando em uma solicitação única para vários blocos, e até mesmo blocos descontínuos podem ser solicitados em uma solicitação.

Uma configuração básica que pode ser impulsionada pela decisão de solicitar um bloco único (ou um bloco parcial) ou para solicitar vários blocos consecutivos é ter a base de configuração a decisão sobre se ou não os blocos solicitados são susceptíveis de ser reproduzidos ou não. Por exemplo, se é provável que não haverá a necessidade de mudar para uma outra representação em breve, então é melhor para o cliente fazer solicitações dê blocos individuais, isto é, pequenas quantidades de dados de midia. Uma razão para isto é que, se uma solicitação de blocos múltiplos é feita quando um comutador para uma outra representação pode ser iminente é que o interruptor pode ser feito antes dos últimos poucos blocos da solicitação ser reproduzida. Assim, o download desses últimos blocos pode atrasar a entrega de dados de midia da representação a que a troca é feita, o que poderia causar pausas de reprodução midia.

No entanto, as solicitações de simples blocos resultam em uma maior frequência de solicitações. Por outro lado, se é improvável que haverá uma necessidade de mudar para uma outra representação em breve, então pode ser preferido fazer solicitações de blocos múltiplos, como todos estes blocos são susceptíveis de ser reproduzidos, e isto resulta em uma menor frequência de solicitações, o que pode reduzir substancialmente a overhead de solicitação, especialmente se é típico que não haja alteração na representação iminente.

Em sistemas convencionais de agregação de blocos, a quantidade solicitada em cada solicitação não é ajustada dinamicamente, ou seja, tipicamente cada solicitação é para um arquivo inteiro, ou cada solicitação tem aproximadamente a mesma quantidade de arquivo de uma representação (por vezes medida em tempo, por vezes em bytes). Assim, se todas as solicitações são menores, então a overhead de solicitação é elevado, ao passo que se todos as solicitações são maiores, então isso aumenta as chances de eventos da pausa de mídia e/ou provimento de um serviço de qualidade da reprodução de mídia se as representações de baixa qualidade são escolhidas para evitar ter que mudar rapidamente representações conforme as condições da rede variam.

Um exemplo de uma condição que, quando cumprida, pode causar solicitações subsequentes para fazer referência a vários blocos, é um limite no tamanho do armazenador, Batuai- Se Batuai está abaixo do limite, então cada solicitação emitida faz referencia a um único bloco. Se Batuai é maior do que ou igual ao limite, então cada solicitação emitida faz referencia a blocos múltiplos. Se uma solicitação for emitida que faz referencia a múltiplos blocos, então o número de blocos solicitados em cada solicitação única pode ser determinado de uma das várias maneiras possíveis. Por exemplo, o número pode ser constante, por exemplo, dois. Alternativamente, o número de blocos solicitados em uma única solicitação pode ser dependente do estado de armazenamento e em particular em Batuai. Por exemplo, um número de limites pode ser ajustado, com o número de blocos solicitados em uma única solicitação sendo derivada dos maiores limites múltiplos que são menores do que BatUai-

Outro exemplo de uma condição que, quando cumprida, pode causar solicitações para fazer referência a vários blocos, é a variável State de valor acima descrito. Por exemplo, quando o State é "estável" ou "cheio", então as solicitações podem ser emitidas por vários blocos, mas, quando o State é "Baixo", então todas as solicitações podem ser para um bloco.

Outra modalidade é mostrada na figura 16. Nesta modalidade, quando a solicitação seguinte deve ser emitida (determinado na etapa 1300) , o valor de State atual e Batuai é usado para determinar o tamanho da solicitação seguinte. Se o valor de State atual é "baixo" ou o valor de State atual é "cheio" e a representação atual não é a mais alta disponivel (determinado na etapa 1310, a resposta é "Sim"), então a próxima solicitação é escolhida para ser curta, põr exemplo, apenas para o bloco seguinte (bloco determinado e solicitação feita na etapa 1320). A lógica por trás disto é que estas são as condições em que é provável que, muito breve, haverá uma mudança de representações. Se o valor de State atual é "estável" ou o valor de State atual é "cehio" e a representação atual é a mais alta disponivel (determinado na etapa 1310, a resposta é "Não"), então a duração dos blocos consecutivos solicitados na próxima solicitação é escolhida para ser proporcional a uma fração α de Batuai para algum a-1 fixo (blocos determinados na etapa 1330, solicitação feita na etapa 1340), por exemplo, por a = 0,4, se BatUai = 5 segundos, então a próxima solicitação pode ser de aproximadamente 2 segundos de blocos, enquanto que se BatUai = 10 segundos, então a próxima solicitação pode ser para cerca de 4 segundos de blocos. Uma razão para, isto é que, nestas condições, pode ser improvável que uma mudança para uma nova representação seja feita por uma quantidade de tempo que é proporcional à Batuai • Encadeamento Flexível

Sistemas de fluxo contínuo de bloco podem usar um protocolo de solicitação de arquivo que tem um protocolo de transporte específico subjacente, por exemplo, TCP / IP. No início de um TCP / IP ou outro protocolo de conexão de transporte, pode demorar um tempo considerável para alcançar a utilização da largura de banda total disponível. Isso pode resultar em uma "penalidade de inicialização de conexão" cada vez que uma nova conexão é iniciada. Por exemplo, no caso de TCP / IP, a penalidade de inicialização de conexão ocorre devido ao tempo que leva para o estabelecimento de uma ligação (handshake) de TCP inicial para estabelecer a conexão e o tempo que leva para o protocolo de controle de congestão para atingir a utilização total da largura de banda disponivel.

Neste caso, pode ser desejável emitir solicitações múltiplas, utilizando uma única conexão, a fim 5 de reduzir a frequência com que a penalidade de inicialização de conexão é constituída. No entanto, alguns protocolos de transporte de arquivos, por exemplo, HTTP, não proveem um mecanismo para cancelar uma solicitação, além de fechar a conexão da camada de transporte toda e, 10 assim, incorrem em uma penalidade de inicialização de conexão quando uma nova conexão é estabelecida no lugar da antiga. Uma solicitação emitida pode precisar de ser cancelada, se for determinado que a largura de banda disponivel mudou e uma diferente taxa de dados de midia é necessária em vez disso, ou seja, há uma decisão para mudar para uma representação diferente. Outra razão para o cancelamento de uma solicitação pode ser emitida se o usuário solicitou que a apresentação de midia seja encerrada e uma nova apresentação começou (talvez do mesmo 20 item de conteúdo em um ponto diferente na apresentação, ou talvez de um novo item de conteúdo).

Como é sabido, a penalidade de inicialização de conexão pode ser evitada, mantendo a conexão aberta e reutilizando a mesma conexão para solicitações subsequentes 25 e como também é conhecido a conexão pode ser mantida totalmente utilizada se várias solicitações são emitidas ao mesmo tempo sobre a mesma conexão (uma técnica conhecida como "encadeamento", no contexto de HTTP). No entanto, uma desvantagem de emissão de múltiplas solicitações, ao mesmo 30 tempo, ou, mais geralmente, de tal maneira que várias solicitações são emitidas antes de solicitações anteriores terem sido completadas através de uma conexão, pode ser que a conexão seja então comprometida a portar a resposta para estas solicitações e assim se mudanças as quais as solicitações devem ser emitidos se tornarem desejáveis, então a conexão pode ser fechada se torna necessário solicitações já emitidas que não são mais desejadas.

A probabilidade de que uma solicitação emitida precisa de ser cancelada pode ser, em parte, dependente da duração do intervalo de tempo entre a emissão da solicitação e o tempo de reprodução do bloco solicitado no sentido de que, quando este intervalo de tempo é elevado a probabilidade de que uma solicitação emitida precisa de ser cancelada é também elevada (porque é provável que a largura de banda disponivel mude durante o intervalo).

Como é sabido, alguns protocolos de download de arquivo têm a propriedade de que uma única conexão de camada de transporte subjacente pode ser vantajosamente utilizada para várias solicitações de downloads. Por exemplo, HTTP tem esta propriedade, uma vez que a reutilização de uma única conexão para múltiplas solicitações evita a "penalidade de inicialização de conexão" descrita acima para outras solicitações diferentes da primeira. No entanto, uma desvantagem dessa abordagem é que a conexão está comprometida a transportar os dados solicitados em cada solicitação emitida e, portanto, se uma solicitação ou solicitações tem de ser cancelada então a conexão pode ser fechada, incorrendo na penalidade de inicialização de conexão quando uma conexão de substituição é estabelecida, ou o cliente pode esperar para receber dados que não são mais necessários, incorrendo em um retardo na recepção de dados subsequentes.

Agora é descrita uma modalidade que retém as vantagens da reutilização da conexão sem incorrer esta desvantagem e que também adicionalmente aumenta a frequência com que asconexões podem ser reutilizadas.

As modalidades dos sistemas de fluxo continuo de bloco aqui descritas são configuradas para reutilizar uma conexão para várias solicitações sem ter que comprometer a conexão no inicio de um determinado conjunto de solicitações. Essencialmente, uma nova solicitação é emitida em uma conexão existente quando as solicitações já emitidas sobre a conexão ainda não foram completadas, mas estão em fase de conclusão. Uma razão para não esperar até que as solicitações existentes se tornem completas é que se as solicitações anteriores foram completadas, então a velocidade de conexão pode degradar, ou seja, a sessão de TCP subjacente poderia entrar em um estado ocioso, ou o TCP variável cwnd poderia ser substancialmente reduzido, assim substancialmente reduzindo a velocidade de download inicial da nova solicitação emitida nessa conexão. Uma razão para esperar até chegar próximo à conclusão antes de emitir uma solicitação adicional é porque se uma nova solicitação é emitida muito antes das solicitações anteriores estarem completadas, então a nova solicitação emitida não pode nem mesmo começar por algum periodo de tempo substancial, e isto poderia ser o caso em que durante este periodo de tempo antes que a nova solicitação emitida começa a decisão de fazer a nova solicitação não é mais válida, por exemplo, devido a uma decisão de mudar representações. Assim, incorporação de clientes que implementam esta técnica irá emitir uma nova solicitação em uma conexão mais tarde possivel sem abrandar as capacidades de download da conexão.

O método compreende monitorar o número de bytes recebidos de uma conexão, em resposta à última solicitação emitida nesta conexão e aplicar um teste para esse número. Isto pode ser feito fazendo com que o receptor (ou o transmissor, se aplicável) seja configurado para monitorar e testar.

Se o teste passar, então uma nova solicitação pode ser emitida na conexão. Um exemplo de um ensaio adequado é se o número de bytes recebidos é maior do que uma fração fixa do tamanho dos dados solicitados. Por exemplo, esta fração pode ser de 80%. Outro exemplo de um ensaio adequado baseia-se no seguinte cálculo, tal como ilustrado na figura 17. No cálculo, seja R uma estimativa da taxa de dados da conexão, T uma estimativa do tempo de Isa e volta ("RTT") e X seja o fator numérico que, por exemplo, poderia ser um conjunto de constantes para um valor entre 0,5 e 2, onde as estimativas de R e T são atualizadas em uma base regular (atualizada na etapa 1410). Seja S o tamanho dos dados requeridos na última solicitação, B é o número de bytes dos dados requeridos recebidos (calculados na etapa 1420).

Um teste adequado seria ter o receptor (ou o transmissor, se aplicável) executando uma rotina para avaliar a desigualdade (S-B) < X*R»T (testado na etapa 1430), e se "Sim", então tomar uma ação. Por exemplo, um teste poderia ser feito para ver se há outra solicitação pronta para ser emitida na conexão (testado na etapa 1440), e se "Sim", então emitir a solicitação para a conexão (etapa 1450) e se "Não" então o processo retorna para a etapa 1410 para continuar a atualização e teste. Se o resultado do teste na etapa 1430 é "Não" então o processo retorna para a etapa 1410 para continuar a atualização e teste.

O teste de desigualdade na etapa 1430 (realizado por elementos adequadamente programados, por exemplo) faz com que cada solicitação subsequente seja emitida quando a quantidade de dados restantesaser recebida é igual X vezes a quantidade de dados que pode ser recebida na taxa de recepção estimada atual dentro de um RTT. Um certo número de métodos para estimar a taxa de dados, R, na etapa 1410 é conhecido na técnica. Por exemplo, a taxa de dados pode ser estimada como Dt/t, onde Dt é o número de bits recebidos nos t segundos precedentes e onde t pode ser, por exemplo, ls ou 0,5s ou algum outro intervalo. Outro método é uma média ponderada exponencial, ou filtro de Resposta ao Impulso Infinito de primeira ordem (IIR) da taxa de dados entrante. Vários métodos para estimar o RTT, T, na etapa 1410 são conhecidos na técnica.

O teste na etapa 1430 pode ser aplicado para o agregado de todas as conexões ativas sobre uma interface, como explicado em mais detalhe abaixo.

O método adicionalmente compreende a construção de uma lista de solicitações candidatas, associando cada solicitação candidata com um conjunto de servidores adequados para que a solicitação possa ser feita e ordenando a lista de solicitações candidatas em ordem de prioridade. Algumas entradas na lista de solicitações candidatas podem ter a mesma prioridade. Servidores na lista de servidores adequados associados a cada solicitação candidata são identificados por nomes de hospedeiro. Cada nome de hospedeiro corresponde a um conjunto de endereços de Protocolo Internet que pode ser obtido a partir do Sistema de Nome do Dominio como é bem conhecido. Por conseguinte, cada possivel solicitação na lista de solicitações candidatas está associada com um conjunto de endereços de Protocolo Internet, especificamente a união dos conjuntos de endereços de Protocolo Internet associados com os nomes de hospedeiro associados com os servidores associados com a solicitação candidata. Sempre que o teste descrito na etapa 1430 éatendido para uma conexão, £ nenhuma nova solicitação ainda não tiver sido emitida nessa conexão, a solicitação de prioridade nas listas de solicitações candidatas com as quais o endereço do Protocolo Internet do destino da conexão está associado é escolhida, e esta solicitação é emitida na conexão. A solicitação também é removida da lista de solicitações candidatas.

Solicitações candidatas podem ser removidas (canceladas) da lista de solicitações candidatas, novas solicitações podem ser adicionadas à lista de candidatos com uma prioridade maior do que solicitações já existentes na lista de candidatos, e as solicitações existentes na lista de candidatos podem ter a sua prioridade alterada. A natureza dinâmica da qual as solicitações estão na lista de solicitações candidatas, e a natureza dinâmica da sua prioridade na lista de candidatos, que podem alterar as solicitações podem ser emitidas próximas dependendo de quando um teste do tipo descrito na etapa 1430 é satisfeito.

Por exemplo, poderia ser possivel que, se a resposta ao teste descrito na etapa 1430 é "Sim" em algum tempo t, então a próxima solicitação emitida seria uma solicitação A, enquanto que se a resposta ao teste descrito na etapa 1430 não é "Sim" até algum tempo t'>t, então a próxima solicitação emitida passaria a ser uma solicitação B, porque ou a solicitação A foi retirada da lista de solicitações candidatas entre tempo t e t' , ou porque a solicitação B foi adicionada à lista de solicitações candidatas com maior prioridade do que uma solicitação de tempo e entre t e t' , ou porque a solicitação B estava na lista de candidatos no tempo t, mas com menor prioridade do que a solicitação A, e entre o tempo t e t' a prioridade da solicitação B foi tornada maior do que a da solicitação A. A figura 18 ilustra um exemplo de uma lista de solicitações na lista de candidatos de solicitações. Neste exemplo, existem três conexões, e há seis solicitações na lista de candidatos, identificados como A, B, C, D, E e F. Cada uma das solicitações na lista de candidatos pode ser emitida com um subconjunto das conexões como indicado, a solicitação A, por exemplo, pode ser emitida na conexão 1, enquanto a solicitação F pode ser emitida na conexão 2 ou conexão 3. A prioridade de cada solicitação está também marcada na figura 18, e um valor de prioridade mais baixo indica que uma solicitação tem maior prioridade. Assim, as solicitações A e B com 0 prioridades são as solicitações de maior prioridade, enquanto a solicitação F com um valor de prioridade 3 é a prioridade mais baixa entre as solicitações na lista de candidatos.

Se, neste momento no tempo t, conexão 1 passa no teste descrito na etapa 1430, então nem a solicitação A nem a solicitação B é emitida na conexão 1. Se em vez disso, a conexão 3 passa no teste descrito na etapa 1430 neste tempo t, então solicitação D é emitida na conexão 3, uma vez que a solicitação D é a solicitação com a maior prioridade que pode ser emitida na conexão 3.

Suponha que, para todas as conexões a resposta ao ensaio descrito na etapa 1430 do tempo t para algum tempo depois t' é "Não", e entre o tempo t e t' a solicitação A muda sua prioridade de 0 para 5, a solicitação B é removida da lista de candidatos, e uma nova solicitação G com prioridade 0 é adicionada à lista de candidatos. Então, no tempo t', a nova lista de candidato pode ser como mostrada na figura 19.

Se no tempo t' a conexão 1 passa no teste descrito na etapa 1430, então solicitação C com prioridade 4 é emitida na conexão 1^ pois ela é ã solicr Lação de- prioridade na lista de candidatos que pode ser emitida na conexão 1, neste ponto no tempo.

Suponha na mesma situação que em vez da solicitação A ter sido emitida na conexão 1 no tempo t (que 5 era uma das duas escolhas de mais alta prioridade para conexão 1 no tempo t, como mostrado na figura 18) . Como a resposta ao teste descrito na etapa 1430 do tempo t para algum tempo depois t' é "não" para todas as conexões, conexão 1 está ainda entregando os dados, até, pelo menos, 10 o tempo t' para as solicitações emitidas antes de tempo t, e, assim, a solicitação A não teria iniciado até, pelo menos, o tempo t'. Emitir a solicitação C no tempo t' é uma decisão melhor do que emitir a solicitação A no tempo t teria sido, uma vez que a solicitação C começa ao mesmo 15 tempo depois de t' como a solicitação A teria iniciado, e uma vez que a solicitação C é de maior prioridade que a solicitação A.

Como outra alternativa, se o teste do tipo descrito na etapa 1430 é aplicado ao agregado das conexões 20 ativas uma conexão pode ser escolhida a qual tem um destino cujo endereço de Protocolo Internet está associado com a primeira solicitação na lista de solicitações candidatas ou outra solicitação com a mesma prioridade que a primeira solicitação.

Vários métodos são possiveis para a construção da lista de solicitações candidatas. Por exemplo, a lista de candidatos pode conter n solicitações representando solicitações para uma próxima n porções de dados da representação atual da apresentação, em ordem de sequência 30 temporal, quando a solicitação para a primeira parte dos dados tem maior prioridade e a solicitação para a última parte de dados tem menor prioridade. Em alguns casos n pode ser um. 0 valor de n pode depender dõ tamanho der armazenador Batuai, ou a variável State ou outra medida do estado da ocupação do armazenador cliente. Por exemplo, um número de valores limites pode ser ajustado para Batuai θ um valor associado a cada limite e, então o valor de n é considerado como sendo o valor associado com o maior limite que é menor do que BatUai-

A modalidade descrita acima garante alocação flexivel das solicitações de conexões, garantindo que a preferência seja dada para a reutilização de uma conexão existente, mesmo se a solicitação de prioridade não fosse adequada para essa conexão (porque o endereço IP de destino da conexão não é aquele que é atribuido a qualquer um dos nomes de hospedeiro associados com a solicitação). A dependência de n em Batuai ou State ou outra medida da ocupação do armazenador cliente garante que tais solicitações "fora da ordem de prioridade", não sejam emitidas quando o cliente tem necessidade urgente de emissão e conclusão da solicitação associada à próxima porção de dados para ser resproduzida na sequência do tempo. Estes métodos podem ser vantajosamente combinados com HTTP cooperativo e FEC.

Seleção de Servidor Consistente Como é sabido, os arquivos a serem baixados usando um protocolo de download de arquivos são normalmente identificados por um identificador que compreende um nome de hospedeiro e um nome de arquivo. Por exemplo, este é o caso para o protocolo HTTP, caso em que o identificador é um identificador de recursos uniforme (URI) . Um nome de hospedeiro pode corresponder a vários hopedeiros identificados por endereços de Protocolo Internet. Por exemplo, este é um método comum de propagação da carga de solicitações de vários clientes em várias máquinas—físicas.

Em particular, esta abordagem é normalmente tomada por Redes de Entrega de Conteúdo (CDN). Neste caso, uma solicitação emitida em conexão com qualquer um dos hospedeiros fisicos deverá ter sucesso. Um certo número de 5 métodos são conhecidos através dos quais um cliente pode selecionar dentre os endereços de Protocolo Internet associados com um hospedeiro. Por exemplo, esses endereços são normalmente providos para o cliente através do Sistema de Nomes de Dominio e são providos em ordem de prioridade.

Um cliente pode então escolher a mais alta prioridade (primeiro) de endereços do protocolo Internet. No entanto, geralmente não há coordenação entre os clientes sobre a forma como de esta escolha é feita, com o resultado de que diferentes clientes podem solicitar o mesmo arquivo de 15 diferentes servidores. Isso pode resultar no mesmo arquivo sendo armazenado no cache de vários servidores vizinhos, o que reduz a eficiência da infraestrutura de cache.

Isto pode ser tratado por um sistema que vantajosamente aumenta a probabilidade de que dois clientes 20 solicitando o mesmo bloco irão solicitar este bloco a partir do mesmo servidor. 0 novo método aqui descrito compreende a seleção dentre os Endereços de Protocolo Internet disponíveis de uma forma determinada pelo identificador do arquivo a ser solicitado e de tal forma 25 que os diferentes clientes apresentados com as mesmas escolhas ou similar de endereços Protocolo Internet e identificadores de arquivo irão fazer a mesma escolha.

Uma primeira modalidade do método é descrita com referência à figura 20. O primeiro cliente obtém um 30 conjunto de endereços de Protocolo Internet IPI, IP2, ..., IPN, como mostrado na etapa 1710. Se houver um arquivo que as solicitações devem ser emitidas para, tal como decidido na etapa 1720, então o clientedetermina qual endereço dê-

Protocolo Internet emitir solicitações para o arquivo, como determinado nas etapas 1730-1770. Dado um conjunto de endereços de protocolo de Internet e um identificador para um arquivo a ser solicitado o método compreende ordenar o 5 Protocolo Internet aborda de uma forma determinada pelo identificador de arquivo. Por exemplo, para cada endereço de Protocolo Internet um string de byte é construído compreendendo a concatenação do endereço de Protocolo Internet e o identificador de arquivo, como mostrado na 10 etapa 1730. Uma função hash é aplicada a este string de byte, como mostrado na etapa 1740, e os valores hash resultantes são dispostos de acordo com uma ordenação fixa, como mostrado na etapa 1750, por exemplo, aumentando o número de ordem, induzindo uma ordenação nos endereços de 15 Protocolo Internet. A mesma função hash pode ser utilizada por todos os clientes, garantindo assim que o mesmo resultado seja produzido pela função hash sobre uma dada entrada para todos os clientes. A função de hash pode ser configurada estaticamente para todos os clientes em um 20 conjunto de clientes, ou todos os clientes em um conjunto de cliente pode obter uma descrição parcial ou total da função hash quando os clientes obtêm a lista de endereços de Protocolo Internet, ou todos os clientes em um conjunto de cliente podem obter uma descrição parcial ou total da 25 função hash quando os clientes obtêm o identificador de arquivo, ou a função hash pode ser determinada por outros meios. O endereço de Protocolo Internet que é o primeiro nesta ordem é escolhido e este endereço é então usado para estabelecer uma conexão de solicitações e emissão para todo 30 ou partes do arquivo, como mostrado nas etapas 1760 e 1770.

O método acima pode ser aplicado quando uma nova conexão é estabelecida para solicitar um arquivo. Também pode ser aplicadoquando um número de conexões estabelecidas estão disponíveis e uma delas pode ser escolhida para emitir uma nova solicitação.

Além disso, quando uma conexão estabelecida está disponível e uma solicitação pode ser escolhida dentre um conjunto de solicitações candidatas com igual prioridade uma ordenação descrita nas solicitações candidatas é induzida, por exemplo, pelo mesmo método de valores de hash acima e a solicitação candidata que aparece em primeiro lugar nesta ordenação é escolhida. Os métodos podem ser combinados para selecionar tanto uma conexão quanto solicitação candidata dentre um conjunto de conexões e solicitações de prioridade iguais, mais uma vez computando um hash para cada combinação de conexão e solicitação, ordenando estes valores de hash de acordo com uma ordem fixa e escolhendo a combinação que ocorre em primeiro lugar na ordenação induzida sobre o conjunto de combinações de solicitações e conexões.

Este método tem a vantagem pela seguinte razão: uma abordagem típica tomada por uma infraestrutura de serviço de bloco como a mostrada na figura 1 (BSI 101) ou figura 2 (BSIs 101), e em uma abordagem particular, comumente tomada pelo CDN, é prover vários servidores proxy cache que recebem solicitações de cliente. Um servidor proxy cache não pode ser provido com o arquivo solicitado em uma determinada solicitação e, neste caso tais servidores tipicamente encaminham a solicitação para outro servidor, recebem a resposta do servidor que normalmente inclui o arquivo solicitado, e encaminham a resposta ao cliente. O servidor proxy cache pode também armazenar (cache) o arquivo solicitado para que ele possa responder imediata às solicitações subsequentes para o arquivo. A abordagem comum descrita acima tem a propriedade de que o conjunto de arquivos armazenados em um determinado servidor proxy cache é largamente determinado pelo conjunto de solicitações que o servidor proxy cache recebeu.

O método descrito acima tem a seguinte vantagem. Se todos os clientes em um conjunto de clientes são 5 providos para a mesma lista de endereços de Protocolo Internet, então estes clientes irão utilizar o mesmo endereço de Protocolo Internet para todas as solicitações emitidas para o mesmo arquivo. Se há duas diferentes listas de endereços de protocolo Internet e cada cliente é provido 10 com uma dessas duas listas, então os clientes irão utilizar no máximo dois endereços de protocolo Internet diferentes para todas as solicitações emitidas para o mesmo arquivo. Em geral, se as listas de endereços de Protocolo Internet providas aos clientes são semelhantes, então os clientes 15 usarão um pequeno conjunto de endereços de protocolo Internet provido para todas as solicitações emitidas para o mesmo arquivo. Como os clientes próximos tendem a ser providos com listas similares de endereços de protocolo Internet, é. provável que as próximas solicitações de 20 clientes que visem a um arquivo de apenas uma pequena parte dos servidores proxy cache disponíveis para esses clientes. Assim, haverá apenas uma pequena fração de servidores proxy cache que armazenem em cache os arquivos, que vantajosamente minimiza a quantidade de recursos de cache 25 usados para armazenar o arquivo.

De preferência, a função hash tem a propriedade de que uma fração muito pequena de diferentes entradas são mapeadas para a mesma saida, e que diferentes entradas são mapeadas para saidas essencialmente aleatórias, para 30 assegurar que, para um dado conjunto de endereços de Protocolo Internet, a proporção de arquivos para os quais um dado endereço dos endereços de Protocolo Internet está em primeiro lugar na listaclassificada produzida pela etapa 1750 é aproximadamente a mesma para todos os endereços de Protocolo Internet na lista. Por outro lado, é importante que a função hash seja deterministica, no sentido de que para uma dada entrada a saida da função hash é a mesma para todos os clientes.

Outra vantagem do método descrito acima é a seguinte. Suponha que todos os clientes em um conjunto de clientes são providos com a mesma lista de endereços de Protocolo Internet. Por causa das propriedades da função hash que acabaram de ser descritas, é provável que as solicitações de arquivos diferentes desses clientes sejam uniformemente distribuídas em todo o conjunto de endereços de Protocolo Internet, o que por sua vez significa que as solicitações serão distribuídas uniformemente pelos servidores de proxy cache. Assim, os recursos de cache usados para armazenar esses arquivos são distribuídos uniformemente entre os servidores de proxy cache, e as solicitações de arquivos são distribuídas uniformemente entre os servidores de proxy cache. Assim, o método provê tanto o equilíbrio de armazenamento quanto equilíbrio de carga em toda a infraestrutura de cache.

Um certo número de variações para a abordagem descrita acima são conhecidos dos versados na técnica e, em muitos casos essas variações retêm a propriedade de que o conjunto de arquivos armazenados em um proxy é determinado pelo menos em parte pelo conjunto de solicitações que o servidor de proxy cache recebeu. No caso comum em que um dado nome de hospedeiro resolve para múltiplos servidores de proxy cache fisicos, será comum que todos esses servidores, eventualmente, armazenem uma cópia de qualquer dado arquivo que é frequentemente solicitado. Esta duplicação pode ser indesejável, uma vez que os recursos de armazenamento dos servidores de proxy cache são limitados e, como resulto arquivos podem ser, na ocasião, removidos (expurgados) do cache. 0 novo método aqui descrito assegura que as solicitações de um arquivo de dados são dirigidas para os servidores de proxy cache de tal maneira que esta duplicação seja reduzida, reduzindo assim a necessidade de remover os arquivos do cache e aumentando assim a probabilidade de que qualquer dado arquivo esteja presente (isto é, não foi purgado de) na memória cache proxy.

Quando um arquivo está presente na memória cache proxy, a resposta enviada para o cliente é mais rápida, que tem a vantagem em reduzir a probabilidade de que o arquivo solicitado chegue tarde, o que pode resultar em uma pausa na reprodução de mídia e, portanto, uma má experiência de usuário. Além disso, quando um arquivo não estiver presente no cache do proxy a solicitação pode ser enviada para outro servidor, colocando carga adicional tanto na porção de infraestrutura quanto nas conexões de rede entre os servidores. Em muitos casos, o servidor ao qual a solicitação é enviada pode estar em um local distante e transmissão do arquivo a partir deste servidor para o servidor de proxy cache pode incorrer em custos de transmissão. Por conseguinte, o novo método aqui descrito resulta em uma redução nestes custos de transmissão.

Solicitação de Arquivo Probabilisticos Inteiro Uma questão particular no caso em que o protocolo HTTP é usado com solicitações de intervalo é o comportamento de servidores de cache que são comumente utilizados para prover escalabilidade da infraestrutura de serviço. Embora possa ser comum para os servidores de cache HTTP suportar o cabeçalho HTTP de Intervalo, o comportamento exato de diferentes servidores de cache HTTP varia de acordo com a implementação. A maioria das implementações de servidor de cache atendem às solicitações de Intervalo de cache no caso em que o arquivo está disponivel no cache. Uma implementação comum de servidores de Cache HTTP sempre encaminha solicitações HTTP a jusante contendo cabeçalho de intervalo para um nó a montante, a 5 menos que o servidor de cache tenha uma cópia do arquivo (servidor de cache ou servidor de origem). Em algumas implementações a resposta a montante da solicitação de Intervalo é o arquivo inteiro, e esse arquivo inteiro é armazenado em cache e a resposta à solicitação de Intervalo 10 a jusante é extraída deste arquivo e enviada. No entanto, em pelo menos uma implementação a resposta a montante para a solicitação de Intervalo é apenas os bytes de dados na solicitação de Intervalo em si, e estes bytes de dados não são armazenados, mas em vez disso simplesmente enviados 15 como a resposta à solicitação de Intervalo a jusante. Como resultado, o uso de cabeçalhos de Intervalo por clientes pode ter como consequência que o arquivo em si nunca é levado a caches e as propriedades desejáveis de escalabilidade da rede serão perdidas.

No que precede, a operação de servidores de proxy cache foi descrita e também o método de solicitação de Blocos a partir de um arquivo que é uma agregação de vários blocos foi descrito. Por exemplo, este pode ser alcançado através da utilização do cabeçalho de solicitação de

Intervalo HTTP. Tais solicitações são chamadas de "solicitações parciais" no seguinte. Uma outra modalidade é agora descrita, que tem vantagem no caso em que o bloco de infraestrutura de serviço 101 não provê suporte completo para o cabeçalho de intervalo HTTP. Comumente, os 30 servidores dentro de uma infraestrutura de bloco de serviço, por exemplo, uma Rede de Entrega de Conteúdo, suportam as solicitações parciais, mas não podem armazenar a resposta às solicitações parciais dearmazenamento local (cache). Esse servidor pode atender a uma solicitação parcial, encaminhado a solicitação para outro servidor, a menos que todo o arquivo seja armazenado na memória local, caso em que a resposta pode ser enviada sem encaminhar a solicitação para outro servidor.

Um sistema de fluxo continuo de solicitação de bloco que faz uso do novo aperfeiçoamento de agregação de bloco descrito acima pode executar fracamente se a infraestrutura de serviço de bloco apresentar esse comportamento, porque todas as solicitações, sendo as solicitações parciais, serão encaminhadas para outro servidor e nenhuma solicitação será servida por servidores de proxy cache, fracassando o objeto de prover os servidores de proxy cache em primeiro lugar. Durante o processo de fluxo continuo de solicitação de bloco, como descrito acima, um cliente pode, em algum ponto solicitar um bloco que seja no inicio de um arquivo.

De acordo com o novo método aqui descrito, sempre que uma determinada condição for atendida, tais solicitações podem ser convertidas de solicitações para o primeiro bloco em um arquivo para solicitações por todo o arquivo. Quando uma solicitação por todo o arquivo é recebida por um servidor de proxy cache o servidor de proxy normalmente armazena a resposta. Portanto, o uso dessas solicitações faz com que o arquivo seja trazido para o cache dos servidores de cache local tal que as solicitações subsequentes, seja para o arquivo completo ou solicitações parciais podem ser servidas diretamente pelo servidor de proxy cache. A condição pode ser tal que, entre um conjunto de solicitações associado com um dado arquivo, por exemplo, o conjunto de solicitações gerado por um conjunto de clientes visualizando o item de conteúdo em questão, a condição será satisfeita por pelo menos uma fração provida destas solicitações.

Um exemplo de uma condição adequada é que um número escolhido aleatoriamente está acima de um limite provido. Este limite pode ser reprodução de tal forma que a conversão de uma única solicitação de bloco em uma solicitação de arquivo completo ocorra em média para uma fração provida das solicitações, por exemplo, um tempo limite de dez (caso em que o número aleatório pode ser escolhido a partir do intervalo [0,1] e o limite pode ser 0,9). Outro exemplo de uma condição adequada é a de que uma função hash calculada ao longo de algumas informações associadas com o bloco e alguma informação associada com o cliente pegue um de um conjunto de valores providos. Este método tem a vantagem de que para um arquivo que é frequentemente requerido, o processo será trazido para o cache de um servidor proxy local no entanto, o funcionamento do sistema de fluxo continuo de solicitação de bloco não é alterado significativamente a partir da operação padrão em que cada solicitação é para um único bloco. Em muitos casos, onde a conversão da solicitação a partir de uma única solicitação de bloco para uma solicitação de arquivo inteiro ocorre, os procedimentos de cliente, iriam de outra maneira ocorrer para solicitar os outros blocos dentro do arquivo. Se este for o caso, então essas solicitações podem ser suprimidas porque os blocos em questão irão ser recebidos em qualquer caso, como um resultado da solicitação de arquivo completo. Construção de URL e Geração de Lista de Segmento e Busca

A lista de segmento trata com a questão de como um cliente pode gerar uma lista de segmento a partir da MPD em um tempo local específico dê cliente FTOW para—uma- representação específica, que se inicia em algum tempo de partida starttime, quer em relação ao início da apresentação de mídia para casos on-demand ou expressa em tempo de relógio de parede. Uma lista de segmento pode compreender um localizador de, por exemplo um URL para uma metadados de representação inicial opcional, bem como uma lista de segmentos de mídia. A cada segmento de mídia pode ter sido atribuído um starttime, uma duração e um localizador. O starttime tipicamente expressa uma aproximação do tempo de mídia da mídia contida em um segmento, mas não necessariamente um tempo de amostra exato. 0 starttime é usado pelo cliente de fluxo contínuo HTTP para emitir a solicitação de download no momento apropriado. A geração da lista de segmento, incluindo o tempo de partida de cada um, pode ser feita de formas diferentes. Os URLs podem ser providos como uma lista de leitura ou uma regra de construção de URL pode ser vantajosamente utilizada para uma representação compacta da lista de segmento.

Uma lista de segmento baseada na construção de URL pode, por exemplo, ser realizada se os sinais de MPD que, por um atributo específico ou elemento, tal como FileDynamicInfo ou um sinal equivalente. A forma genérica para criar uma lista de segmentos de uma construção de URL é provida abaixo na seção "Visão Geral de Construção de URL". Uma construção baseada em playlist pode, por exemplo, ser sinalizada por um sinal diferente. Buscar na lista de segmento e conseguir um tempo de mídia preciso também é vantajosamente implementado neste contexto.

Visão Geral de Construtor de URL Como descrito anteriormente, em uma modalidade da presente invenção pode ser provido um arquivo de metadados contendo regras de construção de URL que permitem que dispositivos de cliente construam os identificadores de arquivo para blocos da apresentação. Agora é descrito um novo aperfeiçoamento adicional para o sistema de fluxo continuo de solicitação de bloco que provê alterações no arquivo de metadados, incluindo as alterações às regras de construção de URL, alterações no número de codificações disponíveis, mudanças de metadados associados com as codificações disponíveis, tais como o bitrate, relação de aspecto, resolução de áudio, codec de video ou parâmetros de codec e outros parâmetros.

Neste aperfeiçoamento novo, podem ser providos dados adicionais associados com cada elemento do arquivo de metadados indicando um intervalo de tempo dentro da apresentação global. Dentro deste intervalo de tempo o elemento pode ser considerado válido e de outra forma o intervalo de tempo o elemento pode ser ignorado. Além disso, a sintaxe dos metadados pode ser aumentada de forma que os elementos previamente autorizados a aparecer apenas uma vez ou no máximo uma vez podem aparecer várias vezes. Uma restrição adicional pode ser aplicada no presente caso, que provê que, para tais elementos os intervalos de tempo especificados devem ser separados. Em qualquer instante de tempo determinado, considerando somente os elementos cujo intervalo de tempo contém os dados resultados de instantes de tempo em um arquivo de metadados que é consistente com a sintaxe de metadados original. Chama-se intervalos de tempo tais intervalos de validade. Este método provê, portanto, a sinalização dentro de algumas alterações de metadados de arquivo único do tipo descrito acima. Vantajosamente, tal método pode ser usado para prover uma apresentação de midia que suporta mudanças do tipo descrito em pontos específicos no interior da apresentação. Construtor de URL

Tal como descrito aqui, uma característica comum do sistemas de fluxo continuo de solicitação de bloco é a necessidade de prover ao cliente "metadados" que identificam as codificações de midia disponíveis e provê as informações necessárias pelo cliente para solicitar os blocos dessas codificações. Por exemplo, no caso de HTTP, esta informação pode incluir URLs para os arquivos contendo os blocos de midia. Um arquivo de playlist pode ser provido que lista as URLs para os blocos de uma determinada codificação. Vários arquivos de lista de reprodução são providos, um para cada codificação, juntamente com uma lista de reprodução da lista de reprodução mestre que lista as listas correspondentes às diferentes codificações. Uma desvantagem deste sistema é que os metadados podem tornar- se muito grandes e, por conseguinte, leva algum tempo para serem solicitados quando o cliente começa a transmitir. Uma outra desvantagem deste sistema é evidente, no caso do conteúdo, ao vivo, quando os arquivos correspondentes aos blocos de dados de midia são gerados "on-the-fly" a partir de um fluxo de midia que está sendo capturado em tempo real (ao vivo) , por exemplo um evento de esportes ao vivo ou programa de noticias. Neste caso, os arquivos da lista podem ser atualizados cada vez que um novo bloco está disponivel (por exemplo a cada poucos segundos). Dispositivos clientes podem repetidamente buscar o arquivo de playlist para determinar se novos blocos estão disponíveis e obter a sua URL. Isto pode colocar uma carga significativa na infraestrutura de serviço e em particular significa que arquivos de metadados não podem ser armazenados durante mais tempo do que o intervalo de atualização, que é igual ao tamanho do bloco que é comumente da ordem de alguns segundos.

Um aspecto importante de um sistema de fluxo continuo de solicitação de bloco é o método utilizado para informar os clientes dos identificadores de arquivo, por exemplo, URLs, que devem ser usados, juntamente com o protocolo de download de arquivo, para solicitar Blocos. Por exemplo, um método em que para cada representação de uma apresentação é provido um arquivo de playlist que lista os URLs dos arquivos contendo os blocos de dados de midia. Uma desvantagem deste método é que, pelo menos, algum do arquivo de playlist em si precisa ser descarregado antes da reprodução poder começar, aumentando o tempo de zapping de canal e, por conseguinte, causando uma experiência de usuário ruim. Para uma apresentação de midia longa com várias representações ou muitas, a lista de URLs de arquivo pode ser grande e, portanto, o arquivo de playlist pode ser grande aumentando ainda mais o tempo de zapping de canal.

Outra desvantagem deste método ocorre no caso de o conteúdo ao vivo. Neste caso, a lista completa de URLs não é disponibilizada com antecedência e o arquivo de playlist é atualizado periodicamente conforme novos blocos se tornam disponíveis e os clientes exigem, periodicamente, o arquivo de playlist, a fim de receber a versão atualizada. Devido ao fato deste arquivo ser atualizado com frequência, ele não pode ser armazenado por muito tempo dentro dos servidores de proxy cache. Isto significa que muitas das solicitações para este arquivo serão encaminhadas para outros servidores e, eventualmente, para o servidor que gera o arquivo. No caso de uma apresentação de mídia popular isto pode resultar em uma carga elevada no servidor e na rede, que pode por sua vez, resultar em um tempo de resposta lenta e, portanto, um elevado tempo de zapping de canal e experiência de usuário ruim. No pior caso, o servidor fica sobrecarregado e isso resulta em alguns usuários que são incapazes de ver a apresentação.

É desejável no projeto de um sistema de fluxo continuo de solicitação . de bloco evitar a imposição de restrições sobre a forma dos identificadores de arquivos que pode ser utilizada. Isto porque uma série de considerações pode motivar a utilização de identificadores de uma forma particular. Por exemplo, no caso em que a infraestrutura de serviço de bloco é uma Rede de Entrega de Conteúdo pode haver nomeação de arquivo ou convenções de armazenamento relacionadas a um desejo de distribuir carga de armazenamento ou de serviço em toda a rede ou outros requisitos que levam a determinadas formas de identificador de arquivo que não pode ser prevista no momento do projeto do sistema.

Uma outra modalidade é agora descrita, que atenua os inconvenientes acima mencionados, mantendo a flexibilidade para escolher as convenções de identificação de arquivo adequadas. Neste método metadados podem ser providos para cada representação da apresentação de midia que inclui uma regra de construção de identificador de arquivo. A regra de construção de identificador de arquivo pode, por exemplo, compreender um texto. A fim de determinar o identificador de arquivo para um dado bloco da apresentação, um método de interpretação da regra de construção de identificador de arquivo pode ser provido, este método compreendendo a determinação de parâmetros de entrada e avaliação da regra de construção de identificador de arquivo juntamente com os parâmetros de entrada. Os parâmetros de entrada podem, por exemplo, incluir um indice do arquivo a ser identificado, em que o primeiro arquivo tem indice zero, o segundo tem indice um, o terceiro tem indice dois e assim por diante. Por exemplo, no caso em que todos os arquivos estendem-se pelo mesmo período de tempo (ou aproximadamente o mesmo período de tempo), então o índice do arquivo associado com qualquer dado momento dentro da apresentação pode ser facilmente determinado. Alternativamente, o prazo da apresentação gerado por cada arquivo pode ser provido dentro da apresentação ou metadados de versão.

Em uma modalidade, a regra de construção de identificador de arquivo pode compreender uma string de texto que pode conter certos identificadores especiais correspondentes aos parâmetros de entrada. 0 método de avaliação da regra de construção de identificador de arquivo compreende determinar as posições dos identificadores especiais dentro do string de texto e substituir cada tal identificador especial por uma representação de string do valor do parâmetro de entrada correspondente.

Em uma outra modalidade, a regra de construção de identificador de arquivo pode compreender um string de texto de acordo com uma linguagem de expressão. Uma linguagem de expressão compreende a definição de uma sintaxe a qual expressões na língua podem se conformar e um conjunto de regras para avaliar um string que se conforma com a sintaxe.

Um exemplo específico será agora descrito, com referência à figura 21 et seq. Um exemplo de uma definição de sintaxe para um idioma de expressão adequado, definido em Forma Backus-Naur Aumentada, é como mostrado na figura 21. Um exemplo de regras para avaliar um string de acordo com a produção <expressão> na figura 21 compreende recursivamente transformar o string conformant na produção <expressão> (um <expressão>) em um string conformant para a produção <literal> como se segue: Um <expressão> conformant para produção <literal> permanece inalterado.

Um conformant <expressão> para a produção <variável> é substituído pelo valor da variável identificada pelo string <token> da produção <variável>.

Um conformant <expressão> para a produção <função> é avaliado pela avaliação de cada um dos seus argumentos de acordo com estas regras e aplicando uma transformação a estes argumentos dependentes do elemento <token> da produção <função> como descrito abaixo.

Um conformant <expressão> para a última alternativa da produção <expressão> é avaliado por meio da avaliação dos dois elementos <Expressão> e aplicando uma operação a estes argumentos dependentes do elemento <operador> da última alternativa da produção <expressão> como descrito abaixo.

No método acima descrito é assumido que a avaliação é efetuada em um contexto em que uma pluralidade de variáveis podem ser definidas. Uma variável é um par (nome, valor) , onde "nome" é um conformant string para a produção <token> e "valor" é um conformant string para a produção <literal>. Algumas variáveis podem ser definidas fora do processo de avaliação antes de a avaliação começar. Outras variáveis podem ser definidas no escopo do processo de avaliação em si. Todas as variáveis são "globais" no sentido de que apenas uma variável existe com cada "nome" possível.

Um exemplo de uma função é a função "print". Esta função aceita um ou mais argumentos. O primeiro argumento pode ser conformant à produção <string> (doravante um "string"). A função printf é avaliada como uma versão transformada do seu primeiro argumento. A transformação aplicada é a mesma que afunção "printf" dã biblioteca padrão C, com os argumentos adicionais incluidos na produção <função> fornecendo os argumentos adicionais exceto pela função printf de biblioteca padrão C.

Outro exemplo de uma função é a função "hash". Esta função aceita dois argumentos, o primeiro dos quais pode ser um string e o segundo dos quais pode ser conformant à produção <número> (a seguir um "número"). A função "hash" aplica um algoritmo de hash ao primeiro argumento e retorna um resultado que é um número inteiro não negativo menor do que o segundo argumento. Um exemplo de uma função hash adequada é dada na função C mostrada na figura 22, cujos argumentos são o string de entrada (excluindo as aspas) e o valor de entrada numérico. Outros exemplos de funções hash são bem conhecidos dos versados na técnica.

Outro exemplo de uma função é a função "subst" que tem um, dois ou três argumentos de string. No caso em que um argumento é provido o resultado da função "Subst" é o primeiro argumento. No caso em que dois argumentos forem providos, o resultado da função "Subst" é calculado pela eliminação de todas as ocorrências do segundo argumento (excluindo as aspas) no primeiro argumento e retorna o primeiro argumento assim modificado. No caso em que três argumentos forem providos, o resultado da função "Subst" é calculado através da substituição de todas as ocorrências do segundo argumento (excluindo as aspas) dentro do primeiro argumento com o terceiro argumento (excluindo as aspas) e retornando ao primeiro argumento assim modificado.

Alguns exemplos de operadores são a adição, subtração, multiplicação, divisão e operadores de módulo, identificadas pelas produções <operador> ' + ', ' '/', ' '%', respectivamente. Esses operadores exigem que as produções <Expression > de üm dos lados da produção <operador> avaliem em números. A avaliação do operador compreende aplicar a operação aritmética apropriada (adição, subtração, divisão, multiplicação, e módulo, respectivamente) a estes dois números da maneira usual e retornando o resultado de uma forma compativel com a produção <número>.

Outro exemplo de um operador é o operador de atribuição, identificado pela produção <operador> Este operador requer que o argumento da esquerda seja avaliado como um string cujo conteúdo é compativel com a produção <token>. O conteúdo de um string é definido como o string de caracteres entre aspas. O operador de igualdade faz com que a variável cujo nome é o <token> seja igual ao conteúdo do argumento da esquerda para ser atribuido um valor igual ao resultado da avaliação do argumento do lado direito. Este valor é também o resultado da avaliação da expressão do operador.

Outro exemplo de um operador é o operador de sequência, identificado pela produção <operador> ' ; ' . O resultado da avaliação deste operador é o argumento do lado direito. Observe que, como com todos os operadores, ambos os argumentos são avaliados e o argumento da esquerda é avaliado primeiro.

Em uma modalidade da presente invenção, o identificador de um arquivo pode ser obtido através da avaliação de uma regra de construção de identificador de arquivo de acordo com a regra acima com um conjunto especifico de variáveis de entrada que identificam o arquivo pretendido. Um exemplo de uma variável de entrada é a variável com o nome "index" e o valor igual ao indice numérico do arquivo dentro da apresentação. Outro exemplo de uma variável de entrada é a variável com nome "bitrate" e o valor igual à taxa de bits média da versão necessária da apresentação A figura 23 ilustra alguns exemplos de regras de construção de identificador de arquivo, onde as variáveis de entrada são "id", dando um identificador para a representação da apresentação desejada e "seq", dando um número de sequência para o arquivo

Como será claro para aqueles que são versados na técnica após a leitura desta descrição, numerosas variações do método acima são possiveis. Por exemplo, nem todas as funções e os operadores descritos acima podem ser providos ou funções ou operadores adicionais podem ser providos. Regras de Construção de URL e Temporização

Esta seção provê regras de construção de URI básicas para atribuir um arquivo de URI ou segmento, bem como um tempo de partida de cada segmento dentro de uma representação e apresentação de midia. Para esta cláusula a disponibilidade de uma descrição de apresentação de midia no cliente é assumida.

Suponha que o cliente de fluxo continuo HTTP está reproduzindo a midia que é baixada dentro de uma apresentação de midia. O tempo de apresentação real do cliente HTTP pode ser definido como a onde o tempo de apresentação é relativo ao inicio da apresentação. Na inicialização, o tempo de apresentação t = 0 pode ser assumido.

Em qualquer ponto t, o cliente HTTP pode baixar quaisquer dados com tempo de reprodução tP (também em relação ao inicio da apresentação), no máximo, MaximumClientPreArmazenadorTime à frente do tempo de apresentação real t e quaisquer dados que são necessários devido a uma interação de usuário, por exemplo busca, avanço, etc. Em algumas modalidades o

MaximumClientPreArmazenadorTime não pode nem mesmo ser especificado no sentido de que um cliente pode realizar download de dados à frente da reprodução real tP, sem restrições.

O cliente HTTP pode evitar o download de dados desnecessários, por exemplo, todos os segmentos de representações que não são esperados para ser reproduzidos não podem normalmente ser baixados.

O processo básico no provimento dos serviços de 10 fluxo continuo pode ser o download de dados através da geração de solicitações apropriadas para download de arquivos inteiros / segmentos ou subconjunto de arquivos e segmentos, por exemplo, usando solicitações HTTP GET ou solicitações HTTP GET parcial. Esta descrição trata de como acessar os dados por um tempo de reprodução tP especifico, mas geralmente o cliente pode fazer download de dados por um intervalo maior de tempo de reprodução para evitar solicitações ineficientes. O cliente HTTP pode minimizar o número / frequência de solicitações HTTP no provimento do 20 serviço de fluxo continuo.

Para acessar os dados de midia em tempo de reprodução tP ou pelo menos perto do tempo de reprodução tP em uma representação especifica o cliente determina o URL para o arquivo que contém esse tempo de reprodução e, além 25 disso determina o intervalo de bytes no arquivo para acessar a este tempo de reprodução.

A Descrição de Apresentação de Midia pode atribuir um ID de representação, r, para cada representação, por exemplo, pelo uso do atributo 30 RepresentationID. Em outras palavras, o conteúdo da MPD, quando gravado pelo sistema de ingestão ou quando lido pelo cliente, será interpretado de tal forma que existe uma atribuição. Para baixar os dados para um tempo de reprodução tP especifico para uma representação especifica com id r, o cliente pode construir uma URI apropriada para um arquivo.

A Descrição de Apresentação de Midia pode 5 atribuir a cada arquivo ou segmento de cada representação r os seguintes atributos: (a) um número de sequência i do arquivo dentro da representação r, com i = 1, 2, ... , Nr, (b) o tempo de partida relativo do arquivo com id de representação r e 10 indice de arquivo i em relação ao tempo de apresentação, definido como ts(r,i), (c) o URI de arquivo para o arquivo / segmento com id de representação r e indice de arquivo i, denotado como FileURI (r,i).

Em uma modalidade o tempo de partida do arquivo e 15 os URIs de arquivo podem ser providos explicitamente para uma representação. Em outra modalidade, uma lista de URIs de arquivo pode ser provida explicitamente onde a cada URI de arquivo é inerentemente atribuido o indice i de acordo com a posição na lista e o tempo de partida do segmento é 2 0 determinado como a soma de todas as durações de segmentos para os segmentos de 1 a i-1. A duração de cada segmento pode ser provida de acordo com qualquer uma das regras acima discutidas. Por exemplo, qualquer versado em matemática básica pode utilizar outros métodos para derivar 25 uma metodologia para facilmente derivar tempo de partida a partir de um único elemento ou atributo e a posição / indice da URI de arquivo na representação.

Se uma regra de construção de URI dinâmica é provida na MPD, então o tempo de partida de cada arquivo e 30 cada URI de arquivo pode ser construído de forma dinâmica usando uma regra de construção, o indice do arquivo solicitado e eventualmente alguns parâmetros adicionais providos na descrição de apresentação de midia. A informação pode, por exemplo, ser provida em atributos de MPD e elementos tais como FileURIPattern e Filelnf©Dynamic. O FileURIPattern provê informações sobre como construir os URIs com base no número de sequência de indice de arquivo i e o ID de representação r. O FileURIFormat é construído como: FileURIFormat = sprintf ("% s% s% s% s% s.%s", BaseURI, baseFileName,

Representation!DFormat,SeparatorFormat, FileSequencelDFormat,FileExtention); e o FileURI (r, i) é construído como FileURI (r, i) = sprintf (FileURIFormat, r, i);

O tempo de partida relativo ts (r, i) para cada arquivo / segmento pode ser derivado por algum atributo contido na MPD descrevendo a duração dos segmentos nesta representação, por exemplo, o atributo FilelnfoDynamic. A MPD pode também conter uma sequência de atributos FilelnfoDynamic que é global para todas as representações na apresentação de midia ou pelo menos para todas as representações em um periodo da mesma maneira como acima especificado. Se os dados de midia para um tempo de reprodução tP especifico na representação r são solicitados, o indice correspondente i (r, tP) pode ser derivado como i (r, tp) de tal modo que o tempo de reprodução deste indice está no intervalo do tempo de partida de ts (r, i (r, tP)) e st(r,i(r, tP) + 1). O acesso ao segmento pode ser adicionalmente restrito por casos acima, por exemplo, o segmento não está acessivel.

Para acessar o tempo de restrição tP exato uma vez que o indice e o URI do segmento correspondente é obtido, depende do formato do segmento real. Neste exemplo assumir que os segmentos de midia têm uma linha de tempo local; quê começa nõ Õ sem perda de generalidade. Para acessar e apresentar os dados em tempo de reprodução tP o cliente pode baixar os dados correspondentes para o tempo local do arquivo / segmento que pode ser acessado através do URI FileURI (r,i) com i = i (r,tp) .

Geralmente, os clientes podem baixar o arquivo inteiro e podem, então, acessar o tempo de reprodução tP. No entanto, não necessariamente todas as informações do arquivo 3GP precisam ser baixadas, como o arquivo 3GP provê estruturas para mapear a temporização local para intervalos de bytes. Portanto, apenas os intervalos de bytes específicos que acessam tempo de reprodução tP podem ser suficientes para desempenhar a midia contanto que a informação de acesso aleatório suficiente está disponivel. Também a informação suficiente sobre a estrutura e mapeamento do intervalo de bytes e o tempo local do segmento de midia podem ser providos na parte inicial do segmento, por exemplo, utilizando um indice de segmento. Ao ter acesso ao inicial, por exemplo, 1200 bytes do segmento, o cliente pode ter informações suficientes para acessar diretamente o intervalo de bytes necessário para tempo de reprodução tP.

Em um exemplo adicional assumir que o indice de segmento, possivelmente especificado como a caixa "tidx" como abaixo, pode ser usado para identificar os desvios de byte do Fragmento necessário ou Fragmentos. Solicitações de GET parciais podem ser formadas para o fragmento necessário ou Fragmentos. Há outras alternativas, por exemplo, o cliente pode emitir uma solicitação padrão para o arquivo e cancelar esta quando a primeira caixa "tidx" foi recebida. Busca

Um cliente pode tentar buscar um tempo de apresente ação tp especifico em uma representação. Com base na MPD, o cliente tem acesso ao tempo de partida do segmento de midia e URL de segmento de midia de cada segmento da representação. O cliente pode obter o indice de segmento segment_index do segmento mais provável que contêm amostras de midia para tempo de apresentação tp como o indice máximo de segmento i, para os quais o tempo de partida tS (r, i) é menor ou igual ao tempo de apresentação tp isto é, segment_index = max {i | tS (r, i) <= tp}. O URL de segmento é obtido como FileURI (r, i).

Note que as informações de temporização na MPD podem ser aproximadas, devido a questões relacionadas com a colocação de pontos de acesso aleatório, o alinhamento das faixas de midia e drift de temporização de midia. Como resultado, o segmento identificado pelo processo acima descrito pode começar em um tempo ligeiramente após tp e os dados de midia para tempo de apresentação tp podem ser no segmento de midia anterior. No caso de busca, quer o tempo de busca pode ser atualizado para igualar o tempo de amostra, antes do arquivo recuperado, quer o arquivo anterior pode ser. recuperado em vez disso. No entanto, note que, durante a reprodução continua, incluindo casos em que houver uma comutação entre representações alternativas / versões, os dados de midia para o tempo entre o tp e o inicio do segmento recuperado são, contudo disponíveis.

Para busca precisa por um tempo de apresentação tp, o cliente de fluxo continuo HTTP precisa acessar um ponto de acesso aleatório (RAP). Para determinar o ponto de acesso aleatório em um segmento de midia, no caso de fluxo continuo HTTP adaptativo 3GPP, o cliente pode, por exemplo, usar a informação na caixa 'tidx' ou 'sidx', se presente, para localizar os pontos de acesso aleatório e o tempo de apresentação correspondente na apresentação de midia. Nos casos em que um segmento é um fragmento de filme 3GPP, também é possivel para o cliente usar a informação no interior da caixa 'Moof e 'mdat', por exemplo, para localizar RAPs e obter o tempo de apresentação necessário a partir da informação no fragmento de filme e o tempo de partida de segmento derivado da MPD. Se nenhum RAP com o tempo de apresentação antes do tempo de apresentação solicitado tp disponivel, o cliente pode tanto acessar o segmento anterior ou pode usar apenas o primeiro ponto de acesso aleatório como o resultado de busca. Quando os segmentos de midia começam com um RAP, estes procedimentos são simples.

Além disso, note que não necessariamente todas as informações do segmento de midia precisam ser baixadas para acessar o tempo de apresentação tp. O cliente pode, por exemplo, inicialmente solicitar a caixa 'tidx' 'sidx' a partir do inicio do segmento de midia usando solicitações de intervalo de byte. Pelo uso da caixa 'tidx' ou 'sidx', o tempo do segmento pode ser mapeado para intervalos de bytes do segmento. Continuamente usando solicitações HTTP parciais, apenas as partes relevantes do segmento de midia precisam ser acessadas, para experiência de usuário melhorada e baixos retardos na inicialização.

Geração de Lista de Segmentos Como aqui descrito, deve ser aparente como implementar um cliente de fluxo continuo HTTP simples que utiliza a informação provida pela MPD para criar uma lista de segmentos para uma representação que tem uma duração de segmento aproximada sinalizada dur. Em algumas modalidades, o cliente pode atribuir os segmentos de midia dentro de indices de representação consecutivos i = 1, 2, 3, . .., isto é, ao primeiro segmento de midia é atribuido o indice i = 1, ao segundo segmento de midia é atribuido o indice i = 2, e assim por diante. Então à lista de segmentos de midia com os indices de segmento i é atribuido startTime [i] e URL [i] é gerado, por exemplo, como se segue. Primeiro, o indice i é ajustado para 1. 0 tempo de partida do primeiro segmento de midia é obtido como 0, startTime [1] = 0. A URL do segmento de midia i, URL [i] , é obtida 5 como FileURI (r, i). O processo é continuado para todos os segmentos de midia descritos com o indice i e startTime [i] do segmento de midia i é obtido como (i-1) * dur e a URL [i], é obtida como FileURI (r, i). Solicitações HTTP / TCP Simultâneas

Uma questão em um sistema de fluxo continuo de solicitação de bloco é um desejo de sempre solicitar os blocos da mais alta qualidade que podem ser totalmente recebidos em tempo para a reprodução. No entanto, a taxa de chegada de dados não pode ser conhecida com antecedência e 15 por isso pode acontecer que um bloco solicitado não chegue a tempo de ser reproduzido. Isso resulta em uma necessidade de pausar a reprodução de midia, o que resulta em uma má experiência de usuário. Este problema pode ser atenuado por meio... de algoritmos ... de clientes que têm., uma abordagem conservadora para a seleção de blocos para solicitar solicitando blocos de menor qualidade (e portanto, de menor tamanho) que são mais susceptíveis de serem recebidos no tempo, mesmo se a taxa de chegada de dados cai durante a recepção do bloco. No entanto, esta abordagem conservadora 25 tem a desvantagem de, possivelmente entregar uma reprodução de menor qualidade para o usuário ou o dispositivo de destino, que é também uma má experiência de usuário. O problema pode ser ampliado quando várias conexões de HTTP são usadas ao mesmo tempo para baixar blocos diferentes, 30 como descrito abaixo, uma vez que os recursos da rede disponíveis são compartilhados através de conexões e, assim, estão sendo utilizados simultaneamente por blocos com tempos de reprodução diferentes.

Pode ser vantajoso para o cliente emitir solicitações de vários blocos ao mesmo tempo, onde, neste contexto, "simultaneamente" significa respostas às solicitações que estão ocorrendo em sobreposição de 5 intervalos de tempo, e não é necessariamente o caso que as solicitações são feitas precisamente no mesmo ou aproximadamente ao mesmo tempo. No caso do protocolo HTTP, esta abordagem pode melhorar a utilização da largura de banda disponivel devido ao comportamento do protocolo TCP 10 (tal como é bem conhecido) . Isso pode ser especialmente importante para melhorar o tempo de zapping de conteúdo, como quando um novo conteúdo é primeiramente solicitado as conexões HTTP / TCP correspondentes através das quais os dados para os blocos são solicitados podem ser lentas para 15 iniciar, e, portanto, o uso de várias conexões HTTP / TCP neste ponto pode acelerar drasticamente o tempo de entrega de dados dos primeiros blocos. No entanto, solicitar blocos diferentes ou fragmentos sobre diferentes conexões HTTP / TCP também pode levar à degradação do desempenho,. assim 20 como as solicitações para os blocos que estão sendo primeiro reproduzidas estão competindo com as solicitações para os blocos subsequentes, competir downloads HTTP / TCP varia muito na sua velocidade de entrega e, assim, o tempo de conclusão da solicitação pode ser altamente variável, e 25 não é geralmente possivel controlar quais downloads HTTP / TCP irão se completar rapidamente e qual será mais lento, e, assim, é provável que pelo menos algum do tempo dos downloads de HTTP / TCP dos primeiros blocos será o último para completar, conduzindo assim a grandes e variáveis 30 tempos de zapping de canal.

Suponha-se que cada bloco ou fragmento de um segmento seja baixado através de uma conexão HTTP / TCP em separado, e que o número de conexões paralelas é N e o tempo de reprodução de cada bloco é t segundos, e que a taxa de fluxo do conteúdo associado com o segmento é S. Quando o primeiro cliente começa a transmitir o conteúdo, as solicitações podem ser emitidas para os primeiros blocos 5 n, representando n * t segundos de dados de midia.

Como é conhecido dos versados na técnica, há uma grande variação na taxa de dados de conexões TCP. No entanto, para simplificar a discussão, suponha-se que idealmente todas as conexões devem decorrer em paralelo de 10 tal modo que o primeiro bloco será completamente recebido aproximadamente ao mesmo tempo que os outros n-1 blocos solicitados. Para simplificar a discussão mais aprofundada, suponha-se que a largura de banda agregada utilizada pelas n conexões de download é fixada para um valor B durante 15 toda a duração do download, e que a taxa de fluxo S é constante ao longo da representação inteira. Suponha-se ainda que a estrutura de dados de midia é tal que reprodução de um bloco pode ser feita quando todo o bloco está disponivel no cliente, isto é, reprodução de um bloco 20 só pode começar após todo o bloco ser recebido, por exemplo, devido à estrutura da codificação de video subjacente, ou porque criptografia deve ser empregue para criptografar cada fragmento ou bloco separadamente, e, assim, o fragmento inteiro ou bloco tem de ser recebido 25 antes de ele poder ser decodificado. Assim, para simplificar a discussão abaixo, assume-se que um bloco inteiro precisa de ser recebido antes de qualquer um do bloco poder ser reproduzido. Então o tempo necessário antes do primeiro bloco chegar e poder ser reproduzido é de 30 aproximadamente n * t * S / B.

Uma vez que é desejável minimizar o tempo de zapping de conteúdo, é, por conseguinte, desejável minimizar n * t * S / B. 0 valor de t pode ser determinado por fatores tais como a estrutura de codificação de video subjacente e como os métodos de ingestão são utilizados, e, assim, t pode ser razoavelmente pequeno, mas valores muito pequenos de t levam a um mapa de segmento muito complicado e, possivelmente, pode ser incompatível com codificação de video eficiente e decriptografia, se utilizada. O valor de n pode também afetar o valor de B, isto é, B pode ser maior para um maior número n de conexões, e reduzindo assim o número de conexões, n, tem o efeito colateral negativo de potencialmente reduzir a quantidade de largura de banda disponível que é utilizada, B, e assim pode não ser eficaz para se alcançar o objetivo de reduzir o tempo de zapping de conteúdo. O valor de S depende de qual representação é escolhida para baixar e reproduzir e, idealmente, S deve ser tão próximo de B quanto possível, a fim de maximizar a qualidade de reprodução da midia para as condições de rede dadas. Assim, para simplificar a discussão, assumir que S é aproximadamente igual a B. Então o tempo de zapping de canal.é proporcional a n * t. Assim, utilizar mais conexões para baixar diferentes fragmentos pode degradar o tempo de zapping de canal, se a largura de banda agregada utilizada pelas conexões é sublinearmente proporcional ao número de conexões, que é tipicamente o caso.

Como um exemplo, suponha-se que t = 1 segundo, e com n = 1 o valor de B = 500 Kbps, e com n = 2 o valor de B = 700 Kbps, e com n = 3 o valor de B = 800 Kbps. Suponha-se que a representação com S = 700 Kbps seja escolhida. Então com n = 1 o tempo de download para o primeiro bloco é de 1 * 700/500 =1,4 segundo, com n = 2 o tempo de download para o primeiro bloco é 2 * 700/700 = 2 segundos, e com n = 3 o tempo de download para o primeiro bloco é de 3 * 700/800 = 2,625 segundos. Além disso, como o número de conexões aumenta a variabilidade nas velocidades de download individual das conexões é susceptível de aumentar (embora, mesmo com uma conexão é provável que seja alguma variabilidade significativa). Assim, neste exemplo, o tempo de zapping de canal e a variabilidade no tempo de zapping 5 de canal aumenta assim como aumenta o número de conexões.

Intuitivamente, os blocos que devem ser entregues têm prioridades diferentes, ou seja, o primeiro bloco tem o prazo de entrega mais próximo, o segundo bloco tem o segundo prazo mais próximo, etc., enquanto que as conexões 10 de download sobre as quais os blocos estão sendo entregues estão competindo pelos recursos de rede durante a entrega, e assim os blocos com os primeiros prazos tornam-se mais atrasados assim como mais blocos concorrentes são solicitados. Por outro lado, mesmo neste caso, em última 15 análise, usar mais do que uma conexão de download permite suportar uma taxa de fluxo continuo sustentavelmente mais elevada, por exemplo, com três conexões uma taxa de fluxo continuo de até 800 Kbps pode ser suportada, neste exemplo, enquanto que apenas um fluxo de 500 Kbps pode ser suportado 20 com uma conexão.

Na prática, como notado acima, a taxa de dados de uma conexão pode ser altamente variável, tanto na mesma conexão ao longo do tempo quanto entre as conexões e, como resultado, os n blocos solicitados geralmente não se 25 completam ao mesmo tempo e no fato de que pode geralmente ser o caso em que um bloco pode concluir na metade do tempo de outro bloco. Este efeito resulta no comportamento imprevisível uma vez que em alguns casos, o primeiro bloco pode completar muito mais cedo do que outros blocos e em 30 outros casos, o primeiro bloco pode completar muito mais tarde do que os outros blocos, e como resultado, o inicio da reprodução pode, em alguns casos ocorrer de forma relativamente rápida e em outros casos pode ser lenta para ocorrer. Esse comportamento imprevisível pode ser frustrante para o usuário e pode, portanto, ser considerado uma má experiência de usuário.

O que é necessário, portanto, são os métodos em que várias conexões TCP podem ser utilizadas para melhorar o tempo de zapping de canal e a variabilidade no tempo de zapping de canal, enquanto ao mesmo tempo suportando uma taxa de fluxo de boa qualidade possível. O que também é necessário são métodos para permitir que o compartilhamento de largura de banda disponível atribuída a cada bloco seja ajustado conforme o tempo de reprodução de uma abordagem de bloco, de modo que, se necessário, uma parte maior da largura de banda disponível possa ser alocada para o bloco com o tempo de reprodução mais próximo. Solicitação HTTP / TCP Cooperativa

Agora irá ser descrito métodos para usar solicitações HTTP / TCP simultâneas de forma cooperativa. Um receptor pode empregar múltiplas solicitações HTTP / TCP cooperativas simultâneas, por exemplo, utilizando uma pluralidade de solicitações de intervalo de byte HTTP, em que cada uma dessas solicitações é para uma porção de um fragmento de um segmento fonte, ou todos de um fragmento de um segmento fonte, ou uma porção ou um fragmento de reparação de um segmento de reparação, ou para a totalidade de um fragmento de reparação de um segmento de reparação.

As vantagens de solicitações HTTP / TCP cooperativas, juntamente com o uso de dados de reparação FEC podem ser especialmente importantes para prover tempos de zapping de canal consistentemente rápidos. Por exemplo, em um tempo de zapping de canal é provável que as conexões TCP, quer tenham acabado de ser iniciadas ou ter sido paradas por um período de tempç, caso em que a janela de congestionamento, cwnd, está nç seu valor mínimo para as conexões, e assim a velocidade de entrega dessas conexões TCP terá vários tempo de ida e volta (RTT) acima, e haverá grande variabilidade nas velocidades de entrega ao longo das diferentes conexões TCP durante este tempo de 5 aceleração.

Uma visão geral do método sem FEC é agora descrita, que é um método de solicitação HTTP / TCP cooperativa em que apenas os dados de midia de blocos de código são solicitados usando múltiplas conexões HTTP / TCP 10 simultâneas, ou seja, não existem dados de reparação FEC solicitados. Com o método de n-FEC, porções do mesmo fragmento são solicitadas através de conexões diferentes, por exemplo, usando as solicitações de intervalo de bytes HTTP de porções do fragmento, e, assim, por exemplo, cada solicitação HTTP de intervalo de byte é para uma porção do intervalo de byte indicada no mapa de segmento para o fragmento. Pode ser o caso que uma solicitação HTTP / TCP individual incline acima até que a velocidade de entrega utilize totalmente a largura de banda disponível em vários RTTs (tempos de ida e volta) , e, portanto, há um periodo relativamente longo de tempo onde a velocidade de entrega é menor do que a largura de banda disponível e, portanto, se uma conexão HTTP / TCP única é utilizada para baixar por exemplo, o primeiro fragmento de um conteúdo a ser 25 reproduzido, o tempo de zapping de canal pode ser grande.

Utilizando o método sem FEC, baixar diferentes porções do mesmo fragmento através de diferentes conexões HTTP / TCP pode reduzir significativamente o tempo de zapping de canal.

Uma visão geral do método FEC é agora descrita, que é um método de solicitação de HTTP / TCP cooperativa em que dados de midia de um segmento fonte e dados de reparação FEC gerados a partir dos dados de midia são solicitados usando múltiplas conexões HTTP / TCP simultâneas. Com o método de FEC, porções do mesmo fragmento e os dados de reparação de FEC gerados a partir daquele fragmento são solicitados através de conexões 5 diferentes, usando as solicitações HTTP de intervalo de byte de porções do fragmento, e, assim, por exemplo, cada solicitação de HTTP de intervalo de byte é para uma porção do intervalo de byte indicada no mapa de segmento para o fragmento. Pode ser o caso que um solicitações HTTP / TCP 10 individuais inclinem para cima até que a velocidade de entrega utilize totalmente a largura de banda disponivel em vários RTTs (tempos de ida e volta) , e, portanto, há um periodo relativamente longo de tempo onde a velocidade de entrega é menor do que a largura de banda disponivel e, portanto, se uma conexão HTTP / TCP única é utilizada para baixar por exemplo, o primeiro fragmento de um conteúdo a ser reproduzido, o tempo de zapping de canal pode ser grande. Utilizar o método FEC tem as mesmas vantagens que o método sem FEC, e tem a vantagem adicional de que nem todas 20 as dadas solicitações precisam chegar antes do fragmento poder ser recuperado, reduzindo assim ainda mais o tempo de zapping de canal e a variabilidade no tempo de zapping de canal. Ao fazer solicitações sobre diferentes conexões TCP, e sobre solicitações também solicitando dados de reparação 25 de FEC em pelo menos uma das conexões, a quantidade de tempo que leva para entregar uma quantidade suficiente de dados para, por exemplo, recuperar o primeiro fragmento solicitado que permite que reprodução de midia comece, pode ser bastante reduzido e tornado muito mais consistente do 30 que se as conexões TCP cooperativas e dados de reparação FEC não forem utilizados. As figuras 24 (a) - (e) mostram um exemplo das flutuações de taxa de entrega de 5 conexões TCP sendo executadas sobre a mesma conexão para o mesmo cliente a partir do mesmo servidor de web HTTP de uma rede otimizada de dados de evolução emulados (EVDO). Nas figuras 24 (a) - (e), o eixo X mostra o tempo em segundos, e o eixo Y mostra a taxa a que os bits são recebidos no cliente sobre cada uma das 5 conexões TCP medidas ao longo de intervalos de 1 segundo, para cada conexão. Nesta emulação particular, houve 12 conexões TCP no total sendo executadas sobre esta conexão e, assim, a rede foi relativamente carregada durante o tempo indicado, o que pode ser tipico quando mais do que um cliente está fluindo dentro da mesma célula de uma rede móvel. Note-se que embora as taxas de entrega sejam um tanto correlacionadas com o tempo, há grande diferença nas taxas de entrega de 5 conexões em muitos pontos no tempo. A figura 25 mostra uma estrutura de solicitação possivel para um fragmento que é de 250.000 bits de tamanho (cerca de 31,25 kilobytes), onde existem 4 solicitações HTTP de intervalos de byte feitos em paralelo para as diferentes partes do fragmento, ou seja, as primeiras solicitações de conexão HTTP dos primeiros bits de 50.000 , as segundas solicitações de conexão HTTP nos próximos 50.000 bits, as terceiras solicitações de conexão HTTP nos próximos 50.000 bits, e as quartas solicitações de conexão HTTP nos próximos 50.000 bits. Se FEC não é usado, isto é, o método sem FEC, então estas são as únicas 4 solicitações para o fragmento neste exemplo. Se FEC é usado, isto é, o método de FEC, então no presente exemplo, há uma conexão HTTP adicional que solicita um adicional de 50.000 bits de dados de reparação de FEC de um segmento de reparação gerado a partir do fragmento. A figura 26 é uma ampliação do primeiro par de segundos das _J5 co&exèes—de TCP mostradas na figura. As figuras 24 (a) - (e) , onde na figura 26, o eixo X mostra o tempo em intervalos de 100 milissegundos, e o eixo Y mostra a taxa a que os bits são recebidos no cliente sobre cada uma das 5 conexões de TCP medidas ao longo de intervalos de 100 milissegundos. Uma linha mostra a quantidade total de bits que foram recebidos no cliente para o fragmento a partir das 4 primeiras conexões HTTP (excluindo a conexão HTTP sobre a qual os dados de FEC são solicitados) , ou seja, os que chegam usando o método sem FEC. Outra linha mostra a quantidade total de bits que foram recebidos no cliente para o fragmento de todas as 5 conexões HTTP (incluindo a conexão HTTP sobre a qual os dados de FEC são solicitados), ou seja, os que chegam usando o método de FEC. Para o método de FEC, presume-se que o fragmento pode ser decodificado por FEC a partir de recepção de quaisquer 200.000 bits dos bits de 250.000 solicitados , que podem ser realizados, se por exemplo um código Reed-Solomon FEC é usado, e que pode ser essencialmente realizado se por exemplo o código RaptorQ descrito no Luby IV é utilizado. Para o método de FEC neste exemplo, dados suficientes são recebidos para recuperar o fragmento através de decodificação de FEC depois de 1 segundo, permitindo um tempo de zapping de canal de 1 segundo (assumindo que os dados para os fragmentos subsequentes podem ser solicitados e recebidos antes do primeiro fragmento são totalmente reproduzidos). Para o método sem FEC neste exemplo, todos os dados para as 4 solicitações tem de ser recebidos antes do fragmento podem ser recuperados, que ocorre depois de 1,7 segundo, levando a um tempo de zapping de canal de 1,7 segundo. Assim, no exemplo mostrado na figura 26, o método sem FEC é 7 0% pior em termos de tempo de zapping de canal do que o método FEC. Uma das razões para a vantagem mostrada pelo método FEC neste exemplo é que, para o método de FEC, a recepção de qualquer 80% dos dados requeridos permite a recuperação do fragmento, enquanto que para o método sem FEC, a recepção de 100% dos dados são solicitados. Assim, o método sem FEC tem de esperar para a conexão TCP mais lenta para terminar a entrega, e por causa das variações naturais na taxa de entrega de TCP está apto a ter grande variação na velocidade de entrega da conexão TCP mais lenta em comparação com uma conexão TCP média conexão. Com o método de FEC neste exemplo, uma conexão TCP lenta não determina quando o fragmento é recuperável. Em vez disso, para o método de FEC, a entrega de dados suficientes é muito mais uma função da taxa média de entrega TCP do que o pior caso da taxa de entrega de TCP.

Existem muitas variações do método sem FEC e o método FEC descrito acima. Por exemplo, as solicitações HTTP / TCP cooperativas podem ser utilizadas apenas durante os primeiros fragmentos após um zap de canal ter ocorrido, e, subsequentemente, apenas uma solicitação HTTP / TCP única é utilizada para baixar fragmentos adicionais, vários fragmentos, ou segmentos inteiros. Como outro exemplo, o número de conexões HTTP / TCP cooperativas usadas pode ser uma função de ambas a urgência dos fragmentos sendo solicitada, isto é, como iminente é o tempo de reprodução destes fragmentos, e as condições atuais da rede.

Em algumas variações, uma pluralidade de conexões HTTP pode ser utilizada para solicitar dados de reparação a partir de segmentos de reparação. Em outras variações, diferentes quantidades de dados podem ser solicitadas em conexões HTTP diferentes, por exemplo, dependendo do tamanho atual do armazenador de midia e da taxa de recepção de dados no cliente. Em uma outra variação, as representações fonte não são independentes uma da outra, mas em vez disso representam codificação de midia em camadas, onde, por exemplo uma representação fonte reforçada pode depender de uma representação fonte de base. Neste caso, pode haver uma representação de reparação correspondente à representação fonte de base, e uma outra representação de reparação correspondente à combinação das representações fonte melhorada e de base.

Adição de elementos gerais adicionais às vantagens pode ser realizado pelos métodos divulgados acima. Por exemplo, o número de conexões de HTTP utilizado pode variar dependendo da quantidade atual de midia no armazenador de midia, e/ou da taxa de recepção para o armazenador de midia. Solicitações HTTP cooperativas usando FEC, isto é, o método FEC acima descrito e variantes desse método, podem ser usadas de forma agressiva quando o armazenador de midia está relativamente vazio, por exemplo, mais solicitações HTTP cooperativas são efetuados em paralelo para as diferentes partes do primeiro fragmento, solicitando todo o fragmento fonte e uma fração relativamente grande dos dados de reparação do fragmento de reparação correspondente, e, então transitando para um número reduzido de solicitações HTTP simultâneas, solicitando porções maiores dos dados de midia por solicitação, e solicitando uma menor fração de dados de reparação, por exemplo, a transição para as 1, 2 ou 3 solicitações HTTP concorrentes, transitando para fazer solicitações de fragmentos completos ou vários fragmentos consecutivos por solicitação, e transitando para não solicitar nenhum dado de reparação, conforme o armazenador de midia cresce.

Como outro exemplo, a quantidade de dados de reparação de FEC pode variar como uma função do tamanho do armazenador de midia, isto é, quando o armazenador de mídia é pequeno, então mais dados de reparação de FEC podem ser solicitados, e conforme o armazenador de midia cresce então a quantidade de dados de reparação FEC solicitada pode diminuir, e em algum momento quando o armazenador de midia é suficientemente grande, então nenhum dado de reparação FEC pode ser solicitado, apenas dados de segmentos fonte de representações fonte. Os beneficios de tais técnicas melhoradas é que elas podem permitir que tempos de zapping de canal mais rápidos e mais consistentes, e mais resistência contra interrupções ou pausas de midia potenciais, enquanto ao mesmo tempo minimiza a quantidade de largura de banda adicional usada além da quantidade que seria consumida apenas entregando a midia nos segmentos fonte, reduzindo o tráfego de mensagem de solicitação e os dados de reparação FEC, enquanto ao mesmo tempo, permitindo suportar as mais altas taxas de midia possivel para as condições da rede. Aprimoramentos Adicionais ao Usar Conexões HTTP simultâneas

Uma solicitação HTTP / TCP pode ser abandonada se uma condição adequada é atendida e outra solicitação HTTP / TCP pode ser feita para realizar download de dados que podem substituir os dados solicitados na solicitação abandonada, em que a segunda solicitação de HTTP / TCP pode solicitar exatamente os mesmos dados que na solicitação original, por exemplo, dados de base, ou de dados que se sobrepõem, por exemplo, alguns dos mesmos dados fonte e os dados de reparação que não tinham sido solicitados na primeira solicitação, ou dados completamente separados, por exemplo, dados de reparação que não tinham sido solicitados na primeira solicitação. Um exemplo de uma condição adequada é a de que uma solicitação falha devido à ausência de uma resposta de inf raestrutura de servidor de bloco (BSI) dentro de um tempo provido

ou uma falha no estabelecimento de uma conexão de transporte para a BSI ou a recepção de uma mensagem de falha explicita do servidor ou de outra condição de falha.

Outro exemplo de uma condição adequada é a de que a recepção de dados está prosseguindo de forma incomum lentamente, de acordo com uma comparação de uma medida da velocidade de conexão (taxa de dados de chegada, em resposta à solicitação em questão) com a velocidade de conexão esperada ou com uma estimativa da velocidade de conexão necessária para receber a resposta antes do tempo de reprodução dos dados de midia nela contida ou outro tempo dependente desse tempo.

Esta abordagem tem a vantagem de no caso em que a BSI, por vezes, apresenta falhas ou mau desempenho. Neste caso, a abordagem acima aumenta a probabilidade de que o cliente pode continuar reprodução fiável dos dados de midia apesar de falhas ou mau desempenho dentro da BSI. Note-se que em alguns casos, pode haver vantagem para projetar a BSI, de tal maneira que ela não exibe tais falhas ou mau desempenho em ocasiões, por exemplo um projeto tal pode ter um custo menor do que uma concepção alternativa que não exibe tais falhas ou mau desempenho ou que exibe estes com menos frequência. Neste caso, o método aqui descrito tem a vantagem adicional na medida em que permite a utilização de uma tal concepção a um custo mais baixo para a BSI sem uma consequente degradação na experiência de usuário.

Em outra modalidade, o número de solicitações emitidas para os dados correspondentes a um dado bloco pode ser dependente do fato de uma condição adequada em relação ao bloco ser satisfeita. Se a condição não for satisfeita, o cliente pode ser restringido de fazer novas solicitações para o bloco se a conclusão bem sucedida de todas as solicitações de dados atualmente incompletas para o bloco permitir a recuperação do bloco, com probabilidade alta. Se a condição for atendida, então um maior número de solicitações para o bloco pode ser emitido, ou seja, a restrição acima não se aplica. Um exemplo de uma condição 5 adequada é a de que o tempo até o tempo de reprodução programado do bloco ou de outro tempo dependente do daquele tempo cai abaixo de um limite provido. Este método tem a vantagem porque solicitações adicionais de dados para um bloco são emitidas quando a recepção do bloco torna-se mais 10 urgente, porque o tempo de reprodução dos dados de midia compreendendo o bloco está próximo. No caso de protocolos de transporte comuns, tais como HTTP / TCP, estas solicitações adicionais têm o efeito de aumentar a percentagem da largura de banda disponivel dedicada aos 15 dados que contribuem para a recepção do bloco em questão.

Isto reduz o tempo necessário para a recepção de dados suficiente para recuperar o bloco para completar e, por conseguinte, reduz a probabilidade de que o bloco não pode ser recuperado antes do tempo de reprodução programado para. 20 os dados de midia compreendendo o bloco. Como descrito acima, se o bloco não pode ser recuperado antes do tempo de reprodução programado dos dados de midia compreendendo o bloco então a reprodução pode pausar resultando em uma experiência de usuário ruim e, por conseguinte, o método 25 descrito aqui vantajosamente reduz a probabilidade desta experiência de usuário ruim.

Deve ser entendido que ao longo desta especificação referências ao tempo de reprodução programado de um bloco se refere ao tempo em que os dados de midia 30 codificados compreendendo o bloco podem ser primeiro disponíveis no cliente, a fim de alcançar reprodução da apresentação sem pausa. Como será claro para aqueles que são versados na técnica dos sistemas de apresentação de midia, este tempo é, na prática, um pouco antes do tempo real do aparecimento da midia que compreende o bloco com os transdutores fisicos utilizados para a reprodução (tela, altofalante. etc.), uma vez que várias funções de 5 transformação podem precisar de ser aplicadas aos dados de midia compreendendo o bloco para efetuar a reprodução real daquele bloco e estas funções podem exigir uma certa quantidade de tempo para completar. Por exemplo dados de midia são geralmente transportados em forma comprimida e 10 uma transformação de descompressão pode ser aplicada. Métodos para Gerar Estruturas de Arquivos que Suportam Métodos HTTP / FEC Cooperativos

Uma modalidade para gerar uma estrutura de arquivo que pode ser utilizada vantajosamente por um 15 cliente empregando métodos de HTTP / FEC cooperativos é agora descrita. Nesta modalidade, para cada segmento fonte há um segmento de reparação correspondente gerado como se segue. O parâmetro R indica, em média, a quantidade de dados de reparação FEC que são gerados paraos dados fonte 20 nos segmentos fonte. Por exemplo, R = 0,33 indica que, se um segmento fonte contém 1.000 kilobytes de dados, então o segmento de reparação correspondente contém cerca de 330 kilobytes de dados de reparação. O parâmetro S indica o tamanho do simbolo em bytes utilizados para codificação e 25 decodificação FEC. Por exemplo, S = 64 indica que os dados fontes e os dados de reparação compreendem simbolos de 64 bytes de tamanho cada, para efeitos de codificação e decodificação FEC.

O segmento de reparação pode ser gerado por um 30 segmento fonte da seguinte forma. Cada fragmento do segmento fonte é considerado como um bloco fonte para fins de codificação FEC, e, assim, cada fragmento é tratado como uma sequência de simbolos fonte de um bloco fonte a partir do qual os símbolos de reparação são gerados. 0 número de símbolos de reparação no total gerados para os primeiros i fragmentos é calculado como TNRS (i) = teto (R * B (i) / S) , em que teto (x) é a função que gera o menor número inteiro com um valor que é, pelo menos, x. Assim, o número de símbolos de reparação gerados para fragmento i é NRS (i) = TNRS (i) - TNRS (i-1).

O segmento de reparação compreende uma concatenação dos símbolos de reparação para os fragmentos, em que a ordem dos símbolos de reparação dentro de um segmento de reparação está na ordem dos fragmentos a partir do qual eles são gerados, e dentro de um fragmento os símbolos de reparação estão em ordem do seu identificador de símbolo de codificação (ESI). A estrutura do segmento de reparação que corresponde a uma estrutura de segmento fonte é mostrada na figura 27, incluindo um gerador de segmento de reparação 2700.

Note-se que definindo o número de símbolos de reparação de um fragmento, tal como descrito acima, o número total de símbolos de reparação para todos os fragmentos anteriores, e assim o índice de byte para o segmento de reparação, depende apenas de R, S, B (i-1) e B (i), e não depende de nenhuma da estrutura anterior ou posterior dos fragmentos dentro do segmento fonte. Isto é vantajoso porque permite que um cliente calcule rapidamente a posição do início de um bloco de reparação dentro do segmento de reparação, e também rapidamente calcule o número de símbolos de reparação dentro desse bloco de reparação, utilizando apenas uma informação local sobre a estrutura do fragmento correspondente do segmento fonte a partir do qual o bloco de reparação é gerado. Assim, se um cliente decide começar a baixar e reproduzir um fragmento a partir do meio de um segmento fonte, ele também pode rapidamente gerar e acessar o bloco de reparação correspondente dentro do segmento de reparação correspondente.

O número de símbolos fonte no bloco fonte correspondente ao fragmento i é calculado como NSS (i) = teto ( (B i)-B(i-1))/S) . 0 último símbolo fonte é preenchido com zero bytes, para efeitos de codificação e decodificação FEC se B(i)-B(i-1) não é um múltiplo de S, isto é, o último símbolo fonte é preenchido com zero bytes de modo que ele é S bytes em tamanho para efeitos de codificação e decodificação FEC, mas estes bytes de preenchimento de zero não são armazenados como parte do segmento fonte. Nesta modalidade, o ESIs para o símbolo fonte são 0, 1, ..., NSS (i)-l e o ESIs para os símbolos de reparação são NSS (i) , ..., NSS (í) + NRS (i)-1.

O URL para um segmento de reparação nesta modalidade pode ser gerado a partir do URL para o segmento fonte correspondente simplesmente adicionando, por exemplo, o sufixo "Reparação” ao URL do segmento fonte.

A informação de indexação de reparação e informação de FEC para um segmento de reparação é implicitamente definida indexando informações para o segmento fonte correspondente e, a partir dos valores de R e S, como aqui descrito. Os desvio de tempo e a estrutura de fragmento compreendendo o segmento de reparação, são determinadas pelos desvios de tempo e a estrutura do segmento fonte correspondente. O desvio de byte para o fim dos símbolos de reparação no segmento de reparação correspondente ao fragmento i pode ser calculado como RB (i) = S * teto (R*B(i)/S). O número de bytes no segmento de reparação correspondente ao fragmento i é então RB(i) - RB (i-1), e, assim, o número de símbolos correspondentes ao fragmento de reparação i é calculado como NRS (i) = (RB (i) - RB(i-l))/S. 0 número de simbolos fonte correspondentes ao fragmento i pode ser calculado como NSS (i) = teto ((B (i)- B(i-1))/S). Assim, nesta modalidade, as informações de indexação de reparação de um bloco de reparação dentro de 5 um segmento de reparação e a informação FEC correspondente podem ser implicitamente derivadas de R, Se as informações de indexação para o fragmento correspondente do segmento fonte correspondente.

Como exemplo, considere o exemplo mostrado na 10 figura 28, mostrando um fragmento 2 que começa no desvio de byte B (1) = 6410 e termina no desvio de byte B (2) = 6770. Neste exemplo, o tamanho do simbolo é S = 64 bytes, e as linhas pontilhadas verticais mostram os desvios de byte dentro do segmento fonte que correspondem a múltiplos de S.

O tamanho do segmento de reparação global como uma fração do tamanho do segmento fonte é definido para R = 0,5 neste exemplo. O número de simbolos fonte no bloco fonte para fragmento 2 é calculado como NSS (2) = teto ((6,770-6,410) / 64) = teto (5,625) = 6, e estes 6 simbolos fonte têm ESIS 20 0, ... , 5, respectivamente, em que o primeiro simbolo fonte é os primeiros 64 bytes de fragmento 2 que começa no indice de byte 6410 dentro do segmento fonte, o segundo simbolo fonte é os próximos 64 bytes do fragmento 2 que começa no indice de byte 6474 dentro do segmento fonte, etc. O desvio de byte final do bloco de reparação correspondente ao fragmento 2 é calculado como RB (2) = 64 * teto (0,5 * 6770/64) = 64 * teto (52,89 ...) =64*53= 3392 e o desvio de byte inicial do bloco de reparação correspondente ao fragmento 2 é calculado como RB (1) = 64 30 * teto (0,5 * 6410/64) =64* teto (50,07 ...) =64*51= 3264, e assim, neste exemplo, existem dois simbolos de reparação no bloco de reparação correspondentes ao fragmento 2 com ESIS 6 e 7, respectivamente, iniciando no desvio de byte 3264 dentro do segmento de reparação e terminando no desvio de byte 3392.

Note-se que, no exemplo mostrado na figura 28, embora R = 0,5 e existam 6 simbolos fonte correspondentes ao fragmento 2, o número de simbolos de reparação não é 3, como se poderia esperar se alguém simplesmente usou o número de simbolos fonte para calcular o número de simbolos de reparação, mas em vez disso trabalhou-se para ser 2 de acordo com os métodos aqui descritos. Em oposição a simplesmente usar o número de simbolos fonte de um fragmento para determinar o número de simbolos de reparação, as modalidades acima descritas tornam possivel calcular o posicionamento do bloco de reparação dentro do segmento de reparação unicamente a partir da informação do indice associado com o bloco fonte correspondente do segmento fonte correspondente. Além disso, conforme o número, K, de simbolos fonte em um bloco fonte cresce, o número de simbolos de reparação, KR, do bloco de reparação correspondente está intimamente aproximado por K * R, como em geral, KR é no máximo teto (K ★ R) e KR é pelo menos piso((K-l) * R), onde piso(x) é o maior número inteiro que é no máximo x.

Há muitas variações das modalidades acima para gerar uma estrutura de arquivo que pode ser utilizada vantajosamente por um cliente empregando métodos de HTTP / FEC cooperativos, tal como um versado na técnica irá reconhecer. Como um exemplo de uma modalidade alternativa, um segmento original para uma representação pode ser dividido em N > 1 segmentos paralelos, em que para i = 1, . . . , N, uma fração especificada Fi do segmento original está contida no i-ésimo segmento paralelo, e onde a soma para i = 1, . . . , N de Fj é igual a 1. Nesta modalidade, pode haver um mapa de segmento principal que é utilizado para derivar os mapas de segmento para todos os segmentos paralelos, semelhantes à forma como o mapa de segmento de reparação é derivado a partir do mapa de segmento fonte na modalidade acima descrita. Por exemplo, o mapa de segmento principal pode indicar a estrutura de fragmento se todos os dados de midia fonte não foram particionados em segmentos paralelos, mas em vez disso contidos no segmento de um original, e, então o mapa de segmento para i-ésimo segmento paralelo pode ser derivado a partir do mapa de segmento principal através do cálculo que, se a quantidade de dados de midia em um primeiro prefixo de fragmentos do segmento original é L bytes, então o número total de bytes deste prefixo em agregado entre o primeiro segmento paralelo i é teto (L * Gi) , onde Gt é a soma sobre j = 1, . .., i de Fj. Como outro exemplo de uma modalidade alternativa, os segmentos podem consistir em uma combinação de dados de midia fontes originais para cada fragmento seguido imediatamente pelos dados de reparação para aquele fragmento, resultando em um segmento que contém uma mistura de dados de midia fonte e dados de reparação gerados utilizando um código FEC a partir daqueles dados de midia fonte. Como outro exemplo de uma modalidade alternativa, um segmento que contém uma mistura de dados de midia fonte e dados de reparação pode ser dividido em múltiplos segmentos paralelos que contêm uma mistura de dados de midia fonte e dados de reparação.

Modalidades adicionais podem ser previstas por versado na técnica comum após a leitura desta descrição. Em outras modalidades, combinações ou subcombinações da invenção acima descrita pode ser vantajosamente feita. Os arranjos exemplares de componentes são mostrados para fins de ilustração e devem ser entendidos que as combinações, adições, rearranjos, e similares, são contemplados em modalidades alternativas da presente invenção. Assim, enquanto a invenção for descrita com respeito a modalidades exemplares, um versado na técnica irá reconhecer que numerosas modificações são possiveis.

Por exemplo, os processos aqui descritos podem ser implementados usando componentes de hardware, componentes de software, e/ou qualquer combinação destes. Em alguns casos, os componentes de software podem ser providos em midia tangivel e não-transitória para execução 10 em hardware que é provida com a midia ou é separada da midia. A especificação e os desenhos devem, por conseguinte, ser considerados em um sentido ilustrativo em vez de restritivo. Irá ser, no entanto, evidente que várias modificações e alterações podem ser feitas a isso sem se 15 afastar do mais amplo escopo e espirito da invenção conforme apresentado nas reivindicações e que a invenção se destina a cobrir todas as modificações e equivalentes dentro do escopo das seguintes reivindicações.

Claims (14)

1. Método para uso em um sistema de comunicação em que um dispositivo cliente (108) solicita arquivos de mídia a partir de um sistema de ingestão de mídia, caracterizado pelo fato de que compreende: receber, por um dispositivo cliente (108), um arquivo de descrição de apresentação de mídia (500) contendo um identificador de representação, índices de arquivo, e uma regra de construção de identificador de arquivo, em que um índice de arquivo é o número de sequência do arquivo na representação identificada pelo identificador de representação e em que a regra de construção de identificador de arquivo fornece informação que permite ao dispositivo cliente (108) construir dinamicamente identificadores de arquivo de mídia dos arquivos de mídia com dados de mídia requeridos usando o identificador de representação e um ou mais dos índices de arquivo; construir (123), no dispositivo cliente (108), um identificador de arquivo de um arquivo de mídia com base na regra de construção de identificador de arquivo recebido usando o identificador de representação e pelo menos um dos índices de arquivo; e enviar (124) uma solicitação (112) para o arquivo de mídia para o sistema de ingestão de mídia (103), em que a solicitação compreende o identificador de arquivo construído com base na regra de construção de identificador de arquivo.

2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende adicionalmente: receber dados adicionais associados com cada elemento do arquivo de descrição de apresentação de mídia indicando um intervalo de tempo dentro do qual o elemento é considerado válido, e, do contrário, o elemento é ignorado.

3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que uma regra de construção de identificador de arquivo compreende uma string de texto que contém identificadores especiais correspondendo a parâmetros de entrada.

4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que compreende adicionalmente: determinar posições dos identificadores especiais dentro da string de texto, e substituir cada identificador especial com uma representação de string de um valor do parâmetro de entrada correspondente.

5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a regra de construção de identificador de arquivo compreende uma string de texto conformando a uma linguagem de expressão compreendendo um definição de uma sintaxe à qual expressões na linguagem se conforma e um conjunto de regras para avaliar uma string que se conforma à sintaxe.

6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a solicitação é uma solicitação HTTP.

7. Aparelho, em um sistema de comunicação em que um dispositivo cliente (108) solicita arquivos de mídia a partir de um sistema de ingestão de mídia, caracterizado pelo fato de que compreende: meios para receber, no dispositivo cliente (108), um arquivo de descrição de apresentação de mídia (500) contendo um identificador de representação, índices de arquivo, e uma regra de construção de identificador de arquivo, em que um índice de arquivo é o número de sequência do arquivo na representação identificada pelo identificador de representação e em que a regra de construção de identificador de arquivo fornece informação que permite ao dispositivo cliente (108) construir dinamicamente identificadores de arquivo de mídia dos arquivos de mídia com dados de mídia requeridos usando o identificador de representação e um ou mais dos índices de arquivo; meios para construir, no dispositivo cliente (108), um identificador de arquivo de um arquivo de mídia com base na regra de construção de identificador de arquivo recebido usando o identificador de representação e pelo menos um dos índices de arquivo; e meios para enviar uma solicitação (112) para o arquivo de mídia para o sistema de ingestão de mídia (103), em que a solicitação compreende o identificador de arquivo construído com base na regra de construção de identificador de arquivo.

8. Método para uso em um sistema de comunicação em que um dispositivo cliente (108) solicita arquivos de mídia partir de um sistema de ingestão de mídia (103), caracterizado pelo fato de que compreende: prover um arquivo de descrição de apresentação de mídia (500) contendo um identificador de representação, índices de arquivo, e uma regra de construção de identificador de arquivo, em que um índice de arquivo é o número de sequência do arquivo na representação identificada pelo identificador de representação e em que a regra de construção de identificador de arquivo fornece informação que permite ao dispositivo cliente (108) construir dinamicamente identificadores de arquivo de mídia dos arquivos de mídia com dados de mídia requeridos usando o identificador de representação e um ou mais dos índices de arquivo; e receber, no sistema de ingestão de mídia (103), uma solicitação (112) para o arquivo de mídia, em que a solicitação compreende um identificador de arquivo construído com base na regra de construção de identificador de arquivo usando o identificador de representação e pelo menos um dos índices de arquivo.

9. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que compreende adicionalmente: prover dados adicionais associados com cada elemento do arquivo de descrição de apresentação de mídia indicando um intervalo de tempo dentro do qual o elemento é considerado válido, e, do contrário, o elemento é ignorado.

10. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que uma regra de construção de identificador de arquivo compreende uma string de texto que contém identificadores especiais correspondendo a parâmetros de entrada.

11. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que a regra de construção de identificador de arquivo compreende uma string de texto conformando a uma linguagem de expressão compreendendo uma definição de uma sintaxe à qual expressões na linguagem se conforma e um conjunto de regras para avaliar uma string que se conforma à sintaxe.

12. Método, de acordo com a reivindicação 8, caracterizado pelo fato de que a solicitação é uma solicitação HTTP.

13. Aparelho em um sistema de comunicação em que um dispositivo cliente (108) solicita arquivos de mídia a partir de um sistema de ingestão de mídia, caracterizado pelo fato de que compreende: meios para prover um arquivo de descrição de apresentação de mídia (500) contendo um identificador de representação, índices de arquivo, e uma regra de construção de identificador de arquivo, em que um índice de arquivo é o número de sequência do arquivo na representação identificada pelo identificador de representação e em que a regra de construção de identificador de arquivo fornece informação que permite ao dispositivo cliente (108) construir dinamicamente identificadores de arquivo de mídia dos arquivos de mídia com dados de mídia requeridos usando o identificador de representação e um ou mais dos índices de arquivo; e meios para receber, no sistema de ingestão de mídia (103), uma solicitação (112) para o arquivo de mídia, em que a solicitação (112) compreende um identificador de arquivo construído com base na regra de construção de identificador de arquivo usando o identificador de representação e pelo menos um dos índices de arquivo.

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

Images