BR112012006377B1 - streaming de solicitação de bloco aperfeiçoado utilizando codificação escalonável - Google Patents

Abstract

STREAMING DE SOLICITAÇÃO DE BLOCO APERFEIÇOADO UTILIZANDO CODIFICAÇÃO ESCALONÁVEL Um sistema de sequenciamento de solicitação de bloco fornece aperfeiçoamentos na experiência de usuário e eficiência de largura de banda de tais sistemas, tipicamente utilizando um sistema de ingestão que gera dados em uma forma a ser servidora por um servidor de arquivo convencional (HTTP, FTP ou similar), onde o sistema de ingestão recebe conteúdo e prepara o mesmo como arquivos ou elementos de dados para serem servidos pelo servidor de arquivo. Um dispositivo de cIiente pode ser adaptado para tirar vantagem do processo de ingestão além de incluir aperfeiçoamentos que melhoram a apresentação independentemente do processo de ingestão. Os arquivos ou elementos de dados são organizados como bloco"' que são transmitidos e decodificados como uma unidade, e o sistema é configurado para fornecer e consumir blocos escalonáveis de modo que a qualidade da apresentação aumente à medida que mais blocos são descarregados. A codificação e decodificação de blocos com múltiplas camadas de capacidade de escalonamento independentes podem ser realizadas também

Description

Referências Cruzadas a Pedidos Relacionados

[0001] Esse pedido é um pedido de patente não provisório reivindicando os benefícios sob os seguintes pedidos provisórios, cada um nomeando Michael G. Luby, et al., e cada um intitulado "Enhanced Block-Request Streaming System": Pedido de patente provisório U.S. No. 61/244.767, depositado em 22 de setembro de 2009; Pedido de patente provisório U.S. No. 61/257.719, depositado em 3 de novembro de 2009; Pedido de patente provisório U.S. No. 61/258.088, depositado em 4 de novembro de 2009; Pedido de patente provisório U.S. No. 61/285.779, depositado em 11 de dezembro de 2009; e Pedido de patente provisório U.S. No. 61/296.725, depositado em 20 de janeiro de 2010.

[0002] Esse pedido também reivindica os benefícios sob o pedido de patente provisório U.S. No. 61/372.399, depositado em 10 de agosto de 2010, nomeando Ying Chen, et al. e intitulado "HTTP Streaming Extensions".

[0003] Cada pedido provisório citado acima é incorporado aqui por referência para todas as finalidades. A presente descrição também incorpora por referência, como se tivessem sido apresentados por completo nesse documento, para todas as finalidades, os pedidos/patente comumente cedidos a seguir: Patente U.S. No. 6.307.487 de Luby (doravante "Luby I"); Patente U.S. No. 7.068.729 de Shokrollahi, et al. (doravante, Shokrollahi I"); Pedido de patente U.S. No. 11/423.391, depositado em 9 de junho de 2006 e intitulado "Forward ErrorCorrecting (FEC) Coding and Streaming" nomeando Luby, et al. (doravante "Luby II"); Pedido de patente U.S. No. 12/103.605, depositado em 15 de abril de 2008, intitulado "Dynamic Stream Interleaving and Sub-Stream Based Delivery" nomeando Luby, et al., (doravante "Luby III"); Pedido de patente U.S. No. 12/705.202, depositado em 12 de fevereiro de 2010, intitulado "Block Partitioning for a Data Stream" nomeando Pakzad, et al. (doravante "Pakzad"); e Pedido de patente U.S. No. 12/859.161, depositado em 18 de agosto de 2010, intitulado "Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes" nomeando Luby, et al. (doravante "Luby IV").

Campo da Invenção

[0004] A presente invenção refere-se a sistemas de sequenciamento de mídia aperfeiçoados e métodos, mais particularmente a sistemas e métodos que são adaptativos à rede e condições de armazenamento a fim de otimizar uma apresentação de mídia seqüenciada e permite uma distribuição temporal e simultânea eficiente de dados de mídia seqüenciados.

Fundamentos da Invenção

[0005] A distribuição de mídia seqüenciada pode se tornar cada vez mais importante à medida que se torna mais comum para áudio e vídeo de alta qualidade a serem distribuídos através de redes com base em pacote, tal como a Internet, redes celulares e sem fio, redes de linha de energia e outros tipos de rede. A qualidade com a qual a mídia de sequenciamento distribuída pode ser apresentada pode depender de vários 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 recebimento em decodificar e apresentar a mídia, a timeliness e qualidade de sinal recebido nos receptores, etc. Para se criar uma boa experiência de mídia de sequenciamento, transporte e timeliness do sinal recebido nos receptores podem ser especialmente importantes. Bom transporte pode fornecer fidelidade da sequência recebida no receptor com relação ao que um remetente envia, enquanto timeliness pode representar quão rapidamente um receptor pode começar a reproduzir o conteúdo depois de uma solicitação inicial por esse conteúdo.

[0006] Um sistema de distribuição de mídia pode ser caracterizado como um sistema possuindo fontes de mídia, destinos de mídia, e canais (em tempo e/ou espaço) separando fontes e destinos. Tipicamente, uma fonte inclui um transmissor com acesso à mídia na forma eletronicamente gerenciável, e um receptor com uma capacidade de controlar eletronicamente o recebimento da mídia (ou uma aproximação da mesma) e fornecer a mesma para um consumidor de mídia (por exemplo, um usuário possuindo um dispositivo de exibição acoplado de alguma forma ao receptor, um dispositivo de armazenamento ou elemento, outro canal, etc.).

[0007] Enquanto muitas variações são possíveis, em um exemplo comum, um sistema de distribuição de mídia possui um ou mais servidores que possuem acesso ao conteúdo de mídia na forma eletrônica, e um ou mais sistemas ou dispositivos de cliente realizam solicitações por mídia para os servidores, e os servidores transportam mídia utilizando um transmissor como parte do servidor, transmitindo para 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 determinada solicitação e resposta, mas esse não precisa ser o caso.

[0008] Tradicionalmente, os sistemas de distribuição de mídia podem ser caracterizados em um modelo de "download" ou modelo de "sequenciamento". O modelo de "download" pode ser caracterizado pela temporização de independência entre a distribuição de dados de mídia e a reprodução da mídia para o dispositivo de usuário ou recipiente.

[0009] Como um exemplo, a mídia é descarregada de antemão o suficiente quando é necessária ou será utilizada e quando é utilizada, tanto quanto necessário se já estiver disponível no recipiente. A distribuição no contexto de download é frequentemente realizada utilizando-se um protocolo de transporte de arquivo, tal como HTTP, FTP ou Distribuição de Arquivo através de Transporte Unidirecional (FLUTE) e a taxa de distribuição pode ser determinada por um protocolo de controle de fluxo e/ou congestionamento subjacente, tal como TCP/IP. A operação do protocolo de controle de fluxo ou congestionamento pode ser independente da reprodução de mídia para o dispositivo de usuário ou de destino, o que pode ocorrer simultaneamente com o download ou em algum outro momento.

[0010] O modo de "sequenciamento" pode ser caracterizado por um acoplamento justo entre a temporização da distribuição dos dados de mídia e a reprodução de mídia para o dispositivo de usuário ou recipiente. A distribuição nesse contexto é frequentemente realizada utilizando-se um protocolo de sequenciamento, tal como o Protocolo de Sequenciamento em Tempo Real (RTSP) para controle e Protocolo de Transporte Em Tempo Real (RTP) para dados de mídia. A taxa de distribuição pode ser determinada por um servidor de sequenciamento, frequentemente combinando a taxa de reprodução de dados.

[0011] Algumas desvantagens do modelo de "download" podem ser que, devido à independência de temporização da distribuição e reprodução, outros dados de mídia podem não estar disponíveis quando escassos, e consumindo recursos valiosos de rede para a distribuição que pode ser desperdiçada se o conteúdo não for, eventualmente, reproduzido ou de outra forma utilizado.

[0012] Uma vantagem do modelo de "download" pode ser que a tecnologia necessária para realizar tais downloads, por exemplo, HTTP, é muito madura, amplamente desenvolvida e aplicável através de uma ampla faixa de aplicativos. Servidores de download e soluções para a capacidade de escalonamento massiva de tais downloads de arquivo (por exemplo, Servidores de Rede HTTP e Redes de Distribuição de Conteúdo) podem ser prontamente disponíveis, tornando o desenvolvimento dos serviços com base nessa tecnologia simples e barato.

[0013] Algumas desvantagens do modelo de "sequenciamento" podem ser que geralmente a taxa de distribuição de dados de mídia não é adaptada à largura de banda disponível na conexão entre servidor e cliente e que servidores de sequenciamento especializados ou arquitetura de rede mais complexa fornecendo largura de banda e garantias de retardo são necessários. Apesar de os sistemas de sequenciamento existirem e suportarem a variação da taxa de dados de distribuição de acordo com a largura de banda disponível (por exemplo, Sequenciamento Adaptativo Adobe Flash), esses são geralmente ineficientes como protocolos de controle de fluxo de transporte de download tal como TCP na utilização de toda a largura de banda disponível.

[0014] Recentemente, novos sistemas de distribuição de mídia com base em uma combinação de modelos de "sequenciamento" e "download" foram desenvolvidos. Um exemplo de tal modelo é referido aqui como modelo de "sequenciamento de solicitação de bloco", onde um cliente de mídia solicita os blocos de dados de mídia a partir da infraestrutura servidora utilizando um protocolo de download, tal como HTTP. Uma preocupação com tais sistemas pode ser a capacidade de iniciar a reprodução de uma sequência, por exemplo, a decodificação e criação de sequências de áudio e vídeo recebidas utilizando um computador pessoal e exibindo o vídeo em uma tela de computador e reproduzindo o áudio através de alto falantes embutidos, ou como outro exemplo, decodificando e criando sequências de áudio e vídeo recebidas utilizando uma caixa decodificadora e exibindo o vídeo em um dispositivo de monitor de televisão e reproduzindo o áudio através de um sistema estéreo.

[0015] Outras preocupações, tal como ser capaz de decodificar os blocos fonte rápido o suficiente para acompanhar a taxa de sequenciamento de fonte, para minimizar a latência de decodificação e para reduzir o uso de recursos de CPU disponíveis são problemas. Outra preocupação é se fornecer uma solução de distribuição de sequenciamento robusta e escalonável que permita que os componentes do sistema falhem sem afetar de forma adversa a qualidade das sequências distribuídas para os receptores. Outros problemas podem ocorrer com base na mudança rápida da informação sobre uma apresentação, à medida que está sendo distribuída. Dessa forma, é desejável se ter processos e aparelho aperfeiçoados.

Breve Sumário da Invenção

[0016] Um sistema de sequenciamento de solicitação de bloco fornece aperfeiçoamentos na experiência de usuário e eficiência de largura de banda de tais sistemas, tipicamente utilizando um sistema de ingestão que gera dados em uma forma a ser servida por um servidor de arquivo convencional (HTTP, FTP, ou similar), onde o sistema de ingestão recolhe conteúdo e prepara o mesmo como arquivos ou elementos de dados a serem servidos pelo servidor de arquivo, que pode ou não incluir um armazenador temporário. Um dispositivo de cliente pode ser adaptado para levar vantagem do processo de ingestão além de incluir aperfeiçoamentos que criam uma apresentação melhor independentemente do processo de ingestão. Os arquivos ou elementos de dados são organizados como blocos que são transmitidos e decodificados como uma unidade, e o sistema é configurado para fornecer e consumir blocos escalonáveis de modo que a qualidade da apresentação aumente à medida que mais do bloco é descarregado. Em algumas modalidades, aperfeiçoamentos novos aos métodos de codificação e decodificação de blocos com múltiplas camadas de capacidade de escalonamento independentes são fornecidos.

[0017] A descrição detalhada a seguir juntamente com os desenhos em anexo fornecerão uma melhor compreensão da natureza e das vantagens da presente invenção.

Breve Descrição dos Desenhos

[0018] A figura 1 apresenta elementos de um sistema de sequenciamento de solicitação de bloco de acordo com as modalidades da presente invenção;

[0019] A figura 2 ilustra um sistema de sequenciamento de solicitação em bloco da figura 1, ilustrando maiores detalhes nos elementos de um sistema de cliente que é acoplado a uma infraestrutura servidora de bloco ("BSI") para receber dados que são processados por um sistema de ingestão de conteúdo ;

[0020] A figura 3 ilustra uma implementação de hardware/software de um sistema de ingestão;

[0021] A figura 4 ilustra uma implementação de hardware/software de um sistema de cliente;

[0022] A figura 5 ilustra possíveis estruturas do armazenador de conteúdo ilustrado na figura 1, incluindo segmentos e arquivos de descritor de apresentação de mídia ("MPD") e uma quebra das segmentos, temporização e outra estrutura dentro de um arquivo MPD;

[0023] A figura 6 ilustra detalhes de um segmento fonte típico, como pode ser armazenado no armazenador de conteúdo ilustrado nas figuras 1 e 5;

[0024] As figuras 7a e 7b ilustram indexação simples e hierarquizada dentro dos arquivos;

[0025] A figura 8a ilustra um dimensionamento de bloco variável com pontos de busca alinhados através de uma pluralidade de versões de uma sequência de mídia;

[0026] A figura 8b ilustra dimensionamento de bloco variável com pontos de busca não alinhados através de uma pluralidade de versões de uma sequência de mídia;

[0027] A figura 9a ilustra uma Tabela de Metadados;

[0028] A figura 9b ilustra a transmissão de Tabela de Blocos e Metadados do servidor para o cliente;

[0029] A figura 10 ilustra blocos que são independentes dos limites RAP;

[0030] A figura 11 ilustra a temporização contínua e descontínua através de segmentos;

[0031] A figura 12 é uma figura ilustrando um aspecto de blocos escalonáveis;

[0032] A figura 13 ilustra uma representação gráfica da evolução de determinadas variáveis dentro de um sistema de sequenciamento de solicitação de bloco através do tempo;

[0033] A figura 14 apresenta outra representação gráfica da evolução de determinadas variáveis dentro de um sistema de sequenciamento de solicitação de bloco com o tempo;

[0034] A figura 15 apresenta uma grade de célula de estados como uma função dos valores limite;

[0035] A figura 16 é um fluxograma de um processo que pode ser realizado em um receptor que pode solicitar blocos singulares e múltiplos blocos por solicitação;

[0036] A figura 17 é um fluxograma de um processo de sequenciamento flexível;

[0037] A figura 18 ilustra um exemplo de um conjunto candidato de solicitações, suas prioridades, e quais conexões nas quais podem ser emitidas, em um determinado momento;

[0038] A figura 19 ilustra um exemplo de um conjunto candidato de solicitações, suas prioridades, e quais conexões nas quais podem ser emitidas, que tenha evoluído a partir de um momento para outro;

[0039] A figura 20 é um fluxograma de seleção de proxy servidor de armazenamento temporário com base em um identificador de arquivo;

[0040] A figura 21 ilustra uma definição de sintaxe para uma linguagem de expressão adequada;

[0041] A figura 22 ilustra um exemplo de uma função hash adequada;

[0042] A figura 23 ilustra exemplos de regras de construção de identificador de arquivo;

[0043] As figuras 24(a) a 24(c) ilustram as flutuações de largura de banda das conexões TCP;

[0044] A figura 25 ilustra múltiplas solicitações HTTP para dados fonte e de reparo;

[0045] A figura 26 ilustra um tempo de zapping de canal ilustrativo com e sem FEC;

[0046] A figura 27 ilustra detalhes de um gerador de segmento de reparo que, como parte do sistema de ingestão ilustrado na figura 1, gera segmentos de reparo a partir dos segmentos fonte e parâmetros de controle;

[0047] A figura 28 ilustra as relações entre os blocos fonte e os blocos de reparo;

[0048] A figura 29 ilustra um procedimento para serviços ao vivo em diferentes momentos no cliente.

[0049] Nas figuras, itens similares são referidos com referências similares e subíndices são fornecidos em parênteses para indicar múltiplos casos de itens similares ou idênticos. A menos que seja indicado de outra forma, o subíndice final (por exemplo, "N", ou "M") não deve ser limitador de qualquer valor em particular e o número de casos de um item pode diferir do número de casos de outro item mesmo quando o mesmo número é ilustrado e o subíndice é reutilizado.

Descrição Detalhada da Invenção

[0050] Como descrito aqui, um objetivo de um sistema de sequenciamento é mover a mídia de seu local de armazenamento (ou o local onde foi gerado) para um local onde está sendo consumido, isso é, apresentado para um usuário ou de outra forma "utilizado" por um consumidor humano ou eletrônico. De forma ideal, o sistema de sequenciamento pode fornecer a reprodução ininterrupta (ou mais geralmente, "consumo" ininterrupto) em uma extremidade de recebimento e pode começar a reproduzir uma sequência ou uma coleção de sequências logo depois de um usuário ter solicitado a sequência ou sequências. Por motivos de eficiência, é desejável também que cada sequência seja interrompida uma vez que o usuário indicar que a sequência não é mais necessária, tal como quando o usuário está mudando de uma sequência para outra sequência ou obedece à apresentação de uma sequência, por exemplo, a sequência de "subtítulo". Se o componente de mídia, tal como vídeo, continuar a ser apresentado, mas uma sequência diferente for selecionada para apresentar esse componente de mídia, é frequentemente preferível se ocupar a largura de banda limitada com nova sequência e interromper a sequência antiga.

[0051] Um sistema de sequenciamento de solicitação de bloco de acordo com as modalidades descritas aqui fornece muitos benefícios. Deve-se compreender que um sistema viável não precisa incluir todas as características descritas aqui, visto que algumas aplicações podem fornecer uma experiência adequadamente satisfatória com menos do que todas as características descritas aqui. Sequenciamento HTTP

[0052] O sequenciamento HTTP é um tipo específico de sequenciamento. Com o sequenciamento HTTP, as fontes podem ser servidores de rede padrão e redes de distribuição de conteúdo (CDNs) e podem utilizar HTTP padrão. Essa técnica pode envolver a segmentação de sequência e o uso de múltiplas sequências, todas dentro do contexto de solicitações HTTP padronizadas. A mídia, tal como vídeo, pode ser codificada em múltiplas taxas de bit para formar diferentes versões, ou representações. Os termos "versão" e "representação" são utilizados como sinônimos nesse documento. Cada versão ou representação pode ser dividida em pedaços menores, talvez da ordem de poucos segundos cada, para formar segmentos. Cada segmento pode então ser armazenado em um servidor da rede ou CDN como um arquivo separado.

[0053] No lado do cliente, as solicitações pode então ser feitas, utilizando HTTP, para segmentos individuais que são unidos sem junções pelo cliente. O cliente pode comutar para diferentes taxas de dados com base na largura de banda disponível. O cliente também pode solicitar múltiplas representações, cada uma apresentando um componente de mídia diferente, e pode apresentar a mídia nessas representações em conjunto e de forma sincronizada. Os acionadores para comutação podem incluir medições de rede e ocupação de armazenamento temporário, por exemplo, Quando da operação no estado estável, o cliente pode medir as solicitações para o servidor a fim de manter uma ocupação de armazenador temporário alvo.

[0054] As vantagens do sequenciamento HTTP podem incluir adaptação de taxa de bit, inicialização rápida e busca, e distribuição mínima desnecessária. Essas vantagens são provenientes do controle da distribuição para que esteja apenas um pouco adiantada com relação à reprodução, fazendo uso máximo da largura de banda disponível (através da mídia de taxa de bit variável), e otimizando a segmentação de sequência e procedimentos de cliente inteligentes.

[0055] Uma descrição de apresentação de mídia pode ser fornecida para um cliente de sequenciamento HTTP de modo que o cliente possa utilizar uma coleção de arquivos (por exemplo, em formatos especificados por 3GPP, chamados aqui de segmentos 3GP) para fornecer um serviço de sequenciamento para o usuário. Uma descrição de apresentação de mídia e possivelmente atualizações dessa descrição de apresentação de mídia, descrevem uma apresentação de mídia que é uma coleção estruturada de segmentos, cada um contendo componentes de mídia de modo que o cliente possa apresentar a mídia incluída de forma sincronizada e possa fornecer características avançadas, tal como busca, taxas de bit de comutação e apresentação conjunta de componentes de mídia em representações diferentes. O cliente pode utilizar a informação de descrição de apresentação de mídia de formas diferentes para o fornecimento do serviço. Em particular, a partir da descrição de apresentação de mídia, o cliente de sequenciamento HTTP pode determinar quais segmentos na coleção podem ser acessados de modo que os dados sejam úteis para a capacidade do cliente e o usuário dentro do serviço de sequenciamento.

[0056] Em algumas modalidades, a descrição de apresentação de mídia pode ser estática, apesar de os segmentos poderem ser criados dinamicamente. A descrição de apresentação de mídia pode ser a mais compacta possível para minimizar o acesso e tempo de download para o serviço. Outra conectividade de servidor dedicada pode ser minimizada, por exemplo, sincronização de temporização regular ou frequente entre cliente e servidor.

[0057] A apresentação de mídia pode ser construída para permitir acesso pelos terminais com diferentes capacidades, tal como acesso a diferentes tipos de rede de acesso, diferentes condições de rede atuais, tamanhos de exibição, taxas de bit de acesso e suporte de codec. O cliente pode então extrair a informação adequada para fornecer o serviço de sequenciamento para o usuário.

[0058] A descrição de apresentação de mídia também pode permitir a flexibilidade de desenvolvimento e compacidade de acordo com as exigências.

[0059] Em um caso mais simples, cada Representação Alternativa pode ser armazenada em um único arquivo 3GP, isso é, um arquivo em conformidade como definido em 3GPP TS 26.244, ou qualquer outro arquivo que esteja em conformidade com o formato de arquivo de mídia base ISO como definido em ISO/IEC 14496-12 ou especificações derivadas (tal como o formato de arquivo 3GP descrito na Especificação Técnica 3GPP 26.244). No restante desse documento, quando se faz referência a um arquivo 3GP, deve- se compreender que ISO/IEC 14496-12 e especificações derivadas podem mapear todas as características descritas para o formato de arquivo de mídia base ISO mais geral como definido em ISO/IEC 14496-12 ou quaisquer especificações derivadas. O cliente pode então solicitar uma parte inicial do arquivo para aprender sobre os metadados de mídia (que são tipicamente armazenados na caixa decodificadora de Filme, também referida como caixa "moov") juntamente com momentos de fragmento de filme e desvios de byte. O cliente pode então emitir solicitações de obtenção parcial HTTP para obter fragmentos de filme como necessário.

[0060] Em algumas modalidades pode ser desejável se dividir cada representação em vários segmentos. No caso de o formato de segmento ser baseado no formato de arquivo 3GP, então os segmentos contêm fatias de tempo não sobrepostas dos fragmentos do filme, chamadas de "divisão no sentido de tempo". Cada um desses segmentos pode conter múltiplos fragmentos de filme e cada um pode ser um arquivo 3GP válido por direito. Em outra modalidade a representação é dividida em um segmento inicial contendo os metadados (tipicamente uma caixa "moov" de Cabeçalho de Filme) e um conjunto de segmentos de mídia, cada um contendo dados de mídia e a concatenação de segmento inicial e qualquer segmento de mídia forma um arquivo 3GP válido além da concatenação do segmento inicial e todos os segmentos de mídia de uma representação formam um arquivo 3GP válido. Toda a apresentação pode ser formada pela reprodução de cada segmento por sua vez, mapeando os selos de tempo locais dentro do arquivo para o tempo de apresentação global de acordo com o momento inicial de cada representação.

[0061] Deve-se notar que por toda essa descrição referências a um "segmento" devem ser compreendidas como incluindo qualquer objeto de dados que seja total ou parcialmente construído ou lido a partir de um meio de armazenamento ou de outra forma obtido como resultado de uma solicitação de protocolo de download de arquivo, incluindo, por exemplo, uma solicitação HTTP. Por exemplo no caso de HTTP, os objetos de dados podem ser armazenados em arquivos reais residentes em um disco ou outro meio de armazenamento conectado a ou formando parte de um servidor HTTP, ou os objetos de dados podem ser construídos por um script CGI, ou outro programa executado dinamicamente, que seja executado em resposta à solicitação HTTP. Os termos "arquivo" e "segmento" são utilizados como sinônimos nesse documento a menos que especificado o contrário. No caso de HTTP, o segmento pode ser considerado como o corpo de entidade de uma resposta à solicitação HTTP.

[0062] Os termos "apresentação" e "item de conteúdo" são utilizados como sinônimos nesse documento. Em muitos exemplos, a apresentação é um áudio, vídeo ou outra apresentação de mídia que tenha um tempo de "reprodução" definido, mas outras variações são possíveis.

[0063] Os termos "bloco" e "fragmento" são utilizados como sinônimos nesse documento a menos que seja especificado o contrário e geralmente se referem à menor agregação de dados que é indexada. Com base na indexação disponível, um cliente pode solicitar diferentes partes de um fragmento em diferentes solicitações HTTP, ou pode solicitar um ou mais fragmentos consecutivos ou partes de fragmentos em uma solicitação HTTP. No caso onde o formato de arquivo de mídia de base ISO com base em segmentos ou formato de arquivo 3GP com base em segmentos são utilizados, um fragmento se refere tipicamente 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").

[0064] Aqui, uma rede portando dados é considerada baseada em pacote a fim de simplificar a descrição, com o reconhecimento que, depois da leitura dessa descrição, os versados na técnica possam aplicar as modalidades da presente invenção descrita aqui a outros tipos de redes de transmissão, tal como redes de sequência de bits contínua.

[0065] Aqui, os códigos FEC são considerados como fornecendo proteção contra tempos de distribuição de dados longos e variáveis, a fim de simplificar as descrições apresentadas aqui, com o reconhecimento que, depois da leitura dessa descrição, os versados na técnica podem aplicar modalidades da presente invenção a outros tipos de problemas de transmissão de dados, tal como uma corrupção de bit-flip de dados. Por exemplo, sem FEC, se a última parte de um fragmento solicitado chegar muito depois ou possuir alta variação em seu tempo de chegada com relação às partes anteriores do fragmento, então o tempo de zapping de conteúdo pode ser grande e variável, ao passo que a utilização de FEC e solicitações paralelas, apenas a maior parte dos dados solicitados para um fragmento precisa chegar antes de poder ser recuperado, reduzindo, assim, o tempo de zapping de conteúdo e a variação no tempo de zapping de conteúdo. Nessa descrição, pode ser considerado que os dados a serem codificados (isso é, dados fonte) foram divididos em "símbolos" de comprimento igual, que pode ter qualquer comprimento (até um único bit), mas símbolos podem ter comprimentos diferentes para diferentes partes dos dados, por exemplo, diferentes tamanhos de símbolo podem ser utilizados para diferentes blocos de dados.

[0066] Nessa descrição, a fim de simplificar as descrições apresentadas aqui, é considerado que o FEC seja aplicado a um "bloco" ou "fragmento" de dados em um momento, isso é, um "bloco" é um "bloco fonte" para fins de codificação e decodificação FEC. Um dispositivo de cliente pode utilizar a indexação de segmento descrita aqui para ajudar a determinar a estrutura do bloco fonte de um segmento. Os versados na técnica podem aplicar modalidades da presente invenção a outros tipos de estruturas de bloco fonte, por exemplo, um bloco fonte pode ser uma parte de um fragmento, ou englobar um ou mais fragmentos ou partes de fragmentos.

[0067] Os códigos FEC considerados para uso com o sequenciamento de solicitação de bloco são tipicamente códigos FEC sistemáticos, isso é, os símbolos fonte do bloco fonte podem ser incluídos como parte da codificação do bloco fonte e, dessa forma, os símbolos fonte são transmitidos. Como os versados na técnica reconhecerão, as modalidades descritas aqui se aplicam igualmente bem aos códigos FEC que não são sistemáticos. Um codificador FEC sistemático gera, a partir de um bloco fonte de símbolos fonte, algum número de símbolos de reparo e a combinação de pelo menos alguns dos símbolos fonte e de reparo são símbolos codificados que são enviados através do canal representando o bloco fonte. Alguns códigos FEC podem ser úteis para gerar de forma eficiente tantos símbolos de reparo quantos forem necessários, tal como "códigos adicionais de informação" ou "códigos fonte" e exemplos desses códigos incluem "códigos de reação em cadeia" e "códigos de reação em cadeia de múltiplos estágios". Outros códigos FEC tal como códigos Reed-Solomon podem praticamente gerar apenas um número limitado de símbolos de reparo para cada bloco fonte.

[0068] É considerado em muitos desses exemplos que um cliente é acoplado a um servidor de mídia ou uma pluralidade de servidores de mídia e o cliente solicita o sequenciamento de mídia através de um canal ou uma pluralidade de canais a partir do servidor de mídia ou pluralidade de servidores de mídia. No entanto, disposições mais envolvidas também são possíveis.

Exemplos de Benefícios

[0069] Com o sequenciamento de solicitação de bloco, o cliente de mídia mantém um acoplamento entre a temporização dessas solicitações de bloco e a temporização da reprodução de mídia para o usuário. Esse modelo pode reter as vantagens do modelo de "download" descrito acima, enquanto evita algumas das desvantagens que surgem do desacoplamento normal da reprodução de mídia da distribuição de mídia. O modelo de sequenciamento de solicitação de bloco faz uso dos mecanismos de controle de taxa e congestionamento disponíveis nos protocolos de transporte, tal como TCP, para garantir que a largura de banda máxima disponível seja utilizada para dados de mídia. Adicionalmente, a divisão da apresentação de mídia em blocos permite que cada bloco de dados de mídia codificados seja selecionado a partir de um conjunto de múltiplas codificações disponíveis.

[0070] Essa seleção pode ser baseada em vários critérios, incluindo a combinação de taxa de dados de mídia com a largura de banda disponível, mesmo quando a largura de banda disponível está mudando com o tempo, combinando a resolução de mídia ou complexidade de decodificação para capacidades de cliente ou configuração, ou combinando com preferências de usuário, tal como línguas. A seleção também pode incluir o download e apresentação de componentes auxiliares, tal como componentes de acessibilidade, closed captioning, legendas, vídeo em linguagem de sinais, etc. Exemplos de sistemas existentes utilizando o modelo de sequenciamento de solicitação de bloco incluem Move Networks™, Microsoft Smooth Streaming e Apple iPhone™ Streaming Protocol.

[0071] Comumente, cada bloco de dados de mídia pode ser armazenado em um servidor como um arquivo individual e então um protocolo, tal como HTTP, é utilizado, em conjunto com o software do servidor HTTP executado no servidor, para solicitar o arquivo como uma entrada. Tipicamente, o cliente recebe arquivos de metadados, que podem, por exemplo, estar em formato de Linguagem de Marcação Extensível (XML) ou em formato de texto de lista de reprodução ou no formato binário, que descreve as características da apresentação de mídia, tal como as codificações disponíveis (por exemplo, largura de banda necessária, resoluções, parâmetros de codificação, tipo de mídia, linguagem), tipicamente referidos como "representações" nesse documento, e a forma na qual as codificações foram divididas em blocos. Por exemplo, os metadados podem incluir um Localizador de Recurso Uniforme (URL) para cada bloco. Os URLs propriamente ditos podem fornecer um esquema tal como sendo pré-anexados à sequência HTTP:// para indicar que o protocolo que deve ser utilizado para acessar o recurso documentado é HTTP. Outro exemplo é ftp:// para indicar que o protocolo a ser utilizado é FTP.

[0072] Em outros sistemas, por exemplo, os blocos de mídia podem ser construídos "na hora" pelo servidor em resposta a uma solicitação do cliente que indica a parte da apresentação de mídia, em tempo, que é solicitada. Por exemplo, no caso de HTTP com esquema HTTP://, a execução da solicitação desse URL fornece uma resposta à solicitação que contém alguns dados específicos no corpo de entidade dessa resposta à solicitação. A implementação na rede sobre como gerar essa resposta á solicitação pode ser bem diferente, dependendo da implementação do servidor servindo tais solicitações.

[0073] Tipicamente, cada bloco pode ser decodificado independentemente. Por exemplo, no caso de mídia de vídeo, cada bloco pode começar com um "ponto de busca". Em alguns esquemas de codificação, um ponto de busca é referido como "Pontos de Acesso Randômicos" ou "RAPs", apesar de nem todos os RAPs poderem ser designados como um ponto de busca. De forma similar, em outros esquemas de codificação, um ponto de busca começa em um quadro de "Atualização de Dados Independentes", ou "IDR", no caso de codificação de vídeo H.264, apesar de nem todos os IDRs poderem ser designados como um ponto de busca. Um ponto de busca é uma posição na mídia de vídeo (ou outra) onde um decodificador pode começar a decodificar sem exigir quaisquer dados sobre os quadros anteriores ou dados ou amostras, como pode ser o caso onde um quadro ou amostra que está sendo decodificado foi codificado não de forma independente, mas como, por exemplo, a diferença entre o quadro atual e o quadro anterior.

[0074] Uma preocupação em tais sistemas pode ser a capacidade de se iniciar a reprodução de uma sequência, por exemplo, decodificação e criação de sequências de áudio e vídeo recebidas utilizando um computador pessoal e exibindo o vídeo em uma tela de computador e reproduzindo o áudio através de alto falantes embutidos, ou como outro exemplo de decodificação e criação de sequências de áudio e vídeo recebidas utilizando uma caixa decodificadora e exibindo o vídeo em um dispositivo de tela de televisão e reproduzindo o áudio através de um sistema estéreo. Uma preocupação principal pode ser minimizar o retardo entre quando um usuário decide assistir a um novo conteúdo distribuído como uma sequência e realiza a ação que expressa essa decisão, por exemplo, o usuário clica em um link dentro de uma janela do navegador ou no botão de reprodução de um dispositivo de controle remoto, e quando o conteúdo começa a ser exibido na tela do usuário, doravante chamado de "tempo de zapping de conteúdo". Cada uma dessas preocupações pode ser solucionada por elementos do sistema aperfeiçoado descrito aqui.

[0075] Um exemplo de zapping de conteúdo é quando um usuário está assistindo a um primeiro conteúdo distribuído através de uma primeira sequência e então o usuário decide assistir um segundo conteúdo distribuído através de uma segunda sequência e inicia uma ação para começar a assistir o segundo conteúdo. A segunda sequência pode ser enviada a partir do mesmo conjunto ou de um conjunto diferente de servi dores que a primeira sequência. Outro exemplo de zapping de conteúdo é quando um usuário está visitando um sítio da rede e decide começar a assistir um primeiro conteúdo distribuído por uma primeira sequência clicando em um link dentro da janela do navegador. De forma similar, um usuário pode decidir iniciar a reprodução do conteúdo não do começo, mas de algum ponto dentro da sequência. O usuário indica para seu dispositivo de cliente que busque uma posição no tempo e o usuário pode esperar que o tempo selecionado seja criado instantaneamente. A minimização do tempo de zapping de conteúdo é importante para se assistir a vídeos para permitir que os usuários tenham uma experiência de navegação de conteúdo rápida de alta qualidade quando busca e amostra uma mapa faixa de conteúdos disponíveis.

[0076] Recentemente, se tornou uma prática comum a utilização de códigos FEC para proteção da mídia de sequenciamento durante a transmissão. Quando enviadas através de uma rede em pacote, exemplos das quais incluem as redes de Internet e sem fio tal como as padronizadas pelos grupos tal como 3GPP, 3GPP2 e DVB, a sequência fonte é colocada em pacotes e é gerada ou disponibilizada, e, dessa forma, os pacotes podem ser utilizados para portar a sequência fonte ou de conteúdo a fim de ser gerada ou disponibilidade para os receptores.

[0077] Em uma aplicação típica de códigos FEC desses tipos de situação, um codificador pode utilizar um código FEC na criação de pacotes de reparo, que são então enviados em adição aos pacotes fonte originais contendo a sequência fonte. Os pacotes de reparo possuem uma propriedade que, quando a perda de pacote fonte ocorre, os pacotes de reparo recebidos podem ser utilizados para recuperar os dados contidos nos pacotes fonte perdidos. Os pacotes de reparo podem ser utilizados para recuperar o conteúdo de pacotes fonte perdidos que são totalmente perdidos, mas podem ser utilizados também para recuperar da perda de pacote parcial, pacotes de reparo totalmente recebidos ou mesmo pacotes de reparo parcialmente recebidos. Dessa forma, pacotes de reparo recebidos totalmente ou parcialmente podem ser utilizados para recuperar os pacotes fonte total ou parcialmente perdidos.

[0078] Em outros exemplos, outros tipos de corrupção podem ocorrer nos dados enviados, por exemplo, valores de bits podem ser mudados, e, dessa forma, os pacotes de reparo podem ser utilizados para corrigir tal corrupção e fornecer a recuperação mais precisa possível dos pacotes fonte. Em outros exemplos, a sequência fonte não é necessariamente enviada em pacotes discretos, mas, ao invés disso, podem ser enviados, por exemplo, como uma sequência de bits contínua.

[0079] Existe muitos exemplos de códigos FEC que podem ser utilizados para fornecer proteção de uma sequência fonte. Códigos Reed-Solomon são códigos bem conhecidos para correção de erro e eliminação em sistemas de comunicação. Para correção de eliminação através, por exemplo, de redes de dados em pacote, uma implementação eficiente bem conhecida de códigos Reed-Solomon utiliza matrizes Cauchy ou Vandermonde como descrito em L.Rizzo, "Effective Erasure Codes for Reliable Computer Communication Protocols", Computer Communication Revies, 27(2):24-36 (abril de 1997) (doravante "Rizzo") e Bloemer, et al., "An XOR-Based Erasure-Resilient Coding Scheme", Technical Report TR-95- 48, International Computer Science Institute, Berkeley, Califórnia (1995) (doravante "XOR-Reed-Solomon") ou em outro lugar.

[0080] Outros exemplos dos códigos FEC incluem códigos LDPC, códigos de reação em cadeia tal como os descritos em Luby I e códigos de reação em cadeia de múltiplos estágios tal como em Shokrollahi I.

[0081] Exemplos do processo de decodificação FEC para variações de códigos Reed-Solomon são descritos em Rizzo e XOR-Reed-Solomon. Nesses exemplos, a decodificação pode ser aplicada depois que os pacotes de dados fonte e de reparo suficientes foram recebidos. O processo de decodificação pode ser computacionalmente intenso e, dependendo dos recursos de CPU disponíveis, isso pode levar um tempo considerável para ser completado, com relação à duração de tempo abrangida pela mídia no bloco. O receptor pode levar em consideração essa duração de tempo necessária para decodificação quando do cálculo do retardo necessário entre o início da recepção da sequência de mídia e a reprodução da mídia. Esse retardo devido à decodificação é percebido pelo usuário como um retardo entre sua solicitação por uma sequência de mídia em particular e o início da reprodução. É, dessa forma, desejável se minimizar esse retardo.

[0082] Em muitas aplicações, os pacotes podem ser adicionalmente subdivididos em símbolos nos quais o processo FEC é aplicado. Um pacote pode conter um ou mais símbolos (ou menos de um símbolo, mas normalmente os símbolos não são divididos através de grupos de pacotes a menos que condições de erro entre os grupos de pacotes sejam conhecidas como altamente correlacionadas). Um símbolo pode ter qualquer tamanho, mas frequentemente o tamanho de um símbolo é quase igual ao tamanho do pacote. Os símbolos fonte são os símbolos que codificam os dados que devem ser transmitidos. Os símbolos de reparo são símbolos gerados a partir dos símbolos fonte, direta ou indiretamente que estão apresentados em adição aos símbolos fonte (isso é, os dados a serem transmitidos podem ser totalmente recuperados se todos os símbolos fonte estiverem disponíveis e nenhum dos símbolos de reparo estiver disponível).

[0083] Alguns códigos FEC podem ser baseados em bloco, visto que as operações de codificação dependem dos sim bolos que estão em um bloco e podem ser independentes dos símbolos que não estão no bloco. Com a codificação baseada em bloco, um codificador FEC pode gerar símbolos de reparo para um bloco a partir dos símbolos fonte nesse bloco, então mover par ao próximo bloco e não precisa ser referir aos símbolos fonte além dos para o bloco atual sendo codificado. Em uma transmissão, um bloco fonte compreendendo símbolos fonte pode ser representado por um bloco codificado compreendendo símbolos codificados (que podem ser alguns símbolos fonte, alguns símbolos de reparo ou ambos). Com a presença dos símbolos de reparo, nem todos os símbolos fonte são necessários em cada bloco codificado.

[0084] Para alguns códigos FEC, especialmente os códigos Reed-Solomon, o tempo de codificação e decodificação pode se tornar impraticável à medida que o número de símbolos codificado por bloco fonte cresce. Dessa forma, na prática, existe frequentemente um limite superior prático (255 é um limite prático aproximado para algumas aplicações) no número total de símbolos codificados que podem ser gerados por bloco fonte, especialmente em um caso típico onde o processo de codificação ou decodificação Reed-Solomon é realizado por hardware personalizado, por exemplo, os processos MPE-FEC que utilizam códigos Reed-Solomon incluídos como arte do padrão DVB-H para proteção de sequências contra perda de pacote são implementados em hardware especializado dentro de um telefone celular que é limitado a 255 símbolos codificados totais Reed-Solomon por bloco fonte. Visto que os símbolos precisam frequentemente ser colocados em cargas úteis de pacote separadas, isso cria um limite superior prático no comprimento máximo do bloco fonte sendo codificado. Por exemplo, se uma carga útil de pacote for limitada a 1024 bytes ou menos e cada pacote portar um símbolo codificado, então um bloco fonte codificado pode ter no máximo 255 kilobytes, e isso também, obviamente, um limite superior no tamanho do bloco fonte propriamente dito.

[0085] Outras preocupações, tal como ser capaz de decodificar os blocos fonte rápido o suficiente para acompanhar a taxa de sequenciamento fonte, para minimizar a latência de decodificação introduzida pela decodificação FEC, e para utilizar apenas uma pequena fração da CPU disponível no dispositivo de recebimento em qualquer momento durante a decodificação FEC são solucionadas pelos elementos descritos aqui, além de lidar com a necessidade de se fornecer uma solução de distribuição de sequenciamento robusta e escalonável que permita que os componentes do sistema falhem sem afetar de forma adversa a qualidade das sequências distribuídas para os receptores.

[0086] Um sistema de sequenciamento de solicitação de bloco precisa suportar as mudanças na estrutura ou metadados da apresentação, por exemplo, mudanças no número de codificações de mídia disponíveis ou mudanças nos parâmetros das codificações de mídia tal como taxa de bit, resolução, razão de aparência, codecs de áudio ou vídeo ou parâmetros de codec de mudanças em outros metadados tal como URLs associados com os arquivos de conteúdo. tais mudanças podem ser necessárias por várias razões incluindo a edição de conteúdo a partir de fontes diferentes tal como anúncio ou segmentos diferentes de uma apresentação maior, modificação dos URLs ou outros parâmetros que se tornam necessários como resultado das mudanças na infraestrutura servidora, por exemplo, devido às mudanças de configuração, falhas de equipamento ou recuperação das falhas de equipamento ou outras razões.

[0087] Existem métodos nos quais uma apresentação pode ser controlada por um arquivo de lista de reprodução atualizada continuamente. Visto que esse arquivo é continuamente atualizado, então pelo menos algumas das mudanças descritas acima podem ser feitas dentro dessas atualizações. Uma desvantagem de um método convencional é que os dispositivos de cliente devem recuperar continuamente, também referido como "pesquisa", o arquivo de lista de reprodução, colocando a carga na infraestrutura servidora e que esse arquivo não pode ser armazenado temporariamente por méis do que o intervalo de atualização, tornando a tarefa da infraestrutura servidora muito mais difícil. Isso é solucionado por elementos apresentados aqui de modo que as atualizações do tipo descrito acima sejam fornecidas sem a necessidade de pesquisa contínua por clientes para arquivo de metadados.

[0088] Outro problema, especialmente em serviços ao vivo, tipicamente conhecidos a partir da distribuição de difusão, é a falta de capacidade de o usuário em visualizar o conteúdo que foi difundido anteriormente ao momento em que o usuário se uniu ao programa. Tipicamente, a gravação pessoal local consome armazenamento local desnecessário ou não é possível visto que o cliente não sintonizou o programa ou esta proibido pelas regras de proteção de conteúdo. A gravação da rede e visualização de mudança de tempo é preferida, mas exige conexões individuais do usuário com o servidor e um protocolo de distribuição separado e infraestrutura com relação aos serviços ao vivo, resultando em infraestrutura duplicada e custos de servidor significativos. Isso também é solucionado pelos elementos descritos aqui.

Visão Geral do Sistema

[0089] Uma modalidade da invenção é descrita com referência à figura 1, que ilustra um diagrama simplificado de um sistema de sequenciamento de solicitação de bloco consubstanciando a invenção.

[0090] Na figura 1, um sistema de sequenciamento de bloco 100 é ilustrado, compreendendo a infraestrutura servidora de bloco ("BSI") 101 compreendendo, por sua vez, um sistema de ingestão 102 para ingerir o conteúdo 102, preparando esse conteúdo e o empacotamento do mesmo para serviço por um servidor de sequenciamento HTTP 104 pelo armazenamento do mesmo em um armazenador de conteúdo 110 que é acessível a ambos o sistema de ingestão 103 e o servidor de sequenciamento HTTP 104. Como ilustrado, o sistema 100 também pode incluir um armazenador temporário HTTP 106. Em operação, um cliente 108, tal como um cliente de sequenciamento HTTP, envia as solicitações 112 para o servidor de sequenciamento HTTP 104 e recebe respostas 114 do servidor de sequenciamento HTTP 104 ou armazenador temporário HTTP 106. Em cada caso, os elementos ilustrados na figura 1 podem ser implementados, pelo menos em parte, em software, compreendendo código de programa que é executado em um processador ou outras partes eletrônicas.

[0091] O conteúdo pode compreender filmes, áudio, vídeo plano 2D, vídeo 3D, outros tipos de vídeos, imagens, texto temporizado, metadados temporizados ou similares. Algum conteúdo pode envolver dados que devem ser apresentados ou consumidos de forma temporal, tal como dados para apresentação de informação auxiliar (identificação de estação, anúncio, cotas de ações, sequências Flash, etc.) juntamente com outra mídia sendo reproduzida. Outras apresentações híbridas podem ser utilizadas também e combinam outra mídia e/ou vão além do mero áudio e vídeo.

[0092] Como ilustrado na figura 2, os blocos de mídia podem ser armazenados dentro de uma infraestrutura servidor de bloco 101 (1), que pode ser, por exemplo, um servidor HTTP, um dispositivo de Rede de Distribuição de Conteúdo, um proxy HTTP, um proxy ou servidor FTP, ou algum outro servidor ou sistema de mídia. A infraestrutura servidora de bloco 101(1) é conectada a uma rede 122, que pode ser, por exemplo, uma rede de Protocolo de Internet ("IP") tal como a Internet. Um cliente de sistema de sequenciamento de solicitação de bloco é ilustrado possuindo seis componentes funcionais, isso é, um seletor de bloco 123, fornecido com os metadados descritos acima e realizando uma função de seleção de blocos ou blocos parciais a serem solicitados dentre a pluralidade de blocos disponíveis indicados pelos metadados, um solicitante de bloco 124, que recebe instruções de solicitação do seletor de bloco 123 e realiza as operações necessárias para o envio de uma solicitação por bloco especificado, partes de um bloco, ou múltiplos b locos, para a infraestrutura servidora de bloco 101(1) através da rede 122 e para receber os dados compreendendo o bloco em retorno, além de um armazenador de bloco 125, um monitor de armazenamento 126, um decodificador de mídia 127 e um ou mais transdutores de mídia 128 que facilitam o consumo de mídia.

[0093] Os dados de bloco recebidos pelo solicitante de bloco 124 são passados para armazenamento temporário para o armazenador de bloco 125, que armazena os dados de mídia. Alternativamente, os dados de bloco recebidos podem ser armazenados diretamente no armazenador de bloco 125 como ilustrado na figura 1. O decodificador de mídia 127 é fornecido com dados de mídia pelo armazenador de bloco 125 e realiza tais transformações nesses dados que são necessárias para fornecer entrada adequada para transdutores de mídia 128, que criam a mídia em uma forma adequada para o usuário ou outro consumo. Exemplos de transdutores de mídia incluem dispositivos de exibição visual tal como os encontrados em telefones móveis, sistemas de computador ou televisores, e também podem incluir dispositivos de criação de áudio, tal como alto falantes ou fones de ouvido.

[0094] Um exemplo de um decodificador de mídia seria uma função que transforma os dados no formato descrito em padrão de codificação de vídeo H.264 em representações analógicas ou digitais dos quadros de vídeo, tal como um mapa de pixel de formato YUV com selos de tempo de apresentação associados para cada quadro ou amostra.

[0095] O monitor de armazenamento 126 recebe informação referente ao conteúdo do armazenador de bloco 125 e, com base nessa informação e possivelmente em outras informações, fornece a entrada para o seletor de bloco 123, que é utilizado para determinar a seleção de blocos a solicitar, como descrito aqui.

[0096] Na terminologia utilizada aqui, cada bloco possui um "tempo de reprodução" ou "duração" que representa a quantidade de tempo que leva para o receptor reproduzir a mídia incluída nesse bloco em velocidade normal. Em alguns casos, a reprodução da mídia dentro de um bloco pode depender de já se ter recebido os dados dos blocos anteriores. Em casos raros, a reprodução de parte da mídia em um bloco pode depender de um bloco subsequente, caso no qual o tempo de reprodução para o bloco é definido com relação à mídia que pode ser reproduzida dentro do bloco sem referência ao bloco subsequente, e o tempo de reprodução para o bloco subsequente é aumentado pelo tempo de reprodução da mídia dentro desse bloco que só pode reproduzir depois de ter recebido o bloco subsequente. Visto que a inclusão de mídia em um bloco que depende dos blocos subsequente é um caso raro, no restante dessa descrição considera-se que a mi dia em um bloco não depende dos blocos subsequentes, mas note que os versados na técnica reconhecerão que essa variação pode ser facilmente adicionada às modalidades descritas abaixo.

[0097] O receptor pode ter controles tal como "pausa", "avanço", "retrocesso", etc. que podem resultar no bloco sendo consumido pela reprodução a uma taxa diferente, mas se o receptor puder obter e decodificar cada sequência consecutiva de blocos em um tempo agregado igual a ou inferior ao seu tempo de reprodução agregado excluindo o último bloco na sequência, então o receptor pode apresentar a mídia para o usuário sem interrupção. Em algumas descrições apresentadas aqui, uma posição em articular na sequência de mídia é referida como um "tempo" particular na mídia, correspondendo ao tempo que teria passado entre o começo da reprodução de mídia e o temo quando a posição particular na sequência de vídeo é alcançada. O tempo ou posição em uma sequência de mídia é um conceito convencional. Por exemplo, onde a sequência de vídeo compreende 24 quadros por segundo, o primeiro quadro pode se considerado como possuindo uma posição ou momento t=0,0 segundo e o quadro No. 24 pode ser considerado como possuindo uma posição ou momento t=10,0 segundos. Naturalmente, em uma sequência de vídeo baseada em quadro, a posição ou momento precisam ser contínuos, visto que cada um dos bits na sequência do primeiro bit do quadro 1 até antes do primeiro bit do quadro 2 podem ter todos o mesmo valor de tempo.

[0098] Adotando-se a terminologia acima, um sistema de sequenciamento de solicitação de bloco (BRSS) compreende um ou mais clientes que fazem solicitações para um ou mais servidores de conteúdo (por exemplo, servidores HTTP, servidores FTP, etc.). Um sistema de ingestão compreende um ou mais processadores de ingestão, onde um processador de ingestão recebe conteúdo (em tempo real ou não), processa o conteúdo para uso pelo BRSS e armazena o mesmo em armazenamento acessível para os servidores de conteúdo, possivelmente também juntamente com metadados gerados pelo processador de ingestão.

[0099] O BRSS também pode conter armazenadores temporários de conteúdo que coordenam com os servidores de conteúdo. Os servidores de conteúdo e os armazenadores temporários de conteúdo podem ser servidores HTTP convencionais ou armazenadores temporários HTTP que recebem solicitações por arquivos ou segmentos na forma de solicitações HTTP que incluem um URL, e também podem incluir uma faixa de byte, a fim de solicitar menos do que todos o arquivo ou segmento indicado pelo URL. Os clientes podem incluir um cliente HTTP convencional que solicita os servidores HTTP e manuseia as respostas a essas solicitações, onde o cliente HTTP é acionado por um sistema de cliente novo que fórmula solicitações, passa as mesmas par ao cliente HTTP, obtém respostas do cliente HTTP e processas as mesmas (ou armazena, transforma, etc.) a fim de fornecer as mesmas para um aparelho de apresentação para reprodução por um dispositivo de cliente. Tipicamente, o sistema de cliente não conhece de antemão a mídia que irá precisar (visto que a necessidade pode depender do registro de usuário, mudanças no registro de usuário, etc.) de modo que é considerado um sistema de "sequenciamento" visto que a mídia é "consumida" tão logo é recebida, ou pouco tempo depois disso. Como resultado disso, os retardos de resposta e restrições de largura de banda podem causar retardos em uma apresentação, tal como causar uma pausa em uma apresentação à medida que a sequência alcança o ponto onde o usuário se encontra no consumo da apresentação.

[00100] A fim de se fornecer uma apresentação que seja percebida como de boa qualidade, um número de detalhes pode ser implementado no BRSS, na extremidade de cliente, na extremidade de ingestão, ou em ambas. Em alguns casos, os detalhes que são implementados são realizados considerando- se que, e para lidar com a interface entre cliente e servidor na rede. Em algumas modalidades, ambos o sistema de cliente e o sistema de ingestão estão cientes sobre as melhorias, ao passo que em outras modalidades, apenas um lado está ciente das melhorias. Em tais casos, todo o sistema se beneficia das melhorias mesmo que um lado não esteja ciente das mesmas, enquanto em outros, o benefício só é possível se ambos os lados estiverem cientes da mesma, mas quando um lado não está ciente, ainda opera sem falha.

[00101] Como ilustrado na figura 3, o sistema de ingestão pode ser implementado como uma combinação de componentes de hardware e software, de acordo com várias modalidades. O sistema de ingestão pode compreender um conjunto de instruções que podem ser executadas para fazer com que o sistema realize qualquer uma ou mais das metodologias discutidas aqui. O sistema pode ser criado como uma máquina específica na forma de um computador. O sistema pode ser um computador servidor, um computador pessoal (PC), ou qualquer sistema capaz de executar um conjunto de instruções (sequências ou trás) que especificam as ações a serem realizadas por esse sistema. Adicionalmente, enquanto apenas um único sistema é ilustrado, o termo "sistema" deve ser considerado também como incluindo qualquer coleção de sistemas que executam individualmente ou em conjunto um conjunto (ou múltiplos conjuntos) de instruções para realizar qualquer uma ou mais das metodologias discutidas aqui.

[00102] O sistema de ingestão pode incluir o processador de ingestão 302 (por exemplo, uma CPU), uma memória 304 que pode armazenar o código de programa durante a execução, e o armazenador em disco 306, todos os quais se comunicam um com o outro através de um barramento 300. O sistema pode incluir adicionalmente uma unidade de exibição de vídeo 308 (por exemplo, um monitor de cristal líquido (LCD) ou tubo de raio catodo (CRT)). O sistema também pode incluir um dispositivo de entrada alfanumérica 310 (por exemplo, um teclado), e um dispositivo de interface de rede 312 para receber a fonte de conteúdo e armazenador e distribuir o armazenador de conteúdo.

[00103] A unidade de armazenamento em disco 306 pode incluir um meio legível por máquina no qual podem ser armazenados um ou mais conjuntos de instruções (por exemplo, software) consubstanciando qualquer uma ou mais das metodologias ou funções descritas aqui. As instruções também podem residir, completamente ou pelo menos parcialmente, dentro da memória 304 e/ou dentro do processador de ingestão 302 durante a execução das mesmas pelo sistema, com a memória 304 e o processador de ingestão 302 também constituindo mídia legível por máquina.

[00104] Como ilustrado na figura 4, o sistema de cliente pode ser implementado como uma combinação de componentes de hardware e software, de acordo com várias modalidades. O sistema de cliente pode compreender um conjunto de instruções que pode ser executado para fazer com que o sistema realize qualquer uma ou mais das metodologias discutidas aqui. O sistema pode ser realizado como uma máquina específica na forma de um computador. O sistema pode ser um computador servidor, um PC ou qualquer sistema capaz de executar um conjunto de instruções (sequencial ou de outra forma) que especifique as ações a serem tomadas pelo sistema. Adicionalmente, enquanto apenas um único sistema é ilustrado, o termo "sistema" também deve ser considerado como incluindo qualquer coleção de sistemas que executam individualmente ou em conjunto um conjunto (ou vários conjuntos) de instruções para realizar qualquer uma ou mais das metodologias discutidas aqui.

[00105] O sistema de cliente pode incluir o processador de cliente 402 (por exemplo, uma CPU), uma memória 404 que pode armazenar o código de programa durante a execução, e um armazenador em disco 406, todos os quais podem se comunicar um com o outro através de um barramento 400. O sistema pode incluir adicionalmente uma unidade de exibição de vídeo 408 (por exemplo, um monitor de cristal líquido (LCD) ou tubo de raio catodo (CRT)). O sistema também pode incluir um dispositivo de registro alfanumérico 410 (por exemplo, um teclado), e um dispositivo de interface de rede 412 para enviar solicitações e receber respostas.

[00106] A unidade de armazenamento em disco 406 pode incluir um meio legível por máquina no qual podem ser armazenados um ou mais conjuntos de instruções (por exemplo, software) consubstanciando qualquer uma ou mais das metodologias ou funções descritas aqui. As instruções também podem residir, completamente ou pelo menos parcialmente, dentro da memória 404 e/ou dentro do processador de cliente 402, durante a execução das mesmas pelo sistema, com a memória 404 e o processador de cliente 402 também constituindo mídia legível por máquina. Utilização do Formato de Arquivo 3GPP

[00107] O formato de arquivo 3GPP ou qualquer outro arquivo com base no formato de arquivo de mídia com base em ISO, tal como o formato de arquivo MP4 ou formato de arquivo 3GPP2, pode ser utilizado como o formato recipiente para o sequenciamento HTTP com as seguintes características. Um índice de segmento pode ser incluído em cada segmento para sinalizar os desvios de tempo e faixas de bytes, de modo que o cliente possa descarregar as peças adequadas de arquivos ou segmentos de mídia como necessário. A temporização de apresentação global de toda a apresentação de mídia e temporização local dentro de cada arquivo 3GP ou segmento de mídia pode ser alinhada com precisão. Trilhos dentro de um arquivo 3GP ou segmento de mídia podem ser alinhados precisão. Trilhos através de representações também podem ser alinhados pela designação de cada um dos mesmos para a linha de tempo global de modo que a comutação através da representação possa ser contínua e a apresentação em conjunto de componentes de mídia em diferentes representações possa ser sincronizada.

[00108] O formato de arquivo pode conter um perfil para Sequenciamento Adaptativo com as seguintes propriedades. Todos os dados de filme podem ser contidos em fragmentos de filme - a caixa "moov" pode não conter qualquer informação de amostra. Dados de amostras de áudio e vídeo podem ser intercalados, com exigências similares quanto ao perfil de download progressivo como especificado em TS26.244. A caixa "moov" pode ser localizada no começo do arquivo, seguido por dados de desvio de fragmento, também referidos como índice de segmento, contendo informação de desvio em tempo e faixas de byte para cada fragmento ou pelo menos um subconjunto de fragmentos no segmento de contenção.

[00109] Pode ser possível também que a Descrição da Apresentação de Mídia para fazer referência aos arquivos que seguem o perfil de Download Progressivo existente. Nesse caso, o cliente pode utilizar a Descrição de Apresentação de Mídia simplesmente para selecionar a versão alternativa adequada dentre múltiplas versões disponíveis. Os clientes podem utilizar também solicitações de obtenção parcial de HTTP com arquivos em conformidade com o perfil de Download Progressivo para solicitar os subconjuntos de cada versão alternativa e, dessa forma, implementar uma forma menos eficiente de sequenciamento adaptativo. Nesse caso, diferentes representações contendo a mídia no perfil de download progressivo ainda podem aderir a uma linha de tempo global comum para permitir a comutação contínua através de representações. Visão Geral de Métodos Avançados

[00110] Nas seções a seguir, os métodos para os sistemas de sequenciamento de solicitação de bloco aperfeiçoados são descritos. Deve-se compreender que alguns desses aperfeiçoamentos podem ser utilizados com ou sem outros desses aperfeiçoamentos, dependendo das necessidades de aplicação. Na operação geral, um receptor solicita de um servidor ou outro transmissor blocos específicos ou partes de blocos de dados Arquivos, também chamados de segmentos, podem conter múltiplos blocos e são associados com uma representação de uma apresentação de mídia.

[00111] Preferivelmente, a informação de indexação, também chamada de "indexação de segmento" ou "mapa de segmento" é gerada e fornece um mapeamento para tempos de reprodução ou decodificação para desvios de byte de blocos correspondentes ou fragmentos dentro de um segmento. Essa indexação de segmento pode ser incluída dentro do segmento, tipicamente no começo do segmento (pelo menos parte do mapa de segmento está no começo) e é frequentemente pequeno. O índice de segmento também pode ser fornecido em um segmento de índice separado ou arquivo. Especialmente nos casos onde o índice de segmento é contido no segmento, o receptor pode descarregar parte ou todo o seu mapa de segmento rapidamente e utilizar subsequentemente isso para determinar o mapeamento entre os desvios de tempo e as posições de byte correspondentes de fragmentos associados com esses desvios de tempo dentro do arquivo.

[00112] Um receptor pode utilizar um desvio de bytes para solicitar dados dos fragmentos associados com os desvios de tempo particulares, sem precisar descarregar todos os dados associados com outros fragmentos não associados com os desvios de tempo de interesse. Dessa forma, o mapa de segmento ou indexação de segmento pode aperfeiçoar muito a capacidade de um receptor em acessar diretamente partes do segmento que são relevantes aos desvios de tempo atuais de interesse, com benefícios incluindo os tempos de zapping de conteúdo aperfeiçoados, capacidade de mudar rapidamente de uma representação para outra à medida que as condições da rede variam, e desperdício reduzido dos recursos de rede descarregando mídia que não é reproduzida por um receptor.

[00113] No caso de comutação de uma representação (referida aqui como representação de "comutar a partir de") para outra representação (referida aqui como representação para "comutar para") ser considerada, o índice de segmento também pode ser utilizado para identificar o tempo inicial de um ponto de acesso randômico na representação de comutação para identificar a quantidade de dados a serem solicitados na representação de comutar a partir de para garantir a comutação contínua em um sentido no qual a mídia na representação de comutar a partir de seja descarregada até um momento de apresentação de modo que a reprodução da representação de comutar para possa começar de forma contínua a partir do ponto de acesso randômico.

[00114] Esses blocos representam segmentos de mídia de vídeo e outras mídias que o receptor solicitante precisa a fim de gerar a saída par ao usuário do receptor. O receptor da mídia pode ser um dispositivo de cliente, tal como quando o receptor recebe conteúdo de um servidor que transmite o conteúdo. Exemplos incluem caixas decodificadoras, computadores, consoles de jogos, televisores especialmente equipados, dispositivos portáteis, telefones móveis especialmente equipados ou outros receptores de cliente.

[00115] Muitos métodos de gerenciamento de armazenador avançados são descritos aqui. Por exemplo, um método de gerenciamento de armazenador permite que o cliente solicite blocos de qualidade de mídia mais alta que podem ser recebidos em tempo para serem reproduzidos com continuidade. Uma característica de tamanho de bloco variável aperfeiçoa a eficiência de compressão. A capacidade de se ter múltiplas conexões para transmissão de blocos par ao dispositivo solicitante enquanto se limita a frequência das solicitações fornece um desempenho de transmissão aperfeiçoado. Blocos de dados recebidos parcialmente podem ser utilizados para continuar a apresentação de mídia. Uma conexão pode ser reutilizada para vários blocos sem precisa comprometer a conexão no começo de um conjunto particular de blocos. A consistência na seleção de servidores dentre os vários possíveis servidores por vários clientes é aperfeiçoada, o que reduz a frequência de duplicação de conteúdo em servidores próximos e aperfeiçoa a probabilidade de um servidor conter todo um arquivo. Os clientes podem solicitar blocos de mídia com base em metadados (tal como as codificações de mídia disponíveis) que são embutidos nos URLs para os arquivos contendo os blocos de mídia. Um sistema pode fornecer o cálculo e minimização da quantidade de tempo de armazenamento necessário antes da reprodução do conteúdo poder começar sem incorrer em pausas subsequentes na reprodução de mídia. Largura de banda disponível pode ser compartilhada entre vários blocos de mídia, ajustada à medida que o tempo de reprodução de cada bloco se aproxima, de modo que, se necessário, uma parte maior da largura de banda disponível possa ser alocada na direção do bloco com o tempo de reprodução mais próximo.

[00116] O sequenciamento HTTP pode empregar metadados. Os metadados de nível de apresentação incluem, por exemplo, duração de sequência, codificações disponíveis (taxas de bit, codecs, resoluções espaciais, taxas de quadro, linguagem, tipos de mídia), apontadores para metadados de sequência para cada codificação, e proteção de conteúdo (informação de gerenciamento de direitos digitais (DRM)). Os metadados de sequência podem ser URLs para os arquivos de segmento.

[00117] Os metadados de segmento podem incluir faixa de byte X informação de tempo para solicitações dentro de um segmento e identificação de RAPs ou outros pontos de busca, onde alguma ou toda essa informação pode ser parte de uma indexação de segmento ou mapa de segmento.

[00118] As sequências podem compreender múltiplas codificações do mesmo conteúdo. Cada codificação pode então ser dividida em segmentos onde cada segmento corresponde a uma unidade de armazenamento ou arquivo. No caso de HTTP, um segmento é tipicamente um recurso que pode ser referido por um URL e a solicitação de tal URL resulta no retorno do segmento como o corpo de entidade da mensagem de resposta de solicitação. Os segmentos podem compreender múltiplos grupos de imagens (GoPs). Cada GoP pode compreender adicionalmente múltiplos fragmentos onde a indexação de segmento fornece informação de desvio de byte/tempo para cada fragmento, isso é, a unidade de indexação é um fragmento.

[00119] Os fragmentos ou partes de fragmentos podem ser solicitados através das conexões TCP paralelas para aumentar o rendimento. Isso pode mitigar problemas que surgem quando as conexões de compartilhamento em um link de estreitamento ou quando conexões são perdidas devido ao congestionamento, aumentando, assim, a velocidade geral e a confiabilidade da distribuição, que pode aperfeiçoar substancialmente a velocidade e confiabilidade do tempo de zapping de conteúdo. A largura de banda pode ser trocada por latência por solicitação, mas deve-se ter cuidado para evitar a realização de solicitações muito distantes no futuro que possam aumentar o risco de starvation.

[00120] Várias solicitações por segmentos no mesmo servidor podem ser sequenciadas (criando a próxima solicitação antes de a solicitação atual ser completada) para evitar os retardos de inicialização TCP repetitivos. As solicitações por fragmentos contínuos podem ser agregadas em uma solicitação.

[00121] Algumas CDNs preferem arquivos grandes e podem acionar coletas de fundo de todo um arquivo a partir de um servidor de origem quando primeiro vê uma solicitação de faixa. A maior parte das CDNs irá, no entanto, servir solicitações de faixa a partir do armazenador temporário se os dados estiverem disponíveis. Pode, portanto, ser vantajoso se ter alguma parte das solicitações de cliente por um arquivo de segmento total. Essas solicitações podem ser posteriormente canceladas se necessário.

[00122] Os pontos de comutação válidos podem ser pontos de busca, especificamente RAPs, por exemplo, na sequência alvo. Diferentes implementações são possíveis tal como estruturas GoP fixas ou alinhamento de RAPs através de sequências (com base no começo da mídia ou com base nos GoPs).

[00123] Em uma modalidade, os segmentos e GoPs podem ser alinhados através de diferentes sequências de taxa. Nessa modalidade, GoPs podem ter tamanho variável e podem conter vários fragmentos, mas os fragmentos não são alinhados entre as diferentes sequências de taxa.

[00124] Em algumas modalidades, a redundância de arquivos pode ser empregada de forma vantajosa. Nessas modalidades, um código de eliminação é aplicado a cada fragmento para gerar versões redundantes dos dados. Preferivelmente, a formatação fonte não é alterada devido à utilização de FEC, e segmentos de reparo adicionais, por exemplo, como representação dependente da representação original, contendo dados de reparo FEC são gerados e disponibilizados como uma etapa adicional no sistema de ingestão. O cliente, que é capaz de reconstruir um fragmento utilizando apenas dados fonte para esse fragmento, pode solicitar apenas dados fonte para o fragmento dentro do segmento dos servidores. Se os servidores estiverem indisponíveis ou a conexão com os servidores for lenta, o que pode ser determinado antes ou depois da solicitação por dados fonte, os dados de reparo adicionais podem ser solicitados para o fragmento a partir do segmento de reparo, o que diminui o tempo para se distribuir de forma confiável dados suficientes para recuperação do fragmento, possivelmente utilizando a decodificação FEC para uso de uma combinação de dados fonte e de reparo recebidos para recuperar os dados fonte do fragmento. Adicionalmente, os dados de reparo adicionais podem ser solicitados para permitir a recuperação do fragmento se um fragmento se tornar urgente, isso é, seu tempo de reprodução se torna iminente, o que aumenta o compartilhamento de dados para esse fragmento em um link, mas é mais eficiente do que o encerramento de outras conexões no link para liberar a largura de banda. Isso pode mitigar também o risco de starvation do uso de conexões paralelas.

[00125] O formato de fragmento pode ser uma sequência armazenada de pacotes RTP com sincronização de áudio e vídeo alcançada através do RTCP.

[00126] O formato de segmento também pode ser uma sequência armazenada de pacotes MPEG-2 TS com sincronização de áudio e vídeo alcançada por temporização interna MPEG-2 TS. Utilização de Sinalização e/ou Criação de Bloco para Tornar o Sequenciamento Mais Eficiente

[00127] Um número de características pode ser utilizado ou não em um sistema de sequenciamento de solicitação de bloco para fornecer um desempenho aperfeiçoado. O desempenho pode ser relacionado com a capacidade de reprodução de uma apresentação sem interrupção, obtenção de dados de mídia dentro das restrições da largura de banda, e/ou tudo isso dentro de recurso de processador limitados em um sistema de cliente, servidor e/ou ingestão. Algumas dessas características serão descritas agora. Indexação dentro dos Segmentos

[00128] A fim de formular solicitações GET parciais para Fragmentos de filme, o cliente pode ser informado sobre o desvio de byte e tempo inicial na decodificação ou apresentação de todos os componentes de mídia contidos nos fragmentos dentro do arquivo ou segmento e também quais fragmentos iniciam ou contêm um Ponto de Acesso Randômico (e são mais adequados para serem utilizados com pontos de comutação entre representações alternativas), onde essa informação é frequentemente referida como indexação de segmento ou mapa de segmento. O tempo inicial no tempo de decodificação ou apresentação pode ser expresso como deltas com relação a um tempo de referência.

[00129] Essa informação de indexação de desvio de byte e tempo pode exibir pelo menos 8 bytes de dados por fragmento de filme. Como um exemplo, para um filme de duas horas contido dentro de um único arquivo, com 500 ms de fragmentos de filme, isso seria um total de cerca de 112 kilobytes de dados. O download de todos esses dados quando do início de 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 de forma hierárquica, de modo que o cliente possa encontrar rapidamente um pedaço pequeno de tempo e dados de desvio relevantes ao ponto na apresentação onde deseja começar. A informação também pode ser distribuída dentro de um segmento de modo que algum refinamento do índice de segmento possa ser localizado intercalado com os dados de mídia.

[00130] Note-se que se uma representação for segmentada no sentido de tempo em múltiplos segmentos, o uso dessa codificação hierárquica pode não ser necessário, visto que o tempo total e os dados de desvio para cada segmento já podem ser bem pequenos. Por exemplo, se os segmentos forem de um minuto ao invés de duas horas no exemplo acima, a informação de indexação de desvio de byte e tempo é de cerca de 1 kilobyte de dados, que pode encaixar tipicamente dentro de um único pacote TCP/IP.

[00131] Opções diferentes são possíveis para adicionar tempo de fragmento e dados de desvio de byte a um arquivo 3GPP:

[00132] Primeiro, a Caixa de Acesso Randômico de Fragmento de Filme ("MFRA") pode ser utilizada para essa finalidade. A MFRA fornece uma tabela, que pode auxiliar os leitores em encontrar pontos de acesso randômicos em um arquivo utilizando fragmentos de filme. Para suportar essa função, a MFRA contém os desvios de byte das caixas MFRA contendo pontos de acesso randômico. A MFRA pode ser localizada em ou perto do final do arquivo, mas esse não é necessariamente o caso. Pela digitalização a partir do final do arquivo para uma Caixa de Desvio de Acesso Randômico de Fragmento de Filme e utilizando a informação de tamanho encontrada na mesma, pode-se localizar o começo de uma Caixa de Acesso Randômico de Fragmento de Filme. No entanto, a colocação da MFRA no final do sequenciamento HTTP exige tipicamente pelo menos de 3 a 4 solicitações HTTP para se acessar os dados desejado: pelo menos uma para solicitar a MFRA a partir do final do arquivo, uma para obter a MFRA e finalmente uma para obter o fragmento desejado no arquivo. Portanto, a colocação no começo pode ser desejável visto que então a MFRA pode ser descarregada juntamente com os primeiros dados de mídia em uma única solicitação. Além disso, a utilização de MFRA para sequenciamento HTTP pode ser ineficiente, visto que nenhuma das informações na "MFRA" é necessária além do tempo e moof_offset e especificando desvio ao invés de comprimentos pode exigir mais bits.

[00133] Em segundo lugar, a Caixa de Localização de Item ("ILOC") pode ser utilizada. ILOC fornece um diretório de recursos de metadados nesse ou em outros arquivos, pela localização de seus arquivos de contenção, seus desvios dentro desse arquivo e seus comprimentos. Por exemplo, um sistema pode integrar todos os recursos de metadados referidos externamente dentro de um arquivo, reajustar os desvios de arquivo e referências de arquivo de acordo. No entanto, ILOC é destinada a fornecer a localização dos metadados de modo que possa ser difícil que coexista com os metadados reais.

[00134] Por fim, e talvez mais adequada é a especificação de uma nova caixa, referida como Caixa de Índice de Tempo ("TIDX"), especificamente dedicada à finalidade de fornecer tempos ou durações exatos de fragmentos e desvio de byte de forma eficiente. Isso é descrito em maiores detalhes na próxima seção. Uma caixa alternativa com as mesmas funcionalidades pode ser a Caixa de Índice de Segmento ("SIDX"). Aqui, a menos que indicado o contrário, essas duas podem ser intercambiáveis, visto que ambas as caixas fornecem a capacidade de fornecer tempos ou durações de fragmento exatos e desvio de byte de forma eficiente. A diferença entre a TIDX e a SIDX é fornecida abaixo. Deve ser aparente como se intercambiar as caixas TIDX e as caixas SIDX, visto que ambas as caixas implementam um índice de segmento.

Indexação de Segmento

[00135] Um segmento possui um momento inicial identificado e um número de bytes identificado. Múltiplos fragmentos podem ser concatenados em um único segmento e clientes podem emitir solicitações que identificam a faixa de byte específica dentro do segmento que corresponde ao fragmento necessário ou subconjunto de fragmento. Por exemplo, quando HTTP é utilizado como o protocolo de solicitação, então o cabeçalho de Faixa HTTP pode ser utilizado para essa finalidade. Essa abordagem exige que o cliente tenha acesso a um "índice de segmento" do segmento que específica a posição dentro do segmento de fragmentos diferentes. Esse "índice de segmento" pode ser fornecido como parte dos metadados. Essa abordagem possui o resultado de muito menos arquivos precisarem ser criados e gerenciados em comparação com a abordagem onde cada bloco é mantido em um arquivo separado. O gerenciamento da criação, transferência e armazenamento de números muito grandes de arquivos (que podem ser estender para muitos milhares para uma apresentação de 1 hora) pode ser completa e pode tender a apresentação de erros e, dessa forma, a redução no número de arquivos representa uma vantagem.

[00136] Se o cliente conhecer apenas o momento inicial desejado de uma parte menor de um segmento, o mesmo pode solicitar todo o arquivo, então ler o arquivo para determinar a localização inicial de reprodução adequada. Para se aperfeiçoar a utilização de largura de banda, segmentos podem incluir um arquivo de indica como metadados, onde o arquivo de índice mapeia as faixas de byte dos blocos individuais com as faixas de tempo às quais os blocos correspondem, chamados de indexação de segmento ou mapa de segmento. Esses metadados podem ser formatados como dados XML ou podem ser binários, por exemplo, seguindo a estrutura de átomo e caixa do formato de arquivo 3GPP. A indexação pode ser simples, onde as faixas de tempo e byte para cada bloco são absolutas com relação ao início do arquivo ou podem ser hierárquicas, onde alguns blocos são agrupados em blocos parentes (e esse em blocos avôs, etc.) e o tempo e faixa de byte para o bloco determinado são expressos com relação á faixa de byte e/ou tempo do bloco parente do bloco. Estrutura de Mapa de Indexação Ilustrativa

[00137] Em uma modalidade, os dados fonte originais para uma representação de uma sequência de mídia podem ser contidos em um ou mais arquivos de mídia chamados aqui de "segmento de mídia", onde cada segmento de mídia contém os dados de mídia utilizados para reproduzir um segmento de tempo contínuo de mídia, por exemplo, 5 minutos de reprodução de mídia.

[00138] A figura 6 ilustra uma estrutura geral ilustrativa de um segmento de mídia. Dentro de cada segmento, no começo ou espalhado através do segmento fonte, também existe informação de segmentação, que compreende um mapa de segmento de desvio de tempo e byte. O mapa de segmento de desvio de tempo e byte em uma modalidade pode ser uma lista de pares de desvio de tempo e byte (T(0), B(0)), T(1), B(1)), ...,(T(n), B(n)), onde T(i-1) representa um momento inicial dentro do segmento para reprodução do fragmento i da mídia com relação ao momento inicial da mídia entre todos os segmentos de mídia, T(i) representa um momento final para o fragmento i (e, dessa forma, o momento inicial para o próximo fragmento), e o desvio de byte B(i-1) é o índice de byte correspondente do começo dos dados dentro desse segmento fonte onde o fragmento i da mídia começa com relação ao começo do segmento fonte, e B(i) é o índice de byte final correspondente do fragmento i (e, dessa forma, o índice do primeiro byte do próximo fragmento). Se o segmento contiver múltiplos componentes de mídia, então T(i) e B(i) podem ser fornecidos para cada componente no segmento de uma forma absoluta ou podem ser expressos com relação a outro componente de mídia que serve como um componente de mídia de referência.

[00139] Nessa modalidade, o número de fragmentos no segmento fonte é igual a n, onde n pode variar de segmento para segmento.

[00140] Em outra modalidade, o desvio de tempo no índice de segmento para cada fragmento pode ser determinado com o momento inicial absoluto do primeiro fragmento e as durações de cada fragmento. Nesse caso, o índice de segmento pode documentar o momento inicial do primeiro fragmento e a duração de todos os fragmentos que são incluídos no segmento. O índice de segmento também pode documentar apenas um subconjunto de fragmentos. Nesse caso, o índice de segmento documenta a duração de um subsegmento que é definido como um ou mais fragmentos consecutivos, terminando no final do segmento de contenção, ou no começo do próximo subsegmento.

[00141] Para cada fragmento, pode haver um valor que indica se ou não o fragmento começa em ou contém um ponto de busca, isso é, em um ponto no qual nenhuma mídia depois desse ponto depende de qualquer mídia anterior a esse ponto e, dessa forma, a mídia desse fragmento em diante pode ser reproduzida independentemente dos fragmentos anteriores. Pontos de busca são, em geral, pontos na mídia onde a reprodução pode começar independentemente de toda a mídia anterior. A figura 6 também ilustra um exemplo simples de possível indexação de segmento para um segmento fonte. Nesse exemplo, o valor de desvio de tempo é em unidades de milissegundos, e, dessa forma, o primeiro fragmento desse segmento fonte começa 20 segundos depois do começo da mídia, e o primeiro fragmento possui um tempo de reprodução de 485 milissegundos. O desvio de byte do início do primeiro fragmento é igual a 0, e o desvio de byte do final do primeiro fragmento/início do segundo fragmento é de 50,245, e, dessa forma, o primeiro fragmento tem o tamanho de 50.245 bytes. Se o fragmento ou o subsegmento não começar com um ponto de acesso randômico, mas o ponto de acesso randômico for contido no fragmento ou subsegmento, então a diferença do tempo de decodificação ou tempo de apresentação entre o momento inicial e o momento RAP real pode ser fornecida. Isso permite que no caso de comutação desse segmento de mídia, o cliente pode saber com precisão o tempo até a comutação da representação precisar ser apresentada.

[00142] Adicionalmente, ou ao invés de indexação simples e hierárquica, a indexação tipo daisy-chain e/ou indexação hibrida pode ser utilizada.

[00143] Visto que as durações ilustrativas para trilhos diferentes podem não ser iguais (por exemplo, amostras de vídeo podem ser exibidas por 33 ms, ao passo que uma amostra de áudio pode durar 180 ms), os trilhos diferentes em um Fragmento de Filme pode não começar e terminar precisamente na mesma hora, isso é, o áudio pode começar um pouco antes ou um pouco depois do vídeo, com o oposto sendo verdadeiro para o fragmento anterior, para compensar. Para se evitar ambiguidade, os selos de tempo especificados nos dados de desvio de tempo e byte podem ser especificados com relação a um trilho particular e esse pode ser o mesmo trilho para cada representação. Normalmente esse seria o trilho de vídeo. Isso permite que o cliente identifique exatamente o próximo quadro de vídeo quando está comutando representações.

[00144] Deve-se ter cuidado durante a apresentação para se manter uma relação estrita entre as escalas de tempo de trilho e o tempo de apresentação, para se garantir uma reprodução suave e manutenção da sincronização de áudio e vídeo a despeito do problema acima.

[00145] A figura 7 ilustra alguns exemplos, tal como um índice simples 700 e um índice hierárquico 702.

[00146] Dois exemplos específicos de uma caixa que contém um mapa de segmento são fornecidos abaixo, um referido como TIDX e um referido como SIDX. A definição segue a estrutura de caixa de acordo com o formato de arquivo de mídia com base em ISO. Outros desenhos para tais caixas para definir a sintaxe similar e com a mesma semântica e funcionalidade deve ser aparente ao leitor. Caixa de Índice de Tempo Definição Tipo de Caixa: "tidx" recipiente: arquivo obrigatório: não quantidade: qualquer número igual a zero ou um

[00147] A Caixa de Índice de Tempo pode fornecer um conjunto de índices de desvio de tempo e byte que associa determinadas regiões do arquivo com determinados intervalos de tempo da apresentação. A Caixa de Índice de Tempo pode incluir um campo tipo alvo, que indica o tipo de dados referidos. Por exemplo, a Caixa de Índice de Tempo com "moof" tipo alvo fornece um índice para os Fragmentos de Mídia contidos no arquivo em termos de desvios de tempo e byte. Uma Caixa de Índice de Tempo com tipo alvo de Caixa de Índice de Tempo pode ser utilizada para construir um índice de tempo hierárquico, permitindo que os usuários do arquivo naveguem rapidamente para a parte necessária do índice.

[00148] O índice de segmento pode, por exemplo, conter a sintaxe a seguir: aligned(8) class TimeIndexBox extends FullBox ('frai'){ 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) random_acess_flag; unsigned int(31) length; unsigned int(32) deltaT; } } Semântica targettype: é o tipo de dados de caixa referidos por essa Caixa de Índice de Tempo. Pode ser Cabeçalho de Fragmento de Filme ("moof") ou Caixa de Índice de Tempo ("tidx"). time-reference-track_id: indica o trilho com relação a qual desvio de tempo nesse índice é especificado. number_of_elements: o número de elementos indexados por essa Caixa de Índice de Tempo. first_element_offset: O desvio de byte a partir do início do arquivo do primeiro elemento indexado. first_element_time: O momento inicial do primeiro elemento indexado, utilizando a escala de tempo especificada na caixa de Cabeçalho de Mídia do trilho identificado pelo time_reference_track_id. random_access_flag: Um se o momento inicial do elemento for um ponto de acesso randômico. Zero de outra forma. comprimento: O comprimento do elemento indexado em bytes. deltaT: A diferença em termos de escala de tempo especificada na caixa de Cabeçalho de Mídia do trilho identificado pelo time_reference_track_id entre o momento inicial desse elemento e o momento final do próximo elemento. Caixa de Índice de Segmento

[00149] A Sidx fornece um índice compacto de fragmentos de filme e outras Caixas de Índice de Segmento em um segmento. Existem duas estruturas de circuito na Caixa de Índice de Segmento. O primeiro circuito documenta a primeira amostra do subsegmento, isso é, a amostra no primeiro fragmento de filme referida pelo segundo circuito. O segundo circuito fornece um índice do subsegmento. O recipiente para a caixa sidx é o arquivo ou segmento diretamente. Sintaxe

Semânticas reference_track_ID fornece o track_ID para o trilho de referência. track_count: o número de trilhos indexados no circuito a seguir (1 ou mais); reference_count: o número de elementos indexados pelo segundo circuito (1 ou mais); track_ID: o ID de um trilho para o qual um fragmento de trilho é incluído no primeiro fragmento de filme identificado por esse índice; exatamente um track_ID nesse circuito é igual a reference_track_ID; decoding_time: o tempo de decodificação para a primeira amostra no trilho identificada pelo track_ID no fragmento de filme referido pelo primeiro item no segundo circuito, expresso em escala de tempo do trilho (como documentado no campo de escala de tempo da Caixa de Cabeçalho de Mídia do trilho); reference_type: quando configurado para 0, indica que a referência é para uma caixa de fragmento de filme ("moof"), quando configurado para 1, indica que a referência é para uma caixa de índice de segmento ("sidx"); reference_offset: a distância em bytes do primeiro byte seguindo a Caixa de Índice de Segmento de contenção, para o primeiro byte da caixa referida; subsegment_duration: quando a referência à Caixa de Índice de Segmento, esse campo porta a soma dos campos de subsegment_duration no segundo circuito dessa caixa; quando a referência é para um fragmento de filme, esse campo porta a soma das durações de amostra das amostras no trilho de referência, no fragmento de filme indicado e fragmentos de filme subsequentes até o primeiro fragmento de filme documentado pelo próximo registro no circuito, ou o final do subsegmento, o que quer que seja mais cedo, a duração é expressa na escala de tempo do trilho (como documentado no campo de escala de tempo da Caixa de Cabeçalho de Mídia do trilho); contains_RAP: quando a referência é para um fragmento de filme, então esse bit pode ser 1 se o fragmento de trilho dentro do fragmento de filme para o trilho com track_ID igual a reference_track_ID contiver pelo menos um ponto de acesso randômico, do contrário, esse bit é configurado para 0; quando a referência é para um índice de segmento, então esse bit é configurado para 1 apenas se qualquer uma das referências nesse índice de segmento tiver esse bit configurado para 1, e 0 do contrário; RAP_delta_time: se contain_RAP for igual a 1, fornece o tempo de apresentação (composição) de um RAP; reservado com os valor 0 se contains_RAP for igual a 0. O tempo é expresso como a diferença entre o tempo de decodificação da primeira amostra do subsegmento documentado por esse registro e o tempo de apresentação (composição) do ponto de acesso randômico, no trilho com track_ID igual a reference_track_ID. Diferenças entre TIDX e SIDX

[00150] SIDX e SIDX fornecem a mesma funcionalidade com relação à indexação. O primeiro circuito de SIDX fornece em adição à temporização global para o primeiro fragmento de filme, mas a temporização global também pode ser contida no fragmento de filme propriamente dito, de forma absoluta ou relativa ao trilho de referência.

[00151] O segundo circuito de SIDX implementa a funcionalidade de TIDX. Especificamente, SIDX permite se ter uma mistura de alvos para a referência para cada índice referido por reference_type, ao passo que TIDX só faz referência a apenas TIDX ou apenas MOOF. O number_of_elements em TIDX corresponde a reference_count em SIDX, time-reference_track_id em TIDX corresponde a reference-track_ID em SIDX, first_element_offset em TIDX corresponde a reference_offset no primeiro registro do segundo circuito, first_element_time em TIDX corresponde a decoding_time do reference_track no primeiro circuito, random_access_flag no TIDX corresponde a contains_RAP em SIDX com a liberdade adicional que em SIDX RAPO pode não ser necessariamente localizado no começo do fragmento, e, portanto, exigindo RAP_delta_time, o comprimento em TIDX corresponde a reference_offset em SIDX e finalmente deltaT em TIDX corresponde ao subsegment_duration em SIDX. Portanto, as funcionalidades das duas caixas são equivalentes. Dimensionamento de Bloco Variável e Blocos sub- GoP

[00152] Para mídia de vídeo, a relação entre a estrutura de codificação de vídeo e a estrutura de bloco para solicitações pode ser importante. Por exemplo, se cada bloco começar com um ponto de busca, tal como RAP, e cada bloco representar um período igual de tempo de vídeo, então o posicionamento de pelo menos alguns pontos de busca na mídia de vídeo é fixado e pontos de busca ocorrerão em intervalos regulares dentro da codificação de vídeo. Como é bem sabido dos versados na técnica de codificação de vídeo, a eficiência de compressão pode ser aperfeiçoada se pontos de busca forem localizados de acordo com as relações entre quadros de vídeo, e em particular, se forem localizados nos quadros que possuem pouco em comum com os quadros anteriores. Essa exigência que os blocos representem quantidades iguais de tempo coloca, dessa forma, uma restrição na codificação de vídeo, de modo que a compressão possa ser menos que ideal.

[00153] É desejável se permitir a posição de pontos de busca dentro de uma apresentação de vídeo a ser escolhida pelo sistema de codificação de vídeo, ao invés de se exigir que os pontos de busca sejam 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 aperfeiçoada e, dessa forma, em uma qualidade maior da mídia de vídeo que pode ser fornecida utilizando-se uma largura de banda disponível determinada, resultando em uma experiência de usuário aperfeiçoada. Os sistemas de sequenciamento 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 deva começar com um ponto de busca e isso é, portanto, uma desvantagem dos sistemas existentes.

[00154] Um sistema de sequenciamento de solicitação de bloco novo que fornece vantagens sobre o acima exposto é descrito agora. 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 escolher as posições de pontos de busca a fim de otimizar a eficiência de compressão, mas com uma exigência que haja um máximo na duração entre pontos de busca. Essa última exigência não restringe a escolha dos pontos de busca pelo processo de codificação e, dessa forma, reduz a eficiência de compressão. No entanto, a redução na eficiência de compressão é pequena em comparação com a incorrida se posições fixas regulares for necessária para pontos de busca, desde que o máximo na duração entre os pontos de busca não seja muito pequeno (por exemplo, maior do que cerca de um segundo). Adicionalmente, se o máximo na duração entre os pontos de busca for de poucos segundos, então a redução na eficiência de compressão em comparação com o posicionamento completamente livre dos pontos de busca é geralmente muito pequena.

[00155] Em muitas modalidades, incluindo essa modalidade, pode ser que alguns RAPs não sejam pontos de busca, isso é, pode haver um quadro que é um RAP que está entre dois pontos de busca consecutivos que não são escolhidos como sendo um ponto de busca, ou porque a quantidade de dados de mídia entre o ponto de busca anterior ou seguinte ao RAP e o RAP é muito pequena.

[00156] Em muitas modalidades, incluindo essa modalidade, pode acontecer de alguns RAPs não serem pontos de busca, isso é, pode haver um quadro que é um RAP que está entre dois pontos de busca consecutivos que não são escolhidos como ponto de busca, por exemplo, porque o RAP está muito perto em tempo dos pontos de busca circundantes, ou porque a quantidade de dados de mídia entre o ponto de busca anterior ou seguinte ao RAP e o RAP é muito pequena.

[00157] A posição dos pontos de busca dentro de todas as outras versões da apresentação de mídia pode ser restrita de modo a ser igual aos pontos de busca em uma primeira (por exemplo, a taxa de dados de mídia mais alta) versão. Isso reduz a eficiência de compressão para essa outra versão em comparação com permitir que o codificador tenha livre escolha dos pontos de busca.

[00158] O uso de pontos de busca exige tipicamente que um quadro seja independentemente decodificável, o que geralmente resulta em uma baixa eficiência de compressão para esse quadro. Os quadros que não precisam ser independentemente decodificáveis podem ser codificados com referência aos dados em outros quadros, o que geralmente aumenta a eficiência de compressão para esse quadro por uma quantidade que depende da quantidade de coincidência entre o quadro a ser codificado e os quadros de referência. A escolha eficiente do posicionamento de ponto de busca escolhe preferivelmente como um quadro de ponto de busca um quadro que possui baixa coincidência com quadros anteriores e, dessa forma, minimiza a penalidade de eficiência de compressão incorrida pela codificação do quadro de uma forma que é independentemente decodificável.

[00159] No entanto, o nível de coincidência entre um quadro e os quadros de referência em potencial é altamente correlacionado através de diferentes representações do conteúdo, visto que o conteúdo original é igual. Como resultado disso, a restrição dos pontos de busca em outras variações para que sejam a mesma posição que os pontos de busca na primeira variação não faz uma diferença muito grande na eficiência de compressão.

[00160] A estrutura de ponto de busca é preferivelmente utilizada para determinar a estrutura de bloco. Preferivelmente, cada ponto de busca determina o início de um bloco, e pode haver um ou mais blocos que englobam os dados entre dois pontos de busca consecutivos. Visto que a duração entre os pontos de busca não é fixa para codificação com boa compressão, nem todos os blocos precisam ter a mesma duração de reprodução. Em algumas modalidades, os blocos são alinhados entre as versões de conteúdo - isso é, se existe um bloco abrangendo um grupo específico de quadros em uma versão do conteúdo, então existe um bloco abrangendo o mesmo grupo de quadros em outra versão do conteúdo. Os blocos para uma determinada versão do conteúdo não se sobrepõem e cada quadro de conteúdo é contido dentro de exatamente um bloco de cada versão.

[00161] Uma característica que permite o uso eficiente de durações variáveis entre os pontos de busca, e, dessa forma, a GoPs de duração variável, é a indexação de segmento ou mapa de segmento que pode ser incluída em um segmento ou fornecida por outros meios para um cliente, isso é, são metadados associados com esse segmento nessa representação que podem ser fornecidos compreendendo o momento inicial e a duração de cada bloco da apresentação. O cliente pode utilizar esses dados de indexação de segmento quando da determinação do bloco no qual começar a apresentação quando o usuário solicitou que a apresentação começasse em um ponto em particular que está dentro de um segmento. Se tais metadados não forem fornecidos, então a apresentação pode começar apenas no começo do conteúdo, ou em um ponto aleatório ou aproximado perto do ponto desejado (por exemplo, pela escolha do bloco inicial pela divisão do ponto inicial solicitado (em tempo) pela duração média de bloco para fornecer o índice de bloco inicial).

[00162] Em uma modalidade, cada bloco pode ser fornecido como um arquivo separado. Em outra modalidade, múltiplos blocos consecutivos podem ser agregados em um único arquivo para formar um segmento. Nessa segunda modalidade, os metadados para cada versão podem ser fornecidos compreendendo o momento inicial e a duração de cada bloco e o desvio de byte dentro do arquivo onde o bloco começa. Esses metadados podem ser fornecidos em resposta a uma solicitação de protocolo inicial, isso é, disponível separadamente do segmento ou arquivo; ou pode ser contidos dentro do mesmo arquivo ou segmento que os blocos propriamente ditos, por exemplo, no começo do arquivo. Como será claro para os versados na técnica, esse metadados podem ser codificados na forma comprimida, tal como gzip ou codificação delta ou na forma binária, a fim de reduzir os recursos de rede necessários para transportar os metadados para o cliente.

[00163] A figura 6 ilustra um exemplo da indexação de segmento onde os blocos são de tamanho variável, e onde o escopo dos bloco sé um GoP parcial, isso é, uma quantidade parcial de dados de mídia entre um RAP e o próximo RAP. Nesse exemplo, os pontos de busca são indicados pelo indicador RAP, onde um valor indicador RAP de 1 indica que o bloco começa com ou contém um RAP, ou ponto de busca, e onde um indicador RAP de 0 indica que o bloco não contém um RAP ou ponto de busca. Nesse exemplo, os primeiros três blocos, isso é, bytes 9 a 157.033, compreendem o primeiro GoP, que possui uma duração de apresentação de 1.623 segundos, com um tempo de apresentação correndo de 20 segundos para o conteúdo para 21,623 segundos. Nesse exemplo, o primeiro dos três primeiros blocos compreende,485 segundos de tempo de apresentação, e compreende os primeiros 50,245 bytes de dados de mídia no segmento. Nesse exemplo, os blocos 4, 5 e 6 compreendem o segundo GoP, blocos 7 e 8 compreendem o terceiro GoP, e os blocos 9, 10 e 11 compreendem o quarto GoP. Note-se que podem haver outros RAPs nos dados de mídia que não são designados como pontos de busca, e são, dessa forma, não sinalizados como RAPs, no mapa de segmento.

[00164] Com referência novamente à figura 6, se o cliente ou receptor desejar acessar o conteúdo começando no desvio de tempo de aproximadamente 22 segundos na apresentação de mídia, então o cliente pode primeiro utilizar outras informações, tal como MPD descrito em maiores detalhes posteriormente, para primeiro determinar que os dados de mídia relevantes estão dentro desse segmento. O cliente pode descarregar a primeira parte do segmento para obter a indexação de segmento, que nesse caso é de poucos bytes por exemplo, utilizando uma solicitação de faixa de byte HTTP. Utilizando a indexação de segmento, o cliente pode determinar que o primeiro bloco que deve descarregar é o primeiro bloco com um desvio de tempo que é de no máximo 22 segundos, e que começa com um RAP, isso é, um ponto de busca. Nesse exemplo, apesar de o bloco 5 possuir um desvio de tempo que é menor que 22 segundos, isso é, seu desvio de tempo é de 21,965 segundos, a indexação de segmento indica que o bloco 5 não começa com um RAP, e, dessa forma, ao invés disso, com base na indexação de segmento, o cliente seleciona descarregar o bloco 4, visto que seu momento inicial é de no máximo 22 segundos, isso é, seu desvio de tempo é 21,623 segundos, e começa com um RAP. Dessa forma, com base na indexação de segmento, o cliente realizará uma solicitação de faixa HTTP começando no desvio de byte 157,034.

[00165] Se a indexação de segmento não estiver disponível então o cliente pode precisar descarregar todos os 157,034 bytes anteriores de dados antes de descarregar esses dados, levando a um tempo de inicialização muito maior, ou tempo de zapping de canal, e desperdiçar o download de dados que não são úteis. Alternativamente, se a indexação de segmento não estiver disponível, o cliente pode se aproximar de onde os dados desejados começam dentro do segmento, mas a aproximação pode ser ruim e pode perder o tempo adequado e então exigir o retorno que novamente aumenta o retardo de inicialização.

[00166] Geralmente, cada bloco engloba uma parte de dados de mídia que, juntamente com os blocos anteriores, podem ser reproduzidos por um aparelho de mídia. Dessa forma, a estrutura de bloqueio e a sinalização de estrutura de bloqueio de indexação de segmento para o cliente, contido dentro do segmento ou fornecido para o cliente através de outros meios, pode aperfeiçoar de forma significativa a capacidade do cliente em fornecer zapping de canal rápido, e reprodução contínua em vista de variações e interrupções de rede. O suporte dos blocos de duração variável, e blocos que englobam apenas partes de um GoP, como permitido pela indexação de segmento, pode aperfeiçoar de forma significativa a experiência de sequenciamento. Por exemplo, com referência novamente à figura 6 e ao exemplo descrito acima onde o cliente deseja iniciar a reprodução em aproximadamente 22 segundos na apresentação, o cliente pode solicitar, através de uma ou mais solicitações, os dados dentro do bloco 4, e então alimentar isso para o aparelho de mídia tão logo esteja disponível para iniciar a reprodução. Dessa forma, nesse exemplo, a reprodução começa tão logo os 42,011 bytes do bloco 4 sejam recebidos no cliente, permitindo, assim, um tempo de zapping de canal rápido. Se, ao invés disso, o cliente precisar solicitar todo o GoP antes da reprodução começar, o tempo de zapping de canal será maior, visto que são 144.211 bytes de dados.

[00167] 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 indicam onde esse 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, ao invés do tempo de apresentação do primeiro quadro dentro do bloco.

[00168] As figuras 8(a) e (b) ilustram um exemplo de dimensionamento de bloco variável e estrutura de ponto de busca alinhado através de uma pluralidade de versões ou representações. A figura 8(a) ilustra o dimensionamento de bloco variável com pontos de busca alinhados através de uma pluralidade de versões de uma sequência de mídia, enquanto a figura 8(b) ilustra o dimensionamento de bloco variável com pontos de busca não alinhados através de uma pluralidade de versões de uma sequência de mídia.

[00169] O tempo é ilustrado através do topo em segundos, e os blocos e pontos de busca dos dois segmentos para as duas representações são ilustrados da esquerda para a direita em termos de sua temporização com relação a essa mesma linha, e, dessa forma, o comprimento de cada bloco ilustrado é proporcional a seu tempo de reprodução e não proporcional ao número de bytes no bloco. Nesse exemplo, a indexação de segmento para ambos os segmentos das duas representações teria os mesmos desvios de tempo para os pontos de busca, mas números potencialmente diferentes de blocos ou fragmentos entre os pontos de busca, e desvios de byte diferentes para blocos devido às quantidades diferentes de dados de mídia em cada bloco. Nesse exemplo, se o cliente desejar comutar da representação 1 para a representação 2 no tempo de apresentação aproximadamente 23 segundos, em tão o cliente pode solicitar através do bloco 1.2 no segmento para representação 1, e começar a solicitar o segmento para a representação 2 começando no bloco 2.2 e, dessa forma, a comutação ocorrerá na apresentação coincidindo com o ponto de busca 1.2 na apresentação 1, que é igual ao tempo do ponto de busca 2.2 na representação 2.

[00170] Como deve ficar claro a partir do acima exposto, o sistema de sequenciamento de solicitação de bloco descrito não restringe a codificação de vídeo para colocar pontos de busca em posições específicas dentro do conteúdo e então mitiga um dos problemas dos sistemas existentes.

[00171] Nas modalidades descritas acima existe uma organização de modo que os pontos de busca para as várias representações da mesma apresentação de conteúdo sejam alinhadas. No entanto, em muitos casos, é preferível se relaxar essa exigência de alinhamento. Por exemplo, algumas vezes é o caso de as ferramentas de codificação terem sido utilizadas para gerar as representações que não possuem as capacidades para gerar uma representação alinhada por pontos de busca. Como outro exemplo, a apresentação de conteúdo pode ser codificada em diferentes representações independentemente, sem qualquer alinhamento de ponto de busca entre diferentes representações. Como outro exemplo, uma representação pode conter mais pontos de busca visto que possui taxas mais baixas e necessita mais comumente ser comutada ou contém pontos de busca para suportar modos de truque tal como avanço, retrocesso ou busca rápida. Dessa forma, é desejável se fornecer métodos que tornam um sistema de sequenciamento de solicitação de bloco capaz de lidar de forma eficiente e contínua com pontos de busca não alinhados através das várias representações para uma apresentação de conteúdo.

[00172] Nessa modalidade, as posições dos pontos de busca através das representações podem não estar alinhadas. Os blocos são construídos de modo que um novo bloco comece em cada ponto de busca, e, dessa forma, pode não haver alinhamento entre os blocos de diferentes versões da apresentação. Um exemplo de tal estrutura de ponto de busca não alinhada entre diferentes representações é ilustrada na figura 8(b). O tempo é ilustrado através do topo em segundos, e os blocos e pontos de busca dos dois segmentos para as duas representações são ilustrados a partir da esquerda para a direita em termos de sua temporização com relação a essa linha de tempo, e, dessa forma, o comprimento de cada bloco ilustrado é proporcional a seu tempo de reprodução e não proporcional ao número de bytes no bloco. Nesse exemplo, a indexação de segmento para ambos os segmentos das duas representações terá desvios de tempo potencialmente diferentes para os pontos de busca, e também números potencialmente diferentes de blocos ou fragmentos entre os pontos de busca, e diferentes desvios de byte para blocos devido às quantidades diferentes de dados de mídia em cada bloco. Nesse exemplo, se o cliente desejar comutar da representação 1 para a representação 2 no tempo de apresentação de aproximadamente 25 segundos, então o cliente pode solicitar até o bloco 1.3 no segmento para a representação 1, e começar a solicitar o segmento para a representação 2 começando no bloco 2.3, e, dessa forma, a comutação pode ocorrer na apresentação coincidindo com o ponto de busca 2.3 na representação 2, que está no meio da reprodução do bloco 1.3 na representação 1, e, dessa forma, alguma mídia para o bloco 1.2 não terá sido reproduzida (apesar de os dados de mídia para os quadros do bloco 1.3 que não forem reproduzidos poderem ter que ser carregados para o armazenador de recebimento para decodificação de outros quadros do bloco 1.3 que foram reproduzidos).

[00173] Nessa modalidade, a operação do seletor de bloco 123 pode ser modificada de modo que toda vez que for necessário se selecionar um bloco de uma representação que é diferente da versão selecionada anteriormente, o último bloco cujo primeiro quadro não está depois do quadro subsequente ao último quadro do último bloco selecionado é escolhido.

[00174] Essa última modalidade descrita pode eliminar a exigência de restringir as posições dos pontos de busca dentro das versões além da primeira versão e, dessa forma, aumenta a eficiência de compressão para essas versões resultando em uma apresentação de maior qualidade para uma determinada largura de banda disponível e isso é uma experiência de usuário aperfeiçoada. Uma consideração adicional é que as ferramentas de codificação de vídeo que realizam a função de alinhamento do ponto de busca através de múltiplas codificações (versões) do conteúdo podem não estar amplamente disponíveis e, portanto, uma vantagem dessa última modalidade descrita é que as ferramentas de codificação de vídeo atualmente disponíveis podem ser utilizadas. Outra vantagem é que a codificação de diferentes versões do conteúdo pode prosseguir em paralelo sem qualquer necessidade de coordenação entre os processos de codificação para diferentes versões. Outra vantagem é que as versões adicionais do conteúdo podem ser codificadas e adicionadas à apresentação posteriormente, sem precisar fornecer as ferramentas de codificação sem as listas de posições de ponto de busca específicas.

[00175] Geralmente, onde as imagens são codificadas como grupos de imagens (GoPs), a primeira imagem na sequência pode ser um ponto de busca, mas esse não precisa ser sempre o caso. Divisão Ideal de Bloco

[00176] Um problema em um sistema de sequenciamento de solicitação de bloco é a interação entre a estrutura da mídia codificada, por exemplo, mídia de vídeo e estrutura de bloco utilizada para as solicitações de bloco. Como é sabido pelos versados na técnica de codificação de vídeo, é frequentemente ocaso de o número de bits necessários para a representação codificada de cada quadro de vídeo variar, algumas vezes substancialmente, de quadro para quadro. Como resultado da relação entre a quantidade de dados recebidos e a duração da mídia codificada por esses dados pode não ser direta. Adicionalmente, a divisão de dados e mídia em bloco dentro de um sistema de sequenciamento de solicitação de bloco adiciona uma dimensão adicional de complexidade. Em particular, em alguns sistemas os dados de mídia de um bloco podem não ser reproduzidos até que todo o bloco tenha sido recebido, por exemplo, a disposição de dados de mídia dentro de um bloco ou as dependências entre as amostras de mídia dentro de um bloco e o uso de códigos de eliminação pode resultar nesse caso. Como resultado dessas interações complexas entre o tamanho de bloco e a duração do bloco e a possível necessidade de se receber todo um bloco antes de se começar a reproduzir o mesmo é comum para sistemas de cliente para adotar uma abordagem conservadora onde os dados de mídia são armazenados antes de a reprodução começar. Tal armazenamento resulta em um tempo de zapping de canal longo e, dessa forma, uma experiência de usuário ruim.

[00177] Pakzad descreve "métodos de divisão de bloco" são métodos novos e eficientes para determinar como se dividir uma sequência de dados em blocos contíguos com base na estrutura subjacente da sequência de dados e descreve adicionalmente várias vantagens desses métodos no contexto de um sistema de sequenciamento. Uma modalidade adicional da invenção para aplicação de métodos de divisão de bloco de Pakzad para um sistema de sequenciamento de solicitação de bloco é descrita agora. Esse método pode compreender a disposição de dados de mídia a serem apresentados em uma ordem de tempo de apresentação aproximada, de modo que o tempo de reprodução de qualquer elemento determinado de dados de mídia (por exemplo, um quadro de vídeo ou amostra de áudio) difira de qualquer elemento de dados de mídia adjacente por menos do que um limite fornecido. Os dados de mídia ordenados dessa forma podem ser considerados uma sequência de dados na linguagem de Pakzad e qualquer um dos métodos de Pakzad aplicados a essa sequência de dados identifica limites de bloco com a sequência de dados. Os dados entre qualquer par de limites de bloco adjacentes são considerados um "bloco" na linguagem dessa descrição e os métodos dessa descrição são aplicados para fornecer a apresentação de dados de mídia dentro de um sistema de sequenciamento de solicitação de bloco. Como fica claro para os versados na técnica depois de lerem essa descrição, as várias vantagens dos métodos descritos em Pakzad podem então ser realizadas no contexto de um sistema de sequenciamento de solicitação de bloco.

[00178] Como descrito em Pakzad, a determinação da estrutura de bloco de um segmento, incluindo os blocos que engloba m GoPs parciais ou partes de mais de um GoP, podem causar um impacto na capacidade de o cliente ativar os tempos de zapping de canal rápido. Em Pakzad, métodos são fornecidos nos quais, de acordo com um tempo de inicialização alvo, é fornecido uma estrutura de bloco e uma taxa de download alvo que garantiria que se o cliente iniciasse o download da representação em qualquer ponto de busca e começasse a reproduzir depois que o tempo de inicialização alvo tivesse passado então a reprodução continuaria de forma contínua desde que em cada ponto no tempo a quantidade de dados que o cliente descarregou fosse pelo menos a taxa de download alvo X o tempo passado a partir do começo do download. É vantajoso que o cliente tenha acesso ao tempo de inicialização alvo e à taxa de download alvo, visto que isso fornece ao cliente meios para determinar quando iniciar a reprodução da representação no momento mais cedo, e permite que o cliente continue a reproduzir a representação desde que o download corresponda às condições descritas acima. Dessa forma, o método descrito posteriormente fornece um meio de incluir o tempo de inicialização alvo e a taxa de download alvo dentro da Descrição de Apresentação de Mídia, de modo que possa ser utilizado para fins descritos acima. Modelo de Dados de Apresentação de Mídia

[00179] A figura 5 ilustra possíveis estruturas do armazenador de conteúdo ilustrado na figura 1, incluindo segmentos e arquivos de descrição de apresentação de mídia ("MPD"), e uma quebra de segmentos, temporização e outra estrutura dentro de um arquivo MPD. Detalhes de possíveis implementações de estruturas MPD ou arquivos serão descritos agora. Em muitos exemplo, MPD é descrito como um arquivo, mas estruturas de não arquivo podem ser utilizadas também.

[00180] Como ilustrado aqui, o armazenador de conteúdo 110 mantém uma pluralidade de segmentos fonte 510, MPDs 500 e segmentos de reparo 512. Um MPD pode compreender registros de período 501, que, por sua vez, podem compreender registros de representação 502, que contêm informação de segmento 503 tal como referências para segmentos de inicialização 504 e segmentos de mídia 505.

[00181] A figura 9(a) ilustra uma tabela de metadados ilustrativa 900, enquanto a figura 9(b) ilustra um exemplo de como um cliente de sequenciamento HTTP 902 obtém a tabela de metadados 900 e blocos de mídia 904 através de uma conexão com um servidor de sequenciamento HTTP 906.

[00182] Nos métodos descritos aqui, uma "Descrição de Apresentação de Mídia" é fornecida e compreende informação referente às representações da apresentação de mídia que são disponíveis para o cliente. As representações podem ser alternativas em um sentido de que o cliente seleciona um dentre as diferentes alternativas, ou podem ser complementares em um sentido de que o cliente seleciona várias das representações, cada uma possivelmente também de um conjunto de alternativas, e apresenta as mesmas em conjunto. As representações podem ser vantajosamente designadas a grupos, com o cliente programado ou configurado para compreender que, para as representações em um grupo, existem alternativas para o outro, ao passo que as representações de grupos diferentes são tais que mais de uma representação deve ser apresentada em conjunto. Em outras palavras, se houver mais de uma representação em um grupo, o cliente escolhe uma representação do grupo, uma representação do próximo grupo, etc., para formar uma apresentação.

[00183] A informação que descreve as representações pode incluir vantajosamente detalhes dos codecs de mi dia aplicados incluindo perfis e níveis desses codecs que são necessários para se decodificar a representação, taxas de quadro de vídeo, resolução de vídeo e taxas de dados. O cliente recebendo a Descrição de Apresentação de Mídia pode utilizar essa informação para determinar de antemão se uma representação é adequada para decodificação ou apresentação. Isso representa uma vantagem visto que se a informação de diferenciação fosse contida apenas nos dados binários da representação seria necessário se solicitar os dados binários de todas as representações e se analisar e extrair a informação relevante a fim de descobrir a informação sobre sua adequação. Essas múltiplas solicitações e a extração do anexo de análise dos dados podem, algumas vezes, levar algum tempo que resultaria em um tempo de inicialização longo e, portanto, em uma experiência de usuário ruim.

[00184] Adicionalmente, a Descrição de Apresentação de Mídia pode compreender informação restringindo as solicitações de cliente com base na hora do dia. Por exemplo, para um serviço ao vivo o cliente pode ser restrito a solicitar partes da apresentação que estão perto do "tempo de difusão atual". Isso representa uma vantagem visto que a difusão ao vivo pode ser desejável para purgar os dados da infraestrutura servidora de conteúdo que foi difundido mais do que um limite fornecido antes do tempo de difusão atual. Isso pode ser desejável para a reutilização de recursos de armazenamento dentro da infraestrutura servidora. Isso 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 determinado modelo de assinatura dos dispositivos de recebimento de cliente, ao passo que outras apresentações de mídia podem ser disponibilizadas ao vivo e sob demanda, e outras apresentações só podem ser disponibilizadas ao vivo para um dispositivo de cliente de primeira classe, apenas sob demanda para um dispositivo de cliente de segunda classe, e uma combinação de ao vivo ou sob demanda para uma terceira classe de dispositivos de cliente. Os métodos descritos no Modelo de Dados de Apresentação de Mídia (abaixo) permitem que o cliente seja informado sobre tais políticas de modo que o cliente possa evitar realizar solicitações e ajustar as ofertas para o usuário, por dados que podem não estar disponíveis na infraestrutura servidora. Como uma alternativa, por exemplo, o cliente pode apresentar uma notificação para o usuário que esses dados não estão disponíveis.

[00185] Em uma modalidade adicional da invenção, os segmentos de mídia podem estar em conformidade com o Formato de Arquivo de Mídia de Base ISO descrito em ISO/IEC 14496-12 ou especificações derivadas (tal como o formato de arquivo 3GP descrito na Especificação Técnica 3GPP 26.244). A utilização da seção de Formato de Arquivo 3GPP (acima) descreve novos aperfeiçoamentos para o Formato de Arquivo de Mídia Base ISO permitindo o uso eficiente de estruturas de dados desse formato de arquivo dentro de um sistema de sequenciamento de solicitação de bloco. Como descrito nessa referência, a informação pode ser fornecida dentro do arquivo permitindo mapeamento rápido e eficiente entre segmentos de tempo da apresentação de mídia e faixas de byte dentro do arquivo. Os dados de mídia propriamente ditos podem ser estruturados de acordo com a construção de Fragmento de Filme definido em ISO/IEC 14496-12. Essa informação fornecendo tempo e desvios de byte pode ser estrutura hierarquicamente ou como um bloco único de informação. Essa informação pode ser fornecida com começo do arquivo. O fornecimento dessa informação utilizando uma codificação eficiente como descrito na seção de Formato de Arquivo 3GPP resulta no cliente sendo capaz de recuperar essa informação rapidamente, por exemplo, utilizando solicitações GET parciais HTTP, no caso de o protocolo de download de arquivo utilizado pelo sistema de sequenciamento de solicitação de bloco ser HTTP, o que resulta em uma inicialização curta, tempo de comutação de busca ou sequência e, portanto, em uma experiência de usuário aperfeiçoada.

[00186] As representações em uma apresentação de mídia são sincronizadas em uma linha de tempo global para garantir a comutação contínua através das representações, tipicamente sendo alternativas, e para garantir a apresentação sincronizada de duas ou mais representações. Portanto, a temporização de amostra de mídia contida nas representações dentro de uma apresentação de mídia de sequenciamento HTTP adaptativa pode ser relacionada com uma linha de tempo global contínua através de múltiplos segmentos.

[00187] Um bloco de mídia contendo mídia codificada de múltiplos tipos, por exemplo, áudio e vídeo, pode ter tempos finais de apresentação diferentes para diferentes tipos de mídia. Em um sistema de sequenciamento de solicitação de bloco, tais blocos de mídia podem ser reproduzidos consecutivamente de tal forma que cada tipo de mídia seja reproduzido continuamente e, dessa forma, amostras de mídia de um tipo de um bloco possam ser reproduzidas antes das amostras de mídia de outro tipo do bloco anterior, que é referido aqui como "junção contínua de blocos". Como uma alternativa, tais blocos de mídia podem ser reproduzidos de tal forma que a amostra mais anterior de qualquer tipo de um bloco seja reproduzida depois da última amostra de qualquer tipo de bloco anterior, que é referido aqui como "junção descontínua de bloco". A junção contínua de bloco pode ser adequada quando ambos os blocos contêm mídia do mesmo item de conteúdo e a mesma representação, codificada em sequência, ou em outros casos. Tipicamente, dentro de uma representação a junção contínua de bloco pode ser aplicada quando da junção de dois blocos. Isso é vantajoso visto que a codificação existente pode ser aplicada e a segmentação pode ser feita sem precisar se alinhar os trilhos de mídia nos limites de bloco. Isso é ilustrado na figura 10, onde a sequência de vídeo 1000 compreende o bloco 1202 e outros blocos, com RAPs tal como RAP 1204. Descrição de Apresentação de Mídia

[00188] Uma apresentação de mídia pode ser visualizada como uma coleção estruturada de arquivos em um servidor de Sequenciamento HTTP. O cliente de sequenciamento HTTP pode descarregar informação suficiente para apresentar o serviço de sequenciamento par ao usuário. Representações alternativas podem compreender um ou mais arquivos 3GP ou partes de arquivos 3GP em conformidade com o formato de arquivo 3GP ou pelo menos a um conjunto bem definido de estruturas de dados que pode ser facilmente convertido de ou para um arquivo 3GP.

[00189] Uma apresentação de mídia pode ser descrita por uma descrição de apresentação de mídia. MPD pode conter metadados que o cliente pode utilizar para construir as solicitações de arquivo adequadas, por exemplo, solicitações GET HTTP, par acessar os dados no momento adequado e para fornecer o serviço de sequenciamento para o usuário. A descrição de apresentação de mídia pode fornecer informação suficiente para o cliente de sequenciamento HTTP para selecionar os arquivos 3GPP adequados e peças dos arquivos. As unidades que são sinalizadas para o cliente como sendo acessíveis são referidas como segmentos.

[00190] Entre outros, uma descrição de apresentação de mídia pode conter elementos e atributos como se segue.

[00191] Elemento de Descrição de Apresentação de Mídia

[00192] Um elemento encapsulando metadados utilizados pelo Cliente de Sequenciamento HTTP para fornecer um serviço de sequenciamento para o usuário final. O elemento de Descrição de Apresentação de Mídia pode conter um ou mais dos atributos e elementos a seguir. Versão: Número de versão para protocolo para garantir a capacidade de extensão. PresentationIdentifier: Informação de modo que a apresentação possa ser identificada de forma singular 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 mídia, isso é, com que frequência o cliente pode recarregar a descrição de apresentação de mídia real. Se não estiver presente, a apresentação de mídia pode ser estática. A atualização da apresentação de mídia pode significar que a apresentação de mídia não pode ser armazenada temporariamente. MediaPresentatioDescriptionURI: URI para datar a descrição de apresentação de mídia. Stream: Descreve o tipo de Sequência ou apresentação de mídia: vídeo, áudio, ou texto. Um tipo de sequência de vídeo pode conter áudio e pode conter texto. Service: Descreve o tipo de serviço com atributos adicionais. Os tipos de serviço podem ser ao vivo ou sob demanda. Isso pode ser utilizado para informar ao cliente que a busca e acesso além de algum momento atual não é permitido. MaximumClientPreBufferTime: Uma quantidade máxima de tempo que o cliente pode armazenar previamente a sequência de mídia. Essa temporização pode diferenciar o sequenciamento do download progressivo se o cliente estiver restrito ao download além desse tempo de armazenamento prévio máximo.

[00193] O valor pode não estar presente indicando que nenhuma restrição nos termos de pré-armazenamento se aplica. SafetyGuardIntervalLiveService: Informação sobre o tempo de retorno máximo de um serviço ao vivo no servidor. Fornece uma indicação para o cliente de que informação já está acessível no momento atual. Essa informação pode ser necessária se o cliente e o servidor operarem no momento UTC e nenhuma sincronização de tempo justa é fornecida. TimeShiftBufferDepth: Informação sobre quanto o cliente pode voltar em um serviço ao vivo com relação ao tempo atual. Pela extensão dessa profundidade, a visualização de mudança de tempo e serviços de acompanhamento podem ser permitidos sem mudanças específicas no fornecimento de serviço. LocalCachingPermitted: Esse indicador indica se o Cliente HTTP pode armazenar temporariamente os dados descarregados localmente depois de terem sido reproduzidos. LivePresentationInterval: Contém intervalos de tempo durante os quais a apresentação pode estar disponível pela especificação de StartTimes e EndTimes. StartTime indica o momento inicial dos serviços e EndTime indica o momento final do serviço. Se EndTime não for especificado, então o momento final é desconhecido nesse momento atual e UpdateFrequency pode garantir que os clientes tenham acesso ao momento final antes do momento final real do serviço. OnDemandAvailabilityInterval: O intervalo de apresentação indica a disponibilidade do serviço na rede. Múltiplos intervalos de apresentação podem ser fornecidos. O cliente HTTP pode não ser capaz de acessar o serviço fora de qualquer janela de tempo especificada. Pelo fornecimento de Intervalo Sob Demanda, a visualização de mudança de tempo adicional pode ser especificada. Esse atributo também pode 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 Sob Demanda durante todos os intervalos de disponibilidade fornecidos. Portanto, o LivePresentationInterval pode não se sobrepor a qualquer OnDemandAvailabilityInterval. MPDFileInfoDynamic: Descreve a construção dinâmica padrão dos arquivos na apresentação de mídia. Mais detalhes são fornecidos abaixo. A especificação padrão no nível MPD pode economizar a repetição desnecessária se as mesmas regras para várias ou todas as representações alternativas forem utilizadas. MPDCodecDescription: Descreve os codecs padrão principais na apresentação de mídia. Mais detalhes são fornecidos abaixo. A especificação padrão no nível de MPD pode economizar a repetição desnecessária se os mesmos codecs para várias ou todas as representações forem utilizadas. MPDMoveBoxHeaderSizeDoesNotChange: Um indicador para indicar se o Cabeçalho MoveBox muda de tamanho entre os arquivos individuais dentro de toda a apresentação de mídia. Esse indicador pode ser utilizado para otimizar o download e pode estar presente apenas no caso de formatos de segmento específicos, especialmente os para os quais os segmentos contêm o cabeçalho moov. FileURIPattern: Um padrão utilizado pelo Cliente para gerar mensagens de Solicitação para arquivos dentro da apresentação de mídia. Os diferentes atributos permitem a geração de URIs singulares para cada um dos arquivos dentro da apresentação de mídia. O URI base pode ser um URI HTTP. Alternative Representation: Descreve uma lista de representações. AlternativeRepresentation Element:

[00194] Um elemento XML que encapsula todos os metadados para uma representação. O AlternativeRepresentation Element pode conter os seguintes atributos e elementos. RepresentationID: Um ID singular para essa Representação Alternativa específica dentro da apresentação de mídia. FilesInfoStatic: Fornece uma lista explícita dos momentos iniciais e URI de todos os arquivos de uma apresentação alternativa. O fornecimento estático da lista de arquivos pode fornecer a vantagem de uma descrição de temporização exata da apresentação de mídia, mas pode não ser tão compacta, especialmente se a representação alternativa contiver muitos arquivos. Além disso, os nomes podem ser nomes arbitrários. FilesInfoDynamic: Fornece uma forma implícita de se construir a lista de momentos iniciais e a URI de uma apresentação alternativa. O fornecimento dinâmico da lista de arquivos pode fornecer a vantagem de uma representação mais compacta. Se apenas a sequência de momentos iniciais for fornecida, então as vantagens de temporização também são aplicáveis, as os nomes do arquivo devem ser construídos dinamicamente com base em FilePatternURI. Se apenas a duração de cada segmento for fornecida então a representação é compacta e pode ser adequada para uso dentro dos serviços ao vivo, mas a geração dos arquivos pode ser governada pela temporização global. APMoveBoxHeaderSizeDoesNotChange: Um indicador que indica se o Cabeçalho MoveBox muda de tamanho entre os arquivos individuais dentro da Descrição Alternativa. Esse indicador pode ser utilizado para otimizar o download e pode estar presente apenas no caso de formatos de segmento específicos, especialmente os para os quais os segmentos contêm o cabeçalho moov. APCodecDescription: Descreve os codecs principais dos arquivos na apresentação alternativa. Elemento de Descrição de Mídia MediaDescription: Um elemento que pode encapsular todos os metadados para a mídia que está contida nessa representação. Especificamente pode conter informação sobre os trilhos nessa apresentação alternativa além de agrupamento recomendado de trilhos, se aplicável. O MediaDescription Attribute contém os seguintes atributos: TrackDescription: Um atributo XML que encapsula todos os metadados para a mídia que está contida nessa representação. TrackDescription Attribute contém os atributos a seguir: TrackID: Um ID singular para o trilho dentro da representação alternativa. Pode ser utilizado no caso de o trilho ser parte de uma descrição de agrupamento. Bitrate: A taxa de bits do trilho. TrackCodecDescription: Um atributo XML que contém todos os atributos no codec utilizados nesse trilho. O TrackCodecDescription Attribute contém os seguintes atributos: MediaName: Um atributo definindo o tipo de mídia. Os tipos de mídia incluem "áudio", "vídeo", "texto", "aplicativo" e "mensagem". Codec: CodecType incluindo um perfil e nível. LanguageTag: LanguageTag se aplicável. MaxWidth, MaxHeight: para vídeo, altura e largura do vídeo contidas em pixel. SamplingRate: Para áudio, taxa de amostragem. GroupDescription: Um atributo que fornece a recomendação para o cliente para o agrupamento adequado com base nos parâmetros diferentes. GroupType: Um tipo com base no qual o cliente pode decidir como agrupar os trilhos.

[00195] A informação em uma descrição de apresentação de mídia é vantajosamente utilizada por um cliente de sequenciamento HTTP para realizar solicitações por arquivos/segmentos ou partes do mesmo em momentos adequados, selecionar os segmentos a partir de representações adequadas que combinam suas capacidades, e assim por diante além de preferências do usuário tal como linguagem, e assim por diante. Adicionalmente, visto que a descrição de Apresentação de Mídia descreve as representações que são alinhadas em tempo e mapeadas para uma linha de tempo global, o cliente também pode utilizar a informação no MPD durante uma apresentação de mídia em andamento para iniciar as ações adequadas para comutar através das representações, para apresentar as representações em conjunto ou para buscar dentro da apresentação de mídia. Momentos Iniciais de Segmento de Sinalização

[00196] Uma representação pode ser dividida, no sentido de tempo, em múltiplos segmentos. Um problema de temporização intertrilho existe entre o último fragmento de um segmento e o próximo fragmento do próximo segmento. Adicionalmente, outro problema de temporização existe no caso de os segmentos de duração constante serem utilizados.

[00197] A utilização da mesma duração para cada segmento pode ter a vantagem de MPD ser compacto e estático. No entanto, cada segmento ainda pode começar em um Ponto de Acesso Randômico. Dessa forma, a codificação de vídeo pode ser restringida para fornecer Pontos de Acesso Randômicos nesses pontos específicos, ou as durações de segmento reais podem não ser precisamente como especificado em MPD. Pode ser desejável que os sistema de sequenciamento não imponha restrições desnecessárias ao processo de codificação de vídeo e, dessa forma, a segunda opção pode ser preferida.

[00198] Especificamente, se a duração de arquivo for especificada em MPD como d segundos, então o arquivo n pode começar com o Ponto de Acesso Randômico em ou imediatamente depois do tempo (n-1)d.

[00199] Nessa abordagem, cada arquivo pode incluir informação quanto ao momento inicial exato do segmento em termos de tempo de apresentação global. Três possíveis formas para se sinalizar isso incluem: (1) Primeiro, restringir o momento inicial de cada segmento para a temporização exata como especificado em MPD. Mas, então o codificador de mídia pode não ter qualquer flexibilidade na colocação de quadros IDR e pode exibir codificação especial para o sequenciamento de arquivo. (2) Segundo, adicionar o momento inicial exato ao MPD para cada segmento. Para o caso sob demanda, a compacidade de MPD pode ser reduzida. Para o caso ao vivo, o mesmo pode exigir uma atualização regular de MPD, que pode reduzir a capacidade de escalonamento. (3) Terceiro, adicionar o tempo global ou o momento inicial exato com relação ao momento inicial anunciado da representação ou o momento inicial anunciado do segmento em MPD para o segmento em um sem tido que o segmento contenha essa informação. Isso pode ser adicionado a uma nova caixa dedicada ao sequenciamento adaptativo. Essa caixa também pode incluir a informação como fornecido pela caixa TIDX ou SIDX. Uma consequência dessa terceira abordagem é que quando se busca uma posição particular perto do começo de um dos segmentos o cliente pode, com base em MPD, escolher o segmento subsequente ao contendo o ponto de busca necessário. Uma resposta simples nesse caso pode ser mover o ponto de busca para frente para o início do segmento recuperado (isso é, para o próximo Ponto de Acesso Randômico depois do ponto de busca). Normalmente, os Pontos de Acesso Randômicos são fornecidos pelo menos a cada poucos segundos (e frequentemente existe pouco ganho de codificação para tornar os mesmos menos frequentes) e, dessa forma, na pior situação o ponto de busca pode ser movido para estar poucos segundos depois do especificado. Alternativamente, o cliente pode determinar na recuperação da informação de cabeçalho para o segmento que o ponto de busca solicitado está de fato no segmento anterior e solicitar esse segmento. Isso pode resultar em um aumento ocasional no tempo necessário para se executar a operação de busca. Lista de Segmentos Acessíveis

[00200] A apresentação de mídia compreende um conjunto de representações, cada uma fornecem alguma versão diferente de codificação para o conteúdo de mídia original. As representações propriamente ditas contêm vantajosamente informação sobre parâmetros de diferenciação da representação em comparação com outros parâmetros. Também contêm, explicitamente ou implicitamente, uma lista de segmentos acessíveis.

[00201] Os segmentos podem ser diferenciados em segmentos sem tempo contendo metadados apenas e segmentos de mídia que contêm basicamente dados de mídia. A MPD identifica vantajosamente e designa atributos diferentes para cada um dos segmentos, implicitamente ou explicitamente. Os atributos designados vantajosamente para cada segmento compreendem o período durante o qual um segmento está acessível, os recursos e protocolos através dos quais os segmentos são acessíveis. Adicionalmente, segmentos de mídia são atributos vantajosamente designados tal como o momento inicial do segmento na apresentação de mídia, e duração do segmento na apresentação de mídia.

[00202] Onde a apresentação de mídia é do tipo "sob demanda", como vantajosamente indicado por um atributo na descrição de apresentação de mídia tal como OnDemandAvailabilityInterval, então a descrição de apresentação de mídia descreve tipicamente todos os segmentos e também fornece indicação quando os segmentos são acessíveis e quando os segmentos não são acessíveis. Os momentos iniciais dos segmentos são vantajosamente expressos com relação ao início da apresentação de mídia de modo que dois clientes iniciando a reprodução das mesmas apresentações de mídia, mas em momentos diferentes, podem utilizar a mesma descrição de apresentação de mídia além de mesmos segmentos de mídia. Isso aperfeiçoa vantajosamente a capacidade de armazenamento temporário dos segmentos.

[00203] Onde a apresentação de mídia é do tipo "ao vivo", como indicado vantajosamente por um atributo na descrição de apresentação de mídia tal como o Serviço de atributo, então os segmentos compreendendo a apresentação de mídia além do momento atual do dia são geralmente não gerados ou pelo menos não acessíveis a despeito de os segmentos serem totalmente descritos na MPD. No entanto, com a indicação 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 momento interno de cliente AGORA no momento de relógio com base na informação contida na MPD e o tempo de download da MPD. O servidor opera vantajosamente em um sentido que torna o recurso acessível de modo que um cliente de referência operando com o caso da MPD na hora de relógio AGORA possa acessar os recursos.

[00204] Especificamente, o cliente de referência produz uma lista de segmentos acessíveis juntamente com os atributos de temporização para um momento interno de cliente AGORA no momento de relógio com base na informação contida na MPD e o tempo de download da MPD. Com o avanço do tempo, o cliente utilizará a mesma MPD e criará uma nova lista de segmento acessível que pode ser utilizada para reproduzir continuamente a apresentação de mídia. Portanto, o servidor pode anunciar os segmentos em uma MPD antes desses segmentos serem na verdade acessíveis. Isso é vantajoso, visto que reduz a atualização e download frequentes da MPD.

[00205] Assume-se que uma lista de segmentos, cada um com um momento inicial, tS, seja descrita explicitamente por uma lista de reprodução nos elementos tal como FileInfoStatic ou implicitamente pela utilização de um elemento tal como FileInfoDynamic. Um método vantajoso de se gerar uma lista de segmentos utilizando FileInfoDynamic é descrito abaixo. Com base nessa regra de construção, o cliente tem acesso a uma lista de URIs para cada representação, r, referida aqui como FileURI (r,i), e um momento inicial tS(r,i) para cada segmento com índice i.

[00206] O uso da informação na MPD para criar a janela de tempo acessível de segmentos pode ser realizada utilizando- se as regras a seguir.

[00207] Para um serviço do tipo "sob demanda", como indicado vantajosamente por um atributo tal como Serviço, se o tempo de relógio atual no cliente AGORA estiver dentro de qualquer faixa de disponibilidade, vantajosamente expresso por um elemento MPD tal como OnDemandAvailabilityInterval, então todos os segmentos descritos dessa apresentação Sob Demanda são acessíveis. Se o tempo de relógio atual no cliente AGORA estiver fora de qualquer faixa de disponibilidade, então nenhum dos segmentos descritos dessa apresentação Sob Demanda são acessíveis.

[00208] Para um serviço do tipo "ao vivo", como indicado vantajosamente por um atributo tal como Serviço, o momento inicial tS(r,i) expressa vantajosamente o tempo de disponibilidade no tempo de relógio. O momento inicial de disponibilidade pode ser derivado como uma combinação do tempo de serviço ao vivo do evento e algum tempo de retorno no servidor para captura, codificação e publicação. O tempo para esse processo pode, por exemplo, ser especificado na MPD, por exemplo, utilizando um intervalo de proteção de segurança tG especificado, por exemplo, especificado como SafetyGuardIntervalLiveService na MPD. Isso fornece a diferença mínima entre o tempo UTC e a disponibilidade de dados no servidor de sequenciamento HTTP. Em outra modalidade, MPD específica explicitamente o tempo de disponibilidade do segmento na MPD sem fornecer o tempo de retorno como uma diferença entre o tempo de evento ao vivo e o tempo de retorno. Nas descrições a seguir, é considerado que quaisquer tempos globais sejam especificados como tempos de disponibilidade. Os versados na técnica de difusão de mídia ao vivo podem derivar essa informação a partir de informação adequada na descrição de apresentação de mídia depois de ler essa descrição.

[00209] Se o tempo de relógio atual no cliente AGORA estiver fora de qualquer faixa de intervalo de apresentação ao vivo, vantajosamente expressa por um elemento MPD tal como LivePresentationInterval, então nenhum dos segmentos descritos dessa apresentação ao vivo é acessível. Se o tempo de relógio atual no cliente AGORA estiver dentro do intervalo de apresentação ao vivo então pelo menos determinados segmentos dos segmentos descritos dessa apresentação ao vivo podem ser acessíveis.

[00210] A restrição dos segmentos acessíveis é governada pelos seguintes valores: O tempo de relógio AGORA (como disponível para o cliente). A profundidade de armazenamento de mudança de tempo permitida tTSB, por exemplo, especificada como TimeShiftBufferDepth na descrição de apresentação de mídia. Um cliente no tempo de evento relativo ti só pode solicitar os segmentos com os momentos iniciais tS(r,i) no intervalo de (AGORA-tTSB) e AGORA ou em um intervalo de modo que o momento final do segmento com duração d também seja incluído resultando em um intervalo de (AGORA - Ttsb - d) e AGORA. Atualização de MPD

[00211] Em algumas modalidades, o servidor não conhece de antemão o arquivo ou localização de segmento e os momentos iniciais dos segmentos como, por exemplo, a localização do servidor mudarão, ou a apresentação de mídia incluir alguns anúncios de um servidor diferente, ou a duração da apresentação de mídia é desconhecida, ou o servidor deseja ofuscar o localizador para os segmentos seguintes.

[00212] Em tais modalidades, o servidor só pode descrever os segmentos que já são acessíveis ou se tornarão acessíveis logo depois desse caso da MPD ter sido publicada. Adicionalmente, em algumas modalidades, o cliente consome vantajosamente mídia perto da mídia descrita na MPD de modo que o usuário experimente o programa de mídia contido o mais perto possível da geração de conteúdo de mídia. Tão logo o cliente antecipa que alcançou o final dos segmentos de mídia descritos na MPD, o mesmo vantajosamente solicita um novo caso de MPD para continuar com a reprodução contínua na expectativa de o servidor ter publicado uma nova MPD descrevendo novos segmentos de mídia. O servidor gera vantajosamente novos casos de MPD e atualiza MPD de modo que os clientes possam se basear nos procedimentos para atualizações contínuas. O servidor pode adaptar seus procedimentos de atualização MPD juntamente com a geração de segmento e publicação dos procedimentos de um cliente de referência que age como um cliente comum.

[00213] Se um novo caso de MPD descrever apenas um avanço de tempo curto, então os clientes precisam solicitar frequentemente novos casos de MPD. Isso pode resultar na capacidade de escalonamento de problemas e tráfego de uplink e downlink desnecessário devido às solicitações frequentes desnecessárias.

[00214] Portanto, é relevante por um lado se descrever os segmentos o máximo possível no futuro sem torná-los necessariamente acessíveis ainda, e, por outro lado, se permitir atualizações não previstas na MPD para expressar novas localizações de servidor, permitir a inserção de novo conteúdo tal como anúncios ou se fornecer mudanças nos parâmetros de codec.

[00215] Adicionalmente, 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 dos segmentos de mídia é vantajosamente flexível para ajustar os tamanhos de segmento adequados que podem ser otimizados para distribuição ou armazenamento temporário de propriedades, para compensar o retardo de extremidade para extremidade em serviços ao vivo ou outros aspectos que lidam com o armazenamento ou distribuição de segmentos, ou por outras razões. Especialmente em casos onde 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 de segmento de mídia e momentos iniciais precisam ser descritos na descrição de apresentação de mídia. Como resultado disso, o tamanho da descrição de apresentação de mídia pode ser grande o que pode afetar de forma adversa o tempo de download da descrição de apresentação de mídia e, portanto, afetar o retardo de inicialização da apresentação de mídia e também a utilização de largura de banda no link de acesso. Portanto, é vantajoso não se permitir apenas a descrição de uma lista de segmentos de mídia utilizando listas de reprodução, mas também se permitir a descrição pela utilização de gabaritos ou regras de construção URL. Os gabaritos e regras de construção URL são utilizados de forma sinônima nessa descrição.

[00216] Adicionalmente, os gabaritos podem ser vantajosamente utilizados para descrever os localizadores de segmento em casos ao vivo além do momento atual. Em tais casos, as atualizações da MPD são por si só desnecessárias visto que os localizadores além da lista de segmento são descritos por gabaritos. No entanto, eventos não previstos ainda podem ocorrer e exigem mudanças na descrição das representações ou segmentos. As mudanças em uma descrição de apresentação de mídia de sequenciamento HTTP podem ser necessárias quando o conteúdo de múltiplas fontes diferentes é unido, por exemplo, quando o anúncio foi inserido. O conteúdo de diferentes fontes pode diferir em uma variedade de formas. Outra razão, durante as apresentações ao vivo, é que pode ser necessário se mudar os URLs utilizados para arquivos de conteúdo para fornecer fail-over de um servidor de origem ao vivo para outro.

[00217] Em algumas modalidades, é vantajoso que se a MPD for atualizada, então as atualizações para a MPD sejam realizadas de modo que a MPD atualizada seja compatível com a MPD anterior no sentido de que o cliente de referência e, portanto, qualquer cliente implementado gere uma lista identicamente funcional de segmentos acessíveis a partir da MPD atualizada para qualquer momento até o tempo de validade da MPD anterior como se tivesse feito a partir do caso anterior da MPD. Essa exigência garante que (a) clientes possa começar imediatamente a utilizar a nova MPD sem sincronização com a MPD antiga, visto que é compatível com a MPD antiga antes do momento de atualização; e (b) o momento de atualização não precisa ser sincronizado com o momento no qual a mudança real na MPD ocorre. Em outras palavras, atualizações da MPD podem ser anunciadas de antemão e o servidor pode substituir o caso antigo da MPD uma vez que nova informação esteja disponível sem precisar manter diferentes versões da MPD.

[00218] Duas possibilidades podem existir para temporização de mídia através de uma atualização MPD para um conjunto de representações ou todas as representações. (a) a linha de tempo global existente continua através da atualização MPD (referida aqui como "atualização de MPD contínua") ou (b) a linha de tempo atual termina e uma nova linha de tempo começa com o segmento seguindo a mudança (referida aqui como uma "atualização MPD descontínua").

[00219] A diferença entre essas opções pode ser evidente quando se considera que os trilhos de um Fragmento de Mídia, e, dessa forma, de um Segmento, geralmente não começa e terminam no mesmo momento devido ao detalhamento de amostra diferente através dos trilhos. Durante a apresentação normal, amostras de um trilho de um fragmento podem ser criados antes de algumas amostras de outro trilho do fragmento anterior, isso é, existe algum tipo de sobreposição entre os fragmentos apesar de poder não haver sobreposição dentro de um único trilho.

[00220] A diferença entre (a) e (b) é se tal sobreposição pode ser permitida através de uma atualização MPD. Quando a atualização MPD se deve à junção de conteúdo completamente separado, tal sobreposição é geralmente difícil de alcançar visto que o novo conteúdo precisa de nova codificação para ser unido ao conteúdo anterior. É, portanto, vantajoso, se fornecer a capacidade de atualizar de forma descontínua a apresentação de mídia pela reinicialização da linha de tempo para determinados segmentos e possivelmente também definir um novo conjunto de representações depois da atualização. Além disso, se o conteúdo tiver sido codificado e segmentado independentemente, então também se evita ajustar os selos de tempo para encaixar em uma linha de tempo global da peça anterior de conteúdo.

[00221] Quando a atualização é por razões menores tal como apenas adição de novos segmentos de mídia à lista de segmentos de mídia descritos, ou se a localização dos URLs for alterada então a sobreposição e atualizações contínuas podem ser permitidas.

[00222] No caso de uma atualização MPD descontínua, a linha de tempo do último segmento da representação anterior termina no momento final da última apresentação de qualquer amostra no segmento. A linha de tempo da próxima representação (ou, mais precisamente, o primeiro momento de apresentação do primeiro segmento de mídia da nova parte de apresentação de mídia, também referido como novo período) começa tipicamente e vantajosamente nesse mesmo instante que o final da apresentação do último período de modo que a reprodução contínua seja garantida.

[00223] Os dois casos são ilustrados na figura 11.

[00224] É preferível e vantajoso se restringir as atualizações MPD para os limites de segmento. O racional para a restrição de tais mudanças ou atualizações nos limites de segmento é como se segue. Primeiro, as mudanças nos metadados binários para cada representação, tipicamente o Cabeçalho de Filme, pode ocorrer pelo menos nos limites de segmento. Em segundo lugar, a Descrição de Apresentação de Mídia pode conter os apontadores (URLs) para os segmentos. Em um sentido a MPD é a estrutura de dados tipo "guarda chuva" agrupando todos os arquivos de segmento associados com a apresentação de mídia. Para se manter essa relação de contenção, cada segmento pode ser referido por uma única MPD e quando a MPD é atualizada, atualiza vantajosamente apenas em um limite de segmento.

[00225] Os limites de segmento não precisam geralmente ser alinhados, no entanto, para o caso de conteúdo unido a partir de fontes diferentes, e para atualizações MPD descontínuas geralmente, faz sentido se alinhar os limites de segmento (especificamente, o último segmento de cada representação pode terminar no mesmo quadro de vídeo e pode não conter amostras de áudio com um momento inicial de apresentação posterior ao momento de apresentação desse quadro). Uma atualização descontínua pode então começar um novo conjunto de representações em um momento comum, referido como período. O momento inicial da validade desse novo conjunto de representações é fornecido, por exemplo, por um momento inicial de período. O momento inicial relativo de cada representação é reconfigurado para zero e o momento inicial do período coloca o conjunto de representações nesse novo período na linha de tempo de apresentação de mídia global.

[00226] Para atualizações de MPD contínuas, limites de segmento não precisam necessariamente ser alinhados. Cada segmento de cada representação alternativa pode ser governado por uma única Descrição de Apresentação de Mídia e, dessa forma, as solicitações de atualização para novos casos da Descrição de Apresentação de Mídia, geralmente acionados pela antecipação de que nenhum dos segmentos de mídia adicionais é descrito na MPD operacional, podem ocorrer em momentos diferentes dependendo do conjunto consumido de representações incluindo o conjunto de representações que são antecipadas para serem consumidas.

[00227] Para se suportar as atualizações nos elementos MPD e atributos em um caso mais geral, quaisquer elementos não apenas as representações ou o conjunto de representações podem ser associados com um tempo de validade. Logo, se determinados elementos da MPD precisarem 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 esses elementos podem, cada um, ser atualizados individualmente em momentos específicos, pelo fornecimento de múltiplas cópias do elemento com tempos de validade diferentes.

[00228] A validade é vantajosamente associada com o tempo de mídia global, de modo que o elemento descrito associado com um tempo de validade seja válido em um período da linha de tempo global da apresentação de mídia.

[00229] Como discutido acima, em uma modalidade, os tempos de validade são apenas adicionais a um conjunto completo de representações. Cada conjunto completo então forma um período. O tempo de validade então forma o momento inicial do período. Em outras palavras, em um caso específico de utilização de elemento de validade, um conjunto completo de representações pode ser valido por um período 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 período. No começo de um novo período, a validade da representação de conjunto anterior é expirada e o novo conjunto das representações é válido. Note-se novamente que os tempos de validade dos períodos são preferivelmente diferentes.

[00230] Como notado acima, as mudanças na Descrição de Apresentação de Mídia ocorre em limites de segmento, e, logo, para cada representação, a mudança em um elemento na verdade ocorre no próximo limite de segmento. O cliente pode então formar uma MPD válida incluindo uma lista de segmentos para cada momento dentro do tempo de apresentação da mídia.

[00231] A união de bloco descontínua pode ser adequada em casos onde os blocos contêm dados de mídia de diferentes representações, ou de conteúdos diferentes, por exemplo, de um segmento de conteúdo e um anúncio, ou em outros casos. Pode ser necessário em um sistema de sequenciamento de solicitação de bloco que mudanças nos metadados de apresentação ocorram apenas nos limites de bloco. Isso pode ser vantajoso por motivos de implementação visto que a atualização dos parâmetros de decodificador de mídia dentro de um bloco pode ser mais complexa do que a atualização dos mesmos apenas entre os blocos. Nesse caso, pode ser vantajosamente especificado que os intervalos de validade como descrito acima podem ser interpretados como aproximados, de modo que um elemento seja considerado válido a partir do primeiro limite de bloco não antes do início do intervalo de validade especificado para o primeiro limite de bloco, não antes do final do intervalo de validade especificado.

[00232] Uma modalidade ilustrativa do acima exposto descreve aperfeiçoamentos novos a um sistema de sequenciamento de solicitação de bloco descritas na seção apresentada posteriormente intitulada Mudanças nas Apresentações de Mídia. Sinalização de Duração de Segmento

[00233] As atualizações descontínuas dividem efetivamente a apresentação em uma série de intervalos separados, referidos como período. Cada período tem sua própria linha de tempo para temporização de amostra de mídia. A temporização de mídia da representação dentro de um período pode ser vantajosamente indicada pela especificação de uma lista compacta separada de durações de segmento para cada período ou para cada representação em um período.

[00234] Um atributo, por exemplo, referido como um momento inicial de período, associado com os elementos dentro da MPD pode especificar o tempo de validade de determinados elementos dentro do tempo de apresentação de mídia. Esse atributo pode ser adicionado a quaisquer elementos (atributos que podem receber uma validade podem ser alterados para elementos) da MPD.

[00235] Para atualizações descontínuas da MPD os segmentos de todas as representações podem terminar em descontinuidade. Isso geralmente implica pelo menos em que o último segmento antes da descontinuidade tenha uma duração diferente dos anteriores. A sinalização da duração de segmento pode envolver a indicação de que todos os segmentos possuem a mesma duração ou indicação de uma duração separada para cada segmento. Pode ser desejável se ter uma representação compacta para uma lista de durações de segmento que seja eficiente no caso de muitos dos mesmos possuírem a mesma duração.

[00236] As durações de cada segmento em uma representação ou um conjunto de representações podem ser vantajosamente realizadas com uma única sequência que específica todas as durações de segmento para um único intervalo a partir do início da atualização descontínua, isso é, o início do período até o último segmento de mídia descrito na MPD. Em uma modalidade, o formato desse elemento é uma sequência de texto em conformidade com uma produção que contém uma lista de entradas de duração de segmento onde cada entrada contém um atributo de duração dure um multiplicador opcional mult do atributo indicando que essa representação contém <mult> dos primeiros segmentos de entrada de duração <dur> da primeira entrada, então <mult> dos segundos segmentos de entrada de duração <dur> da segunda entrada e assim por diante.

[00237] Cada entrada de duração específica a duração de um ou mais segmentos. Se o valor <dur> for seguido por "*" e um número, em tão esse número específica o número de segmentos consecutivos com essa duração, em segundos. Se o sinal de multiplicador "*" estiver ausente, o número de segmentos é igual a um. Se "*" estiver presente sem qualquer número depois, então todos os segmentos subsequentes possuem a duração especificada e pode não haver entradas adicionais na lista. Por exemplo, a sequência "30*" significa que todos os segmentos possuem uma duração de 30 segundos. A sequência "30*12 10,5" indica 12 segmentos de duração de 30 segundos, seguidos por um de duração de 10,5 segundos.

[00238] Se as durações de segmento forem especificadas separadamente para cada representação alternativa, então a soma das durações de segmento dentro de cada intervalo podem ser iguais para cada representação. No caso de trilhos de vídeo, o intervalo pode terminar no mesmo quadro em cada representação alternativa.

[00239] Os versados na técnica, depois de lerem essa descrição, podem encontrar formas similares e equivalentes de expressar as durações de segmento de forma compacta.

[00240] Em outra modalidade, a duração de um segmento é sinalizada para ser constante para todos os segmentos na representação exceto pelo último por um atributo de duração de sinal <duration>. A duração do último segmento antes de uma atualização descontínua pode ser mais curta desde que o ponto inicial da próxima atualização descontínua ou o início de um novo período seja fornecido, o que então implica na duração do último segmento alcançando o início do próximo período. Mudanças e Atualizações nos Metadados de Representação

[00241] A indicação de mudanças de metadados de representação codificados binários tal como mudanças do cabeçalho de filme "moov" pode ser realizada de formas diferentes: (a) pode haver uma caixa moov para toda a representação em um arquivo separado referido na MPD, (b) pode haver uma caixa moov para cada representação alternativa em um arquivo separado referido 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.

[00242] Note-se que no caso de (a) e (b), o único "moov" pode ser vantajosamente combinado com o conceito de validade a partir de cima em um sentido de que mais caixas "moov" podem ser referidas em uma MPD desde que sua validade seja separada. Por exemplo, com a definição de um limite de período, a validade de "moov" no período antigo pode expirar com o início do novo período.

[00243] No caso da opção (a), a referência à caixa moov única pode receber um elemento de validade. Múltiplos cabeçalhos de apresentação podem ser permitidos, mas apenas um pode estar valido de cada vez. Em outra modalidade, o tempo de validade de todo o conjunto de representações em um período ou todo o período como definido acima pode ser utilizado como um tempo de validade para esses metadados de representação, tipicamente fornecidos como o cabeçalho moov.

[00244] No caso da opção (b), referência à caixa moov de cada representação pode receber um elemento de validade. Múltiplos cabeçalhos de representação podem ser permitidos, mas apenas um pode ser valido de cada vez. Em outra modalidade, o tempo de validade de toda a representação ou todo o período como definido acima pode ser utilizado como um tempo de validade para esses metadados de representação, tipicamente fornecidos como o cabeçalho moov.

[00245] No caso da opção (c), nenhuma sinalização na MPD pode ser adicionada, mas sinalização adicional na sequência de mídia pode ser adicionada para indicar se a caixa moov mudará para qualquer um dos próximos segmentos. Isso é adicionalmente explicado abaixo no contexto de "Atualizações de Sinalização dentro de Metadados de Segmento". Atualizações de Sinalização Dentro de Metadados de Segmento

[00246] Para se evitar atualizações frequentes da descrição de apresentação de mídia para obter conhecimento sobre as atualizações em potencial, é vantajoso se sinalizar quaisquer atualizações juntamente com os segmentos de mídia. Pode ser fornecido um elemento adicional ou elementos dentro dos segmentos de mídia propriamente ditos que podem indicar que os metadados atualizados tal como a descrição de apresentação de mídia estão disponíveis e precisam ser acessados dentro de uma determinada quantidade de tempo para continuar com sucesso a criação de listas de segmento acessíveis. Adicionalmente, tais elementos podem fornecer um identificador de arquivo, tal como um URL, ou informação que pode ser utilizada para construir um identificador de arquivo, para o arquivo de metadados atualizado. O arquivo de metadados atualizado pode incluir metadados iguais aos fornecidos no arquivo de metadados original para a apresentação modificada para indicar os intervalos de validade juntamente com os metadados adicionais também acompanhados por intervalos de validade. Tal indicação pode ser fornecida em segmentos de mídia de todas as representações disponíveis para uma apresentação de mídia. Um cliente acessando um sistema de sequenciamento de solicitação de bloco, detectando tal indicação dentro do bloco de mídia, pode utilizar o protocolo de download de arquivo ou outros meios para recuperar o arquivo de metadados atualizado. O cliente é, dessa forma, fornecido com informação sobre as mudanças na descrição de apresentação de mídia e o momento no qual as mesmas ocorrerão ou ocorreram. Vantajosamente, cada cliente solicita a descrição de apresentação de mídia atualizada apenas uma vez quando tais mudanças ocorrem ao invés de "pesquisar" e receber o arquivo muitas vezes para possíveis atualizações ou mudanças.

[00247] Exemplos de mudanças incluem a adição ou remoção de representações, mudanças em uma ou mais representações tal como mudança na taxa de bit, resolução, razão de aparência, trilhos incluídos 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 mudanças podem afetar apenas o segmento de inicialização tal como o átomo Cabeçalho de Filme ("moov") associado com uma representação, ao passo que outras mudanças podem afetar a Descrição de Apresentação de Mídia (MPD).

[00248] No caso de conteúdo sob demanda, essas mudanças e sua temporização podem ser conhecidas de antemão e podem ser sinalizadas na Descrição de Apresentação de Mídia.

[00249] Para conteúdo ao vivo, as mudanças pode não ser conhecidas até o ponto no qual ocorrem. Uma solução é se permitir que a Descrição de Apresentação de Mídia disponível em uma URL específica seja dinamicamente atualizada e se exigir que os clientes solicitem regularmente essa MPD a fim de detectar as mudanças. Essa solução apresenta desvantagens em termos de capacidade de escalonamento (carga de servidor de origem e eficiência de armazenamento temporário). Em uma situação com grandes números de espectadores, os armazenadores temporários podem receber muitas solicitações para MPD depois da versão anterior ter expirado do armazenado temporário e antes da nova versão ter sido recebida e tudo isso pode ser enviado para o servidor de origem. O servidor de origem pode precisar processar constantemente as solicitações dos armazenadores temporários para cada versão atualizada da MPD. Além disso, as atualizações podem não ser facilmente alinhadas em tempo com mudanças na apresentação de mídia.

[00250] Visto que uma das vantagens do Sequenciamento HTTP é a capacidade de utilizar a infraestrutura de rede padrão e serviços para a capacidade de escalonamento, uma solução preferida pode envolver apenas arquivos "estáticos" (isso é, que podem ser armazenados temporariamente) e não se basear em clientes "pesquisando" arquivos para ver se os mesmos mudaram.

[00251] As soluções são discutidas e propostas para se solucionar a atualização dos metadados incluindo a descrição de apresentação de mídia e metadados de representação binária tal como átomos "moov" em uma apresentação de mídia de Sequenciamento HTTP adaptativo.

[00252] Para o caso de conteúdo ao vivo, os pontos nos quais a MPD ou "moov" pode mudar podem não ser conhecidos quando a MPD é construída. Visto que a "pesquisa" frequente da MPD para verificação de atualizações deve ser geralmente evitada, por motivos de largura de banda e capacidade de escalonamento, as atualizações da MPD podem ser indicadas "em banda" nos arquivos de segmento propriamente ditos, isso é, 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 exposto, diferentes atualizações podem ser sinalizadas.

[00253] Geralmente, a indicação a seguir pode ser vantajosamente fornecida em um sinal dentro do segmento: um indicador de que a MPD pode ser atualizada antes da solicitação do novo segmento dentro dessa representação ou qualquer próximo segmento que possua o momento inicial maior do que o momento inicial do segmento atual. A atualização pode ser anunciada de antemão indicando que a atualização só precisa ocorrer em qualquer segmento posterior ao próximo. Essa atualização de MPD também pode ser utilizada para atualizar os metadados de representação binária tal como Cabeçalhos de Filme no caso do localizador de segmento de mídia ser alterado. Outro sinal pode indicar que com a finalização desse segmento, nenhum segmento que avance o tempo será solicitado.

[00254] No caso de os segmentos serem formatados de acordo com o formato de segmento (c), isso é, cada segmento de mídia pode conter metadados de inicialização automática tal como um cabeçalho de filme, então outro sinal pode ser adicionado indicando que o segmento subsequente contém um Cabeçalho de Filme atualizado (moov). Isso permite vantajosamente que o cabeçalho de filme seja incluído no segmento, mas o Cabeçalho de Filme só precisa ser solicitado pelo cliente se o segmento anterior indicar uma Atualização de Cabeçalho de Filme ou no caso de busca ou acesso randômico quando comutando representações. Em outros casos, o cliente pode emitir uma solicitação de faixa de byte para o segmento que exclui o cabeçalho de filme do download, economizando, dessa forma, vantajosamente, largura de banda.

[00255] Em outra modalidade adicional, se a indicação de Atualização MPD for sinalizada, então o sinal também pode conter um localizador tal como URL para a Descrição de Apresentação de Mídia atualizada. A MPD atualizada pode descrever a apresentação tanto antes quanto depois da atualização, utilizando os atributos de validade tal como período novo e antigo no caso de atualizações descontínuas. Isso pode ser utilizado de forma vantajosa para permitir a visualização de mudança de tempo como descrito adicionalmente abaixo, mas também permitir vantajosamente que a atualização MPD seja sinalizada a qualquer momento antes das mudanças que contém começarem. O cliente pode descarregar imediatamente a nova MPD e aplicar a mesma à apresentação em andamento.

[00256] Em uma realização específica, a sinalização de quaisquer mudanças para a descrição de apresentação de mídia, os cabeçalhos moov ou o final da apresentação pode ser contida em uma caixa de informação de sequenciamento que é formatada seguindo as regras do formato de segmento utilizando a estrutura de caixa do formato de arquivo de mídia de base ISO. Essa caixa pode fornecer um sinal específico para qualquer uma das diferentes atualizações. Caixa de Informação de Sequenciamento Definição Tipo de caixa: "sinf" Recipiente: Nenhum obrigatório: não quantidade: zero ou um. A Caixa de Informação de Sequenciamento contém informação sobre a apresentação de sequenciamento da qual o arquivo é uma parte Sintaxe aligned(8) class StreamingInformationBox extends FullBox('sinf'){ unsigned int(32)streaming_information_flags; /// Os seguintes são campos opcionais string mpd_location } Semântica streaming_information_flags contém OR lógico igual a zero ou mais dos seguintes: 0x00000001 Atualização de Cabeçalho de Filme se segue 0x00000002 Atualização de Descrição de Apresentação 0x00000004 Final de Apresentação mpd_location está presente se e apenas se os indicadores de Atualização de Descrição de Apresentação forem configurados e fornece um Localizador de Recurso Uniforme para nova Descrição de Apresentação de Mídia. Caso de Uso Ilustrativo para Atualizações MPD para Serviços ao Vivo

[00257] Supõe-se que um provedor de serviço deseje fornecer um evento de futebol utilizando o sequenciamento de solicitação de bloco melhorado descrito aqui. Talvez de milhões de usuários podem desejar acessar a apresentação do evento. O evento ao vivo é esporadicamente interrompido por quebras quando uma expiração de tempo é chamada, ou outro lull na ação, durante o qual os anúncios podem ser adicionados. Tipicamente, não existe qualquer notícia de avanço ou pouca notícia de temporização exata das quebras.

[00258] O provedor de serviço pode precisar fornecer infraestrutura redundante (por exemplo, codificadores e servidores) para permitir uma troca contínua no caso de qualquer um dos componentes falhar durante o evento ao vivo.

[00259] Supõe-se que um usuário, Ana, acesse o serviço em um barramento com seu dispositivo móvel, e o serviço é imediatamente disponível. Perto dela senta outro usuário, Paul, que observa o evento em seu laptop. Um objetivo é marcado e ambos celebram esse evento ao mesmo tempo. Paul avisa a Ana que o primeiro objetivo no jogo foi ainda mais excitante e Ana utiliza o serviço de modo que possa observar o evento 30 minutos atrás. Depois de ter observado o objetivo, ela volta para o evento ao vivo.

[00260] Para solucionar esse caso de uso, o provedor de serviço deve poder atualizar a MPD, sinalizar para os clientes que uma MPD atualizada está disponível, e permite que os clientes acessem o serviço de sequenciamento de modo que possa apresentar os dados perto de tempo real.

[00261] A atualização da MPD é possível de forma assíncrona à distribuição de segmentos, como explicado aqui em outro lugar. O servidor pode fornecer garantia para o receptor que uma MPD não seja atualizada por algum tempo. O servidor pode se basear na MPD atual. No entanto, nenhuma sinalização explícita é necessária quando a MPD é atualizada antes de algum período de atualização mínimo.

[00262] A reprodução completamente sincronizada é dificilmente alcançada visto que o cliente pode operar em diferentes casos de atualização de MPD e, portanto, os clientes podem ter mudado. Utilizando-se as atualizações MPD, o servidor pode portar mudanças e os clientes podem ser alertados sobre as mudanças, mesmo durante uma apresentação. A sinalização em banda com base de segmento por segmento pode ser utilizada para indicar a atualização da MPD, de modo que as atualizações possam ser limitadas aos limites de segmento, mas que devem ser aceitáveis na maior parte das aplicações.

[00263] Um elemento MPD pode ser adicionado e fornece o tempo de publicação no tempo de relógio da MPD além de uma caixa de atualização de MPD opcional que é adicionada no começo dos segmentos para sinalizar que uma atualização MPD é necessária. As atualizações podem ser realizadas de forma hierárquica, como com as MPDs.

[00264] O "tempo de publicação" de MPD fornece um identificador singular para a MPD e quando a MPD foi emitida. Também fornece uma âncora para os procedimentos de atualização.

[00265] A caixa de atualização MPD pode ser encontrada na MPD depois da caixa "styp", e definida por um Tipo de Caixa = "mupe", não necessitando de qualquer recipiente, não sendo obrigatório e possuindo uma quantidade de zero ou um. A caixa de atualização MPD contém informação sobre a apresentação de mídia da qual o segmento é uma parte. Sintaxe ilustrativa é como se segue: aligned(8) class MPDUpdateBox extends FullBox('mupe'){ unsigned int(3) mpd information flags; unsigned int(1) new-location flag; unsigned int(28) latest_mpd_update time; /// Os seguintes são campos opcionais string mpd_location } A semântica de vários objetos da classe MPDUpdateBox deve ser como se segue: mpd_information_flags: OR lógico ou zero ou mais dos seguintes: 0x00 Atualizar Descrição de Apresentação de Mídia agora 0x01 Atualizar Descrição de Apresentação de Mídia mais adiante 0x02 Final de apresentação 0x03-0x07 reservado new_location flag: é determinado para 1, então a nova Descrição de Apresentação de Mídia é disponível em um novo local especificado em mpd_location. latest_mpd_update time: especifica o tempo (em ms) quando a atualização da MPD é necessária com relação ao tempo de emissão de MPD da última MPD. O cliente pode escolher atualizar a MPD a qualquer momento entre agora. mpd_location: está presente e se apenas se new_location_flag for configurado e se for esse o caso, mpd_location fornece um Localizador de Recurso Uniforme para a nova Descrição de Apresentação de Mídia.

[00266] Se a largura de banda utilizada pelas atualizações for um Visualização de Mudança de Tempo e PVR em Rede

[00267] Quando a visualização da mudança de tempo é suportada, pode acontecer de para a vida útil da sessão duas ou mais MPDs ou Cabeçalhos de Filme serem válidas. Nesse caso pela atualização da MPD quando necessário, mas adicionando o mecanismo de validade ou conceito de período, uma MPD válida possa existir para toda a janela de tempo. Isso significa que o servidor pode garantir que qualquer MPD e cabeçalho de filme sejam anunciados por qualquer período de tempo que esteja dentro da janela de tempo válida para a visualização de mudança de tempo. É obrigação do cliente garantir que sua MPD disponível e metadados para seu tempo de apresentação atual estejam validos. A migração de uma sessão ao vivo para uma sessão PVR de rede utilizando apenas atualizações MPD espelhadas também pode ser suportada. Segmentos de Mídia Especiais

[00268] Um problema quando o formato de arquivo ISO/IEC 14496-12 é utilizado dentro de um sistema de sequenciamento de solicitação de bloco é que, como descrito acima, pode ser vantajoso se armazenar os dados de mídia para uma única versão da apresentação em múltiplos arquivos, dispostos em segmentos de tempo consecutivos. Adicionalmente, pode ser vantajoso se dispor que cada arquivo comece com um Ponto de Acesso Randômico. Adicionalmente, pode ser vantajoso se escolher as posições dos pontos de busca durante o processo de codificação de vídeo e para segmentar a apresentação em múltiplos arquivos cada um começando com um ponto de busca com base na escolha dos pontos de busca que foram feitos durante o processo de codificação, onde cada Ponto de Acesso Randômico pode ou não ser localizado no começo de um arquivo, mas onde cada arquivo começa com um Ponto de Acesso Randômico. Em uma modalidade com as propriedades descritas acima, os metadados de apresentação, ou Descrição de Apresentação de Mídia, pode conter a duração exata de cada arquivo, onde a duração é tomada, por exemplo, como significando a diferença entre o momento inicial da mídia de vídeo de um arquivo e o momento inicial da mídia de vídeo do próximo arquivo. Com base nessa informação nos metadados de apresentação o cliente pode construir um mapeamento entre a linha de tempo global para a apresentação de mídia e a linha de tempo local para a mídia dentro de cada arquivo.

[00269] Em outra modalidade, o tamanho dos metadados de apresentação pode ser vantajosamente reduzido pela especificação ao invés de cada arquivo ou segmento possuir a mesma duração. No entanto, nesse caso, e onde os arquivos de mídia 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 mídia visto que um Ponto de Acesso Randômico pode não existir no ponto que é exatamente a duração especificada do começo do arquivo.

[00270] Uma modalidade adicional da invenção para fornecer a operação correta do sistema de sequenciamento de solicitação de bloco a despeito da discrepância mencionada acima é descrita agora. Nesse método, pode ser fornecido um elemento dentro de cada arquivo que específica o mapeamento da linha de tempo local de mídia dentro do arquivo (pela qual se deseja significar a linha de tempo começando a partir do selo de tempo zero contra o qual os selos de tempo de decodificação e composição das amostras de mídia no arquivo são especificados de acordo com ISO/IEC 1449612) para a linha de tempo de apresentação global. Essa informação de mapeamento pode compreender um único selo de tempo no tempo de apresentação global que corresponde ao selo de tempo zero na linha de tempo 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 selo de tempo zero na linha de tempo de arquivo local e o tempo de apresentação global correspondente ao início do arquivo de acordo com a informação fornecida nos metadados de apresentação.

[00271] Exemplo de tais caixas pode, por exemplo, ser a caixa de tempo de decodificação de fragmento de trilho ('tfdt') ou a caixa de ajuste de fragmento de trilho ('tfad') juntamente com a caixa de ajuste de mídia de fragmento de trilho ('tfma'). Cliente Ilustrativo incluindo Geração de Lista de Segmento

[00272] Um cliente ilustrativo é descrito agora. Pode ser utilizado como um cliente de referência para o servidor para garantir a geração adequada e atualizações da MPD.

[00273] Um cliente de sequenciamento HTTP é orientado pela informação fornecida na MPD. Considera-se que o cliente tenha acesso à MPD que é recebida no momento T, isso é, o tempo que foi capaz de receber com sucesso uma MPD. A determinação da recepção bem sucedida pode incluir o cliente obter uma MPD atualizada ou o cliente verificar que a MPD não foi atualizada desde a recepção bem sucedida anterior.

[00274] O comportamento de um cliente ilustrativo é introduzido. Para fornecer um serviço de sequenciamento contínuo para o usuário, o cliente primeiro analisa a MPD e cria uma lista de segmentos acessíveis para cada representação para o tempo local e cliente em um tempo de sistema atual, levando em consideração os procedimentos de geração de lista de segmento como detalhado abaixo possivelmente utilizando listas de reprodução ou utilizando regras de construção URL. Então, o cliente seleciona uma ou várias representações com base na informação nos atributos de representação e outras informações, pode exemplo, largura de banda disponível e capacidades de cliente. Dependendo do agrupamento representações podem ser apresentadas sozinhas ou em conjunto com outras representações.

[00275] Para cada representação, o cliente adquire metadados binários tal como cabeçalho 'moov' para a representação, se presente, e os segmentos de mídia das representações selecionadas. O cliente acessa o conteúdo de mídia pela solicitação de segmentos ou faixas de bytes de segmentos, possivelmente utilizando a lista de segmento. O cliente pode armazenar inicialmente mídia antes de iniciar a apresentação e, uma vez que a apresentação tenha começado, o cliente continua a consumir o conteúdo de mídia pela solicitação contínua de segmentos ou partes dos segmentos levando em consideração os procedimentos de atualização MPD.

[00276] O cliente pode comutar as representações levando em consideração a informação de MPD atualizada e/ou a informação atualizada a partir desse ambiente, por exemplo, mudança de largura de banda disponível. Com qualquer solicitação por um segmento de mídia contendo um ponto de acesso randômico, o cliente pode comutar para uma representação diferente. Quando movendo para frente, isso é, o tempo de sistema atual (referido como "momento AGORA" para representar o tempo relativo à apresentação) avançando, o cliente consome os segmentos acessíveis. Com cada avanço no tempo AGORA, o cliente possivelmente expande a lista de segmentos acessíveis para cada representação de acordo com os procedimentos especificados aqui.

[00277] Se o final da apresentação de mídia ainda não tiver sido alcançado e se o tempo de reprodução atual estiver dentro de um limite para o qual o cliente antecipa enviar mídia descrita na MPD para qualquer consumo ou para ser a representação, então o cliente pode solicitar uma atualização da MPD, com um novo tempo de recepção de tempo de coleta T. Uma vez recebido, o cliente então leva em consideração a MPD possivelmente atualizada e o novo tempo T na geração das listas de segmento acessíveis. A figura 29 ilustra um procedimento para serviços ao vivo em diferentes momentos no cliente. Geração de Lista de Segmento Acessível

[00278] Considera-se que o cliente de sequenciamento HTTP tenha acesso a uma MPD e possa desejar gerar uma lista de segmento acessível para um tempo de relógio AGORA. O cliente é sincronizado com uma referência de tempo global com determinada precisão, mas, vantajosamente, nenhuma sincronização direta com o servidor de sequenciamento HTTP é necessária.

[00279] A lista de segmento acessível para cada representação é preferivelmente definida como um par de listas de um tempo inicial de segmento e localizador de segmento onde o tempo inicial de segmento pode ser definido como sendo relativo ao começo da representação sem perda de generalidade. O começo da representação pode ser alinhado com o começo de um período ou se esse conceito for aplicado. Do contrário, o começo da representação pode ser no começo da apresentação de mídia.

[00280] O cliente utiliza as regras de construção de URL e temporização, por exemplo, como definido adicionalmente aqui. Uma vez que uma lista de segmentos descritos é obtida, essa lista é adicionalmente restrita aos acessíveis, que podem ser um subconjunto dos segmentos da apresentação de mídia completa. A construção é governada pelo valor atual do relógio no momento AGORA do cliente. Geralmente, os segmentos são apenas disponíveis para qualquer momento AGORA dentro de um conjunto de tempos de disponibilidade. Para momentos AGORA fora dessa janela, nenhum segmento está disponível. Adicionalmente, para serviços ao vivo, considera-se que o tempo de verificação forneça o eixo geométrico de tempo de mídia documentada por MPD; quando o tempo de reprodução do cliente alcança o tempo de verificação, e solicita vantajosamente uma nova MPD.

[00281] quando o tempo de reprodução do cliente alcança um tempo de verificação, o mesmo solicita vantajosamente uma nova MPD.

[00282] Então, a lista de segmento é adicionalmente restringida pelo tempo de verificação juntamente com o atributo MPD TimeShiftBufferDepth de modo que apenas os segmentos de mídia disponíveis sejam os para os quais a soma do momento inicial do segmento de mídia e o momento inicial de representação se encontram no intervalo entre AGORA menos TimeShiftBufferDepth menos a duração do último segmento descrito e o menor valor do tempo de verificação ou AGORA. Blocos Escalonáveis

[00283] Algumas vezes a largura de banda disponível se encontra tão baixa que o bloco ou blocos atualmente sendo recebidos em um receptor se tornam improváveis de serem completamente recebidos a tempo para serem reproduzidos sem pausa na apresentação. O receptor pode detectar tais situações antecipadamente. Por exemplo, o receptor pode determinar que está recebendo unidades de codificação de blocos 5 de mídia a cada 6 unidades de tempo, e possui um armazenador de 4 unidades de mídia, de modo que o receptor possa esperar ter uma interrupção, uma pausa na apresentação cerca de 24 unidades de tempo depois. Com aviso suficiente, o recepto pode reagir a tal situação, por exemplo, abandonando a sequência atual de blocos e começando a solicitar um bloco ou blocos de uma representação diferente de conteúdo, tal como um que utilize menos largura de banda por unidade de tempo de reprodução. Por exemplo, se o receptor tiver comutado para uma representação onde os blocos codificados para pelo menos 20% a mais de tempo de vídeo para o mesmo tamanho de bloco, o receptor pode ser capaz de eliminar a necessidade de interromper até que a situação da largura de banda seja aperfeiçoada.

[00284] No entanto, pode ser um desperdício fazer com que o receptor descarte completamente os dados já recebidos da representação abandonada. Em uma modalidade de um sistema de sequenciamento de bloco descrito aqui, os dados dentro de cada bloco podem ser codificados e dispostos de tal forma que determinados prefixos de dados dentro do bloco possam ser utilizados para continuar a apresentação sem o restante do bloco ter sido recebido. Por exemplo, as técnicas bem conhecidas de codificação de vídeo escalonável podem ser utilizadas. Exemplos de tais métodos de codificação de vídeo incluem a Codificação de Vídeo Escalonável H.264 (SVC) ou a capacidade de escalonamento temporal de Codificação de Vídeo Avançado H.264 (AVC). Vantajosamente, esse método permite que a apresentação continue com base na parte de um bloco que foi recebido mesmo quando a recepção de um bloco ou blocos pode ser abandonada, por exemplo, devido às mudanças na largura de banda disponível. Outra vantagem é que um único arquivo de dados pode ser utilizado como a fonte para múltiplas representações diferentes do conteúdo. É possível, por exemplo, pela utilização de solicitações GET parciais HTTP para selecionam o subconjunto de um bloco correspondendo à representação necessária.

[00285] Um aperfeiçoamento detalhado aqui é um segmento melhorado, um mapa de segmento escalonável. O mapa de segmento escalonável contém as localizações de diferentes camadas no segmento de modo que o cliente possa acessar as partes dos segmentos de acordo e extrair as camadas. Em outra modalidade, os dados de mídia no segmento são ordenados de modo que a qualidade do segmento seja crescente enquanto realiza o download de dados gradualmente a partir do começo do segmento. Em outra modalidade, o aumento gradual da qualidade é aplicado para cada bloco ou fragmento contido no segmento, de modo que as solicitações de fragmento possam ser feitas para solucionar a abordagem escalonável.

[00286] A figura 12 é uma figura ilustrando um aspecto dos blocos escalonáveis. Nessa figura, um transmissor 1200 envia metadados 1202, a camada escalonável 1 (1204), a camada escalonável 2 (1206), e a camada escalonável 3 (1208), com a última sendo retardada. Um recepto 1210 pode então utilizar metadados 1202, a camada escalonável 1 (1204), e a camada escalonável 2 (1206) para apresentar apresentação de mídia 1212. Camadas de Capacidade de Escalonamento Independentes

[00287] Como explicado acima, é indesejável que um sistema de sequenciamento de solicitação de bloco precise interromper quando o receptor é incapaz de receber os blocos solicitados de uma representação específica dos dados de mídia a tempo para sua reprodução, visto que isso cria frequentemente uma experiência de usuário ruim. As interrupções podem ser evitadas, reduzidas ou mitigadas pela restrição de uma taxa de dados das representações escolhida para ser muito menor do que a largura de banda disponível, de modo que se torne muito provável que qualquer parte determinada da apresentação não seja recebida a tempo, mas essa estratégia tem a desvantagem de a qualidade de mídia ser necessariamente muito mais baixa do que poderia a principio ser suportado pela largura de banda disponível. Uma apresentação de qualidade inferior que é possível também pode ser interpretada como uma experiência de usuário ruim. Dessa forma, o projetista de um sistema de sequenciamento de solicitação de bloco se depara com uma escolha no desenho dos procedimentos de cliente, programação do cliente ou configuração de hardware, para solicitar uma versão de conteúdo que possui uma taxa de dados muito inferior à largura de banda disponível, caso no qual o usuário pode sofrer de baixa qualidade de mídia, ou solicitar uma versão de conteúdo que possua uma taxa de dados próxima da largura de banda disponível, caso no qual o usuário pode sofrer uma alta probabilidade de pausas durante a apresentação à medida que a largura de banda disponível muda.

[00288] Para manusear tais situações, os sistemas de sequenciamento de bloco descritos aqui podem ser configurados para manusear múltiplas camadas de capacidade de escalonamento independentemente, de modo que um receptor possa realizar solicitações em camadas e um transmissor possa responder às solicitações em camada.

[00289] Em tais modalidades, os dados de mídia codificados para cada bloco podem ser divididos em múltiplas peças separadas, referidas aqui como "camadas", de modo que uma combinação de camadas compreenda todos os dados de mídia para um bloco de modo que um cliente que tenha recebido determinados subconjuntos de camadas possa realizar a decodificação e apresentação de uma representação do conteúdo. Nessa abordagem, a ordenação dos dados na sequência é tal que as faixas contíguas estão aumentando em qualidade e os metadados refletem isso.

[00290] Um exemplo de uma técnica que pode ser utilizada para gerar camadas com a propriedade acima é a técnica SVC, por exemplo, como descrito nos padrões ITU-T H.264/SVC. Outro exemplo de uma técnica que pode ser utilizada para gerar camadas com a propriedade acima é a técnica de camadas de capacidade de escalonamento temporal fornecidas no padrão ITU-T H.264/AVC.

[00291] Nessas modalidades, os metadados podem ser fornecidos na MPD ou no segmento propriamente dito que permite a construção de solicitações para camadas individuais de qualquer bloco determinado e/ou combinações de camadas e/ou uma determinada camada de múltiplos blocos e/ou uma combinação de camadas de múltiplos blocos. Por exemplo, as camadas compreendendo um bloco podem ser armazenadas dentro de um arquivo único e metadados podem ser fornecidos especificando as faixas de byte dentro do arquivo correspondendo ás camadas individuais.

[00292] Um protocolo de download de arquivo capaz de especificar as faixas de byte, por exemplo, HTTP 1.1, pode ser utilizado para solicitar as camadas individuais ou múltiplas camadas. Adicionalmente, como será claro para os versados na técnica mediante revisão dessa descrição, as técnicas descritas acima pertencentes à construção, solicitação e download de blocos de tamanho variável e combinações variáveis de blocos podem ser aplicadas nesse contexto também. Combinações

[00293] Um número de modalidades é agora descrito que pode ser vantajosamente empregado por um cliente de sequenciamento de solicitação de bloco a fim de alcançar um aperfeiçoamento na experiência de usuário e/ou uma redução nas exigências de capacidade de infraestrutura servidora em comparação com as técnicas existentes pelo uso de dados de mídia divididos em camadas como descrito acima.

[00294] Em uma primeira modalidade, as técnicas conhecidas de um sistema de sequenciamento de solicitação de bloco podem ser aplicadas com a modificação que versões diferentes do conteúdo sejam em alguns casos substituídas por combinações diferentes de camadas. Isso é, onde um sistema existente pode fornecer duas representações distintas de conteúdo o sistema aperfeiçoado descrito aqui pode fornecer duas camadas, onde uma representação do conteúdo no sistema existente é similar em taxa de bit, qualidade e possivelmente outras métrica à primeira camada no sistema aperfeiçoado e a segunda representação do conteúdo no sistema existente é similar em taxa de bit, qualidade e possivelmente outras métricas à combinação disso, a capacidade de armazenamento necessária dentro do sistema aperfeiçoado é reduzida em comparação com a necessária no sistema existente. Adicionalmente, ao passo que os clientes do sistema existente podem emitir solicitações para blocos de uma representação ou outra representação, clientes do sistema aperfeiçoado podem emitir solicitações para a primeira ou ambas as camadas de um bloco. Como resultado disso, a experiência de usuário nos dois sistemas é similar. Adicionalmente, o armazenamento temporário aperfeiçoado é fornecido mesmo para segmentos comuns de qualidades diferentes utilizados que são então armazenados temporariamente com maior probabilidade.

[00295] Em uma segunda modalidade um cliente em um sistema de sequenciamento de solicitação de bloco aperfeiçoado empregando o método de camadas descrito agora pode manter um armazenador de dados separado para cada uma das várias camadas de codificação de mídia. Como estará claro para os versados na técnica de gerenciamento de dados dentro dos dispositivos de cliente, esses armazenadores "separados" podem ser implementados por alocação de regiões de memória física e logicamente separadas para os armazenadores separados ou por outras técnicas nas quais os dados armazenados são armazenados em uma única região ou várias regiões de memória e a separação de dados de camadas diferentes é alcançada logicamente através do uso de estruturas de dados que contêm referências às localizações de armazenamento de dados a partir de camadas separadas e, logo, a seguir, o termo "armazenadores separados" devem ser compreendidos como incluindo qualquer método no qual os dados de camadas distintas podem ser identificados separadamente. O cliente emite solicitações por 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 modo que uma solicitação por dados de uma camada não possa ser emitida se a ocupação de qualquer armazenador para uma camada inferior na ordem de prioridade estiver abaixo de um limite para essa camada inferior. Nesse método, a prioridade é fornecida para o recebimento de dados a partir das camadas inferiores na ordem de prioridade de modo que se a largura de banda disponível se encontrar abaixo do necessário para também receber camadas superiores na ordem de prioridade então apenas as camadas inferiores são solicitadas. Adicionalmente, os limites associados com as diferentes camadas podem ser diferentes, de modo que, por exemplo, as camadas inferiores tenham limites mais altos. No caso de a largura de banda disponível mudar de modo que os dados para uma camada superior não possam ser recebidos antes do tempo de reprodução do bloco, então os dados para as camadas inferiores já terão sido necessariamente recebidos e, logo, a apresentação pode continuar com camadas inferiores apenas. Os limites para a ocupação do 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 adequada.

[00296] Em uma terceira modalidade, os métodos das primeira e segunda modalidades podem ser combinados de modo que sejam fornecidas várias representações de mídia cada uma compreendendo um subconjunto de camadas (como na primeira modalidade) e de forma que a segunda modalidade seja aplicada a um subconjunto de camadas dentro de uma representação.

[00297] Em uma quarta modalidade os métodos das primeira, segunda e/ou terceira modalidades podem ser configurados com a modalidade onde múltiplas representações independentes do conteúdo são fornecidas de modo que, por exemplo, pelo menos uma das representações independentes compreenda múltiplas camadas às quais as técnica das primeira, segunda e/ou terceira modalidades são aplicadas. Gerenciador de Armazenador Avançado

[00298] Em combinação com o monitor de armazenador 126 (ver figura 2), um gerenciador de armazenador avançado pode ser utilizado para otimizar um armazenador de lado de cliente. Os sistemas de sequenciamento de solicitação de bloco desejam garantir que a reprodução de mídia possa iniciar rapidamente e continuar suavemente, enquanto fornece simultaneamente a qualidade máxima de mídia para o usuário ou dispositivo de destino. Isso pode exigir que o cliente solicite blocos que possuam a qualidade de mídia mais alta, mas que também possam ser iniciados rapidamente e recebidos a tempo para serem reproduzidos sem forçar uma pausa na apresentação.

[00299] Nas modalidades que utilizam o gerenciador de armazenamento avançado, o gerenciador determina quais blocos de dados de mídia solicitar e quando se realizar essas solicitações. Um gerenciador de armazenador avançado pode, por exemplo, ser fornecido com um conjunto de metadados para o conteúdo a ser apresentado, esses metadados incluindo uma lista de representações disponíveis para o conteúdo e metadados para cada representação. Os metadados para uma representação podem compreender informação sobre a taxa de dados de representação e outros parâmetros, tal como vídeo, áudio e outros codecs e parâmetros de codec, resolução de vídeo, complexidade de decodificação, linguagem de áudio e quaisquer outros parâmetros que possam afetar a escolha de representação no cliente.

[00300] Os metadados para uma representação também podem compreender identificadores para os blocos nos quais a representação foi segmentada, esses identificadores fornecendo informação necessária para o cliente para solicitação de um bloco. Por exemplo, onde o protocolo de solicitação é HTTP, o identificador pode ser um URL HTTP possivelmente juntamente com informação adicional identificando uma faixa de byte ou abrangência de tempo dentro do arquivo identificado pelo URL, essa faixa de byte ou abrangência de tempo identificando o bloco específico dentro do arquivo identificado pelo URL.

[00301] Em uma implementação específica, o gerenciador de armazenador avançado determina quando um receptor faz uma solicitação por novos blocos e pode manusear o envio de solicitações. Em um aspecto novo, o gerenciador de armazenador avançado realiza as solicitações por novos blocos de acordo com o valor de uma razão de equilíbrio que equilibra entre a utilização de muita largura de banda e a falta de mídia durante uma reprodução de sequenciamento.

[00302] A informação recebida pelo monitor de armazenamento 126 a partir do armazenador de bloco 125 pode incluir indicações de cada evento quando os dados de mídia são recebidos, quanto foi recebido, quando a reprodução dos dados de mídia teve início ou térmico, e a velocidade de reprodução de mídia. Com base nessa informação, o monitor de armazenamento 126 pode calcular uma variável representando um tamanho de armazenador atual, Bcurrent. Nesses exemplos, Bcurrent representa a quantidade de mídia contida em um cliente ou outro armazenador ou armazenadores de dispositivo e pode ser medida em unidades de tempo de modo que Bcurrent represente a quantidade de tempo que leva para se reproduzir toda a mídia representada pelos blocos ou blocos parciais armazenados no armazenador ou armazenadores se nenhum bloco adicional ou blocos parciais forem recebidos. Dessa forma, Bcurrent representa a "duração de reprodução", com velocidade de reprodução normal, de dados de mídia disponíveis no cliente, mas ainda não reproduzidos.

[00303] À medida que o tempo passa, o valor de Bcurrent diminuirá à medida que a mídia é reproduzida e pode aumentar cada vez que novos dados para um bloco são recebidos. Note-se que, para fins dessa explicação, considera-se que um bloco seja recebido quando todos os dados desse blocos estão disponíveis no solicitante de bloco 124, mas outras medidas podem ser utilizadas ao invés, por exemplo, de se levar em consideração a recepção de blocos parciais. Na prática, a recepção de um bloco pode ocorrer através de um período de tempo.

[00304] A figura 13 ilustra uma variação do valor de Bcurrent com o tempo, à medida que mídia é reproduzida e os blocos são recebidos. Como ilustrado na figura 13, o valor de Bcurrent é igual a zero para momentos inferiores a t0, indicando que nenhum dado foi recebido. Em t0, o primeiro bloco é recebido e o valor de Bcurrent aumenta para igual à duração de reprodução do bloco recebido. Nesse momento, a reprodução ainda não foi iniciada e o valor de Bcurrent permanece constante, até o momento t1, onde um segundo bloco chega e Bcurrent aumenta pelo tamanho desse segundo bloco. Nesse momento, a reprodução começa e o valor de Bcurrent começa a diminuir de forma linear, até o momento t2 quando um terceiro bloco chega.

[00305] A progressão de Bcurrent continua nessa forma de "dente de serra", aumentando cada vez que um bloco é recebido (nos momentos t2, t3, t4, t5 e t6) e diminuindo suavemente à medida que os dados são reproduzidos. Note-se que nesse exemplo, a reprodução prossegue em uma taxa de reprodução normal para o conteúdo e dessa forma a inclinação da curva entre a recepção de bloco é exatamente -1, significando que um segundo de dados de mídia é reproduzido para cada segundo de tempo real que passa. Com a mídia com base em quadro reproduzida em um determinado número de quadros por segundo, por exemplo 24 quadros por segundo, a inclinação de -1 será aproximada por funções de pequeno escalonamento que indicam a reprodução de cada quadro de dados individual, por exemplo, etapas de -1/24 de um segundo quando cada quadro é reproduzido.

[00306] A figura 14 ilustra outro exemplo da evolução de Bcurrent através do tempo. Nesse exemplo, o primeiro bloco chega em t0 e a reprodução tem início imediatamente. A chegada do bloco e a reprodução continuam até o momento t3, onde o valor de Bcurrent alcança zero. Quando isso acontece, nenhum dado de mídia adicional está disponível para reprodução, forçando uma pausa na apresentação de mídia. No momento t4, um quarto bloco é recebido e a reprodução pode ser retomada. Esse exemplo, portanto, ilustra um caso no qual a recepção do quarto bloco foi depois do desejado, resultando em uma pausa na reprodução e, dessa forma, em uma experiência de usuário ruim. Dessa forma, um objetivo do gerenciador de armazenador avançado e outras características é a redução da probabilidade desse evento, enquanto se mantém simultaneamente a alta qualidade de mídia.

[00307] O monitor de armazenamento 126 também pode calcular outra métrica, Bratio(t), que é a razão de mídia recebida em um determinado período de tempo para o comprimento do período de tempo. Mais especificamente, Bratio(t) é igual a Treceived/(Tnow-t), onde Treceived é a quantidade de mídia (medida por seu tempo de reprodução) recebida no período de tempo de t, algum tempo antes do tempo atual até o tempo atual, Tnow.

[00308] Bratio(t) pode ser utilizado para medir a taxa de mudança de Bcurrent. Bratio(t)=0 é o caso onde nenhum dado foi recebido desde o momento t; Bcurrent terá sido reduzido (Tnow- t) desde esse momento, assumindo-se que a mídia esteja sendo reproduzida. Bratio(t)=1 é o caso no qual a mídia é recebida na mesma quantidade que está sendo reproduzida, para o momento (Tnow-t); Bcurrent terá o mesmo valor que o momento Tnow como no momento t. Bratio(t)>1 é o caso onde mais dados foram recebidos que o necessário para reprodução par ao momento (Tnow -t); Bcurrent terá aumentado desde o momento t par ao momento Tnow.

[00309] O monitor de armazenamento 126 calcula adicionalmente um valor de State, que pode assumir um número discreto de valores. O monitor de armazenamento 126 é adicionalmente equipado com uma função, NewState(Bcurrent, Bratio) que, de acordo com o valor atual de Bcurrent e os valores de Bratio para t<Tnow, fornece um novo valor de State como saída. Toda vez que Bcurrent e Bratio fazem com que essa função retorne um valor diferente do valor atual de State, o novo valor é designado para State e esse novo valor de State indicado para o seletor de bloco 123.

[00310] A função NewState pode ser avaliada com referência ao espaço de todos os possíveis valores do par (Bcurrent, Bratio(Tnow-Tx)) onde Tx pode ser um valor fixo (configurado), ou pode ser derivado de Bcurrent, por exemplo, por uma tabela de configuração que mapeia dos valores de B current para valores de Tx, ou pode depender do valor anterior de State. O monitor de armazenador 126 é suprido com uma ou mais divisões desse espaço, onde cada divisão compreende conjuntos de regiões separadas, cada região sendo anotada com um valor State. A avaliação da função NewState então compreende a operação de identificação de uma divisão e determinação da região na qual o par (Bcurrent, Bratio (Tnow-Tx)) se encontra. O valor de retorno é então a anotação associada com essa região. Em um caso simples, apenas uma divisão é fornecida. Em um caso mais complexo, a divisão pode depender do par (Bcurrent, Bratio(Tnow-Tx)) no mo mento anterior de avaliação da função NewState ou outros fatores.

[00311] Em uma modalidade específica, a divisão descrita acima pode ser baseada em uma tabela de configuração contendo um número de valores limite para Bcurrent e um número de valores limite para Bratio. Especificamente, considera-se os valores limite para Bcurrent como Bthresh(0)=0, Bthresh(1),...,Bthresh(ni), Bthresh(ni+1) = ~, onde n2 é o número de valores limite para Bratio. Esses valores limite definem uma divisão compreendendo uma grade de células (n1+1) por (n 2+1), onde a célula i da fileira j corresponde à região na qual Bt resh (i-1)<=B current< Btresh(i) e Br-thresh(j-1)<= Bratio<Br-thresh(j). Cada célula da grade descrita acima é anotada com um valor de state, tal como sendo associada com valores particulares armazenados na memória e a função NewState então retorna para o valor de estado associado com a célula indicada pelos valores Bcurrent e Bratio(Tnow-Tx).

[00312] Em uma modalidade adicional, um valor de histerese pode ser associado com cada valor limite. Nesse método melhorado, a avaliação da função NewState pode ser baseada em uma divisão temporária construída utilizando um conjunto de valores limite modificados temporariamente, como se segue. Para cada valor Bcurrent limite que é inferior à faixa de Bcurrent correspondente à célula escolhida na última avaliação de NewState, o valor limite é reduzido pela subtração do valor de histerese associado com esse limite. Para cada valor limite Bcurrent superior à faixa Bcurrent correspondente à célula escolhida na última avaliação de NewState, o valor limite é aumentado pela adição do valor de histerese associado com esse limite. Para cada valor limite Bratio que é inferior à faixa Bratio correspondente à célula escolhida na última avaliação de NewState, o valor limite é reduzido pela subtração do valor de histerese associado com esse limite. Para cada valor limite Bratio que é superior à faixa Bratio correspondendo à célula escolhida na última avaliação de NewState, o valor limite é aumentado pela adição de valor de histerese associado a esse limite. Os valores limite modificados são utilizados para avaliar o valor de NewState e então os valores limite são retornados para seus valores originais.

[00313] Outra formas de definição de divisões de espaço serão óbvios aos versados na técnica mediante leitura dessa descrição. Por exemplo, uma divisão pode ser definida pelo uso de desigualdades com base nas combinações lineares de Bratio e Bcurrent, por exemplo, limites de desigualdade linear da forma α1*Bratio+α2*Bcurrent^α0 para α0 de valor real, α1 e α2, para definir meios espaços dentro do espaço geral e definindo cada conjunto separado como a interseção de um número de tais meios espaços.

[00314] A descrição acima é ilustrativa do processo básico. Como será claro para os versados na técnica de programação em tempo real depois da leitura dessa descrição, as implementações eficientes são possíveis. Por exemplo, em cada momento que nova informação é fornecida para o monitor de armazenador 126, é possível se calcular o tempo futuro no qual NewState transitará para um novo valor se, por exemplo, nenhum dado adicional para blocos for recebido. Um temporizador é então configurado para esse momento e na ausência de expiração de entradas adicionais desse temporizador faz com que o novo valor de State seja enviado para o seletor de bloco 123. Como resultado disso, as computações só precisam ser realizadas quando nova informação é fornecida para o monitor de armazenador 126 ou quando um temporizador expira, ao invés de continuamente.

[00315] Valores adequados de State podem ser "Baixo", "Estável" e "Completo". Um exemplo de um conjunto adequado de valores limite e a grade de célula resultante é ilustrada na figura 15.

[00316] Na figura 15, os limites Bcurrent são ilustrados no eixo geométrico horizontal em milissegundos, com valores de histerese ilustrados abaixo de "+/- valor". Os limites Bratio são ilustrados no eixo geométrico vertical por mil (isso é, multiplicado por 1000) com os valores de histerese ilustrados abaixo como "+/- valor". Os valores de estado são anotados nas células de grade como "L", "S" e "F" para "Baixo", "Estável" e "Total", respectivamente.

[00317] O seletor de bloco 123 recebe notificações do solicitante de bloco 124 sempre que houver uma oportunidade de se solicitar um novo bloco. Como descrito acima, o seletor de bloco 123 é fornecido com informação quanto à pluralidade de blocos disponíveis e metadados para esses blocos, incluindo, por exemplo, a informação sobre a taxa de dados de mídia de cada bloco.

[00318] A informação sobre a taxa de dados de mídia de um bloco pode compreender a taxa de dados de mídia real do bloco específico (isso é, o tamanho de bloco em bytes dividido pelo tempo de reprodução em segundos), a taxa de dados de mídia média da representação à qual o bloco pertence de uma medição de largura de banda disponível necessária, em base sustentada, para produção da representação à qual o bloco pertence sem pausas, ou uma combinação do acima.

[00319] O seletor de bloco 123 seleciona os blocos com base no valor de State indicado por último pelo monitor de armazenador 126. Quando esse valor de State é "Estável", o seletor de bloco 123 seleciona um bloco a partir da mesma representação que o bloco selecionado anteriormente. O bloco selecionado é o primeiro bloco (na ordem de reprodução) contendo dados de mídia para um período de tempo na apresentação para o qual nenhum dado de mídia foi previamente solicitado.

[00320] Quando o valor State é "Baixo", o seletor de bloco 123 seleciona um bloco de uma representação com uma taxa de dados de mídia mais baixa do que a do bloco selecionado anteriormente. Um número de fatores pode influenciar a escolha exata da representação nesse caso. Por exemplo, o seletor de bloco 123 pode ser fornecido com uma indicação da taxa agregada de dados de entrada e pode escolher uma representação com uma taxa de dados de mídia que seja inferior a esse valor.

[00321] Quando o valor State é "Total", o seletor de bloco 123 seleciona um bloco a partir de uma representação com uma taxa de dados de mídia maior do que a do bloco selecionado previamente. Um número de fatores pode influenciar a escolha exata de representação nesse caso. Por exemplo, o seletor de bloco 123 pode ser fornecido com uma indicação da taxa de agregado dos dados de entrada e pode escolher uma representação com uma taxa de dados de mídia que não é maior que esse valor.

[00322] Vários fatores adicionais podem influenciar adicionalmente a operação do seletor de bloco 123. Em particular, a frequência com a qual a taxa de dados de mídia do bloco selecionado é aumentada pode ser limitada, mesmo se o monitor de armazenador 126 continuar a indicar o estado "total". Adicionalmente, é possível que o seletor de b loco 123 receba uma indicação de estado "total" mas não haja qualquer bloco de taxa de dados de mídia superior disponível (por exemplo, visto que o último bloco selecionado já foi para a taxa de dados de mídia disponível mais alta). Nesse caso, o seletor de bloco 123 pode retardar a seleção do próximo bloco por um tempo escolhido de modo que a quantidade geral de dados de mídia armazenados no armazenador de bloco 125 seja limitado acima.

[00323] Fatores adicionais 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 aos das representações cuja resolução de codificação se encontra dentro da faixa específica fornecida para o seletor de bloco 123.

[00324] O seletor de bloco 123 também pode receber entradas de outros componentes que monitoram outros aspecto do sistema, tal como disponibilidade de recursos de computação para decodificação de mídia. Se tais recursos se tornarem escassos, o seletor de bloco 123 pode escolher blocos cuja decodificação é indicada como sendo a complexidade computacional inferior dentro dos metadados (por exemplo, representações com resolução mais baixa, ou taxa de quadro são geralmente de complexidade de decodificação mais baixa).

[00325] A modalidade descrita acima traz uma vantagem substancial pelo fato de o uso do valor Bratio na avaliação da função NewState dentro do monitor de armazenador 126 permite um aumento maior na qualidade no início da apresentação em comparação com um método que considera apenas Bcurrent. Sem considerar Bratio, uma grande quantidade de dados armazenados pode ser acumulada antes de o sistema ser capaz de selecionar os blocos com uma taxa de dados de mídia maior e, dessa forma, uma maior qualidade. No entanto, quando o valor de Bratio é grande, isso indica que a largura de banda disponível é muito maior do que a taxa de dados de mídia dos blocos recebidos previamente e que mesmo com relativamente poucos dados armazenados (isso é, valor baixo de Bcurrent), permanece seguro se solicitar blocos de taxa de dados de mídia mais altos e, dessa forma, maior qualidade. Igualmente, se o valor de Bratio for baixo (<1, por exemplo) isso indica que a largura de banda disponível caiu abaixo da taxa de dados de mídia dos blocos previamente solicitados e, dessas forma, mesmo se Bcurrent for alto, o sistema comutará para uma taxa de dados de mídia mais baixa e, dessa forma, uma qualidade mais baixa, por exemplo, para evitar alcançar o ponto onde Bcurrent-0 e a reprodução de interrupções de mídia. Esse comportamento aperfeiçoado pode ser especialmente importante em ambientes onde as condições de rede e, dessa forma, velocidades de distribuição podem variar rapidamente e dinamicamente, por exemplo, usuários sequenciando dispositivos móveis.

[00326] Outra vantagem é conferida pelo uso dos dados de configuração para especificar a divisão do espaço de valores de (Bcurrent Bratio). Tais dados de configuração podem ser fornecidos para monitorar o armazenador 126 como parte dos metadados de apresentação ou por outros meios dinâmicos. Visto que nos desenvolvimentos práticos, o comportamento das conexões de rede de usuário podem ser altamente variáveis entre usuários e com o tempo para um único usuário, pode ser difícil se prever as divisões que funcionarão para todos os usuários. A possibilidade de se fornecer tal informação de configuração para usuários dinamicamente permite que boas configurações sejam desenvolvidas com o tempo de acordo com a experiência acumulada. Dimensionamento de Solicitação Variável

[00327] Uma alta frequência de solicitações pode ser necessária se cada solicitação for um único bloco e cada bloco codificar um segmento de mídia curto. Se os blocos de mídia forem curtos, a reprodução de vídeo está movendo de bloco para bloco rapidamente, o que fornece oportunidades mais frequentes para o receptor de ajustar ou alterar sua taxa de dados selecionada pela alteração da representação, aperfeiçoamento da probabilidade de a reprodução poder continuar sem interrupções. No entanto, uma desvantagem para uma alta frequência de solicitações é que as mesmas podem não ser sustentáveis em determinadas redes onde a largura de banda disponível é restrita na rede de cliente para servidor, por exemplo, nas redes WAN tal como WANs sem fio 3G e 4G, onde a capacidade do link de dados do cliente para a rede é limitada ou pode se tornar limitada por períodos de tempo curtos ou longos devido às mudanças nas condições de rádio.

[00328] Uma frequência alta de solicitações também implica em uma alta carga na infraestrutura servidora, que resulta em custos associados em termos de exigências de capacidade. Dessa forma, seria desejável se ter alguns dos benefícios de uma alta frequência de solicitações sem todas as suas desvantagens.

[00329] Em algumas modalidades de um sistema de sequenciamento de bloco, a flexibilidade de alta frequência de solicitação é combinada com solicitações menos frequentes. Nessa modalidade, os blocos podem ser construídos como descrito acima e agregados em segmentos contendo múltiplos blocos, também descritos acima. No começo da apresentação, os processos descritos acima nos quais cada solicitação faz referência a solicitações a um único bloco ou múltiplos blocos simultâneos são realizados para solicitar partes de um bloco que são aplicadas para garantir um tempo de zapping de canal rápido e, portanto, uma boa experiência de usuário no início da apresentação. Subsequentemente, quando uma determinada condição, a ser descrita abaixo, é correspondida, o cliente pode emitir solicitações que englobam múltiplos blocos em uma única solicitação. Isso é possível porque os blocos foram agregados em grandes arquivos ou segmentos e podem ser solicitados utilizando-se faixas de tempo ou byte. Faixas de byte ou tempo consecutivas podem ser agregadas em uma única faixa de byte e tempo maior em uma única solicitação para múltiplos blocos, e mesmo blocos descontínuos podem ser solicitados em uma solicitação.

[00330] Uma configuração básica que pode ser acionada pela decisão de se se solicita um único bloco (ou um bloco parcial) ou se solicita múltiplos blocos consecutivos é se fazer com que a configuração baseie a decisão de se ou não os blocos solicitados devem ser reproduzidos ou não. Por exemplo, é provável que haja a necessidade de se mudar para outra apresentação logo, então é melhor que o cliente solicite blocos unitários, isso é, pequenas quantidades de dados de mídia. Uma razão para isso é que se uma solicitação por múltiplos blocos for feita quando um comutador para outra apresentação pode estar iminente é que a comutação pode ser feita antes de os últimos poucos blocos da solicitação serem reproduzidos. Dessa forma, o download desses últimos poucos blocos pode retardar a distribuição dos dados de mídia da representação à qual a comutação é feita, o que pode causar interrupções de reprodução de mídia.

[00331] No entanto, as solicitações por blocos únicos resultam em uma frequência maior de solicitações. Por outro lado, se for improvável que haja uma necessidade de se mudar para outra representação logo, então pode ser preferível se fazer solicitações para múltiplos blocos, visto que todos esses blocos devem ser reproduzidos, e isso resulta em uma frequência de solicitações mais baixa, que pode reduzir substancialmente o overhead de solicitação, especialmente se for típico que não há mudança iminente na representação.

[00332] Nos sistemas de agregação de bloco convencionais, a quantidade solicitada em cada solicitação não é dinamicamente ajustada, isso é, tipicamente, cada solicitação é para todo um arquivo, ou cada solicitação é para aproximadamente a mesma quantidade de arquivo de uma representação (algumas vezes medido em tempo, algumas vezes em bytes). Dessa forma, se todas as solicitações forem menores, então o overhead de solicitação é alto, ao passo que se todas as solicitações forem maiores, então isso aumenta as chances de eventos de interrupção de mídia, e/ou fornecimento de uma qualidade inferior de reprodução de mídia se as representações de qualidade inferior forem escolhidas para evitar ter que mudar rapidamente as representações à medida que as condições de rede variam.

[00333] Um exemplo de uma condição que, quando correspondida, pode causar solicitações subsequentes para múltiplos blocos de referência, é um limite no tamanho de armazenador, Bcurrent. Se Bcurrent estiver abaixo do limite, então cada solicitação emitida faz referência a um único bloco. Se Bcurrent for superior a ou igual ao limite, então cada solicitação expedida faz referência a múltiplos blocos. Se uma solicitação for emitida com referência a múltiplos blocos, então o número de blocos solicitado em cada solicitação única pode ser determinado em uma dentre várias formas. Por exemplo, o número pode ser constante, por exemplo, dois. Alternativamente, o número de blocos solicitados em uma única solicitação pode depender do estado do armazenador e em particular de Bcurrent. Por exemplo, vários limites podem ser determinados, com o número de blocos solicitados em uma única solicitação sendo derivado do mais alto dos múltiplos limites que é inferior a Bcurrent.

[00334] Outro exemplo de uma condição que, quando correspondida, pode fazer com que as solicitações façam referência a múltiplos blocos é o valor State variável descrito acima. Por exemplo, quando State é "Estável" ou "Total" então solicitações podem ser emitidas para múltiplos blocos, mas quando State é "Baixo", então todas s solicitações podem ser para um bloco.

[00335] Outra modalidade é ilustrada na figura 16. Nessa modalidade, quando a próxima solicitação está para ser emitida (determinado na etapa 1300), o valor atual State e Bcurrent são utilizados para determinar o tamanho da próxima solicitação. Se o valor atual State for "Baixo" ou o valor atual State for "Total" e a representação atual não for a mais alta disponível (determinado na etapa 1310, resposta sendo "Sim"), então a próxima solicitação é escolhida para ser curta, por exemplo, apenas para o próximo bloco (bloco determinado e solicitação realizada na etapa 1320). A racionalização por trás disso é que essas são condições onde é provável que bem cedo haja uma mudança nas representações. Se o valor atual State for "Estável" ou o valor atual State for "total" e a representação atual for a mais alta possível (determinado pela etapa 1310, resposta sendo "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 Bcurrent para algum fixo α<1 (blocos determinados na etapa 1330, solicitação feita na etapa 1340), por exemplo, com α=0,4 se Bcurrent=5 segundos, então a próxima solicitação pode ser para aproximadamente 2 segundos de blocos, ao passo que se Bcurrent-10 segundos, então a próxima solicitação pode ser para aproximadamente 4 segundos de blocos. Uma racionalização para isso é que nessas condições pode ser improvável que uma comutação para uma nova representação seja feita para uma quantidade de tempo que seja proporcional a Bcurrent. Sequenciamento Flexível

[00336] Os sistemas de sequenciamento de bloco podem utilizar um protocolo de solicitação de arquivo que possui um protocolo de transporte subjacente particular, por exemplo, TCP/IP. No começo de um protocolo TCP/IP ou outra conexão de protocolo de transporte, pode levar um tempo considerável para se alcançar a utilização de toda a largura de banda 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 a transferência TPC inicial estabelecer a conexão e o tempo que leva para o protocolo de controle de congestionamento alcançar a utilização total da largura de banda disponível.

[00337] Nesse caso, pode ser desejável se emitir múltiplas solicitações utilizando-se uma unida conexão, a fim de se reduzir a frequência com a qual a penalidade de inicialização de conexão é incorrida. No entanto, alguns protocolos de transporte de arquivo, por exemplo, HTTP, não fornecem um mecanismo para canelar uma solicitação, além da escolha da conexão de camada de transporte e dessa forma incorrendo 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 ser cancelada se for determinado que a largura de banda disponível mudou e uma taxa de dados de mídia diferente é necessária, isso é, existe uma decisão para se comutar para uma representação diferente. Outra razoa para o cancelamento de uma solicitação emitida pode ser se o usuário tiver solicitado que a apresentação de mídia seja encerrada e uma nova apresentação iniciada (talvez do mesmo item de conteúdo em um ponto diferente na apresentação ou talvez de um novo item de conteúdo).

[00338] Com é sabido, a penalidade de inicialização de conexão pode ser evitada mantendo-se a conexão aberta e reutilizando a mesma conexão para solicitações subsequentes e como também é sabido a conexão pode ser mantida totalmente utilizada se múltiplas solicitações forem emitidas ao mesmo tempo na mesma conexão (uma técnica conhecida como "sequenciamento" no contexto de HTTP). No entanto, uma desvantagem de emissão de múltiplas solicitações ao mesmo tempo, ou mais geralmente de tal forma que múltiplas solicitações sejam emitidas antes de as solicitações anteriores terem sido completadas através de uma conexão, pode ser que a conexão é então comprometida com o transporte da resposta para essas solicitações e, assim, se mudanças com relação às solicitações que devem ser emitidas se tornarem desejáveis, então, a conexão pode ser fechada se for necessário se cancelar as solicitações já emitidas que não são mais desejáveis.

[00339] A probabilidade de uma solicitação emitida precisar ser cancelada pode depender em parte na 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 quando esse intervalo de tempo é alto, a probabilidade de uma solicitação emitida precisar ser cancelada também é alta (visto que é provável que a largura de banda disponível mude durante o intervalo).

[00340] Como é sabido, alguns protocolos de download de arquivo possuem a propriedade de uma única conexão de camada de transporte subjacente poder ser vantajosamente utilizada para múltiplas solicitações de download. Por exemplo, HTTP possui essa propriedade, visto que a reutilização de uma única conexão para múltiplas solicitações evita a "penalidade de reinicialização de conexão" descrita acima para solicitações além da primeira. No entanto, uma desvantagem dessa abordagem é que a conexão é comprometida com o transporte dos dados solicitados em cada solicitação emitida e, portanto, se uma solicitação ou solicitações precisarem ser canceladas, então a conexão pode ser fechada, incorrendo em uma 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.

[00341] Descreve-se agora uma modalidade que retém as vantagens da reutilização de conexão sem se incorrer na desvantagem e que também aperfeiçoa adicionalmente a frequência com a qual as conexões são reutilizadas.

[00342] As modalidades dos sistemas de sequenciamento de bloco descritas aqui são configuradas para reutilizar uma conexão para múltiplas solicitações sem precisar comprometer a conexão no começo a um conjunto particular de solicitações. Essencialmente, uma nova solicitação é emitida em uma conexão existente quando solicitações já emitidas na conexão ainda não foram completadas, mas estão perto da finalização. Uma razão para não se esperar até que as solicitações existentes sejam completadas é que se as solicitações anteriores forem completadas, então, a velocidade de conexão pode degradar, isso é, a sessão TCP subjacente pode passar para um estado inativo, ou a variável cwnd TCP pode ser substancialmente reduzida, reduzindo, assim, substancialmente, a velocidade de download inicial da nova solicitação emitida nessa conexão. Uma razão pela espera até perto da finalização antes da emissão de uma solicitação adicional é porque se uma nova solicitação for emitida muito tempo antes das solicitações anteriores serem completadas, então a nova solicitação emitida pode n ao começar por algum período de tempo substancial, e pode ser o caso de durante esse período de tempo antes da nova solicitação emitida começar a decisão de se realizar uma nova solicitação não ser mais válida, por exemplo, devido a uma decisão para se permutar representações. Dessa forma, uma modalidade de clientes que implementam essa técnica emitira uma nova solicitação em uma conexão o mais tarde possível sem reduzir as capacidades de download da conexão.

[00343] O método compreende o monitoramento do número de bytes recebido em uma conexão em resposta à última solicitação emitida nessa conexão e aplicação de um teste para desse número. Isso pode ser feito configurando-se um receptor (ou o transmissor, se aplicável) para monitoramento e teste.

[00344] Se o teste passar, então uma solicitação adicional pode ser emitida na conexão. Um exemplo de um teste adequado é se o número de bytes recebidos é maior do que uma fração fixa do tamanho de dados solicitados. Por exemplo, essa fração pode ser 80%. Outro exemplo de um teste adequado é baseado no cálculo a seguir, como ilustrado na figura 17. No cálculo, considera-se R uma estimativa da taxa de dados da conexão, T sendo uma estimativa de Tempo de Ida e Volta ("RTT") e X o fator numérico que, por exemplo, pode ser uma constante determinada para um valor entre 0,5 e 2, onde as estimativas de R e T são atualizadas regularmente (atualizadas na etapa 1410). Considera-se S o tamanho dos dados solicitados na última solicitação, B o número de bytes dos dados solicitados recebidos (calculados na etapa 1420).

[00345] Um teste adequado seria fazer com que o receptor (ou o transmissor, se aplicável) execute uma rotina para avaliar a desigualdade (S-B)<X*R*T (testada na etapa 1430) e se "Sim" então se realizar uma ação. Por exemplo, um teste pode ser feito para se ver se existe outra solicitação pronta para ser emitida na conexão (testada na etapa 1440) e se "sim" então emitir essa 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 for "não" então o processo retorna para a etapa 1410 para continuar a atualização e teste.

[00346] O teste de desigualdade na etapa 1430 (realizado pelos elementos programados adequadamente, por exemplo) faz com que cada solicitação subsequente seja emitida quando a quantidade de dados restantes a serem recebidos for igual a X vezes a quantidade de dados que podem ser recebidos na taxa de recepção estimada atual dentro de um RTT. Um número de métodos para estimativa da taxa de dados, R, na etapa 1410 é conhecido da técnica. Por exemplo, a taxa de dados pode ser estimada como Dt/t, onde Dt é o número de bits recebido nos t segundos anteriores e onde t pode ser, por exemplo, 1 s ou 0,5 s ou algum outro intervalo. Outro método é uma média ponderada exponencial, ou filtro de Resposta a Impulso Infinito (IIR) de primeira ordem da taxa de dados de entrada. Um número de métodos para estimativa de RTT, T na etapa 1410 são conhecidos da técnica.

[00347] O teste na etapa 1430 pode ser aplicado ao agregado de todas as conexões ativas em uma interface, como explicado em maiores detalhes abaixo.

[00348] O método compreende adicionalmente a construção de uma lista de solicitações candidatas, associação de cada solicitação candidata com um conjunto de servidores adequados aos quais a solicitação pode ser feita e ordenação da lista de solicitações candidatas em ordem de prioridade. Alguns registros na lista de solicitações candidatas podem ter a mesma prioridade. Servidores na lista de servi dores adequados associados com cada solicitação candidata são identificados por nomes de hospedeiro. Cada nome de hospedeiro corresponde a um conjunto de endereços IP que podem ser obtidos a partir do Sistema de Nome de Domínio como é bem sabido. Portanto, cada possível solicitação na lista de solicitações candidatas é associada com um conjunto de endereços IP, especificamente a união de conjuntos de Endereços de Protocolo de Internet associados com os nomes de hospedeiros associados com os servidores associados com a solicitação candidata. Toda vez que o teste descrito na etapa 1430 é correspondido para uma conexão, e nenhuma solicitação nova foi emitida ainda nessa conexão, a solicitação de prioridade mais alta nas listas de solicitações candidatas com as quais o endereço IP do destino da conexão é associado é escolhido, e essa solicitação é emitida na conexão. A solicitação também é removida da lista de solicitações candidatas.

[00349] As solicitações candidatas podem ser removidas (canceladas) da lista de solicitações candidatas, novas solicitações podem ser adicionadas à lista candidata com uma prioridade que é maior do que as solicitações já existentes na lista candidata, e as solicitações existentes na lista candidata podem ter sua prioridade alterada. A natureza dinâmica de quais solicitações estão na lista de solicitações candidatas, pode altera as solicitações que podem ser emitidas a seguir dependendo de quando um teste do tipo descrito na etapa 1430 foi satisfeito.

[00350] Por exemplo pode ser possível que se a resposta para o teste descrito na etapa 1430 for "sim" em algum momento t então a próxima solicitação emitida seria uma solicitação A, ao passo que se a resposta ao teste descrito na etapa 1430 não for "sim" até algum tempo t'>t, então a próxima solicitação emitida seria uma solicitação B, visto que a solicitação A foi removida da lista de solicitações candidatas entre o momento t e t', ou porque a solicitação B foi adicionada à lista de solicitações candidatas com maior prioridade do que a solicitação A entre o momento t e t', ou porque a solicitação B estava na lista candidata no momento t, mas com prioridade mais baixa do que a solicitação A, e ente o momento t e t' a prioridade da solicitação B foi tornada maior do que a da solicitação A.

[00351] A figura 18 ilustra um exemplo de uma lista de solicitações na lista candidata de solicitações. Nesse exemplo, existem três conexões, e existem seis solicitações na lista candidata, rotuladas A, B, C, D, E e F. Cada uma das solicitações na lista candidata pode ser emitida em um subconjunto de conexões como indicado, por exemplo, a solicitação A pode ser emitida na conexão 1, ao passo que a solicitação F pode ser emitida na conexão 2 ou conexão 3. A prioridade de cada solicitação também é rotulada na figura 18, e um valor de prioridade mais baixa indica que uma solicitação tem prioridade mais alta. Dessa forma, as solicitações A e B com prioridade 0 são as solicitações de prioridade mais alta, ao passo que a solicitação F com um valor de prioridade de 3 é a prioridade mais baixa entre as solicitações na lista candidata.

[00352] Se, nesse momento t, a conexão 1 passar o teste descrito na etapa 1430, então a solicitação A ou solicitação B é emitida na conexão 1. Se ao invés disso, a conexão 3 passar pelo teste descrito na etapa 1430 nesse momento t, então a solicitação D é emitida na conexão 3, visto que a solicitação D é a solicitação com a prioridade mais alta que pode ser emitida na conexão 3.

[00353] Supondo-se que para toda as conexões a resposta para o teste descrito na etapa 1430 a partir do momento t para algum outro momento t' seja "não", e entre o momento t e t' a solicitação A mude sua prioridade de 0 para 5, a solicitação B é removida da lista candidata, e uma nova solicitação G com prioridade 0 é adicionada à lista candidata. Então, no momento t', a nova lista candidata deve ser como ilustrado na figura 19.

[00354] Se no momento t' a conexão 1 passar pelo teste descrito na etapa 1430, então a solicitação C com prioridade 4 é emitida na conexão 1, visto que é a solicitação de prioridade mais alta na lista candidata que pode ser emitida na conexão 1 nesse momento.

[00355] Supondo-se que nessa mesma situação ao invés da solicitação A ter sido emitida na conexão 1 no momento t (que foi uma das duas escolhas de maior prioridade para a conexão 1 no momento t como ilustrado na figura 18). Visto que a resposta para o teste descrito na etapa 1430 a partir do momento para algum tempo posterior t' foi "não" para todas as conexões, a conexão 1 ainda está distribuindo dados até o último momento t' para solicitações emitidas antes do momento t, e, dessa forma, a solicitação A não terá começado até pelo menos o momento t'. A emissão da solicitação C no momento t' é uma decisão melhor do que a emissão de solicitação A no momento t teria sido, visto que a solicitação C começa no mesmo momento depois t' que a solicitação A teria começado, e visto que nesse momento a solicitação C tem maior prioridade do que a solicitação A.

[00356] Com outra alternativa, se o teste do tipo descrito na etapa 1430 for aplicado ao agregado das conexões ativas uma conexão pode ser escolhida e possui um destino cujo endereço IP está associado com a primeira solicitação na lista de solicitações candidatas ou outra solicitação com a mesma prioridade que a dita primeira solicitação.

[00357] Um número de métodos é possível par a construção da lista de solicitações candidatas. Por exemplo, a lista candidata pode conter n solicitações representando solicitações para as próximas n partes de dados da representação atual da apresentação na ordem de sequência de tempo, onde a solicitação por uma parte anterior de dados possui uma prioridade mais alta e a solicitação por uma parte posterior dos dados possui uma prioridade mais baixa. Em alguns casos, n pode ser igual a um. O valor de n pode depender do tamanho do armazenador Bcurrent, ou a variável State ou outra medida do estado de ocupação de armazenador de cliente. Por exemplo, vários valores limite podem ser determinado para Bcurrent e um valor associado com cada limite e então o valor de n é considerado o valor associado com o limite mais alto que é inferior a Bcurrent.

[00358] A modalidade descrita acima garante a alocação flexível de solicitações para conexões, garantindo que a preferência seja fornecida à reutilização de uma conexão existente mesmo se a solicitação de prioridade mais alta não for adequada para essa conexão (visto que o endereço IP de destino da conexão não é um que esteja alocado para qualquer um dos nomes hospedeiros associados com a solicitação). A dependência de n em Bcurrent ou State ou outra medida de ocupação do armazenador de cliente garante que tais solicitações "fora de ordem de prioridade" não sejam emitidas quando cliente está necessitando urgentemente da emissão e finalização da solicitação associada com a próxima parte de dados a ser reproduzida na sequência de tempo.

[00359] Esses métodos podem ser vantajosamente combinados com HTTP cooperativo e FEC. Seleção Consistente de Servidor

[00360] Como é bem sabido, arquivos a serem descarregados utilizando um protocolo de download de arquivo são comumente identificados por um identificador compreendendo um nome de hospedeiro e um nome de arquivo. Por exemplo, esse é o caso para protocolo HTTP caso no qual o identificador é um URI. Um nome de hospedeiro pode corresponder a múltiplos hospedeiros, identificados por endereços IP. Por exemplo, esse é um método comum de espalhamento de carga de solicitações a partir de múltiplos clientes através de múltiplas máquinas físicas. Em particular essa abordagem é comumente realizada pelas CDNs. Nesse caso, uma solicitação emitida em uma conexão para qualquer um dos hospedeiros físicos deve ser bem sucedida. Um número de métodos é conhecido pelos quais um cliente pode selecionar dentre os endereços IP associados com um nome de hospedeiro. Por exemplo, esses endereços são tipicamente fornecidos para o cliente através do Sistema de Nome de Domínio e são fornecidos na ordem de prioridade. Um cliente pode então escolher o endereço IP de prioridade mais alta (primeiro). No em tanto, geralmente não existe qualquer coordenação entre os clientes e como essa escolha é feita, com o resultado de clientes diferentes poderem solicitar o mesmo arquivo com servidores diferentes. Isso pode resultar no mesmo arquivo sendo armazenado na memória temporária de múltiplos servidores próximos, o que reduz a eficiência da infraestrutura de armazenamento temporário.

[00361] Isso pode ser manuseado por um sistema que aumenta vantajosamente a probabilidade de dois clientes solicitando o mesmo bloco solicitarem esse bloco do mesmo servidor. O método novo descrito aqui compreende a seleção dentre os endereços IP disponíveis de forma determinada pelo identificador do arquivo a ser solicitado e de tal forma que diferentes clientes apresentados com escolhas iguais ou similares dos endereços IP e identificadores de arquivo façam a mesma escolha.

[00362] Uma primeira modalidade do método é descrita com referência à figura 20. O cliente primeiro obtém um conjunto de endereços IP, IP1, IP2,...,IPn como ilustrado na etapa 1710. Se houver um arquivo para o qual se deva emitir solicitações, como decidido na etapa 1720, então o cliente determina qual endereço IP emitir solicitações para o arquivo, como determinado nas etapas 1730-1770. De acordo com um conjunto de endereços IP e um identificador para um arquivo a ser solicitado o método compreende a ordenação dos endereços IP de forma determinada pelo identificador de arquivo. Por exemplo, para cada endereço IP uma sequência de bytes é construída compreendendo a concatenação do endereço IP e o identificador de arquivo, como ilustrado na etapa 1730. Uma função hash é aplicada a essa sequência de bytes, como ilustrado na etapa 1740, e os valores hash resultantes são dispostos de acordo com uma ordenação fixa, como ilustrado na etapa 1750, por exemplo, ordem numérica crescente, induzindo uma ordenação nos endereços IP. A mesma função hash pode ser utilizada por todos os clientes, garantindo, assim, que o mesmo resultado seja produzido pela função hash em uma única entrada por todos os clientes. A função hash pode ser configurada de forma estática em todos os clientes em um conjunto de clientes, ou todos os clientes em um conjunto de clientes podem obter uma descrição parcial ou total da função hash quando os clientes obtêm a lista de endereços IP, ou todos os clientes em um conjunto de clientes pode obter uma descrição parcial ou total da 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 IP que é primeiro nessa ordenação é escolhido e esse endereço é então utilizado para estabelecer uma conexão e emite solicitações para todo ou partes do arquivo, como ilustrado nas etapas 1760 e 1770.

[00363] O método acima pode ser aplicado quando uma nova conexão é estabelecida para solicitar um arquivo. Pode ser aplicado também quando um número de conexões estabelecidas está disponível e uma das mesmas pode ser escolhida para emitir uma nova solicitação.

[00364] Adicionalmente, quando uma conexão estabelecida está disponível e uma solicitação pode ser escolhida entre um conjunto de solicitações candidatas com igual prioridade uma ordenação das solicitações candidatas é induzida, por exemplo, pelo mesmo método de valores hash descritos acima e a solicitação candidata que aparece primeiro nessa ordenação é escolhida. Os métodos podem ser combinados para selecionar ambas uma conexão e uma solicitação candidata a partir de um conjunto de conexões e solicitações de mesma prioridade, novamente pela computação de um hash para cada combinação de conexão e solicitação, ordenando esses valores hash de acordo com uma ordenação fixa e escolhendo a combinação que ocorre primeiro na ordenação induzida no conjunto de combinações de solicitações e conexões.

[00365] Esse método tem a vantagem pela seguinte razão: uma abordagem típica realizada por uma infraestrutura servidora de bloco tal como a ilustrada na figura 1 (BSI 101) ou figura 2 (BSIs 101) e em particular uma abordagem comumente realizada pelas CDNs, é fornecer múltiplos servidores proxy de armazenamento temporário que recebem solicitações de cliente. Um servidor proxy de armazenamento temporário pode não ser fornecido com o arquivo solicitado em uma determinada solicitação e nesse caso tais servidores enviam tipicamente a solicitação para outro servidor, recebem a resposta desse servidor, incluindo tipicamente o arquivo solicitado, e enviam a resposta para o cliente. O servidor proxy de armazenamento temporário também pode armazenar (memória temporária) o arquivo solicitado de modo que possa responder imediatamente às solicitações subsequentes para o arquivo. A abordagem comum descrita acima tem a propriedade de o conjunto de arquivos armazenado em um determinado servidor proxy de armazenamento temporário ser muito determinado pelo conjunto de solicitações que o servidor proxy de armazenamento temporário recebeu.

[00366] O método descrito acima tem a seguinte vantagem. Se todos os clientes em um conjunto de clientes receberem a mesma lista de endereços IP, então esses clientes utilizarão o mesmo endereço IP para todas as solicitações emitidas para o mesmo arquivo. Se houver duas listas diferentes de endereços IP e cada cliente receber uma dessas duas listas, então os clientes utilizarão no máximo dois endereços IP diferentes para todas as solicitações emitidas para o mesmo arquivo. Em geral, se as listas de endereços IP fornecidas para os clientes forem similares, então os clientes utilizarão um conjunto pequeno de endereços IP fornecidos para todas as solicitações emitidas para o mesmo arquivo. Visto que os clientes próximos tendem a receber listas similares de endereços IP, é provável que os clientes próximos emitam solicitações para um arquivo a partir de apenas uma parte pequena dos servidores proxy de armazenamento temporário disponíveis para esses clientes. Dessa forma, haverá apenas uma pequena fração de servidores proxy de armazenamento temporário que armazenam temporariamente o arquivo, o que minimiza de forma vantajosa a quantidade de recursos de armazenamento temporário utilizados para armazenar temporariamente o arquivo.

[00367] Preferivelmente, a função hash tem a propriedade de uma fração muito pequena de diferentes entradas ser mapeada para a mesma saída, e que diferentes entradas sejam mapeadas para saídas essencialmente aleatórias, para garantir que para um determinado conjunto de endereços IP, a proporção de arquivos para os quais um determinado endereço IP está primeiro na lista classificada produzida pela etapa 1750 seja aproximadamente igual para todos os endereços IP na lista. Por outro lado, é importante que a função hash seja determinística, no sentido de que para uma determinada entrada a saída da função hash seja igual para todos os clientes.

[00368] Outra vantagem do método descrito acima é a seguinte. Supondo0se que todos os clientes em um conjunto de clientes recebam a mesma lista de endereços IP. Devido às propriedades da função hash recém descrita, é provável que as solicitações para arquivos diferentes desses clientes sejam igualmente espalhadas através do conjunto de endereço IP, que, por sua vez, significa que as solicitações serão espalhadas igualmente através dos servidores proxy de armazenamento temporário. Dessa forma, os recursos de armazenamento temporário para o armazenamento desses arquivos são espalhados igualmente através dos servidores proxy de armazenamento temporário, e as solicitações por arquivos é espalhada igualmente através dos servidores proxy de armazenamento temporário. Dessa forma, o método fornece o equilíbrio de armazenamento e o equilíbrio de carga através da infraestrutura de armazenamento temporário.

[00369] Um número de variações para a abordagem descrita acima é conhecido dos versados na técnica e em muitos caos essas variações retêm a propriedade de o conjunto de arquivos armazenado em um determinado proxy ser determinado pelo menos em parte pelo conjunto de solicitações que o servidor proxy de armazenamento temporário recebeu. No caso comum no qual um determinado nome de hospedeiro se relaciona com múltiplos servidores proxy de armazenamento temporário físicos, será comum que todos esses servidores armazenem eventualmente uma cópia de qualquer arquivo determinado que seja frequentemente solicitado. Tal duplicação pode ser indesejável, visto que os recursos de armazenamento dos servidores proxy de armazenamento temporário são limitados e como resultado disso, os arquivos podem ser, ocasionalmente, removidos (purgados) da memória temporária. O método novo descrito aqui garante que as solicitações por um determinado arquivo sejam direcionadas para os servidores proxy de armazenamento temporário a partir da memória temporária e, dessa forma, aumentando a probabilidade de qualquer arquivo determinado estar presente (isso é, não ter sido purgado) na memória temporária proxy.

[00370] Quando um arquivo está presente na memória temporária proxy, a resposta enviada para o cliente é mais rápida, que tem a vantagem de reduzir a probabilidade de o arquivo solicitado chegar tarde, que pode resultar em uma pausa na reprodução de mídia e, portanto, uma experiência de usuário ruim. Adicionalmente, quando um arquivo não está presente na memória temporária proxy, a solicitação pode se enviada para outro servidor, causando uma carga adicional em ambas a infraestrutura servidora e as 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 a transmissão do arquivo a partir desse servidor de volta para o servidor proxy de armazenamento temporário pode incorrer em custos de transmissão. Portanto, o método novo descrito aqui resulta em uma redução desses custos de transmissão. Solicitações de Arquivo Total Probabilísticas

[00371] Uma preocupação em particular no caso de o protocolo HTTP ser utilizado com solicitações de Faixa é o comportamento dos servidores de armazenamento temporário que são comumente utilizados para fornecer a capacidade de escalonamento na infraestrutura servidora. Enquanto pode ser comum para os servidores de armazenamento temporário HTTP suportarem o cabeçalho de Faixa HTTP, o comportamento exato de diferentes servidores de armazenamento temporário HTTP varia pela implementação. A maior parte das implementações de servidor de armazenamento temporário servem solicitações de Faixa a partir da memória temporária no caso de o arquivo estar disponível na memória temporária. Uma implementação comum de servidores de Memória Temporária HTTP sempre envia solicitações HTTP a jusante contendo o cabeçalho de Faixa para um nó a montante a menos que o servidor de armazenamento temporário tenha uma cópia do arquivo (servidor de armazenamento temporário ou servidor de origem). Em algumas implementações, a resposta a montante para a solicitação de Faixa é todo o arquivo, e todo esse arquivo é armazenado temporariamente e a resposta à solicitação de Faixa a jusante é extraída desse arquivo e enviada. No entanto, em pelo menos uma implementação a resposta a montante à resposta de Faixa é apenas os bytes de dados na solicitação de Faixa propriamente dita, e esses bytes de dados não são armazenados temporariamente, mas, ao invés disso, apenas enviados como resposta para a solicitação de Faixa a jusante. Como resultado disso, o uso de cabeçalhos de Faixa pelos clientes pode ter a consequência de o arquivo propriamente dito nunca ser trazido para dentro da memória temporária e as propriedades de capacidade de escalonamento desejáveis da rede serem perdidas.

[00372] Acima, a operação dos servidores proxy de armazenamento temporário foi descrita e também o método de solicitação de Blocos a partir de um arquivo que é uma agregação de múltiplos blocos foi descrita. Por exemplo, isso pode ser alcançado pelo uso de cabeçalho de solicitação de Faixa HTTP. Tais solicitações são chamadas de "solicitações parciais" a seguir. Uma modalidade adicional é descrita agora e apresenta a vantagem no caso de a infraestrutura servidora de bloco 101 não fornece o suporte completo para o cabeçalho de Faixa HTTP. Comumente, os servidores dentro de uma infraestrutura servidora de bloco, por exemplo, uma Rede de Distribuição de Conteúdo, suporta solicitações parciais, mas pode não armazenar a resposta para o envio parcial da solicitação para outro servidor, a menos que todo o arquivo seja armazenado no armazenador local, caso no qual a resposta pode ser enviada sem envio da solicitação para outro servidor.

[00373] Um sistema de sequenciamento de solicitação de bloco que faz uso do aperfeiçoamento novo da agregação de bloco descrita acima pode ter um desempenho ruim se a infraestrutura servidora de bloco exibir esse comportamento, visto que todas as solicitações, sendo solicitações paralelas, serão enviada para outro servidor e nenhuma solicitação será servida pelos servidores proxy de armazenamento temporário, não alcançando o objetivo de fornecimento de servidores proxy de armazenamento temporário inicialmente. Durante o processo de sequenciamento de solicitação de bloco como descrito acima, um cliente pode em algum momento solicitar um Bloco que esteja no começo de um arquivo.

[00374] De acordo com o método novo descrito aqui, toda vez que uma condição determinada é correspondida, tais solicitações podem ser convertidas de solicitações para o primeiro Bloco em um arquivo em solicitações para todo o arquivo. Quando uma solicitação por todo um arquivo é recebida por um servidor proxy de armazenamento temporário o servidor proxy armazena tipicamente a resposta. Portanto, o uso dessas solicitações faz com que o arquivo seja trazido para dentro da memória temporária dos servidores proxy de armazenamento temporário locais de modo que solicitações subsequentes, para todo o arquivo ou solicitações parciais possam ser servidas diretamente pelo servidor proxy de armazenamento temporário. A condição pode ser tal que dentre um conjunto de solicitações associadas com um determinado 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 seja correspondida para pelo menos uma fração fornecida dessas solicitações.

[00375] Um exemplo de uma condição adequada é que um número escolhido aleatoriamente está acima de um limite fornecido. Esse limite pode ser configurado de modo que a conversão de uma única solicitação de Bloco em uma solicitação de todo o arquivo ocorra em média para uma fração fornecida das solicitações, por exemplo, uma vez de cada dez (caso no qual o número aleatório pode ser escolhido a partir do intervalo [0,1] e o limite pode ser de 0,9). Outro exemplo de uma condição adequada é que uma função hash calculada através de alguma informação associada com o bloco e alguma informação associada com o cliente assuam um de um conjunto fornecido de valores. Esse método tem a vantagem de para um arquivo que é frequentemente solicitado, o arquivo seja trazido para dentro da memória temporária de um servidor proxy local, no entanto, a operação do sistema de sequenciamento de solicitação de bloco não é alterado de forma significativa a partir da operação padrão na qual cada solicitação é para um único Bloco. Em muitos casos, onde a conversão da solicitação de uma solicitação de Bloco único para uma solicitação de todo o arquivo ocorre, os procedimentos de cliente seguirão, de outra forma, para a solicitação de outros Blocos dentro do arquivo. Se esse for o caso, então tais solicitações podem ser suprimidas visto que os blocos em questão serão recebidos em qualquer caso como resultado a solicitação de todo o arquivo. Construção URL e Geração e Busca de Lista de Segmento

[00376] A geração de lista de segmento lida com o problema de como um cliente pode gerar uma lista de segmento a partir de MPD em um momento específico de cliente e local AGORA para uma representação específica que começa no mesmo momento inicial starttime com relação ao início da apresentação de mídia para casos sob demanda ou expresso em tempo de relógio. Uma lista de segmento pode compreender um localizador, por exemplo, um URL para metadados de representação inicial opcionais, além de uma lista de segmentos de mídia. Cada segmento de mídia pode ter sido designado um starttime, uma duração e um localizador. O starttime expressa tipicamente uma aproximação do tempo de mídia da mídia contida em um segmento, mas não necessariamente um tempo preciso de amostra. O starttime é utilizado pelo cliente de sequenciamento HTTP ara emitir a solicitação de download no momento adequado. A geração da lista de segmento, incluindo o momento inicial de cada, pode ser realizada de formas diferentes. Os URLs podem ser fornecidos como uma lista de reprodução ou uma regra de construção de URL pode ser vantajosamente utilizada para uma representação compacta da lista de segmento.

[00377] Uma lista de segmento com base na construção URL pode, por exemplo, ser realizada se a MPD sinalizar isso por um atributo específico ou elemento tal como FileDynamicInfo ou um sinal equivalente. Uma forma genérica de se criar uma lista de segmento a partir de uma construção URL é fornecida abaixo na seção "Visão Geral de Construção URL". Uma construção com base em lista de reprodução pode, por exemplo, ser sinalizada por um sinal diferente. A busca na lista de segmento e obtenção de um tempo de mídia preciso também são vantajosamente implementadas nesse contexto. Visão Geral de Construtor URL

[00378] Como descrito anteriormente, em uma modalidade da presente invenção pode ser fornecido um arquivo de metadados contendo regras de construção URL que permitem que os dispositivos de cliente construam identificadores de arquivo para Blocos de apresentação. Descreve-se agora um aperfeiçoamento novo adicional para o sistema de sequenciamento de solicitação de bloco que fornece mudanças no arquivo de metadados, incluindo mudanças para as regras de construção URL, mudanças para o número de codificações disponíveis, mudanças para os metadados associados com as codificações disponíveis tal como taxa de bit, razão de aparência, resolução, codec de áudio ou vídeo ou parâmetros de codec ou outros parâmetros.

[00379] Nesse aperfeiçoamento novo, podem ser fornecidos dados adicionais associados com cada elemento do arquivo de metadados indicando um intervalo de tempo dentro da apresentação geral. Dentro desse intervalo de tempo o elemento pode ser considerado válido e, do contrário, o intervalo de tempo pode ser ignorado. Adicionalmente, a sintaxe dos metadados pode ser melhorada de modo que os elementos previamente com permissão para aparecer apenas uma vez ou no máximo uma vez podem aparecer múltiplas vezes. Uma restrição adicional pode ser aplicada nesse caso e fornece que para tais elementos os intervalos de tempo especificados devam ser separados. Em qualquer momento determinado, considerando-se apenas os elementos cujo intervalo de tempo contém o instante determinado resulta em um arquivo de metadados que é consistente com a sintaxe de metadados original. Chama-se tais intervalos de tempo de intervalos de validade. Esse método, portanto, fornece a sinalização dentro de mudanças de arquivo de metadados único do tipo descrito acima. Vantajosamente, tal método pode ser utilizado para fornecer uma apresentação de mídia que suporta a mudança do tipo descrito em pontos específicos dentro da apresentação. Construtor de URL

[00380] Como descrito aqui, uma característica comum de sistemas de sequenciamento de solicitação de bloco é a necessidade de se fornecer ao cliente "metadados" que identificam as codificações de mídia disponíveis e forneça informação necessária pelo cliente para solicitar os blocos a partir dessas codificações. Por exemplo, no caso de HTTP essa informação pode compreender URLs para os arquivos contendo os blocos de mídia. Um arquivo de lista de reprodução pode ser fornecida listando os URLs para os blocos para uma determinada codificação. Múltiplos arquivos de lista de reprodução são fornecidos, um para cada codificação, juntamente com uma lista de reprodução principal das listas de reprodução que listam as listas de reprodução correspondentes às codificações diferentes. Uma desvantagem desse sistema é que os metadados podem se tornar bem grandes e, portanto, levar algum tempo para serem solicitados quando o cliente inicia a sequência. Uma desvantagem adicional desse sistema é evidente no caso de conteúdo ao vivo, quando os arquivos correspondentes aos blocos de dados de mídia são gerados "imediatamente" a partir de uma sequência de mídia que está sendo capturada em tempo real (ao vivo), por exemplo, um evento esportivo ao vivo ou noticiário. Nesse caso, os arquivos de lista de reprodução podem ser atualizados cada vez que um novo bloco está disponível (por exemplo, a cada poucos segundos). Os dispositivos de cliente podem coletar repetidamente o arquivo de lista de reprodução para determinar se novos blocos estão disponíveis e obter seus URLs. Isso pode colocar uma carga significativa na infraestrutura servidora e em particular significa que os arquivos de metadados não podem ser armazenados temporariamente por mais tempo do que o intervalo de atualização, que é igual ao tamanho de bloco que é comumente da ordem de poucos segundos.

[00381] Um aspecto importante de um sistema de sequenciamento de solicitação de bloco é o método utilizado para informar aos clientes sobre os identificadores de arquivo, por exemplo, URLs, que devem ser utilizados, juntamente com o protocolo de download de arquivo, para solicitar os Blocos. Por exemplo, um método no qual para cada representação de uma apresentação é fornecido um arquivo de lista de reprodução que lista os URLs dos arquivos contendo os blocos de dados de mídia. Uma desvantagem desse método é que pelo menos alguns dos arquivos de lista de reprodução propriamente ditos precisam ser descarregados antes de a reprodução poder começar, aumentando o tempo de zapping de canal e, portanto, causando uma experiência de usuário ruim. Para uma apresentação de mídia longa com várias ou muitas representações, a lista de URLs de arquivo pode ser grande e, dessa forma, a lista de reprodução pode ser grande, aumentando ainda mais o tempo de zapping de canal.

[00382] Outra desvantagem desse método ocorre no caso de conteúdo ao vivo. Nesse caso, a lista completa de URLs não é disponibilizada de antemão e o arquivo de lista de reprodução é periodicamente atualizado à medida que novos blocos se tornam disponíveis e clientes solicitam periodicamente o arquivo de lista de reprodução, a fim de receber a versão atualizada. Visto que esse arquivo é frequentemente atualizado o mesmo não pode ser armazenado por muito tempo dentro dos servidores proxy de armazenamento temporário. Isso significa que muitas das solicitações para esse arquivo serão enviadas para outros servidores e eventualmente para o servidor que gera o arquivo. No caso de uma apresentação de mídia popular isso pode resultar em uma carga alta nesse servidor e na rede, o que pode, por sua vez, resultar em um tempo de resposta lento e, portanto, um tempo de zapping de canal alto e uma experiência de usuário ruim. No pior caso, o servidor se torna sobrecarregado e isso resulta em alguns usuários sendo incapazes de visualizar a apresentação.

[00383] É desejável no desenho de um sistema de sequenciamento de solicitação de bloco se evitar a colocação de restrições na forma de identificadores de arquivo que podem ser utilizados. Isso porque um número de considerações pode motivar o uso de identificadores de uma forma particular. Por exemplo, no caso de a Infraestrutura Servidora de Bloco ser uma Rede de Distribuição de Conteúdo pode haver nomeação de arquivo ou convenções de armazenamento relacionadas com um desejo de se distribuir a carga de armazenamento ou serviço através da rede ou outras exigências que levam às formas particulares do identificador de arquivo que não podem ser previstas no momento de desenho de sistema.

[00384] Uma modalidade adicional é agora descrita e mitiga as desvantagens mencionadas acima enquanto retém a flexibilidade de escolha adequada de convenções de identificação de arquivo. Nesse método os metadados podem ser fornecidos para cada representação da apresentação de mídia compreendendo uma regra de construção de identificador de arquivo. A regra de construção de identificador de arquivo pode, por exemplo, compreender uma sequência de texto. A fim de determinar o identificador de arquivo para um determinado bloco de apresentação, um método de interpretação da regra de construção de identificador de arquivo pode ser fornecida, esse método compreendendo a determinação de parâmetros de entrada e avaliação da regra de construção de identificação de arquivo juntamente com os parâmetros de entrada. Os parâmetros de entrada podem, por exemplo, incluir um índice do arquivo a ser identificado, onde o primeiro arquivo possui um índice igual a zero, o segundo possui um índice igual a um, o terceiro possui um índice igual a dois e assim por diante. Por exemplo, no caso de cada arquivo abranger alguma duração de tempo (ou aproximadamente a mesma duração de tempo), então o índice do arquivo associado com qualquer momento determinado dentro da apresentação pode ser facilmente determinado. Alternativamente, o tempo dentro da apresentação abrangida por cada arquivo pode ser fornecido dentro dos metadados de apresentação ou versão.

[00385] Em uma modalidade, a regra de construção de identificador de arquivo pode compreender uma sequência de texto que pode conter determinados identificadores especiais correspondendo a parâmetros de entrada. O método de avaliação da regra de construção de identificador de arquivo compreende a determinação das posições dos identificadores especiais dentro da sequência de texto e substituição de cada identificador especial por uma representação de sequência do valor do parâmetro de entrada correspondente.

[00386] Em outra modalidade, a regra de construção de identificador de arquivo pode compreender uma sequência de texto em conformidade com uma linguagem de expressão. Uma linguagem de expressão compreende uma definição de uma sintaxe à qual as expressões na linguagem podem se conformar e um conjunto de regras para avaliação de uma sequência em conformidade com a sintaxe.

[00387] Um exemplo específico será descrito agora, com referência à figura 21 et seq. Um exemplo de uma definição de sintaxe para uma linguagem de expressão adequada, definida na Forma Backus-Naur Aumentada, é como ilustrado na figura 21. Um exemplo das regras para avaliação de uma sequência em conformidade com a produção de <expressão> na figura 21 compreende a transformação recursiva da sequência em conformidade com a produção <expressão> (uma <expressão>) em uma sequência em conformidade com a produção <literal> como se segue: Uma <expressão> em conformidade com a produção <literal> é inalterada. Uma <expressão> em conformidade com a produção <variável> é substituída pelo valor da variável identificado pela sequência de <token> da produção <variável>. Uma <expressão> em conformidade com a produção de <função> é avaliada pela avaliação de cada um de seus argumentos de acordo com essas regras e aplicação de uma transformação para esses argumentos dependendo do elemento <token> da produção de <função> como descrito abaixo. Uma <expressão> em conformidade com a última alternativa da produção <expressão> é avaliada pela avaliação de dois elementos <expressão> e aplicação de uma operação desses argumentos dependendo do elemento <operador> da última alternativa da produção <expressão> como descrito abaixo.

[00388] No método descrito acima é considerado que a avaliação ocorra em um contexto no qual uma pluralidade de variáveis pode ser definida. Uma variável é um (nome, valor) par onde "nome" é uma sequência em conformidade com a produção <token> e "valor" é uma sequência em conformidade com 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 dentro do processo de avaliação propriamente dito. Todas as variáveis são "globais" no sentido de apenas uma variável existir com cada possível "nome".

[00389] Um exemplo de uma função é a função "printf". Essa função aceita um ou mais argumentos. O primeiro argumento pode estar em conformidade com a produção <sequência> (doravante uma "sequência"). A função printf avalia uma versão transformada de seu primeiro argumento. A transformação aplicada é igual à função "printf" da biblioteca de padrão C, com os argumentos adicionais incluídos na produção <função> suprindo os argumentos adicionais exceto pela função printf da biblioteca padrão C.

[00390] Outro exemplo de uma função é a função "hash". Essa função aceita dois argumentos, o primeiro dos quais pode ser uma sequência e o segundo dos quais pode estar em conformidade com a produção <número> (doravante um "número"). A função "hash" aplica um algoritmo hash ao primeiro argumento e retorna um resultado que é um número inteiro não negativo inferior ao segundo argumento. Um exemplo de uma função hash adequada é fornecido na função C ilustrada na figura 22, cujos argumentos são a sequência de entrada (excluindo as marcas de anotação de encerramento) e o valor de entrada numérico. Outros exemplos de funções hash são bem conhecidos dos versados na técnica.

[00391] Outro exemplo de uma função é a função "subst" que considera um, dois ou três argumentos de sequência. No caso de um argumento ser suprido o resultado da função "Subst" é o primeiro argumento. No caso de dois argumentos serem supridos então o resultado da função "Subst" é computado pela eliminação de quaisquer ocorrências do segundo argumento (excluindo as marcas de anotação de encerramento) dentro do primeiro argumento e retornando o primeiro argumento modificado dessa forma. No caso de três argumentos serem supridos então o resultado da função "Subst" é computado pela substituição de quaisquer ocorrências do segundo argumento (excluindo as marcações de anotação de encerramento) dentro do primeiro argumento com o terceiro argumento (excluindo as marcas de anotação de encerramento) e retornando o primeiro argumento modificado dessa forma.

[00392] Alguns exemplos de operadores são a adição, subtração, divisão, multiplicação e operadores de módulo, identificados pelas produções <operador> '+', '-', '/', '*', '%', respectivamente. Esses operadores exigem que as produções <operador> de qualquer lado da produção <operador> avaliem os números. A avaliação do operador compreende a aplicação de operação aritmética adequada (adição, subtração, divisão, multiplicação e módulo, respectivamente) a esses dois números da forma normal e retornando o resultado em uma forma em conformidade com a produção <número>.

[00393] Outro exemplo de um operador é o operador de designação, identificado pela produção <operador> '='. Esse operador exige que o argumento da esquerda avalie para uma sequência o conteúdo da qual está em conformidade com a produção <token>. O conteúdo de uma sequência é definido para ser a sequência de caracteres dentro das marcas de anotação de encerramento. O operador de igualdade faz com que a variável cujo nome é o <token> igual ao conteúdo do argumento da esquerda receba um valor igual ao resultado da avaliação do argumento da direita. Esse valor também é o resultado de avaliação da expressão de operação.

[00394] Outro exemplo de um operador é o operador de sequência, identificado pela produção <operador> ';'. O resultado da avaliação desse operador é o argumento da direita. Note-se que como com todos os operadores, ambos os argumentos são avaliados e o argumento da esquerda é avaliado primeiro.

[00395] Em uma modalidade dessa invenção o identificador de um arquivo pode ser obtido pela avaliação de uma regra de construção de identificador de arquivo de acordo com a regra acima com um conjunto específico de variáveis de entrada que identifica o arquivo necessário. Um exemplo de uma variável de entrada é a variável com o nome "índice" e o valor igual ao índice numérico do arquivo dentro da apresentação. Outro exemplo de uma variável de entrada é a variável com o nome "taxa de bit" e o valor igual à taxa de bit média da versão necessária da apresentação.

[00396] A figura 23 ilustra alguns exemplos das regras de construção de identificador de arquivo, onde as variáveis de entrada são "id", fornecendo um identificador para a representação da apresentação desejada e "seq", fornecendo um número de sequência para o arquivo.

[00397] Como será claro para os versados na técnica depois da leitura dessa descrição, inúmeras variações do método acima são possíveis. Por exemplo, nem todas as funções e operadores descritos acima podem ser fornecidos ou funções adicionais ou operadores podem ser fornecidos. Regras de Construção URL e Temporização

[00398] Essa seção fornece Regras de Construção URI básicas para designar um URI de arquivo ou segmento além de um momento inicial para cada segmento dentro de uma representação e apresentação de mídia.

[00399] Para essa cláusula a disponibilidade de uma descrição de apresentação de mídia no cliente é considerada.

[00400] Assume-se que o cliente de sequenciamento HTTP esteja reproduzindo mídia que é descarregada dentro de uma apresentação de mídia. O tempo de apresentação real do cliente HTTP pode ser definido com relação a onde o tempo de apresentação é relativo ao início da apresentação. Durante a inicialização, o tempo de apresentação t=0 pode ser considerado.

[00401] Em qualquer momento t, o cliente HTTP pode descarregar quaisquer dados com o tempo de reprodução tP (também com relação ao início da apresentação) em MaximumClientPreBufferTime antecipadamente com relação ao tempo de apresentação real t e quaisquer dados que sejam necessários devido a uma interação com o usuário, por exemplo, busca, avanço, etc. Em algumas modalidades, MaximumClientPreBufferTime pode não ser especificado em um sentido de que um cliente pode descarregar dados antes do tempo de reprodução atual tP sem restrições.

[00402] Os clientes HTTP podem evitar descarregar dados desnecessários, por exemplo, quaisquer segmentos das representações que não devem ser reproduzidos podem tipicamente não ser descarregados.

[00403] O processo básico no fornecimento de serviços de sequenciamento pode ser o download de dados pela geração de solicitações adequadas para descarregar todos os arquivos/segmentos do subconjunto de arquivos/segmentos, por exemplo, pela utilização de solicitações GET HTTP ou solicitações GET HTTP parcial. Essa descrição soluciona como acessar os dados para um tP de tempo de reprodução específico, mas geralmente o cliente pode descarregar os dados para uma faixa de tempo 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 fornecimento de serviço de sequenciamento.

[00404] Para se acessar os dados de mídia no tempo de reprodução tP ou pelo menos perto do tempo de reprodução tP em uma representação específica o cliente determina o URL para o arquivo que contém esse tempo de reprodução e adicionalmente determina a faixa de byte no arquivo para acessar esse tempo de reprodução.

[00405] A Descrição de Apresentação de Mídia pode designar uma id de representação, r, para cada representação, por exemplo, pelo uso de atributo RepresentationID. Em outras palavras, o conteúdo da MPD, quando escrita pelo sistema de ingestão ou quando lido pelo cliente, será interpretado de modo que exista uma designação. A fim de se descarregar dados para um tempo de reprodução específico tP para uma representação específica com id r, o cliente pode construir um URI adequado para um arquivo.

[00406] A Descrição de Apresentação de Mídia pode designar cada arquivo ou segmento de cada representação r dos seguintes atributos.

[00407] (a) um número de sequência i do arquivo dentro da representação r, com i = 1, 2,..., Nr, (b) o tempo inicial relativo do arquivo com representação id r e índice de arquivo I com relação ao tempo de apresentação, definido como ts(r,i), (c), o URI de arquivo para arquivo/segmento com representação id r e índice de arquivo I, denotado como FileURI (r,i).

[00408] Em uma modalidade, o tempo inicial do arquivo e os URIs de arquivo podem ser fornecidos explicitamente para uma representação. Em outra modalidade, uma lista de arquivos URIs pode ser fornecida explicitamente onde cada arquivo URI recebe inerentemente o índice i de acordo com a posição na lista e o momento inicial do segmento é derivado como a soma de todas as durações de segmento para os segmentos de 1 a i-1. A duração de cada segmento pode ser fornecida de acordo com qualquer uma das regras discutidas acima. Por exemplo, qualquer pessoa versada em matemática básica pode utilizar outros métodos para derivar uma metodologia para derivar facilmente o tempo inicial de um elemento único ou atributo e a posição/índice do arquivo URI na representação.

[00409] Se uma regra de construção URI dinâmica for fornecida na MPD, então o tempo inicial de cada arquivo e cada arquivo URI pode ser construído dinamicamente pela utilização de uma regra de construção, o índice do arquivo solicitado e potencialmente alguns parâmetros adicionais fornecidos na descrição de apresentação de mídia. A informação pode, por exemplo, ser fornecida nos atributos ou elementos MPD tal como FileURIPattern e FileInfoDynamic. O FileURIPattern fornece informação sobre como construir os URIs com base no número de sequência de índice de arquivo i e a representação ID r. FileURIFormat é construído como: FileURIFormat=sprintf("%s%s%s%s%s%s", BaseURI, BaseFileName, RepresentationIDFormat, SeparatorFormat, FileSequenceIDFormat, FileExtension); e FileURI(r,i) é construído como FileURI (r,i)=sprintf(FileURIFormat,r,i);

[00410] O tempo inicial relativo ts(r,i) para cada arquivo/segmento pode ser derivado por algum atributo contido na MPD descrevendo a duração dos segmentos nessa representação, por exemplo, o atributo FileInfoDynamic. A MPD também pode conter uma sequência de atributos FileInfoDynamic que é global para todas as representações na apresentação de mídia ou pelo menos para todas as representações em um período da mesma forma que especificado acima. Se os dados de mídia para um tempo de reprodução específico tP na representação r forem solicitados, o índice de correspondência i(r,tP) pode ser derivado como (r, tP) de modo que o tempo de reprodução desse índice esteja no intervalo do tempo inicial de ts(r,i(r,tP)) e ts(r,i(r,tP)+1). O acesso de segmento pode ser adicionalmente restringido pelos casos acima, por exemplo, o segmento não é acessível.

[00411] Para se acessar o tempo de reprodução exato tP uma vez que o índice e o URI do segmento correspondente são obtidos depende do formato de segmento real. Nesse exemplo assume-se que os segmentos de mídia tenham uma linha de tempo local que começa com 0 sem perda de generalidade. Para se acessar e apresentar os dados em tempo de reprodução tP o cliente pode descarregar os dados correspondentes ao tempo local a partir do arquivo/segmento que pode ser acessado através de URI FileURI(r,i) com i = (r, tp).

[00412] Geralmente, os clientes podem descarregar todo o arquivo e podem então acessar o tempo de reprodução tP. No entanto, não necessariamente toda a informação do arquivo 3GP precisa ser descarregado, visto que o arquivo 3GP fornece estruturas para mapear a temporização local para faixas de byte. Portanto, apenas as faixas de byte específicas para acessar o tempo de reprodução tP podem ser suficientes para se reproduzir a mídia desde que a informação de acesso randômico suficiente esteja disponível. Além da informação suficiente sobre a estrutura e mapeamento da faixa de byte e a temporização local do segmento de mídia podem ser fornecidas na parte inicial do segmento, por exemplo, utilizando um índice de segmento. Tendo-se acesso aos, por exemplo, 1200 bytes iniciais do segmento, o cliente pode ter informação suficiente para acessar diretamente a faixa de byte necessária para o tempo de reprodução tP.

[00413] Em um exemplo adicional, assume-se que o índice de segmento, possivelmente especificado como a caixa "tidx" como abaixo possa ser utilizado para identificar os desvios de byte do Fragmento necessário ou Fragmentos. Solicitações GET parciais podem ser formadas para o Fragmento ou Fragmentos necessários. Existem outras alternativas, por exemplo, o cliente pode emitir uma solicitação padrão para o arquivo e cancelar a mesma quando a primeira caixa "tidx" foi recebida. Busca

[00414] Um cliente pode tentar buscar um tempo de apresentação específico tp em uma representação. Com base na MPD, o cliente tem acesso ao momento inicial do segmento de mídia e URL de segmento de mídia de cada segmento na representação. O cliente pode obter o índice de segmento segment_index do segmento que mais provavelmente contém amostras de mídia para o tempo de apresentação tp como o índice de segmento máximo i, para o qual o momento inicial tS(r,i) é menor ou igual ao tempo de apresentação tp, isso é, segment_index = max {i|tS(r,i)<=tp}. O segmento URL é obtido como FileURI(r,i).

[00415] Note-se que a informação de temporização na MPD pode ser aproximada, devido aos problemas relacionados com a colocação dos Pontos de Acesso Randômicos, alinhamento de trilhos de mídia e mudança de temporização de mídia. Como resultado disso, o segmento identificado pelo procedimento acima pode começar em um momento ligeiramente posterior tp e os dados de mídia para o momento de apresentação tp podem estar no segmento de mídia anterior. No caso de busca, o tempo de busca pode ser atualizado para que seja igual a um primeiro tempo de amostra do arquivo recuperado, ou o arquivo anterior pode ser recuperado ao invés disso. No entanto, note-se que durante a reprodução continua, incluindo os casos nos quais existe uma comutação entre representações/versões alternativas, os dados de mídia para o tempo entre tp e o começo do segmento recuperado é, não obstante, disponível.

[00416] Para a busca precisa para um momento de apresentação tp, o cliente de sequenciamento HTTP precisa acessar um ponto de acesso randômico (RAP). Para se determinar o ponto de acesso randômico em um segmento de mídia no caso de Sequenciamento HTTP Adaptativo 3GPP, o cliente pode, por exemplo, utilizar a informação na caixa "tidx" ou "sidx", se presente, para localizar os pontos de acesso randômicos, e o tempo de apresentação correspondente na apresentação de mídia. Nos casos onde um segmento é um fragmento de filme 3GPP, é possível também que o cliente utilize a informação dentro das caixas "moof" e "mdat", por exemplo, para localizar os RAPs e obter o tempo de apresentação necessário da informação no fragmento de filme e o tempo inicial de segmento derivado da MPD. Se nenhum RAP com tempo de apresentação anterior ao tempo de apresentação solicitado tp estiver disponível, o cliente pode acessar o segmento anterior ou pode apenas utilizar o primeiro ponto de acesso randômico como resultado de busca. Quando os segmentos de mídia começam com um RAP, esses procedimentos são simples.

[00417] Além disso, deve-se notar que não necessariamente toda a informação do segmento de mídia precisa ser descarregada para se acessar o tempo de apresentação tp. O cliente pode, por exemplo, inicialmente solicitar a caixa "tidx" ou "sidx" do começo do segmento de mídia utilizando solicitações de faixa de byte. Pelo uso das caixas "tidx" ou "sidx", a temporização de segmento pode ser mapeada para faixas de byte do segmento. Pela utilização contínua de solicitações HTTP parciais, apenas as partes relevantes do segmento de mídia precisam ser acessadas, para uma experiência de usuário aperfeiçoada e baixos retardos de inicialização. Geração de Lista de Segmento

[00418] Como descrito aqui, deve ser aparente como se implementar um cliente de sequenciamento HTTP de forma direta que utilize a informação fornecida pela MPD para criar uma lista de segmentos para uma representação que possui uma duração de segmento aproximada sinalizada de dur. Em algumas modalidades, o cliente pode designar os segmentos de mídia dentro de uma representação de índices consecutivos i = 1, 2, 3,..., isso é, o primeiro segmento de mídia recebe o índice i=1, o segundo segmento de mídia recebe o índice i=2, e assim por d ante. Então, a lista de segmentos de mídia com os índices de segmento i recebe startTime[i] e URL[i] é gerado, por exemplo, como se segue. Primeiro, o índice i é configurado para 1. O momento inicial do primeiro segmento de mídia é obtido como 0, startTime[1]=0. O URL do segmento de mídia i, URL[i] é obtido como FileURI(r,i). O processo continua para todos os segmentos de mídia descritos com índice i e o startTime[i] do segmento de mídia 1 é obtido como (i-1)*dur e o URL[i] é obtido como FileURI(r,i). Solicitações HTTP/TCP Simultâneas

[00419] Uma preocupação no sistema de sequenciamento de solicitação de bloco é um desejo de sempre se solicitar os blocos de qualidade mais alta que podem ser completamente recebidos em tempo para reprodução. No entanto, a taxa de chegada pode não ser conhecida de antemão e, assim, pode acontecer de um bloco solicitado não chegar a tempo de ser reproduzido. Isso resulta em uma necessidade de se interromper a reprodução de mídia, que resulta em uma experiência de usuário ruim. Esse problema pode ser mitigado pelos algoritmos de cliente que assumem uma abordagem conservadora da seleção de blocos para solicitar pela solicitação de blocos com qualidade inferior (e de menor tamanho) que têm mais chances de serem recebidos a tempo, mesmo se a taxa de chegada de dados cair durante a recepção do bloco. No entanto, essa abordagem conservadora tem a desvantagem de se possivelmente distribuir uma reprodução de qualidade inferior para o usuário ou dispositivo de destino, que também é uma experiência de usuário ruim. O problema pode ser aumentado quando as múltiplas conexões HTTP são utilizadas ao mesmo tempo para descarregar diferentes blocos, como descrito abaixo, visto que os recursos de rede disponíveis são compartilhados através das conexões e, dessa forma, estão sendo simultaneamente utilizados para os blocos com diferentes tempos de reprodução.

[00420] Pode ser vantajoso que o cliente emita solicitações para múltiplos blocos simultaneamente, onde nesse contexto "simultaneamente" significa respostas às solicitações estejam ocorrendo em intervalos de tempo sobrepostos e não seja necessariamente o caso de as solicitações serem feitas precisamente ou até mesmo quase ao mesmo tempo. No caso do protocolo HTTP, essa abordagem pode aperfeiçoar a utilização da largura de banda disponível devido ao comportamento do protocolo TCP (como é bem sabido). Isso pode ser especialmente importante para se aperfeiçoar 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 inicialmente, e, dessa forma, a utilização de várias conexões HTTP/TCP nesse ponto pode acelerar drasticamente o tempo de distribuição de dados dos primeiros blocos. No entanto, a solicitação de blocos diferentes ou fragmentos através de conexões HTTP/TCP diferentes também pode resultar em um desempenho degradado, visto que as solicitações para os blocos que devem ser reproduzidos primeiro estão competindo com as solicitações para blocos subsequentes, downloads HTTP/TCP competidores podem variar muito em sua velocidade de distribuição e, dessa forma, o tempo de finalização da solicitação pode ser muito variável, e é geralmente impossível se controlar quais downloads HTTP/TCP serão completados rapidamente e quais serão mais lentos, e, dessa forma, é provável que pelo menos parte do tempo os downloads HTTP/TCP dos primeiros poucos blocos sejam os últimos a serem completados, resultando, assim, em tempos de zapping de canal grandes e variáveis.

[00421] Supõe-se que cada bloco ou fragmento de um segmento seja descarregado através de uma conexão HTTP/TCP separada, e que o número de conexões paralelas seja igual a n e a duração de reprodução de cada bloco seja de t segundos, e que a taxa de sequenciamento do conteúdo associado com o segmento seja S. Quando o cliente primeiro começa a sequência o conteúdo, solicitações podem ser emitidas para os primeiros n blocos, representando n*t segundos de dados de mídia.

[00422] Como é sabido pelos versados na técnica, existe uma grande variação na taxa de dados das conexões TCP. No entanto, para se simplificar essa discussão, supõe-se de forma ideal que todas as conexões estejam prosseguindo em paralelo de modo que o primeiro bloco seja completamente recebido aproximadamente ao mesmo tempo em que outros n-1 blocos solicitados. Para simplificar a discussão adicional, assume-se que a largura de banda agregada utilizada pelas na conexões de download seja fixada a um valor B para toda a duração do download, e que a taxa de sequenciamento S seja constante através de toda a representação. Supõe-se adicionalmente que a estrutura de dados de mídia seja tal que a reprodução de um bloco possa ser feita quando todo o bloco é disponível no cliente, isso é, a reprodução de um bloco só pode ser feita depois que todo o bloco seja recebido, por exemplo, devido à estrutura da codificação de vídeo subjacente, ou devido ao fato de a criptografia estar sendo empregada para criptografar cada fragmento ou bloco separadamente, e, dessa forma, todo o fragmento ou bloco precisa ser recebido antes de poder ser descriptografado. Dessa forma, para simplificar a discussão abaixo, considera-se que todo um bloco precise ser recebido antes de qualquer bloco poder ser reproduzido. Então, o tempo necessário antes de o primeiro bloco ter chegado e poder ser reproduzido é aproximadamente n*i*S/B.

[00423] Visto que é desejável se minimizar o tempo de zapping de conteúdo, é, portanto, desejável se minimizar n*t*S/B. O valor de t pode ser determinado por fatores tal como a estrutura de codificação de vídeo subjacente e como os métodos de ingestão são utilizados, e dessa forma i pode ser razoavelmente pequeno, mas valores muito pequenos de t levam a um mapa de segmento excessivamente complicado e possivelmente pode ser incompatível com codificação de vídeo eficiente e descriptografia, se utilizado. O valor de n pode afetar também o valor de B, isso é, B pode ser maior para um número maior n de conexões, e, dessa forma, reduzindo o número de conexões, n, tem o efeito negativo de redução potencial da quantidade de largura de banda disponível que é utilizada, B, e pode não ser eficiente para alcançar o objetivo de redução do tempo de zapping de conteúdo. O valor de S depende de qual representação é escolhida para download e reprodução, e de forma ideal S deve ser o mais próximo de B possível a fim de maximizar a qualidade de reprodução de mídia para as condições de rede determinadas. Dessa forma, para se simplificar essa discussão, assume-se que S é aproximadamente igual a B. Então, o tempo de zapping de canal é proporcional a n*L. Dessa forma, a utilização de mais conexões para se descarregar diferentes fragmentos pode degradar o tempo de zapping de canal se a largura de banda agregada utilizada pelas conexões for sub-linearmente proporcional ao número de conexões, que é tipicamente o caso.

[00424] Como um exemplo, supõe-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. Supõe-se que a representação com S=700 Kbps seja escolhida. Então, com n=1 o tempo de download para o primeiro bloco é 1*700/700=2 segundos, e com n=3 o tempo de download para o primeiro bloco é 3*700/800=2,65 segundos. Adicionalmente, à medida que o número de conexões aumenta a variação nas velocidades de download individuais das conexões é provável se aumentar (apesar de mesmo com uma conexão pode haver alguma variação significativa). Dessa forma, nesse exemplo, o tempo de zapping de canal e a variação no tempo de zapping de canal aumenta à medida que o número de conexões aumenta. Intuitivamente, os blocos que estão sendo distribuídos possuem prioridades diferentes, isso é, o primeiro blocos possui o prazo fatal de distribuição mais cedo, o segundo bloco possui o segundo prazo mais cedo, etc. ao passo que as conexões de download através das quais os blocos estão sendo distribuídos estão competindo por recursos de rede durante a distribuição, e, dessa forma, os blocos com os prazos fatais mais cedo se tornam atrasados à medida que mais blocos competidores são solicitados. Por outro lado, mesmo nesse caso, por fim, a utilização de mais de uma conexão de download permite o suporte de uma taxa de sequenciamento sustentavelmente mais alta, por exemplo, com três conexões uma taxa de sequenciamento de até 800 Kbps pode ser suportada nesse exemplo, ao passo que apenas uma sequência de 500 Kbps pode ser suportada com uma conexão.

[00425] Na prática, como notado acima, a taxa de dados de uma conexão pode ser altamente variável tanto dentro da mesma conexão através do tempo e entre conexões e, como resultado disso, os n blocos solicitados geralmente não completam ao mesmo tempo e de fato pode ser comumente o caso de um bloco poder ser completado em metade do tempo de outro bloco. Esse efeito resulta em um comportamento imprevisível visto que em alguns casos o primeiro bloco pode ser completado muito mais cedo de que outros blocos e em outros casos o primeiro bloco pode ser completado muito depois dos outros blocos, e como resultado disso o começo da reprodução pode em alguns casos ocorrer relativamente de forma rápida e em outros casos pode ser lento. Esse comportamento imprevisível pode ser frustrante para o usuário e pode, portanto, ser considerado uma experiência de usuário ruim.

[00426] O que se precisa, portanto, é de métodos nos quais múltiplas conexões TCP possam ser utilizadas para se aperfeiçoar o tempo de zapping de canal e a variação no tempo de zapping de canal, enquanto que, ao mesmo tempo, suporta a taxa de sequenciamento de boa qualidade possível. O que se precisa também é de métodos para permitir o compartilhamento de largura de banda disponível alocada para cada bloco a ser ajustada à medida que o tempo de reprodução de um bloco se aproxima, de modo que, se necessário, uma parte maior da largura de banda disponível possa ser alocada no sentido do bloco com o tempo de reprodução mais próximo. Solicitação HTTP/TCP Cooperativa

[00427] Descreve-se agora métodos para utilização de 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 faixa de byte HTTP, onde cada solicitação é para uma parte de um fragmento em um segmento fonte, ou todo um fragmento de um segmento fonte, ou uma parte ou um fragmento de reparo de um segmento de reparo, ou para todo o fragmento de reparo de um segmento de reparo.

[00428] As vantagens das solicitações HTTP/TCP cooperativas juntamente com a utilização dos dados de reparo FEC podem ser especialmente importantes para se fornecer tempos de zapping de canal consistentemente rápidos. Por exemplo, em um tempo de zapping de canal é provável que as conexões TCP tenham apenas sido iniciadas ou tenham permanecido inativas por algum período de tempo, caso no qual a janela de congestionamento, cwnd, está em um valor mínimo para as conexões, e, dessa forma, a velocidade de distribuição dessas conexões TCP levará vários RTTs, para subir e haverá uma variação alta nas velocidades de distribuição através das conexões TCP diferentes durante esse tempo de subida.

[00429] Uma visão geral do método não FEC é descrita agora, que é um método de solicitação HTTP/TCP cooperativo onde apenas os dados de mídia dos blocos de fonte são solicitados utilizando-se as múltiplas conexões HTTP/TCP simultâneas, isso é, nenhum dado de reparo FEC é solicitado. Com qualquer método não FEC, partes do mesmo fragmento são solicitadas através de conexões diferentes, por exemplo, utilizando solicitações de faixa de byte HTTP para partes do fragmento, e, dessa forma, por exemplo, cada solicitação de faixa de byte HTTP serve uma parte da faixa de byte indicada no mapa de segmento para o fragmento. Pode ser o caso de uma solicitação HTTP/TCP individual suba sua velocidade de distribuição para utilizar totalmente a largura de banda disponível através de vários RTTs, e, dessa forma, existe um período relativamente longo de tempo onde a velocidade de distribuição é inferior à largura de banda disponível, e, dessa forma, se uma única conexão HTTP/TCP é utilizada para descarregar, por exemplo, o primeiro fragmento de um conteúdo a ser reproduzido, o tempo de zapping de canal pode ser grande. Utilizando-se o método não FEC, o download de diferentes partes do mesmo fragmento através de diferentes conexões HTTP/TCP pode reduzir significativamente o tempo de zapping do canal.

[00430] Uma visão geral do método FEC é descrita agora, que é um método de solicitação de HTTP/TCP cooperativo onde os dados de mídia de um segmento fonte e dados de reparo FEC gerados a partir dos dados de mídia são solicitados utilizando-se múltiplas conexões HTTP/TCP simultâneas. Com o método FEC, partes do mesmo fragmento e dados de reparo FEC gerados a partir desse fragmento são solicitadas através de conexões diferentes, utilizando as solicitações de faixa de byte HTTP para partes do fragmento, e, dessa forma, por exemplo, cada solicitação de faixa de byte HTTP serve para uma parte da faixa de byte indicada no mapa de segmento para o fragmento. Pode ser o caso de uma solicitação HTTP/TCP individual aumentar sua velocidade de distribuição para utilizar totalmente a largura de banda disponível através de vários RTTs, e, dessa forma, existe um período de tempo relativamente longo onde a velocidade de distribuição é inferior à largura de banda disponível, e, dessa forma, se uma única conexão HTTP/TCP é utilizada para descarregar, por exemplo, o primeiro fragmento de um conteúdo a ser reproduzido, o tempo de zapping de canal pode ser grande. A utilização do método FEC tem as mesmas vantagens que o método não FEC, e tem a vantagem adicional de nem todos os dados solicitados precisarem chegar antes de o fragmento poder ser recuperado, reduzindo, assim, adicionalmente, o tempo de zapping de canal e a variação no tempo de zapping de canal. Pela realização de solicitações através de diferentes conexões TCP, a quantidade de tempo que leva para distribuir uma quantidade suficiente de dados para, por exemplo, recuperar o primeiro fragmento solicitado que permite que a reprodução de mídia inicie, pode ser muito reduzida e tornada muito mais consistente do que se as conexões TCP cooperativas e dados de reparo FEC não forem utilizados.

[00431] As figuras 24(a) a (e) ilustram um exemplo de flutuações de taxa de distribuição de 5 conexões TCP correndo através do mesmo link para o mesmo cliente a partir do servidor de rede HTTP de uma rede otimizada de dados de evoluído copiada (EVDO). Nas figuras 24(a) a (3), o eixo geométrico X ilustra o tempo em segundos, e o eixo geométrico Y ilustra a taxa na qual os bits são recebidos no cliente através de cada uma das 5 conexões TCP medida através de intervalos de 1 segundo, para cada conexão. Nessa emulação em particular, existem 12 conexões TCP no total correndo através desse link, e, dessa forma, a rede foi relativamente carregada durante o tempo ilustrado, que pode ser típico quando mais de um cliente está sequenciando dentro da mesma célula de uma rede móvel. Note-se que apesar de as taxas de distribuição serem de alguma forma correlacionadas com o tempo, existe uma diferença grande nas taxas de distribuição das 5 conexões em muitos pontos no tempo.

[00432] A figura 25 ilustra uma possível estrutura de solicitação para um fragmento que tem 250.000 bits de tamanho (aproximadamente 31,25 kilobytes), onde existem 4 solicitações de faixa de byte feitas em paralelo para diferentes partes do fragmento, isso é, a primeira conexão HTTP solicita os primeiros 50.000 bits, a segunda conexão HTTP solicita os próximos 50.000 bits, a terceira conexão HTTP solicita os próximos 50.000 bits, e a quarta conexão HTTP solicita as próximas 50.000 bits. Se FEC não for utilizado, isso é, o método não FEC, então essas são apenas 4 solicitações para o fragmento nesse exemplo. Se FEC for utilizado, isso é, o método FEC, então nesse exemplo existe uma conexão HTTP adicional que solicita 50.000 bits adicionais dos dados de reparo FEC de um segmento de reparo gerado a partir do fragmento.

[00433] A figura 26 é um aumento dos primeiros dois segundos das 5 conexões TCP ilustradas nas figuras 24(a) a (e), onde na figura 26 o eixo geométrico X ilustra o tempo nos intervalos de 100 milissegundos, e o eixo geométrico Y ilustra a taxa na qual os bits são recebidos no cliente através de cada uma das 5 conexões TCP medidas através de intervalos de 100 milissegundos. Uma linha ilustra a quantidade agregada de bits que foram recebidos no cliente para o fragmento a partir das primeiras 4 conexões HTTP (excluindo a conexão HTTP através da qual os dados FEC são solicitados), isso é, o que chega utilizando o método não FEC. Outra linha ilustra a quantidade agregada de bits que foram recebidos no cliente para o fragmento a partir de todas as 5 das conexões HTTP (incluindo a conexão HTTP através da qual os dados FEC são solicitados), isso é, o que chega utilizando o método FEC. Para o método FEC, é considerado que o fragmento pode ser decodificado FEC a partir da recepção de quaisquer 200.000 bits dos 250.000 bits solicitados, que podem ser realizados se, por exemplo, um código FEC Reed-Solomon é utilizado, e que pode ser essencialmente realizado se, por exemplo, o código RaptorQ descrito em Luby IV é utilizado. Para o método FEC, nesse exemplo, dados suficientes são recebidos para recuperar o fragmento utilizando a decodificação FEC depois do 1 segundo, permitindo que um tempo de zapping de canal de 1 segundo (considerando que os dados para fragmentos subsequentes podem ser solicitados e recebidos antes de o primeiro fragmento ser totalmente reproduzido). Para o método não FEC, nesse exemplo, todos os dados para 4 solicitações precisa ser recebido antes de o fragmento poder ser recuperado, o que ocorre depois de 1,7 segundos, levando a um tempo de zapping de canal de 1,7 segundos. Dessa forma, no exemplo ilustrado na figura 26, o método não FEC é 70% pior em termos de tempo de zapping de canal que o método FEC. Uma das razões para a vantagem ilustrada pelo método FEC nesse exemplo é que, para o método FEC, a recepção de qualquer 80% dos dados solicitados permite a recuperação do fragmento, ao passo que para o método não FEC, a recepção de 100% de dados solicitados é necessária. Dessa forma, o método não FEC precisa esperar pela conexão TCP mais lenta para encerrar a distribuição, e em vista das variações naturais na taxa de distribuição TCP existe chance de se ter uma variação ampla na velocidade de distribuição da conexão TCP mais lenta em comparação com uma conexão TCP média. Com o método FEC nesse exemplo, uma conexão TCP lenta não determina quando o fragmento é recuperável. Ao invés disso, para o método FEC, a distribuição de dados suficientes é muito maior que uma função da taxa de distribuição TCP média do que o a pior taxa de distribuição TCP.

[00434] Existem muitas variações do método não FEC e método FEC descritas acima. Por exemplo, as solicitações HTTP/TCP cooperativas podem ser utilizadas para apenas os primeiros poucos fragmentos depois de um zap de canal ter ocorrido, e depois disso, apenas uma única solicitação HTTP/TCP é utilizada para descarregar os fragmentos adicionais, múltiplos fragmentos, ou segmentos inteiros. Como outro exemplo, o número de conexões HTTP/TCP cooperativas utilizadas pode ser uma função de ambas a urgência dos fragmentos sendo solicitada, isso é, o quão iminente é o tempo de reprodução desses fragmentos, e das condições de rede atuais.

[00435] Em algumas variações, uma pluralidade de conexões HTTP pode ser utilizada para solicitar os dados de reparo a partir dos segmentos de reparo. Em outras variações, diferentes quantidades de dados podem ser solicitados em diferentes conexões HTTP, por exemplo, dependendo do tamanho atual do armazenador de mídia e a taxa de recepção de dados no cliente. Em outra variação, as representações fonte não são independentes uma da outra, mas ao invés disso, representam uma codificação de mídia em camadas, onde, por exemplo, uma representação de fonte melhorada pode depender de uma representação fonte de base. Nesse caso, pode haver uma representação de reparo correspondente à representação de fonte de base e outra representação de reparo correspondendo á combinação das representações fonte melhorada e de base.

[00436] Elementos gerais adicionais adicionam são adicionados às vantagens que se pode realizar pelos métodos descritos acima. Por exemplo, o número de conexões HTTP utilizadas pode variar dependendo da quantidade atual de mídia no armazenador de mídia, e/ou a taxa de recepção no armazenador de mídia. As solicitações HTTP cooperativas utilizando FEC, isso é, o método FEC descrito acima e variações desse método, podem ser utilizadas agressivamente quando o armazenador de mídia é relativamente vazio, por exemplo, solicitações HTTP mais cooperativas são feitas em paralelo para partes diferentes do primeiro fragmento, solicitando todo o fragmento fonte e uma fração relativamente grande de dados de reparo do fragmento de reparo correspondente, e então transitando para um número reduzido de solicitações HTTP simultâneas, solicitando partes maiores dos dados de mídia por solicitação, e solicitando uma fração menor de dados de reparo, por exemplo, transitando para 1, 2 ou 3 solicitações HTTP simultâneas, transitando para realizar as solicitações para todos os fragmentos ou múltiplos fragmentos consecutivos por solicitação, e transitando para solicitar nenhum dado de reparo, à medida que o armazenador de mídia aumenta.

[00437] Como outro exemplo, a quantidade de dados de reparo FEC pode variar como uma função do tamanho de armazenador de mídia, isso é, quando o armazenador de mídia é pequeno então mais dados de reparo FEC podem ser solicitados, e à medida que o armazenador de mídia aumenta então a quantidade de dados de reparo FEC solicitados podem diminuir, e em algum momento quando o armazenador de mídia é suficientemente grande então nenhum dos dados de reparo FEC pode ser solicitado, apenas os dados dos segmentos fonte das representações fonte. Os benefícios de tais técnicas melhoradas é que as mesmas podem permitir tempos de zapping de canal mais rápidos e mais consistentes, e mais resiliência contra situações intermitentes e de interrupção de mídia em potencial, enquanto que, ao mesmo tempo, a minimização da quantidade de largura de banda adicional utilizada além da quantidade que seria consumida apenas pela distribuição de mídia nos segmentos fonte pela redução de tráfego de mensagem de solicitação e dados de reparo FEC, enquanto que ao mesmo tempo permite o suporte das taxas de mídia mais altas possíveis para as condições de rede determinadas. Melhorias Adicionais Quando da Utilização de Conexões HTTP Simultâneas

[00438] Uma solicitação HTTP/TCP pode ser abandonada se uma condição adequada for correspondida e outra solicitação HTTP/TCP pode ser feita para descarregar os dados que podem substituir os dados solicitados na solicitação abandonada, onde a segunda solicitação HTTP/TCP pode solicitar exatamente os mesmos dados que na solicitação original, por exemplo, dados fonte; ou dados sobrepostos, por exemplo, alguns dos mesmos dados como na solicitação original, por exemplo, dados fonte; ou dados sobrepostos, por exemplo, alguns dos mesmos dados fonte e dados de reparo que não foram solicitados na primeira solicitação; ou dados completamente separados, por exemplo, dados de reparo que não foram solicitados na primeira solicitação. Um exemplo de uma condição adequada é que uma solicitação falha devido à ausência de uma resposta da BSI dentro de um tempo fornecido ou uma falha no estabelecimento de uma conexão de transporte para a BSI ou recebimento de uma mensagem de falha explícita do servidor ou outra condição de falha.

[00439] Outro exemplo de uma condição adequada é que o recebimento de dados prossegue normalmente de forma lenta, de acordo com uma comparação de uma medição da velocidade de conexão (taxa de chegada de dados em resposta à solicitação em questão) com a velocidade de conexão esperada ou com uma estimativa de velocidade de conexão necessária para receber a resposta antes do tempo de reprodução dos dados de mídia contidos ou outro tempo independente desse tempo.

[00440] Essa abordagem tem a vantagem no caso de a BSI algumas vezes exibir falhas ou um desempenho ruim. Nesse caso a abordagem acima aumenta a probabilidade de o cliente poder continuar a reproduzir de forma confiável os dados de mídia a despeito de falhas ou baixo desempenho dentro da BSI. Note-se que em alguns casos pode haver vantagem para designação da BSI de tal forma que exiba tais falhas o u desempenho ruim em ocasiões, por exemplo, tal desenho pode ter um custo inferior ao de um desenho alternativo que não exibe tais falhar ou desempenho ruim ou que exiba esses com menor frequência. Nesse caso, o método descrito aqui tem a vantagem adicional de que permite a utilização de tal desenho de custo inferior para a BSI sem uma degradação consequente na experiência de usuário.

[00441] Em outra modalidade, o número de solicitações emitido para os dados correspondentes a um determinado bloco pode ser dependente de se uma condição adequada com relação ao bloco é correspondida. Se a condição não for correspondida então o cliente pode ser restringido de realizar solicitações adicionais para o bloco se a finalização bem sucedida de todas as solicitações de dados atualmente incompletas para o bloco permitir a recuperação do bloco com alta probabilidade. Se a condição for correspondida então um número maior de solicitações para o bloco pode ser emitido, isso é, a restrição acima não se aplica. Um exemplo de uma condição adequada é que o tempo até o momento de reprodução programado do bloco ou outro tempo dependente desse momento se encontra abaixo de um limite fornecido. Esse método tem vantagens visto que as solicitações adicionais para os dados para um bloco sejam emitidas quando o recebimento do bloco se torna mais urgente, visto que o tempo de reprodução dos dados de mídia compreendendo o bloco está próximo. No caso de protocolos de transporte comuns tal como HTTP/TCP, essas solicitações adicionais têm o efeito de aumento do compartilhamento da largura de banda disponível dedicada aos dados que contribui para a recepção de bloco em questão. Isso reduz o tempo necessário para a recepção de dados suficiente para recuperar o bloco para completar e, portanto, reduz a probabilidade de o bloco não poder ser recuperado antes de o tempo de reprodução programado dos dados de mídia compreendendo o bloco. Como descrito acima, se o bloco não for recuperado antes do tempo de reprodução programado de dados de mídia compreendendo o bloco então a reprodução pode sofrer interrupções resultando em uma experiência de usuário ruim e, portanto, o método descrito aqui reduz de forma vantajosa a probabilidade dessa experiência de usuário ruim.

[00442] Deve-se compreender que por toda essa especificação referências ao tempo de reprodução programado de um bloco se refere ao tempo no qual os dados de mídia codificados compreendendo o bloco pode primeiro estar disponível no cliente a fim de alcançar a reprodução da apresentação sem pausa. Como será claro aos versados na técnica de sistemas de apresentação de mídia, esse tempo é, na prática, ligeiramente anterior ao tempo real de surgimento da mídia compreendendo o bloco nos transdutores físicos utilizados para reprodução (tela, alto falante, etc.) visto que várias funções de transformação podem precisar ser aplicadas aos dados de mídia compreendendo o bloco para realizar a reprodução real desse bloco e essas funções podem exigir uma quantidade determinada de tempo para serem completadas. Por exemplo, dados de mídia são geralmente transportados na forma comprimida e uma transformação de descompressão pode ser aplicada. Métodos de Geração de Estruturas de Arquivo Suportando Métodos HTTP/FEC Cooperativos

[00443] Uma modalidade para geração de uma estrutura de arquivo que pode ser utilizada de forma vantajosa por um cliente empregando métodos HTTP/FEC cooperativos é descrita agora. Nessa modalidade, para cada segmento fonte existe um segmento de reparo correspondente gerado como se segue. O parâmetro R indica em média quantos dados de reparo FEC são gerados para os dados fonte nos segmentos fonte. Por exemplo, R=0,33 indica que se um segmento fonte contiver 1.000 kilobytes de dados, então o segmento de reparo correspondente contém aproximadamente 330 kilobytes de dados de reparo. O parâmetro S indica o tamanho de símbolo em bytes utilizado para a codificação e decodificação FEC. Por exemplo, S=64 indica que os dados fonte e os dados de reparo compreendem símbolos do tamanho de 64 bytes cada para fins de codificação e decodificação FEC.

[00444] O segmento de reparo pode ser gerado para um segmento fonte como se segue. Cada fragmento do segmento fonte é considerado um bloco fonte para fins de codificação FEC, e, dessa forma, cada fragmento é tratado como uma sequência de símbolos fonte de um bloco fonte de onde os símbolos de reparo são gerados. O número de símbolos de reparo no total gerado para os primeiros i fragmentos é calculado como TNRS(i) = teto (R*B(i)/S), onde o teto (x) é a função que envia o inteiro menor com um valor que é pelo menos x. Dessa forma, o número de símbolos de reparo gerados para o fragmento i é NRS(i) = TNRS(i)-TNRS(i-1).

[00445] O segmento de reparo compreende uma concatenação dos símbolos de reparo para os fragmentos, onde a ordem dos símbolos de reparo dentro de um segmento de reparo está na ordem dos fragmentos a partir dos quais são gerados, e dentro de um fragmento os símbolos de reparo estão em ordem de seu ESI. A estrutura do segmento de reparo correspondente a uma estrutura de segmento fonte é ilustrada na figura 27, incluindo um gerador de segmento de reparo 2700.

[00446] Note-se que pela definição do número de símbolos de reparo para um fragmento como descrito acima, o número total de símbolos de reparo para todos os fragmentos anteriores e, dessa forma, o índice de byte no segmento de reparo, só depende de R, S, B(i-1) e B(i) e não depende de qualquer estrutura anterior ou subsequente de fragmentos dentro do segmento fonte. Isso é vantajoso visto que permite que um cliente compute rapidamente a posição do início de um bloco de reparo dentro do segmento de reparo, e também compute rapidamente o número de símbolos de reparo dentro desse bloco de reparo, utilizando apenas a informação local sobre a estrutura do fragmento correspondente do segmento fonte do qual o bloco de reparo foi gerado. Dessa forma, se um cliente decidir iniciar o download e reprodução de um fragmento a partir do meio de um segmento fonte, o mesmo pode rapidamente gerar e acessar o bloco de reparo correspondente a partir de dentro do segmento de reparo correspondente.

[00447] O número de símbolos fonte no bloco fonte correspondendo ao fragmento i é calculado como NSS(i)=teto((B(i)-B(i-1))/S). O último símbolo fonte é preenchido com bytes zero para fins de codificação e decodificação FEC se B(i)-B(i-1) não for um múltiplo de S, isso é, o último símbolo fonte é preenchido com bytes zero de modo que seja igual a S bytes em tamanho para fins de codificação e decodificação FEC, mas esses bytes de enchimento zero não são armazenados como parte do segmento fonte. Nessa modalidade, os ESIs para o símbolo fonte são 0, 1,...,NSS(i)-1 e os ESIs para os símbolos de reparo são NSS(i),...,NSS(i)+NRS(i)-1.

[00448] O URL para um segmento de reparo nessa modalidade pode ser gerado a partir do URL para o segmento fonte correspondente simplesmente pela adição, por exemplo, do sufixo ".repair" ao URL do segmento fonte.

[00449] A informação de indexação de reparo e informação FEC para um segmento de reparo é implicitamente definido pela informação de indexação para o segmento fonte correspondente e a partir dos valores de R e S, como descrito aqui. Os desvios de tempo e a estrutura de fragmento compreendendo o segmento de reparo são determinados pelos desvios de tempo e estrutura do segmento fonte correspondente. O desvio de byte para o final dos símbolos de reparo no segmento de reparo correspondente ao fragmento i pode ser calculado como RB(i)=S*teto(R*B(i)/S). O número de bytes no segmento de reparo correspondente ao fragmento i é então RB(i)-RB(i-1), e dessa forma o número de símbolos de reparo correspondentes ao fragmento i é calculado como NRS(i)=(RB(i)-RB(i-1)/S. O número de símbolos fonte correspondentes ao fragmento i pode ser calculado como NSS(i)=teto((B(i)-B(i-1))/S. Dessa forma, nessa modalidade, a informação de indexação de reparo para um bloco de reparo dentro de um segmento de reparo e a informação FEC correspondente podem ser implicitamente derivados de R, S e a informação de indexação para o fragmento correspondente do segmento fonte correspondente.

[00450] Como um exemplo, considere-se o exemplo ilustrado na figura 28, ilustrando um fragmento 2 que começa no desvio de byte B(1) = 6,410 e termina no desvio de byte B(2)=6,770. Nesse exemplo, o tamanho de símbolo é S=64 bytes, e as linhas verticais pontilhadas ilustram os desvios de byte dentro do segmento fonte que correspondem a múltiplos de S. O tamanho do segmento de reparo total como uma fração do tamanho do segmento fonte é configurado para R = 0,5 nesse exemplo. O número de símbolos fonte no bloco fonte para o fragmento 2 é calculado como NSS(2)=teto((6,770-6,410)/64=teto (5,625)=6, e esses 6 símbolos fonte possuem ESIs 0,...,5, respectivamente, onde o primeiro símbolo fonte são os 62 primeiros bytes do fragmento 2 que iniciam no índice de byte 6,410 dentro do segmento fonte, o segundo símbolo fonte são os próximos 64 bytes do fragmento 2 que iniciam no índice de byte 6,474 dentro do segmento fonte, etc. O desvio de byte final do bloco de reparo correspondendo ao fragmento 2 é calculado como RB(2)=64*teto(0,5*6,770/64)=64*teto(62,89...)=64*53=3,392 e o desvio de byte inicial do bloco de reparo correspondendo ao fragmento 2 é calculado como RB(1)=64*teto(0,5*6,410/64)=64*teto(50,07...)=64*51=3,264, e, dessa forma, nesse exemplo, existem dois símbolos de reparo no bloco de reparo correspondendo ao fragmento 2 com ESIs 6 e 7, respectivamente, iniciando no desvio de byte 3,264 dentro do segmento de reparo e terminando em um desvio de byte 3,392.

[00451] Note-se que no exemplo ilustrado na figura 28, apesar de R=0,5 e haver 6 símbolos fonte correspondentes ao fragmento 2, o número de símbolos de reparo não é igual a 3, como se pode esperar se se utilizar simplesmente o número de símbolos fonte para calcular o número de símbolos de reparo, mas, ao invés disso, resultou em 2 de acordo com os métodos descritos aqui. Em oposição à simples utilização do número de símbolos fonte de um fragmento para determinar o número de símbolos de reparo, as modalidades descritas acima possibilitam o cálculo do posicionamento do bloco de reparo dentro do segmento de reparo apenas a partir da informação de índice associada com o bloco fonte correspondente do segmento fonte correspondente. Adicionalmente, à medida que o número K de símbolos fonte em um bloco fonte aumenta, o número de símbolos de reparo KR do bloco de reparo correspondente é aproximado por K*R, como em geral, KR é no máximo teto (K*R) e KR é pelo menos o piso ((K-1)*R), onde piso(x) é o maior inteiro que é no máximo igual a x.

[00452] Existem muitas variações das modalidades acima para a geração de uma estrutura de arquivo que possa ser utilizada de forma vantajosa por um cliente empregando métodos HTTP/FEC cooperativos, como os versados na técnica reconhecerão. Como um exemplo de uma modalidade alternativa, um segmento original para uma representação pode ser dividido em N>1 segmentos paralelos, onde para i=1,...,N, uma fração especificada Fi do segmento original é contida no segmento paralelo i, e onde a soma para i=1,...,N de Fi é igual a 1. Nessa modalidade, pode haver um mapa de segmento principal que é utilizado para derivar os mapas de segmento para todos os segmentos paralelos, similar a como o mapa de segmento de reparo é derivado do mapa de segmento fonte na modalidade descrita acima. Por exemplo, o mapa de segmento principal pode indicar a estrutura de fragmento se todos os dados de mídia fonte não forem divididos em segmentos paralelos, mas, ao invés disso, contidos no segmento original, e então o mapa de segmento para o segmento paralelo i pode ser derivado do mapa de segmento principal pelo cálculo de que, se a quantidade de dados de mídia em um primeiro prefixo de fragmentos do segmento original for igual a L bytes, então o número total de bytes desse prefixo no agregado entre o primeiro segmento paralelo i é teto(L*Gi), onde Gi é a soma através de j=1,...,i de Fj. Como outro exemplo de uma modalidade alternativa, os segmentos podem consistir da combinação dos dados de mídia fonte originais para cada fragmento seguidos imediatamente pelos dados de reparo para esse fragmento, resultando em um segmento que contém uma mistura de dados de mídia fonte e dados de reparo gerados utilizando um código FEC a partir desses dados de mídia fonte. Como outro exemplo de uma modalidade alternativa, um segmento que contém uma mistura de dados de mídia fonte e dados de reparo pode ser dividido em múltiplos segmentos paralelos contendo uma mistura de dados de mídia fonte e dados de reparo.

[00453] Modalidades adicionais podem ser vislumbradas pelos versados na técnica depois da leitura dessa descrição. Em outras modalidades, as combinações ou subcombinações da invenção descrita acima podem ser vantajosamente criadas. As disposições ilustrativas dos componentes são ilustradas para fins de ilustração e deve ser compreendido que combinações, adições, novas disposições e similares são contempladas nas modalidades alternativas da presente invenção. Dessa forma, enquanto a invenção foi descrita com relação às modalidades ilustrativas, os versados na técnica reconhecerão que inúmeras modificações são possíveis.

[00454] Por exemplo, os processos descritos aqui podem ser implementados utilizando-se componentes de hardware, componentes de software, e/ou qualquer combinação dos mesmos. Em alguns casos, os componentes de software podem ser fornecidos em mídia não transitória tangível para execução em hardware que é fornecido com mídia ou é separado da mídia. A especificação e os desenhos são, de acordo, considerados de forma ilustrativa ou invés de restritiva. Será, no entanto, evidente que várias modificações e mudanças podem ser feitas aqui sem se distanciar do espírito e escopo mais amplo da invenção como apresentados nas reivindicações e que a invenção deve cobrir todas as modificações e equivalências dentro do escopo das reivindicações a seguir.

Claims (9)

1. Método para uso em um sistema de comunicação no qual um dispositivo de cliente solicita arquivos de mídia a partir de um sistema de ingestão de mídia, o método CARACTERIZADO por compreender: fornecer, no sistema de ingestão de mídia, múltiplas camadas (1204, 1206, 1208) de dados de mídia dentro de arquivos de mídia, em que uma versão de conteúdo de mídia pode ser construída a partir de um subconjunto de múltiplas camadas (1204, 1206, 1208); e fornecer metadados (1202) para habilitar construção de solicitações para as camadas (1204, 1206, 1208) de dados de mídia; em que camadas compreendendo um bloco são armazenadas dentro de um único arquivo e metadados são fornecidos especificando faixas de bytes dentro do arquivo correspondendo às camadas individuais.

2. Método, de acordo com a reivindicação 1, CARACTERIZADO pelas camadas serem geradas ao utilizar uma técnica descrita em Padrão ITU-T H.264/SVC ou Padrão ITU-T H.264/AVC.

3. Método, de acordo com a reivindicação 1, CARACTERIZADO pelos metadados serem fornecidos em uma descrição de apresentação de mídia, MPD, ou como uma parte de um arquivo de mídia.

4. Aparelho para uso em um sistema de comunicação no qual um dispositivo de cliente solicita arquivos de mídia a partir de um sistema de ingestão de mídia, o aparelho CARACTERIZADO por compreender: meios para fornecer, no sistema de ingestão de mídia, múltiplas camadas (1204, 1206, 1208) de dados de mídia dentro de arquivos de mídia, em que uma versão de conteúdo de mídia pode ser construída a partir de um subconjunto de múltiplas camadas (1204, 1206, 1208); e meios para fornecer metadados (1202) para habilitar construção de solicitações para as camadas (1204, 1206, 1208) de dados de mídia; em que camadas compreendendo um bloco são armazenadas dentro de um único arquivo e metadados são fornecidos especificando faixas de bytes dentro do arquivo correspondendo às camadas individuais.

5. Método para uso em um sistema de comunicação em que um dispositivo cliente solicita blocos de mídia a partir de um sistema de ingestão de mídia, o método CARACTERIZADO por compreender: receber, no dispositivo cliente, múltiplas camadas (1204, 1206, 1208) de dados de mídia dentro de arquivos de mídia, em que uma versão de conteúdo de mídia pode ser construída a partir de um subconjunto de múltiplas camadas (1204, 1206, 1208); e receber metadados (1202) para habilitar construção de solicitações para as camadas (1204, 1206, 1208) de dados de mídia; em que camadas compreendendo um bloco são armazenadas dentro de um único arquivo e metadados são fornecidos especificando faixas de bytes dentro do arquivo correspondendo às camadas individuais.

6. Método, de acordo com a reivindicação 5, CARACTERIZADO pelas camadas serem geradas ao utilizar uma técnica descrita em Padrão ITU-T H.264/SVC ou Padrão ITU-T H.264/AVC.

7. Método, de acordo com a reivindicação 5, CARACTERIZADO pelos metadados serem fornecidos em uma descrição de apresentação de mídia, MPD, ou como uma parte de um arquivo de mídia.

8. Aparelho para uso em um sistema de comunicação em que um dispositivo cliente solicita blocos de mídia a partir de um sistema de ingestão de mídia, o aparelho CARACTERIZADO por compreender: meios para receber, no dispositivo cliente, múltiplas camadas (1204, 1206, 1208) de dados de mídia dentro de arquivos de mídia, em que uma versão de conteúdo de mídia pode ser construída a partir de um subconjunto de múltiplas camadas (1204, 1206, 1208); e meios para receber metadados (1202) para habilitar construção de solicitações para as camadas (1204, 1206, 1208) de dados de mídia; em que camadas compreendendo um bloco são armazenadas dentro de um único arquivo e metadados são fornecidos especificando faixas de bytes dentro do arquivo correspondendo às camadas individuais.

9. Memória CARACTERIZADA por compreender instruções que, quando executadas, fazem com que pelo menos um computador realize um método conforme definido em qualquer uma das reivindicações 1 a 3 ou 5 a 7.

Images